Risco de agentes de IA: por que agentes precisam de um novo modelo de governança
12 de abril de 2026 · 8 min de leitura
Os agentes de IA estão rapidamente se tornando a nova narrativa padrão da IA empresarial. Os fornecedores estão adicionando agentes a suítes de produtividade, plataformas de atendimento ao cliente, ferramentas para desenvolvedores, sistemas de workflow e ambientes low-code. O Microsoft Copilot Studio, por exemplo, agora se apresenta como uma plataforma para criar, personalizar, implantar e gerenciar agentes de IA que podem se conectar a dados de negócio, usar ferramentas e ser publicados em canais como Microsoft 365 Copilot, Teams, SharePoint e sites.
Essa mudança importa. Mas também cria um problema de linguagem.
Nem todo produto chamado de "agente" traz o mesmo nível de risco.
Um assistente simples de prompt e resposta, baseado em alguns documentos, não é a mesma coisa que um agente de workflow autônomo que monitora eventos, decide o que fazer, chama ferramentas, atualiza registros, envia mensagens, escala casos ou aciona processos de negócio em segundo plano. Ambos podem ser vendidos como agentes. Mas não precisam do mesmo modelo de governança.
Ideia-chave: agente é uma categoria de produto, mas comportamento agêntico é uma propriedade de risco.
Da IA que responde para a IA que age
A governança tradicional de IA costuma começar com perguntas como:
- O modelo é preciso?
- A saída é enviesada?
- O sistema explica seu resultado?
- Os dados pessoais estão sendo processados de forma legal?
- Os usuários podem confiar na resposta?
Essas perguntas continuam importantes. Mas sistemas agênticos adicionam uma nova camada: ação.
Com agentes, a pergunta de governança muda de:
O que o modelo disse?
Para:
O que o agente estava autorizado a fazer, o que ele realmente fez, por que fez, quem aprovou e conseguimos provar isso?
Esse é um problema de controle muito diferente.
Um chatbot pode dar uma resposta errada. Um agente pode dar uma resposta errada e então agir com base nessa resposta. Pode chamar uma API, atualizar um ticket, enviar um e-mail a um cliente, mudar um registro, recuperar dados sensíveis, iniciar um reembolso, criar uma tarefa ou passar trabalho para outro agente.
No momento em que um sistema de IA consegue afetar outro sistema, a governança de IA se torna governança operacional.
O rótulo “agente” é amplo demais
A própria documentação da Microsoft deixa o espectro visível. O Microsoft 365 Copilot descreve agentes que vão de agentes simples de prompt e resposta até agentes totalmente autônomos. O Copilot Studio amplia isso com capacidades autônomas, nas quais agentes podem agir a partir de gatilhos, instruções e guardrails, operando em segundo plano em vez de apenas responder dentro de uma conversa.
Esse espectro é útil. Mas também cria confusão.
Muitas organizações ouvem a palavra “agente” e assumem que estão lidando com uma única categoria. Na prática, existem vários níveis de comportamento agêntico.
Nível 1: assistente de conhecimento
Essa é uma ferramenta de baixa agentividade. Ela responde perguntas usando instruções e fontes de conhecimento selecionadas.
Exemplo:
- Um assistente interno de RH que responde perguntas sobre políticas com base em documentos aprovados.
- Um agente do Copilot Studio que responde em um chat do Teams usando tópicos e conhecimento configurados.
Riscos principais:
- Respostas incorretas
- Conhecimento desatualizado
- Divulgação inadequada
- Confiança excessiva do usuário
Foco de governança:
- Qualidade do conteúdo
- Acesso às fontes de conhecimento
- Avisos e escalonamento
- Logging básico
Nível 2: assistente de workflow guiado
Essa ferramenta ajuda um usuário a concluir uma tarefa, mas a pessoa continua no controle.
Exemplo:
- Um assistente de suporte que redige uma resposta e sugere o próximo passo.
- Um assistente de vendas que resume informações de uma conta e propõe um e-mail de follow-up.
Riscos principais:
- Recomendações ruins
- Contexto incompleto
- Resumos enganosos
- Aprovação automática sem revisão real
Foco de governança:
- Revisão humana
- Transparência de fontes
- Limites do workflow
- Treinamento do usuário
Nível 3: agente que usa ferramentas
É aqui que o risco começa a mudar de forma material. O agente pode chamar ferramentas, APIs, flows ou conectores.
Exemplo:
- Um agente de suporte de TI que cria tickets e verifica o status de um dispositivo.
- Um agente de atendimento ao cliente que consulta pedidos e inicia ações aprovadas.
- Um agente do Copilot Studio conectado a flows do Power Automate ou APIs de sistemas de negócio.
Riscos principais:
- Uso não autorizado de ferramentas
- Permissões excessivas
- Prompt injection levando a uso indevido de ferramentas
- Vazamento de dados por entradas ou saídas de ferramentas
- Auditabilidade incompleta
Foco de governança:
- Matriz de permissões de ferramentas
- Acesso de menor privilégio
- Regras de aprovação
- Logs de auditoria
- Aplicação de políticas em runtime
Nível 4: agente de workflow autônomo
O agente pode monitorar eventos, tomar decisões e executar tarefas sem esperar por um prompt do usuário.
Exemplo:
- Um agente que monitora e-mails de fornecedores, extrai mudanças contratuais, classifica risco e encaminha aprovações.
- Um agente financeiro que monitora exceções de reconciliação e inicia workflows de correção.
- Um agente de segurança que observa alertas, enriquece casos e toma medidas de contenção.
Riscos principais:
- Ação não aprovada
- Decisão errada em escala
- Falha silenciosa
- Falha de escalonamento
- Disrupção do processo de negócio
- Lacunas em evidências de conformidade
Foco de governança:
- Validação de gatilhos
- Limites de decisão
- Aprovação humana para ações críticas
- Monitoring e alerting
- Resposta a incidentes
- Kill switches
Nível 5: orquestração multiagente
Vários agentes se coordenam, delegam ou repassam trabalho.
Exemplo:
- Um processo de onboarding de cliente em que um agente coleta documentos, outro verifica compliance, outro atualiza sistemas e outro se comunica com o cliente.
Riscos principais:
- Lacunas de accountability
- Instruções conflitantes
- Propagação de erros
- Delegação oculta
- Análise de causa raiz difícil
Foco de governança:
- Identidade dos agentes
- Regras de delegação
- Rastreabilidade ponta a ponta
- Testes em nível de sistema
- Modelo de ownership
Regra prática: não governe o rótulo; governe o comportamento.
Exemplos de casos de uso por nível de agente
Os níveis não pretendem ser caixas perfeitas. Eles são uma forma prática de perguntar: quanta agency esse sistema realmente tem?
| Nível de agente | Casos de uso típicos | O que o torna agêntico | Foco de governança |
|---|---|---|---|
| Nível 1: assistente de conhecimento | Q&A de políticas de RH, busca de conhecimento para helpdesk de TI, FAQ de compliance interna, assistente de documentação de produto, assistente de onboarding | Responde com base em fontes aprovadas, mas não executa ações | Qualidade do conhecimento, controle de acesso, atualização das fontes, avisos, caminhos de escalonamento |
| Nível 2: assistente de workflow guiado | Rascunho de respostas para clientes, resumo de contas de vendas, preparação de briefs para reuniões, sugestões de next-best-action, primeiras versões de notas de risco | Guia um humano em uma tarefa enquanto o humano continua sendo o decisor | Revisão humana, transparência de fontes, limites do workflow, treinamento, aprovação do resultado final |
| Nível 3: agente que usa ferramentas | Criação de tickets de suporte, verificação de status de pedidos, consulta a registros de CRM, abertura de solicitações de serviço de TI, invocação de flows do Power Automate | Chama ferramentas ou conectores, normalmente dentro de uma sessão iniciada pelo usuário | Matriz de permissões, menor privilégio, audit logging, regras de aprovação, testes de prompt injection |
| Nível 4: agente de workflow autônomo | Monitoramento de e-mails de fornecedores, roteamento de exceções contratuais, triagem de alertas de segurança, reconciliação de exceções financeiras, escalonamento de casos de clientes | Age a partir de gatilhos e executa partes de um processo sem esperar um prompt explícito a cada etapa | Validação de gatilhos, limites de ação, monitoring, kill switches, aprovação humana para ações de alto impacto |
| Nível 5: orquestração multiagente | Onboarding de clientes entre KYC, jurídico, CRM e suporte; incident response com agentes de investigação e remediação; workflows corporativos de procurement | Vários agentes se coordenam, delegam ou repassam trabalho entre sistemas e equipes | Identidade dos agentes, regras de delegação, rastreabilidade ponta a ponta, testes de sistema, ownership e accountability |
Ferramentas de baixa agentividade ainda precisam de governança
Seria um erro tratar plataformas de baixa agentividade como inofensivas. Um agente simples do Copilot Studio ainda pode expor informações sensíveis, fornecer respostas enganosas, depender de conhecimento desatualizado ou criar uma falsa sensação de autoridade.
Mas ferramentas de baixa agentividade normalmente se encaixam em um modelo de governança mais leve, porque o sistema está principalmente respondendo, e não agindo de forma independente.
Para essas ferramentas, as perguntas mais importantes são:
- A quais fontes de conhecimento o agente pode acessar?
- As permissões são herdadas corretamente do Microsoft 365, SharePoint ou outros sistemas?
- As respostas estão ancoradas em conteúdo aprovado?
- O usuário sabe quando verificar ou escalar?
- As conversas são registradas adequadamente?
- Quem é o owner do agente depois do lançamento?
Isso é governança, mas é principalmente governança de conteúdo, acesso, qualidade e ownership.
O risco mais pesado começa quando o agente ganha ferramentas, autonomia, memória, gatilhos ou capacidade de afetar sistemas de negócio.
Nesse ponto, o modelo de governança precisa incluir desenho de controles, e não apenas revisão de conteúdo.
Por que a governança de IA existente não é suficiente
Muitos programas de governança de IA foram desenhados em torno de modelos e casos de uso. Eles pedem que as equipes documentem o modelo, classifiquem o caso de uso, avaliem impacto de privacidade, testem vieses e aprovem o deploy.
Esse é um bom começo. Mas agentes introduzem riscos que não são totalmente cobertos por uma governança centrada no modelo.
1. Agentes têm permissões
Modelos geram saídas. Agentes frequentemente têm permissões.
Eles podem acessar arquivos, consultar bancos de dados, chamar APIs, enviar e-mails, criar registros ou invocar workflows. Isso significa que a governança de agentes precisa pegar elementos emprestados de identity and access management.
A pergunta-chave passa a ser:
O que esse agente está autorizado a fazer, em quais condições, e quem aprovou essas permissões?
2. Agentes têm ferramentas
Ferramentas criam uma nova superfície de ataque. Uma instrução maliciosa escondida em um documento, e-mail, página web, ticket ou fonte de conhecimento recuperada pode tentar manipular o agente para usar suas ferramentas de forma incorreta.
Para agentes, prompt injection não é só sobre influenciar texto. Pode ser sobre influenciar ação.
3. Agentes têm comportamento em runtime
Uma avaliação do modelo antes do lançamento não é suficiente. Agentes podem se comportar de maneira diferente dependendo de gatilhos, contexto, respostas de ferramentas, dados recuperados, instruções do usuário e estado do workflow.
A governança precisa continuar em runtime por meio de logging, monitoring, alertas e resposta a incidentes.
4. Agentes precisam de limites de ação
Uma resposta aceitável não é a mesma coisa que uma ação aceitável.
Por exemplo, um agente pode ter permissão para redigir uma recomendação de reembolso, mas não para emitir o reembolso. Pode ter permissão para criar um ticket, mas não para fechá-lo. Pode resumir um risco contratual, mas não enviar o contrato revisado para a contraparte.
Esses limites precisam ser explícitos.
5. Agentes criam requisitos de evidência
Quando algo dá errado, a organização precisa reconstruir a sequência:
- O que disparou o agente?
- Quais dados ele viu?
- Qual instrução ele seguiu?
- Quais ferramentas ele chamou?
- Que decisão de política foi tomada?
- Havia exigência de aprovação humana?
- Quem aprovou ou rejeitou a ação?
- O que mudou no sistema de negócio?
Se você não consegue responder a essas perguntas, você não tem governança de agentes. Você tem esperança em agentes.
Um modelo prático de governança para agentes de IA
Um modelo útil de governança para agentes deve incluir pelo menos oito camadas de controle.
1. Inventário de agentes
Você não consegue governar agentes que não consegue ver.
Rastreie cada agente com:
- Owner
- Propósito
- Grupo de usuários
- Modelo ou plataforma
- Fontes de dados
- Ferramentas e conectores
- Nível de autonomia
- Nível de risco
- Status de aprovação
- Data de revisão
- Responsável por monitoring
2. Classificação de risco agêntico
Classifique agentes pelo comportamento, não pelo rótulo do fornecedor.
Dimensões úteis incluem:
- Ele pode acessar dados sensíveis?
- Ele pode chamar ferramentas?
- Ele pode escrever em sistemas?
- Ele pode agir sem prompt do usuário?
- Ele pode acionar comunicação externa?
- Ele pode tomar ou influenciar decisões de alto impacto?
- Ele pode delegar para outros agentes?
3. Matriz de permissões de ferramentas
Toda ferramenta deve ter uma política explícita.
Para cada ferramenta, defina:
- Permitida ou bloqueada
- Somente leitura ou com capacidade de escrita
- Aprovação necessária ou não
- Limites máximos
- Classes de dados permitidas
- Grupos de usuários permitidos
- Requisitos de logging
Uma ferramenta de reembolso, por exemplo, pode permitir recomendações em rascunho sem aprovação, exigir aprovação abaixo de um limite e bloquear reembolsos autônomos acima desse limite.
4. Pontos de aprovação humana
Human-in-the-loop não deve ser apenas um slogan. Precisa ser desenhado no workflow.
A aprovação deve ser obrigatória para:
- Compromissos legais
- Transações financeiras
- Decisões de RH
- Ações com impacto no cliente
- Mudanças sensíveis de segurança
- Ações irreversíveis
- Decisões automatizadas em alto volume
O registro da aprovação deve virar parte da trilha de auditoria.
5. Testes de prompt injection e uso indevido de ferramentas
Agentes devem ser testados contra cenários adversariais antes da produção.
Testar para:
- Documentos recuperados maliciosos
- Instruções conflitantes
- Tentativas de exfiltrar dados
- Tentativas de contornar aprovação
- Tentativas de usar ferramentas não autorizadas
- Tentativas de sobrescrever instruções do sistema
- Tentativas de acionar ações a partir de entradas não confiáveis
6. Audit logging em runtime
Os logs devem capturar mais do que a resposta final.
No mínimo, registrar:
- Gatilho do usuário ou do evento
- ID do agente
- Versão do prompt ou da instrução
- Versão do modelo
- Contexto recuperado
- Chamadas de ferramentas
- Entradas e saídas de ferramentas
- Decisões de política
- Aprovações humanas
- Ação final
- Trace ID
7. Monitoring e kill switches
Agentes precisam de controles operacionais.
Monitorar para:
- Uso inesperado de ferramentas
- Acesso incomum a dados
- Falhas repetidas
- Picos de escalonamento
- Anomalias de custo
- Comportamento em loop
- Ações fora de padrões normais
Um agente de alto risco deve ter um procedimento claro de pausa, revogação ou kill switch.
8. Revisões de ciclo de vida
Agentes evoluem. Suas ferramentas, prompts, fontes de dados, modelos, usuários e contexto de negócio mudam.
Revise agentes quando:
- Uma nova ferramenta for adicionada
- Uma nova fonte de dados for conectada
- A autonomia aumentar
- O modelo mudar
- O agente for publicado em um novo canal
- O processo de negócio mudar
- Um incidente ocorrer
A lição do Microsoft Copilot Studio
A abordagem da Microsoft é útil porque mostra o padrão empresarial emergente. O Copilot Studio reúne criação low-code de agentes, grounding em dados de negócio, ferramentas, flows, APIs, canais de publicação, capacidades de gestão, analytics e recursos de governança.
Mas também mostra por que as organizações precisam da sua própria linguagem de risco de agentes.
Um agente declarativo simples ou de prompt e resposta pode ser uma extensão administrável de knowledge management. Um agente autônomo do Copilot Studio conectado a workflows de negócio está mais próximo de um ator de processo digital. Um sistema multiagente coordenando ferramentas e áreas está mais próximo de um sistema operacional distribuído.
Esses sistemas não deveriam passar pela mesma checklist de aprovação.
A pergunta de risco não é:
Isso foi construído em Copilot Studio, Azure AI Foundry, LangGraph, OpenAI, CrewAI ou outro framework?
A pergunta melhor é:
Qual grau de agency esse sistema tem, e quais controles combinam com esse grau de agency?
Esse enquadramento também ajuda a evitar pontos cegos específicos do fornecedor. Uma plataforma low-code pode oferecer guardrails úteis, controles administrativos e integração com ferramentas corporativas de governança. Isso é valioso. Mas a organização ainda precisa decidir quais ações são aceitáveis, quais aprovações são exigidas, quais evidências precisam ser mantidas e quem é dono do agente depois do deployment.
Uma regra simples
Quanto mais um sistema de IA puder agir, mais a governança precisa se mover da documentação para o controle.
Use esta regra:
- Se ele apenas responde, governe conteúdo, acesso e precisão.
- Se ele recomenda, governe apoio à decisão e revisão humana.
- Se ele usa ferramentas, governe permissões e políticas de chamadas de ferramentas.
- Se ele age autonomamente, governe gatilhos, aprovações, monitoring e resposta a incidentes.
- Se ele se coordena com outros agentes, governe identidade, delegação e rastreabilidade ponta a ponta.
Essa é a base de AI Agent Risk.
O que fazer agora
Para organizações começando agora, os primeiros passos são práticos:
- Criar um inventário de todos os agentes e sistemas semelhantes a agentes.
- Classificá-los por nível de agency, e não por nome do produto.
- Identificar quais agentes podem acessar dados, chamar ferramentas ou disparar ações.
- Definir uma matriz de permissões para cada agente que usa ferramentas.
- Exigir aprovação humana para ações sensíveis ou irreversíveis.
- Registrar ações dos agentes de forma que suporte auditoria e resposta a incidentes.
- Testar agentes contra prompt injection, vazamento de dados e bypass de aprovação.
- Revisar agentes sempre que autonomia, ferramentas ou acesso a dados forem ampliados.
O futuro da governança de IA não será apenas sobre modelos. Será sobre sistemas que percebem, decidem e agem dentro de processos de negócio.
É por isso que agentes precisam de um novo modelo de governança.