n8n y agentes de IA: cómo crear workflows fiables con aprobación humana
n8n puede convertir un agente en un workflow operativo, pero el canvas no sustituye permisos, contratos ni evaluación. Diseña una tarea estrecha, separa decisiones de efectos y deja al humano la última palabra cuando haya riesgo.
n8n puede convertir un agente en un workflow operativo, pero el canvas no sustituye permisos, contratos ni evaluación. Diseña una tarea estrecha, separa decisiones de efectos y deja al humano la última palabra cuando haya riesgo.
Un agente de IA en n8n es un workflow en el que un modelo elige una o varias tools para alcanzar una meta. Es útil cuando el trabajo tiene pasos, integraciones y decisiones que cambian; no es una excusa para dar acceso indiscriminado a correo, bases de datos o producción.
Checklist
Qué es un agente de IA en n8n — y qué no es
Una cadena ejecuta pasos que tú defines de antemano: recibir un formulario, normalizar campos, llamar una API y guardar una respuesta. Un agente añade una decisión del modelo sobre qué tool usar, con qué argumentos y en qué orden. Esa flexibilidad tiene valor cuando la entrada es ambigua; también introduce rutas de fallo que un workflow determinista no tenía.
No confundas un AI Agent con cualquier nodo que llame a un LLM. Para clasificación, extracción con schema, resumen o transformación de texto, una cadena con salida estructurada suele ser más barata, fácil de probar y más segura. El agente entra cuando necesita seleccionar capacidades y la selección no cabe razonablemente en un `if` explícito.
La prueba de realidad es sencilla: describe la tarea sin mencionar el modelo. Si no puedes enumerar input permitido, resultado esperado, herramientas necesarias, dueño de la decisión y efecto externo, todavía no tienes un caso de uso; tienes una intención vaga.
Caso de inicio que sí merece un agente
Un buen primer caso es el triage de incidencias internas. Un webhook recibe título, descripción, servicio y enlace; el agente consulta una base de conocimiento de solo lectura y propone categoría, prioridad, evidencia y siguiente acción. El workflow valida el objeto de salida. Solo después, una persona aprueba crear o actualizar el ticket en el sistema correspondiente.
Ese diseño ofrece un baseline claro. Puedes medir si la categoría es correcta, si la evidencia existe, si eligió una tool adecuada y cuánto tarda. También puedes comparar una cadena simple contra el agente: si la cadena resuelve el 90% de los casos sin tools, probablemente no necesitas más autonomía para ese 90%.
Evita empezar por «responde tickets automáticamente». Es una mezcla de clasificación, conocimiento, identidad, tono, SLA y acción externa. Descompón esa frase en etapas; automatiza primero la que sea reversible y tenga un criterio de aceptación objetivo.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisContratos: el agente propone JSON; el workflow decide
Haz que el agente devuelva una decisión pequeña y validable, no párrafos que otro nodo tenga que interpretar. Un contrato útil incluye `category`, `priority`, `evidence`, `next_action` y `requires_approval`. Mantén los enums limitados y exige que la evidencia proceda del input o de una tool consultada; no conviertas una confianza inventada en una orden operativa.
Puntos a revisar
Lo que conviene comprobar
Ejemplo de contrato para un triage. En n8n puedes implementarlo con Structured Output Parser o con un nodo de validación posterior; lo importante es que la rama de escritura solo reciba objetos que pasen el schema.
<div style="margin:28px 0;border:1px solid #dbe3ef;border-radius:12px;overflow:hidden;background:#0f172a;"> <div style="padding:10px 14px;background:#111827;color:#cbd5e1;font:13px Consolas,monospace;">decision.schema.json</div> <pre style="margin:0;padding:18px;overflow:auto;color:#e5e7eb;font:13px/1.55 Consolas,monospace;"><code>{ "type": "object", "additionalProperties": false, "required": ["category", "priority", "evidence", "next_action", "requires_approval"], "properties": { "category": {"enum": ["bug", "access", "question", "incident"]}, "priority": {"enum": ["low", "normal", "high"]}, "evidence": {"type": "array", "items": {"type": "string"}, "maxItems": 3}, "next_action": {"enum": ["request_context", "draft_ticket", "escalate"]}, "requires_approval": {"type": "boolean"} } }</code></pre> </div>
Un schema no hace verdadera la respuesta; solo evita que un formato ambiguo avance. La regla es: validation failure significa detener, pedir más contexto o enviar a humano. Nunca significa adivinar campos que faltan y continuar con la escritura.
Checklist
Tools estrechas y credenciales con alcance mínimo
Una tool debe corresponder a una operación que puedas describir como una API segura. `buscar_runbook(servicio, consulta)` es mejor que «acceso a toda la wiki». `crear_borrador_ticket(titulo, cuerpo, prioridad)` es mejor que «administrar el proyecto». Menos parámetros, resultados limitados, límites de tamaño y un owner claro hacen que la tool sea más fácil de evaluar y revocar.
Usa credenciales separadas por entorno y workflow. Compartir un workflow puede permitir a sus editores usar las credenciales que contiene; por eso, antes de compartir, revisa quién necesita editarlo y qué identidad ejecuta cada nodo. Un canvas compartido no es una razón para usar una cuenta de administrador global.
Trata cualquier documento, email, issue o resultado de búsqueda que entre al contexto como datos no confiables. Puede contener instrucciones para el modelo. Filtra qué campos se exponen a la tool, separa los datos de las instrucciones de sistema y nunca dejes que texto recuperado cambie scopes, URLs sensibles o identificadores de tenant.
Checklist
Aprobación humana: dónde debe detenerse el flujo
La revisión humana es útil antes de una mutación, no después de descubrir una mutación. En n8n, una operación puede pausar y pedir aprobación; para procesos más complejos, usa una espera y una interfaz o canal de decisión que conserve el `execution_id`, actor, payload propuesto y fecha de expiración.
La aprobación debería mostrar lo que una persona necesita para responsabilizarse: acción propuesta, campos concretos, evidencia usada, destino, coste potencial y enlace a la ejecución. «El agente recomienda continuar» no es una solicitud de aprobación; es una transferencia opaca de responsabilidad.
Define políticas por impacto. Lectura de documentación pública puede seguir sin gate. Crear un borrador puede requerir revisión por muestreo. Enviar un correo, borrar, desplegar, cambiar permisos o tocar datos de cliente debe requerir aprobación explícita y registrar quién la otorgó. Si no puedes esperar, probablemente la acción no debería depender de un agente libre.
Mi criterio: introduce MCP después de validar una tool nativa o HTTP estrecha. Si no sabes qué tool del catálogo necesita el caso, no es momento de dar al agente decenas de opciones. La selección de capabilities también necesita un diseño de producto y de seguridad.
Evaluación antes de activar el workflow
n8n ofrece evaluaciones ligeras y métricas, pero tu dataset importa más que el botón. Crea al menos 30 casos con entradas normales, incompletas, ambiguas y hostiles. Para cada uno, guarda decisión esperada, tools permitidas, tool calls prohibidas, evidencia mínima y si el caso debe pedir aprobación.
Define gates antes de modificar prompt, modelo o herramientas: porcentaje de categoría correcta, tasa de JSON válido, evidencia verificable, llamadas indebidas, falsos positivos de escritura, tiempo y coste. No cambies modelo y prompt a la vez si quieres saber por qué apareció una regresión.
La evaluación de trayectorias es especialmente valiosa en agentes: la respuesta final puede parecer buena aunque haya consultado una fuente errónea, usado la herramienta equivocada o intentado escribir sin aprobación. Registra ruta y argumentos redactados, no solo el texto final.
Seguridad y operaciones que no dejaría para después
Ejecuta el security audit de n8n al incorporar un workflow sensible. Revisa credenciales sin uso, webhooks sin protección, nodos con acceso a filesystem o ejecución de comandos, community nodes y configuración de instancia. Es una señal de higiene, no la garantía de que un agente entiende tus permisos.
Puntos a revisar
Lo que conviene comprobar
Separa desarrollo, staging y producción. Prueba con identidades sandbox, datos sintéticos y destinos que no generen efectos reales. Mantén secretos en el gestor apropiado, redáctalos de logs y limita acceso al historial de ejecuciones: un prompt o respuesta puede incluir datos de cliente aunque la tool haya sido de solo lectura.
Cuando el workflow evolucione, versiona export, prompt, schema, modelo, lista de tools y credenciales lógicas. Cualquier cambio en una de estas piezas es una versión candidata que debe pasar el dataset y un canary, no un ajuste inocente en el canvas.
Checklist
Checklist para un primer agente n8n
- La tarea tiene un input, una salida y un owner definidos; no es «automatizar soporte».
- Una cadena determinista no resuelve el caso igual de bien y más barata.
- El agente recibe solo contexto necesario y devuelve un objeto que pasa schema.
- Cada tool tiene propósito, allowlist, límite de datos, identidad y scope mínimos.
- Las mutaciones se separan de la decisión y pasan por aprobación cuando el impacto lo exige.
- Los retries son idempotentes y la rama de error distingue causas recuperables de denegaciones.
- Existe un dataset con casos normales, ambiguos y hostiles, más gates de calidad, trayectoria, latencia y coste.
- Hay trazas y auditoría con IDs, decisiones, tool calls y aprobaciones, sin almacenar secretos por defecto.
- Staging y producción usan credenciales distintas; el workflow no necesita una cuenta admin global.
Checklist
Conclusión
n8n es una buena capa de orquestación cuando quieres que una decisión de IA toque integraciones reales de forma visible. Su virtud no es dibujar nodos: es darte lugares claros donde validar, pausar, reintentar y auditar. Úsalos.
Empieza con un triage de lectura, una tool y una salida estructurada. Añade aprobación antes de la primera escritura. Mide la trayectoria antes de celebrar la respuesta. Cuando esas tres cosas sean aburridas y repetibles, entonces tendrás base para automatizar más; antes, solo tendrás una demo con acceso a sistemas reales.
Preguntas frecuentes
¿Qué es un agente de IA en n8n?
Es un workflow donde un modelo puede decidir qué herramientas usar para una meta. A diferencia de una cadena fija, la ruta puede variar según la entrada, por lo que necesita más control y evaluación.
¿Cuándo conviene usar n8n Agent y cuándo una cadena?
Usa una cadena para extracción, clasificación, resumen y pasos definidos. Usa un agente cuando la selección de una tool o el orden de pasos dependa de la situación y puedas limitar y auditar esa decisión.
¿Puede un agente n8n enviar emails o modificar un CRM?
Técnicamente sí, pero no debería hacerlo sin una identidad mínima, una tool estrecha, validación de argumentos e idealmente aprobación humana para efectos externos o irreversibles.
¿Cómo pruebo un agente antes de producción?
Crea un dataset de casos normales, ambiguos y hostiles; mide decisión, formato, evidencia, tools llamadas, acciones indebidas, latencia y coste. Ejecuta un canary con credenciales y destinos sandbox.
¿MCP hace seguro un workflow de n8n?
No. MCP conecta capacidades; aún debes revisar servidor, autenticación, scopes, tools expuestas, datos y aprobaciones. Una tool remota con permisos amplios sigue siendo un riesgo amplio.
¿Necesito queue mode para un agente?
No para un piloto pequeño. Sí puede ser necesario cuando hay carga, trabajos asíncronos, aprobaciones largas o necesidad de separar la recepción de eventos del procesamiento por workers.
Cómo desplegar un primer agente de IA en n8n
- Acotar la misión. Elige una tarea reversible y de lectura, como clasificar y proponer el triage de una incidencia.
- Definir el contrato. Especifica campos de entrada, schema de decisión, evidencia requerida, herramientas permitidas y acciones prohibidas.
- Crear una tool mínima. Conecta una única fuente de conocimiento de solo lectura y limita datos, credencial y parámetros.
- Añadir validación. Rechaza salida que no pase schema o que no contenga evidencia suficiente; no inventes defaults para continuar.
- Separar escritura. Encierra crear ticket, enviar mensaje o cambiar registro en una rama posterior con clave idempotente.
- Configurar aprobación. Muestra acción, payload, destino, evidencia y ejecución a una persona antes de la primera mutación.
- Crear dataset. Incluye casos normales, ambiguos, incompletos y hostiles con decisión y trayectoria esperadas.
- Medir y canary. Compara calidad, tools, latencia, coste y aprobaciones en staging antes de abrir una parte pequeña de tráfico.
- Auditar y versionar. Guarda versión de workflow, prompt, schema, modelo y allowlist; redacta secretos de ejecuciones y trazas.
Fuentes y referencias
También te puede interesar
MCP en producción: seguridad, permisos y supply chainPrompt injection en agentes de IAEvaluación RAG en producciónOpenTelemetry GenAI para agentesOAuth 2.1 para servidores MCPRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
