A Governança de Segurança de IA da Microsoft se Rigoriza à Medida que Agentes Ganham Mais Controle

A Microsoft reformulou suas regras de IA responsável à medida que os agentes ganham mais acesso, autonomia e alcance operacional em seus produtos. A mudança na governança de segurança de IA da Microsoft aborda um conflito básico: controles escritos para chatbots não regem automaticamente softwares capazes de executar ações.

O Relatório de Transparência de IA Responsável de 2026 da empresa descreve novas práticas de modelagem de ameaças voltadas a agentes, defesas contra injeção de prompts, classificadores de segurança e uma supervisão pré-lançamento mais rigorosa. Ele também amplia a governança para além dos modelos, abrangendo as plataformas, ferramentas, dados e aplicações ao seu redor.

Esse escopo mais amplo importa porque um agente pode enviar mensagens, recuperar registros, alterar documentos, chamar ferramentas de software e delegar trabalho. Anthropic, OpenAI, Google e outros provedores de modelos enfrentam a mesma transição: de gerar respostas para executar tarefas.

A resposta da Microsoft é mais do que uma atualização de política. Ela representa uma aposta de que a segurança de IA precisa se tornar um sistema de controle operacional, e não um documento revisado antes do lançamento.

A Governança de Segurança de IA da Microsoft Agora Abrange Toda a Stack de Agentes

A Microsoft está transferindo seu foco de segurança das saídas dos modelos para toda a cadeia de ações que um sistema de IA pode realizar.

A empresa afirma ter reformulado de maneira abrangente seu Padrão de IA Responsável. Esse padrão orienta como a Microsoft desenvolve, lança e opera sistemas de IA em toda a empresa.

Segundo seu relatório de transparência, a abordagem revisada contempla modelos, serviços de plataforma e aplicações. As capacidades agênticas atravessam todas as camadas, em vez de existirem como uma categoria de produto separada.

Um agente de IA é um software que usa um modelo para planejar e concluir tarefas por meio de ferramentas, dados ou ambientes digitais. Seu perfil de risco depende de mais do que as respostas do modelo.

Um chatbot pode produzir uma resposta imprecisa. Um agente pode agir com base nessa resposta antes que uma pessoa a revise.

Essa diferença muda o que a governança precisa abranger. Uma empresa precisa examinar a identidade, as permissões, a memória, as ferramentas, os requisitos de aprovação e o histórico de execução do agente.

A Microsoft afirma que seu padrão agora inclui requisitos para capacidades agênticas em todo o ciclo de vida da IA. A empresa também introduziu novas práticas de modelagem de ameaças projetadas em torno do comportamento dos agentes.

A modelagem de ameaças identifica como um sistema pode falhar, ser usado indevidamente ou sofrer um ataque. Para agentes, o processo precisa considerar atividades de múltiplas etapas e condições mutáveis durante a execução.

A Microsoft relata diversas mudanças relacionadas. Ela expandiu as defesas contra injeção de prompts, aumentou a cobertura de classificadores de segurança, criou novos modelos de transparência e fortaleceu as capacidades de governança de agentes.

A injeção de prompts ocorre quando conteúdo não confiável tenta substituir as instruções de um agente. O ataque pode aparecer dentro de um documento, e-mail, página da web ou interface de software processada pelo agente.

Uma injeção bem-sucedida pode redirecionar um agente sem comprometer o modelo subjacente. Isso torna a arquitetura da aplicação ao redor dele central para a segurança.

A Microsoft também descreve um processo central de supervisão pré-lançamento. O processo busca verificar se os riscos relevantes foram tratados antes que um sistema se torne disponível.

A empresa alinha esse trabalho a quatro funções do Framework de Gerenciamento de Riscos de IA do NIST: governar, mapear, medir e gerenciar. Essas funções tratam o gerenciamento de riscos como um processo contínuo, e não como uma revisão final antes do lançamento.

A Microsoft afirma ter oferecido treinamento em IA responsável a quase 20 mil engenheiros, formuladores de políticas e clientes. Também analisou mais de 100 leis propostas ou promulgadas ao revisar seu padrão.

Mais de 80 funcionários de mais de 30 equipes participaram desse trabalho jurídico e de governança. Esses números mostram a escala organizacional do esforço, embora não comprovem que todos os controles funcionem como previsto.

A mudança central continua clara. A Microsoft não apresenta mais a avaliação de modelos como proteção suficiente para sistemas cada vez mais autônomos.

