Agente de workflow

Cómo un agente puede operar dentro de un procedimiento institucional: seguir la ruta, seleccionar la etapa pertinente y pedir aprobación sin inventar el proceso.

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:

En ese contexto aparece el agente de workflow.

Idea central

Un agente de workflow no inventa el procedimiento institucional completo.

Opera dentro de una ruta previamente diseñada y puede ayudar a:

  1. seguir el procedimiento;
  2. seleccionar qué etapa corresponde según el estado del caso;
  3. 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:

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

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.

Back to top