De la proliferación de herramientas de flujos de trabajo con IA a una plataforma propia
Las herramientas de flujos de trabajo suelen entrar en una empresa por una puerta lateral útil.
Un equipo construye un flujo en n8n. Otro equipo construye una app en Dify. Alguien más conecta Zapier o Make. Pronto hay muchas automatizaciones pequeñas que funcionan, pero nadie entiende del todo el sistema completo.
Eso es la proliferación de flujos de trabajo. No es un fallo de las herramientas: cada una fue la elección correcta en su momento. Es un fallo estructural: nadie era responsable de la capa que surgió cuando esas elecciones se apilaron unas sobre otras.
Señales de que la capa de herramientas pesa demasiado
Vigila estos síntomas:
Las credenciales están duplicadas entre flujos de trabajo
La lógica de negocio existe solo dentro de nodos visuales
Nadie sabe qué flujo de trabajo es la fuente de la verdad
Los errores se gestionan a mano en el chat
No hay suite de tests
Los registros de auditoría están incompletos
Cambiar un campo rompe tres automatizaciones
Síntomas más concretos de fase avanzada:
Desviación entre staging y producción. Cada entorno se mantiene a mano; ya no coinciden.
Flujos de trabajo en la sombra. Un equipo copió un flujo a "su propio workspace" y lo modificó. El equipo original no lo sabía.
Secretos guardados como texto plano dentro de los nodos. Rotarlos exige abrir docenas de editores.
Fallos con impacto en clientes descubiertos horas tarde porque la única alerta es que "alguien se dé cuenta".
Permisos heredados del propio workspace. "Cualquiera con login puede editar el flujo de facturación de producción."
El factor bus es uno. Una sola persona sabe cómo encajan todos los flujos; sus vacaciones son un riesgo de producción.
El coste de IA está descontrolado. Varios flujos de trabajo llaman a OpenAI/Anthropic sin límites de velocidad centrales, sin reintentos y sin presupuestos por equipo.
El problema no es la herramienta. El problema es que la herramienta se convirtió en la arquitectura.
Convierte los patrones repetidos en software
La solución es identificar los patrones de automatización repetidos y moverlos a software propio:
Adaptadores de API compartidos
Colas de revisión
Dashboards de administración
Servicios de reintento
Trabajos programados
Servicios de notificaciones
Arneses de evaluación de LLM
Una forma útil para la capa de plataforma propia:
```
core/
adapters/ # one typed module per external system
# (zendesk.ts, salesforce.ts, kintone.ts, ...)
# auth, rate limit, retries, idempotency, observability
queues/ # named topics, retry policy, DLQ
llm/ # provider abstraction, prompt registry,
# structured output, evaluation hooks, cost accounting
review-ui/ # shared admin app: queues, evidence, override, audit
scheduler/ # one place for cron and triggered jobs
notifications/ # email / slack / teams with templates and rate limits
audit/ # append-only events table, queryable
workflows/
<team>/<workflow> # actual business workflows, using core primitives
# or, where appropriate, n8n / Dify flows that call core
```
El objetivo no es prohibir el low-code. Es dar a cada equipo el mismo conjunto de primitivas de confianza, para que la capa visual deje de cargar con una responsabilidad crítica para el negocio para la que nunca fue diseñada. Una vez existe `core/`, la herramienta de flujos de trabajo puede volver a lo que hace bien: orquestación, experimentos rápidos y pegamento no crítico.
Una migración práctica
No lo reescribas todo.
Una migración por etapas que mantiene todo en marcha:
1. Inventario. Lista cada flujo de trabajo activo, su responsable, su disparador, sus salidas, los sistemas que toca y su volumen. Un ejercicio de dos días; el resultado suele sorprender a todos.
2. Ordena por riesgo × volumen. Los flujos de trabajo que tocan clientes, dinero o compliance van primero. Los internos prescindibles van al final.
3. Elige un flujo de trabajo frágil e importante. Documenta el disparador, los datos, la lógica, el paso de IA, la ruta de revisión y el traspaso. Reconstruye la pieza más crítica como software.
4. Construye la primera pieza de `core/` que necesite. A menudo es el primer adaptador (Zendesk, Salesforce, kintone), la primera cola o el wrapper de LLM. Hazla reutilizable desde el principio.
5. Ejecuta en paralelo. Compara las salidas. Haz el cambio con un feature flag.
6. Reutiliza en el siguiente flujo de trabajo. Cada migración deja detrás una pieza de plataforma sobre la que el siguiente puede construir.
Elige un flujo de trabajo frágil. Documéntalo. Reconstruye la pieza más crítica como software. Ejecútala junto al flujo de trabajo. Mide la fiabilidad.
Ese es el camino de la proliferación de herramientas a una plataforma de automatización profesional. La métrica que demuestra que el trabajo está dando frutos no es "borramos n8n"; la mayoría de las empresas deberían conservarlo. La métrica es "la siguiente automatización crítica costó la mitad de esfuerzo porque la plataforma ya tenía lo que necesitaba". Cuando eso se vuelve rutina, la proliferación ha desaparecido.