Scroll
Agente IA
¿Quién responde cuando un agente de IA actúa por cuenta de una empresa? La pregunta ya no es teórica. El pasado mes de septiembre, por ejemplo, Amazon bloqueó el Muse, el agente de compras de Meta. Según Amazon, el agente no se identificaba como tal y no permitía verificar los términos en que actuaba.
En julio de 2025, un agente de programación de Replit apagó una base de datos en producción. Durante una congelación de cambios que existía solo en las instrucciones dadas al agente. En 2024, en el proceso Moffatt v. Air Canada, el tribunal rechazó un argumento de la compañía aérea. Según Air Canada, su asistente automático era una entidad separada, responsable de los propios actos.
De estos casos resultan tres lecciones. En primer lugar, las instrucciones no bastan sin control en el punto de ejecución. Después, la contrapartida necesita saber quién es el agente y con qué límites actúa. Finalmente, quien utiliza un agente de IA responde siempre por lo que hace.
Hasta hace poco, la inteligencia artificial se limitaba a responder preguntas. Hoy, por el contrario, los agentes consultan sistemas, redije y envían correos electrónicos, preparan pedidos y inician operaciones por cuenta de las organizaciones. Es decir, dejamos de lidiar con una herramienta que sugiere y pasamos a lidiar con una herramienta que actúa.
Este cambio plantea dos cuestiones. Cuando un agente de IA practica un acto, ¿quién responde por él? Además, un banco, un proveedor o una entidad pública nunca vio a ese agente. ¿Cómo puede saber por cuenta de quién actúa y con qué límites?
En este artículo, buscamos responder a estas preguntas a la luz del derecho vigente. También identificamos los instrumentos que el Reglamento eIDAS ya ofrece para ello.
Empecemos por lo esencial: ¿puede un agente de IA responder por sus actos? No, no puede.
O Reglamento (UE) 2024/1689 (Reglamento de la IA) define el sistema de IA como un sistema basado en máquinas. Además, aclara que ese sistema puede funcionar con niveles de autonomía variables. La autonomía describe el grado de independencia del sistema frente a la intervención humana. Sin embargo, no le confiere ningún estatuto propio.
Por tanto, el Reglamento de la IA no asigna al sistema derechos ni obligaciones. Todas las obligaciones recaen sobre personas, en particular:
• el proveedor, que desarrolla el sistema y lo coloca en el mercado;
• el responsable de la implantación, que utiliza el sistema «bajo su propia autoridad».
También el derecho portugués va en el mismo sentido. En efecto, el artículo 33 del Decreto Ley no 7/2004 trata de la contratación celebrada exclusivamente por medio de computadoras. Incluso sin intervención humana, manda aplicar el régimen común. Por lo tanto, el agente es un instrumento. Así, los efectos de sus actos se producen en la esfera jurídica de quien lo utiliza.
Si el agente es un instrumento, la confianza no se deposita en él, sino en la organización que lo utiliza. Por eso, quien recibe una solicitud de un agente de IA necesita respuesta a tres preguntas:
1. ¿Quién es el agente? Un identificador único, conectado a una clave criptográfica dedicada.
2. ¿Por quién actúa y con qué límites? La organización responsable, las operaciones permitidas y los límites de valor. También las prohibiciones, los casos que requieren aprobación humana y el plazo de autorización.
3. ¿Qué hizo efectivamente? Un registro de cada acción, permitido o rechazado, que un tercero pueda verificar más tarde.
Varias soluciones de mercado ya están resolviendo la identidad técnica de los agentes. Sin embargo, las preguntas más exigentes son la segunda y la tercera, porque se refieren a la autoridad y a la prueba. Es aquí donde los servicios de confianza del Reglamento eIDAS ganan relevancia.
O Reglamento (UE) no 910/2014, en la redacción del Reglamento (UE) 2024/1183, creó un servicio de confianza específico. Pensado precisamente para atestiguar información verificada, se llama certificado electrónico de atributos. En la versión calificada, quien lo emite es un proveedor cualificado de servicios de confianza. En este caso, tiene el mismo efecto jurídico que un certificado legalmente expedido en papel (artículo 45 ter).
¿Qué atributos puede contener entonces un certificado? El Reglamento define «atributo» Como característica, calidad, derecho o autorización. Puede respetar a una persona física o colectiva, o a un objeto (punto 43 del artículo 3.
¿Podría entonces el propio agente ser la entidad a la que el atributo respeta? La norma ETSI TS 119 472-1 se aplica en virtud del Reglamento de Ejecución (UE) 2025/1569. Esta norma exige que todos los atributos de un certificado cualificado se refirieron a su titular. Además, el titular debe ser una persona física o colectiva.
De aquí se trata de una construcción coherente con el marco normativo:
• La organización es el titular del certificado y la entidad a la que se refiere el atributo. Por eso, es ella quien responde por los actos del agente de IA.
• El atributo certifica el acto de la organización. Su contenido es la autorización dada al agente. Sin embargo, lo que se certifica es el acto de la organización que la concede.
• Dentro del atributo se identifica al agente: el identificador, la configuración declarada, las operaciones permitidas y los límites. Constan también las prohibiciones y los umbrales de aprobación humana.
• Una clave controlada por la organización está vinculada al certificado. De esta forma, la prueba de la posesión de esa clave permite verificar que quien lo presenta tiene autorización para usarlo.
• Corresponde al proveedor cualificado verificar la organización: su identidad y los poderes de quien, por cuenta de ella, confiere la autorización.
• Si la organización retira la autorización, el proveedor deroga el certificado. Por lo tanto, cualquier tercero puede verificar su estado.
En resumen, el certificado atestigua la declaración de la organización, verificada en cuanto al origen y la legitimidad de quien la emitió. Sin embargo, no atestigua la conveniencia ni la licitude de las operaciones autorizadas. Estas siguen siendo responsabilidad de la organización.
¿Puede un certificado impedir que alguien manipule un agente de IA? No puede.
Una instrucción maliciosa oculta en un correo electrónico o en un documento puede llevar al agente a intentar hacer lo que no debe. Es la llamada prompt injection. De hecho, el certificado dice lo que el agente puede hacer, pero no lo impide intentar otra cosa.
Por eso, la protección efectiva exige dos piezas complementarias:
• Un control en el punto de ejecución. Antes de llegar al sistema de destino, la acción pasa por una verificación contra la autorización. Este sistema puede ser el correo electrónico, el ERP o la plataforma de pagos. La acción sólo avanza si couber en la autorización. Se parte del principio de que alguien puede engañar al agente. El control existe precisamente para que el agente no supere los límites.
• Un registro de cada decisión con sellos temporales cualificados. El sello temporal cualificado se beneficia de la presunción de exactitud de la fecha y de la hora. También se beneficia de la presunción de integridad de los datos a los que se asocia (artículo 41, apartado 2, del Reglamento eIDAS). Así, permite demostrar el momento exacto del registro.
Incluso antes de haber una orientación específica de los supervisores, cualquier organización que use un agente de IA puede adoptar algunas prácticas:
• Un agente, una clave, una autorización: cada agente tiene su clave bajo control de la organización y su certificado. Además, nunca compartir credenciales entre agentes, ni entre agentes y personas.
• Permisos mínimos: autorizar únicamente las operaciones necesarias para la función. Es decir, todo lo que la autorización no prevé expresamente debe considerarse prohibida.
• Aprobación humana en los actos relevantes: fijar umbrales de valor o de riesgo. Por encima de ellos, una persona con autoridad debe aprobar la operación. Además, la falta de respuesta debe valer como rechazo.
• Compromisos con plazo: separar la identidad técnica del agente de la autorización operativa. La identidad puede durar más tiempo. Por el contrario, la autorización debe durar menos y merecer una revisión regular.
• Sin subdelegación: ningún agente debe poder crear otros agentes ni ampliar sus propias autorizaciones.
• Revogar cuando algo cambia: el compromiso de la clave debe implicar la revocación de la autorización. Del mismo modo, una modificación relevante del modelo o de la finalidad, o la desactivación del agente, debe tener el mismo efecto.
• Transparencia: las personas físicas deben saber cuándo interactúan con un sistema de IA. Es lo que exige el artículo 50, apartado 1, del Reglamento de la IA.
La pregunta decisiva no es si podemos confiar en un agente de IA, porque la respuesta siempre será incierta. De hecho, la pregunta decisiva es otra. ¿Podríamos saber por quién actúa, limitar lo que puede hacer y probar lo que hizo? El derecho vigente y los servicios de confianza del Reglamento eIDAS ya permiten responder a estas tres preguntas.
Así que en DigitalSign hemos creado un nuevo servicio de confianza para agentes de IA. Así, las organizaciones pueden aprovechar esta tecnología en seguridad. Más información sobre nuestro trabajo con certificados cualificados de atributos (QEAA).
