flowchart LR
A["Instrucción"] --> B["Metodología"]
B --> C["Información"]
C --> D["Acción"]
D --> E["Proceso"]
E --> F["Criterios"]
F --> G["Selección dinámica"]
A -. "riesgo de especificación" .-> R1[" "]
B -. "riesgo metodológico" .-> R2[" "]
C -. "riesgo de fuente" .-> R3[" "]
D -. "riesgo de acción" .-> R4[" "]
E -. "riesgo de proceso" .-> R5[" "]
F -. "riesgo de criterio" .-> R6[" "]
G -. "riesgo de trayectoria" .-> R7[" "]
Qué riesgo introduce cada capa
Cómo crece la superficie de riesgo cuando añadimos reutilización, metodología, información, herramientas, procesos y autonomía, y por qué cada capacidad nueva exige controles específicos.
Hasta ahora la arquitectura se ha presentado como una sucesión de mejoras.
Una nueva capa aparece porque resuelve una limitación.
Eso es correcto, pero incompleto.
Cada vez que el sistema adquiere una capacidad nueva también adquiere una nueva forma de equivocarse.
Una template permite reutilizar una instrucción, pero también puede reutilizar un error cien veces.
Una skill estabiliza una metodología, pero también puede institucionalizar una metodología incompleta.
RAG permite traer información pertinente, pero también puede traer la fuente equivocada.
Una tool permite actuar, pero también permite producir efectos no deseados.
Un agente puede seleccionar una ruta, pero también puede encadenar decisiones incorrectas antes de que una persona intervenga.
Por eso la pregunta de diseño propuesta en las clases tiene dos partes inseparables:
¿Qué limitación concreta resuelve esta pieza y qué riesgo nuevo introduce?
Idea central
La arquitectura debe crecer en dos direcciones al mismo tiempo:
más capacidad
y
más control.
No existe una buena razón para aumentar el espacio de acciones, información o decisiones disponibles para el sistema sin diseñar también cómo limitar, observar, revisar y corregir ese nuevo poder operacional.
Riesgo no significa solamente “alucinación”
Cuando se habla de IA generativa, es frecuente reducir el riesgo a una sola categoría:
el modelo puede inventar información.
Ese riesgo importa, especialmente en trabajo jurídico.
Pero al construir sistemas más complejos aparecen otros problemas:
- acceso indebido a información;
- uso de fuentes desactualizadas;
- errores sistemáticos de metodología;
- acciones irreversibles;
- saltos de aprobación;
- propagación de errores;
- pérdida de trazabilidad;
- decisiones inconsistentes;
- sobredelegación;
- dependencia de proveedores;
- fallos de integración.
La arquitectura amplía el repertorio de riesgos porque amplía el repertorio de cosas que el sistema puede hacer.
Prompt: riesgo de especificación
El prompt determina qué tarea intentará realizar el sistema.
Si la instrucción es ambigua o contradictoria, el resultado puede estar correctamente generado respecto de un encargo incorrectamente especificado.
Ejemplo:
Revisa este contrato y determina si puede aprobarse.¿Qué significa aprobar?
¿Desde qué posición?
¿Bajo qué criterios?
¿Con qué documentos?
¿Puede el modelo decidir o sólo preparar antecedentes?
El riesgo característico es la desalineación entre el trabajo requerido y el trabajo especificado.
Controles útiles
- tarea explícita;
- objetivo claro;
- perspectiva;
- delimitación documental;
- criterios;
- restricciones;
- formato verificable.
La regla no es “hacer prompts largos”.
Es reducir decisiones implícitas cuando esas decisiones pueden cambiar materialmente el resultado.
Template: riesgo de escalar una mala instrucción
Una template mejora consistencia.
Precisamente por eso puede aumentar el impacto de un defecto.
Supongamos que una plantilla de revisión contractual omite sistemáticamente la interacción entre limitación de responsabilidad e indemnidad.
Una ejecución puede producir un error.
Cien ejecuciones convierten el error en una práctica.
La reutilización introduce un riesgo específico:
un defecto deja de ser accidental y puede volverse sistemático.
Controles útiles
- versionado;
- responsable de mantenimiento;
- pruebas con casos distintos;
- revisión periódica;
- registro de cambios;
- criterios para retirar una versión.
La pregunta deja de ser solamente:
¿funciona este prompt?
y pasa a ser:
¿podemos gobernar esta instrucción como un activo reutilizado?
Skill: riesgo metodológico
La skill encapsula una forma de trabajar.
Su principal riesgo es que una metodología incompleta, desactualizada o mal delimitada pueda ejecutarse con gran consistencia.
Esto es especialmente delicado porque un sistema consistente puede parecer confiable.
Imaginemos una skill de privacidad que:
- identifica categorías de datos;
- revisa finalidades;
- revisa retención;
pero nunca comprueba subprocesadores.
La salida puede ser ordenada y repetible.
La metodología sigue siendo incompleta.
El riesgo es entonces automatizar una omisión profesional.
Controles útiles
- validación por especialistas;
- casos de prueba;
- criterios de cobertura;
- definición de alcance;
- manejo explícito de excepciones;
- revisión cuando cambia la normativa o la práctica.
Consistencia no es corrección
Un sistema puede ejecutar de forma perfectamente consistente una metodología equivocada.
La estandarización reduce variabilidad.
No reemplaza la validación sustantiva.
Knowledge: riesgo de fuente
Knowledge amplía lo que el sistema puede utilizar.
Con ello aparecen preguntas sobre:
- procedencia;
- vigencia;
- autenticidad;
- confidencialidad;
- permisos;
- completitud;
- separación entre clientes o asuntos.
Un sistema puede disponer de demasiada información, no sólo de demasiado poca.
Por ejemplo, una biblioteca puede contener:
política vigente
política derogada
borrador no aprobado
contrato de otro cliente
documento confidencial sin permiso para este asuntoEl problema ya no es “¿tenemos información?”.
Es:
¿qué información puede utilizarse legítima y correctamente en esta tarea?
Controles útiles
- clasificación de fuentes;
- metadatos de vigencia;
- control de acceso;
- separación por asunto o cliente;
- responsables de curaduría;
- trazabilidad de procedencia;
- políticas de retención.
En trabajo jurídico, la procedencia puede ser tan importante como el contenido.
RAG: riesgo de recuperación
RAG permite seleccionar información pertinente.
Su riesgo característico es que la selección sea incompleta o equivocada.
Podemos distinguir varios fallos:
falso positivo
recupera material irrelevante
falso negativo
omite material decisivo
versión incorrecta
trae una fuente obsoleta
fragmentación
recupera un párrafo sin el contexto necesario
ranking defectuoso
prioriza una fuente secundaria sobre una primariaUna respuesta puede ser perfectamente razonable respecto de los fragmentos recuperados y seguir siendo incorrecta respecto del expediente completo.
Controles útiles
- evaluación de recuperación;
- filtros por fuente, fecha o asunto;
- citas al material recuperado;
- posibilidad de abrir la fuente;
- declaración de información faltante;
- búsqueda alternativa cuando la evidencia es insuficiente.
RAG no debe convertirse en una excusa para dejar de preguntar:
¿la fuente correcta estaba realmente allí?
Tool: riesgo de acción
Con las tools cambia la naturaleza del riesgo.
Antes el sistema producía contenido.
Ahora puede:
- leer;
- consultar;
- crear;
- modificar;
- enviar;
- eliminar;
- ejecutar.
La diferencia entre esas acciones es enorme.
Las clases proponen una regla simple:
Leer
riesgo normalmente menor
Escribir borrador
riesgo intermedio
Enviar a terceros
riesgo alto
Modificar sistemas críticos
riesgo muy altoEl riesgo característico es transformar una decisión o inferencia incorrecta en un efecto externo.
Ejemplo:
El sistema concluye equivocadamente que el contrato fue aprobado.
Si sólo produce una frase, el error puede revisarse.
Si dispone de una tool que actualiza automáticamente el sistema de procurement, el error cambia el estado institucional del asunto.
Controles útiles
- least privilege;
- separar lectura de escritura;
- validación de parámetros;
- confirmación humana;
- límites de alcance;
- sandbox;
- reversibilidad;
- logs de tool calls;
- prohibiciones técnicas para operaciones críticas.
Capacidad no equivale a permiso
Que exista una tool capaz de enviar un correo no implica que el agente deba poder enviarlo.
Puede tener permiso únicamente para preparar un borrador.
El diseño de permisos debe ocurrir antes de delegar acciones.
API, connector y MCP: riesgo de integración
Las integraciones amplían la superficie del sistema.
Cada conexión puede introducir:
- credenciales;
- permisos;
- formatos de entrada;
- dependencias externas;
- cambios de versión;
- disponibilidad;
- nuevos flujos de datos.
Un connector mal configurado puede exponer más información de la necesaria.
Una API puede cambiar.
Una herramienta puede interpretar mal una respuesta.
Un protocolo estandariza una interacción, pero no garantiza que la capacidad expuesta sea segura o apropiada.
El riesgo característico es confiar en la existencia de una interfaz como si eso resolviera autorización, seguridad y semántica de la acción.
Controles útiles
- autenticación;
- autorización granular;
- scopes;
- validación de schema;
- manejo de errores;
- rate limits;
- monitoreo;
- documentación de dependencias;
- pruebas de integración.
Workflow: riesgo de proceso
El workflow aporta secuencia.
Por eso puede automatizar también una secuencia defectuosa.
Un flujo podría:
recibir contrato
↓
ejecutar revisión
↓
aprobarsin comprobar que el expediente estuviera completo.
O podría enviar siempre a privacidad, generando costos innecesarios.
O podría cerrar un asunto aunque exista una tarea pendiente.
El riesgo característico es convertir un mal procedimiento en una práctica repetible.
Controles útiles
- estados explícitos;
- condiciones de avance;
- responsables;
- manejo de excepciones;
- rutas de error;
- posibilidad de reabrir;
- indicadores de asuntos bloqueados;
- pruebas con casos excepcionales.
Weske enfatiza precisamente que los procesos no son sólo secuencias nominales: contienen actividades, eventos, decisiones y datos cuya relación debe modelarse adecuadamente.
Playbook: riesgo de criterio
El playbook codifica decisiones organizacionales.
Por ejemplo:
si riesgo < umbral
aprobar ruta ordinaria
si riesgo >= umbral
escalarLa pregunta inmediata es:
¿quién definió el umbral y cuándo se revisó por última vez?
Un playbook puede producir una apariencia de objetividad porque convierte criterios en reglas.
Pero esos criterios pueden ser:
- demasiado generales;
- desactualizados;
- inconsistentes;
- incompletos;
- inaplicables a casos excepcionales.
El riesgo es automatizar una política deficiente o esconder juicio normativo detrás de una regla operacional.
Controles útiles
- responsable de cada criterio;
- fuente del criterio;
- fecha de vigencia;
- procedimiento de modificación;
- excepciones documentadas;
- escalamiento;
- posibilidad de revisión humana;
- registro de la regla aplicada.
Un buen playbook debe poder responder no sólo:
¿qué decidió?
sino:
¿qué criterio activó esa ruta?
Agent: riesgo de selección y propagación
El agente añade selección dinámica.
Eso significa que una decisión puede afectar el contexto de la siguiente.
Supongamos:
1. interpreta que falta información;
2. decide buscar;
3. selecciona la fuente equivocada;
4. incorpora esa fuente;
5. clasifica el riesgo;
6. elige una ruta;
7. ejecuta una tool;Un error temprano puede propagarse.
Por eso el riesgo no está sólo en la decisión final.
Está en la trayectoria.
Google destaca la necesidad de instrumentar sistemas agentic con logs y traces precisamente para reconstruir por qué se seleccionó una herramienta, qué parámetros se utilizaron y qué observó el sistema después.
Controles útiles
- espacio limitado de acciones;
- criterios de término;
- límites de iteraciones;
- herramientas autorizadas;
- permisos mínimos;
- validaciones antes de acciones;
- human-in-the-loop;
- logs;
- traces;
- monitoreo;
- capacidad de detener o revertir.
La regla de las clases es especialmente útil:
un agente confiable debe saber concluir, abstenerse o escalar.
No basta con saber continuar.
Más autonomía, más superficie de fallo
Podemos visualizar el crecimiento así:
El diagrama no significa que las capas superiores sean necesariamente más peligrosas.
Significa que permiten más tipos de efecto.
Una aplicación muy limitada puede tener riesgos graves si se utiliza en un contexto crítico.
Un agente puede ser de bajo riesgo si sólo opera sobre información pública y produce borradores sin posibilidad de envío.
El riesgo depende de la combinación entre capacidad, datos, permisos, impacto y contexto.
El riesgo depende de reversibilidad
Una distinción útil es preguntar qué ocurre si la acción está equivocada.
Comparemos:
leer un contratocon:
eliminar un expedienteLa segunda acción es más difícil de revertir.
O:
preparar un correocon:
enviar el correo a una contraparteEl borrador puede corregirse antes de producir efectos.
El envío ya cruzó una frontera.
Por eso el diseño de autonomía debería considerar:
- impacto;
- reversibilidad;
- confidencialidad;
- costo de error;
- posibilidad de supervisión.
Riesgo de acumulación
También puede ocurrir algo más sutil.
Cada capa individual puede parecer razonable y, sin embargo, la combinación producir un riesgo mayor.
Ejemplo:
RAG
recupera una política equivocada.
Playbook
usa esa política como criterio.
Agent
selecciona una ruta conforme a ese criterio.
Tool
actualiza el estado del proveedor.Ningún componente necesita “alucinar” para que el resultado sea incorrecto.
El fallo se produce por composición.
Esto explica por qué la evaluación de sistemas complejos no puede limitarse a probar el modelo de manera aislada.
Evidencia operativa: registrar la trayectoria
A medida que crece la arquitectura, también crece la necesidad de trazabilidad.
Las clases proponen registrar, según el caso:
| Elemento | Para qué sirve |
|---|---|
| Prompt o instrucción | saber qué se pidió |
| Documentos recuperados | verificar base del análisis |
| Tool calls y argumentos | reconstruir acciones |
| Outputs y versiones | controlar cambios |
| Aprobaciones humanas | atribuir decisiones y umbrales |
Esta evidencia no garantiza que el sistema sea correcto.
Pero sin ella es mucho más difícil:
- investigar errores;
- aprender de incidentes;
- comparar versiones;
- demostrar revisión;
- reconstruir decisiones.
En trabajo jurídico, el log puede convertirse en parte de la defensa de calidad del proceso.
Human-in-the-loop no significa “una persona aparece en algún momento”
La presencia de una persona suele presentarse como solución general.
No basta.
Debemos preguntar qué poder real tiene esa persona.
Un control humano útil puede:
- ver la evidencia;
- entender qué decisión se propone;
- rechazarla;
- corregirla;
- pedir información;
- detener el proceso.
Un botón de “aprobar” sin contexto suficiente puede ser un control nominal.
Las guías profesionales de la ABA y del CCBE insisten, desde perspectivas deontológicas, en la necesidad de comprender las limitaciones de las herramientas, verificar outputs cuando corresponde y preservar las obligaciones profesionales del abogado.
La supervisión humana debe diseñarse para que esas obligaciones puedan ejercerse realmente.
Una matriz de riesgo por capa
| Capa | Riesgo característico | Pregunta de control |
|---|---|---|
| Prompt | tarea mal especificada | ¿estamos pidiendo realmente el trabajo correcto? |
| Template | error reutilizado | ¿la versión es válida para este tipo de caso? |
| Skill | metodología defectuosa | ¿la forma de trabajo cubre lo necesario? |
| Knowledge | fuente inadecuada | ¿qué información está autorizada, vigente y completa? |
| RAG | recuperación incorrecta | ¿se trajo la evidencia pertinente? |
| Tool | acción errónea | ¿qué puede ejecutar y con qué permiso? |
| Workflow | proceso defectuoso | ¿puede saltarse estados o controles? |
| Playbook | criterio defectuoso | ¿qué regla activó la decisión y quién la gobierna? |
| Agent | trayectoria errónea | ¿cómo reconstruimos por qué eligió esos pasos? |
La matriz no es una checklist universal.
Su función es mostrar que el control debe corresponder al tipo de capacidad introducida.
Qué debes recordar
La arquitectura completa no debe evaluarse sólo por lo que permite hacer.
Debe evaluarse también por cómo puede fallar.
La regla general es:
NUEVA CAPACIDAD
↓
NUEVO RIESGO
↓
CONTROL ESPECÍFICO
↓
EVIDENCIA DEL FUNCIONAMIENTONo basta agregar la palabra “guardrail”.
El control debe operar en la capa adecuada.
Un prompt puede pedir prudencia.
Pero un permiso puede impedir una acción.
Un workflow puede impedir saltar una aprobación.
Un log puede permitir reconstruir una ejecución.
Un humano puede retener autoridad sobre una decisión crítica.
El problema que todavía queda abierto
Ya hemos recorrido la arquitectura desde dos direcciones.
Primero:
qué aporta cada capa.
Después:
qué riesgo introduce cada capa.
Ahora podemos responder la pregunta final del recorrido.
¿Qué significa realmente aumentar la autonomía de un sistema?
La respuesta no puede ser simplemente “usar un modelo mejor” ni “agregar un agente”.
La última página muestra por qué la autonomía operacional surge de combinar capacidades, conocimiento, herramientas, procedimientos, permisos y controles, y por qué esa autonomía debe diseñarse como una propiedad gobernada del sistema.