Hay una conversación incómoda que casi nadie está teniendo sobre la IA y la automatización: el coste real no está en construir la solución, está en mantenerla viva.
Esta semana, el ingeniero James Shore publicó un artículo que se viralizó en Hacker News con un argumento sencillo pero demoledor: un agente de IA que escribe código no sirve de nada si lo que produce te cuesta más mantener de lo que te ahorró construir. Y aunque el artículo habla de programación, el principio aplica a cualquier automatización que metas en tu negocio.
Vamos a desempaquetarlo, porque si estás pensando en automatizar algo en tu empresa, esto te va a ahorrar disgustos.
La trampa del "ya está hecho"
Cuando alguien te vende una automatización —ya sea un bot, un workflow o un agente de IA— lo que ves es la demo. Funciona. Hace lo que prometió. Firmas, pagas, te vas a casa contento.
Y tres semanas después empiezan los problemas:
- El bot empieza a fallar con casos que no se contemplaron.
- Una API cambia y todo se rompe.
- Nadie sabe cómo arreglarlo porque el código es ilegible.
- El proveedor original no contesta, o cobra una fortuna por cada ajuste.
- Acabas pagando a alguien para que haga manualmente lo que la automatización tenía que hacer sola.
Esto es lo que en el mundo del software se llama deuda técnica. Y con la llegada de los agentes de IA que generan código y automatizaciones a toda velocidad, el problema se está multiplicando.
Por qué la IA empeora el problema (si no la usas bien)
Los agentes de IA modernos son rapidísimos generando soluciones. En cinco minutos te montan un workflow que conecta tu CRM con tu email y manda respuestas automáticas. Magia.
El problema es que esa velocidad esconde una verdad incómoda: generar código o automatizaciones es fácil. Mantenerlos es lo difícil.
Un agente de IA mal supervisado produce automatizaciones que:
- Funcionan en el caso feliz, pero se rompen en los bordes. Cuando entra un email raro, un cliente con un nombre con caracteres especiales, o una factura con un formato distinto, todo se cae.
- Son una caja negra. Nadie entiende cómo están hechas. Cuando hay que cambiar algo, hay que reconstruir desde cero.
- Dependen de servicios opacos. Si el proveedor sube los precios, cambia la API o cierra, te quedas tirado.
- No tienen registros ni alertas. Cuando fallan, no te enteras hasta que un cliente se queja.
Es como comprar un coche que funciona perfecto durante un mes y luego empieza a fallar, y resulta que ningún mecánico sabe arreglarlo porque está hecho con piezas que solo conoce el vendedor.
Cómo distinguir una buena automatización de una bomba de relojería
Antes de aprobar cualquier automatización en tu negocio, deberías poder responder a estas preguntas. Si la respuesta es "no sé" o "el proveedor no me lo dice", malo:
| Pregunta | Por qué importa |
|---|---|
| ¿Quién puede modificarla si el proveedor desaparece? | Evita el secuestro tecnológico (vendor lock-in). |
| ¿Qué pasa cuando algo falla? ¿Me avisa o me entero por un cliente? | Sin monitoreo, los fallos se acumulan en silencio. |
| ¿Está documentada de forma que un humano la pueda leer? | Si solo lo entiende la IA que lo creó, tienes un problema. |
| ¿Usa herramientas open-source o estoy atado a un proveedor? | Lock-in = subidas de precio y cero flexibilidad. |
| ¿Cuánto tiempo de mantenimiento mensual requiere? | Si la respuesta es "ninguno", desconfía. Si es "mucho", también. |
| ¿Cómo gestiona los casos raros o errores inesperados? | El 80% de los fallos vienen del 20% de los casos extremos. |
El cálculo que casi nadie hace: ROI real
La gente calcula el ROI de una automatización así:
"Me ahorra 3 horas al día, eso son 60 horas al mes, a 30€/hora son 1.800€ ahorrados. La automatización me costó 2.000€. En un mes y poco la amortizo."
El cálculo real debería ser:
"Me ahorra 3 horas al día. Pero requiere 4 horas al mes de mantenimiento, más 1 hora cuando algo se rompe (pasa 2 veces al mes), más el coste mental de no fiarme del todo y revisar los resultados. Eso son 10 horas reales al mes de coste, no cero."
Una automatización buena tiene coste de mantenimiento bajo y predecible. Una mala parece barata al principio y luego se come tus horas y tu paciencia.
Lo que distingue una automatización que dura
Después de años construyendo automatizaciones para PYMEs, hay patrones claros sobre lo que separa una solución que aguanta del juguete que se rompe en tres meses:
1. Está construida sobre cimientos que no son tuyos pero tampoco están secuestrados. Las mejores automatizaciones usan herramientas open-source y estándares abiertos. En Studio SmartWork trabajamos con n8n precisamente por esto: si mañana decides cambiar de proveedor, te llevas todo. No estás atado.
2. Tiene observabilidad desde el día uno. Una automatización seria te dice cuándo funciona, cuándo falla, cuánto procesa y qué está costando. Si no tienes visibilidad, no tienes control.
3. Está diseñada para fallar bien. Sí, has leído bien. Toda automatización va a fallar en algún momento. La diferencia entre una buena y una mala es lo que pasa cuando falla: ¿se cae todo el sistema o se queda en estado seguro, te avisa y sigue con el resto?
4. La hace alguien que sigue ahí después. Esto es clave. Una automatización no es un producto que compras una vez. Es un sistema vivo. Necesita alguien que la entienda, la cuide y la mejore conforme tu negocio cambia.
El error de pensar en automatizaciones como "set and forget"
La fantasía del "lo montas y se olvida" es eso: una fantasía. Los negocios cambian. Las APIs cambian. Los modelos de IA cambian (a veces de un día para otro). Las regulaciones cambian.
Lo que sí es realista es esto: una automatización bien hecha requiere poco mantenimiento, pero constante. Como un coche. No le haces nada cada día, pero le haces la revisión cuando toca. Y si lo cuidas, te dura años.
Esa es la diferencia entre comprar una herramienta y trabajar con alguien que opera la automatización contigo. La herramienta es tuya el día uno y tu problema el día treinta. La automatización operada es un servicio: alguien la construye, la monitoriza, la ajusta y la mejora.
Qué deberías exigir antes de automatizar algo en tu negocio
Si vas a meter una automatización en tu operación, exige esto por escrito:
- Propiedad clara del código y las configuraciones. Tú deberías poder llevártelo si quieres.
- Documentación legible para humanos, no solo para la IA que la generó.
- Plan de monitoreo y alertas. ¿Cómo te vas a enterar de que algo falla?
- Acuerdo de soporte y mantenimiento. Quién, cuándo, a qué coste.
- Estrategia de rollback. Si algo sale mal, ¿cómo volvemos al estado anterior?
- Tiempo de respuesta para incidencias críticas. Especialmente si la automatización toca clientes o ventas.
Si un proveedor no puede darte esto, no te está vendiendo una automatización profesional. Te está vendiendo un prototipo.
La lección de fondo
El debate que está abriendo el artículo de Shore es importante porque marca el final de la fase "wow, mira lo que puede hacer la IA" y el comienzo de la fase "vale, pero ¿esto es sostenible?".
La IA ha bajado a casi cero el coste de construir automatizaciones. Eso es genial. Pero ha subido el riesgo de construir automatizaciones que parecen funcionar y son una pesadilla a los seis meses.
La pregunta correcta ya no es "¿puedo automatizar esto?". La respuesta casi siempre es sí. La pregunta correcta es: "¿puedo automatizarlo de forma que dentro de un año siga funcionando sin habernos arruinado en mantenimiento?".
Esa es la diferencia entre una automatización que transforma tu negocio y un experimento caro que acabas desconectando.
Y es exactamente el tipo de problema que nos llevamos pensando desde 2021: cómo construir cosas que funcionen bien, que sean fáciles de mantener y que sigan dando resultados meses después de haberlas puesto en marcha. Porque al final, una automatización solo tiene valor si te devuelve tiempo, no si te lo quita por otra puerta.