O comportamento de um agente surge da interação entre seu modelo, instruções, permissões, ferramentas, dados e ambiente operacional. A governança precisa acompanhar toda essa cadeia.

Por Que as Ações dos Agentes Criam um Problema de Segurança Diferente

O problema mais difícil começa depois que um modelo gera uma resposta, quando um agente transforma essa resposta em uma ação externa.

Os controles tradicionais de IA generativa costumam se concentrar no conteúdo. As equipes testam se um modelo produz instruções inseguras, respostas enviesadas, informações privadas ou afirmações imprecisas.

Os sistemas de agentes acrescentam outra camada. Eles convertem decisões do modelo em chamadas de ferramentas com consequências reais.

Um agente de atendimento ao cliente pode visualizar registros de contas, redigir respostas ou autorizar reembolsos. Um agente de programação pode modificar um repositório, executar comandos ou abrir um pull request.

Um agente de escritório pode pesquisar e-mails, resumir reuniões, atualizar um documento e enviar mensagens a colegas. Cada etapa pode afetar um sistema diferente, com permissões separadas.

O risco cresce por composição. Uma saída do modelo que parece inofensiva pode desencadear uma ação perigosa quando combinada com acesso amplo ou validação incompleta.

O próprio exemplo da Microsoft para Agent Hooks ilustra esse problema. Um agente fictício de suporte emite reembolsos incorretamente após um controle de aprovação gerar uma exceção.

A estrutura ao redor registra o erro, mas continua a execução. Um caminho separado de processamento em lote ignora outro controle porque o callback esperado nunca é executado.

A lição é estrutural. Um controle de segurança não pode proteger um caminho de execução que nunca vê.

É por isso que o trabalho recente da Microsoft distingue observação de aplicação. Registrar a atividade de um agente ajuda investigadores, mas não necessariamente interrompe uma ação insegura.

A Microsoft introduziu o Agent Hooks como um contrato aberto e neutro em relação a frameworks para inserir controles na execução de agentes. A especificação define como frameworks e componentes de governança devem interagir.

A versão inicial inclui kits de desenvolvimento de software para Python, TypeScript, .NET, Rust e Go. Ela também inclui uma suíte de conformidade com 47 cenários.

Os testes de conformidade verificam se um framework respeita o contrato sob condições definidas. O objetivo declarado da Microsoft é tornar o suporte verificável, em vez de deixá-lo como uma mera alegação de compatibilidade.

O contrato mira diversos modos de falha. Os controles devem visualizar todos os caminhos de execução relevantes, registrar evidências e bloquear ações quando uma política as negar.

Esse último requisito parece óbvio, mas frameworks de agentes frequentemente evoluíram a partir de ferramentas de orquestração e observabilidade. Seu tratamento de erros pode favorecer a conclusão de tarefas em vez de uma aplicação rigorosa.

Os agentes também criam riscos de delegação. Um agente principal pode pedir a um subagente que conclua parte de uma tarefa, introduzindo outra identidade e outro caminho de execução.

As tentativas repetidas adicionam mais complexidade. Uma ação bloqueada pode retornar por um caminho de recuperação que aplica uma lógica diferente de middleware ou aprovação.

Tarefas em segundo plano e processos em lote podem se comportar de forma diferente de sessões interativas. Um controle ligado apenas a um fluxo voltado ao usuário pode deixar esses caminhos inteiramente de fora.

A memória cria outra superfície de ataque. O contexto armazenado pode preservar instruções falsas ou dados sensíveis além da sessão em que apareceram pela primeira vez.

Esses riscos explicam por que a Microsoft descreve a governança como dinâmica. Um teste único de modelo não consegue capturar todas as permissões, ferramentas, usuários e fontes de dados encontrados após a implantação.

A posição da empresa também reflete a amplitude de seus produtos. A Microsoft fornece modelos, infraestrutura em nuvem, aplicações de trabalho, sistemas de identidade, ferramentas para desenvolvedores e produtos de segurança.

Esse alcance oferece à Microsoft pontos para aplicar políticas por toda a stack. Também dá à empresa responsabilidade por mais conexões nas quais os controles podem falhar.

Para compradores corporativos, a questão prática não é mais se um agente produz uma demonstração aceitável. É se o sistema implantado se comporta de maneira previsível em todas as rotas para uma ação.

A Principal Troca é Entre Capacidade e Controle Aplicável

A Microsoft quer que os agentes concluam tarefas mais amplas, mas cada permissão adicional torna a aplicação confiável mais difícil.

