Mantenimiento de automatizaciones: quién lo hace cuando se rompe y el proveedor no contesta

El mantenimiento de las automatizaciones lo tiene que hacer alguien con nombre: tu proveedor con un compromiso de respuesta por escrito, una persona de tu equipo con acceso de administrador y horas asignadas, o un tercero que la audite y la adopte. Si nadie cumple esas tres condiciones, tu automatización no tiene mantenimiento: tiene suerte. Y la suerte se acaba, porque un flujo de Make, Zapier o n8n se degrada solo aunque nadie lo toque: las API cambian, los tokens caducan y los planes se agotan. Este artículo es el manual para el escenario que nadie te contó al vender: la automatización se rompió y quien la montó no contesta. Es la pieza de rescate del método de automatizar procesos con IA: aquella guía enseña a nacer bien; esta arregla lo que nació mal.

Por qué tu automatización se rompe sola aunque nadie la toque

Una automatización se rompe sola porque depende de piezas de terceros que cambian sin pedirte permiso: las API se actualizan o se retiran, las credenciales y los tokens caducan, los datos de entrada cambian de formato, el plan contratado se queda corto y la plataforma se actualiza. Ninguna de esas causas requiere que alguien toque el flujo: basta con que el mundo siga girando alrededor.

Tres de ellas vienen documentadas con fechas por los propios proveedores. La política de versiones de la Graph API de Meta (2026) garantiza cada versión durante al menos dos años y la caduca dos años después de que salga la siguiente; lo traicionero es que al caducar las llamadas no fallan: se redirigen a otra versión disponible y el flujo cambia de comportamiento sin lanzar un solo error. La documentación de identidad de Google (2026) explica el clásico de las automatizaciones baratas: si tu proveedor conectó Gmail o Sheets con una aplicación propia que nunca salió del estado de prueba, el token caduca a los 7 días; y uno sin uso durante seis meses muere igual. Y la política de deprecación de modelos de Anthropic (2026) da al menos 60 días de aviso antes de retirar un modelo; pasada la fecha, las peticiones fallan.

¿Cada cuánto se rompe una automatización que nadie vigila?

No hay una cifra universal, pero sí un patrón: cada causa tiene su calendario y todos corren a la vez. Las cinco, con su síntoma, su frecuencia típica y quién debería hacerse cargo:

Dos de las cinco filas no producen ningún error visible. Por eso la respuesta a "¿pero quién lo rompió?" suele ser: nadie. Se rompió de calendario.

Qué es de verdad el mantenimiento de automatizaciones (y en qué se va el tiempo)

El mantenimiento de automatizaciones es el trabajo recurrente de vigilar, ajustar y actualizar un flujo para que siga representando la realidad: revisar errores y ejecuciones, renovar credenciales, adaptar el flujo cuando cambian las API o los datos y actualizar la información del negocio que el sistema usa. No es reparar averías: es evitar que lleguen a producirse.

En qué se va el tiempo, por orden real. Primero, en mirar: leer las ejecuciones de la semana, distinguir los fallos que se reintentan solos de los que se tragan datos y comprobar que los avisos llegan a alguien. Segundo, en los cambios del negocio: precios, catálogo y políticas cambian, y un flujo que nadie actualiza responde con seguridad cosas que ya no son verdad. Tercero, en los cambios de fuera: leer las notas de versión y migrar lo afectado dentro de la ventana de aviso. Y cuarto, en los cambios que pide el cliente, donde los flujos frágiles enseñan su naturaleza. Una frase anónima de un foro de automatizadores lo resume: "Zapier, Make y similares son geniales… hasta que el cliente quiere cambiar algo y tu flujo se rompe como una torre de naipes".

En Godius operamos n8n autoalojado en producción para nuestros propios procesos, y autoalojar enseña lo que las cuotas mensuales esconden: las actualizaciones las aplicas tú, con copia previa y leyendo qué cambia en cada versión. Ese trabajo existe siempre; la elección es quién lo hace y si está presupuestado.

Las señales de que tu proveedor va a dejarte tirado, antes de que pase

