flowchart TD
A[Objetivo] --> B[Alcance]
B --> C[Criterios]
C --> D[Herramientas]
D --> E[Límites]
E --> F[Evidencia]
F --> G[Intervención humana]
G --> H[Criterio de cierre]
H --> I[Agente gobernable]
F -. permite evaluar .-> C
E -. restringe .-> D
G -. controla .-> D
H -. verifica cumplimiento de .-> A
Diseñar un agente jurídico
Una plantilla conceptual para traducir una tarea jurídica en un sistema agente gobernable: objetivo, alcance, criterios, herramientas, límites, evidencia, intervención humana y criterio de cierre.
En la página anterior llegamos a una conclusión deliberadamente prudente.
Hay tareas jurídicas en las que sí puede ser razonable considerar un agente: trabajo repetible, varias etapas, fuentes identificables, criterios parcialmente explicitables, revisión humana posible y una ganancia real de consistencia o trazabilidad.
Pero reconocer una buena candidata no equivale a haber diseñado el sistema.
Entre ambas cosas existe un salto importante.
Una organización puede identificar correctamente que la revisión de contratos de proveedores consume tiempo, repite patrones y exige coordinar información de varias fuentes. Aun así, puede construir un agente mal definido si comienza por elegir un modelo, una plataforma o una colección de herramientas antes de responder preguntas más básicas.
¿Qué resultado concreto debe producir? ¿Sobre qué documentos puede trabajar? ¿Qué cuenta como un buen resultado? ¿Qué acciones puede ejecutar? ¿Qué debe quedar fuera de su autoridad? ¿Qué evidencia debe conservar? ¿Cuándo debe intervenir una persona? ¿Cuándo debe detenerse?
Esta página organiza esas preguntas en una plantilla conceptual de diseño.
No necesitamos programar para utilizarla.
Idea central
Diseñar un agente jurídico no comienza preguntando qué modelo utilizar ni cuántas herramientas conectar.
Comienza delimitando qué capacidad queremos delegar y bajo qué condiciones puede ejercerse.
En este handbook utilizaremos ocho elementos:
objetivo · alcance · criterios · herramientas · límites · evidencia · intervención humana · criterio de cierre.
Si alguno permanece indefinido, una parte importante del comportamiento del sistema queda entregada a supuestos implícitos.
Del problema profesional al diseño del sistema
Retomemos el caso conductor:
“Llegó un contrato de proveedor de IA. ¿Puede aprobarse?”
La formulación parece una buena misión para un agente, pero todavía es demasiado amplia.
La palabra aprobarse mezcla varias operaciones distintas:
- leer documentos;
- identificar cláusulas;
- comparar con criterios internos;
- detectar información faltante;
- estimar riesgos;
- proponer cambios;
- coordinar revisiones;
- adoptar una decisión institucional.
No todas esas operaciones tienen por qué ser delegadas al mismo sistema.
Y, en particular, que un sistema pueda preparar antecedentes para una decisión no significa que deba adoptar la decisión final.
Por eso el primer ejercicio de diseño consiste en desagregar el encargo.
Podemos reformularlo así:
Preparar una revisión interna trazable de un contrato de proveedor de IA, identificando hallazgos relevantes, evidencia, desviaciones frente a criterios autorizados, información faltante y puntos que requieren decisión humana.
La nueva formulación hace algo importante.
Transforma una misión vaga —“aprobar”— en un resultado operativo que puede ser evaluado.
A partir de aquí podemos diseñar el sistema.
1. Objetivo: ¿qué resultado debe producir?
El objetivo expresa el estado que queremos alcanzar al terminar la ejecución.
Debe ser suficientemente concreto para que podamos responder después:
“¿Se cumplió?”
Un objetivo débil sería:
Ayudar con contratos de tecnología.
No sabemos qué significa éxito.
Otro objetivo débil sería:
Revisar muy bien contratos de proveedores.
Sabemos algo más, pero seguimos sin poder determinar cuándo la tarea está completa.
Una formulación más útil podría ser:
Preparar una matriz de revisión que identifique para cada materia relevante: cláusula o documento de origen, hallazgo, evidencia, criterio aplicado, nivel de desviación, información faltante y necesidad de escalamiento.
Ahora el objetivo describe un producto verificable.
Objetivo no es autoridad
Aquí reaparece una distinción que debe permanecer transversal a toda la arquitectura:
producir una recomendación no es lo mismo que adoptar una decisión.
Podemos diseñar un agente cuyo objetivo sea:
Preparar una recomendación interna de aprobación, aprobación condicionada, escalamiento o rechazo.
Eso no significa necesariamente que el agente tenga autoridad para cambiar el estado del contrato a “aprobado”.
La recomendación puede constituir una entrada para una decisión humana o institucional posterior.
Una prueba sencilla para el objetivo
Pregúntate:
Si dos personas observaran el resultado final, ¿podrían determinar razonablemente si el agente completó la misión?
Si la respuesta es no, el objetivo probablemente sigue siendo demasiado vago.
2. Alcance: ¿sobre qué documentos, fuentes y asuntos trabaja?
Una vez definido el resultado aparece la siguiente pregunta:
¿Sobre qué universo puede operar el agente?
El alcance tiene al menos tres dimensiones:
alcance documental, alcance material y alcance operacional.
Alcance documental
Debemos identificar qué fuentes puede utilizar.
Por ejemplo:
Fuentes autorizadas
- contrato principal;
- anexos incorporados al expediente;
- DPA;
- SLA;
- cuestionario de seguridad;
- política contractual interna vigente;
- playbook aprobado;
- repositorio corporativo autorizado.También puede resultar útil declarar qué queda fuera:
Fuentes no autorizadas sin escalamiento
- correos de otros asuntos;
- repositorios de otros clientes;
- borradores sin identificar;
- políticas históricas sustituidas;
- fuentes web abiertas utilizadas como criterio interno.El diseño no debería asumir que “más información” siempre mejora el sistema.
En Derecho, utilizar una fuente equivocada puede ser peor que reconocer que falta información.
Alcance material
También debemos definir qué materias revisa.
Por ejemplo:
- datos y confidencialidad;
- propiedad intelectual;
- seguridad;
- niveles de servicio;
- subcontratación;
- responsabilidad;
- terminación;
- continuidad y salida.
Si la misión excluye análisis tributario, laboral o regulatorio sectorial, conviene hacerlo visible.
Esto evita que una salida fluida produzca la impresión de exhaustividad cuando el sistema sólo cubre una parte del problema.
Alcance operacional
Finalmente debemos determinar qué clase de actuación forma parte de la misión.
Por ejemplo:
Puede leer, buscar, extraer, comparar, clasificar y preparar borradores.
Pero:
No puede enviar comunicaciones, aceptar excepciones ni cambiar el estado contractual final.
Esta tercera dimensión conecta el alcance con los permisos que estudiaremos dentro de las herramientas y límites.
“Revisar el contrato” no define el universo de revisión
Un contrato puede remitir a políticas, anexos, sitios web, términos incorporados por referencia o documentos internos de la organización.
Si el diseño no define el universo documental, el agente puede producir una respuesta completa respecto de un expediente incompleto.
3. Criterios: ¿cómo sabe que va bien?
Un agente orientado a objetivos necesita alguna forma de distinguir entre avance útil y mera actividad.
Los criterios cumplen esa función.
No deben confundirse con la totalidad del razonamiento jurídico.
No todo juicio profesional puede convertirse en una regla precisa.
Pero muchas partes del trabajo sí admiten criterios suficientemente explícitos para orientar y evaluar.
Criterios de análisis
Podemos definir qué debe comprobar.
Por ejemplo:
Una cláusula de uso de datos debe analizarse respecto de finalidad, categorías de datos, usos secundarios, retención, subencargados y derechos posteriores al término.
Criterios de evidencia
Podemos exigir que cada hallazgo relevante tenga respaldo localizable.
Por ejemplo:
Ninguna desviación contractual puede presentarse como confirmada si no se identifica el texto o dato que la sustenta.
Criterios de clasificación
Podemos definir qué significa una categoría.
Por ejemplo:
ALTO
La desviación puede bloquear la aprobación o requiere decisión de una persona con autoridad especial.
MEDIO
Debe aclararse o negociarse, pero normalmente no bloquea por sí sola.
BAJO
Debe registrarse, aunque su impacto esperado sea limitado.
Criterios de aceptación
Finalmente podemos definir qué necesita cumplir el producto final.
Por ejemplo:
- todas las materias obligatorias revisadas;
- todas las fuentes requeridas identificadas;
- hallazgos con evidencia;
- incertidumbres explícitas;
- puntos críticos escalados;
- formato completo.
Estos criterios permiten evaluar la ejecución sin suponer que la calidad se reduce a una impresión general del texto.
4. Herramientas: ¿qué puede leer, buscar o ejecutar?
Hasta aquí todavía podríamos tener un sistema que únicamente genera texto a partir de documentos proporcionados.
Un agente adquiere mayor capacidad cuando puede utilizar herramientas.
La pregunta de diseño no es simplemente:
“¿Qué herramientas existen?”
Es:
“¿Qué medios necesita realmente para alcanzar el objetivo y qué permisos debe tener sobre cada uno?”
Para nuestro caso, una tabla inicial podría ser:
| Herramienta | Finalidad | Operación | Efecto |
|---|---|---|---|
| Abrir documento | leer contrato o anexo | lectura | no modifica |
| Buscar expediente | localizar documentos faltantes | búsqueda | no modifica |
| Recuperar política | consultar criterio interno | lectura | no modifica |
| Comparar versiones | detectar diferencias | cálculo/análisis | no modifica |
| Completar matriz | registrar hallazgos | escritura interna | modifica borrador |
| Crear solicitud | preparar requerimiento | borrador | no comunica por sí solo |
| Enviar solicitud | contactar proveedor | comunicación externa | produce efecto |
La última columna cambia radicalmente el problema.
Las herramientas no sólo agregan capacidad. También agregan superficie de acción.
Menos herramientas puede ser mejor
Un error frecuente consiste en equipar al agente con toda herramienta disponible.
Pero cada herramienta adicional:
- amplía las decisiones posibles;
- puede introducir datos adicionales;
- agrega permisos;
- crea nuevos modos de falla;
- dificulta evaluación y observabilidad.
Si un agente sólo necesita buscar contratos y consultar una política, no existe una ventaja evidente en darle acceso a correo, CRM y sistemas financieros “por si acaso”.
Definir herramientas por función
Para un equipo jurídico resulta útil describirlas primero en lenguaje funcional:
“recuperar el DPA del expediente”
antes que en lenguaje de implementación:
“llamar al endpoint
/documents/searchcon estos parámetros”.
La implementación será necesaria al construir el sistema, pero la función permite discutir autoridad y riesgo sin exigir que todas las personas del equipo sean desarrolladoras.
5. Límites: ¿qué no puede hacer solo?
Las herramientas describen capacidad.
Los límites describen la frontera de actuación.
Esta separación es esencial.
Un agente puede tener técnicamente acceso a una herramienta y, sin embargo, no estar autorizado a utilizarla en cualquier momento.
Podemos distinguir tres clases de límites.
Límites de información
Por ejemplo:
- no acceder a expedientes no vinculados al asunto;
- no mezclar información entre clientes;
- no utilizar fuentes no autorizadas como fundamento final;
- no persistir determinados datos fuera de la sesión.
Límites de acción
Por ejemplo:
- no enviar comunicaciones externas sin aprobación;
- no modificar estados finales;
- no aceptar términos;
- no eliminar registros;
- no conceder acceso a terceros.
Límites de decisión
Por ejemplo:
- no resolver excepciones de alto impacto;
- no adoptar juicio profesional final;
- no declarar “aprobado” un caso con información crítica faltante;
- no superar umbrales de riesgo sin escalamiento.
Un límite útil debe poder hacerse efectivo
Una frase como:
“No hagas nada peligroso.”
es demasiado indeterminada.
Una regla como:
“La herramienta de envío externo requiere aprobación humana antes de ejecutarse”
es mucho más gobernable porque puede reflejarse tanto en instrucciones como en controles de aplicación.
6. Evidencia: ¿qué debe citar o registrar?
En tareas jurídicas no basta con obtener una conclusión.
Necesitamos saber qué la sostiene.
La evidencia cumple dos funciones diferentes.
Primero, permite verificar el contenido.
Segundo, permite reconstruir la trayectoria.
Evidencia sustantiva
Para cada hallazgo podemos exigir:
Documento
Contrato principal
Ubicación
Cláusula 12.3
Texto relevante
[fragmento necesario]
Criterio utilizado
Política interna de contratación, sección aplicable
Evaluación
Desviación frente al estándar
Información faltante
Confirmar si el anexo comercial modifica el capAsí separamos:
texto encontrado
criterio aplicado
inferencia o evaluación
incertidumbre
Evidencia operacional
También puede ser necesario registrar:
- qué documentos se abrieron;
- qué búsquedas se ejecutaron;
- qué herramienta se utilizó;
- qué versión del criterio estaba vigente;
- qué error ocurrió;
- qué aprobación humana se recibió;
- cuándo se cambió de ruta.
Esto conecta diseño con observabilidad.
Un agente jurídicamente útil no debería ser una máquina que produce únicamente un documento final imposible de reconstruir.
Registrar no significa conservar todo
La evidencia debe diseñarse junto con confidencialidad, seguridad y retención.
No existe una regla según la cual gobernanza implique almacenar indiscriminadamente cada fragmento, cada prompt y cada documento para siempre.
La pregunta correcta es:
¿Qué evidencia necesitamos conservar para verificar, corregir y auditar razonablemente la operación, y durante cuánto tiempo?
7. Intervención humana: ¿cuándo pide autorización?
Decir simplemente “habrá human-in-the-loop” no resuelve nada.
Necesitamos identificar eventos concretos que provocan intervención.
La intervención humana puede cumplir al menos cuatro funciones.
Aclarar
El agente no dispone de información suficiente.
Ejemplo:
El contrato menciona un anexo de seguridad que no está en el expediente.
La persona puede aportar el documento o decidir cómo proceder.
Autorizar
La siguiente acción supera el nivel de permiso automático.
Ejemplo:
El agente preparó una solicitud al proveedor y necesita autorización antes de enviarla.
Resolver una excepción
El caso no encaja razonablemente en los criterios disponibles.
Ejemplo:
Existe una cláusula inusual de propiedad intelectual sin precedente en el playbook.
Adoptar una decisión profesional o institucional
El sistema ya preparó la información necesaria, pero el juicio final pertenece a una persona.
Ejemplo:
Aprobar una excepción contractual material.
La documentación de Google sobre agentes utiliza precisamente el patrón de human-in-the-loop para detener la ejecución antes de acciones significativas y solicitar aprobación humana. En práctica jurídica esta pausa adquiere una dimensión adicional: puede preservar no sólo seguridad técnica, sino también distribución adecuada de autoridad y responsabilidad.
Diseñar la intervención para que sea real
La persona debe recibir suficiente información para ejercer control.
Un mal human gate sería:
“El agente recomienda continuar. ¿Aprobar? Sí / No.”
Un control mucho más útil mostraría:
- acción propuesta;
- motivo;
- evidencia;
- riesgo;
- efecto esperado;
- posibilidad de reversión;
- alternativas.
La revisión humana deja de ser ceremonial y se vuelve informada.
8. Criterio de cierre: ¿cuándo termina?
Un sistema que mantiene un objetivo necesita una condición de término.
Sin ella, puede continuar buscando, revisando y refinando indefinidamente o, en el extremo contrario, detenerse demasiado pronto.
Podemos distinguir varios cierres válidos.
Cierre por cumplimiento
El objetivo fue alcanzado.
Por ejemplo:
Todas las materias obligatorias tienen estado resuelto, no aplicable o escalado; los hallazgos materiales contienen evidencia y no existen documentos críticos pendientes sin registrar.
Cierre por bloqueo
No puede continuar de manera válida.
Por ejemplo:
Falta el DPA y no existe una fuente autorizada para recuperarlo.
El cierre correcto puede ser:
expediente incompleto — requiere antecedente.
Cierre por escalamiento
Se alcanzó un punto que debe resolver una persona.
La ejecución se detiene hasta recibir una decisión.
Cierre por límite operacional
Puede existir un máximo de iteraciones, costo, tiempo o intentos.
Esto evita que un agente quede atrapado en ciclos improductivos.
Saber detenerse es parte de hacer bien la tarea
En un entorno profesional, “no puedo concluir todavía” puede ser una salida correcta.
Un agente gobernable debe distinguir entre:
terminar porque completó el trabajo
y detenerse porque continuar sería injustificado.
Cómo se conectan los ocho elementos
Los ocho componentes no son casillas independientes.
Se limitan entre sí.
El objetivo determina qué información necesitamos.
El alcance delimita dónde puede buscarse.
Los criterios permiten evaluar avance.
Las herramientas proporcionan medios.
Los límites restringen su utilización.
La evidencia permite verificar lo realizado.
La intervención humana absorbe decisiones o acciones que no deben delegarse.
El criterio de cierre determina cuándo terminar o escalar.
Podemos representarlo así:
El diagrama no describe una secuencia técnica obligatoria.
Describe dependencias de diseño.
Un ejemplo completo: agente para revisión de un proveedor de IA
Podemos reunir la plantilla en una sola ficha conceptual.
Objetivo
Preparar una revisión interna trazable del contrato y sus anexos para que una persona autorizada pueda decidir entre:
- aprobar;
- aprobar con condiciones;
- escalar;
- no continuar.
Alcance
Fuentes: contrato, DPA, SLA, anexos, política contractual interna, playbook y documentos del expediente.
Materias: datos, confidencialidad, PI, seguridad, servicio, cambios, subcontratación, responsabilidad, terminación y continuidad.
Exclusiones: análisis tributario especializado, decisión comercial final y aceptación de excepciones.
Criterios
Cada materia debe quedar:
- revisada;
- no aplicable;
- pendiente por información;
- escalada.
Cada hallazgo material debe contener evidencia y criterio aplicado.
Herramientas
Puede:
- abrir documentos;
- buscar anexos;
- recuperar políticas;
- comparar versiones;
- completar la matriz;
- preparar preguntas.
Límites
No puede:
- enviar mensajes externos;
- modificar el estado final del contrato;
- aceptar excepciones;
- utilizar fuentes no autorizadas como fundamento definitivo;
- inventar antecedentes faltantes.
Evidencia
Debe registrar:
- documento y ubicación;
- fragmento relevante;
- criterio;
- evaluación;
- información faltante;
- herramientas utilizadas;
- escalamiento y aprobación.
Intervención humana
Debe detenerse cuando:
- falta un documento crítico;
- existe contradicción entre fuentes;
- aparece una desviación alta;
- se propone una comunicación externa;
- se requiere aceptar una excepción;
- corresponde la decisión final.
Cierre
Puede finalizar la preparación del expediente cuando:
- no existen categorías obligatorias sin estado;
- los hallazgos materiales tienen evidencia;
- las incertidumbres están identificadas;
- los puntos críticos han sido escalados;
- ninguna acción pendiente excede sus permisos.
Observa lo que no hemos hecho.
No hemos elegido todavía una marca, modelo, framework ni proveedor.
Y, sin embargo, ya conocemos una parte sustancial de la arquitectura que necesitamos.
Eso demuestra por qué el diseño funcional debe anteceder a la selección tecnológica.
La ficha mínima de diseño
Antes de construir un agente jurídico, debería ser posible completar algo parecido a esto:
| Elemento | Pregunta | Respuesta esperada |
|---|---|---|
| Objetivo | ¿Qué resultado debe producir? | Producto o estado verificable |
| Alcance | ¿Sobre qué trabaja? | Fuentes, materias y exclusiones |
| Criterios | ¿Cómo sabe que va bien? | Reglas de análisis y aceptación |
| Herramientas | ¿Qué puede utilizar? | Capacidades necesarias y permisos |
| Límites | ¿Qué no puede hacer solo? | Prohibiciones y umbrales |
| Evidencia | ¿Qué debe citar o registrar? | Evidencia sustantiva y operacional |
| Humano | ¿Cuándo debe intervenir una persona? | Eventos de aclaración, autorización o decisión |
| Cierre | ¿Cuándo termina? | Cumplimiento, bloqueo, escalamiento o límite |
Si una de estas filas sólo puede completarse con expresiones vagas —“cuando sea necesario”, “si parece riesgoso”, “usar fuentes confiables”— todavía queda trabajo de diseño.
Qué puede salir mal
Empezar por la tecnología
Elegir primero el modelo o la plataforma puede llevar a redefinir el problema para acomodarlo a la herramienta.
Diseñar un objetivo que ya contiene una decisión no delegable
“Agente que aprueba contratos” puede esconder una transferencia de autoridad nunca discutida.
Definir herramientas sin límites
Una lista de integraciones no equivale a una política de permisos.
Definir límites sólo mediante lenguaje
Las instrucciones ayudan, pero ciertas prohibiciones requieren controles técnicos u organizacionales más fuertes.
Pedir evidencia sin diseñar su procedencia
“Cita fuentes” es insuficiente si el sistema no sabe qué repositorios son autorizados o cómo conservar la relación entre hallazgo y documento.
Incorporar una persona sólo al final
Si el sistema ya ejecutó una acción irreversible, la aprobación posterior no es control previo.
No especificar cierre
El agente puede continuar iterando o entregar prematuramente una conclusión incompleta.
Por qué importa especialmente en el trabajo jurídico
Las orientaciones profesionales sobre IA generativa convergen en una idea básica: los abogados pueden apoyarse en estas herramientas, pero siguen necesitando comprender sus capacidades y limitaciones, proteger información, verificar resultados cuando corresponda y conservar el juicio profesional que no puede delegarse sin más.
La ABA señala que la intensidad de la revisión puede variar según la herramienta y la tarea, pero no permite que el abogado abdique de las responsabilidades que requieren juicio profesional. El CCBE insiste igualmente en competencia tecnológica, confidencialidad, verificación contextual y responsabilidad por el trabajo utilizado.
La plantilla de esta página no reemplaza esas obligaciones.
Las traduce a preguntas de arquitectura.
¿Dónde aparece el juicio humano?
¿Qué información puede entrar al sistema?
¿Qué acciones están autorizadas?
¿Qué evidencia permite revisar el resultado?
¿Qué capacidad estamos delegando realmente?
Qué debes recordar
Diseñar un agente jurídico significa transformar una tarea profesional en una arquitectura delimitada.
No basta con escribir un buen prompt.
No basta con conectar herramientas.
No basta con agregar una aprobación humana al final.
Debemos definir, como mínimo:
qué resultado persigue, sobre qué puede trabajar, qué criterios aplica, qué medios tiene, qué no puede hacer, qué evidencia debe dejar, cuándo interviene una persona y cuándo termina.
La calidad de estas respuestas determina una parte importante de la gobernabilidad del sistema antes de que exista una sola línea de código.
El problema que todavía queda abierto
La plantilla de ocho elementos es suficientemente completa para diseñar.
Pero no siempre necesitamos recorrerla entera para evaluar rápidamente un agente existente, una demo, una propuesta de proveedor o una idea interna.
Podemos comprimirla en cinco preguntas de control.
Esas cinco preguntas serán el cierre de esta sección: un test breve para determinar si entendemos realmente qué capacidad se está delegando y si existe suficiente información para gobernarla.