Hay empresas que llaman workflow —o, en español, flujo de trabajo— a una colección de tarjetas, mensajes y buena voluntad. Funciona hasta el primer caso que no cabe en el recuadro azul.

TL;DR

Un flujo de trabajo, también llamado workflow, es un camino que deja claro qué entra, quién decide, qué sucede después, cómo pasa una etapa a la siguiente y qué evidencia prueba el resultado. Un proceso describe el trabajo que debe existir; la automatización ejecuta partes repetibles; un agente puede elegir pasos dentro de límites; un harness organiza contexto, permisos, validación e interrupción alrededor de esas piezas. Los nombres varían entre herramientas. La idea operativa no: sin responsable, excepción, criterio de paso y camino de vuelta, automatizar un proceso mal comprendido solo hace que el caos llegue más rápido.

He visto muchas conversaciones sobre inteligencia artificial (IA) empezar por el final.

«¿Se puede automatizar?»

A veces. Pero antes viene una pregunta bastante menos glamorosa: cuando alguien presenta una solicitud, ¿alguien sabe qué pasa después?

No «más o menos». No «normalmente alguien lo mira». No «hay una hoja de cálculo que actualizamos cuando nos acordamos».

¿Qué ocurre después, qué dato entra, quién decide, cómo se ejecuta esa decisión, quién la verifica, dónde aparece el resultado y qué queda como prueba?

Si esas respuestas dependen de telepatía organizativa, no tienes un flujo de trabajo. Tienes esperanza con etapas.

Y la esperanza es una herramienta de integración terrible.

Antes de elegir la herramienta, desinflamos cinco palabras grandes

No existe una taxonomía —un sistema de clasificación— universal y perfecta para estas palabras. Cada proveedor ordena sus diapositivas como quiere; algunos llaman agente a una automatización con un modelo en medio. No voy a fingir que encontré la tabla definitiva de la humanidad.

Para este artículo, uso estas definiciones de trabajo:

• un proceso es el trabajo recurrente que debe producir un resultado: atender una solicitud, aprobar una compra, publicar un cambio;
• un flujo de trabajo (workflow) es la ruta operativa de ese proceso: estados, responsables, reglas de paso, excepciones y evidencia entre el inicio y el final;
• la automatización ejecuta pasos previsibles de esa ruta mediante reglas e integraciones;
• un agente puede seleccionar próximos pasos y usar herramientas dentro de un objetivo, alcance y permisos definidos;
• un harness es el entorno que organiza contexto, fuentes, herramientas, límites, validación y puntos de aprobación alrededor de todo eso.

El mapa más detallado de estas capas está en «La IA no es una sola cosa: modelo, agente, automatización y harness».

Nada de esa lista convierte una herramienta en gerente, dueña del proceso o responsable de una pérdida. Solo ayuda a elegir la pieza correcta en cada momento.

Mi síntesis editorial es más sencilla: un flujo de trabajo es el acuerdo verificable sobre lo que sucede después. La herramienta llega después de ese acuerdo, si llega.

Un flujo real empieza antes del botón «ejecutar»

Piensa en una solicitud de compra, soporte, publicación o acceso a un sistema. El dibujo cambia; las preguntas esenciales no.

1. Solicitud: ¿qué llegó, de quién, con qué información mínima y para qué objetivo?
2. Triaje: ¿está completa, duplicada, dentro de alcance o necesita más contexto?
3. Decisión: ¿quién tiene autoridad y qué regla separa aprobar, rechazar, devolver o escalar?
4. Ejecución: ¿qué acción cambia el mundo: registra, paga, publica, concede acceso, envía un mensaje?
5. Validación: ¿cómo sabemos que el resultado coincide con lo decidido y no solo que una llamada técnica devolvió «éxito»?
6. Publicación o entrega: ¿quién recibe el resultado, por qué canal y con qué límites de exposición?
7. Evidencia: ¿dónde queda el rastro suficiente para explicar después la solicitud, decisión, acción y verificación?

Esta ruta no necesita ser burocrática para existir. Una solicitud sencilla puede atravesarla en minutos. Pero saltarse las preguntas no hace desaparecer la complejidad. Solo vuelve después como retrabajo, ruido entre equipos o alguien preguntando por qué el sistema hizo eso a las 18:47.

Qué cabe en una regla, automatización o IA

No toda etapa necesita IA. Eso debería ser un alivio, no una derrota de marketing.

