Automatización de procesos con IA que dura

La automatización de procesos con IA es fácil de demostrar y difícil de mantener viva. La demo se hace en una tarde. La versión que sigue funcionando en el mes cuatro tiene rutas de error, un responsable con nombre y un manual, y hace algo lo bastante estrecho como para que nadie discuta si funcionó.

Todo lo que viene es el diseño que uso con clientes, en el orden en que lo uso.

Qué es exactamente la automatización de procesos con IA#

Un flujo es una secuencia de pasos disparada por un evento. La automatización clásica ejecuta esa secuencia contra reglas fijas: cuando llega un formulario, crea una ficha y avisa a un canal. La automatización de procesos con IA es la misma secuencia con uno o más pasos donde la siguiente acción depende de criterio en vez de de una regla.

Esa es toda la diferencia, y tenerla clara es lo que mantiene los costes bajos. Una llamada a un modelo es más lenta y más cara que una escritura en base de datos, y puede equivocarse de formas en que una escritura no puede. Así que la gastas solo donde una regla genuinamente no puede decidir.

Los equipos que difuminan la definición acaban pidiéndole a un modelo que haga aritmética y enrutado, y luego se preguntan por qué la factura es grande y los resultados varían entre ejecuciones.

Elige el proceso antes que la herramienta#

Puntúa cada candidato con tres cosas.

Frecuencia. ¿Cuántas veces a la semana ocurre? Por debajo de cinco, el retorno rara vez justifica el mantenimiento.

Criterio. ¿Cuánto requiere una decisión que solo una persona puede tomar? El criterio alto no bloquea nada, solo te dice dónde va el modelo y dónde va un paso de aprobación humana.

Documentación. ¿Está escrito en pasos numerados? Si no, escríbelo primero. Automatizar un proceso sin documentar codifica lo que improvisó la última persona.

Coge el que más puntúe. Uno. Los equipos que empiezan con cinco no terminan ninguno bien.

Dónde va el modelo y dónde no#

El error de diseño más común es poner un modelo al mando del flujo entero.

Usa pasos deterministas para todo lo que tenga regla: enrutar por valor de campo, formatear, programar, escribir en base de datos. Son más rápidos, más baratos, auditables y nunca inventan.

Usa el modelo solo en los pasos que necesitan criterio:

• Clasificar texto libre en tus categorías
• Extraer campos estructurados de documentos desordenados
• Resumir con referencias
• Redactar algo que una persona va a aprobar
• Decidir qué rama aplica cuando la regla es genuinamente difusa

Un buen flujo con IA es sobre todo fontanería con dos o tres articulaciones inteligentes. Si el tuyo es un único prompt haciéndolo todo, será caro e impredecible a partes iguales.

Las partes que todo el mundo se salta#

Reintentos con espera. Las APIs devuelven 429 y 503 rutinariamente. Sin reintentos tu flujo falla un martes sin motivo que nadie pueda reconstruir.

Una ruta alternativa. ¿Qué pasa cuando el modelo devuelve algo inservible? A una cola humana. Nunca dejes que un flujo continúe en silencio con basura.

Una alerta de fallo. Un canal, todos los fallos, con el nombre del flujo y el paso. Una automatización rota que nadie ve es peor que ninguna, porque la gente ya dejó de hacerlo a mano.

Un paso de verificación para todo lo que sale fuera. Correos, contenido publicado, mensajes a clientes. Aprueba una persona, siempre.

Idempotencia. Si se ejecuta dos veces, ¿se duplica algo? Compruébalo ahora, no después de la primera doble facturación.

El stack que uso#

n8n como capa de flujos, autoalojado cuando el dato no puede salir del edificio. Gestiona ramas, reintentos y programación, y una persona no técnica puede leer el lienzo.

Claude para los pasos de criterio, con el prompt guardado en control de versiones y no pegado en un nodo que nadie encuentra.

MCP cuando el modelo necesita alcanzar tus propios sistemas de forma controlada.

Si aún estás eligiendo, Zapier vs n8n y Make vs n8n cubren las tres opciones principales.

La propiedad, que es lo que mata estos proyectos#

Cada flujo necesita un nombre detrás. No un equipo, una persona. Esa persona sabe qué hace, qué se rompe y dónde está el manual.

El manual es una página: qué hace el flujo en una frase, qué lo dispara, qué credenciales usa, los tres fallos más probables y a quién escalar. Se escribe mientras construyes, porque después no lo escribe nadie.

He visto morir más sistemas de automatización por propiedad difusa que por límites de herramienta. La tecnología estaba bien; la persona que lo montó cambió de trabajo y nadie sabía para qué era la mitad de los lienzos.

Qué cuesta esto#

Herramientas: un servidor de automatización y créditos de modelo, normalmente por debajo de cien euros al mes para los primeros flujos de un equipo pequeño.

Montaje: días, no meses, para un flujo bien acotado.

Mantenimiento: unas horas al mes, para siempre. Este es el coste que la gente deja fuera del caso de negocio y luego descubre como sorpresa.

Si el proceso que vas a automatizar no ahorra bastante más que eso, no lo automatices. Escríbelo y sigue adelante.

Un formato de cuatro semanas#

Semana 1. Mapea el proceso, cronometra cada paso, escribe la versión numerada.

Semanas 2 y 3. Constrúyelo, incluidas las rutas de error y la alerta desde el día uno.

Semana 4. Ejecútalo junto al proceso manual, compara salidas y no capturas de pantalla, y entrégalo con el manual y el responsable nombrado.

Mide lo que te propusiste cambiar: horas recuperadas, tiempo de respuesta o tasa de error. Si no puedes nombrar el número antes de construir, estás construyendo una demo.

La versión corta#

Un proceso documentado. Fontanería determinista con unas pocas articulaciones inteligentes. Rutas de error y alerta en la versión uno. Un responsable con nombre y un manual de una página. Y entonces, solo entonces, el segundo flujo.

Si quieres el primer sistema montado en tus cuentas con tu equipo formado para extenderlo, es lo que cubren mis formaciones de IA para empresas, y en la agencia de inteligencia artificial es donde hago este trabajo para clientes.