Por qué una automatización se rompe (montar no es lo mismo que mantener)
Una automatización con IA no es un mueble: no la montas, la enchufas y te olvidas. Es un motor. Y un motor que trabaja todos los días se desgasta, pide aceite y algún día se para si nadie lo mira. La promesa de "lo dejamos funcionando y ya no tocas nada" suena bien en la reunión de venta. En producción, es la primera mentira que se cae.
El detalle importante es cómo se rompe. Casi nunca con un estruendo. Una automatización no suele caerse entera de golpe —eso al menos se ve—: se degrada en silencio. Sigue funcionando, pero un poco peor cada semana, hasta que un día alguien revisa y descubre que lleva un mes clasificando mal, contestando fuera de tono o saltándose casos. Para entonces el daño ya está hecho. Mantener es justo lo contrario: mirar antes de que alguien se queje.
Esto no es un fallo de tu automatización concreta, es cómo funcionan todas. De hecho, no meter el mantenimiento en la ecuación es una de las razones por las que fracasan los proyectos de automatización con IA: se celebra el arranque, nadie asume el cuidado, y seis meses después el sistema es un zombi que nadie se atreve a apagar ni a arreglar. Si quieres el mapa amplio de todo esto, está en la guía de automatizar con IA; esto es el zoom a la parte que empieza el día después de entregar.
Las tres cosas que se caen: el modelo cambia, la integración se rompe, aparece el caso raro
Una automatización con IA vive apoyada en tres patas, y las tres se mueven con el tiempo. Saber cuáles son es saber qué vigilar.
Uno: el modelo cambia. El proveedor actualiza la versión, ajusta el comportamiento, deprecia la que usabas. No te avisa a la cara: un día el mismo prompt devuelve una respuesta con otro tono, otro formato o menos precisión. El sistema no se para —ese es el problema—, solo empieza a decidir un poco peor. Es la rotura más traicionera porque no salta ninguna alarma sola, y por eso sobrevivir a un cambio de versión del modelo sin romper tus automatizaciones se prepara antes, no el día que pasa.
Dos: la integración se rompe. Tu CRM cambia un campo, una API actualiza su formato, un permiso o un token caduca, alguien toca un export. Esto sí se ve rápido: el flujo se para en seco. Es la rotura dura, la que da la cara. Y es la razón por la que integrar la IA con tus sistemas no es un trabajo de una vez: cada sistema al que te enganchas es una pieza que puede moverse por su cuenta.
Tres: aparece el caso raro del mes 3. Al principio la automatización ve los casos normales, para los que se diseñó. Pero el mundo real tiene cola larga: el pedido con la condición extraña, el email en un idioma que no esperabas, el cliente que rellena el formulario al revés. Ese caso no existía cuando montaste; aparece semanas después y rompe un flujo que parecía sólido. Ninguna automatización nace cubriendo el 100% de la realidad; la va cubriendo a medida que la realidad se la enseña.
| Qué se cae | Cómo se manifiesta | Cómo se detecta |
|---|---|---|
| El modelo cambia | Sigue respondiendo, pero peor: otro tono, otro formato, menos acierto | Revisión de logs y muestras; no salta solo |
| La integración se rompe | El flujo se para en seco | Alertas de error; se ve el mismo día |
| Aparece el caso raro | Un tipo de entrada nuevo atasca o desvía el flujo | Cola de excepciones y revisión de lo que escaló |
Qué es el mantenimiento de una automatización (cuidas un motor, no cuelgas un cuadro)
Mantener no es "estar por si acaso". Es un trabajo concreto con tareas concretas. Cuidas el motor: revisas cómo decide, ajustas lo que se desvía, tapas los agujeros que enseña el uso real. No cuelgas un cuadro y lo miras de lejos.
En la práctica, el mantenimiento de una automatización con IA son cuatro cosas:
- Supervisar las decisiones. Mirar en los logs qué está decidiendo el sistema y compararlo con lo que decidiría una persona. Donde acierta, sigue; donde falla, se corrige.
- Iterar los prompts y las reglas. Ajustar las instrucciones cuando el modelo cambia o cuando aparece un patrón nuevo. No es reprogramar: es afinar.
- Arreglar los casos límite. Recoger las excepciones que escalaron, entender por qué, y decidir si se cubren o se siguen mandando a un humano. Aquí es donde vive la frontera de humano en el bucle, que no es fija: se mueve con lo que enseñan los datos.
- Vigilar las integraciones. Comprobar que las conexiones con tus sistemas siguen vivas y actuar cuando una se cae, antes de que el flujo entero se pare.
Todo esto tiene un coste, y meterlo desde el principio es lo honesto. Es una de las tres patas del cálculo de rentabilidad: el setup, el modelo y el mantenimiento. Si haces las cuentas y te dejas la tercera fuera, el número miente. Por eso la guía de ROI de la automatización insiste en meter las horas de mantenimiento antes de firmar: un sistema barato de montar puede salir caro de sostener.
Cada cuánto se revisa y qué se mira en cada pasada
El mantenimiento no es mirar el sistema todo el rato ni no mirarlo nunca. Es una cadencia. Hay cosas que se vigilan en automático y saltan solas, y cosas que pide un par de ojos cada cierto tiempo.
- Continuo (automático). Alertas de error: si una integración se cae o un flujo se para, salta al momento. Esto no espera a la revisión; es la red que avisa de la rotura dura.
- Semanal (una pasada rápida). Un vistazo a los logs y a la cola de excepciones: qué escaló, qué tipos de caso nuevos aparecieron, si el volumen de errores sube. Diez minutos que evitan que un problema pequeño se convierta en un mes perdido.
- Mensual (revisión de calidad). Una muestra de decisiones del sistema comparada contra el criterio humano, para cazar la deriva silenciosa del modelo. Aquí es donde se nota si el proveedor cambió algo por debajo.
- Cuando el proveedor actualiza el modelo. Fuera de cadencia: si sale una versión nueva o deprecian la tuya, se prueba antes de dejar que corra sola. Un cambio de modelo se trata como un cambio de pieza, no como un detalle.
La regla debajo de todo esto: lo que se rompe de golpe se vigila en automático; lo que se degrada despacio se revisa a mano. Las dos cosas hacen falta. Solo con alertas no cazas la deriva del modelo; solo con revisiones manuales te enteras tarde de una integración caída.
Cómo se deja con red: logs, alertas y un dueño
Una automatización que no se puede mantener es una automatización que no está terminada. Y para poder mantenerla hacen falta tres cosas desde el día uno, no como parche después.
Logs, para ver qué decidió el sistema y por qué —sin registro no hay supervisión posible, solo fe—. Alertas, para que la rotura dura te encuentre a ti antes de que la encuentre tu cliente. Y un dueño: una persona con nombre que se ocupa de mirar los logs, atender las alertas e iterar. Sin dueño, el mantenimiento no lo hace nadie, que es lo mismo que no tenerlo. Quién es ese dueño y con qué autonomía trabaja es parte de que tu equipo adopte de verdad la IA, no solo la estrene.
Y una frontera que conviene dejar dicha: el mantenimiento decide qué se revisa cada mes, no qué se hace la noche que algo se para. Esa otra mitad —a quién se llama, con qué prisa y qué hace mientras tanto— es quién responde cuando se cae una automatización: severidades, guardia y runbook a escala de empresa pequeña.