flowchart LR
A[Objetivo] --> A1[Resultado]
A --> A2[Cierre]
B[Contexto] --> B1[Fuentes]
B --> B2[Estado]
B --> B3[Memoria]
C[Herramientas] --> C1[Capacidad]
C --> C2[Permisos]
C --> C3[Límites]
D[Trayectoria] --> D1[Criterios]
D --> D2[Evidencia]
D --> D3[Observabilidad]
E[Persona] --> E1[Aprobación]
E --> E2[Escalamiento]
E --> E3[Responsabilidad]
Cinco preguntas de control
Después de recorrer la arquitectura de los agentes aparece un riesgo pedagógico paradójico.
Podemos aprender decenas de términos —modelo, contexto, tool, RAG, workflow, planner, critic, memoria, trace, human gate— y terminar sin una forma sencilla de evaluar un sistema real.
Una demo puede verse convincente. Un proveedor puede describir su producto como “agente autónomo”. Un equipo interno puede anunciar que ha construido un agente para contratos, compliance o investigación jurídica.
¿Cómo saber si realmente comprendemos qué hace?
La clase cierra el recorrido con cinco preguntas.
No pretenden reemplazar todo lo estudiado.
Funcionan como una compresión del modelo completo.
Antes de confiar, contratar, desplegar o ampliar la autonomía de un agente, deberíamos poder responder cinco preguntas:
- ¿Cuál es el objetivo operativo exacto?
- ¿Qué contexto utiliza y de dónde sale?
- ¿Qué herramientas puede utilizar y con qué permisos?
- ¿Cómo se evalúa su trayectoria, no sólo la salida?
- ¿En qué punto interviene una persona responsable?
Si no podemos responderlas, todavía no comprendemos suficientemente la capacidad que pretendemos gobernar.
Por qué sólo cinco preguntas
La página anterior utilizó ocho elementos para diseñar un agente jurídico.
¿Por qué reducirlos ahora?
Porque las cinco preguntas agrupan varias decisiones relacionadas.
La pregunta por el objetivo incorpora también el criterio de cierre.
La pregunta por el contexto obliga a revisar alcance, fuentes, estado y memoria.
La pregunta por las herramientas obliga a discutir capacidades, permisos y límites.
La pregunta por la trayectoria reúne criterios, evidencia, calidad y observabilidad.
La pregunta por la persona responsable sitúa autorización, juicio profesional y escalamiento.
Podemos verlo así:
No son cinco temas nuevos.
Son cinco ventanas desde las cuales reconstruimos todo lo aprendido.
1. ¿Cuál es el objetivo operativo exacto?
La primera pregunta parece obvia, pero muchas descripciones de agentes fracasan aquí.
“Es un agente jurídico.”
no es un objetivo.
“Ayuda a revisar contratos.”
es una función general.
“Automatiza compliance.”
es todavía demasiado amplio.
Un objetivo operativo debería describir qué resultado debe producir y cuándo puede considerarse alcanzado.
Por ejemplo:
Preparar una matriz de revisión de contratos de proveedores de IA, identificando desviaciones frente a criterios internos, evidencia, información faltante y asuntos que requieren decisión humana.
Ahora podemos preguntar:
- ¿la matriz existe?;
- ¿cubre las materias obligatorias?;
- ¿cada hallazgo está respaldado?;
- ¿los faltantes están identificados?;
- ¿los casos críticos fueron escalados?
La misión puede evaluarse.
El objetivo también revela lo que no debe delegarse
Comparemos dos formulaciones.
Objetivo A
Aprobar automáticamente contratos estándar.
Objetivo B
Preparar antecedentes y una recomendación para que la instancia competente decida si un contrato estándar puede aprobarse.
La diferencia no es estilística.
El objetivo A atribuye al sistema una decisión.
El objetivo B reserva la decisión y delega preparación.
Antes de discutir precisión del modelo necesitamos saber cuál de las dos arquitecturas estamos evaluando.
Pregunta de cierre asociada
Toda definición del objetivo debería permitir responder:
¿Cuándo termina correctamente el agente?
Puede terminar porque:
- completó el trabajo;
- falta información crítica;
- alcanzó un punto de aprobación humana;
- salió de alcance;
- llegó a un límite operacional.
Un agente sin criterio de cierre tiene un objetivo incompleto.
2. ¿Qué contexto utiliza y de dónde sale?
La segunda pregunta se ocupa de la información que condiciona las decisiones del sistema.
Un agente no opera sobre “la realidad”.
Opera sobre una representación construida mediante aquello que recibe, recupera, conserva y selecciona.
Por eso debemos preguntar dos cosas distintas:
¿qué información utiliza?
¿cuál es su procedencia?
Qué puede formar parte del contexto
Dependiendo del sistema:
- instrucciones;
- solicitud del usuario;
- documentos adjuntos;
- resultados de RAG;
- datos obtenidos mediante herramientas;
- estado del workflow;
- resultados anteriores;
- ejemplos;
- memoria persistente.
El contexto de un agente es dinámico.
Puede cambiar a medida que actúa.
La procedencia importa
Consideremos una afirmación:
“El proveedor conserva los datos durante 90 días.”
Podría provenir de:
- una cláusula contractual;
- una política web del proveedor;
- un correo comercial;
- un DPA;
- una respuesta generada anteriormente;
- una memoria del agente;
- una inferencia.
El texto final puede ser idéntico.
Su valor probatorio y operacional no lo es.
Por eso “tener contexto” no basta.
Necesitamos conocer su origen, vigencia y función.
Contexto y alcance
La pregunta también obliga a examinar qué queda fuera.
¿Puede el agente buscar toda la web?
¿Sólo documentos del expediente?
¿Puede acceder a correos?
¿A información de otros clientes?
¿Utiliza memoria entre sesiones?
¿Puede recuperar políticas antiguas?
El control de fuentes es una parte central de la gobernanza del agente.
Un agente puede razonar correctamente sobre documentos incompletos y aun así producir una conclusión incorrecta respecto del caso completo.
Por eso debemos evaluar no sólo cómo procesó, sino qué tuvo realmente disponible para procesar.
3. ¿Qué herramientas puede utilizar y con qué permisos?
La tercera pregunta separa dos ideas que suelen mezclarse:
capacidad y autoridad.
Una herramienta permite realizar una operación.
Un permiso determina si el sistema puede ejecutarla en una situación concreta.
No basta enumerar integraciones
Una demo puede anunciar:
“El agente se conecta a correo, Drive, CRM y gestor documental.”
Eso describe capacidad potencial.
Todavía necesitamos saber:
- ¿qué puede leer?;
- ¿qué puede escribir?;
- ¿qué puede modificar?;
- ¿puede enviar mensajes?;
- ¿puede eliminar?;
- ¿puede hacerlo automáticamente?;
- ¿qué requiere autorización?;
Una matriz mínima
| Acción | Capacidad técnica | Permiso automático | Aprobación humana |
|---|---|---|---|
| Leer contrato del expediente | Sí | Sí | No |
| Buscar DPA interno | Sí | Sí | No |
| Preparar correo al proveedor | Sí | Sí | No |
| Enviar correo | Sí | No | Sí |
| Cambiar contrato a “aprobado” | Sí técnicamente | No | Sí / reservado |
| Eliminar documentos | Posible | No | No o control especial |
La columna decisiva no es sólo la primera.
Un sistema puede ser técnicamente capaz y estar correctamente impedido de actuar.
Principio de mínimo privilegio funcional
El agente debería disponer de las capacidades necesarias para su misión, no de todas las capacidades técnicamente disponibles.
Si necesita recuperar documentos, no existe una razón automática para permitirle enviar correos.
Si necesita completar una matriz, no se sigue que deba poder modificar el contrato fuente.
Cada permiso adicional amplía el espacio de consecuencias posibles.
Reversibilidad
La pregunta por las herramientas también debería incorporar:
¿Qué ocurre si la acción fue incorrecta?
Leer un documento es distinto de eliminarlo.
Preparar un borrador es distinto de enviarlo.
Recomendar un estado es distinto de cambiarlo.
Cuanto menor sea la reversibilidad, más importante será limitar la autonomía.
4. ¿Cómo se evalúa su trayectoria, no sólo la salida?
Ésta es probablemente la pregunta que más claramente distingue la evaluación de un agente de la evaluación de una respuesta aislada.
Supongamos que el resultado final dice:
“Recomendación: aprobar con condiciones.”
Podría ser correcto.
Pero todavía debemos saber:
- qué documentos examinó;
- qué rutas eligió;
- qué búsquedas hizo;
- qué herramienta utilizó;
- qué encontró;
- qué descartó;
- qué errores ocurrieron;
- qué decisiones tomó entre pasos;
- qué evidencia sostiene la conclusión.
Resultado correcto, trayectoria defectuosa
Imaginemos que el agente concluye correctamente que falta un DPA.
Pero lo hizo porque una búsqueda falló, aunque el DPA sí estaba en el expediente.
El resultado final parece prudente.
La trayectoria revela un defecto de recuperación.
O pensemos en el caso contrario.
El agente encuentra el documento correcto por casualidad después de utilizar varias herramientas innecesarias y acceder a repositorios que no debía consultar.
El producto final puede ser correcto y, sin embargo, el comportamiento del sistema ser inaceptable.
Qué debemos poder observar
No necesitamos capturar una supuesta transcripción de “pensamientos internos” del modelo.
Lo importante es conservar señales operacionales observables, como:
- entradas relevantes;
- documentos utilizados;
- herramientas llamadas;
- parámetros;
- resultados;
- errores;
- cambios de estado;
- decisiones de ruta;
- aprobaciones;
- salida final.
Los materiales de Google sobre calidad de agentes enfatizan precisamente la evaluación de la trayectoria completa: calidad del plan, uso de herramientas y manejo del contexto, además de la salida.
Logs, traces y métricas vuelven a aparecer
Esta pregunta condensa la página sobre observabilidad.
Logs: ¿qué ocurrió?
Traces: ¿cómo se conectan los eventos dentro de una ejecución?
Métricas: ¿cómo se comporta el sistema a escala?
La evaluación no se limita a un único caso.
Necesitamos saber también si aparecen patrones:
- herramienta que falla con frecuencia;
- exceso de escalamiento;
- rutas innecesariamente largas;
- omisiones recurrentes;
- incremento de costo;
- diferencias por tipo documental.
Evidencia sustantiva y operacional
La trayectoria debe permitir reconstruir tanto:
“¿por qué se llegó a esta conclusión?”
como:
“¿qué hizo el sistema para llegar hasta ella?”
En Derecho, ambas preguntas pueden ser importantes.
5. ¿En qué punto interviene una persona responsable?
La quinta pregunta evita una expresión demasiado vaga:
“Hay supervisión humana.”
La mera existencia de una persona alrededor del sistema no demuestra supervisión efectiva.
Necesitamos saber cuándo, para qué y con qué información interviene.
La persona puede intervenir antes
Por ejemplo:
- autorizar fuentes sensibles;
- definir el alcance;
- seleccionar el expediente;
- configurar el objetivo.
Puede intervenir durante
Por ejemplo:
- resolver una ambigüedad;
- aportar un documento;
- autorizar una acción externa;
- decidir una excepción;
- corregir una clasificación.
Puede intervenir al final
Por ejemplo:
- validar el producto;
- adoptar la decisión jurídica;
- aprobar una recomendación;
- firmar o enviar.
No toda intervención equivale a control
Supongamos que el agente produce 200 decisiones diarias y una persona debe aprobarlas en segundos sin acceder a documentos ni evidencia.
Formalmente existe un humano.
Materialmente puede existir sesgo de automatización o revisión meramente nominal.
Una intervención significativa exige al menos:
- oportunidad real de revisar;
- información suficiente;
- autoridad para rechazar o corregir;
- tiempo razonable;
- registro de la decisión cuando sea relevante.
La responsabilidad no se transfiere por interfaz
La ABA señala expresamente que el abogado no puede abdicar de funciones que requieren juicio profesional confiando exclusivamente en una herramienta generativa y que sigue siendo responsable por el trabajo realizado para el cliente. El CCBE enfatiza de manera semejante competencia, verificación cuando el caso lo exige, independencia y responsabilidad profesional.
Por tanto, una arquitectura agente debe mostrar dónde permanece el juicio humano necesario.
Una buena especificación dice:
“Antes de enviar cualquier comunicación externa, el agente se detiene y muestra borrador, destinatario, fundamento y documentos utilizados para que una persona autorizada apruebe o rechace.”
Eso es mucho más informativo que escribir simplemente:
“HITL habilitado.”
Las cinco preguntas aplicadas al caso conductor
Volvamos una última vez al contrato de proveedor de IA.
1. ¿Cuál es el objetivo?
Preparar una matriz de revisión trazable y una recomendación preliminar para la instancia competente.
No aprobar autónomamente.
2. ¿Qué contexto utiliza?
- contrato;
- DPA;
- SLA;
- anexos;
- políticas internas vigentes;
- playbook;
- estado del expediente.
Toda fuente debe ser identificable.
3. ¿Qué herramientas puede utilizar?
Puede:
- abrir;
- buscar;
- recuperar;
- comparar;
- registrar;
- preparar borradores.
No puede enviar comunicaciones ni aprobar excepciones sin intervención humana.
4. ¿Cómo se evalúa la trayectoria?
Se registra:
- qué documentos utilizó;
- qué herramienta ejecutó;
- qué criterios aplicó;
- qué hallazgos produjo;
- qué evidencia los respalda;
- qué errores ocurrieron;
- dónde escaló.
5. ¿Cuándo interviene una persona?
- cuando falta información crítica;
- ante desviaciones altas;
- antes de comunicaciones externas;
- para resolver excepciones;
- para adoptar la decisión final.
Ahora tenemos una descripción mucho más útil que:
“Tenemos un agente que revisa contratos.”
Tres niveles de respuesta posibles
Estas preguntas también sirven para distinguir grados de madurez.
Respuesta insuficiente
Objetivo: ayudar.
Contexto: todos nuestros documentos.
Herramientas: varias integraciones.
Evaluación: revisamos la respuesta.
Humano: siempre hay una persona.
La terminología suena correcta, pero casi nada es verificable.
Respuesta aceptable
Objetivo: detectar riesgos contractuales.
Contexto: contrato y política interna.
Herramientas: búsqueda documental y generación de matriz.
Evaluación: revisión de hallazgos y fuentes.
Humano: aprueba riesgos altos.
Ya existe una arquitectura reconocible, aunque faltan detalles.
Respuesta gobernable
Objetivo: completar la matriz de revisión definida para contratos SaaS de proveedores de IA y escalar toda desviación alta.
Contexto: documentos del expediente más versiones vigentes del playbook recuperadas desde repositorio autorizado; sin memoria entre clientes.
Herramientas: lectura del DMS y escritura únicamente en borrador de la matriz; envío externo deshabilitado.
Trayectoria: trace por expediente con documentos, búsquedas, herramientas, estados, evidencia y escalamiento.
Humano: intervención obligatoria ante ausencia de documentos críticos, desviaciones altas, toda excepción y decisión final.
La diferencia no está en utilizar más palabras técnicas.
Está en reducir zonas de autoridad y comportamiento implícitas.
Una prueba rápida para una demo o proveedor
Cuando alguien muestre un nuevo agente, no es necesario comenzar preguntando por temperatura, embeddings o framework.
Podemos comenzar con las cinco preguntas.
Si las respuestas son buenas, podremos profundizar técnicamente después.
Si no existen respuestas claras, el problema ya es visible.
Una conversación de evaluación podría seguir esta secuencia:
¿Qué resultado exacto produce?
¿Qué información puede utilizar para producirlo?
¿Qué acciones puede ejecutar fuera de la conversación?
¿Qué registro permite reconstruir cómo llegó hasta ahí?
¿Dónde se detiene para que una persona decida?
Las preguntas funcionan tanto para una demo como para una contratación, un proyecto interno o una revisión de riesgo.
Señales de alerta
No existe una respuesta única correcta, pero ciertas respuestas justifican mayor cautela.
“El agente decide todo automáticamente”
Pregunta inmediatamente qué decisiones incluye “todo” y cuáles producen efectos externos.
“Tiene acceso a toda la información de la empresa”
Pregunta por alcance, aislamiento, permisos y minimización.
“Puede utilizar cualquier herramienta que necesite”
Pregunta cómo se controla la selección y qué acciones requieren aprobación.
“Lo importante es que el resultado final sea bueno”
Pregunta cómo detectan trayectorias defectuosas, errores intermedios o uso indebido de herramientas.
“Siempre hay un humano supervisando”
Pregunta en qué punto, con qué evidencia y si puede realmente detener o revertir la acción.
Estas respuestas no demuestran por sí solas que el sistema sea incorrecto.
Indican dónde falta precisión.
De la pregunta técnica a la pregunta de gobierno
Al comienzo del recorrido podíamos preguntar:
“¿Qué puede hacer la IA?”
Después aprendimos a descomponer esa frase.
Un modelo genera o clasifica.
Un prompt instruye.
Una template reutiliza.
Una skill estabiliza una metodología.
Knowledge proporciona información.
RAG recupera lo pertinente.
Una tool permite obtener, calcular o actuar.
Un workflow organiza etapas.
Un playbook incorpora criterios y ramas.
Un agente puede seleccionar dinámicamente próximos pasos.
Pero el punto de llegada no es simplemente una arquitectura más compleja.
Es una pregunta distinta:
¿Qué capacidad queremos permitir, bajo qué contexto, mediante qué medios, con qué evidencia y bajo responsabilidad de quién?
Ésa es la transición de decidir a gobernar.
Lo que las cinco preguntas no hacen
No convierten automáticamente un agente en seguro.
No sustituyen:
- pruebas;
- evaluación empírica;
- seguridad;
- protección de datos;
- análisis contractual;
- supervisión profesional;
- monitoreo continuo.
Tampoco existe una arquitectura universalmente correcta.
Un agente de investigación puede necesitar amplia capacidad de lectura y ninguna capacidad de escritura.
Un agente administrativo puede necesitar modificar registros de bajo impacto.
Un agente de litigación puede requerir controles mucho más estrictos sobre fuentes, evidencia y revisión.
Las cinco preguntas proporcionan una estructura para descubrir qué controles necesita cada caso.
Qué debes recordar
Cuando alguien utilice la palabra agente, intenta resistir la tentación de comenzar por la etiqueta.
Pregunta primero:
1. Objetivo
¿Qué resultado exacto persigue y cuándo termina?
2. Contexto
¿Qué información utiliza, de dónde proviene y qué queda fuera?
3. Herramientas
¿Qué puede hacer realmente y cuáles de esas acciones están autorizadas?
4. Trayectoria
¿Podemos reconstruir y evaluar cómo llegó al resultado?
5. Persona
¿Dónde se detiene la autonomía y quién asume el juicio o la autorización correspondiente?
Estas preguntas permiten separar capacidad técnica de autoridad, forma de evidencia y automatización de autonomía.
Cierre de la sección: de “qué agente uso” a “qué capacidad quiero gobernar”
El recorrido comenzó con una diferencia pequeña pero decisiva.
Una IA puede responder una instrucción.
Un agente puede mantener un objetivo y seleccionar qué hacer a continuación.
Esa capacidad abre posibilidades útiles: investigar, recuperar información, utilizar herramientas, navegar procedimientos, planificar y coordinar componentes especializados.
También cambia el objeto de control.
Ya no basta revisar una respuesta.
Debemos gobernar:
- contexto;
- acciones;
- permisos;
- trayectoria;
- evidencia;
- memoria;
- costos;
- errores;
- intervención humana;
- criterios de término.
Por eso la pregunta final de esta sección no es:
“¿Qué agente debería usar?”
Es:
“¿Qué capacidad quiero delegar, qué parte debe seguir bajo control humano y qué evidencia necesito para demostrar que esa frontera se respetó?”
Ése es el criterio que permite pasar de experimentar con agentes a diseñar sistemas jurídicos que puedan ser comprendidos, supervisados y gobernados.