flowchart TD
A[Ingreso] --> B[Clasificación]
B --> C{¿Datos personales?}
C -- Sí --> D[Revisión privacidad]
C -- No --> E[Revisión contractual]
D --> E
E --> F{¿Riesgo alto?}
F -- Sí --> G[Aprobación especial]
F -- No --> H[Aprobación ordinaria]
G --> I[Registro]
H --> I
Agente de workflow
Las herramientas permiten que un agente busque, lea, calcule, escriba o registre.
Pero todavía queda una pregunta organizacional:
¿cómo se insertan esas acciones dentro de un proceso que ya tiene etapas, responsables y reglas?
Una firma, empresa o institución rara vez quiere que un sistema “resuelva como estime conveniente” todo un procedimiento.
Puede existir una ruta definida para:
- recibir una solicitud;
- clasificarla;
- pedir antecedentes;
- revisar especialidades;
- solicitar aprobación;
- registrar una decisión;
- cerrar.
En ese contexto aparece el agente de workflow.
Un agente de workflow no inventa el procedimiento institucional completo.
Opera dentro de una ruta previamente diseñada y puede ayudar a:
- seguir el procedimiento;
- seleccionar qué etapa corresponde según el estado del caso;
- pedir aprobación cuando el proceso lo exige.
Su valor está en introducir flexibilidad local sin perder la estructura institucional.
El delta respecto del workflow tradicional
La sección anterior del handbook ya explicó qué es un workflow: entrada, pasos, condiciones, responsables, estados, salidas y cierre.
No necesitamos volver a enseñar ese concepto.
La pregunta nueva es:
¿qué ocurre cuando incorporamos un agente dentro del workflow?
En un workflow completamente determinista, las transiciones pueden estar predefinidas:
si A → B
si B → C
si C → D
Con agencia podemos permitir que algunas transiciones dependan de una evaluación contextual.
Pero el agente continúa operando dentro de un marco de proceso.
1. Seguir procedimiento institucional
Un procedimiento existe porque la organización ya decidió ciertas cosas.
Por ejemplo:
Todo proveedor que trate datos personales debe pasar por revisión de privacidad.
El agente no debería reinterpretar esa regla como una sugerencia.
Su tarea puede ser reconocer si el caso activa la condición y moverlo a la etapa adecuada.
Ejemplo
Workflow de contratación:
La estructura institucional ya existe.
El agente puede ayudar en la clasificación y en la recopilación de evidencia, pero no tiene autoridad para eliminar nodos obligatorios.
Procedimiento como límite externo al modelo
Este punto es importante.
Una instrucción podría decir:
“Sigue la política interna.”
Pero una arquitectura robusta puede también representar estados y transiciones fuera del modelo.
Así, aunque el modelo sugiera:
“Podemos omitir privacidad porque el riesgo parece bajo”,
la orquestación puede impedir una transición inválida si la política exige revisión.
2. Seleccionar etapa
Si toda transición está predefinida, ¿qué agrega el agente?
Puede agregar capacidad para interpretar el estado del caso y elegir entre rutas permitidas.
Por ejemplo, recibe esta descripción:
“Proveedor SaaS. El servicio analizará CV de candidatos. Los términos mencionan subprocesadores y uso de datos para mejorar funcionalidades.”
El agente puede clasificar:
privacidad: activar
laboral: posible revisión
seguridad: activar
propiedad intelectual: revisar uso de outputs
El workflow contiene las etapas posibles.
El agente decide cuáles resultan relevantes para ese caso.
Seleccionar no es crear una nueva autoridad
La frase:
“el agente selecciona etapa”
no significa:
“el agente decide el resultado jurídico de esa etapa.”
Puede determinar:
“esto debe ir a privacidad”
sin poder determinar:
“privacidad aprueba el tratamiento.”
La primera es una decisión de routing.
La segunda puede requerir juicio profesional y autoridad institucional.
Estado como punto de coordinación
El agente de workflow necesita saber dónde está el caso.
Por ejemplo:
expediente: proveedor-127
contrato: recibido
DPA: recibido
seguridad: pendiente
privacidad: en revisión
compras: completado
aprobación final: bloqueada
Ese estado evita acciones inconsistentes.
Si la aprobación final está bloqueada hasta que seguridad termine, el agente no debería avanzar sólo porque ya completó su propio análisis.
Estados explícitos reducen ambigüedad
Comparemos:
“Parece que casi todo está listo.”
con:
contractual = completado
privacidad = completado
seguridad = pendiente
negocio = aprobado
final = bloqueado
La segunda representación permite una coordinación mucho más precisa.
3. Pedir aprobación
La aprobación no debería aparecer como una interrupción accidental.
Puede ser una etapa diseñada.
Por ejemplo:
flowchart LR
A[Agente prepara propuesta] --> B[Solicitar aprobación]
B --> C{Humano decide}
C -- Aprobar --> D[Continuar]
C -- Modificar --> E[Corregir]
C -- Rechazar --> F[Detener]
El agente puede preparar la información que necesita la persona:
- acción propuesta;
- motivo;
- evidencia;
- alternativas;
- impacto;
- elemento pendiente.
Una aprobación informada
No basta mostrar:
¿Aprobar? Sí / No
Si la persona no sabe qué está autorizando, el control es débil.
Una aprobación más útil podría incluir:
Acción propuesta:
Enviar al proveedor solicitud de modificación de cláusula 9.2.
Motivo:
Plazo de notificación 72h; estándar interno 48h.
Evidencia:
Contrato §9.2 + política interna §4.1.
Efecto:
Comunicación externa al proveedor.
El human gate se convierte en un punto real de gobierno.
Un caso completo: revisión contractual interna
Las clases utilizan una secuencia simple:
1. recibir
2. clasificar
3. analizar
4. pedir aprobación
5. registrar cierre
Desarrollemos ese caso.
1. Recibir
El sistema crea el expediente y verifica documentos mínimos.
Resultado:
Contrato: sí
DPA: sí
SLA: no
2. Clasificar
El agente interpreta el caso:
Tipo: SaaS
Datos personales: sí
Criticidad: alta
Áreas requeridas: contractual + privacidad + seguridad
3. Analizar
Cada área ejecuta su revisión.
El agente puede mover el expediente según estados permitidos.
4. Pedir aprobación
Aparece una desviación de alto impacto.
El sistema no continúa automáticamente.
Crea una solicitud de aprobación con evidencia.
5. Registrar cierre
Sólo cuando todos los estados obligatorios están cerrados puede pasar a:
estado_final = listo_para_decision
El agente organizó el proceso.
No sustituyó la autoridad final.
Workflow y agente pueden coexistir
Ésta es una idea importante para todo el handbook.
A veces se presentan workflow y agente como alternativas:
“Antes usábamos workflows; ahora usamos agentes.”
La oposición es demasiado simple.
Podemos tener:
WORKFLOW
estructura general
AGENTE
selección contextual dentro de ciertas etapas
Por ejemplo:
flowchart TD
W1[Ingreso fijo] --> A1[Agente clasifica]
A1 --> W2[Etapa obligatoria]
W2 --> A2[Agente recopila antecedentes]
A2 --> H[Human gate]
H --> W3[Registro fijo]
La rigidez institucional y la flexibilidad agentiva pueden complementarse.
Cuándo tiene sentido esta arquitectura
Un agente de workflow puede ser útil cuando:
- el proceso ya está definido;
- existen varias rutas válidas;
- la selección depende de información no perfectamente estructurada;
- hay etapas obligatorias;
- la organización necesita registrar estados;
- existen aprobaciones o excepciones.
Por ejemplo:
- intake de asuntos;
- revisión de proveedores;
- compliance;
- gestión contractual;
- solicitudes de derechos de datos;
- due diligence documental.
Cuándo no necesitamos un agente
Si el proceso puede expresarse completamente mediante reglas simples y estables, un workflow tradicional puede ser suficiente.
Ejemplo:
si monto > 100.000 → aprobación nivel 2
si monto <= 100.000 → aprobación nivel 1
No necesitamos un LLM para ejecutar una comparación numérica conocida.
Introducir agencia donde no existe ambigüedad contextual puede aumentar costo y variabilidad sin añadir valor.
Riesgo característico: el agente como atajo del proceso
Un diseño peligroso sería permitir que el agente concluya:
“La revisión de seguridad probablemente no agregará valor; continuaré sin ella.”
si la política exige esa revisión.
El agente puede tener autonomía dentro de la ruta, pero no necesariamente autoridad para redefinir la ruta.
Por eso debemos distinguir:
CAPACIDAD DE SELECCIONAR ETAPA
≠
AUTORIDAD PARA MODIFICAR PROCEDIMIENTO
Otro riesgo: estado inconsistente
Si varias herramientas actualizan estados sin coordinación, podemos terminar con:
privacidad = aprobado
DPA = faltante
La combinación es sospechosa.
La orquestación debería validar condiciones de coherencia.
Por ejemplo:
no puede marcarse privacidad como completa si falta un documento obligatorio.
Éste es un ejemplo de control determinista alrededor de una etapa agentiva.
Excepciones: donde el workflow necesita criterio sin perder su forma
Los procesos institucionales no están hechos sólo de casos normales. También contienen excepciones.
Imaginemos una política de contratación que exige revisión de seguridad para proveedores críticos. La regla general puede estar clara, pero la clasificación de “criticidad” puede depender de hechos descritos en lenguaje natural: tipo de servicio, acceso a sistemas, datos tratados, dependencia operacional y posibilidad de sustitución.
Aquí la IA puede aportar valor sin reemplazar el workflow.
El procedimiento conserva la regla:
si proveedor crítico → revisión de seguridad obligatoria
El agente ayuda a transformar antecedentes del caso en una clasificación preliminar:
servicio soporta operación esencial
+ no existe alternativa inmediata
+ procesa información confidencial
→ posible criticidad alta
→ activar revisión / pedir confirmación
La distinción es importante porque permite colocar la variabilidad antes de una transición controlada, no eliminar la transición.
Bloqueos y dependencias entre etapas
Un workflow real puede contener relaciones de dependencia. No basta saber qué tareas están pendientes; también debemos saber cuáles bloquean a otras.
Por ejemplo:
privacidad = pendiente
seguridad = completada
contractual = completada
aprobación final = bloqueada por privacidad
El agente puede continuar ejecutando tareas que no dependan de privacidad, pero debería impedir una transición final inválida.
Esta capacidad es útil porque evita dos extremos: detener todo el proceso ante cualquier pendiente o, en sentido contrario, cerrar el expediente pese a tener una dependencia crítica abierta.
Excepción no significa libertad de improvisación
Un playbook puede definir que ciertos casos se escalen porque no existe una regla suficiente. El agente de workflow debe reconocer esa frontera.
Ejemplo:
“La cláusula permite una reutilización de datos no prevista por las categorías del playbook.”
Una reacción correcta puede ser:
estado = excepción
acción = escalar a especialista
Una reacción incorrecta sería inventar un nuevo estándar para mantener el flujo en movimiento.
La capacidad de identificar “este caso no cabe en las rutas conocidas” forma parte de un proceso bien gobernado.
Qué aporta frente a una automatización puramente rígida
El agente de workflow tiene sentido cuando el proceso combina dos tipos de elementos:
estructura estable, como aprobaciones, estados y etapas obligatorias;
información flexible, como descripciones contractuales, documentos heterogéneos o hechos expresados en lenguaje natural.
La IA puede interpretar lo segundo para ayudar a navegar lo primero.
Esa combinación es especialmente natural en trabajo jurídico: los procedimientos institucionales suelen ser relativamente estables, mientras que cada asunto llega redactado de manera diferente.
Qué debes recordar
El agente de workflow no reemplaza el proceso institucional.
Su función es operar dentro de él.
Las tres capacidades centrales de esta página son:
seguir procedimiento → seleccionar etapa → pedir aprobación.
La organización puede mantener reglas duras para transiciones críticas y utilizar IA donde existe interpretación contextual.
Esta combinación permite aprovechar flexibilidad sin entregar toda la estructura del trabajo al modelo.
El problema que todavía queda abierto
El agente de workflow funciona especialmente bien cuando conocemos las etapas posibles.
Pero algunos encargos son más abiertos.
Puede que no sepamos de antemano cuál será la mejor secuencia ni cuántas subtareas harán falta.
Entonces aparece otra capacidad:
planificar.
La siguiente página desarrolla el agente planificador: descomponer objetivos, crear subtareas, elegir estrategias, evaluar resultados y replanificar cuando el plan inicial deja de servir.