Un proveedor que va a desaparecer avisa sin querer: las respuestas tardan cada vez más, solo una persona conoce tu proyecto, la documentación "está pendiente" desde la entrega, las cuentas y credenciales siguen a su nombre y la cuota mensual no detalla qué incluye. Tres de esas señales juntas significan que el abandono ya empezó, aunque el flujo todavía funcione.

La queja se repite en foros españoles casi con las mismas palabras; una, literal, sobre pymes que "ya han acudido a una empresa de 'IA', y lo pongo entre comillas porque lo que hacen es una automatización con Make, Zapier, n8n o similar, que a los 3 meses ya no les funciona y la empresa proveedora no responde". Los tres meses no son casualidad: es el plazo típico en que caduca el primer token o llega la primera factura de plan agotado. El proveedor que iba a desaparecer lo hace en la primera avería, porque cobró por construir y nunca presupuestó operar.

Las señales se comprueban sin saber nada técnico. La latencia creciente: de responder en horas a responder en semanas. La persona única: si nadie más que tu contacto sabe contestar una duda del proyecto, tu mantenimiento depende de sus vacaciones. La documentación fantasma: prometida en la propuesta, nunca entregada. La propiedad ajena: si para ver tu propia automatización tienes que pedirle acceso, no es tuya. La cuota opaca: un "mantenimiento" mensual sin desglose de horas ni compromiso de respuesta es un alquiler de tranquilidad, no un servicio. Y la prueba definitiva, hoy mismo: pregúntale qué cambios de sus plataformas están anunciados para los próximos seis meses. Quien mantiene de verdad se sabe la respuesta; quien solo cobra dirá que todo está bien.

¿Quién hace el mantenimiento de las automatizaciones? Las tres opciones reales

El mantenimiento de una automatización lo puede hacer el proveedor que la construyó, con compromiso de respuesta por escrito; una persona de tu equipo, con acceso de administrador y horas asignadas; o un tercero que la adopte tras una auditoría. Lo que no funciona es la cuarta opción, la más común: nadie en concreto, hasta que se rompe.

El proveedor original es la opción natural cuando el proyecto se entregó bien: conoce el flujo y detecta los cambios de las plataformas antes que tú. Exige lo del apartado siguiente por escrito, porque sin contrato esta opción degenera en la cuarta. La persona interna funciona cuando existe de verdad: con credenciales, criterio para abrir una incidencia útil y horas en su semana, no buena voluntad. Es la pieza central del modelo híbrido que analizamos al comparar agencia de IA o equipo interno: fuera se construye, dentro se opera. Y el tercero que adopta es la opción menos conocida y la más usada en la práctica, porque es la única disponible cuando el constructor ya no contesta: otro equipo audita lo que hay, recupera el control y decide qué se queda y qué se rehace. Adoptar un flujo ajeno cuesta más que mantener uno propio: se paga en auditoría inicial lo que se ahorró en documentación.

Qué exigir por contrato para que nadie te deje tirado

Un contrato que te protege incluye cinco cosas: propiedad expresa del código y de los flujos, cuentas y credenciales a nombre de tu empresa, documentación entregada como hito de pago, exportabilidad de los flujos en formato abierto y un compromiso de respuesta con plazos concretos. Si falta cualquiera de las cinco, el día del fallo estarás negociando en lugar de reclamando.

La propiedad y las credenciales son terreno legal y están desarrolladas, con los artículos de la ley que juegan en tu contra si el contrato calla, en la comparativa de agencia o equipo interno. Aquí va lo específico del mantenimiento, donde casi todos los contratos cojean:

La exportabilidad se pide con formato: los flujos de n8n y Make se exportan como JSON, y ese export, con los prompts y los esquemas de datos, debe entregarse en cualquier momento que lo pidas, no solo al rescindir. Quien se niega a darte el JSON de tu propio flujo te está diciendo cómo acabará la relación.

El compromiso de respuesta se escribe con tres números: en cuánto tiempo te responden cuando algo falla, en cuánto está resuelto o escalado y qué pasa si se incumple. Distingue avería total (el flujo no ejecuta) de degradación (ejecuta mal), porque la segunda es más dañina y suele quedar fuera de los compromisos genéricos.

Y la cuota mensual se desglosa o no se firma: cuántas horas de revisión incluye, quién las hace y qué cambios de plataforma cubre sin coste extra. Con ese desglose puedes comparar propuestas; sin él, comparas actos de fe. El reparto completo del coste de un sistema así, partida por partida, está en el desglose de cuánto cuesta un agente de IA.

