⚖️ n8n vs. Make vs. código
A base que orquesta tu flujo define tu límite de flexibilidad y tu nivel mínimo de mantenimiento. Hay tres caminos: n8n (low-code, self-host, muy flexible), Make (visual, SaaS, rápido para empezar) y código (control total, mantenimiento total).
✓ Empieza de forma simple cuando
- ✓El flujo cabe en los conectores listos de la herramienta.
- ✓Quieres validar la idea rápido, sin infraestructura.
- ✓La lógica es directa, sin transformaciones exóticas.
✗ Pasa a código cuando
- ✗Te encuentras con límites de ejecución o de licencia del SaaS.
- ✗Falta un conector y el pegamento queda demasiado frágil.
- ✗La lógica se convierte en un enredo de nodos imposible de mantener.
Rápido, SaaS, visual.
Flexible, self-host.
Máximo control y mantenimiento.
Una mala elección sale cara después.
🧠 Cuándo usar LLM y qué modelo elegir
Primero: la tarea necesita de un LLM? Si una regla, una expresión regular o un IF lo resuelven, úsalos: son más baratos y deterministas. Si necesitas interpretar lenguaje, elige el modelo según el eje costo × capacidad: pequeño y barato para clasificar, grande y caro para razonamientos complejos.
Modelo pequeño / barato
Clasificar, extraer campos, responder sí/no, etiquetar el sentimiento. Tareas acotadas y de alto volumen donde cada centavo por llamada importa.
Modelo mediano
Resumir, redactar respuestas, seguir instrucciones de varios pasos. El equilibrio predeterminado para la mayoría de las automatizaciones.
Modelo grande / caro
Razonamiento complejo, análisis de documentos largos, decisiones de alto riesgo. Úsalo solo cuando la capacidad adicional compense el costo.
💡 Consejo práctico
Empieza con el el modelo más barato que resuelve y sube de nivel solo si la calidad no alcanza la métrica. Lo contrario — empezar desde arriba «por si acaso» — consume el presupuesto y oculta cuánta capacidad necesitas realmente.
¿La regla lo resuelve sin LLM?
Ajustar la tarea al modelo.
Costo por token × escala.
Solo si la métrica lo exige.
📚 RAG: conocimiento propio en contexto
El modelo solo conoce lo que vio durante el entrenamiento. Cuando la automatización depende de información que solo existe en tu empresa — políticas, catálogo, historial de clientes: usas RAG: busca los fragmentos relevantes de tu base de conocimiento y los inyecta en el prompt, anclando la IA en tu verdad en lugar de dejar que invente.
📐 Cuándo conviene usar RAG (y cuándo no)
- •Vale: conocimiento propio, cambia con frecuencia, demasiado grande para caber en el prompt.
- •No cuenta: la información cabe directamente en el prompt, o el modelo ya la conoce (conocimiento general).
- •RAG agrega infraestructura (vector + búsqueda): paga ese costo solo cuando resuelva un problema real.
Buscar antes de generar.
Búsqueda por significado.
Reduce las alucinaciones.
Hay conocimiento propio.
🔌 MCP e integración de herramientas
Cuándo la IA necesita actuar — leer un archivo, consultar una base de datos, llamar a una API — el MCP (Model Context Protocol) ofrece una forma estandarizada de conectar la IA con esas herramientas, sin escribir código de integración distinto para cada una. Es lo que transforma el modelo de «responde texto» en «usa herramientas».
🔧 Qué estandariza el MCP
- •Cómo descubre la IA qué herramientas existen y qué hace cada una.
- •Cómo invoca una herramienta y recibe el resultado de vuelta.
- •La reutilización: el mismo servidor MCP sirve para cualquier cliente compatible.
💡 Consejo práctico
No toda automatización necesita MCP. Si el flujo ya orquesta los pasos (n8n decide el orden), puedes llamar directamente a las API. MCP destaca cuando es la IA propia que decide qué herramienta usar y cuándo; ahí estandarizar el acceso vale la pena.
Acceso estandarizado.
IA que actúa, no solo habla.
Un servidor, muchos clientes.
La IA elige la herramienta.
🔗 APIs, webhooks y bases de datos
Las tuberías de la automatización. API: solicitas datos cuando los necesitas. Webhook: el sistema te avisa cuando ocurre algo. Base de datos: guardas y consultas el estado entre ejecuciones. Supabase es un ejemplo práctico que reúne base de datos + API + autenticación en un paquete.
✓ Usa webhook cuando
- ✓Quieres reaccionar en el momento en que ocurre algo.
- ✓El evento es impredecible (un cliente envía un formulario).
- ✓Seguir preguntando "¿ya hay novedades?" sería un desperdicio.
✓ Usa API/polling cuando
- ✓Necesitas obtener datos bajo demanda.
- ✓El sistema de origen no ofrece webhook.
- ✓Basta con fijar un horario para la verificación.
🗄️ Cuando necesitas una base de datos
- •La automatización necesita recordar algo entre ejecuciones (estado, historial).
- •Necesitas evitar procesar el mismo elemento dos veces (control de duplicados).
- •Supabase ofrece una base de datos Postgres + API REST + autenticación con poca configuración.
Pull: tú lo solicitas.
Push: te avisa.
Guarda el estado.
Base de datos + API + auth.
🎚️ Criterios de decisión y trade-offs
Toda elección de stack cambia una cosa por otra. Un conjunto explícito de criterios —costo, velocidad de entrega, mantenimiento, control, escala, dependencia del proveedor— te obliga a justificar cada decisión, en vez de seguir una moda o una costumbre. Y te da argumentos frente al cliente.
🧾 Cuadro de trade-offs (modelo)
⚠️ Atención
Cuidado con lock-in: elegir una herramienta que retenga tus datos y flujos dificulta cambiar después. Y recuerda que el modelo más nuevo o la herramienta más popular casi nunca es la elección correcta — lo simple gana cuando hay empate.
Toda elección implica un intercambio.
Explícito y ponderado.
Piensa en el costo de salir.
Gana en caso de empate.
🧰 Resumen del módulo
Próximo Módulo:
3.3 · Diseño de prompts y lógica de decisión — el cerebro de la automatización.