Una automatización zombi no está rota: está encendida y no sirve a nadie
Cuando alguien se pregunta qué hacer con las automatizaciones que ya nadie usa, casi siempre está pensando en flujos rotos. No es eso. Un flujo roto avisa: peta, manda un correo rojo, alguien se queja y esa misma mañana se arregla. Un zombi funciona. Se ejecuta a su hora, hace exactamente lo que le pidieron hace dos años y entrega su resultado a un proceso que ya no existe.
El informe que se genera cada lunes para un comité que se disolvió. La sincronización que vuelca pedidos en una hoja que nadie abre desde marzo. El aviso que cae en un canal de Slack archivado. El correo semanal que llega a un alias donde tres personas tienen una regla de «marcar como leído». Todos verdes, todos correctos, todos inútiles.
Sobreviven porque no tienen quien se queje. Un flujo roto tiene dueño de facto —el que sufre el error—; un zombi no tiene a nadie: la persona que lo pidió cambió de equipo, la que lo montó se fue, y el que lo ve en el panel no sabe quién depende de él. Ante la duda, nadie toca. Y así llevan tres años.
El problema es que no son gratis. Consumen operaciones o ejecuciones de tu plan, que es dinero real en cuanto tu herramienta cobra por volumen. Mantienen credenciales vivas —tokens, usuarios de servicio, integraciones OAuth— muchas con permiso de escritura sobre tu CRM o tu ERP. Y ensucian el diagnóstico: cada vez que hay un incidente, alguien pierde media hora descartando flujos que no importan antes de llegar al que sí. Esta guía es el zoom a esa parte de mantener las automatizaciones con IA que va de retirar lo muerto, no de cuidar lo vivo.
El inventario real, no el que crees que tienes
El primer obstáculo no es decidir qué apagar: es saber qué tienes encendido. Casi ninguna empresa lo sabe, porque los flujos no viven en un solo sitio. La pestaña principal de tu herramienta de automatización es la punta del iceberg.
Los seis escondites habituales, por orden de cuántos aparecen cuando se levanta la alfombra:
- La herramienta principal (Make, n8n, Zapier, Power Automate), incluidas las carpetas de otros usuarios y los escenarios «privados» de quien los montó.
- Los flujos nativos dentro de cada SaaS: workflows de HubSpot, reglas de Salesforce, automatizaciones de Notion o Airtable. Nadie los cuenta como automatizaciones y son legión.
- Los scripts programados: Apps Script en Google Workspace, macros con disparador, cron en un servidor que administró alguien que ya no está.
- Las tareas programadas de la nube: Cloud Scheduler, EventBridge, jobs de un contenedor. Aquí es donde vive lo caro.
- Los webhooks entrantes que apuntan a endpoints propios: no se ven en ningún panel de automatización, solo en los logs del servidor.
- Los agentes y prompts en producción con disparador propio, que en muchas empresas ya son la capa más nueva y la peor inventariada.
Cada fila del inventario necesita siete columnas y ni una más: nombre, qué produce (la salida concreta, no «gestiona pedidos»), quién la consume, última ejecución, frecuencia, credenciales que usa y permisos de esas credenciales. La columna que hace todo el trabajo es la tercera. Si no puedes escribir un nombre propio —una persona o un sistema identificable— en «quién la consume», ya tienes tu candidato sin necesidad de investigar nada más.
Ejecución no es uso: cómo saber si un flujo se usa de verdad
Aquí es donde se equivoca todo el mundo: se ordena la lista por «última ejecución» y se dan por buenos los que corrieron ayer. Pero un zombi se ejecuta puntualmente cada día —esa es literalmente su definición—. La ejecución mide que el flujo está vivo, no que su resultado le importe a alguien. Son dos preguntas distintas y solo una es la que estás intentando responder.
Hay tres señales que sí miden consumo, y cuál usar depende de qué hace el flujo al final:
Si escribe en un sistema
Mira el registro que produce, no el flujo. ¿Alguien abre ese documento? ¿Se edita esa fila después de crearse? ¿El campo que rellena aparece en algún informe o vista que alguien consulte? Las herramientas de ofimática y los CRM guardan fecha de último acceso: es el dato más honesto que vas a encontrar y casi nadie lo mira.
Si notifica
¿Alguien responde, reacciona o hace clic? Un canal archivado, una lista de correo con regla automática de archivado o un aviso que lleva ochocientos mensajes sin una sola respuesta son la misma cosa: nadie lo lee. Si tu plataforma de mensajería te deja ver lecturas o reacciones, tienes la respuesta en un minuto.
Si alimenta a otro flujo
Comprueba si ese otro flujo también está en tu lista de dudosos. Los zombis vienen en cadena: alguien apagó el consumidor final hace un año y dejó viva toda la tubería que le daba de comer. Esta es la que más ahorra cuando aparece, porque cae media docena de golpe.
Cuando ninguna señal es concluyente —y pasará en un tercio de los casos— queda un método barato, honesto y sorprendentemente poco usado: la prueba del silencio. Apagas el flujo, dejas un aviso visible en su sitio (un mensaje automático de «esto está pausado, escribe aquí si lo necesitas», una nota en la hoja, una línea fijada en el canal) y esperas un ciclo completo de negocio. Un mes suele bastar; un trimestre si el proceso es trimestral. Si nadie reclama, tienes la respuesta.
La regla que hace que la prueba del silencio sea legítima y no una ruleta: se apaga con aviso y con ventana, nunca en silencio. Apagar a escondidas para ver qué pasa es la forma más rápida de que la próxima limpieza no la autorice nadie.
Apagar no es borrar: los tres movimientos
La razón real por la que nadie apaga nada es que «apagar» suena a irreversible. Y lo parece, porque en la cabeza de todo el mundo apagar, quitar permisos y borrar son la misma acción. No lo son. Son tres, con riesgos y calendarios distintos, y separarlas es lo que desbloquea la decisión:
- Dejar de ejecutar. Desactivas el disparador. Reversible en un clic, coste cero, y es lo que haces el día uno. No borra nada: el flujo sigue ahí, con su historial intacto.
- Revocar el acceso. Quitas la credencial, el token o el usuario de servicio que usaba —o como mínimo le bajas los permisos de escritura a solo lectura—. Esto es lo que casi nadie hace, y es donde está el riesgo de verdad: un flujo apagado con un token vivo sigue siendo una llave con permiso de escritura sobre tu CRM circulando por ahí, sin dueño y sin nadie vigilándola.
- Decidir qué se conserva. El flujo se exporta (JSON al repositorio, con fecha y motivo del apagado). Los datos que produjo se quedan donde están: no se tocan. Los registros y logs, según lo que diga tu política de retención. Solo después de esto se quita del panel, que es la única parte verdaderamente irreversible.
El calendario importa tanto como el orden. Los pasos uno y dos, el mismo día —no tiene ningún sentido apagar un flujo y dejarle las llaves—. El tres, pasados treinta o noventa días de silencio. En medio, el flujo está en cuarentena: desactivado, sin credenciales, recuperable en minutos si alguien aparece reclamándolo. Y aparecerán algunos: eso no es un fallo del método, es el método funcionando.
El criterio escrito: qué se apaga sin discusión
Un criterio escrito convierte una decisión política —«¿y si esto lo necesita alguien?»— en una operativa. No hace falta que sea largo. Cuatro reglas y quién firma las excepciones caben en media página:
- Sin consumidor con nombre → cuarentena. Si nadie puede escribir una persona o un sistema identificable en la columna «quién lo consume», el flujo se apaga. «Lo usa operaciones» no es un nombre.
- Sin resultado consumido en 90 días → cuarentena. Ojo: resultado consumido, no ejecución. Un flujo que corrió ayer y cuyo resultado no ha abierto nadie en tres meses cumple esta regla.
- Duplicado funcional de otro flujo vivo → se apaga el peor mantenido, no el más antiguo. La antigüedad no es un criterio de calidad; el número de intervenciones manuales del último trimestre, sí.
- Credencial de una persona que ya no está en la empresa → apagado inmediato, sin ventana. Esto no es limpieza, es seguridad, y no admite prueba del silencio.
Y una regla que gobierna a las otras cuatro: cualquiera puede reclamar un flujo en cuarentena, pero reclamarlo significa aceptar ser su dueño con nombre y apellidos. No «el departamento». Una persona. Sin eso, el flujo rescatado vuelve a ser zombi en seis meses y habrás hecho la limpieza para nada. Es la misma lógica de dueño nominal que sostiene toda la gobernanza y el control de la automatización: sin nombre no hay control, solo un panel.
Cadencia: una hora al trimestre, no un proyecto de limpieza
La tentación es montar «el proyecto de limpieza de automatizaciones»: un mes de trabajo, una hoja de cálculo enorme, un informe final. Se hace una vez, sale bien, y dos años después estás igual. Lo que aguanta es lo contrario: una revisión corta y periódica que cabe en una hora.
Qué cabe en esa hora trimestral: repasar los flujos que no han tenido resultado consumido, mover a cuarentena los que cumplan criterio, sacar de cuarentena los que alguien haya reclamado (con su dueño ya escrito) y borrar definitivamente los que llevan un trimestre en cuarentena sin que nadie los eche de menos. La primera vez duele —es normal encontrar entre un tercio y la mitad del inventario en estado dudoso—; a partir de la segunda son treinta minutos.
La pieza que evita la recaída se pone antes, no después: cada flujo nuevo nace con dueño y con fecha de revisión. Dos campos en la descripción, treinta segundos al crearlo. Es la diferencia entre limpiar y no volver a ensuciar, y encaja con el mismo hábito de detectar los fallos que no avisan: lo barato no es arreglar, es enterarse a tiempo. Si vas a montar todo esto desde cero, el mapa completo está en la guía de automatizar con IA.