Si una solicitud solo puede avanzar con número, responsable y documento obligatorio, una regla convencional resuelve mejor: es previsible, barata de probar y no necesita interpretar poesía corporativa para detectar un campo vacío.

Si el triaje exige mover datos entre sistemas, enviar un recordatorio y abrir una tarea para el equipo correcto, una automatización convencional puede ser suficiente. Ejecuta un camino conocido.

La IA empieza a ser útil cuando la entrada está menos estructurada: resumir texto largo, sugerir una categoría desde lenguaje natural, localizar divergencias en documentos o preparar una recomendación para revisión. Incluso ahí, «útil» no significa «autorizada a decidirlo todo».

Un agente puede entrar cuando necesita observar resultados, elegir entre herramientas permitidas y adaptar una secuencia dentro de límites explícitos. Pero el artículo sobre agentes genéricos deja la advertencia: el nombre de un cargo no contiene el proceso. Un «agente financiero» no recibe por inspiración divina las reglas, fuentes, excepciones y autoridades de tu empresa.

Momento	Mejor punto de partida	Lo que no puede quedar implícito
Datos obligatorios	regla	campos, formato y camino de corrección
Repetición entre sistemas	automatización	disparador, idempotencia —no crear duplicados cuando se repite la misma acción— y falla técnica
Texto o clasificación ambigua	IA como recomendación	fuente, confianza esperada y revisión humana
Elegir entre acciones permitidas	agente limitado	objetivo, herramientas, presupuesto, condición de parada y escalamiento
Cambio difícil de deshacer	decisión humana o aprobación explícita	autoridad, impacto, evidencia y rollback — retorno controlado a un estado anterior

No es una escala de «más moderno». Es una elección proporcional. Usar un agente para verificar tres campos obligatorios es usar una bazuca para matar una mosca. La mosca puede caer. Mantener el lanzador sigue siendo tu problema.

El criterio de paso evita el limbo elegante

Un flujo de trabajo no es solo una secuencia de verbos. Cada transición debe responder: ¿qué permite pasar de aquí a allí?

«En triaje» puede significar que los campos existen, no hay duplicado y la solicitud pertenece a esa cola. «Aprobado» puede significar que la persona correcta decidió, dentro de una autoridad conocida, con presupuesto y evidencia disponibles. «Concluido» debería significar que la acción ocurrió y fue validada, no solo que alguien marcó una casilla.

Sin criterios de paso, los sistemas ganan estados decorativos. Todos ven «en revisión»; nadie sabe si falta un documento, una persona, una integración o valentía para decidir.

También deben existir excepciones. Un valor fuera de rango, un cliente con restricción, una fuente que contradice a otra, una acción que no se puede deshacer: esos casos no son fallas en el dibujo. Son parte del trabajo real.

Una buena ruta de escalamiento dice quién recibe el caso, qué información viaja con él y qué queda prohibido mientras esa persona decide. «Enviarlo a un humano» sin responsable, plazo o contexto solo externaliza la ambigüedad con una etiqueta más simpática.

La evidencia no es burocracia; es la capacidad de discrepar después

Cuando todo sale bien, el rastro parece prescindible. Cuando algo falla, se vuelve la diferencia entre investigar e improvisar una narrativa.

La evidencia terminal —el registro que cierra un flujo con una prueba revisable— no tiene que ser una novela técnica. Puede ser el identificador de la solicitud, la regla aplicada, quién aprobó, el resultado de validación, los sistemas tocados y la hora. Lo suficiente para responder: «¿qué ocurrió, con qué base y cómo lo verificamos?».

El AI Risk Management Framework del National Institute of Standards and Technology (NIST) de Estados Unidos organiza la gestión de riesgos de IA en actividades como gobernar, mapear, medir y gestionar. Es voluntario y amplio; no entrega el flujo de trabajo de tu empresa ni certifica una automatización. Su utilidad aquí es menor y más concreta: obliga a tratar responsabilidad, contexto y medición como parte del sistema, no como una nota escrita después del incidente.

Para sistemas con IA, registrar de dónde vino una recomendación, qué fuentes usó y cuándo hubo revisión humana ayuda a evitar una fantasía común: confundir una respuesta convincente con una decisión explicable.

La reversibilidad es una pregunta antes del arrepentimiento

Hay acciones que pueden fallar y repetirse. Hay acciones que una persona puede rehacer. Y hay acciones que cambian acceso, dinero, datos, comunicación pública o producción de un modo que no debería depender de «luego miramos los registros técnicos de eventos (logs)».

