flowchart TD
A[Entrada: solicitud + antecedentes] --> B[Ingreso]
B --> C[Clasificación]
C --> D{¿Tipo y criticidad definidos?}
D -- No --> E[Solicitar información]
E --> C
D -- Sí --> F[Recuperación documental]
F --> G{¿Documentación suficiente?}
G -- No --> H[PENDIENTE DE DOCUMENTACIÓN]
H --> F
G -- Sí --> I[Análisis]
I --> J[Matriz de hallazgos]
J --> K{¿Excepciones?}
K -- Sí --> L[Escalar / resolver]
L --> M[Pedir aprobación]
K -- No --> M
M --> N{¿Aprobado?}
N -- No --> O[Registrar rechazo]
N -- Sí --> P[Registrar decisión]
O --> Q[Cerrar]
P --> Q
Workflow
Cómo convertir un proceso en una estructura explícita de entradas, pasos, condiciones, responsables, estados, salidas y criterios de cierre.
En la página anterior dimos un primer paso: dejamos de mirar acciones aisladas y comenzamos a pensar en tareas, secuencias y estados.
Eso nos permitió describir mejor cómo se mueve un asunto.
Pero todavía falta convertir esa intuición en una estructura operativa suficientemente clara para que personas y sistemas puedan coordinarse.
Supongamos que sabemos que una contratación debe seguir, en términos generales, este recorrido:
recibir
→ revisar
→ aprobar
→ registrarLa secuencia es útil, pero sigue dejando muchas preguntas abiertas.
¿Qué información debe existir al comenzar?
¿Qué significa exactamente “revisar”?
¿Qué ocurre si falta un anexo?
¿Quién debe intervenir?
¿Qué condición habilita la aprobación?
¿Qué salida debe dejar cada etapa?
¿Qué estado tiene el expediente mientras espera?
¿Cuándo puede considerarse realmente terminado?
El workflow aparece para responder esas preguntas.
Idea central
En el marco pedagógico de este sitio, un workflow es un proceso explícito que organiza entradas, pasos, condiciones, responsables, estados, salidas y cierre.
Su función principal no es “usar IA”.
Su función es hacer explícita la lógica de avance del trabajo.
Qué añade un workflow a una simple secuencia
Comparemos dos representaciones.
Primera:
recibir contrato
↓
revisar
↓
aprobar
↓
registrarSegunda:
ENTRADA
solicitud + contrato + antecedentes del proveedor
↓
PASO
clasificar tipo de contratación
CONDICIÓN DE AVANCE
tipo y criticidad identificados
RESPONSABLE
Compras / Legal
ESTADO RESULTANTE
EN REVISIÓN
↓
PASO
revisar riesgos
CONDICIÓN DE AVANCE
documentos obligatorios disponibles
SALIDA
matriz de hallazgos con evidencia
↓
PASO
pedir aprobación
CONDICIÓN DE AVANCE
excepciones identificadas y escaladas cuando corresponda
↓
CIERRE
decisión, versión y responsable registradosLas dos describen el mismo trabajo de manera general.
Pero la segunda permite operarlo.
Podemos saber qué falta, quién debe actuar, qué produce cada etapa y por qué un asunto no puede avanzar.
Ésa es la diferencia práctica.
Workflow como representación explícita
La disciplina de Business Process Management utiliza representaciones explícitas precisamente para coordinar actividades y las restricciones que gobiernan su ejecución. Weske muestra que, una vez representado un proceso, es posible analizarlo, ejecutarlo, monitorearlo y mejorarlo.
Nuestro uso del término workflow será deliberadamente más sencillo.
No necesitamos aprender BPMN ni un motor de procesos.
Necesitamos aprender a formular siete preguntas:
| Elemento | Pregunta |
|---|---|
| Entrada | ¿Qué pone en marcha el trabajo y qué recibe? |
| Pasos | ¿Qué actividades deben realizarse? |
| Condiciones | ¿Qué debe cumplirse para avanzar? |
| Responsables | ¿Quién hace o responde por cada etapa? |
| Estados | ¿Dónde se encuentra el asunto? |
| Salidas | ¿Qué produce cada etapa? |
| Cierre | ¿Qué significa haber terminado correctamente? |
Estas siete preguntas serán nuestra anatomía básica del workflow.
1. Entrada: qué pone en marcha el trabajo
Todo workflow necesita un comienzo.
En algunos procesos el inicio es un documento:
llega una demandaEn otros, una solicitud:
un área pide contratar un proveedorEn otros, un evento:
vence un plazoO un cambio en otro sistema:
se crea un nuevo incidente de seguridadPara nuestro caso conductor, la entrada podría formularse así:
Solicitud de contratación de proveedor tecnológico acompañada de los antecedentes disponibles.
Pero conviene separar dos cuestiones.
El disparador no es necesariamente toda la información necesaria
El proceso puede comenzar aun cuando falten documentos.
Por ejemplo:
DISPARADOR
el área solicitante envía la solicitud
ENTRADA INICIAL
nombre del proveedor + descripción del servicio + contrato
INFORMACIÓN TODAVÍA POSIBLEMENTE FALTANTE
DPA + SLA + seguridad + anexosEsto evita exigir que el expediente esté perfecto antes de existir.
El workflow puede comenzar precisamente para detectar qué falta.
Una entrada necesita estructura mínima
Si el proceso comienza con:
Hola, ¿pueden mirar esto?adjunto a un PDF, alguien tendrá que reconstruir:
- quién solicita;
- para qué se contrata;
- qué servicio es;
- qué urgencia existe;
- qué documentos se recibieron.
Un workflow bien diseñado intenta capturar desde el principio la información que necesitarán las etapas posteriores.
Eso reduce re-trabajo.
No significa pedir cien campos “por si acaso”.
Significa identificar la información mínima útil para iniciar correctamente.
2. Pasos: qué actividades componen el trabajo
Los pasos son las actividades del workflow.
Para el contrato tecnológico, Clases UDD.pdf utiliza una secuencia mínima especialmente clara:
1. Ingreso
2. Clasificación
3. Recuperación
4. Análisis
5. Matriz
6. Aprobación
7. RegistroCada paso resuelve un problema distinto.
Ingreso
Crea el asunto y reúne antecedentes iniciales.
Clasificación
Determina qué tipo de contratación es y qué nivel de revisión puede necesitar.
Recuperación
Obtiene documentos y criterios pertinentes.
Análisis
Ejecuta las revisiones que corresponden.
Matriz
Consolida hallazgos, evidencia e información faltante.
Aprobación
Obtiene la decisión de quien tiene autoridad suficiente.
Registro
Conserva la decisión y los elementos necesarios para cerrar el expediente.
La utilidad del workflow está en mantener estas operaciones separadas cuando tienen funciones distintas.
Un paso puede contener varias acciones
“Recuperación” podría incluir:
buscar contrato
buscar DPA
buscar SLA
consultar política interna
consultar historial de excepcionesNo necesitamos necesariamente transformar cada operación en una etapa visible del workflow principal.
La granularidad depende del control que necesitamos.
Una regla útil es:
crea un paso separado cuando necesitas observarlo, asignarlo, condicionarlo, medirlo o controlarlo de manera independiente.
Si no, puede permanecer como una subtarea interna.
Un paso no tiene por qué ser ejecutado por una sola tecnología
Por ejemplo, “analizar riesgos” podría combinar:
skill jurídica
+
RAG sobre política interna
+
tool para leer anexos
+
revisión humanaEl workflow no sustituye esas capas.
Las coordina.
3. Condiciones: qué debe cumplirse para avanzar
Aquí aparece una de las diferencias más importantes entre una lista de pasos y un workflow controlado.
Una lista dice:
clasificación → análisisUn workflow puede decir:
clasificación
↓
¿tipo de contrato y criticidad identificados?
↓
sí → análisis
no → solicitar informaciónLa condición convierte el avance en algo verificable.
Condición de entrada a una etapa
Por ejemplo:
ANÁLISIS
sólo comienza si los documentos obligatorios para la ruta están disponiblesCondición de salida de una etapa
ANÁLISIS
sólo termina cuando cada hallazgo tiene evidencia o está marcado como información faltanteCondición de escalamiento
si existe una desviación fuera del rango autorizado
→ no pasar directamente a aprobación ordinaria
→ escalarCondición de cierre
si la decisión no está registrada
→ el expediente todavía no puede cerrarseLas condiciones hacen visible el “si” que en muchos procesos vive únicamente en la experiencia de las personas.
Las mejores condiciones son observables
Comparemos:
si el contrato está bien
→ aprobarcon:
si:
- terminaron las revisiones obligatorias;
- no quedan hallazgos críticos pendientes;
- las excepciones tienen aprobación;
- la versión final está identificada;
→ solicitar aprobación finalLa segunda formulación es más útil porque permite comprobar si la condición se cumplió.
No elimina el juicio jurídico.
Lo ubica dentro de una arquitectura más visible.
Condiciones deterministas y evaluativas
Algunas condiciones pueden resolverse mediante reglas sencillas:
monto > umbralO:
DPA presente = sí/noOtras requieren evaluación:
¿la desviación contractual es material?No debemos fingir que ambas son idénticas.
Una condición evaluativa puede necesitar:
- criterios explícitos;
- evidencia;
- revisión humana;
- posibilidad de escalamiento.
Una arquitectura madura utiliza reglas simples cuando son suficientes y reserva la evaluación probabilística o profesional para aquello que realmente la necesita.
4. Responsables: quién debe intervenir
Un proceso profesional no ocurre en el vacío.
Necesitamos saber quién debe ejecutar, revisar o responder por cada etapa.
Por ejemplo:
| Etapa | Responsable principal posible | Otros participantes |
|---|---|---|
| Ingreso | área solicitante / Compras | Legal Ops |
| Clasificación | Compras / Legal | negocio |
| Privacidad | especialista de privacidad | negocio / seguridad |
| Seguridad | equipo de seguridad | proveedor |
| Revisión contractual | Legal | Compras |
| Negociación | Compras + Legal | negocio |
| Aprobación | autoridad definida | Legal / negocio |
| Registro | Legal Ops / sistema | responsable contractual |
La tabla no es una distribución universal.
Cada organización tendrá la suya.
La lección es otra: el workflow debe poder decir quién tiene la pelota.
Ejecutar no equivale a responder
Un sistema puede ejecutar materialmente una acción.
Por ejemplo:
crear registroO:
enviar recordatorioEso no significa que el sistema sea el responsable organizacional del proceso.
Debemos mantener separadas cuatro preguntas:
CAPACIDAD
¿puede hacer la acción?
PERMISO
¿está autorizado a hacerla?
DECISIÓN
¿quién determina que corresponde hacerla ahora?
RESPONSABILIDAD
¿quién responde por el resultado del proceso?Esta separación será especialmente importante cuando incorporemos mayor automatización.
Rol y persona tampoco son exactamente lo mismo
Un workflow puede asignar una tarea al rol:
ABOGADO REVISORsin predeterminar qué persona concreta la ejecutará.
La distinción es útil porque los procesos deben sobrevivir a vacaciones, rotaciones y cambios de equipo.
Weske destaca precisamente que los workflows con interacción humana pueden asignar actividades a roles y resolver en ejecución qué persona disponible las realiza.
Para un abogado no técnico basta una intuición:
diseñamos el proceso alrededor de funciones, no de nombres propios siempre que sea posible.
5. Estados: dónde está el expediente
Ya introdujimos estados en la página anterior.
Ahora debemos incorporarlos al workflow.
Una ruta posible sería:
RECIBIDO
↓
EN CLASIFICACIÓN
↓
PENDIENTE DE DOCUMENTACIÓN
↓
EN REVISIÓN
↓
EN NEGOCIACIÓN
↓
PENDIENTE DE APROBACIÓN
↓
APROBADO
↓
CERRADOPero un workflow real permite rutas laterales:
ESCALADO
RECHAZADO
SUSPENDIDO
INFORMACIÓN INSUFICIENTEEl estado tiene dos funciones.
Función informativa
Permite saber qué ocurre.
¿Cuántos asuntos están esperando al proveedor?Función de control
Puede determinar qué acciones están permitidas.
Por ejemplo:
si estado = PENDIENTE_DE_DOCUMENTACIÓN
→ no habilitar aprobaciónEso convierte el estado en parte activa de la gobernanza del proceso.
El estado debe tener significado operacional
Un problema frecuente es crear estados como:
NUEVO
ABIERTO
EN PROCESO
LISTO
TERMINADOsin definir qué significa cada uno.
“Listo” podría significar:
- análisis terminado;
- listo para negociar;
- listo para aprobar;
- listo para firmar;
- listo para cerrar.
Si una etiqueta no permite saber qué puede ocurrir después, probablemente necesita mayor precisión.
6. Salidas: qué produce cada etapa
Los pasos no deberían desaparecer sin dejar un resultado identificable.
Por ejemplo:
| Etapa | Salida posible |
|---|---|
| Ingreso | expediente creado |
| Clasificación | tipo + criticidad |
| Recuperación | conjunto documental + faltantes |
| Análisis | hallazgos con evidencia |
| Matriz | síntesis consolidada |
| Aprobación | decisión + condiciones |
| Registro | expediente cerrado y trazable |
La salida de una etapa puede convertirse en la entrada de la siguiente.
Por ejemplo:
CLASIFICACIÓN
produce:
criticidad = alta
↓
RECUPERACIÓN
usa ese resultado para exigir:
contrato + DPA + SLA + seguridadAsí aparece una relación explícita entre etapas.
Salida no equivale a texto generado
Una salida puede ser:
- un documento;
- un dato;
- un estado;
- una decisión;
- una tarea creada;
- una notificación;
- una matriz;
- un registro.
No todo workflow debe terminar con un informe.
En un sistema jurídico operativo, producir correctamente un estado o registrar una aprobación puede ser tan importante como generar texto.
La forma de salida puede funcionar como contrato entre etapas
Supongamos que la etapa de análisis debe entregar:
cláusula
hallazgo
evidencia
criterio
evaluación
información faltanteLa siguiente etapa puede esperar exactamente esos elementos.
Esto reduce el riesgo de que una etapa entregue una narración difícil de reutilizar.
Pero debemos conservar una distinción aprendida anteriormente:
estructura correcta ≠ contenido correcto ≠ evidencia suficiente.
Un objeto perfectamente estructurado puede contener una clasificación equivocada.
La estructura ayuda a coordinar y revisar.
No reemplaza la verificación.
7. Cierre: qué significa haber terminado correctamente
El último elemento suele recibir menos atención de la que merece.
Un proceso puede dejar de moverse sin haber terminado.
Por ejemplo:
nadie respondió por dos semanasno significa:
CERRADODel mismo modo:
Legal terminó su revisiónno significa necesariamente:
CONTRATACIÓN RESUELTAUn workflow necesita criterios de cierre.
En nuestro caso podrían incluir:
✓ decisión adoptada
✓ versión final identificada
✓ excepciones documentadas
✓ aprobaciones conservadas
✓ documentos finales almacenados
✓ responsable contractual identificado
✓ obligaciones futuras registradasLa regla es sencilla:
terminar una tarea no equivale a cerrar un proceso.
Cierre satisfactorio y cierre negativo
No todo proceso debe terminar con una aprobación.
También puede cerrarse porque:
proveedor rechazadoO:
solicitud retiradaO:
información insuficiente y área decide no continuarUn workflow bien diseñado permite representar esos finales sin obligar a convertir toda ruta en “éxito”.
El workflow completo del contrato tecnológico
Reunamos ahora los siete elementos.
Ahora podemos leer el diagrama de una manera más rica.
Entrada
La solicitud y antecedentes iniciales.
Pasos
Ingreso, clasificación, recuperación, análisis, matriz, aprobación y registro.
Condiciones
Tipo definido, documentos suficientes, excepciones resueltas, aprobación obtenida.
Responsables
Distintos roles organizacionales según cada etapa.
Estados
Pendiente de documentación, en revisión, escalado, pendiente de aprobación, cerrado.
Salidas
Clasificación, conjunto documental, matriz, decisión y registro.
Cierre
Existe una decisión documentada y el expediente queda trazable.
Eso es un workflow.
Workflow no significa necesariamente automatización
El mismo diseño podría ejecutarse mediante personas.
Por ejemplo:
Compras recibe
↓
Legal clasifica
↓
Privacidad revisa
↓
Compras negocia
↓
gerente aprueba
↓
Legal Ops registraTambién podría existir software que sólo muestre estados y asigne tareas.
O IA dentro de determinados pasos.
La estructura del workflow y el grado de automatización son dimensiones diferentes.
Workflow tampoco significa agente
Ésta es una frontera que debemos mantener desde ahora.
Un workflow puede incluir IA en varios pasos y seguir teniendo una ruta principal definida de antemano.
Por ejemplo:
SI faltan documentos
→ pedir información
SI hay datos personales
→ activar privacidad
SI existe excepción
→ escalarLas condiciones fueron diseñadas previamente.
El sistema sigue una arquitectura conocida.
No necesitamos todavía que seleccione dinámicamente una estrategia abierta.
Esa diferencia será importante más adelante.
Por ahora basta conservar:
WORKFLOW
organiza una ruta y sus condiciones
AGENTE
puede llegar a seleccionar dinámicamente próximos pasos dentro de límitesNo todo workflow con un LLM debe llamarse agente.
Workflow y conversación por etapas
Otra confusión posible proviene de la sección anterior del handbook.
Allí aprendimos a trabajar por etapas dentro de una conversación:
modelo propone
↓
persona revisa
↓
persona dice “continúa”
↓
modelo ejecuta siguiente etapaEso enseña la lógica de descomposición.
Pero un workflow agrega elementos que pueden existir fuera de la conversación:
- estados persistentes;
- responsables distintos;
- condiciones explícitas;
- handoffs entre personas;
- eventos externos;
- criterios de cierre;
- registros.
Una conversación de cinco mensajes puede ser parte de un workflow.
No es necesariamente el workflow completo.
La mirada de procesos
El material del curso propone cinco preguntas para insertar IA dentro de una organización.
Proceso
¿Cómo avanza el asunto desde recepción hasta decisión?
Dato
¿Qué información necesita cada etapa y dónde se registra?
Rol
¿Quién prepara, revisa, aprueba o escala?
Evento
¿Qué dispara una etapa o una excepción?
Métrica
¿Cómo sabemos si el proceso mejora o falla?
Estas preguntas amplían la evaluación.
Una aplicación puede producir excelentes outputs aislados y seguir siendo una mala solución organizacional si:
- nadie recibe el resultado correcto;
- la información llega tarde;
- existen duplicaciones;
- el proceso no sabe cuándo detenerse;
- las aprobaciones no quedan registradas;
- una excepción se pierde.
La calidad del sistema no se agota en la calidad del texto generado.
Qué puede salir mal al diseñar un workflow
Modelar únicamente el camino ideal
Si el diagrama sólo funciona cuando todo está completo y todos responden, no cubre el trabajo real.
Crear condiciones imposibles de verificar
“Si el contrato está bien” no es una condición operacional suficiente.
Confundir responsable con ejecutor técnico
Una API puede ejecutar una actualización sin adquirir responsabilidad organizacional.
No definir outputs intermedios
Si una etapa entrega “lo que resulte”, la siguiente dependerá de interpretaciones ad hoc.
Tener demasiados estados
Un proceso con cincuenta etiquetas casi indistinguibles puede resultar tan opaco como uno sin estados.
Tener demasiado pocos
“En proceso” puede esconder esperas, revisiones y aprobaciones completamente distintas.
Cerrar demasiado pronto
Que la decisión esté tomada no significa que la evidencia y las obligaciones futuras estén registradas.
Qué debes recordar
Un workflow responde una pregunta más rica que “¿qué pasos existen?”.
Debe permitir responder:
¿Qué entra?
¿Qué ocurre?
¿Qué debe cumplirse?
¿Quién interviene?
¿Dónde está el asunto?
¿Qué produce cada etapa?
¿Cuándo termina?Por eso en este sitio utilizaremos:
WORKFLOW
=
entrada
+
pasos
+
condiciones
+
responsables
+
estados
+
salidas
+
cierreNo es una definición universal de todos los sistemas de workflow.
Es nuestra arquitectura pedagógica para pensar procesos de trabajo jurídico.
El problema que todavía queda abierto
Ya sabemos describir un workflow.
Ahora aparece una nueva pregunta.
¿Quién debe ejecutar cada paso?
Podemos mantener el proceso completamente humano.
Podemos incorporar IA como asistente dentro de algunas tareas.
Podemos automatizar determinadas transiciones.
Las tres configuraciones pueden compartir exactamente el mismo workflow conceptual y, sin embargo, distribuir el trabajo de manera muy distinta.
El siguiente nodo estudia los tipos de workflow según el grado y la forma de participación de personas, IA y automatización.