Automatizar sin programar: n8n, Make y Zapier con IA dentro

Estas herramientas llevan casi una década haciendo lo mismo: cuando pasa algo en una aplicación, hacer que pase otra cosa en otra. Formulario nuevo, fila en la hoja de cálculo. Factura pagada, mensaje en el chat. Útil, aburrido y sin ninguna necesidad de inteligencia.

Lo que cambió al meterles un modelo de lenguaje dentro es la clase de tarea que alcanzan. Un flujo puede ahora automatizar trabajo que exige criterio —leer un correo y decidir de qué va, resumir una llamada, redactar una respuesta— y ahí es donde empieza a resultar valioso y a romperse de formas nuevas.

Esta guía es la capa de herramienta. La decisión previa —qué automatizar y qué no tocar— está en la guía sobre automatizar tareas con IA en el trabajo, y conviene tenerla resuelta antes de abrir ninguna de las tres: la causa más común de automatización inútil no es elegir mal la plataforma, es automatizar la tarea equivocada con la plataforma correcta.

Qué cambió cuando les metieron un modelo dentro

Antes, para que un flujo tomara una decisión, había que escribir la regla completa por adelantado: si el asunto contiene «factura», entonces…. Funciona hasta que alguien escribe «recibo», y en la práctica siempre alguien escribe «recibo».

Con un modelo en medio, el paso pasa a ser: lee este correo y dime si trata de facturación, de soporte o de ventas. Eso desbloquea tres categorías de trabajo que antes no eran automatizables, y de hecho es la vía más barata para montar un asistente de atención al cliente sin pasar por un desarrollo a medida:

• Clasificar por sentido en lugar de por palabras exactas.
• Extraer datos de texto desordenado: fechas, importes y nombres de un correo escrito por una persona con prisa.
• Redactar el primer borrador de algo que luego se revisa.

Y aparece un problema nuevo que hay que entender antes de montar nada. Un paso programado falla de forma limpia y un paso con modelo falla de forma plausible. Si una regla no encuentra el campo que buscaba, el flujo se detiene con un error y alguien se enteran. Si el modelo no encuentra el importe, es capaz de devolver un número razonable que se parece a un importe, y el resto del flujo lo acepta sin protestar. El error no se detiene: se propaga.

De esa asimetría sale casi todo el diseño sensato en esta materia.

Las tres opciones, sin empate

Traducido a recomendación, que es lo que casi nadie se atreve a dar:

Si no hay nadie técnico en el equipo, Make. Es el punto de equilibrio real: el lienzo visual hace que un proceso con condiciones se pueda leer de un vistazo seis meses después, cosa que la lista de pasos de Zapier no consigue, y el coste por operación no se dispara igual.

Si el objetivo es probar la idea hoy, Zapier. Su ventaja es que la integración que necesitas casi seguro existe. Como plataforma para quedarse es cara, pero para validar en una tarde si el flujo aporta algo, esa caridad es irrelevante.

Si hay volumen, datos que no deben salir o intención de construir agentes, n8n. Es la única de las tres que se puede ejecutar en tu propia infraestructura, lo que la convierte en la respuesta cuando el departamento legal ha bloqueado enviar datos de clientes a un tercero —el mismo razonamiento que hay detrás de la IA local—. Y es la que mejor soporta un agente al que le das varias herramientas y dejas decidir.

Cómo se paga cada una y por qué la factura sorprende

El error de cálculo es siempre el mismo: se factura por ejecuciones u operaciones, no por flujos. Dos automatizaciones aparentemente similares pueden diferenciarse en dos órdenes de magnitud según cómo se disparen.

Dos medidas bajan la factura sin quitar funcionalidad. La primera: filtrar lo antes posible. Si el flujo solo actúa sobre el 5 % de los correos, el filtro tiene que ser el primer paso y no el tercero, porque lo que se paga son los pasos ejecutados. La segunda: agrupar en lote lo que no es urgente. Un proceso que revisa todo a las siete de la mañana cuesta una ejecución diaria en lugar de doce mil.

Y aparte va el coste del modelo, que se factura por tokens y suele ser el menor de los dos hasta que alguien decide pasarle el documento entero al modelo en cada ejecución. Como orden de magnitud: clasificar un correo son céntimos de céntimo; resumir un PDF de cien páginas cuatro mil veces al mes, no.

El primer flujo que conviene montar

No el más útil: el que más enseña con menos riesgo. Tiene que cumplir cuatro condiciones —volumen alto, criterio escribible, error visible al momento y ninguna salida al exterior—.

El que casi siempre cumple las cuatro es clasificar y enrutar entrada. La forma canónica:

1. DISPARADOR   Llega un correo a soporte@ / un formulario nuevo
2. FILTRO       Descartar notificaciones automáticas y copias
3. MODELO       Clasificar en: facturación | incidencia | comercial | otro
                Extraer: cliente, urgencia (alta/media/baja), resumen en 1 frase
4. VALIDACIÓN   ¿La categoría es una de las cuatro? ¿La urgencia, una de las tres?
                Si no → etiquetar "revisar a mano" y parar
5. ACCIÓN       Etiquetar, asignar responsable y anotar en la hoja de registro
6. AVISO        Solo si urgencia = alta, mensaje al canal del equipo

El paso 4 es el que separa un flujo que aguanta de uno que hay que desmontar en un mes, y es el que casi nadie pone. Sin validación, el día que el modelo devuelva «facturación urgente» en lugar de una de las cuatro categorías, el flujo escribirá esa cadena en el campo y ninguna vista lo mostrará bien.

