Automatización
Por qué se rompen las automatizaciones que montaste con IA
Funcionó tres semanas y ahora nadie se fía de ella. No es mala suerte ni es que te faltara un plugin: es que la parte fácil de una automatización es construirla, y esa es justo la que la IA te regaló.
¿Por qué deja de funcionar algo que funcionaba?
Porque se construyó el camino bueno y nada más. El flujo funciona con el ejemplo con el que lo probaste, y el mundo real trae casos que ese ejemplo no tenía: la factura con un abono, el cliente que escribe en mayúsculas, el proveedor que cambió el formato del correo, el modelo de IA que se retiró. Ninguna de esas cosas se ve el primer día. Todas aparecen entre el mes uno y el mes seis.
Esto no es un problema de la IA. Es un problema de que construir era el 30 % del trabajo y te lo dieron gratis, así que parecía que estaba todo hecho.
¿No era verdad que la IA ya monta esto sin saber programar?
Sí lo es, y ahí está la trampa. La IA monta la demo de verdad: en un fin de semana tienes un flujo en n8n que lee un correo, saca los datos con un modelo y los mete en una hoja. Eso hace cinco años costaba un mes y hoy cuesta un sábado. No lo discuto: yo también los monto así.
Lo que no ha bajado es lo que cuesta que eso siga funcionando sin que nadie lo mire durante un año.
Hay medición sobre esto, y va en contra de la intuición de todo el mundo. METR hizo un ensayo aleatorizado con 16 desarrolladores expertos sobre 246 tareas reales en repositorios maduros. Los participantes predijeron que la IA les haría ir un 24 % más rápido. Midiendo, tardaron un 19 % más. Y lo llamativo: después de terminar, seguían creyendo que habían ido un 20 % más rápidos.
Los propios autores advierten de que el resultado no se generaliza a cualquier desarrollador ni a cualquier tarea, y tienen razón. Pero el patrón que describe sí lo he visto en todos los rescates que he hecho: la sensación de velocidad es real y la velocidad no. Sobre un sistema que ya existe, con casos raros y reglas que no están escritas, la ayuda se evapora.
¿De verdad el código generado tiene agujeros?
Sí, y hay cifra. Veracode probó más de 100 modelos de lenguaje en su informe de 2025 y encontró que el 45 % de las muestras de código generado falló las pruebas de seguridad, introduciendo vulnerabilidades del OWASP Top 10. En Java la tasa de fallo subió al 72 %.
Esto importa más de lo que parece en una automatización de pyme, porque el código que genera una IA para conectar sistemas es exactamente el que toca las claves, la base de datos y los datos de tus clientes. No es el código de una web bonita: es el que tiene las llaves.
El fallo típico que me encuentro no es sofisticado. Son claves escritas dentro del propio flujo, un endpoint sin autenticar que cualquiera puede llamar desde internet, o un registro que guarda las conversaciones enteras con los datos personales dentro y sin plazo de borrado.
Las seis formas en que se rompe, por orden de frecuencia
- El caso raro que no era raro. Se probó con tres facturas y llegan de doce proveedores distintos. El fallo no es que se caiga: es que acierta mal en silencio y nadie lo detecta hasta que un cliente reclama.
- Algo cambió por debajo. El modelo de IA se retiró, WhatsApp revisó sus tarifas, tu programa de gestión se actualizó y movió un campo. Un sistema sin vigilancia no avisa: deja de funcionar un martes.
- La credencial caducó. Un token con vencimiento a un año, puesto por alguien que ya no está. Es el fallo más tonto y el que más veces he visto.
- Nadie sabe qué hace. Sin documentación, sin registro de ejecuciones y sin la persona que lo montó, arreglarlo empieza por averiguar qué hacía. Esa arqueología es la mitad de la factura de un rescate.
- Se ejecutó dos veces. Un reintento sin control de duplicados y de pronto hay pedidos duplicados, correos duplicados, apuntes duplicados. Diseñar para que ejecutar dos veces sea inofensivo es una decisión que se toma al principio o no se toma.
- Creció. Funcionaba con 50 registros al día y ahora entran 5.000. Lo que era una espera de dos segundos es una cola que no se vacía nunca.
¿Cuándo se nota?
Hay un calendario bastante repetido:
| Cuándo | Qué pasa |
|---|---|
| Semana 1 | Todo el mundo contento. La demo funciona y la sensación es de haber ahorrado una fortuna |
| Semanas 2–4 | Aparecen los primeros casos raros. Se apañan a mano y nadie lo apunta |
| Mes 2–3 | El apaño a mano ya es parte del proceso. El ahorro real es la mitad del prometido |
| Mes 4–6 | Algo cambia por debajo y se rompe entero. Aquí llega la mayoría de las llamadas |
| Mes 12+ | Nadie se fía, se usa a medias, y arreglarlo cuesta más que rehacerlo |
Por eso digo que mirado en el mes cuatro suele ser una puesta a punto, y dejado hasta el mes catorce lo normal es reconstruirlo. No es una frase comercial: es que en el mes catorce el flujo ya está lleno de parches, la gente ha inventado procedimientos manuales paralelos, y esos procedimientos son ahora el proceso real de la empresa.
¿Arreglar o rehacer?
Se decide con tres preguntas, y ninguna es técnica:
- ¿Alguien sabe qué hace, hoy? Si hay documentación o la persona que lo montó sigue disponible, arreglar sale a cuenta.
- ¿Los datos que produjo son fiables? Si ha estado metiendo datos mal durante meses, el problema ya no es el flujo: es limpiar lo que hay detrás, y eso se hace igual en los dos escenarios.
- ¿Sigue siendo el proceso correcto? A veces la automatización está bien construida y automatiza algo que la empresa ya no hace así. Ahí no hay nada que arreglar.
Mi sesgo, dicho en voz alta: prefiero arreglar. Rehacer es más cómodo para mí, se factura más y se explica mejor. Por eso me obligo a justificar por escrito cuándo recomiendo tirar algo, con los problemas concretos delante.
¿Cuánto cuesta arreglarlo?
Una auditoría de una o dos semanas cuesta 1.900 € + IVA y sale con una lista priorizada de entre 8 y 14 problemas concretos, una revisión de seguridad y un presupuesto cerrado para la reparación. El presupuesto de la reparación no se da antes de auditar, y quien te lo dé por teléfono se lo está inventando.
Lo que casi nadie te dice: una parte de esos 8 a 14 problemas los puedes arreglar tú. La lista viene ordenada por lo que te cuestan, no por lo difíciles que son, y las tres o cuatro primeras suelen ser configuración, no desarrollo.
Cómo se monta algo que no se rompe
Seis cosas. Ninguna es cara si se hace desde el principio, y todas son caras si se añaden después:
- Registro de ejecuciones. Qué se ejecutó, cuándo, con qué entrada y qué salió. Sin esto no hay diagnóstico posible, solo conjeturas.
- Alerta cuando falla. A una persona concreta, con nombre. «Ya lo veremos en el panel» significa que se verá dentro de tres semanas.
- Bandeja de excepciones. Lo que el sistema no sabe resolver va a una cola para que un humano decida, no se descarta ni se inventa. En extracción de documentos, esa bandeja es el producto.
- Ejecutar dos veces tiene que ser inofensivo. Con una clave por operación. Es media hora al principio y un desastre después.
- Las claves fuera del código, con permisos mínimos y fecha de caducidad apuntada en un calendario que alguien mire.
- Un manual de operación de una página. Qué hace, qué se rompe, cómo te enteras, a quién se llama. Si no cabe en una página, el sistema es demasiado complicado para lo que hace.
Lo que sí deberías montar tú mismo
No todo necesita a alguien como yo, y decirlo me cuesta trabajo pero es cierto. Móntate tú, con la IA que uses, todo lo que cumpla estas tres condiciones a la vez:
- Si falla, lo notas el mismo día. Un resumen diario, una alerta a tu correo, un informe.
- Nadie de fuera depende de ello. Si se cae, tus clientes no se enteran.
- No toca dinero ni datos personales de terceros.
Ahí la IA es una herramienta magnífica y contratar a alguien es tirar el dinero. Lo que no aguanta ese trato es lo que factura, lo que habla con tus clientes o lo que mueve datos entre sistemas.
Lo que yo haría en tu lugar
Si tienes algo montado que va a medias, no lo tires ni lo dejes. Escribe primero qué debería hacer —en cinco líneas, sin tecnicismos— y compáralo con lo que hace. La mitad de las veces, ese ejercicio de veinte minutos revela que el problema no es el flujo, es que nunca se acordó qué tenía que pasar con el caso raro.
Si después de eso sigue sin cuadrar, eso es un rescate: auditoría primero, presupuesto después, y la auditoría se descuenta si acabamos rehaciéndolo. Y si resulta que lo que tienes está bien y solo le falta vigilancia, te lo digo y te cobro por la auditoría, no por un proyecto que no necesitas.
Fuentes
Todo lo que se afirma arriba con una cifra o una fecha sale de aquí. Si alguna de estas páginas cambia y esta nota no, escríbeme y la corrijo.
¿Tienes este problema ahora mismo?
Cuéntame en dos líneas a qué os dedicáis y qué proceso os come más horas. Te digo en la llamada si hay algo que hacer, o si la respuesta honesta es esperar.
Se abre WhatsApp con el mensaje ya escrito. Lo lees, lo cambias y lo envías. Lo leo yo, no un bot — el día que conteste un bot, te lo diré. Respondo en menos de 4 horas laborables.