Del prototipo de automatización de flujos de trabajo a la app de producción
Las herramientas low-code de flujos de trabajo son útiles porque abaratan el coste de aprender.
Puedes conectar aplicaciones, probar el acceso a APIs, añadir clasificación con IA, enrutar registros y enseñar al responsable de negocio una ruta que funciona antes de construir el software completo.
Eso está bien.
El error es tratar el prototipo como el sistema de producción para siempre. El prototipo es un artefacto de investigación. Existe para responder preguntas a bajo coste. Una vez las ha respondido, su función es orientar lo que se construye después, no convertirse en ello.
Qué debe demostrar el prototipo
Un prototipo de automatización de flujos de trabajo debería responder:
¿Qué inicia el flujo de trabajo?
¿Qué datos hacen falta?
¿Qué decisiones son deterministas?
¿Qué decisiones necesitan IA?
¿Dónde encaja la revisión humana?
¿Qué sistema recibe el resultado final?
¿Qué debe pasar cuando el flujo de trabajo falla?
Si esas preguntas están respondidas, el prototipo ha creado valor.
Un buen documento de cierre para la fase de prototipo cabe en una página, escrita con las palabras del propio equipo:
Trigger. "Llega un email a la bandeja compartida invoices@."
Entradas. "El PDF adjunto + el cuerpo del email + el dominio del remitente."
Pasos deterministas. "Rechazar todo lo que supere 10MB; comprobar el remitente contra la lista de permitidos."
Pasos de IA. "Clasificar el tipo de documento; extraer los siete campos obligatorios con su confianza."
Revisión. "Si algún campo obligatorio tiene una confianza inferior a 0.85, enrutar al revisor de cuentas a pagar."
Salida. "Tras la aprobación, enviar un asiento contable a la API de contabilidad y archivar el original."
Rutas de fallo. "Reintentar los errores transitorios tres veces; ante un fallo de validación, enrutar a la cola manual con la salida de la IA como pista."
Volumen y coste. "Unas 600 facturas/mes; el coste actual del prototipo es de $X/mes."
Si el equipo puede escribir esa página, el prototipo ha hecho su trabajo. Todo lo que siga siendo vago es señal de que hace falta más aprendizaje antes de la reconstrucción.
Qué añade el software de producción
El software de producción añade las partes que son difíciles de mantener dentro de un lienzo de flujos que no deja de crecer:
Interfaz de usuario limpia
Modelo de datos tipado
Contrato de API
Cobertura de tests
Permisos
Registro de auditoría
Entornos de despliegue
Monitorización y alertas
Documentación de traspaso
Una forma de producción mínima pero real, mapeada al mismo flujo de trabajo:
Servicio de API. FastAPI o Route Handlers de Next.js exponiendo un endpoint tipado por caso de uso. Entradas validadas con Pydantic/Zod, salidas serializadas de la misma forma.
Worker. Cola en segundo plano (BullMQ, Temporal, pgmq) que consume eventos entrantes, llama a los adaptadores y persiste el estado en Postgres.
Base de datos. Postgres con tres tablas como mínimo: la entidad de dominio (p. ej. `invoices`), una tabla `events` para el registro de auditoría y una tabla `runs` para las invocaciones de IA.
Wrapper de LLM. Un módulo pequeño por caso de uso: versión del prompt, salida estructurada, reintentos, contabilidad de costes, hooks de evaluación.
UI de revisión. Una página de administración enfocada a la cola del revisor, con las pruebas de cada campo y la corrección manual.
Observabilidad. Logs a un único destino (Datadog, Grafana Loki o incluso una consulta de Postgres). Alertas sobre tasa de error, latencia y profundidad de cola.
CI/CD. Tests en cada PR, infraestructura como código o despliegue documentado, staging y producción separados.
El flujo de trabajo se convierte en una parte del producto o en un servicio, no en una cadena frágil de nodos.
El enfoque de Urbano DX
Urbano DX parte de los resultados reales del flujo de trabajo. No tiramos lo aprendido.
Mapeamos la automatización que funciona, identificamos la lógica estable y después reconstruimos la ruta crítica como una app enfocada, una API, un dashboard o un servicio de backend.
La forma típica de un proyecto:
Semana 1. Auditar el prototipo, escribir el documento de cierre, acordar el alcance de producción y los criterios de aceptación.
Semanas 2-3. Reconstruir la columna vertebral: API, worker, base de datos, wrapper de LLM, UI de revisión. Tests de humo y una ejecución en paralelo contra el prototipo.
Semana 4. Hacer el cambio detrás de un feature flag; el prototipo se queda como respaldo. Añadir monitorización, documentación de traspaso y un runbook.
Decisión. Retirar el prototipo, dejarlo como sandbox o conservarlo para los casos límite que el sistema de producción deliberadamente no cubre.
El resultado es software que conserva la velocidad del prototipo pero añade el control que necesitan las operaciones reales. El equipo acaba con dos activos, no uno: el sistema de producción y el entorno de prototipado que puede reutilizarse la próxima vez que haya que aprender un nuevo flujo de trabajo.