O que é governança de agentes de IA
Governança de agentes de IA é o conjunto de responsáveis, regras, controles e registros que determinam quais agentes estão em operação, com quais permissões e sob qual nível de supervisão. Não se trata de uma camada de segurança isolada, mas de uma disciplina operacional que atravessa TI, compliance, jurídico e as áreas de negócio que consomem esses agentes.
A distinção entre limitar e governar é central. Limitar é fixar fronteiras estáticas: bloquear um endpoint, restringir um escopo de API. Governar é manter autoridade sobre cada decisão que o agente executa em tempo real, incluindo decisões que as regras estáticas não previram. Um agente pode respeitar todos os limites configurados no deploy e ainda assim causar dano em situações que nenhum desenvolvedor antecipou.
O tema ganhou urgência porque agentes autônomos proliferaram em múltiplas plataformas — Microsoft Copilot, Salesforce Agentforce, ServiceNow Now Assist, entre outras — sem que a maioria das organizações tenha estabelecido uma política centralizada. Cada time implanta seus próprios agentes, com suas próprias credenciais, sem inventário unificado nem critério de desativação.
Riscos concretos da falta de governança
Agent sprawl
Agentes criados sem dono definido acumulam permissões e geram custos invisíveis. Com o tempo, ninguém sabe exatamente o que cada agente faz, quem autorizou sua criação ou se ele ainda é necessário. O resultado é um ambiente onde recursos são consumidos silenciosamente e o surface de ataque cresce sem controle.
Ações irreversíveis sem supervisão humana
Agentes que respondem e-mails em nome de executivos, movem registros entre sistemas ou tomam decisões financeiras automatizadas representam risco operacional imediato quando não há mecanismo de aprovação. Um erro de lógica ou uma instrução maliciosa pode produzir efeitos que nenhum rollback desfaz facilmente: comunicações enviadas, dados deletados, transações confirmadas.
Identidade e rastreabilidade
Sem identidade única por agente, é impossível auditar quem fez o quê em nome de quem. Quando um agente opera sob as credenciais de um usuário humano ou de uma conta de serviço compartilhada, qualquer investigação de incidente se torna inviável. Compliance e resposta a incidentes dependem de rastreabilidade granular.
Efeito cascata em ambientes multi-agente
Em pipelines onde agentes orquestram outros agentes, um único agente comprometido pode injetar instruções maliciosas nos demais, técnica conhecida como prompt injection indireta. Sem isolamento e validação entre agentes, o perímetro de confiança colapsa em toda a cadeia.
Componentes essenciais de um modelo de governança
Dono de agente (agent owner)
Cada agente deve ter uma pessoa responsável pelo seu propósito, custo e resultado, tratado como um serviço interno da organização. Esse dono responde por solicitações de auditoria, aprova mudanças de escopo e decide quando o agente deve ser desativado. Sem dono, não há responsabilidade operacional real.
Identidade e escopo
Cada agente recebe credenciais próprias com as permissões mínimas necessárias para executar seu propósito, princípio do menor privilégio aplicado a identidades não humanas. Isso inclui escopos de OAuth, permissões de API, acesso a datastores e qualquer integração com sistemas externos.
Política em tempo de execução
As regras que um agente deve seguir não podem existir apenas no momento do deploy. O agente precisa consultar políticas ativas antes de agir, especialmente em cenários que envolvem dados sensíveis, comunicação externa ou modificações em sistemas críticos. Políticas estáticas no código tornam-se obsoletas rapidamente.
Registro de ações (audit log)
Toda decisão relevante tomada pelo agente deve ser registrada em log imutável: a ação executada, os dados consultados, o contexto que motivou a decisão e o horário. Esse registro serve tanto para compliance regulatório quanto para diagnóstico de falhas e melhoria contínua do comportamento do agente.
Ponto de supervisão humana (human-in-the-loop)
A definição explícita de quais ações exigem aprovação humana antes de serem executadas é o controle mais crítico em ambientes de alto risco. Esse ponto de supervisão não precisa ser manual para toda ação, mas deve ser mandatório para ações irreversíveis, de alto impacto financeiro ou que afetam dados pessoais.
Frameworks de referência aplicáveis
NIST AI RMF
O AI Risk Management Framework do NIST organiza a gestão de risco em quatro funções: Governar, Mapear, Medir e Gerenciar. A função Governar é particularmente relevante aqui: ela exige que a organização estabeleça papéis, responsabilidades e cultura de risco antes de escalar qualquer sistema de IA. O framework é adaptável a agentes autônomos sem exigir interpretações forçadas.
ISO 42001 e catálogos de controle por domínio
A ISO 42001 introduz um sistema de gestão para IA com requisitos de política, avaliação de impacto e controles operacionais. Uma abordagem prática derivada dela é organizar controles por domínio — identidade, acesso, dados, comunicação, auditoria — com um dono definido por domínio. Isso distribui a responsabilidade sem centralizar tudo em um único time.
Contexto brasileiro: LGPD e decisões automatizadas
O artigo 20 da LGPD garante ao titular o direito de solicitar revisão de decisões tomadas exclusivamente por meios automatizados. Agentes de IA que afetam clientes — concessão de crédito, triagem de atendimento, personalização de ofertas — enquadram-se nessa categoria. A organização precisa ser capaz de explicar a decisão e, se solicitado, revisá-la com supervisão humana.
Plataforma não substitui política
Ferramentas de orquestração e plataformas de agentes oferecem controles técnicos nativos, mas esses controles refletem as prioridades do vendor, não as da organização. Em ambientes multi-plataforma, delegar toda a governança ao produto cria lacunas entre sistemas. Política e responsabilidade precisam existir na camada organizacional, independentemente de qual plataforma executa o agente.
Armadilhas comuns e sinais de alerta
Governança só no papel
Documentar controles em um framework sem implementá-los em tempo de execução não reduz risco operacional: apenas distribui a responsabilidade formal. Se o audit log não está sendo gerado, se a política não é consultada em runtime e se o dono do agente não recebe alertas de anomalia, a governança existe apenas como artefato de compliance.
Plataforma como substituto de política
Delegar toda a governança ao vendor impede controle centralizado quando a organização opera com múltiplas plataformas simultaneamente. Cada plataforma tem seu próprio modelo de permissões, seus próprios logs e seus próprios mecanismos de aprovação. Sem uma camada organizacional unificadora, o inventário de agentes fica fragmentado por ferramenta.
Entusiasmo sem estrutura
Pressão de liderança para escalar agentes rapidamente, sem que TI e compliance tenham sido envolvidos na definição de controles, é um dos padrões de risco mais comuns. O resultado típico é uma coleção de agentes em produção sem inventário, sem dono e sem política de desativação, exatamente o cenário de agent sprawl descrito anteriormente.
Falta de plano de desativação
Agentes sem critério de descomissionamento continuam rodando e consumindo recursos após o projeto que os originou ser encerrado. Credenciais permanecem ativas, permissões não são revogadas e o agente segue processando dados sem que ninguém saiba que ele ainda existe. Desativação precisa ser parte do ciclo de vida desde o momento da criação.
Como avaliar e dar os primeiros passos
Antes de estruturar qualquer framework, faça um inventário realista. Liste todos os agentes em produção, seus donos formais, os sistemas que acessam e o volume aproximado de ações por semana. Esse levantamento costuma revelar surpresas: agentes que ninguém assumiu como responsabilidade e integrações que ninguém sabia que existiam.
Com o inventário em mãos, classifique os agentes por nível de risco. Agentes que apenas leem dados têm perfil muito diferente dos que escrevem, deletam ou se comunicam externamente. Essa classificação determina quais controles são obrigatórios imediatamente e quais podem ser implementados de forma incremental.
Defina um quórum de aprovação explícito: quais ações são executadas automaticamente, quais passam por aprovação humana e quais são bloqueadas por padrão independentemente do contexto. Esse quórum deve ser revisado por compliance e pelo time jurídico antes de ir para produção.
Por fim, estabeleça uma cadência de revisão de permissões — trimestral é o mínimo recomendado. Agentes acumulam permissões ao longo do tempo da mesma forma que contas de serviço humanas. Sem auditoria periódica, o princípio do menor privilégio se degrada silenciosamente até deixar de existir na prática.





