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.