Cómo automatizar tareas con n8n y un LLM: guía práctica 2026

La mayoría de guías de automatización con IA enseñan a conectar dos nodos y celebrar que funciona. Luego lo montas en serio, lo dejas corriendo una semana y descubres lo que nadie contó: que el flujo se cae en silencio, que el modelo decidió algo que no debía, o que ese “asistente autónomo” lleva tres días haciendo llamadas a la API sin que nadie mire el resultado.

Esta guía va de lo segundo. El patrón que aguanta en producción, un caso real montado de principio a fin, y los tres errores que cuestan más tiempo del que ahorra la automatización.

Por qué n8n y no una hoja de cálculo con macros

n8n es un orquestador de flujos: defines un disparador, encadenas pasos y cada paso recibe lo que produjo el anterior. Lo que lo diferencia de las alternativas de pago es que puedes alojarlo tú mismo, lo que importa por dos motivos muy concretos.

El primero es el coste. Las plataformas que cobran por operación se vuelven caras justo cuando la automatización empieza a ser útil: al principio son cientos de ejecuciones al mes y al cabo de un trimestre son decenas de miles. El segundo, y más importante en España, es que si el flujo trata datos personales —correos de clientes, formularios, historiales— alojarlo tú significa que esos datos no salen de tu servidor salvo cuando tú decides que salgan.

Eso no convierte a n8n en la respuesta correcta siempre. Si tu automatización son tres pasos sin lógica, un script de veinte líneas y una tarea programada hacen lo mismo con menos piezas que mantener. La regla que uso: n8n cuando hay varios sistemas que hablarse entre sí; un script cuando es un problema de estado y comparación.

El patrón que aguanta: cinco etapas, siempre en el mismo orden

Después de montar unos cuantos flujos con modelos de lenguaje dentro, todos los que sobreviven tienen la misma forma:

El patrón que aguanta en producción

Fig. 01

1. 1

   Etapa 1: Disparador

   Horario mejor que webhook

2. 2

   Etapa 2: Normalización

   Recortar antes del modelo

   Aquí se decide lo que cuesta

3. 3

   Etapa 3: El modelo

   Una sola tarea acotada

4. 4

   Etapa 4: La acción

   Separada de la decisión

   El modelo propone, el flujo ejecuta

5. 5

   Etapa 5: El registro

   Qué entró, qué salió, cuánto

El orden importa: saltarse la etapa 2 multiplica el coste del modelo sin mejorar el resultado.

Datos propios

→

1. Disparador. Un horario, un webhook o un cambio detectado. Prefiere horarios a webhooks cuando puedas: un webhook abierto es una puerta a internet, y eso trae consecuencias que veremos más abajo.

2. Normalización antes del modelo. Aquí está la parte que casi nadie hace y que separa un flujo estable de uno que quema dinero. Antes de mandar nada al LLM, recorta. Si vas a analizar una página web, quítale la navegación, el pie y los scripts. Si vas a comparar dos versiones de un texto, manda solo lo que cambió, no los dos textos enteros.

Esto no es optimización prematura. El coste de un LLM es proporcional al texto que le mandas, y el ruido no solo se paga: empeora el resultado. Un modelo al que le entregas una página entera dedica atención a cosas irrelevantes. Uno al que le entregas el párrafo que cambió responde mejor y cuesta una fracción.

3. El modelo, con una tarea acotada. Un paso, una pregunta. “Resume esto en tres puntos” funciona. “Analiza esto, decide si es importante, redacta un correo y envíalo” es cuatro tareas disfrazadas de una, y cuando falle no sabrás cuál de las cuatro falló.

Para elegir modelo, el criterio práctico es el tamaño de lo que le mandas y cuánto te duele que se equivoque. Lo desarrollé en la comparativa de Claude y ChatGPT para empresas, pero el resumen es: para clasificar y resumir en volumen, el modelo más barato de la familia sobra; para análisis donde un error se propaga, compensa pagar el bueno.

4. La acción, separada de la decisión. El modelo propone; el flujo ejecuta. Nunca al revés. Volveré sobre esto porque es el error caro.

5. El registro. Cada ejecución deja rastro de qué entró, qué salió y cuánto costó. Sin esto no puedes depurar nada, y descubrirás que llevas semanas pagando por ejecuciones que no servían para nada.

Un caso completo: vigilar fuentes que caducan

Este sitio tiene un problema que cualquiera que publique contenido técnico reconoce: los artículos caducan. Escribes sobre precios de una API en junio y en septiembre el dato es falso. Revisarlo a mano no escala, y actualizar por actualizar tampoco: Google detecta la frescura simulada y no premia cambiar una fecha.

El flujo que resuelve esto hace exactamente lo siguiente:

1. Se dispara dos veces al día a una hora fija.
2. Descarga una lista de páginas vigiladas: documentación de precios, blogs oficiales, boletines de organismos reguladores.
3. Normaliza el HTML a texto plano y elimina el ruido que cambia solo en cada carga: identificadores de caché, marcas de tiempo, hash de recursos. Sin este paso, saltaría una alerta cada día aunque no hubiera cambiado nada.
4. Compara con la última copia guardada.
5. Cuando algo cambió de verdad, el modelo decide si ese cambio afecta a alguno de los artículos publicados.
6. Escribe una propuesta en un fichero: qué cambió, en qué artículos influye y qué habría que revisar.

Y aquí está la decisión que hace que el sistema sea utilizable: la propuesta no toca el artículo. Nadie edita nada automáticamente. El fichero que genera dice, literalmente, que si un cambio no aporta nada al texto hay que ignorarlo.

Podría haberlo montado para que reescribiera los artículos solo. Habría sido más impresionante en una demo y habría destruido el sitio en dos meses: publicar modificaciones sin criterio editorial es justo lo que Google sanciona como contenido generado a escala. Ese razonamiento está desarrollado en la comparativa de herramientas de IA para escribir, y vale para cualquier automatización que toque contenido publicado.

Un detalle de la comparación que costó dos intentos acertar: para los precios no sirve un umbral de magnitud. Un cambio relevante puede ser un carácter —de $3 a $5— y cualquier filtro razonable de “avísame si cambió más de X” se lo come. Los importes hay que extraerlos y compararlos como lista aparte del texto.

Los tres que vienen son de infraestructura. Los de diseño del propio agente —objetivos sin criterio de terminación, bucles sin techo, medir lo que hace en vez de lo que resuelve— los reuní aparte en los errores que se cometen al montar el primer agente de IA.

Los tres errores que cuestan tiempo de verdad

1. Exponer el orquestador entero para publicar un webhook

Es el error más fácil de cometer y el que peor se paga. Necesitas que un formulario llegue a tu flujo, montas un túnel rápido apuntando al servicio y listo: funciona en treinta segundos.

Lo que acabas de publicar en internet no es tu webhook. Es el editor completo, la API interna y todos los flujos con sus credenciales dentro. Cualquiera con la URL entra. Y si el túnel genera una dirección aleatoria nueva en cada reinicio, además tienes un integración que se rompe sola cada vez que el servicio se reinicia.

Lo correcto cuesta una tarde: un túnel con nombre, DNS fijo y una regla que publique solo la ruta del webhook, dejando el editor accesible únicamente desde la red local o una VPN.

2. Dejar que el modelo ejecute acciones irreversibles

Un LLM que puede enviar correos enviará un correo raro. No es una posibilidad remota: es cuestión de volumen. Con suficientes ejecuciones, el caso extraño llega.

La regla es simple y no tiene excepciones que merezcan la pena: el modelo genera contenido, el flujo decide si se ejecuta. Para acciones reversibles —escribir un borrador, crear una tarea, etiquetar algo— puedes automatizar del todo. Para las que no se deshacen —enviar, publicar, borrar, pagar— hace falta una persona en medio. Si eso te parece que rompe la automatización, mira cuántos segundos son realmente: aprobar doce propuestas es un minuto al día.

3. No versionar los flujos

n8n guarda los flujos en su base de datos, y ahí no hay historial útil. El día que alguien toca un nodo y el flujo deja de funcionar, no hay diff que mirar ni versión anterior a la que volver.

La solución es exportar los flujos a JSON y meterlos en el mismo repositorio que el resto del proyecto. Cuesta poco y el día que lo necesitas, lo necesitas mucho. Si además guardas una copia antes de cada cambio importante, puedes comparar exactamente qué se tocó.

Cuánto cuesta esto al mes

Si todavía no tienes dónde alojarlo, los números reales de memoria por servicio y qué VPS hace falta de verdad están medidos en la guía de self-hosting de herramientas de IA.

Con el servicio alojado en un VPS modesto, el coste de la infraestructura es el del propio VPS, que se comparte con todo lo demás que tengas corriendo. La parte variable es el modelo, y depende casi por completo del paso 2: cuánto texto le mandas.

Un flujo que vigila una docena de fuentes dos veces al día, mandando solo los fragmentos que cambiaron, se mueve en céntimos al mes. Ese mismo flujo mandando las páginas enteras cada vez se pone en decenas de euros sin dar mejor resultado. La diferencia no está en el modelo que elijas: está en lo que le entregas.

Por dónde empezar

No empieces por el flujo que más ilusión te hace. Empieza por una tarea que hagas a mano, que sea repetitiva y cuyo resultado puedas comprobar de un vistazo. Móntala siguiendo las cinco etapas, déjala corriendo una semana y mira el registro.

Si al cabo de esa semana el registro te dice que el flujo hizo lo que esperabas, añade el siguiente paso. Si te dice que falló tres veces y no te enteraste, arregla eso antes de añadir nada. La automatización que no sabes si funciona no es automatización: es una fuente de errores que todavía no has descubierto.

Puedes probar n8n en su versión alojada o autoalojada — la segunda es gratuita y es la que uso para todo lo descrito aquí.