Os produtos de agentes se tornam mais úteis quando conseguem acessar contexto relevante e realizar ações significativas. Permissões restritas reduzem o risco, mas também podem limitar o trabalho que um agente consegue concluir.

Permissões amplas criam o problema oposto. O agente pode finalizar mais tarefas, mas erros e ataques passam a ter um impacto potencial maior.

Essa tensão aparece no exemplo do Copilot Cowork da Microsoft. A empresa afirma que o sistema conclui tarefas no ambiente de trabalho em todo o Microsoft 365 por meio de aprovações de usuários, acesso baseado em permissões, controles de segurança e implantação gradual.

Uma liberação gradual limita a exposição enquanto as equipes coletam evidências sobre o comportamento. A aprovação do usuário coloca uma pessoa entre o plano do agente e ações selecionadas.

Nenhum dos mecanismos elimina o risco. Usuários podem aprovar ações sem entender suas consequências, enquanto uma liberação gradual pode não revelar falhas que exigem condições incomuns.

O acesso de menor privilégio oferece outro controle. Ele concede a um agente apenas as permissões necessárias para sua tarefa atribuída.

Esse princípio se torna difícil quando as tarefas são abertas. Um agente encarregado de preparar uma atualização de projeto pode precisar de e-mail, calendário, documentos, chat e registros de clientes.

Ele também pode precisar de permissão para gravar em sistemas compartilhados. Cada nova conexão aumenta tanto a utilidade quanto o número de possíveis caminhos de falha.

O framework mais amplo de modelos de fronteira da Microsoft aborda os riscos de capacidade mais graves. Seu framework de governança acompanha preocupações químicas, biológicas, radiológicas, nucleares, cibernéticas, de autonomia, controle e manipulação.

O framework avalia indicadores iniciais, como raciocínio geral, raciocínio de contexto longo, planejamento, uso de ferramentas, raciocínio científico e engenharia de software.

Modelos que apresentam indicadores relevantes recebem avaliações mais aprofundadas. A Microsoft classifica os riscos resultantes como baixos, médios, altos ou críticos.

A empresa afirma que riscos altos ou críticos exigem revisão adicional e mitigações antes da implantação. Também se compromete a pausar o desenvolvimento e a implantação quando os riscos identificados não puderem ser suficientemente reduzidos.

Esse compromisso é significativo, mas depende das avaliações internas e das decisões de governança da Microsoft. Pessoas externas não podem confirmar de forma independente cada resultado de modelo ou julgamento de implantação.

O framework de fronteira também se concentra em ameaças à segurança nacional e à segurança pública. Agentes corporativos criam muitos riscos de menor escala que ainda importam para os clientes.

Um agente não precisa de autonomia em nível de fronteira para expor um arquivo confidencial, enviar uma mensagem não autorizada ou executar uma transação incorreta.

Essas falhas dependem fortemente do contexto de implantação. O mesmo modelo pode representar baixo risco em uma ferramenta de redação e risco muito maior quando conectado a software financeiro.

A Microsoft aborda essa distinção por meio de governança em camadas. As avaliações de fronteira cobrem capacidades excepcionais, enquanto seu padrão mais amplo abrange produtos, implantações e operação contínua.

Sua Agent Governance Toolkit de código aberto adota outra abordagem. Ela fornece componentes para aplicação de políticas, identidade de agentes, controles de execução, confiabilidade, evidências de conformidade e segurança de plugins.

O toolkit de governança contém sete pacotes em Python, TypeScript, Rust, Go e .NET. A Microsoft afirma que o repositório inclui mais de 9.500 testes.

Um componente coloca uma decisão de política antes da ação de um agente. Outro atribui identidades criptográficas aos agentes e oferece suporte a decisões de confiança entre eles.

O toolkit também inclui anéis de execução, tratamento de transações, disjuntores e um mecanismo de encerramento de emergência. Esses recursos tomam emprestadas ideias consolidadas de sistemas operacionais e engenharia de confiabilidade de sites.

Essa direção de engenharia é importante. A segurança de agentes não pode depender inteiramente de pedir a um modelo que obedeça a uma regra em linguagem natural.

Um prompt pode expressar uma intenção, mas um mecanismo externo de políticas pode tomar uma decisão determinística. Ele pode negar uma chamada de ferramenta proibida mesmo quando o modelo a solicita.

A questão de equilíbrio continua sem solução. Agentes mais capazes exigem mais caminhos para sistemas reais, enquanto mais caminhos criam encargos adicionais de aplicação de controles.