Antes de automatizar, yo preguntaría:

• ¿cuál es el peor efecto si esta acción se ejecuta dos veces?
• ¿cómo detengo una ejecución que se está saliendo del camino?
• ¿hay una vista previa, simulación o aprobación antes del efecto?
• ¿qué vuelve exactamente con rollback y qué no vuelve?
• ¿qué evidencia debe conservarse antes de deshacer algo?

El texto sobre limpieza de automatizaciones explora la misma lógica desde el descarte: no basta llamar viejo a algo; hay que saber si está protegido, quién lo consume y cómo recuperar lo importante.

La reversibilidad no es excusa para actuar sin atención. Es margen para experimentar sin convertir cada cambio en una apuesta irreversible.

El flujo de trabajo viene antes del futuro bonito

Existe una tentación comprensible de dibujar primero la operación perfecta: un agente recibe todo, entiende todo, decide todo y pasa el día resolviendo problemas mientras el equipo toma café mirando un panel impecable.

Tal vez algún día la presentación se vea así. Hoy, si nadie puede explicar la ruta actual, automatizar el futuro solo acelera la confusión de ayer.

Empieza por lo que ya ocurre. ¿Dónde llega la solicitud? ¿Dónde se detiene? ¿Qué decisión sigue siendo humana porque debe serlo y cuál lo es solo porque nadie la ha diseñado bien todavía? ¿Qué falla es aceptable? ¿Quién responde por una excepción? ¿Qué prueba necesitarías si el resultado fuera cuestionado?

En i-9.ai, este tipo de descubrimiento llega antes de una promesa de autonomía. La finalidad no es hacer que una máquina parezca ocupada. Es transformar trabajo disperso en capacidad más clara, gobernable y verificable.

El flujo de trabajo no es una prisión para la operación.

Es lo que permite mejorar la ruta sin fingir que la ruta no existe.

Un prompt inicial para mapear antes de idealizar

Si ya utilizas un agente, chatbot o herramienta de automatización, intenta empezar por esto, sin pedir una solución todavía:

Un prompt es el conjunto de instrucciones que recibe el sistema. Aquí inicia el relevamiento; no lo reemplaza.

Actúa como analista de procesos. No propongas automatización ni IA antes de mapear el flujo de trabajo actual. Haz preguntas cortas y registra, en una tabla: 1) disparador y solicitante; 2) información mínima de entrada; 3) triaje; 4) decisiones y responsables; 5) acciones y sistemas involucrados; 6) criterios de paso; 7) excepciones, plazos y escalamiento; 8) validación de entrega; 9) evidencia que debe permanecer; 10) reversión o mitigación cuando algo falle. Distingue hechos observados, reglas existentes, hipótesis y lagunas. No inventes etapas. Al final, presenta primero el flujo actual, después los riesgos y solo entonces opciones proporcionales de regla, automatización o IA, indicando qué requiere decisión humana.

El prompt no descubre el proceso por sí solo. Nada lo hace. Pero obliga a que la conversación empiece en el lugar correcto.

Antes de la automatización.

Antes del agente.

Antes de la esperanza con etapas.

Para profundizar

• NIST AI Risk Management Framework: referencia oficial para gestión de riesgos de IA; no es una taxonomía universal de flujos de trabajo ni un certificado de seguridad.
• OpenAI — Construcción de agentes: documentación de ingeniería sobre agentes, herramientas y supervisión; describe un enfoque de producto, no sustituye el diseño del proceso local.
• Wikipedia — Flujo de trabajo: ruta enciclopédica hacia la noción general de flujo de trabajo.
• Wikipedia — Idempotencia: contexto para la propiedad de repetir una operación sin acumular un efecto nuevo.
• Wikipedia — Rollback: contexto para el retorno controlado de un cambio de datos o software.

Referencias y límites de uso

• El AI Risk Management Framework del NIST sustenta que la gestión de riesgos de IA involucra gobernanza, contexto y medición a lo largo del ciclo de vida. Es voluntario y de alto nivel; no prueba que un workflow específico sea adecuado.
• La documentación de agentes de OpenAI sustenta la necesidad de límites y supervisión al construir sistemas que usan herramientas. No establece una definición universal de agente, workflow o harness.
• Las definiciones de trabajo y la tesis de «esperanza con etapas» son síntesis editorial de este artículo, no una clasificación atribuida a las fuentes.