Cuando un agente puede actuar frente a terceros, ya no basta con evaluar la calidad de sus respuestas. Hay que separar herramienta, permiso técnico, mandato, confirmación, revocación y evidencia.
Un agente de inteligencia artificial puede leer un correo, preparar una respuesta y dejarla en borradores. También puede, técnicamente, enviarla. Puede consultar disponibilidad y también reservar. Puede preparar una orden de compra y también ejecutarla. Puede proponer una modificación en un CRM y también escribirla directamente.
La diferencia parece pequeña desde la interfaz. Jurídicamente, no lo es.
Cuando el sistema deja de limitarse a producir información y empieza a ejecutar acciones, aparece una pregunta central: ¿qué actos está autorizado a realizar por la organización y de dónde procede esa autoridad?
Poder hacer no equivale a estar autorizado
El Código Civil, en los artículos 1259 a 1262, contiene reglas básicas sobre contratación en nombre de otro, consentimiento y perfección contractual.
El artículo 1259 parte de que nadie puede contratar a nombre de otro sin autorización o representación legal, sin perjuicio de la posible ratificación en los términos previstos. Los artículos siguientes regulan elementos del consentimiento y del contrato.
La conclusión para sistemas agénticos no es que cada clic de un agente equivalga automáticamente a un contrato. Es más básica: la capacidad técnica de emitir una acción no crea por sí sola el poder jurídico para vincular a la organización.
El medio electrónico tampoco resuelve la autoridad
La Ley 34/2002 reconoce eficacia a la contratación electrónica cuando concurren los requisitos necesarios para su validez. El medio electrónico no elimina las preguntas sobre consentimiento, representación o contenido del acto.
Del mismo modo, el Reglamento eIDAS regula efectos jurídicos de instrumentos de identificación, firmas y sellos electrónicos. Esa infraestructura puede servir para autenticar o atribuir determinados actos. No convierte al agente en una persona jurídica independiente ni decide por sí sola si estaba autorizado a actuar.
Hay cuatro capas que deben separarse
1. Capacidad
Qué sabe hacer técnicamente el agente: leer, escribir, consultar, enviar, comprar, modificar, publicar, transferir o activar otra herramienta.
2. Permiso técnico
Qué credenciales y scopes tiene concedidos: acceso a una bandeja, un CRM, un ERP, una cuenta bancaria de pruebas, una API o un repositorio.
3. Mandato o autoridad
Qué actos puede realizar por cuenta de la organización y bajo qué límites: cuantía, destinatario, finalidad, duración, tipo de operación o necesidad de confirmación.
4. Validación y evidencia
Qué actos exigen intervención humana, qué se registra, cómo se revoca y cómo se reconstruye después la cadena de acciones.
Confundir estas cuatro capas es una fuente directa de riesgo.
Un permiso amplio puede ser técnicamente cómodo y jurídicamente defectuoso
Pensemos en un agente conectado a correo y calendario para coordinar reuniones. Para simplificar la integración se le conceden permisos amplios sobre toda la cuenta.
Técnicamente puede leer, enviar, borrar y modificar. Pero su finalidad quizá sea solo consultar disponibilidad y proponer horarios.
La arquitectura correcta no debería preguntar únicamente si el agente «se comportará bien». Debe limitar de forma verificable qué herramientas y actos tiene disponibles.
El principio es:
mínimo permiso técnico compatible con el mandato real.
Las confirmaciones deben situarse en los actos correctos
No todas las acciones necesitan el mismo control. Puede ser razonable permitir automáticamente algunas operaciones reversibles y de bajo impacto, mientras otras exigen confirmación.
La matriz puede distinguir, por ejemplo:
- lectura;
- preparación de borrador;
- modificación interna reversible;
- comunicación externa;
- aceptación de condiciones;
- compra o compromiso económico;
- publicación pública;
- eliminación;
- acceso a información especialmente sensible.
La clave es que el umbral de confirmación responda al radio de consecuencias, no a una idea abstracta de autonomía.
Una fuente de contenido no debe convertirse en autoridad
Los agentes pueden leer correos, documentos, webs y mensajes que contienen texto no confiable. Una de las amenazas características de estas arquitecturas es que una instrucción contenida en una fuente sea interpretada como orden operativa.
Las orientaciones de la AEPD sobre IA agéntica llaman la atención sobre autonomía, control de herramientas, permisos, intervención humana, trazabilidad y riesgos derivados de instrucciones maliciosas, entre otros aspectos.
La regla de arquitectura debe ser clara:
el contenido aporta información; no adquiere autoridad por estar escrito en una fuente que el agente puede leer.
La autoridad debe proceder de una capa distinta de permisos, políticas, validaciones y confirmaciones.
Revocar tiene que ser posible en tiempo real
Un mandato operativo que no puede retirarse con rapidez es difícil de gobernar.
La organización necesita saber:
- cómo suspender al agente;
- cómo revocar credenciales;
- cómo limitar una herramienta concreta;
- cómo detener una cadena multiagente;
- qué acciones ya se ejecutaron;
- qué puede revertirse;
- qué terceros deben ser informados si existe un incidente.
No basta con poder «desactivar el prompt». La capacidad de parada debe existir en la infraestructura.
Criterio H&C
No tratamos a un agente como «empleado digital», «apoderado digital» o persona jurídica por el mero hecho de que pueda actuar de forma autónoma.
Partimos de una secuencia más precisa:
finalidad → mandato → herramientas → permisos → acto → confirmación → evidencia → revocación.
La Matriz de permisos y actos de agentes de IA convierte esa secuencia en controles concretos.
La pregunta que debe poder contestar la organización
Para cada acción externa relevante debería ser posible responder:
- qué agente la ejecutó;
- bajo qué finalidad;
- con qué credencial;
- qué permiso la habilitó;
- qué límite jurídico y operativo tenía;
- si exigía confirmación;
- qué información utilizó;
- qué registro quedó;
- cómo podía haberse detenido.
Cuando esas respuestas no existen, la organización puede haber concedido capacidad técnica antes de haber diseñado autoridad.
Ese es el punto exacto en el que un proyecto de automatización se convierte en una cuestión de arquitectura jurídica.
Fuentes y referencias
Fuentes primarias
- Código Civil · artículos 1259 a 1262 · Derecho vigente
- Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico · Derecho vigente
- Reglamento (UE) n.º 910/2014 · eIDAS · Derecho vigente
Fuentes secundarias
- AEPD · Orientaciones sobre Inteligencia Artificial agéntica · Guía / criterio de autoridad · 2026-02-18