Segue abaixo a tradução para japonês do discurso de abertura proferido na Conferência Europeia de Identidade e Nuvem de 2026 (EIC 2026), realizada em Berlim no dia 19 de maio. Os slides estão disponíveis em formato PDF no final deste documento.
A era em que o software deixou de ser apenas uma ferramenta.
olá pessoal.
Estamos entrando em uma era em que o software deixou de ser apenas uma ferramenta.
Durante muito tempo, o software serviu apenas para executar instruções. Ele processava formulários, movia registros, realizava cálculos, aplicava fluxos de trabalho e conectava sistemas.
Mas agora, o software está começando a se comportar como um funcionário humano.
Eles não são funcionários humanos. Não são empresas. Não são colegas no sentido humano.
Trata-se de um ator digital que se comporta como um funcionário.
Atribuímos missões e tarefas a eles, os capacitamos e lhes fornecemos as ferramentas. Esperamos que eles coordenem tarefas, tomem decisões, reportem à alta administração, deleguem autoridade e produzam resultados no mundo real.
Quando o software se torna capaz de tanto, as questões de governança assumem uma forma diferente.
A questão já não é simplesmente: "O modelo consegue responder corretamente?"
Não se trata apenas de saber se o aplicativo pode chamar a API com segurança.
A pergunta a fazer é:
- Quem aprovou este trabalho?
- De quem são as intenções refletidas aqui?
- Que tipo de autoridade foi delegada?
- O que foi alterado durante o processo de execução?
- Quem pode impedir isso?
- E quando surgirem as consequências, quem será responsabilizado?
- Isso é.
Software como ferramenta de gestão de pessoal e identidade
Ao considerar isso, gostaria de começar com uma proposta simples:
Quando o software se torna um funcionário, a identidade se torna a pedra angular da governança.
O foco da IA agente não está apenas na segurança do modelo. Nem apenas na segurança da aplicação. Em sua essência, reside a questão das permissões delegadas.
Delegar autoridade sempre envolve questões de identidade, propriedade, controle, evidências, responsabilidade e confiança.
Os aplicativos tradicionais normalmente operavam dentro dos limites de uma interface definida. O aplicativo recebia instruções, executava funções e retornava resultados.
No entanto, os agentes são diferentes.
Os agentes recebem objetivos gerais e decidem como alcançá-los. Isso pode envolver a seleção de ferramentas, o uso de APIs, a criação de subtarefas, a colaboração com outros agentes, a adaptação às circunstâncias e a atuação além dos limites organizacionais.
Por isso"Equipe Digital"Essa frase é útil.
É claro que isso não se deve ao fato de os agentes serem humanos.
Receber uma meta geral e, em seguida, decidir e implementar o método para alcançá-la é o que tradicionalmente esperamos de nossa equipe.
Atribuímos tarefas a eles, damos-lhes autonomia e esperamos resultados. E, no fim das contas, alguém tem que assumir a responsabilidade por suas ações, como se fossem nossos subordinados.
Esse padrão não se limita às interações entre humanos e agentes; ele está começando a surgir entre os próprios agentes. Os agentes que recebem solicitações agora declaram o que podem fazer, onde podem chegar, quais habilidades possuem e quais certificações são necessárias, e os clientes revisam essas informações antes de atribuir tarefas.
A função que descobre metadados sobre a parte solicitante é chamada de função de descoberta. A função de descoberta também é útil neste caso.
No entanto, no momento em que a fonte dos metadados sai do seu controle, surge a questão: "Podemos realmente confiar nisso?"
Não está imediatamente claro se o que esse agente está dizendo é verdade, nem quem está por trás dele.
Pode haver um Estado patrocinador do terrorismo por trás disso.
Mas antes disso, surge a questão: o agente com quem falei ontem e o agente com quem estou conectado agora são a mesma pessoa?
Continuidade e consistência da identidade do agente
Agora vamos abordar o primeiro problema difícil.
O que significa para os agentes serem "o mesmo agente"?
Para os funcionários humanos, existe continuidade e consistência (uniformidade) em sua identidade. Mesmo quando aprendem, mudam de função e adquirem experiência, permanecem as mesmas pessoas em termos de responsabilidade.
No entanto, no caso de agentes de IA, essa continuidade e consistência não são tão óbvias.
Se o modelo mudar, ainda será o mesmo agente?
Se a mensagem do sistema mudar, trata-se do mesmo agente?
Se a memória for reinicializada, mesclada ou compartilhada, ainda será o mesmo agente?
O que acontece quando a cadeia de ferramentas muda? O que acontece quando o provedor altera sua política? O que acontece quando o ambiente de execução muda? O que acontece quando um subagente é substituído? O que acontece quando uma missão é transferida de um executor para outro? O que exatamente é esse "isso" em que confiamos?
E quem é o "proprietário" responsável por essas ações?
Isso levanta a seguinte questão:
Quem é o proprietário ou controlador de fato do agente?
Todo agente que exerce autoridade precisa de um proprietário responsável.
Eu tenho isso"Proprietário Supremo de Bots (UBO)"Eu chamo isso.
UBO.
Essa expressão é intencional. Nas regulamentações de lavagem de dinheiro, o conceito de Beneficiário Final (UBO, na sigla em inglês) é crucial. O UBO ao qual me refiro aqui é este mesmo UBO. A importância do UBO reside no fato de que a responsabilidade não deve ser comprometida por uma entidade jurídica nominal. É fundamental compreender o que isso significa antes de encomendar qualquer serviço.
Caso contrário, toda a rede de agentes implantada ficaria exposta a riscos inaceitáveis. Isso é necessário para mitigar os riscos da cadeia de suprimentos.
Missão
Outro aspecto que gostaria de apresentar nesta apresentação é a nossa "missão".
Isso é diferente de um "sugestão". Um "sugestão" é uma instrução.
Também é diferente de uma sessão. Uma sessão é,Este é um local onde os agentes podem continuar seu trabalho.A missão é diferente disso.
Uma missão é um mandato controlado, atribuído a um indivíduo ou grupo, para atingir um objetivo específico; é a razão pela qual um agente tem permissão para continuar trabalhando. Isso inclui objetivos, restrições, autoridade, recursos, cronograma, políticas aplicáveis, requisitos de evidência e uma estrutura de responsabilização pelas ações de uma ou mais entidades.
Missões, agentes e sessões são conceitos independentes e não devem ser confundidos. Uma missão pode durar mais tempo que um agente, ou pode terminar antes que um agente seja concluído. Se uma sessão ainda estiver em andamento quando uma missão terminar, pode ser apropriado encerrar também a sessão.
As ações e sessões dos agentes são limitadas pela missão. Os agentes só podem agir para cumprir a missão.
Uma missão deve ter um escopo claramente definido, ser verificável, poder ser pausada e ser justificada.
Caso contrário, os sistemas baseados em agentes não apenas executariam tarefas, mas também transfeririam permissões sem um registro confiável da origem dessas permissões.
Os humanos atribuem missões aos agentes.
Os agentes formulam tarefas e decidem sobre as ações dentro do poder discricionário que lhes é delegado.
Como os agentes quase sempre são incapazes de assumir responsabilidades, muitas vezes torna-se necessário envolver humanos no processo para obter aprovação.
A supervisão humana é importante.
O julgamento humano é, por vezes, essencial em ações de grande impacto, processos judiciais, decisões regulamentadas, transferências financeiras, comunicações externas ou divulgações irreversíveis.
O problema da escala
No entanto, se tentarmos fazer tudo dessa maneira, enfrentaremos problemas de escala.
Um único funcionário pode gerenciar dezenas ou até mesmo centenas de agentes. Para uma organização, isso pode representar milhares.
Os seres humanos não conseguem aprovar de forma significativa cada passo. Aliás, existem estudos que sugerem que, mesmo quando se trata de um único agente, as confirmações após a terceira tentativa por tarefa tornam-se meramente nominais.
Se 100 agentes solicitassem aprovação um após o outro de uma única pessoa, a aprovação inevitavelmente se tornaria uma questão de inércia.
Nessa escala, não é possível deixar a direção exclusivamente para a revisão humana. "Humano no circuito" não é necessariamente uma forma significativa de governança.
Aprovações feitas sob pressão de tempo e com informações incompletas não são decisões verdadeiras. O Código Claude já comentou sobre essa situação.
Trata-se de "processamento automatizado" disfarçado de julgamento humano.
Precisamos da ajuda de um agente de IA — um agente supervisor que esteja do lado do principal, do delegador.
Este agente avalia evidências e sinais de risco, filtra informações irrelevantes e reporta informações relevantes ao cliente conforme necessário. E deve estar do lado da pessoa ou organização que originalmente delegou o trabalho. Deve ser leal ao cliente, não a um sistema que tenta concluir a tarefa.
O agente de execução deve enviar relatórios estruturados ao agente de monitoramento quando formar uma "intenção" de realizar uma ação e durante a execução. Exceções. Alterações. Resultados.
O registro de eventos do tipo Shared Signals poderia fazer parte desse sistema nervoso. Mas temos padrões concretos para implementar esse tipo de relatório estruturado?
あ り ま せ ん.
E o sinal não é um interruptor de desligamento.
Isso é apenas parte da camada de sinalização. Também precisamos de um plano de controle.
O plano de controle deve ser capaz de intervir. Deve ser capaz de pausar missões, restringir privilégios, desativar ferramentas, bloquear delegação, revogar credenciais, isolar memória, escalar para humanos ou encerrar a própria missão.
Existem protocolos padrão para isso? Não.
O sistema de IA Agentic é um sistema de transações distribuídas.
Existe outra maneira de entender o sistema agentivo.
É assim que você o vê: como um sistema de objetos distribuídos e um sistema de transações distribuídas.
A missão começa. O agente aciona ferramentas. Chama APIs. Delega tarefas a subagentes. Reescreve o estado. Envia mensagens. E pode gerar resultados externamente.
Há muito se sabe que o processamento de transações de longo prazo é difícil em sistemas distribuídos convencionais. O modelo Saga considera as transações de longo prazo como sendo executadas como uma única unidade, porém divisível em subtransações.
A IA agente enfrenta o mesmo problema, mas é ainda mais difícil.
O coordenador pode ser parcialmente não determinístico. O executor pode depender do modelo. O próximo passo pode depender do contexto.
Portanto, as tarefas, ferramentas e habilidades de cada subagente devem declarar a semântica de suas próprias consequências.
É possível cancelar? É possível obter indenização? É possível avançar no processo de recuperação? Ou é irreversível?
O envio de rascunhos internos pode ser passível de retratação. O cancelamento de compromissos pode ser compensado. Alterações no fluxo de trabalho podem ser revertidas. No entanto, a divulgação de dados confidenciais é irreversível.
Não é possível governar uma missão sem saber quais partes ainda podem ser revertidas.
A IA agética transforma transações distribuídas em tomada de decisão distribuída.
E esse julgamento deve ser delimitado, observável e interceptável.
Publicidade de metadados por meio de cartões de agente
Agora, os holofotes se voltam para os cartões dos agentes.
Um cartão de agente é uma autodescrição do agente, incluindo seu nome, provedor, endpoint, capacidades, habilidades, método de autenticação e requisitos de interação. E, futuramente, poderá até mesmo representar características transacionais, como a possibilidade de reversão da transação.
Esses elementos são importantes na descoberta, declaração de funcionalidades, descoberta de endpoints e seleção de protocolos. No entanto, é crucial ter uma compreensão precisa do que eles resolvem e do que não resolvem.
O cartão do agente pode indicar o que ele alega ser capaz de fazer. No entanto, isso por si só não informa o que o agente realmente faz.
- Não vou provar que sou adequado para esta missão.
- Isso também não prova que o ambiente de execução seja confiável.
- Também não verifica o modelo, o prompt, a memória ou as versões da política.
- Ultimate-Bot-Owner também não prova isso. E,
- A parte que confia no agente não garante que este seja um agente confiável nesta transação.
Os cartões de agente autodeclarados são insuficientes do ponto de vista da governança.
Mesmo um Cartão de Agente assinado é apenas um passo adiante. A assinatura simplesmente nos diz que uma pessoa-chave assinou algo.
O verificador também deve determinar se o signatário, a chave, o emissor e a estrutura de confiança são aceitáveis para essa finalidade.
- Identificação não é confiança.
- Descoberta não é autoridade.
- Os metadados não substituem a responsabilização.
Padrão SPIFFE/SPIRE
Os padrões SPIFFE e SPIRE são úteis ao considerar esses aspectos.
SPIFFE e SPIRE não são especificações padrão para governança de agentes. No entanto, elas fornecem padrões dos quais podemos aprender.
Uma carga de trabalho não deve simplesmente declarar quem é; ela deve ser autenticada antes de receber essa identidade.
No entanto, para a IA Agentica, a Identidade da Carga de Trabalho é apenas o ponto de partida.
A declaração de autenticidade pode ajudar a responder à pergunta: "O que está sendo feito?"
No entanto, a declaração não pode responder às seguintes perguntas.
- De quem é a missão que está sendo realizada?
- Que tipo de autoridade foi delegada?
- Qual modelo ou comando foi utilizado?
- Qual política foi aplicada?
- É possível obter indenização por essa ação?
- Quem é o beneficiário final (UBO)?
Portanto, além da comprovação da carga de trabalho, são necessárias comprovação da missão, comprovação da autorização, semântica da transação e relatórios de monitoramento.
Estabelecendo estruturas de confiança por meio da federação.
É aí que entra o conceito de "federação".
O cartão do agente indica o que está sendo reivindicado.
A declaração fornece informações sobre o que está sendo feito.
As federações podem ajudá-lo a determinar em quais declarações ou atestados confiar.
A federação OpenID define como entidades que desejam interagir entre si estabelecem relações de confiança por meio de terceiros confiáveis chamados de "âncoras de confiança". Ela suporta múltiplos níveis de autoridade, e uma única entidade pode pertencer a múltiplas federações. Além disso, fornece os componentes técnicos de infraestrutura de confiança para a construção de redes de confiança dinâmicas e descentralizadas.
A federação nos permite verificar se a chave de assinatura pertence a uma entidade dentro de uma estrutura de confiança que aprovamos, se existe uma cadeia de confiança válida, se as políticas de metadados são aplicadas e se a marca de confiança é significativa para essa parte dependente.
Isso é extremamente importante na governança de agentes.
Um mundo onde cada parte tem que decidir manualmente se aceita ou rejeita cada agente, provedor, registro, emissor de atestado e beneficiário final é indesejável.
Uma cadeia de confiança e políticas de metadados são necessárias. É preciso um mecanismo para determinar quais reivindicações devem ser aceitas antes que qualquer autoridade seja exercida. Para esse fim, um mecanismo de federação é muito útil.
A importância de usar normas
Já existem muitos componentes úteis para atingir esses objetivos. Só as especificações relacionadas ao OpenID incluem as listadas aqui.
- OpenID Connect
- OpenID4VCI/VP
- AuthZEN
- Federação OpenID
- Estrutura de sinais e eventos compartilhados do OpenID
- etc.
Muitas dessas características foram verificadas matematicamente e formalmente do ponto de vista da segurança.
É claro que isso por si só não basta. No entanto, devemos reutilizar o que for reutilizável e construir apenas o que for realmente necessário.
Responsabilidade e Desafios Atuariais
Por fim, permitam-me apresentar a questão que inevitavelmente surge na governança.
Quem arcará com o prejuízo?
Quando um agente vaza dados, desvia pagamentos, manipula fluxos de trabalho, envia instruções incorretas ou desencadeia uma reação em cadeia prejudicial, onde recai a responsabilidade final?
Dessa perspectiva também, o Ultimate-Bot-Owner se torna importante.
E é aí que as provas se tornam cruciais. Sem provas, a responsabilização enfraquece. A atribuição de responsabilidades torna-se mera especulação e o seguro nada mais do que um palpite.
Atualmente, a base atuarial para os riscos associados à IA Agética ainda está em seus estágios iniciais. No entanto, isso não significa que devamos esperar. Agora é o momento de construir a infraestrutura de mensuração.
O seguro não se resume a slogans. É preciso ter dados sobre o grau de exposição ao risco, a frequência de ocorrência, a gravidade dos danos, a eficácia da gestão, as relações causais e as perdas.
O software está se tornando um funcionário.
A governança sobre essas questões está se tornando necessária.
Existem especificações padrão que podem ser utilizadas.
No entanto, construir uma infraestrutura de agentes bem governada não é suficiente. Existem muitas lacunas que precisam ser preenchidas.
Para a comunidade Identerati, nossa jornada para construir um ecossistema de agentes confiável está apenas começando.
Vamos todos trabalhar juntos e começar a fazer isso agora mesmo.