La Inteligencia Artificial está evolucionando desde sistemas que simplemente responden preguntas o generan contenidos hacia agentes capaces de actuar. Un agente de IA puede consultar información, acceder a aplicaciones corporativas, modificar datos en un ERP, enviar comunicaciones, interactuar con otros sistemas, iniciar procesos de compra o incluso intervenir en operaciones económicas.
Este cambio plantea una cuestión fundamental: cuando un agente realiza una operación, ¿cómo sabemos quién es, en nombre de quién está actuando y qué está autorizado a hacer?
De identificar personas a identificar agentes
Durante años, los sistemas de identidad digital se han diseñado principalmente para identificar y autenticar personas. Utilizamos certificados electrónicos, firma electrónica, autenticación multifactor, credenciales corporativas o sistemas de identidad federada para acreditar quién está accediendo a un sistema.
Los agentes de IA introducen un escenario diferente. El sujeto que interactúa técnicamente con un sistema puede ser un componente software autónomo que actúa siguiendo determinadas instrucciones y utilizando permisos concedidos previamente por una persona o una organización.
Por ello, identificar únicamente al usuario que creó o configuró inicialmente el agente puede resultar insuficiente. También necesitamos poder identificar de forma inequívoca qué agente concreto ha ejecutado cada operación.
Identidad, representación y autorización son cosas diferentes
Uno de los aspectos más importantes es distinguir tres conceptos: identidad, representación y autorización.
La identidad responde a la pregunta “¿qué agente es?”. La representación responde a “¿en nombre de quién está actuando?”. Y la autorización determina “¿qué puede hacer?”.
Un agente podría estar perfectamente identificado técnicamente y, sin embargo, intentar ejecutar una operación para la que no dispone de autorización.
Por ejemplo, una empresa podría permitir que un agente consulte proveedores y prepare pedidos, pero no que formalice compras superiores a 5.000 euros. La identidad del agente sería la misma en ambos casos; lo que cambia es el alcance del mandato que se le ha concedido.
Por eso, la arquitectura debería permitir establecer una cadena verificable:
Persona u organización → mandato → agente → credencial → autorización → operación → evidencia
eIDAS2 y la representación electrónica
En Europa existe una base especialmente interesante para construir este modelo: eIDAS2, resultado de la modificación del Reglamento (UE) nº 910/2014 mediante el Reglamento (UE) 2024/1183.
El marco europeo de identidad digital permite trabajar no solamente con identificación electrónica, sino también con atributos y mecanismos de representación. Entre los atributos contemplados aparecen precisamente los poderes y mandatos para representar a personas físicas o jurídicas.
Esto resulta especialmente relevante para los futuros agentes digitales.
Aunque eIDAS2 no crea actualmente una categoría jurídica específica denominada “identidad del agente de IA”, proporciona elementos que pueden utilizarse para construir cadenas de confianza en las que sea posible acreditar quién concede una representación y cuáles son los atributos o poderes asociados.
Reglamento europeo de identidad digital eIDAS2
Una identidad propia para cada agente
Desde una perspectiva de seguridad, no debería ser suficiente que varios agentes utilicen una misma cuenta técnica genérica.
Cada agente debería disponer de una identidad única, vinculada a unas credenciales determinadas y a un responsable o propietario claramente identificado.
Esa identidad podría apoyarse, dependiendo de la arquitectura, en certificados digitales, claves criptográficas, mecanismos de workload identity, OAuth, mTLS u otras tecnologías equivalentes.
Un ejemplo especialmente interesante es SPIFFE, un estándar orientado a proporcionar identidad criptográfica a cargas de trabajo y componentes software. Mediante identificadores SPIFFE y credenciales SVID es posible identificar servicios o procesos sin tratarlos como si fueran usuarios humanos.
SPIFFE – Secure Production Identity Framework for Everyone
No basta con saber quién es: hay que saber qué puede hacer
La segunda gran pieza es la autorización.
Un agente debería trabajar bajo el principio de mínimo privilegio. No debería disponer permanentemente de todos los permisos de la persona o empresa a la que representa.
La autorización debería establecer límites concretos: qué aplicaciones puede utilizar, qué información puede consultar, qué operaciones puede realizar, sobre qué recursos, durante cuánto tiempo y, cuando proceda, hasta qué importe económico.
Tecnologías como OAuth permiten implementar parte de esta separación entre identidad y autorización. Además, mecanismos como OAuth con Mutual TLS (mTLS) permiten vincular criptográficamente determinadas credenciales y tokens.
RFC 8705 – OAuth 2.0 Mutual-TLS Client Authentication
Esto permite imaginar autorizaciones mucho más granulares: un agente podría tener capacidad para consultar facturas y preparar órdenes de pago, pero necesitar autorización humana adicional para ejecutarlas.
El mandato del agente
Aquí aparece probablemente una de las cuestiones más importantes desde el punto de vista jurídico.
Además de identificar al agente y autenticarlo técnicamente, necesitamos poder demostrar por qué tenía derecho a realizar determinada operación.
El mandato debería poder responder, como mínimo, a preguntas como: quién autorizó al agente, cuándo lo hizo, qué operaciones autorizó, durante cuánto tiempo, sobre qué sistemas, con qué límites y en qué circunstancias debe solicitar intervención humana.
En operaciones relevantes, además, ese mandato debería ser verificable y revocable.
Podemos imaginar, por ejemplo, una autorización:
Empresa X → Agente Compras-01 → proveedores homologados → máximo 5.000 € por operación → vigencia 30 días.
La autorización deja entonces de ser una simple configuración interna del software y se convierte en una pieza fundamental de la evidencia de la operación.
La trazabilidad será tan importante como la identidad
Identificar correctamente al agente no sirve de mucho si después no podemos reconstruir lo ocurrido.
Los sistemas deberían conservar evidencias suficientes para determinar qué agente realizó una acción, en nombre de quién, qué autorización utilizó, qué información recibió, qué operación ejecutó y cuál fue su resultado.
Cuando la criticidad de la operación lo justifique, estas evidencias deberían incorporar mecanismos que permitan proteger su integridad, como hashes, sellos electrónicos, sellos de tiempo o sistemas equivalentes.
El Reglamento Europeo de Inteligencia Artificial también concede especial importancia al registro y trazabilidad en determinados sistemas de IA, particularmente en el régimen aplicable a los sistemas de alto riesgo.
Reglamento (UE) 2024/1689 de Inteligencia Artificial
Las normas ISO también proporcionan una base
La familia ISO/IEC 24760 proporciona un marco conceptual para la gestión de identidades y resulta especialmente interesante para analizar este nuevo escenario.
ISO/IEC 24760-1:2025 establece conceptos relacionados con identidad y gestión de información de identidad que pueden utilizarse para diseñar arquitecturas en las que intervengan componentes informáticos, organizaciones y personas.
A ello pueden añadirse estándares relacionados con autenticación y niveles de garantía, como ISO/IEC 29115, además de las normas y especificaciones ETSI relacionadas con identificación electrónica y servicios de confianza.
El ciclo de vida también debe controlarse
La identidad de un agente no debería ser permanente ni independiente de su contexto.
Un sistema adecuado debería contemplar el alta, modificación, suspensión y revocación de agentes y de sus credenciales.
Si un empleado abandona la empresa, cambia de departamento o pierde determinados poderes, los agentes que actuaban bajo sus autorizaciones también deberían verse afectados cuando corresponda.
Lo mismo sucede cuando un agente es sustituido por otro, cambia significativamente su configuración o se detecta un incidente de seguridad.
La gestión de identidad del agente debe contemplarse, por tanto, durante todo su ciclo de vida.
Hacia una identidad digital de agentes de IA
A medida que los agentes comiencen a interactuar directamente entre empresas, APIs, entidades financieras, administraciones y otros agentes, disponer de mecanismos verificables de identidad será cada vez más importante.
No será suficiente que un sistema declare: “soy un agente de la empresa X”.
El sistema receptor necesitará poder comprobar criptográficamente la identidad del agente, determinar quién lo controla, verificar la representación que posee, conocer qué operaciones tiene autorizadas y conservar evidencia de la transacción.
Estamos pasando, por tanto, de un modelo tradicional de Identity & Access Management (IAM) centrado principalmente en personas a otro en el que convivirán identidades humanas, identidades organizativas e identidades no humanas (NHI).
La pregunta fundamental de cualquier auditoría
Desde el punto de vista de auditoría, la cuestión puede resumirse en una pregunta aparentemente sencilla:
¿Podemos demostrar quién realizó la operación, en nombre de quién, con qué autorización y qué ocurrió exactamente?
Para responder adecuadamente será necesario evaluar conjuntamente la identidad del agente, su propietario o responsable, el mandato recibido, sus credenciales, las autorizaciones concedidas, la autenticación utilizada, la trazabilidad de las operaciones y los mecanismos de revocación.
Una posible estructura de control podría resumirse como:
IDENTITY → OWNER → MANDATE → AUTHORIZATION → AUTHENTICATION → TRANSACTION → EVIDENCE → REVOCATION
La identidad de los agentes de IA probablemente se convertirá en uno de los grandes retos de confianza digital de los próximos años. Cuando un agente deja de limitarse a recomendar y empieza a actuar, identificarlo ya no es suficiente: debemos poder demostrar quién le permitió actuar, hasta dónde podía llegar y qué hizo realmente.