El prompt del paso 3, escrito para ser validable:

Clasifica este mensaje. Responde SOLO con un objeto JSON con
exactamente estas cuatro claves y ningún texto adicional:

{
  "categoria": una de ["facturacion","incidencia","comercial","otro"],
  "urgencia": una de ["alta","media","baja"],
  "cliente": nombre si aparece, o null,
  "resumen": una frase de menos de 20 palabras
}

Si dudas entre dos categorías, usa "otro".
No inventes el nombre del cliente: si no aparece, pon null.

MENSAJE:
[...]

Las tres últimas instrucciones son las que se ganan a base de disgustos. Cerrar el conjunto de valores permite validar. Dar una salida explícita para la duda evita que el modelo fuerce una categoría. Y prohibir expresamente inventar el cliente es necesario porque, si no se prohíbe, lo deduce del dominio del correo con una seguridad admirable.

Flujo fijo o agente: cuándo dejar decidir al modelo

Todas las plataformas ofrecen ya la variante «agente»: en lugar de encadenar pasos, le das al modelo un objetivo y un conjunto de herramientas y decide él la secuencia. Suena mejor y casi nunca es lo que conviene.

La regla que evita casi todos los problemas: si eres capaz de dibujar el proceso, no uses un agente. Un agente se justifica cuando dibujarlo exigiría cincuenta ramas, y a cambio aceptas que dos ejecuciones idénticas no garantizan el mismo resultado. Lo que hay detrás del concepto está desarrollado en la guía sobre qué es un agente de IA.

Y una precaución que no es opcional cuando se le dan herramientas a un modelo: las herramientas que se le entregan deben ser de solo lectura o de efecto reversible. Un agente con permiso para enviar correos, borrar registros o mover dinero es una decisión que hay que tomar despierto, no un ajuste que se activa por probar.

Los cinco errores que rompen flujos en producción

1. No validar la salida del modelo. El error madre, del que salen la mitad de los demás. Todo lo que devuelva el modelo se comprueba antes de usarse.
2. Automatizar el envío al exterior el primer día. Un flujo que responde solo a clientes es un flujo que se disculpa solo ante clientes. Fase uno: el flujo prepara el borrador. Fase dos, cuando lleve semanas acertando: se plantea el envío.
3. Ignorar el reintento. Cuando una API falla, la plataforma reintenta, y si el paso no es idempotente se duplica la factura, el ticket o el mensaje. Hay que preguntarse qué pasa si el flujo se ejecuta dos veces con la misma entrada.
4. No dejar registro. Un flujo sin bitácora de qué hizo y con qué datos es imposible de auditar y de deshacer. Una hoja con fecha, entrada, decisión y resultado basta, y es lo primero que se agradece.
5. Dejar el flujo sin dueño. Los flujos se rompen solos cuando la aplicación del otro lado cambia su API o alguien renombra una columna. Sin nadie que vigile, el flujo falla en silencio durante semanas.

El cuarto y el quinto son los que convierten una automatización en deuda. Y el silencio es la parte grave: hay que montar la alerta de fallo antes que el propio flujo, porque una automatización caída sin avisar es peor que no tenerla —el trabajo ha dejado de hacerse y todo el mundo cree que se hace—.

Quién es el dueño del flujo

Estas herramientas son tan accesibles que la primera automatización de una empresa casi nunca la monta el departamento de sistemas. La monta alguien de operaciones un jueves por la tarde, con su cuenta personal y sus credenciales.

Eso produce una forma nueva de shadow IT con dos consecuencias concretas. La primera: cuando esa persona se va, el flujo sigue ejecutándose con sus accesos hasta que se desactivan, y entonces deja de funcionar sin que nadie sepa qué era. La segunda: un flujo que lee correos de clientes y los manda a un modelo es un tratamiento de datos personales que no está en ningún registro de actividades.

Tres medidas que cuestan una tarde y evitan los dos problemas:

• Cuentas de la empresa, no personales, para la plataforma y para las conexiones.
• Una fila por flujo en el inventario de sistemas de IA: qué hace, qué datos toca, quién es el responsable. Es el mismo inventario que pide la guía del AI Act, y los flujos son justo lo que nunca aparece en él.
• Una revisión trimestral: qué flujos están activos, cuáles no ha mirado nadie y cuáles se pueden apagar.

Cuándo esto ya no basta

Hay un punto en el que insistir sin código cuesta más que escribirlo. Las señales son reconocibles:

• El flujo tiene más de veinte pasos y nadie entiende ya la rama de la derecha.
• Hay módulos de código dentro del flujo. Si ya estás programando, estás programando en el peor editor posible.
• La factura de operaciones supera lo que costaría un servidor pequeño.
• Necesitas probar los cambios antes de publicarlos, y en el flujo no hay forma de hacerlo sin tocar producción.

Que el flujo llegue a ese punto no es un fracaso, es información: ha demostrado que el proceso merece código. Reescribirlo con la lógica ya validada es un trabajo pequeño y de riesgo bajo, y muchísimo más barato que haberlo programado el primer día sin saber si servía para algo.

Que es, al final, el argumento entero a favor de estas herramientas. No son la forma más elegante de automatizar nada: son la forma más barata de averiguar si merece la pena automatizarlo. Usadas así —para descubrir, con la disposición a tirarlas cuando el proceso madure— es difícil que salgan mal. Usadas como infraestructura definitiva sobre la que se apoya el negocio, acaban siendo un sistema crítico que nadie sabe mantener y que se factura por ejecución.