flowchart TD
A[Modelo propone acción] --> B{¿Tool habilitada?}
B -- No --> X[Bloquear]
B -- Sí --> C{¿Requiere aprobación?}
C -- No --> D[Validar y ejecutar]
C -- Sí --> E[Solicitar autorización humana]
E --> F{¿Aprobada?}
F -- No --> X
F -- Sí --> D
D --> G[Registrar resultado]
Permisos
Cómo separar capacidad técnica, autorización y responsabilidad cuando una aplicación puede leer, escribir, comunicar, modificar o ejecutar acciones sobre sistemas reales.
Llegamos al punto en que el sistema ya puede hacer mucho más que generar texto.
Puede disponer de tools.
Puede invocarlas mediante tool calling.
Puede comunicarse con servicios mediante APIs.
Puede utilizar connectors.
Puede descubrir capacidades mediante MCP.
Desde una perspectiva puramente funcional, cada nueva conexión parece una mejora.
Pero hay una pregunta que debe aparecer antes de celebrar esa capacidad:
¿Qué está autorizado a hacer el sistema?
La diferencia es fundamental porque una aplicación puede ser técnicamente capaz de ejecutar una operación que institucionalmente no debería ejecutar.
Idea central
No debemos confundir:
CAPACIDAD → qué puede hacer técnicamente el sistema.
PERMISO → qué está autorizado a hacer.
DECISIÓN → cuándo puede seleccionar esa acción.
RESPONSABILIDAD → quién responde por sus efectos.
Una tool amplía capacidad.
No concede automáticamente autoridad.
El problema aparece cuando la IA deja de ser sólo un borrador
Supongamos que el sistema genera:
Recomiendo informar al proveedor que la cláusula 14.2 debe renegociarse.Mientras esa frase permanezca en pantalla, una persona puede revisarla.
Ahora supongamos que existe una tool:
enviar_correo_proveedor(...)El sistema ya puede convertir la recomendación en una comunicación real.
El riesgo cambia.
Y si además existe:
aprobar_proveedor(...)la diferencia es todavía mayor.
Por eso los permisos no deben pensarse como una capa administrativa añadida al final.
Forman parte del diseño de la arquitectura.
Capacidad, permiso, decisión y responsabilidad
Conviene fijar las cuatro preguntas mediante un caso.
Capacidad
Existe técnicamente:
enviar_correoPregunta:
¿puede el sistema ejecutar esa función?
Permiso
La política establece:
puede crear borradores
no puede enviar sin autorizaciónPregunta:
¿está autorizado a hacerlo?
Decisión
Incluso si el envío está permitido después de aprobación, queda otra cuestión:
¿quién decide cuándo corresponde solicitar ese envío?
Puede ser el usuario, un workflow o, más adelante, un agente.
Responsabilidad
Finalmente:
¿quién responde por una comunicación incorrecta?
La existencia de automatización no elimina la necesidad de asignar responsabilidad.
Autenticación, autorización y aprobación
Antes de analizar tipos de permiso conviene consolidar tres conceptos.
Autenticación
Pregunta:
¿Quién eres?
El sistema establece la identidad.
Autorización
Pregunta:
¿Qué puedes hacer?
Por ejemplo:
leer matter ACME
crear borradores
no eliminar documentosAprobación
Pregunta:
¿Puede ejecutarse esta acción concreta ahora?
Por ejemplo:
Acción propuesta:
enviar correo al proveedor
Regla:
requiere confirmación humanaEstas tres capas pueden coexistir.
Una persona puede estar autenticada, tener autorización general para utilizar correo y, aun así, necesitar aprobar un envío concreto generado por el sistema.
1. Leer
El primer nivel es leer.
Puede incluir:
abrir contrato
leer anexo
consultar correo
obtener política
consultar registroA primera vista parece de bajo riesgo porque no modifica el sistema.
Pero la lectura puede involucrar información muy sensible.
En Derecho podemos estar trabajando con:
- información de clientes;
- secretos comerciales;
- comunicaciones confidenciales;
- datos personales;
- expedientes segregados;
- estrategias de litigación.
Por eso read-only significa únicamente:
no modifica el recursoNo significa:
acceso irrestrictoPermisos de lectura deben seguir el alcance
Supongamos que la abogada A trabaja en el matter ACME.
La integración debería permitir:
leer ACMEpero no necesariamente:
buscar todos los matters del estudioEste punto es especialmente importante cuando el connector utiliza una cuenta de servicio con privilegios amplios.
La arquitectura debe evitar que la capacidad técnica de la integración destruya las fronteras de autorización existentes.
2. Escribir
El segundo nivel es escribir.
Incluye:
guardar informe
crear ticket
crear nota
actualizar estado
registrar hallazgoAhora existe persistencia.
El error puede quedar almacenado y propagarse.
Pensemos en:
estado = APROBADOcuando correspondía:
estado = PENDIENTE_REVISIONUna clasificación equivocada deja de ser solamente una frase en una conversación.
Puede convertirse en un dato utilizado por otros sistemas o personas.
Borrador y registro definitivo no son lo mismo
La categoría “write” también necesita granularidad.
Podemos distinguir:
crear borradorde:
publicar versión definitivaEl primer caso puede tener revisión humana posterior.
El segundo puede convertirse inmediatamente en información oficial.
Esto permite diseñar permisos más seguros.
Por ejemplo:
crear_borrador_revision
→ permitido
cerrar_revision_como_aprobada
→ requiere autorización3. Comunicar
Desde la perspectiva jurídica conviene separar comunicar aunque técnicamente sea una forma de escritura.
¿Por qué?
Porque una comunicación cruza una frontera de audiencia.
Comparemos:
redactar_correocon:
enviar_correoEl contenido puede ser idéntico.
El efecto no lo es.
Un borrador puede corregirse.
Un correo enviado puede producir:
- expectativas;
- compromisos;
- efectos reputacionales;
- consecuencias negociadoras;
- revelación de información.
Por eso las acciones comunicativas suelen merecer controles específicos.
Destinatario y adjuntos también son parte del permiso
No basta preguntar:
“¿puede enviar correo?”
También necesitamos considerar:
¿a quién?
¿desde qué cuenta?
¿con qué adjuntos?
¿puede enviar externamente?
¿puede incluir información confidencial?
¿hay allowlist?Un permiso granular podría permitir comunicaciones internas y exigir aprobación para destinatarios externos.
4. Modificar
Modificar incluye operaciones sobre objetos existentes.
Por ejemplo:
editar registro
reemplazar documento
cambiar fecha
mover archivo
cambiar permisos
eliminar contenidoAquí aparecen dos variables muy útiles:
IMPACTO
qué consecuencias produce
REVERSIBILIDAD
qué tan fácil es deshacerloModificar una etiqueta interna no equivale a eliminar un expediente.
Cambiar una fecha de borrador no equivale a cambiar permisos de acceso.
La autorización debería reflejar esas diferencias.
5. Acciones que requieren autorización
Llegamos al núcleo de la página.
No todas las acciones que el sistema puede ejecutar deberían ejecutarse inmediatamente cuando el modelo las propone.
La aplicación puede interponer un human gate.
Por ejemplo:
La diferencia entre instrucción y control es crucial.
“No lo hagas” no equivale a impedirlo
Podríamos escribir en el prompt:
No envíes correos sin aprobación.La instrucción puede ayudar.
Pero si la arquitectura realmente considera imprescindible la autorización, el control más fuerte es:
la función de envío no se ejecuta hasta recibir confirmaciónEso transforma una expectativa lingüística en una regla de ejecución.
Instrucción ≠ control técnico
Las instrucciones orientan al modelo.
Los permisos y gates limitan lo que el sistema puede ejecutar.
Cuando una acción tiene consecuencias importantes, conviene evitar que toda la protección dependa de que el modelo recuerde obedecer una frase.
Read · Write · Execute
Las clases UDD utilizan una clasificación simple para comenzar a pensar permisos según efecto sobre el mundo.
| Nivel | Qué permite | Ejemplo jurídico | Riesgo principal |
|---|---|---|---|
| Read | acceder a información | leer contrato, anexo o correo | confidencialidad, privacidad, acceso indebido |
| Write | crear o modificar estado | guardar informe, actualizar ticket | registro incorrecto, propagación, trazabilidad |
| Execute | producir un efecto relevante | enviar, aprobar, firmar, cancelar | efecto externo o jurídico |
La regla pedagógica es:
cuanto más irreversible o externo sea el efecto, más fuerte debe ser el control.
No es una fórmula matemática ni una regla jurídica universal.
Es un principio de diseño.
Una matriz más granular
Podemos traducirlo al caso contractual.
| Acción | Tipo | ¿Automática? | Posible control |
|---|---|---|---|
| buscar contrato en matter autorizado | Read | sí | logging y ACL |
| leer anexo | Read | sí | permisos heredados |
| calcular ratio | Compute | sí | validar inputs |
| crear borrador de revisión | Write | sí | etiquetar como borrador |
| actualizar estado a “requiere negociación” | Write | quizás | validación previa |
| enviar correo interno | Communicate | quizás | destinatarios permitidos |
| enviar correo al proveedor | Execute | no por defecto | aprobación humana |
| aprobar contratación | Execute | no | autoridad institucional |
| modificar permisos del DMS | Critical modify | no | fuera de alcance o doble aprobación |
La matriz ayuda a diseñar antes de conectar.
Menor privilegio
De esta lógica surge un principio clásico de seguridad: least privilege o menor privilegio.
Una identidad debería disponer sólo de las capacidades necesarias para cumplir su función.
Aplicado a nuestro sistema:
Si sólo necesita buscar contratos:
permitir buscar y leerNo:
permitir eliminar y cambiar permisosSi sólo necesita preparar comunicaciones:
permitir crear borradoresNo necesariamente:
permitir enviarReducir capacidad disponible disminuye el espacio de errores posibles.
Capability bounding: acotar desde la tool
El control no tiene que aparecer solamente en el sistema de permisos.
También podemos diseñar herramientas más estrechas.
Comparemos:
administrar_DMS(accion, recurso, usuario, permisos, ...)con:
buscar_contratos_autorizados(proveedor)La primera tool concentra demasiado poder.
La segunda está acotada por finalidad.
Incluso si ambas utilizan la misma API, la superficie operacional es muy distinta.
La reversibilidad como criterio
Supongamos dos acciones:
crear_borradory:
eliminar_documento_definitivamenteAmbas modifican estado.
Pero la segunda es mucho más difícil de revertir.
Por eso la reversibilidad puede utilizarse para graduar controles.
Una regla útil es:
más irreversible
→ más validación
→ más autorización
→ más evidenciaLa exterioridad como criterio
También importa si el efecto permanece dentro del entorno.
nota internano equivale a:
correo a contraparteAunque ambas sean escrituras.
La exterioridad aumenta la posibilidad de consecuencias que no pueden corregirse simplemente editando un registro.
La autoridad institucional como criterio
Algunas acciones no son sensibles porque modifiquen muchos datos, sino porque representan una decisión.
Por ejemplo:
aprobar contrato
rechazar proveedor
presentar escrito
firmar documentoLa pregunta no es sólo si la tool puede ejecutarlas.
También:
¿quién tiene competencia organizacional o profesional para decidir?
La arquitectura técnica no puede crear por sí sola esa autoridad.
Permiso ≠ responsabilidad
Supongamos que la aplicación tiene permiso para enviar un correo y que una persona aprueba el envío.
Todavía queda una pregunta distinta:
¿quién responde si el contenido era incorrecto?
La autorización técnica no determina automáticamente la asignación jurídica de responsabilidad.
Esto debe analizarse mediante:
- roles organizacionales;
- obligaciones profesionales;
- contratos;
- procedimientos internos.
La ABA Formal Opinion 512 destaca precisamente que el uso de herramientas de IA no elimina deberes profesionales como competencia, confidencialidad, supervisión, comunicación y revisión. La guía del CCBE formula preocupaciones convergentes desde el entorno europeo.
Permisos y trazabilidad
Si una acción requiere autorización, debería poder reconstruirse posteriormente:
qué acción se propuso
quién la solicitó
qué argumentos llevaba
quién la aprobó
cuándo se ejecutó
qué resultado produjoNo desarrollaremos todavía observabilidad completa, pero aquí aparece su razón de ser.
Sin evidencia de ejecución, la autorización puede ser difícil de demostrar.
Un caso completo
Nuestro sistema concluye:
El contrato ACME contiene una desviación material en responsabilidad.Read
Busca precedentes.
consultar_excepciones("responsabilidad")Permitido dentro del matter.
Compute
Calcula exposición.
calcular_ratio(800000, 2400000)Permitido.
Write
Crea borrador.
crear_borrador_revision(...)Permitido, claramente marcado como borrador.
Communicate
Propone correo al proveedor.
enviar_correo(...)La acción queda en estado:
PENDIENTE_DE_APROBACIONHuman gate
La persona revisa:
- destinatario;
- texto;
- adjuntos;
- oportunidad.
Execute
Sólo después de aprobación se envía.
Record
El sistema conserva el resultado.
Éste es el tipo de arquitectura que permite combinar capacidad con control.
Un error frecuente: permiso demasiado amplio por comodidad
Durante una prueba puede parecer sencillo utilizar una cuenta con acceso total.
La aplicación “funciona”.
Después esa misma arquitectura pasa a producción.
El problema es que se ha confundido:
facilidad de integracióncon:
modelo de autorización adecuadoLa etapa de piloto no debería ocultar qué permisos serán aceptables en operación real.
Otro error: pedir autonomía antes de definir permisos
Las clases UDD incluyen una advertencia especialmente importante:
no pedir autonomía antes de definir permisos, logs y criterios de término.
Tiene sentido.
Si todavía no sabemos:
qué puede leer
qué puede escribir
qué necesita aprobación
qué nunca debe hacerno estamos en condiciones de decidir cuánta autonomía conceder.
Los permisos deben preceder a la autonomía.
Por qué importa para la contratación de IA
Cuando un proveedor ofrece una aplicación conectada, una revisión contractual debería ir más allá de la frase:
“el servicio podrá acceder a los sistemas del cliente”.
Necesitamos concretar:
sistemas autorizados
identidades
scopes
operaciones permitidas
finalidades
restricciones
aprobaciones
logging
revocación de credenciales
tratamiento de incidentesLa arquitectura técnica permite formular obligaciones contractuales más precisas.
Dónde estamos en el recorrido
La sección PODER ACTUAR ha añadido una propiedad nueva al sistema.
Antes teníamos:
SKILL
cómo trabajar
KNOWLEDGE / RAG
con qué información trabajarAhora añadimos:
TOOLS
qué operaciones ejecutar
API / CONNECTOR / MCP
cómo acceder a capacidades externas
PERMISOS
qué puede ejecutarse y bajo qué límitesPodemos representarlo así:
flowchart LR
S[Skill] --> K[Knowledge / RAG]
K --> T[Tool]
T --> I[API / Connector / MCP]
I --> P[Permisos]
Pero todavía falta algo.
Tener varias herramientas autorizadas no determina el orden de trabajo.
Qué debes recordar
Los permisos separan poder técnico de autoridad operacional.
Conviene distinguir:
AUTENTICACIÓN
¿quién eres?
AUTORIZACIÓN
¿qué puedes hacer?
APROBACIÓN
¿puede ejecutarse esta acción concreta ahora?Y clasificar acciones según efecto:
READ
leer
WRITE
crear o modificar
COMMUNICATE
cruzar una frontera de audiencia
MODIFY / EXECUTE
producir efectos más fuertesEl principio general es aumentar controles a medida que aumentan sensibilidad, impacto, exterioridad e irreversibilidad.
El problema que todavía queda abierto
Ahora nuestro sistema puede acceder a información, realizar cálculos y ejecutar acciones bajo permisos definidos.
Pero un trabajo jurídico real no es una bolsa de operaciones aisladas.
Existe una secuencia.
Hay estados.
Hay condiciones de avance.
Hay responsables.
Hay excepciones.
Hay puntos de revisión.
Hay decisiones sobre qué ocurre después.
Por eso el siguiente problema ya no es:
¿puede actuar?
Es:
¿cómo organizamos esas acciones dentro de un proceso controlable?
El recorrido pasa ahora de PODER ACTUAR a ORGANIZAR EL TRABAJO.
El siguiente concepto será el workflow.