Última atualização: Setembro de 2026
TL;DR
Um agente precisa de governança, mas um modelo não, por três razões: ele possui permissões, realiza ações e mantém o contexto entre as etapas. Um modelo gera uma pontuação sobre a qual outro sistema age; um agente é o sistema que age. Tudo o que há de genuinamente novo na governança de um agente decorre disso, e a melhor forma de desbloquear uma revisão de segurança é comparecer com o artefato que responde a cada pergunta de limite, e não com um documento de política.
O que é governança de agentes de IA?
A governança de agentes de IA é o conjunto de limites e registros que tornam o comportamento de um agente compreensível antes de agir e reconstituível após a ação. Os limites definem o que o agente pode ler, o que ele pode fazer sem ajuda e o que ele deve encaminhar. Os registros estabelecem o que ele viu, o que concluiu e quem foi o responsável pelo resultado.
Se você está lendo isso, a sua situação provavelmente é específica: a prova de conceito funciona, os resultados são bons, mas a revisão de segurança está travada há três semanas. Isso raramente acontece porque o agente não é seguro. Geralmente é porque ninguém colocou no papel as cinco coisas que um revisor precisa ver, no formato exato que ele precisa ver.
Esses cinco limites são: acesso a dados, ações permitidas, encaminhamento, limite do modelo e responsabilidade.
Por que governar um agente não é o mesmo que governar um modelo
Muitas instituições já operam com uma estrutura de gestão de risco de modelos, e a primeira pergunta útil é quanto dessa estrutura pode ser aproveitada.
Muitas partes servem, incluindo a disciplina de validação, hábitos de documentação, monitoramento contínuo de desempenho e comparação com desafiadores. Se você já tem uma área madura de risco de modelos, você não está começando do zero.
O que não serve é tudo o que decorre de três diferenças básicas:
Um agente possui permissões. Um modelo não tem direitos de acesso. Ele recebe variáveis e retorna um número. Um agente lê sistemas, e algo precisa definir quais sistemas ele pode ler.
Um agente realiza ações. Uma pontuação não pode fechar um alerta, solicitar um documento ou enviar um relatório. Um agente pode, e o conjunto de coisas que ele pode fazer sem a intervenção de um humano é uma decisão que alguém precisa tomar explicitamente.
Um agente mantém o contexto entre as etapas. Um modelo pontua cada caso de forma independente. Um agente acumula estado, o que significa que seu comportamento na etapa quatro depende do que aconteceu na etapa um. Reconstituir uma decisão significa reconstituir uma sequência de fatos, e não apenas uma única inferência.
Nada em uma estrutura de risco de modelos diz o que um agente pode fazer sem ajuda, porque uma pontuação não tem permissões e não pode agir. Essa é a lacuna que a governança precisa preencher.
Os cinco limites que uma revisão de segurança vai questionar
Limite | A pergunta que o revisor faz | O artefato que responde |
|---|---|---|
Acesso a dados | O que este agente pode ler e como você garante isso? | Um escopo de acesso documentado com linhagem de dados — quais sistemas, quais campos, sob as credenciais de quem |
Ações permitidas | O que ele pode fazer sem intervenção humana? | Um conjunto explícito de ações permitidas, com tudo o que estiver fora dele bloqueado por padrão |
Encaminhamento | Quando ele deve parar e perguntar? | Uma política de encaminhamento com os limites que a acionam e evidências de que esses limites estão sendo aplicados |
Limite do modelo | Qual modelo gerou este resultado específico? | Um registro do modelo e da versão associado a cada decisão, para que o resultado possa ser rastreado até o que o gerou |
Responsabilidade | Quem é o responsável pelo resultado quando algo dá errado? | Um proprietário nomeado por classe de decisão — e não por decisão individual |
Associar cada limite ao artefato que o atende é a parte que costuma faltar. Uma visão geral de governança explica que os agentes precisam de supervisão. Uma revisão precisa saber qual documento colocar na pasta. Essa tabela é exatamente o que você deve levar em mãos para a reunião.
Onde os limites são realmente definidos
Os limites não são um exercício de política feito após a implementação. Na prática, a sequência ideal envolve mapear os dados e esquemas da instituição, configurar as regras e políticas internas e, em seguida, estabelecer filas e permissões.
Essa ordem é o argumento central. As permissões e filas são estabelecidas no momento de colocar o agente em funcionamento, e não adaptadas às pressas após objeções da segunda linha de defesa. Um modelo de governança improvisado depois é, com certeza, o que trava as revisões, pois precisa ser desconstruído a partir do comportamento em vez de ser lido diretamente de uma configuração clara.
Isso também responde à pergunta que as instituições fazem com mais frequência: isso funciona com os sistemas de risco que já temos? Os limites e as políticas são seus. O agente opera dentro dos limites configurados pela própria instituição.
O formato da implementação também importa aqui, pois muda quem é o proprietário de cada controle. Os agentes da Oscilar podem rodar como uma camada independente na infraestrutura existente ou como parte de uma plataforma unificada, e a divisão de responsabilidades muda entre os dois casos. A questão da integração é tratada detalhadamente no artigo sobre como adicionar agentes de IA sem substituir sua estrutura de risco atual.
O que as regras realmente dizem agora
As diretrizes atualizadas de gestão de risco de modelos dos EUA excluem explicitamente a IA generativa e os agentes de IA do seu escopo. O comunicado do OCC declara que "os modelos de IA generativa e agentes de IA são novos e evoluem rapidamente. Como tal, não estão no escopo destas diretrizes." Isso consta no comunicado à imprensa do OCC NR 2026-29, publicado em 17 de abril de 2026, com orientações relacionadas no Boletim do OCC 2026-13.
Separadamente, o OCC, o Federal Reserve Board e o FDIC planejam publicar uma solicitação de informações sobre a gestão de risco de modelos em geral, considerando em particular o uso de IA pelos bancos — incluindo IA generativa e agentes de IA. Até o momento em que este texto foi escrito, nada foi publicado, não há prazo para comentários e não se trata de uma consulta específica sobre agentes de IA.
A interpretação que realmente importa: essa exclusão remove uma lista de checagem burocrática, mas não elimina nenhuma das perguntas dos auditores. Ninguém disse às instituições que elas podem parar de se preocupar em como um agente é testado, monitorado ou mantido sob supervisão humana. Eles apenas decidiram, por enquanto, não dizer exatamente como fazer. A obrigação continua de pé e o método prescrito está ausente, o que é uma posição mais difícil do que ter um manual de regras. É por isso que os artefatos da tabela acima importam muito mais do que um mapeamento de conformidade.
A norma SR 11-7 continua sendo a referência certa para pensar sobre isso. Trata-se de uma expectativa sob a qual as instituições operam, e a plataforma da Oscilar foi desenhada para se ajustar a ela: uma trilha de auditoria completa por decisão com justificativas salvas, supervisão humana por padrão (human-in-the-loop) e monitoramento de desvio e viés. Isso é um princípio de design, não uma certificação, e vale a pena manter essa distinção clara em qualquer conversa com a segunda linha.
A trilha de auditoria e o que ela deve conter
"Nós temos uma trilha de auditoria" não é uma resposta suficiente para uma revisão de segurança. A verdadeira questão é se esse registro consegue reconstruir uma decisão e se um humano consegue entendê-lo.
Uma arquitetura útil possui duas camadas. Existe um registro bruto, onde cada motivo de recusa e cada resultado está associado aos dados de origem. E existe uma visualização simplificada construída a partir desse registro — telas legíveis para analistas, e não logs de máquina complexos.
Duas camadas são necessárias porque um revisor faz duas perguntas. Você pode provar? é respondida pelo registro bruto. Seu analista consegue ler isso com clareza? é respondida pela visualização simplificada. A maioria das soluções atende apenas à primeira pergunta, mas é a segunda que determina se o controle é prático no dia a dia ou se existe apenas no papel.
O que deve constar no registro de cada decisão:
Dados de entrada que o agente visualizou
O raciocínio que ele utilizou e salvou
A ação prática que ele realizou
O modelo e a versão exata que geraram o resultado
O profissional que revisou, aprovou ou alterou a decisão
A razão para estruturar as coisas dessa forma não é mera organização. Você precisa estar em uma posição onde, independentemente das decisões tomadas, você possa defendê-las. A supervisão humana é o mecanismo que possibilita essa defesa, e não apenas um item bonito em um slide de apresentação. Vale notar a diferença entre essa postura e as promessas de que os agentes "resolvem tudo sozinhos".
Em conversas sobre governança, promessas de autonomia total jogam contra você.
Esse mesmo registro estruturado é o que servirá para avaliações futuras e ajustes finos, já que cada dado exibido em um caso está vinculado à sua respectiva decisão. Esse ponto é melhor detalhado em como avaliar um agente de IA de risco antes de colocá-lo em produção.
De quem é a responsabilidade pelo resultado
A jornada da maioria das revisões de agentes que acabam travando passa por uma variação desta pergunta, e esse costuma ser o verdadeiro obstáculo, muito mais do que qualquer controle técnico.
A responsabilidade está atrelada a uma classe de decisão, e não a uma decisão individual. Ninguém aprova manualmente cada alerta gerado, e nenhuma norma exige isso. Alguém é o dono da política que define como tratar uma categoria de alertas, e é essa definição de propriedade que o revisor quer encontrar.
Três papéis devem ser definidos claramente antes da revisão de segurança, pois são os mais questionados:
Quem é o dono da política: os limites de tolerância e as ações permitidas
Quem é o dono do modelo: sua validação e acompanhamento de desempenho
Quem é o dono da exceção: os casos que sobem para análise humana e as decisões alteradas manualmente
Sendo bem direto com a parte mais complexa: "o agente decidiu" não é uma resposta aceitável para um revisor, e nem a sua instituição deveria querer isso. A presença humana no processo é uma definição de responsabilidade e governança antes de ser uma interface de usuário.
Monitorando um agente em produção
A obrigação de acompanhamento é contínua e é aqui que a falta de regras claras pesa mais. Os auditores vão perguntar como você garante que o agente funciona bem, e nenhum manual atual traz essa resposta pronta.
O ponto essencial a demonstrar é um monitoramento que cubra desvio de dados (data drift), desvio de variáveis (feature drift) e desvio de conceito (concept drift), com indicadores de desempenho (KPIs) medidos por segmento. A análise por segmento é fundamental. Um agente pode manter um desempenho geral estável enquanto apresenta resultados ruins para um grupo específico de clientes.
A complexidade dos agentes de IA é que eles possuem mais variáveis sujeitas a desvios do que um modelo tradicional. Suas entradas, ferramentas e o público sobre o qual ele atua podem mudar de forma independente, gerando sintomas diferentes. Isso exige uma atenção especial, explicada em detalhes no artigo sobre como monitorar desvios em agentes de IA de risco.
O que levar para a revisão de segurança
A pergunta mais prática que já nos fizeram sobre capacidade de auditoria veio de um banco durante a criação de uma prova de conceito. Eles não perguntaram se as decisões de produção eram salvas. Perguntaram se existiam trilhas de auditoria para os testes de simulação.
A resposta é que existem duas trilhas separadas. Mas o que chama a atenção é a pergunta em si: um revisor não quer apenas provas do que o agente decidiu depois que entrou no ar. Ele quer ver o histórico do que foi feito durante a fase de testes. Um documento de política comprova a intenção, mas um registro de testes comprova a prática real. É nesse intervalo entre "desenhamos este controle" e "colocamos este controle em prática" que as revisões costumam travar.
Portanto, a lista de checagem para levar à reunião se alinha diretamente aos cinco limites:
Acesso a dados — escopo documentado e linhagem de dados
Ações permitidas — lista explícita de ações, bloqueando por padrão o que estiver fora
Encaminhamento — a política, os limites de tolerância e provas de aplicação prática
Limite do modelo — registro de modelo e versão por decisão
Responsabilidade — dono responsável nomeado por classe de decisão
Além do registro de testes — o que foi testado antes do lançamento e os resultados apresentados
Nada disso é um bicho de sete cabeças. Trata-se basicamente de documentar decisões que foram tomadas informalmente durante a implementação. É por isso que as instituições que passam mais rápido pelas revisões são as que definiram as permissões e filas na fase de instalação do agente, e não depois.
Governança não é um imposto pago para colocar um agente no ar. É o que permite que ele continue operando com segurança.
Perguntas frequentes
O que é governança de agentes de IA?
A governança de agentes de IA é o conjunto de limites e registros que tornam o comportamento de um agente compreensível antes de agir e reconstituível após a ação. Os limites definem o que o agente pode ler, o que pode fazer sem ajuda e o que deve encaminhar; os registros mostram o que ele viu, o que concluiu, qual modelo gerou o resultado e quem foi o responsável por ele.
Como governar agentes de IA em serviços financeiros?
Definindo cinco limites e mantendo um artefato para cada um deles: escopo de acesso a dados documentado, conjunto de ações permitidas com bloqueio por padrão para o restante, política de encaminhamento com limites de tolerância bem aplicados, registro de modelo e versão por decisão e um dono responsável por classe de decisão. Em instituições reguladas, essas medidas se somam à estrutura de risco de modelos existente em vez de substituí-la.
A governança de agentes de IA pode funcionar com os sistemas de risco atuais da instituição?
Sim, e os limites devem ser definidos pela própria instituição. Regras e políticas são configuradas durante a implementação em vez de virem prontas do fornecedor. O processo padrão envolve mapear dados e esquemas, configurar limites e políticas e estabelecer filas e permissões. Os agentes podem rodar como uma camada independente na infraestrutura atual ou integrados a uma plataforma unificada, o que muda a distribuição de responsabilidades de cada controle.
Quais controles de governança são necessários para agentes de IA?
Escopo de acesso com linhagem de dados, conjunto explícito de ações permitidas, política de encaminhamento com regras claras, registro de modelo e versão por decisão, responsabilidade nomeada por classe de decisão, trilha de auditoria em duas camadas e monitoramento contínuo de desvios com KPIs de desempenho segmentados.
As diretrizes de risco de modelos se aplicam a agentes de IA?
Nos EUA, atualmente não. As diretrizes atualizadas de gestão de risco de modelos excluem explicitamente a IA generativa e os agentes de IA de seu escopo — o comunicado NR 2026-29 do OCC, de 17 de abril de 2026, afirma que tais modelos "não estão no escopo destas diretrizes". O OCC, o Federal Reserve e o FDIC planejam publicar uma solicitação de informações para avaliar o risco de modelos e o uso de IA pelos bancos, mas ainda sem data ou prazo de comentários. As exigências de auditores sobre testes, monitoramento e supervisão humana continuam valendo normalmente.
Quem é o responsável quando um agente de IA toma uma decisão?
Um profissional nomeado, responsável pela classe de decisão e não por cada ação individual. Três papéis de propriedade devem ser definidos antes de uma revisão: o dono da política, o dono do modelo e o dono da exceção. "O agente decidiu" não é aceito como resposta.
Como são controlados a revisão humana, a capacidade de auditoria e o desempenho do agente?
A revisão humana é controlada por uma política de encaminhamento com regras claras e proprietários definidos por classe de decisão. A capacidade de auditoria é assegurada por um registro em duas camadas — um bruto vinculado aos dados e outro simplificado para analistas. O desempenho é controlado por monitoramento constante de desvios de dados, variáveis e conceitos, com KPIs medidos por segmento de público.

Equipe Oscilar
A equipe da Oscilar é formada por especialistas em diversas áreas de gestão de risco. Estes artigos refletem pontos de vista e conhecimentos de várias fontes e colaboradores de toda a organização.


