flowchart LR
A["Objetivo"] --> B["Observar estado"]
B --> C["Seleccionar acción"]
C --> D["Ejecutar"]
D --> E["Observar resultado"]
E --> F{"¿Objetivo cumplido?"}
F -- "No" --> B
F -- "Necesita ayuda" --> G["Escalar"]
F -- "Sí" --> H["Cerrar"]
Idea final: la autonomía como arquitectura
Por qué la autonomía útil no proviene sólo del modelo, sino de la combinación gobernada de capacidades, conocimiento, herramientas, procedimientos, permisos y controles.
Llegamos a la última pregunta conceptual del recorrido.
Después de estudiar prompts, templates, skills, conocimiento, RAG, herramientas, integraciones, workflows, playbooks y agentes, podemos sentir que hemos avanzado desde sistemas “simples” hacia sistemas “autónomos”.
La descripción es tentadora, pero necesita precisión.
Un modelo puede ser extraordinariamente capaz y seguir esperando una instrucción humana para cada tarea.
Una aplicación puede utilizar un modelo menos sofisticado y, sin embargo, ejecutar durante minutos un proceso completo porque dispone de herramientas, estado, reglas, acceso a información y capacidad para seleccionar próximos pasos.
La diferencia no se explica únicamente por el modelo.
Se explica por la arquitectura.
Ésa es la idea que debe quedar al final del handbook conceptual:
Idea final
La autonomía no proviene sólo del modelo.
Proviene de combinar, de manera gobernada:
capacidades + conocimiento + herramientas + procedimientos + permisos + controles.
El modelo aporta una parte de la capacidad de generar, interpretar y seleccionar.
El sistema completo determina qué información recibe, qué acciones puede ejecutar, qué rutas puede seguir, cuándo debe detenerse y quién conserva autoridad sobre las decisiones.
De “qué tan inteligente es” a “qué puede hacer sin una nueva instrucción”
En conversaciones cotidianas solemos medir la autonomía de manera antropomórfica:
“Esta IA piensa sola.”
“Este agente trabaja por su cuenta.”
Para analizar sistemas reales, conviene utilizar preguntas más concretas.
Por ejemplo:
- ¿puede mantener un objetivo durante varios pasos?;
- ¿puede observar resultados intermedios?;
- ¿puede decidir qué herramienta utilizar?;
- ¿puede recuperar nueva información?;
- ¿puede cambiar de ruta?;
- ¿puede ejecutar acciones?;
- ¿puede hacerlo sin aprobación?;
- ¿puede detectar que no sabe?;
- ¿puede detenerse?;
- ¿puede pedir ayuda?;
- ¿puede registrar lo ocurrido?
Estas preguntas convierten una categoría vaga en propiedades observables.
La autonomía no es una propiedad binaria
Un sistema no necesita ser simplemente:
autónomo
o
no autónomoPuede tener distintos grados de autonomía en distintas dimensiones.
Consideremos una aplicación contractual.
Información
Podría consultar automáticamente documentos internos.
Metodología
Podría seleccionar una skill sin intervención humana.
Proceso
Podría pasar automáticamente de extracción a clasificación.
Comunicación
Podría preparar un correo, pero no enviarlo.
Decisión
Podría recomendar aprobación, pero no aprobar.
Sistemas
Podría leer registros, pero no modificarlos.
La arquitectura sería simultáneamente autónoma en algunas dimensiones y restringida en otras.
Por eso resulta más útil hablar de distribución de autonomía.
Una matriz de autonomía
Podemos representarla así:
| Función | ¿Puede ejecutarla? | ¿Puede seleccionarla? | ¿Requiere aprobación? |
|---|---|---|---|
| Leer contrato | Sí | Sí | No |
| Buscar política | Sí | Sí | No |
| Ejecutar skill de privacidad | Sí | Sí | No |
| Preparar matriz | Sí | Sí | No |
| Crear borrador de correo | Sí | Sí | Revisión |
| Enviar correo | Sí técnicamente | No | Sí |
| Cambiar estado del proveedor | Sí técnicamente | No | Sí |
| Aprobar contrato | No como decisión autónoma | No | Autoridad humana |
La tabla muestra una distinción que atraviesa todo el curso:
CAPACIDAD
≠
PERMISO
≠
DECISIÓN
≠
RESPONSABILIDADQue una integración permita técnicamente una acción no significa que el sistema deba recibir autorización para ejecutarla.
Capacidad técnica
La primera pregunta es:
¿Qué puede hacer el sistema?
Puede generar texto.
Puede buscar.
Puede leer archivos.
Puede ejecutar una función.
Puede actualizar un registro.
Puede enviar un mensaje.
Esta dimensión describe posibilidad técnica.
No contiene todavía una decisión normativa u organizacional sobre si la acción debe estar permitida.
Permiso
La segunda pregunta es:
¿Qué está autorizado a hacer?
Podemos permitir:
leerpero prohibir:
eliminarPodemos permitir:
preparar borradorpero exigir confirmación para:
enviarEl permiso convierte una capacidad general en un espacio operacional limitado.
Ésta es una de las razones por las que los controles técnicos importan más que una instrucción del tipo:
sé prudenteSi una acción debe ser imposible, conviene que el sistema no tenga permiso para ejecutarla.
Decisión
La tercera pregunta es:
¿Qué acciones permitidas puede seleccionar el sistema sin una instrucción humana nueva?
Aquí aparece la agencia.
Podemos permitir que el sistema elija entre:
buscar contrato
buscar política
ejecutar skill A
ejecutar skill B
pedir información
escalarPero podemos excluir de ese espacio:
aprobar contrato
enviar comunicación externa
modificar permisos
eliminar expedienteLa autonomía se diseña entonces como un conjunto de decisiones delegadas.
No como una transferencia general de control.
Responsabilidad
La cuarta pregunta es:
¿Quién responde por el resultado?
La arquitectura no crea una nueva autoridad profesional.
El hecho de que el sistema pueda seleccionar una ruta no significa que asuma responsabilidad por:
- asesoría jurídica;
- confidencialidad;
- cumplimiento;
- representación;
- aprobación institucional.
Las guías profesionales de la ABA y del CCBE convergen en una idea relevante para este punto: el uso de herramientas de IA no elimina las obligaciones profesionales del abogado. La persona debe comprender razonablemente las capacidades y limitaciones de la tecnología, proteger información y verificar los outputs cuando la tarea lo requiere.
El sistema puede participar en el proceso.
La responsabilidad profesional no desaparece dentro de la arquitectura.
Un agente no es “más modelo”
Esta distinción permite corregir otra intuición.
Supongamos dos sistemas.
Sistema A
Utiliza un modelo muy potente.
Recibe un prompt.
Genera una respuesta.
Termina.
Sistema B
Utiliza un modelo suficientemente capaz.
Mantiene estado.
Tiene acceso a documentos.
Puede utilizar tools.
Sigue límites de un workflow.
Aplica criterios de un playbook.
Puede seleccionar próximos pasos.
Puede pedir aprobación.
Registra la trayectoria.
¿Cuál es más autónomo operacionalmente?
Probablemente el segundo, aunque su modelo no sea el más potente.
La razón es que la autonomía surge de la combinación entre:
modelo
+
contexto
+
herramientas
+
orquestación
+
estado
+
criterios
+
permisos
+
controlesGoogle describe precisamente un agente como una combinación de modelos, tools, orquestación y servicios de ejecución dentro de un ciclo orientado a un objetivo. Las clases amplían pedagógicamente esa arquitectura mostrando que, para trabajo jurídico, también importa separar metodología, conocimiento, workflow, playbook, permisos y evidencia.
Autonomía como trayectoria
Existe una segunda forma de comprender la idea.
Un chatbot simple produce principalmente una salida:
entrada → respuestaUn sistema agentic puede producir una trayectoria:
La autonomía reside en parte en la capacidad de mantener esa trayectoria sin pedir al usuario una nueva instrucción en cada microetapa.
Pero precisamente por eso debemos poder reconstruirla.
Una respuesta final puede ser correcta por accidente.
Una trayectoria observable permite preguntar:
- qué vio;
- qué buscó;
- qué utilizó;
- qué decidió;
- qué ejecutó;
- qué evidencia incorporó;
- cuándo pidió aprobación.
La gobernanza del agente es gobernanza de la trayectoria.
Más autonomía exige más gobierno
Las clases formulan esta relación de manera directa:
más autonomía exige más gobierno: permisos, evidencia, límites y supervisión.
Podemos representarla así:
flowchart LR
A["Más decisiones delegadas"] --> B["Más posibles trayectorias"]
B --> C["Mayor necesidad de límites"]
C --> D["Más observabilidad"]
D --> E["Más criterios de revisión"]
La conclusión no es que debamos evitar agentes.
Es que la arquitectura de control debe crecer al mismo tiempo que el espacio de decisión.
Gobernanza no es una capa que se agrega al final
También conviene corregir una imagen.
Podríamos imaginar:
primero construimos el agente
después agregamos gobernanzaEn sistemas jurídicos esa secuencia es deficiente.
La gobernanza debe aparecer durante el diseño.
En prompts
Definimos alcance y restricciones.
En skills
Definimos metodología, entrada, salida y límites.
En knowledge
Definimos fuentes autorizadas y vigencia.
En RAG
Definimos qué puede recuperarse y cómo se muestra la procedencia.
En tools
Definimos permisos y validaciones.
En workflows
Definimos estados y puntos de control.
En playbooks
Definimos criterios, excepciones y escalamiento.
En agents
Definimos espacio de acciones, criterios de término y supervisión.
La gobernanza no rodea externamente la arquitectura.
La arquitectura incorpora gobierno.
La mejor arquitectura no es la más autónoma
Esta idea merece formularse de manera explícita.
Una herramienta puede ser técnicamente capaz de automatizar una decisión y aun así ser mejor diseño mantener esa decisión bajo control humano.
Pensemos en:
aprobar proveedor
presentar escrito
enviar oferta contractual
eliminar documentación
modificar permisosNo necesitamos negar capacidad técnica para decidir que ciertas acciones deben conservar umbrales de autorización mayores.
La pregunta correcta no es:
¿podemos automatizarlo?
Sino:
¿qué parte conviene automatizar y qué parte conviene reservar, considerando impacto, reversibilidad, evidencia y responsabilidad?
Workflow y agente pueden convivir
Otra falsa dicotomía consiste en pensar que una organización debe elegir entre:
workflow rígido
o
agente flexibleLas clases proponen una idea mejor:
los mejores agentes jurídicos viven dentro de workflows gobernados.
Por ejemplo:
flowchart TB
A["Workflow institucional"] --> B["Etapa: revisión"]
B --> C["Agente puede elegir<br/>skills, búsquedas y tools"]
C --> D{"¿Hallazgo crítico?"}
D -- "No" --> E["Volver al workflow"]
D -- "Sí" --> F["Aprobación humana obligatoria"]
F --> E
El workflow fija las fronteras institucionales.
El agente aporta flexibilidad dentro de una etapa.
Esta combinación suele ser más útil que intentar reemplazar todo el proceso por una única entidad autónoma.
Automatización y autonomía no son lo mismo
También debemos conservar esta distinción final.
Un proceso puede estar altamente automatizado y tener muy poca autonomía.
Ejemplo:
cada vez que llega un contrato:
extraer texto;
aplicar regla;
guardar resultado.Todo ocurre automáticamente.
Pero la ruta está predeterminada.
Un agente puede tener menos volumen de automatización y más autonomía si debe seleccionar entre varias acciones según el contexto.
Por eso:
AUTOMATIZACIÓN
¿cuánto trabajo ocurre sin intervención manual?
AUTONOMÍA
¿cuánto puede seleccionar el sistema sobre su propia trayectoria?Son dimensiones diferentes.
Un poco más de detalle técnico: la autonomía necesita estado
Para seleccionar el próximo paso, el sistema necesita conocer algo sobre lo que ya ocurrió.
Por eso el state resulta importante.
Podemos imaginarlo como un registro operacional de la tarea actual:
objetivo:
revisar proveedor
documentos:
contrato recibido
DPA faltante
skills ejecutadas:
contratos generales
privacidad pendiente
hallazgos:
3
aprobaciones:
ninguna
próximo límite:
no cerrar hasta obtener DPAEl estado permite que la siguiente operación dependa de la trayectoria anterior.
No es necesariamente memoria de largo plazo.
Es información necesaria para continuar la tarea actual.
Esta distinción será útil en los casos prácticos cuando diseñemos agentes concretos.
La autonomía también necesita criterios de término
Un sistema que sabe continuar pero no sabe terminar es un mal sistema.
Debe existir alguna definición de:
- objetivo cumplido;
- información insuficiente;
- máximo de intentos;
- acción no autorizada;
- necesidad de escalamiento;
- error irrecuperable.
Por ejemplo:
TERMINAR CUANDO
todos los documentos obligatorios fueron revisados
y los hallazgos tienen evidencia.
ABSTENERSE CUANDO
falta una fuente necesaria para concluir.
ESCALAR CUANDO
existe riesgo alto o una acción exige aprobación.
DETENERSE CUANDO
la tool falla repetidamente o el resultado es inconsistente.La autonomía útil incluye la capacidad de no actuar.
El caso conductor, ahora como sistema gobernado
Volvamos por última vez al contrato de proveedor de IA.
Una arquitectura madura podría funcionar así:
OBJETIVO
preparar decisión de aprobación.
PROMPT
define alcance y perspectiva.
SKILLS
ejecutan revisiones especializadas.
KNOWLEDGE
contiene políticas y precedentes.
RAG
recupera lo pertinente.
TOOLS
leen sistemas y preparan artefactos.
WORKFLOW
define etapas institucionales.
PLAYBOOK
define criterios y escalamiento.
AGENT
selecciona próximos pasos permitidos.
PERMISOS
limitan qué acciones puede ejecutar.
LOGS Y TRACES
registran trayectoria.
HUMANO
conserva autoridad sobre decisiones críticas.En este punto podemos entender por qué la frase:
“el agente revisó y aprobó el contrato”
es demasiado imprecisa.
Una descripción mejor sería:
el sistema reunió antecedentes, ejecutó metodologías de revisión, recuperó criterios, preparó una matriz y recomendó una ruta; las acciones externas y la aprobación final permanecieron sujetas a permisos y decisión humana.
La arquitectura permite decir exactamente qué fue delegado.
La pregunta final para cualquier sistema de IA
Al terminar este recorrido, ante una aplicación de IA ya no deberíamos preguntar solamente:
¿qué modelo utiliza?
Tampoco basta:
¿tiene RAG?
O:
¿es agentic?
Las preguntas útiles son más estructurales:
¿Qué objetivo persigue?
¿Qué instrucciones utiliza?
¿Qué metodología ejecuta?
¿Qué información puede consultar?
¿Qué evidencia recupera?
¿Qué herramientas puede usar?
¿Qué permisos tienen esas herramientas?
¿Qué estados y workflows gobiernan el proceso?
¿Qué criterios activan ramas y escalamiento?
¿Qué decisiones puede seleccionar dinámicamente?
¿Qué acciones requieren aprobación?
¿Qué queda registrado?
¿Cuándo debe detenerse?
¿Quién responde por el resultado?Si podemos responder esas preguntas, estamos analizando un sistema.
Si no podemos responderlas, probablemente seguimos mirando una etiqueta comercial.
Qué debes recordar
La idea final del recorrido puede condensarse así:
MODELO
aporta capacidad generativa y de selección probable
SISTEMA
organiza contexto, herramientas, estado y reglas
ARQUITECTURA
distribuye metodología, información, proceso y decisiones
GOBERNANZA
limita permisos, exige evidencia y define supervisiónLa autonomía operacional emerge de la combinación.
No pertenece exclusivamente al modelo.
Y no debe medirse por cuánto “dejamos hacer” a la IA, sino por qué decisiones delegamos, con qué información, dentro de qué límites y con qué posibilidad de reconstrucción y revisión.
La frase que debe quedar al final
Una buena arquitectura de IA jurídica no maximiza autonomía.
Diseña autonomía.
Decide qué puede hacer el sistema, qué puede seleccionar, qué debe demostrar, cuándo debe pedir ayuda y qué decisiones siguen perteneciendo a las personas.
El problema que ahora cambia de naturaleza
Con esta página termina la construcción conceptual.
Ya no necesitamos una nueva capa.
Tenemos el mapa suficiente para comenzar a aplicarlo.
La pregunta siguiente será práctica:
¿Cómo se ve esta arquitectura cuando la utilizamos para un trabajo jurídico concreto?
Revisar un contrato de trabajo no requiere exactamente la misma combinación que investigar una cuestión jurídica.
Comparar contratos no necesita los mismos permisos que un agente capaz de modificar sistemas.
Organizar evidencia para litigación exige otros criterios de procedencia y trazabilidad.
Los casos prácticos que siguen utilizarán la arquitectura completa como un conjunto de decisiones de diseño, no como una obligación de incorporar todas las capas en todas las tareas.