flowchart LR
A[Agente analiza] --> B[Prepara borrador]
B --> C[Revisión humana]
C -- corregir --> B
C -- aprobar --> D[Documento oficial / envío]
Permisos y autonomía
Cómo graduar la capacidad de acción de un agente según impacto y reversibilidad: leer, preparar borradores, comunicar, modificar sistemas y pedir aprobación humana.
Hasta ahora hemos hablado de agentes que pueden buscar, leer documentos, utilizar herramientas, mantener estado y seleccionar próximos pasos.
Todo eso describe capacidad técnica.
Pero en una organización aparece inmediatamente otra pregunta:
¿qué parte de esa capacidad está autorizada?
La diferencia es decisiva.
Un sistema puede ser técnicamente capaz de enviar un correo, modificar un registro, aprobar una solicitud o eliminar un archivo. De ahí no se sigue que deba poder hacerlo sin intervención humana.
Por eso las clases introducen una regla transversal:
la autonomía se gradúa según impacto y reversibilidad.
Idea central
No todas las acciones valen lo mismo.
En este handbook distinguiremos una progresión simple:
leer → preparar borradores → comunicar externamente → modificar sistemas.
A medida que aumenta el impacto y disminuye la reversibilidad, debe aumentar el control.
La pregunta correcta no es sólo:
“¿Puede hacerlo el agente?”
sino:
“¿bajo qué permiso, con qué límites y en qué punto debe intervenir una persona?”
Capacidad, permiso, decisión y responsabilidad
Conviene recuperar una distinción que atraviesa toda esta sección.
| Pregunta | Concepto |
|---|---|
| ¿Puede técnicamente ejecutar la acción? | Capacidad |
| ¿Está autorizado a ejecutarla? | Permiso |
| ¿Puede seleccionar por sí mismo cuándo ejecutarla? | Autonomía decisional |
| ¿Quién responde por la acción y sus efectos? | Responsabilidad |
Estas cuatro capas pueden separarse.
Un agente puede tener la capacidad de enviar un correo.
Puede tener permiso para enviar únicamente mensajes internos.
Puede estar diseñado para decidir cuándo preparar el borrador, pero no cuándo enviarlo.
Y la responsabilidad por la comunicación puede continuar en la persona u organización correspondiente.
Esta separación evita una idea engañosa: que “dar una herramienta” equivale a delegar autoridad.
Leer: la forma más básica de acción
Leer parece una actividad de bajo riesgo porque no modifica directamente el entorno.
Ejemplos:
- abrir un contrato;
- consultar una política;
- leer un expediente;
- buscar jurisprudencia;
- recuperar un correo.
Pero incluso la lectura exige permisos.
Un agente no debería asumir que todo aquello que técnicamente puede consultar pertenece al universo autorizado de la tarea.
Riesgos de lectura
La lectura puede implicar:
- acceso a información confidencial;
- exposición de datos personales;
- acceso entre asuntos o clientes;
- uso de repositorios restringidos;
- recuperación de información que el usuario humano tampoco estaría autorizado a ver.
Por eso una regla de “sólo lectura” reduce el impacto, pero no elimina el problema de autorización.
Un diseño razonable
Podemos imaginar:
PERMISO
leer exclusivamente documentos del expediente actual
NO PERMITIDO
consultar carpetas de otros clientes
REGISTRO
conservar qué documento fue abierto y para qué tareaLa lógica se aproxima al principio de mínimo privilegio: habilitar solamente el acceso necesario para cumplir el objetivo.
Preparar borradores: producir sin publicar
El siguiente nivel es permitir que el agente prepare artefactos de trabajo.
Puede:
- redactar una minuta;
- preparar una cláusula;
- completar una matriz;
- generar un correo no enviado;
- proponer una respuesta a una autoridad;
- preparar una entrada para un sistema.
Aquí aparece una distinción importante entre crear y hacer efectiva una acción.
Un borrador puede contener errores, pero todavía existe un punto natural de revisión antes de que produzca efectos externos.
El borrador como zona de seguridad
Para muchas tareas jurídicas, una arquitectura útil consiste en permitir alta autonomía en preparación y baja autonomía en publicación.
Por ejemplo:
El sistema puede ahorrar trabajo repetitivo sin adquirir autoridad para adoptar la decisión final.
Marcar el estado del artefacto
Un control sencillo consiste en distinguir explícitamente:
BORRADOR GENERADO POR SISTEMA
NO ENVIADO
PENDIENTE DE REVISIÓNLa ABA recomienda políticas claras sobre uso de IA y supervisión. También señala la utilidad de identificar material producido mediante IA para que usuarios posteriores comprendan su potencial falibilidad.
Comunicar externamente: cuando el error sale del sistema
Enviar un mensaje a un tercero cambia sustancialmente el perfil de riesgo.
Una respuesta incorrecta dentro de una interfaz puede corregirse antes de producir efectos.
Una comunicación externa puede:
- revelar información;
- asumir una posición;
- generar expectativas;
- afectar una negociación;
- realizar una representación frente a un tribunal o autoridad;
- comprometer reputación o relaciones.
Por eso las clases ubican enviar a terceros en un nivel alto de riesgo y sugieren aprobación humana.
Ejemplo
El agente detecta que falta un DPA y prepara:
“Estimado proveedor: para continuar con nuestra revisión necesitamos el anexo de tratamiento de datos y la lista vigente de subprocesadores.”
Podemos permitir que el sistema prepare el mensaje.
Pero antes de enviarlo conviene preguntar:
- ¿el destinatario es correcto?;
- ¿la solicitud refleja la posición institucional?;
- ¿incluye información que no debía divulgarse?;
- ¿debe copiarse a alguien?;
- ¿la comunicación puede afectar una negociación en curso?;
La capacidad de redactar no responde esas preguntas por sí sola.
Modificar sistemas: actuar sobre el estado institucional
El mayor salto ocurre cuando el agente puede cambiar sistemas externos.
Ejemplos:
- modificar permisos;
- cerrar un ticket;
- cambiar el estado de un contrato a “aprobado”;
- registrar una excepción;
- eliminar archivos;
- actualizar una base de clientes;
- alterar una configuración.
Estas acciones pueden tener consecuencias materiales aunque no exista comunicación a un tercero.
Riesgo de propagación
Un cambio aparentemente pequeño puede activar otros procesos.
Por ejemplo:
estado_contrato = aprobadopodría provocar automáticamente:
- emisión de orden de compra;
- habilitación de acceso;
- notificación a proveedor;
- inicio de facturación;
- archivo del expediente.
Por eso debemos analizar no sólo la acción inmediata, sino también qué sistemas dependen de ella.
Regla prudente
Las clases proponen para acciones críticas algo como:
prohibir o exigir doble aprobación.
No es una regla universal. Es una manera de mostrar que el nivel de control debe corresponder al impacto potencial.
Reversibilidad
La reversibilidad es una variable especialmente útil para decidir cuánto control necesitamos.
Preguntemos:
Si esta acción resulta incorrecta, ¿podemos deshacerla sin daño significativo?
Alta reversibilidad
Guardar un borrador interno.
Podemos eliminarlo o corregirlo antes de utilizarlo.
Reversibilidad media
Modificar un campo de una base con historial de cambios.
Puede revertirse, pero quizá ya produjo consecuencias intermedias.
Baja reversibilidad
Enviar información confidencial a un tercero.
Podemos pedir su eliminación, pero ya ocurrió la divulgación.
Irreversibilidad práctica
Presentar una información falsa a un tribunal, transferir fondos o eliminar información sin respaldo.
Aunque técnicamente exista alguna forma de reparación, el efecto jurídico, reputacional o económico puede no ser realmente reversible.
Impacto y reversibilidad deben analizarse juntos
Una acción de impacto bajo puede tolerar mayor autonomía.
Una acción de impacto alto y difícil de revertir justifica controles mucho más fuertes.
Por eso no existe una respuesta única a “¿cuánta autonomía debe tener el agente?”.
Depende de qué acciones concretas puede seleccionar.
Aprobación humana
La aprobación humana es un mecanismo para reservar determinadas decisiones.
Pero debe diseñarse con precisión.
No basta con escribir:
“Habrá un humano en el loop.”
Necesitamos saber:
- ¿en qué evento interviene?;
- ¿qué información recibe?;
- ¿qué opciones tiene?;
- ¿puede rechazar realmente?;
- ¿queda registrada la decisión?;
- ¿qué ocurre si no responde?;
Tres momentos posibles
La intervención humana puede ubicarse antes de diferentes etapas.
Antes de planificar
Una persona fija el objetivo o un plan de alto nivel.
Antes de ejecutar
El agente propone una acción y espera autorización.
Antes de cerrar
El sistema prepara antecedentes y una persona adopta la decisión final.
Huyen señala que humanos pueden intervenir en generación del plan, validación del plan o ejecución de operaciones riesgosas. Google recomienda controles deterministas y confirmación explícita para acciones significativas.
Una matriz simple de permisos
| Acción | Impacto típico | Regla pedagógica posible | Ejemplo |
|---|---|---|---|
| Leer | Bajo a medio | permitir con alcance y registro | abrir contrato |
| Preparar borrador | Medio | permitir con revisión | preparar minuta |
| Comunicar externamente | Alto | autorización previa | enviar correo |
| Modificar sistema crítico | Muy alto | prohibir o doble aprobación | cambiar permisos |
La tabla no sustituye un análisis de riesgos.
Sirve para hacer visible que la autonomía se asigna por acción, no mediante una etiqueta global como “modo autónomo”.
Un ejemplo completo: revisión contractual
Supongamos que diseñamos un agente de revisión de proveedores.
Puede leer
- contrato del expediente;
- DPA;
- política interna autorizada.
No puede leer otras carpetas.
Puede preparar
- matriz de riesgos;
- preguntas al proveedor;
- borrador de cláusulas alternativas.
No puede comunicar directamente
Toda pregunta externa queda pendiente de aprobación.
Puede registrar
- hallazgos;
- documentos revisados;
- estado “pendiente de revisión”.
No puede cambiar
- estado a “aprobado”;
- permisos de acceso;
- excepciones contractuales.
Human gate
Una persona interviene antes de:
- comunicaciones externas;
- aceptación de riesgos altos;
- cierre de la revisión.
El agente continúa siendo útil y relativamente autónomo dentro de un espacio delimitado.
Separar selección de acción y ejecución de acción
Una arquitectura puede introducir un control adicional separando dos decisiones:
- el agente propone qué acción conviene realizar;
- otro componente determina si esa acción puede ejecutarse.
Por ejemplo:
flowchart LR
A[Agente selecciona: enviar solicitud] --> B[Motor de políticas]
B --> C{¿Permitido?}
C -- Sí, bajo umbral --> D[Ejecutar]
C -- Requiere persona --> E[Human gate]
C -- Prohibido --> F[Bloquear]
Esta arquitectura es más robusta que confiar exclusivamente en una frase del prompt como “pide permiso antes de acciones importantes”.
El modelo puede proponer.
La capa de control puede autorizar, bloquear o escalar.
En Derecho, esta separación es especialmente valiosa porque permite distinguir criterio contextual de competencia institucional.
El problema del permiso heredado
Un riesgo adicional aparece cuando una herramienta opera con credenciales demasiado amplias.
Supongamos que el agente utiliza la cuenta de un administrador con acceso a toda la base.
Aunque su instrucción diga:
“Modifica sólo el expediente actual.”
la capacidad técnica continúa siendo mucho mayor.
Google subraya que los agentes deberían operar con identidades y permisos de mínimo privilegio cuando actúan sobre sistemas empresariales.
La lección para un lector jurídico es simple:
los límites críticos no deberían depender únicamente de que el modelo recuerde obedecerlos.
Cuando una acción debe estar prohibida, conviene que la arquitectura la haga efectivamente inaccesible.
Qué puede salir mal
Permisos demasiado amplios
Amplían el “radio de daño” de un error.
Aprobación tardía
Pedir revisión después de que la acción ya ocurrió no es un human gate.
Aprobación sin evidencia
Una persona que sólo ve “¿Aprobar? Sí/No” no dispone necesariamente de control significativo.
Confundir reversibilidad técnica con jurídica
Poder restaurar un registro no deshace necesariamente los efectos que produjo.
Diseñar autonomía global
Un sistema no debería clasificarse simplemente como “autónomo” o “no autónomo”. Puede tener alta autonomía para leer y baja para comunicar.
Qué debes recordar
La autonomía debe diseñarse acción por acción.
Leer, preparar, comunicar y modificar sistemas tienen perfiles de impacto distintos.
La reversibilidad ayuda a determinar cuánta supervisión necesitamos.
Y una regla transversal permanece:
capacidad técnica no equivale a permiso; permiso no equivale a autoridad profesional; autonomía no desplaza automáticamente responsabilidad.
El problema que todavía queda abierto
Ya sabemos graduar acciones y permisos.
Pero todavía debemos resolver una aparente oposición que aparece constantemente en conversaciones sobre agentes:
“¿Debemos usar un workflow o un agente?”
La pregunta está mal formulada si los tratamos como enemigos.
La siguiente página muestra la diferencia entre ruta predeterminada y decisión contextual, y por qué un agente jurídico puede operar precisamente dentro de un workflow gobernado.