A estratégia da Microsoft é tornar esses caminhos visíveis, testáveis e governáveis. O valor dessa estratégia dependerá de quão consistentemente os produtos a adotam.

A Estrutura da Microsoft Ainda Enfrenta uma Lacuna de Aplicação

Os padrões publicados descrevem o sistema pretendido, mas a segurança depende de os controles resistirem à pressão de produto, a erros de integração e a ataques desconhecidos.

O relatório de transparência da Microsoft fornece muitos detalhes sobre os processos de governança. Ele não oferece evidências públicas completas para cada produto, modelo, controle ou incidente.

Essa distinção importa porque a governança interna é, em parte, uma autoavaliação. A Microsoft desenvolve a tecnologia, avalia muitos riscos, seleciona mitigações e decide quando a implantação pode prosseguir.

Testes externos podem reduzir esse conflito. A empresa afirma ter ampliado suas parcerias de avaliação e usado uma estrutura de testes externa para o Copilot Health.

Ela consultou mais de 250 profissionais clínicos licenciados de mais de duas dezenas de países antes de lançar essa experiência de saúde. O trabalho abrangeu clareza, utilidade e segurança.

Esse caso demonstra um processo de avaliação específico para uma implantação. Ele não mostra que um escrutínio independente equivalente alcance todos os produtos de agentes.

A transparência também se torna mais difícil à medida que os sistemas ficam mais complexos. Uma única aplicação pode combinar modelos da Microsoft, modelos de terceiros, plugins, dados proprietários e políticas definidas pelo cliente.

A responsabilidade pode se fragmentar por toda essa cadeia de fornecimento. Um provedor de modelos pode documentar limitações, enquanto um desenvolvedor de framework controla a execução de ferramentas e um cliente atribui permissões.

Quando ocorre um incidente, cada participante pode apontar para outra camada. Portanto, uma governança eficaz de segurança de IA da Microsoft exige propriedade claramente definida em toda a implantação.

A estrutura de risco do NIST sustenta essa visão de ciclo de vida. Ela trata a governança como uma função transversal e pede monitoramento contínuo, revisão, documentação e responsabilidades definidas.

O NIST também observa que a revisão independente pode aprimorar os testes e reduzir vieses internos. Esse princípio cria uma referência útil para futuras divulgações da Microsoft.

Compradores devem buscar evidências de que os controles funcionam em condições de falha. Um mecanismo de políticas deve negar uma ação quando uma dependência falha, expira ou retorna dados malformados.

Isso é conhecido como falhar de forma fechada. O sistema bloqueia atividades incertas em vez de continuar porque um controle se tornou indisponível.

O Agent Hooks visa diretamente esse requisito, mas uma especificação não pode garantir uma implementação correta. Os mantenedores de frameworks precisam integrá-la, e as equipes de aplicação precisam configurá-la adequadamente.

Testes de conformidade ajudam a expor incompatibilidades. Eles não conseguem antecipar todos os caminhos específicos de cada aplicação, plugins personalizados ou erros de política.

O desempenho introduz outra pressão. Desenvolvedores podem contornar controles que adicionam latência perceptível, geram falsos positivos ou interrompem fluxos de trabalho comuns.

As equipes de produto também enfrentam incentivos de adoção. Um agente que pede aprovação constantemente pode parecer menos útil do que um que age rapidamente.

O desafio de design resultante não é a restrição máxima. É aplicar controles mais fortes a ações de maior impacto sem tornar o trabalho comum inviável.

A regulamentação adiciona uma camada separada de pressão. As obrigações da União Europeia para modelos de IA de propósito geral já exigem documentação técnica e informações para provedores posteriores na cadeia.

As obrigações para modelos da Comissão Europeia também abrangem políticas de direitos autorais e resumos públicos do conteúdo de treinamento. Requisitos adicionais se aplicam a modelos com risco sistêmico.

Essas regras se concentram fortemente nos provedores de modelos. As implantações de agentes distribuem o risco entre modelos, aplicações, ferramentas e organizações.

O padrão expandido da Microsoft tenta preencher essa lacuna. Seu novo Deployer Chapter estabelece requisitos para o uso de aplicações de IA de terceiros dentro da Microsoft.

A empresa descreve três estágios operacionais: avaliar o provedor, gerenciar riscos de implantação e detectar e responder continuamente após o lançamento.

Essa abordagem reconhece um fato desconfortável. Mesmo um modelo bem testado pode se tornar inseguro dentro de uma aplicação mal projetada.

A incerteza mais importante não é se a Microsoft escreveu regras detalhadas. É se as equipes conseguem provar que essas regras governam todos os caminhos de ação relevantes.

