A continuación, se presenta la traducción al japonés del discurso de apertura pronunciado en la Conferencia Europea de Identidad y Nube 2026 (EIC 2026), celebrada en Berlín el 19 de mayo. Las diapositivas están disponibles en formato PDF al final de este documento.
La era en la que el software ya no es solo una herramienta.
Hola a todos.
Estamos entrando en una era en la que el software ya no es simplemente una herramienta.
Durante mucho tiempo, el software se centró en ejecutar instrucciones. Procesaba formularios, movía registros, realizaba cálculos, imponía flujos de trabajo y conectaba sistemas.
Pero ahora, el software está empezando a comportarse como un empleado humano.
No son empleados humanos. No son corporaciones. No son colegas en el sentido humano.
Se trata de un actor digital que se comporta como un empleado.
Les asignamos misiones y tareas, les damos autonomía y les proporcionamos las herramientas necesarias. Esperamos que coordinen, tomen decisiones, informen a la alta dirección, deleguen autoridad y obtengan resultados concretos.
Cuando el software alcanza ese nivel de capacidad, los problemas de gobernanza adquieren una forma diferente.
La pregunta ya no es simplemente: "¿Puede el modelo responder correctamente?".
No se trata solo de si la aplicación puede llamar a la API de forma segura.
La pregunta que hay que hacerse es:
- ¿Quién aprobó este trabajo?
- ¿De quién son las intenciones que se reflejan aquí?
- ¿Qué tipo de autoridad se delegó?
- ¿Qué se modificó durante el proceso de ejecución?
- ¿Quién puede detener esto?
- Y cuando surjan consecuencias, ¿quién será el responsable?
- Eso es
El software como personal e identidad
Al considerar esto, me gustaría comenzar con una propuesta sencilla:
Cuando el software se convierte en un empleado, la identidad se convierte en la piedra angular de la gobernanza.
La IA agente no se centra únicamente en la seguridad de los modelos, ni tampoco solo en la seguridad de las aplicaciones. Su esencia radica en la cuestión de los permisos delegados.
La delegación de autoridad siempre implica cuestiones de identidad, propiedad, control, pruebas, responsabilidad y confianza.
Las aplicaciones tradicionales solían operar dentro de los límites de una interfaz definida. La aplicación recibía instrucciones, ejecutaba funciones y devolvía resultados.
Sin embargo, los agentes son diferentes.
A los agentes se les asignan objetivos generales y ellos deciden cómo alcanzarlos. Esto puede implicar seleccionar herramientas, llamar a API, crear subtareas, colaborar con otros agentes, adaptarse a las circunstancias y actuar más allá de los límites de la organización.
Por eso"Equipo digital"Esa frase es útil.
Por supuesto, esto no se debe a que los agentes sean humanos.
Tradicionalmente, hemos esperado de nuestro personal que se les asigne un objetivo general y que luego decidan e implementen el método para alcanzarlo.
Les asignamos tareas, les damos poder y esperamos resultados. Y, en última instancia, alguien tiene que asumir la responsabilidad de sus actos, como si fueran nuestros subordinados.
Este patrón no se limita a las interacciones entre humanos y agentes; está empezando a surgir entre los propios agentes. Los agentes que reciben solicitudes ahora declaran qué pueden hacer, a qué zonas pueden llegar, qué habilidades poseen y qué certificaciones se requieren, y los clientes revisan esta información antes de asignarles el trabajo.
La función que descubre metadatos sobre la parte solicitante se denomina función de descubrimiento. Esta función también resulta útil en este caso.
Sin embargo, en el momento en que la fuente de los metadatos escapa a su control, surge la pregunta: "¿Podemos confiar realmente en ella?".
No está claro de inmediato si lo que dice ese agente es cierto, ni tampoco quién está detrás de ese agente.
Es posible que haya un Estado patrocinador del terrorismo detrás de esto.
Pero incluso antes de eso, surge la pregunta: ¿el agente con el que hablé ayer y el agente con el que estoy conectado actualmente son la misma persona?
Continuidad y coherencia de la identidad del agente
Ahora pasamos al primer problema difícil.
¿Qué significa que los agentes sean "el mismo agente"?
Para los empleados humanos, existe continuidad y coherencia (uniformidad) en su identidad. Aunque las personas aprendan, cambien de rol y adquieran experiencia, siguen siendo la misma persona en términos de responsabilidad.
Sin embargo, en el caso de los agentes de IA, esa continuidad y coherencia no son tan evidentes.
Si el modelo cambia, ¿sigue siendo el mismo agente?
Si el mensaje del sistema cambia, ¿se trata del mismo agente?
Si la memoria se reinicia, se fusiona o se comparte, ¿sigue siendo el mismo agente?
¿Qué sucede cuando cambia la cadena de herramientas? ¿Qué sucede cuando el proveedor cambia su política? ¿Qué sucede cuando cambia el entorno de ejecución? ¿Qué sucede cuando se reemplaza un subagente? ¿Qué sucede cuando una misión se transfiere de un ejecutor a otro? ¿Qué es exactamente ese "eso" en el que confiamos?
¿Y quién es el "propietario" responsable de estas acciones?
Esto plantea la siguiente pregunta:
¿Quién es el propietario o controlador de facto del agente?
Todo agente que actúa con autoridad necesita un propietario responsable.
私はこれを"Dueño de Bots Definitivo (UBO)"呼
Beneficiario final.
Esta expresión es intencional. En la normativa contra el blanqueo de capitales, el concepto de Propietario Último de la Empresa (OUE, por sus siglas en inglés) es fundamental. El OUE al que me refiero aquí es precisamente este OUE. La importancia del OUE radica en que la rendición de cuentas no debe verse interrumpida por una entidad jurídica nominal. Es necesario comprender qué es esto antes de contratar cualquier servicio.
De lo contrario, toda la red de agentes desplegados estaría expuesta a riesgos inaceptables. Esto es necesario para mitigar los riesgos de la cadena de suministro.
Misión
Otro aspecto que me gustaría presentar en esta exposición es nuestra "misión".
Esto es diferente de una "indicación". Una "indicación" es una instrucción.
También es diferente de una sesión. Una sesión es,Este es un lugar donde los agentes pueden continuar con su trabajo.La misión es diferente.
Una misión es un mandato controlado que se le otorga a un individuo o grupo para lograr un objetivo específico; es la razón por la cual se le permite a un agente continuar trabajando. Esto incluye objetivos, limitaciones, autoridad, recursos, plazos, políticas aplicables, requisitos de evidencia y un marco de rendición de cuentas para las acciones de una o más entidades.
Las misiones, los agentes y las sesiones son conceptos independientes y no deben confundirse. Una misión puede durar más que un agente, o puede terminar antes de que este se complete. Si una sesión aún está en curso cuando finaliza una misión, puede ser conveniente finalizar también la sesión.
Las acciones y sesiones de los agentes están limitadas por la misión. Los agentes solo deben actuar para completar la misión.
Una misión debe tener un alcance claramente definido, ser verificable, poder pausarse y estar justificada.
De lo contrario, los sistemas basados en agentes no solo realizarían tareas, sino que también transferirían permisos sin un registro fiable del origen de dichos permisos.
Los humanos asignan misiones a los agentes.
Los agentes formulan tareas y deciden las acciones a seguir dentro de las facultades discrecionales delegadas.
Dado que los agentes casi siempre son incapaces de asumir la responsabilidad, a menudo resulta necesario involucrar a personas en el proceso para obtener la aprobación.
La supervisión humana es importante.
El juicio humano resulta a veces esencial en acciones de gran impacto, procedimientos legales, decisiones reguladas, transferencias financieras, comunicaciones externas o divulgaciones irreversibles.
La escala importa
Sin embargo, si intentamos hacerlo todo de esta manera, nos enfrentaremos a problemas de escala.
Un solo trabajador puede gestionar docenas o incluso cientos de agentes. Para una organización, eso podría ascender a miles.
Los humanos no pueden aprobar de forma significativa cada paso. De hecho, existen estudios que sugieren que, incluso cuando se trata de un solo agente, las confirmaciones posteriores al tercer intento por tarea se vuelven meramente nominales.
Si 100 agentes solicitaran la aprobación uno tras otro a una sola persona, la aprobación se convertiría inevitablemente en una cuestión de inercia.
A esta escala, no se puede dejar la dirección únicamente en manos de la revisión humana. La "intervención humana" no es necesariamente una forma de gobernanza eficaz.
Las aprobaciones realizadas bajo presión de tiempo y con información incompleta no son decisiones verdaderas. El Código Claude ya se pronunció al respecto.
Eso es "procesamiento automatizado" disfrazado de juicio humano.
Necesitamos la ayuda de un agente de IA: un agente supervisor que actúe en nombre del principal, del delegador.
Este agente evalúa las evidencias y los indicios de riesgo, filtra la información irrelevante y comunica la información pertinente al cliente según sea necesario. Además, debe velar por los intereses de la persona u organización que originalmente delegó el trabajo. Debe ser leal al cliente, no a un sistema que intenta completar la tarea.
El agente de ejecución debe enviar informes estructurados al agente de monitoreo cuando detecte la intención de realizar una acción y durante la ejecución. Excepciones. Cambios. Resultados.
El sistema de generación de eventos tipo Shared Signals podría formar parte de este sistema nervioso. Pero, ¿contamos con estándares concretos para implementar este tipo de informes estructurados?
あ り ま せ ん.
Y la señal no es un interruptor de apagado.
Eso es solo una parte de la capa de señalización. También necesitamos un plano de control.
El plano de control debe poder intervenir. Debe poder pausar misiones, restringir privilegios, deshabilitar herramientas, bloquear la delegación, revocar credenciales, aislar la memoria, derivar el control a humanos o finalizar la misión.
¿Existen protocolos estándar para esto? No.
El sistema Agentic AI es un sistema de transacciones distribuidas.
Existe otra forma de entender el sistema de agentes.
Así es como se ve: como un sistema de objetos distribuidos y un sistema de transacciones distribuidas.
Comienza la misión. El agente llama a las herramientas. Llama a las API. Delega en subagentes. Modifica el estado. Envía mensajes. Y puede generar resultados externamente.
Desde hace tiempo se sabe que procesar transacciones a largo plazo resulta difícil en los sistemas distribuidos convencionales. El modelo Saga trata las transacciones a largo plazo como una sola unidad que se ejecuta, pero que puede dividirse en subtransacciones.
La IA con capacidad de gestión de agentes se enfrenta al mismo problema, pero es aún más difícil.
El coordinador puede ser parcialmente no determinista. El ejecutor puede depender del modelo. El siguiente paso puede depender del contexto.
Por lo tanto, las tareas, herramientas y habilidades de cada subagente deben declarar la semántica de sus propias consecuencias.
¿Se puede cancelar? ¿Se puede ofrecer una compensación? ¿Se puede avanzar hacia la recuperación? ¿O es irreversible?
El envío de borradores internos puede ser revocable. La cancelación de citas puede ser compensada. Las correcciones en el flujo de trabajo pueden ser reversibles. Sin embargo, la divulgación de datos confidenciales es irreversible.
No se puede dirigir una misión sin saber qué partes aún se pueden revertir.
La IA agencial transforma las transacciones distribuidas en toma de decisiones distribuida.
Y ese juicio debe ser limitado, observable e interceptable.
Publicidad de metadatos a través de tarjetas de agente
Ahora, la atención se centra en las tarjetas de los agentes.
La ficha de un agente es una descripción que incluye su nombre, proveedor, punto final, capacidades, habilidades, método de autenticación y requisitos de interacción. En el futuro, incluso podría representar características transaccionales, como si la transacción se puede revertir o no.
Son importantes para el descubrimiento, la declaración de características, el descubrimiento de puntos finales y la selección de protocolos. Sin embargo, es fundamental comprender con precisión qué problemas resuelven y cuáles no.
La ficha del agente puede indicar lo que este afirma poder hacer. Sin embargo, eso por sí solo no indica de lo que es capaz.
- No voy a demostrar que soy apto para esta misión.
- Tampoco demuestra que el entorno de ejecución sea fiable.
- Tampoco verifica el modelo, el mensaje, la memoria ni las versiones de las políticas.
- Ultimate-Bot-Owner tampoco lo demuestra. Y,
- La parte que confía en este agente no garantiza que sea digno de confianza en esta transacción.
Las tarjetas de agente autodeclaradas son insuficientes desde una perspectiva de gobernanza.
Incluso una tarjeta de agente firmada es solo un paso adelante. La firma simplemente nos indica que una persona clave ha firmado algo.
El verificador también debe determinar si el firmante, la clave, el emisor y el marco de confianza son aceptables para este propósito.
- La identificación no es lo mismo que la confianza.
- El descubrimiento no es autoridad.
- Los metadatos no sustituyen la rendición de cuentas.
Patrón SPIFFE/SPIRE
Al considerar estos aspectos, los patrones SPIFFE y SPIRE pueden resultar útiles.
SPIFFE y SPIRE no son especificaciones estándar para la gobernanza de agentes. Sin embargo, proporcionan patrones de los que podemos aprender.
Una carga de trabajo no debería simplemente declarar quién es; debería autenticarse antes de que se le otorgue esa identidad.
Sin embargo, para la IA agente, la identidad de la carga de trabajo es solo el punto de partida.
La certificación puede ayudar a responder a la pregunta: "¿Qué se está haciendo?".
Sin embargo, la certificación no puede responder a las siguientes preguntas.
- ¿De quién es la misión que se está llevando a cabo?
- ¿Qué tipo de autoridad se delegó?
- ¿Qué modelo o consigna se utilizó?
- ¿Qué política se aplicó?
- ¿Es posible obtener una indemnización por esa acción?
- ¿Quién es el beneficiario final (UBO)?
Por lo tanto, además de la prueba de carga de trabajo, se requieren pruebas de misión, pruebas de autorización, semántica de transacciones e informes de monitoreo.
Creación de marcos de confianza mediante la federación
Aquí es donde entra en juego el concepto de "federación".
La tarjeta del agente indica qué se está reclamando.
La certificación proporciona información sobre lo que se está haciendo.
Las federaciones pueden ayudarle a determinar en qué reclamaciones o certificaciones confiar.
La federación OpenID define cómo las entidades que buscan interactuar entre sí establecen relaciones de confianza a través de terceros de confianza denominados "anclas de confianza". Admite múltiples niveles de autoridad, y una misma entidad puede pertenecer a varias federaciones. Además, proporciona los componentes de infraestructura técnica de confianza para construir redes de confianza dinámicas y descentralizadas.
La federación nos permite verificar si la clave de firma pertenece a una entidad dentro de un marco de confianza que aprobamos, si existe una cadena de confianza válida, si se aplican políticas de metadatos y si la marca de confianza es significativa para esta parte dependiente.
Esto es sumamente importante en la gobernanza de agentes.
Un mundo en el que cada parte tenga que decidir manualmente si acepta o rechaza a cada agente, proveedor, registro, emisor de certificados y beneficiario final es indeseable.
Es necesario establecer una cadena de confianza y políticas de metadatos. Se requiere un mecanismo para determinar qué reclamaciones aceptar antes de ejercer cualquier autoridad. Para ello, un mecanismo de federación resulta muy útil.
La importancia de utilizar estándares
Ya existen muchos componentes útiles para lograr estos objetivos. Tan solo las especificaciones relacionadas con OpenID incluyen las que se enumeran aquí.
- OpenID Connect
- OpenID4VCI/VP
- Autenticación
- Federación OpenID
- Marco de señales y eventos compartidos de OpenID
- etc.
Muchos de ellos han sido verificados matemática y formalmente desde una perspectiva de seguridad.
Por supuesto, esto por sí solo no basta. Sin embargo, debemos reutilizar lo que sea reutilizable y construir solo lo que sea realmente necesario.
Responsabilidad civil y desafíos actuariales
Finalmente, permítanme plantear la pregunta a la que inevitablemente llega la gobernanza.
¿Quién asumirá la pérdida?
Cuando un agente filtra datos, desvía pagos, manipula flujos de trabajo, envía instrucciones incorrectas o desencadena una reacción en cadena perjudicial, ¿dónde recae la responsabilidad en última instancia?
Desde esta perspectiva, Ultimate-Bot-Owner también cobra importancia.
Y ahí radica la importancia de las pruebas. Sin pruebas, la rendición de cuentas se debilita. La determinación de la responsabilidad se convierte en mera especulación, y el seguro no es más que una conjetura.
Actualmente, la base actuarial para evaluar los riesgos asociados con la IA agente aún se encuentra en sus primeras etapas. Sin embargo, eso no significa que debamos esperar. Ahora es el momento de construir la infraestructura de medición.
Los seguros no se limitan a eslóganes. Se necesitan datos sobre el grado de exposición al riesgo, la frecuencia de los incidentes, la gravedad de los daños, la eficacia de la gestión, las relaciones causales y las pérdidas.
El software se está convirtiendo en un empleado.
La gobernanza en estos asuntos se está volviendo necesaria.
Existen especificaciones estándar que se pueden utilizar.
Sin embargo, simplemente construir una infraestructura de agentes bien gobernada no es suficiente. Hay muchas deficiencias que deben subsanarse.
Para la comunidad de Identerati, nuestro camino hacia la construcción de un ecosistema de agentes confiables no ha hecho más que empezar.
Trabajemos todos juntos y comencemos a hacerlo ahora mismo.