A Microsoft está reforçando uma mudança importante na forma como empresas devem controlar sistemas de inteligência artificial em produção. Em vez de depender apenas de políticas, permissões e revisões realizadas antes da implantação, a estratégia passa a incluir governança aplicada durante a execução dos modelos e agentes.
A ideia é simples: uma política definida antes do deploy não é suficiente quando um agente pode tomar decisões, chamar ferramentas, acessar dados e executar ações diferentes a cada interação.
Nesse cenário, a governança precisa acompanhar o comportamento do sistema em tempo real.
A arquitetura apresentada pela Microsoft combina definição de políticas, controle de requisições, observabilidade e geração de evidências para auditoria, conectando serviços como Microsoft Foundry, identidade, segurança e ferramentas de governança.
A governança de IA deixa de depender apenas de políticas estáticas e passa a incluir enforcement em tempo de execução.
# publicidade
O Microsoft Foundry concentra recursos para gateways, observabilidade e controle do uso de modelos.
A arquitetura combina política, controle, visibilidade e evidências para auditoria.
Agentes podem ser interceptados durante chamadas de ferramentas e serviços externos.
Ações de maior impacto podem exigir aprovação humana sem uma reestruturação completa do agente.
Por que políticas estáticas não são suficientes para agentes de IA?
Aplicações tradicionais costumam seguir caminhos relativamente previsíveis.
Um sistema recebe uma entrada, executa regras previamente definidas e produz uma saída. Mesmo quando existem muitos fluxos possíveis, os desenvolvedores geralmente conseguem antecipar boa parte do comportamento.
Agentes de IA mudam esse cenário.
Um agente pode interpretar uma solicitação, decidir quais ferramentas utilizar, consultar uma base de dados, chamar uma API, executar uma sequência de etapas e gerar uma nova decisão com base no resultado anterior.
Isso significa que não basta perguntar apenas:
"O agente está autorizado a acessar esta ferramenta?"
Também é necessário perguntar:
Ele deveria usar essa ferramenta neste contexto?
Qual dado está sendo enviado?
Qual ação será executada?
O risco da ação exige aprovação humana?
O comportamento está dentro da política definida?
Essa chamada é compatível com o objetivo original do agente?
É justamente nesse espaço que entra o conceito de runtime enforcement.
Em vez de confiar apenas em regras configuradas antes da execução, o sistema passa a avaliar e aplicar controles enquanto o agente está operando.
Como funciona a arquitetura de runtime enforcement da Microsoft?
A arquitetura proposta organiza a governança em diferentes domínios, reunidos em quatro grandes funções:
Política
Controle
Visibilidade
Prova e auditoria
Essas quatro camadas trabalham como um ciclo contínuo.
Primeiro, a organização define quais regras devem existir. Depois, essas regras precisam ser transformadas em controles técnicos. Durante a execução, o comportamento é monitorado. Por fim, os dados coletados se transformam em evidências que podem ser utilizadas para auditoria, investigação e conformidade.
Política: definir o que é permitido
A camada de política estabelece as regras gerais da organização.
Isso pode incluir:
Classificação de risco.
Tipos de dados permitidos.
Modelos autorizados.
Restrições de acesso.
Requisitos de aprovação humana.
Políticas de retenção.
Regras para uso de ferramentas.
O objetivo não é controlar cada requisição manualmente.
É criar uma estrutura que permita traduzir regras de negócio e segurança para comportamentos técnicos.
Por exemplo, uma organização pode definir que um agente pode consultar informações internas, mas não pode executar ações financeiras sem uma aprovação adicional.
A política estabelece essa regra.
A camada de controle é responsável por aplicá-la.
Controle: quando a política precisa virar comportamento técnico
Uma das partes mais importantes da arquitetura é o controle aplicado durante a execução.
Nesse modelo, o gateway e outros componentes de infraestrutura podem analisar chamadas antes que elas cheguem ao modelo, à ferramenta ou ao serviço externo.
Isso permite aplicar diferentes tipos de restrições:
Bloqueio de requisições.
Limites de acesso.
Filtragem de dados.
Controle de modelos autorizados.
Restrições de ferramentas.
Limites de consumo.
Aprovação humana para determinadas ações.
O Microsoft Foundry AI Gateway faz parte dessa camada de centralização e controle.
A lógica é semelhante ao papel de um API Gateway em arquiteturas tradicionais.
Em vez de permitir que cada aplicação se conecte diretamente a diferentes modelos e serviços, uma camada central pode aplicar regras consistentes.
Isso reduz a fragmentação.
Também evita que cada equipe implemente sua própria estratégia de segurança e governança.
Visibilidade: monitorar o que realmente acontece em produção
Definir regras não significa saber se elas estão funcionando.
Por isso, a terceira camada é a visibilidade.
Sistemas baseados em IA precisam gerar telemetria sobre o que está acontecendo durante a execução.
Isso pode incluir informações como:
Qual modelo foi utilizado.
Qual agente iniciou uma ação.
Quais ferramentas foram chamadas.
Quanto tempo o fluxo levou.
Quais decisões foram tomadas.
Quais controles foram acionados.
Onde ocorreram falhas.
Quando houve intervenção humana.
Essa visibilidade é especialmente importante para agentes.
Um erro em uma aplicação tradicional pode ser investigado analisando logs e fluxos conhecidos.
Já um agente pode tomar caminhos diferentes dependendo do contexto.
Sem observabilidade, a equipe pode perceber apenas o resultado final, sem entender como ele foi produzido.
Serviços relacionados à segurança e identidade, como Microsoft Defender e Microsoft Entra ID, ajudam a compor essa visão sobre identidades, acessos e comportamentos dentro do ambiente corporativo.
Prova: transformar telemetria em evidência para auditoria
A quarta camada é a capacidade de transformar dados técnicos em evidências.
Esse ponto se torna importante principalmente para empresas que trabalham em setores regulados ou precisam demonstrar controle sobre sistemas automatizados.
Não basta afirmar que existe uma política.
A organização precisa conseguir responder perguntas como:
Quem executou determinada ação?
Qual agente tomou a decisão?
Qual identidade estava associada à requisição?
Qual política estava ativa naquele momento?
Houve alguma exceção?
Um humano aprovou a ação?
Quais dados foram acessados?
A telemetria deixa de ser apenas uma ferramenta para debugging.
Ela passa a funcionar como parte da infraestrutura de governança.
Os principais componentes da arquitetura de governança
A divisão entre política, controle e visibilidade ajuda a entender o papel de cada tecnologia.
Função | Objetivo principal | Tecnologia associada |
|---|---|---|
Política | Definir regras, classificações e níveis de risco | Microsoft Purview |
Controle | Aplicar limites e políticas durante a execução | Microsoft Foundry AI Gateway |
Visibilidade | Monitorar identidades e comportamento dos agentes | Microsoft Defender e Microsoft Entra ID |
Auditoria | Gerar evidências a partir da telemetria | Logs, avaliações e mecanismos de governança |
Arraste para o lado para ver toda a tabela.
O ponto importante é que nenhuma dessas camadas funciona isoladamente.
Uma política sem enforcement pode virar apenas documentação.
Um gateway sem política clara não sabe quais decisões deve tomar.
E uma arquitetura sem observabilidade pode bloquear ou permitir ações sem que a empresa consiga explicar posteriormente o que aconteceu.
Por que agentes autônomos exigem validação contínua?
Modelos generativos não são sistemas totalmente determinísticos.
Uma mesma solicitação pode produzir resultados diferentes dependendo do contexto, do modelo, das ferramentas disponíveis e das etapas executadas pelo agente.
Quando o sistema ganha autonomia, o problema aumenta.
Imagine um agente que pode:
Ler um ticket.
Consultar documentos.
Buscar dados em um sistema interno.
Chamar uma API externa.
Criar uma solicitação.
Atualizar um registro.
Enviar uma mensagem.
Cada etapa representa uma nova superfície de risco.
O agente pode estar autorizado a utilizar todas essas ferramentas individualmente.
Isso não significa, porém, que qualquer combinação dessas ações seja segura.
Por esse motivo, a validação precisa acontecer durante o fluxo.
É possível, por exemplo, permitir que o agente consulte informações automaticamente, mas exigir aprovação humana antes de executar uma alteração irreversível.
O papel do Agent Governance Toolkit
Ferramentas como o Agent Governance Toolkit buscam oferecer pontos de interceptação para controlar agentes durante sua execução.
A proposta é permitir que desenvolvedores adicionem mecanismos de governança sem precisar reconstruir completamente o código dos agentes.
Dependendo da arquitetura, um ponto de controle pode interceptar uma ação antes de sua execução e decidir se ela deve:
Ser permitida automaticamente.
Ser bloqueada.
Ser registrada.
Exigir uma validação adicional.
Ser encaminhada para aprovação humana.
Isso é particularmente relevante para agentes conectados a ferramentas externas e servidores MCP.
A expansão do uso do Model Context Protocol facilita a conexão entre modelos e diferentes sistemas, mas também aumenta a necessidade de controlar quais ferramentas estão disponíveis e como elas são utilizadas.
Quanto maior a autonomia, maior precisa ser a capacidade de aplicar limites.
Aprovação humana não significa voltar ao modelo manual
Existe uma percepção de que adicionar aprovação humana elimina os ganhos da automação.
Mas o objetivo não é colocar uma pessoa em todas as etapas.
A ideia é utilizar human-in-the-loop apenas quando o risco justificar.
Uma arquitetura pode, por exemplo, permitir automaticamente:
Consultas.
Pesquisas.
Classificações.
Geração de rascunhos.
Recuperação de documentos.
Ao mesmo tempo, pode exigir aprovação para:
Alterações financeiras.
Exclusão de dados.
Mudanças em infraestrutura.
Ações que afetam clientes.
Execução de comandos críticos.
Dessa forma, a autonomia deixa de ser uma escolha binária entre totalmente automático ou totalmente manual.
Ela passa a funcionar em níveis.
Quanto maior o impacto potencial de uma ação, maior pode ser o nível de controle exigido.
O que essa estratégia significa para empresas que usam IA?
A mudança mais importante é conceitual.
Governança de IA não pode ser tratada apenas como uma etapa realizada antes da implantação.
Políticas, avaliações e revisões continuam necessárias, mas agentes em produção exigem uma segunda camada: controle durante a execução.
Uma arquitetura madura precisa responder continuamente:
O agente está fazendo o que deveria?
Ele está acessando apenas o que pode acessar?
A ação atual está dentro do nível de risco permitido?
Existe evidência suficiente para investigar uma decisão?
A organização consegue interromper ou bloquear um comportamento?
Essa abordagem aproxima a governança de IA de conceitos já conhecidos em segurança e infraestrutura.
Em vez de confiar apenas na configuração inicial, os controles acompanham o sistema enquanto ele está em operação.
O futuro da governança de IA será cada vez mais operacional
À medida que modelos deixam de apenas responder perguntas e passam a executar tarefas, a governança também precisa evoluir.
O desafio não será apenas escolher quais modelos a empresa pode utilizar.
Será controlar o que esses modelos e agentes podem fazer depois de receber acesso aos sistemas corporativos.
A estratégia apresentada pela Microsoft aponta justamente nessa direção: conectar política, identidade, segurança, gateways, observabilidade e auditoria em uma arquitetura contínua.
Para equipes de tecnologia, a principal lição é clara.
Não basta colocar guardrails antes do agente entrar em produção. É necessário ter mecanismos capazes de observar, interceptar e controlar seu comportamento enquanto ele trabalha.
Quanto maior for a autonomia dos agentes, mais importante será a infraestrutura que existe entre a decisão do modelo e a ação no mundo real.