Clientes devem pedir evidências de controles, cobertura de avaliações, processos de incidentes e registros de auditoria. Garantias amplas sobre IA responsável não são suficientes.

Eles também devem manter seus próprios inventários. Uma organização não pode governar agentes cuja existência as equipes de segurança e conformidade desconhecem.

Para trabalhos intensivos em conhecimento, manter uma base de conhecimento de IA pesquisável pode melhorar a rastreabilidade. No entanto, os controles de armazenamento e recuperação ainda devem corresponder à sensibilidade das informações subjacentes.

A lacuna de aplicação só diminuirá quando a governança se tornar mensurável. A Microsoft forneceu mais mecanismos, mas as evidências em produção continuam sendo o teste decisivo.

Os Rivais da Microsoft Convergem para uma Governança Baseada em Risco

Os principais provedores de IA concordam cada vez mais que o crescimento de capacidade deve desencadear salvaguardas mais fortes, embora seus limiares e divulgações sejam diferentes.

A Microsoft não está sozinha ao usar regras de segurança baseadas em capacidades. A Anthropic mantém uma Responsible Scaling Policy desde 2023 e a revisou repetidamente conforme os modelos mudaram.

A política da Anthropic conecta limiares de capacidade definidos a salvaguardas obrigatórias. Seus materiais atuais abordam riscos biológicos, riscos cibernéticos e pesquisa autônoma em IA.

A empresa descreve sua política como proporcional, iterativa e adequada para adoção além da Anthropic. Sua política de escalonamento também inclui um processo de denúncia de não conformidade e de proteção contra retaliação.

O Frontier Governance Framework da Microsoft segue uma estrutura relacionada. Ambas as organizações identificam capacidades de alto risco, avaliam modelos e conectam os resultados a proteções mais fortes.

As estruturas não são idênticas. Elas usam definições, limiares, práticas de comunicação e processos organizacionais diferentes.

OpenAI e Google também publicaram abordagens de segurança de fronteira. Juntas, essas políticas mostram um consenso crescente em torno de avaliação escalonada e implantação baseada em risco.

A competição agora diz respeito tanto à implementação quanto aos princípios. Os provedores querem lançar produtos mais capazes enquanto demonstram a governos e clientes que as salvaguardas acompanharão o ritmo.

A Microsoft ocupa uma posição distinta porque opera em software de consumo, infraestrutura empresarial, identidade, segurança e plataformas para desenvolvedores.

Essa integração oferece uma vantagem de governança. A Microsoft pode conectar avaliações de modelos a controles de acesso, segurança de endpoints, políticas de aplicação e sistemas organizacionais de auditoria.

Ela também gera preocupações de dependência. Os clientes podem se tornar dependentes de um único fornecedor para prover o agente, a camada de identidade, o mecanismo de políticas, o monitoramento e as evidências de conformidade.

A decisão da Microsoft de lançar o Agent Hooks como uma especificação independente de framework contraria essa preocupação. Seu toolkit de governança também oferece suporte a diversos frameworks externos de agentes.

Interfaces abertas podem tornar os controles portáveis. Elas também podem oferecer aos clientes uma camada de políticas consistente quando as equipes usam modelos e frameworks de provedores diferentes.

A portabilidade é importante porque ambientes corporativos de IA raramente permanecem uniformes. Uma empresa pode usar Microsoft 365, Azure, um modelo da Anthropic, um agente de programação da OpenAI e software de orquestração de código aberto.

Um contrato independente de framework pode reduzir o trabalho de integração duplicado. Ele também pode esclarecer qual componente deve aplicar cada decisão.

No entanto, uma especificação aberta só se torna significativa quando frameworks concorrentes a implementam fielmente. Portanto, a adoção fora dos produtos da Microsoft será uma medida crítica.

Reguladores também influenciam essa convergência. As regras da União Europeia exigem documentação, gestão de riscos e compartilhamento de informações em toda a cadeia de fornecimento de IA.

Os padrões voluntários do NIST fornecem outro vocabulário comum. A Microsoft mapeia explicitamente seu processo de governança às funções de governar, mapear, medir e gerenciar do NIST.

Uma terminologia compartilhada pode simplificar auditorias e processos de compras. Ela não garante desempenho de segurança equivalente entre provedores.

Cada organização ainda escolhe o que testar, como pontuar os resultados, quais riscos residuais aceitar e quais informações divulgar publicamente.