Cómo recuperar el control de una automatización huérfana, paso a paso

Recuperar una automatización huérfana consiste en averiguar dónde corre, conseguir acceso de administrador, poner las credenciales a tu nombre y reconstruir la documentación mínima antes de decidir su futuro. Se puede hacer sin el proveedor, aunque cuesta más: la mayoría de plataformas permite exportar los flujos, y las integraciones dejan rastro de qué toca cada paso.

Este es el orden exacto para auditar una automatización que heredaste, ya sea de un proveedor desaparecido, de un empleado que se fue o de tu yo de hace dos años:

1. Localiza dónde corre. Busca en el correo de la empresa las altas y facturas de Make, Zapier o n8n. Identifica plataforma, cuenta y tarjeta que paga. Si todo está a su nombre, este paso es una reclamación por escrito: acceso de administrador y traspaso de cuenta.
2. Consigue acceso de administrador, no de invitado. Necesitas ver ejecuciones, credenciales y configuración, no solo el dibujo del flujo. Sin ese nivel no auditas: miras.
3. Exporta todo antes de tocar nada. En n8n y Make los flujos se exportan como JSON; guárdalos con fecha. Es tu copia de seguridad y tu prueba de qué había.
4. Inventaria las integraciones. Lista cada sistema que el flujo toca (correo, hojas, CRM, WhatsApp, modelo de IA) y de quién es la credencial de cada paso. Aquí salen las sorpresas: tokens personales de alguien que ya no está, apps en modo prueba, claves compartidas.
5. Rota las credenciales ajenas. Sustituye toda clave a nombre del proveedor o de un exempleado por una de la empresa, integración a integración, comprobando tras cada cambio que el flujo sigue ejecutando.
6. Activa los avisos de error. Que cada fallo de ejecución llegue a un correo o canal que alguien lea. Es la diferencia entre enterarte tú o por un cliente enfadado.
7. Reconstruye la documentación mínima. Una página por flujo: qué hace, qué lo dispara, qué sistemas toca y qué hacer si falla. Es lo que convierte la automatización en heredable la próxima vez.
8. Mide de dos a cuatro semanas y decide. Ejecuciones, errores, casos resueltos a mano. Con esos datos se decide el futuro del flujo.

Si el paso 1 se atasca porque el proveedor no responde ni al requerimiento, da por perdido el flujo que corre en sus cuentas; lo recuperable es el proceso: qué hacía, con qué datos y para quién. Duele menos de lo que parece, porque un flujo sin acceso ni documentación valía exactamente eso.

¿Cuándo se arregla y cuándo se tira y se rehace?

Se arregla cuando el proceso de negocio sigue siendo el mismo, el fallo está localizado en una pieza concreta y tienes acceso para tocarla. Se tira y se rehace cuando el proceso cambió, cuando nadie puede entrar a mantenerla o cuando repararla exige entender un flujo sin documentar que su autor ya no explica. La inversión pasada no vota.

Con matices: una rotura de la tabla de causas (un token, una versión de API, un plan corto) casi siempre es reparación acotada y compensa aunque el flujo sea mediocre. Una automatización que falla en varios puntos, sin documentación y sobre cuentas ajenas, suele costar más de entender que de rehacer, y rehacerla tiene un premio oculto: esta vez nace con propiedad, avisos y mantenimiento pactado. El marco completo del veredicto, con su tabla de señales, está en por qué la IA no da resultados; y si el flujo merece rehacerse, empieza por la guía de mapear procesos antes de automatizar.

Queda la pregunta con la que abrimos: quién lo hace. En Godius, consultoría de inteligencia artificial aplicada a empresas reales, este escenario es puerta de entrada habitual: llega alguien con un flujo roto y un proveedor en silencio, y el trabajo empieza por recuperar el control, no por vender uno nuevo. Los servicios de automatización incluyen esa auditoría, con veredicto honesto de arreglar o rehacer y, en ambos casos, cuentas a tu nombre y mantenimiento con horas, nombres y plazos por escrito. Que la próxima vez que algo se rompa un domingo, alguien lo vea el domingo.