A pressão competitiva pode fortalecer a governança quando os clientes exigem evidências confiáveis. Ela pode enfraquecê-la quando a velocidade de lançamento se torna a principal medida de sucesso.

Essa é a disputa central do setor. O vencedor não oferecerá simplesmente o agente mais capaz.

Clientes empresariais favorecerão sistemas que possam demonstrar autonomia útil dentro de limites aplicáveis. Isso exige que identidade, permissões, monitoramento, aprovação, recuperação e responsabilização funcionem em conjunto.

A Microsoft está avançando em direção a esse modelo integrado. Os rivais a pressionarão a provar que a integração produz mais do que consistência de políticas.

O Que Observar Enquanto a Microsoft Coloca Suas Regras em Produção

O próximo teste é se a Microsoft converterá sua arquitetura de governança em evidências visíveis e repetíveis em todos os produtos e frameworks externos.

O primeiro sinal é a documentação em nível de produto. A Microsoft deve mostrar como o Responsible AI Standard revisado altera lançamentos individuais de agentes, permissões, avaliações e respostas a incidentes.

Notas detalhadas de implantação fortaleceriam a alegação da empresa de que a governança acompanha todo o ciclo de vida da IA. Divulgações escassas deixariam os clientes dependentes de garantias de alto nível.

Os documentos mais úteis identificariam categorias de avaliação, limitações conhecidas, limites de aprovação, práticas de monitoramento e riscos residuais. Eles também deveriam explicar o que acontece quando um controle falha.

Essas evidências são importantes para produtos Copilot, serviços de agentes do Azure, agentes de programação e sistemas que coordenam vários agentes. Cada contexto cria consequências diferentes.

O segundo sinal é a adoção do Agent Hooks além do próprio framework da Microsoft. O suporte de grandes projetos de orquestração validaria a demanda por um contrato comum de aplicação de controles.

A adoção, por si só, é insuficiente. Os frameworks precisam passar pela suíte de conformidade e preservar a aplicação de políticas em caminhos de execução interativos, em lote, de repetição e delegados.

Relatórios independentes sobre falhas de integração enfraqueceriam a alegação da Microsoft de que um contrato comum resolve o problema da fragmentação. Resultados de conformidade reproduzíveis a fortaleceriam.

O terceiro sinal é a transparência sobre incidentes. A Microsoft afirma que o monitoramento, o feedback dos usuários e as ações corretivas continuam ativos após a implantação.

Os leitores devem observar se a empresa publica informações relevantes sobre falhas de agentes e as correções resultantes. Incidentes reais revelam lacunas que avaliações de laboratório não detectam.

Relatórios úteis distinguiriam erros de modelo de falhas de permissão, uso indevido de ferramentas, injeção de prompt e lógica de aprovação defeituosa. Essa separação ajuda os clientes a aprimorar seus próprios sistemas.

O framework de fronteira da Microsoft também merece escrutínio contínuo. Novos modelos com maior autonomia, capacidade de planejamento, recursos cibernéticos ou habilidades de engenharia de software devem desencadear avaliações mais profundas.

A empresa prometeu pausar o desenvolvimento e a implantação quando os riscos não puderem ser suficientemente reduzidos. Qualquer uso futuro desse compromisso proporcionaria um importante teste da independência da governança.

Os clientes não precisam esperar por esses sinais para agir. Eles podem inventariar os agentes implantados, reduzir permissões, separar ferramentas de alto impacto e exigir aprovação para ações irreversíveis.

Também podem testar condições de falha. As equipes devem interromper deliberadamente os serviços de política, enviar solicitações de ferramentas malformadas e verificar se as ações negadas continuam negadas.

Os registros devem conectar uma decisão de política à ação que foi realmente executada. Registros que capturam apenas mensagens do modelo deixam lacunas importantes.

As organizações devem definir quem é responsável por um agente após seu lançamento. As equipes de produto, segurança, jurídico, dados e operações precisam de responsabilidades claras quando o comportamento muda.

Elas também devem estabelecer procedimentos de desligamento e recuperação. Uma parada de emergência só é útil quando as pessoas sabem quando e como usá-la.

A governança de segurança de IA da Microsoft está seguindo a direção técnica correta ao tratar agentes como sistemas operacionais para ação, e não como interfaces de chat. Suas ideias mais fortes envolvem aplicação em tempo de execução, identidade, permissões e evidências.

A questão restante é se essas ideias resistem às condições complexas do software em produção. Os compradores devem exigir provas em todos os caminhos de execução antes de conceder autoridade mais ampla aos agentes.