Antes de entrar para a Sardine, passei duas décadas no setor bancário. Primeiro, desenvolvendo sistemas de risco de ponta a ponta para bancos de varejo e gestão de patrimônio e, depois, reunindo um grupo de bancos de primeira linha para projetar e operacionalizar a estrutura de gestão de risco da rede Zelle.
Hoje, ajudo a construir infraestrutura moderna de detecção de fraudes e de risco na Sardine e lidero o Sonar, uma solução de utilidade para o setor voltada ao risco de contraparte e ao compartilhamento de inteligência entre bancos, fintechs e redes de pagamento.
Quando apresentamos o Agentic Oversight Framework (AOF), ele repercutiu em todo o setor, mas também levantou uma pergunta imediata dos meus antigos colegas das áreas de risco, compliance e políticas:
“Como transformamos isso de um framework conceitual em algo que os reguladores realmente aprovarão?”
Este playbook é a minha resposta.
Ela preenche a lacuna entre inovação e escrutínio regulatório, traduzindo a AOF em componentes acionáveis e prontos para supervisão, adaptados à governança de modelos, supervisão de terceiros e equipes de risco operacional.
Para bancos que buscam implantar agentes de IA com segurança — seja para revisão e/ou tomada de decisão, atendimento ao cliente ou automação de fluxos de trabalho — este playbook oferece a estrutura operacional necessária para se alinhar às expectativas em evolução dos reguladores.
1. A governança de IA agente começa com a classificação dos agentes e a estratificação de riscos
Em vez de criar políticas separadas para cada agente de IA, desenvolva um mapa de classificação que atribua os agentes a níveis de risco. O nível determina o grau de supervisão, documentação e validação necessários.
- Nível 1 (impacto crítico): Agentes que acionam diretamente medidas regulatórias, financeiras ou legais, como o envio de Relatórios de Atividade Suspeita (SARs), o bloqueio de pagamentos ou a realização de verificações de sanções. Esses agentes exigem uma validação de modelo abrangente, consistente com a norma SR 11-7 do Federal Reserve, incluindo controles de contingência e registros de auditoria imutáveis.
- Nível 2 (impacto moderado): Agentes que auxiliam na tomada de decisão, mas não atuam de forma autônoma. Exemplos incluem apoio a onboarding, triagem de fraude ou fluxos de trabalho de KYC. As saídas influenciam decisões humanas, portanto, explicabilidade e revisões com humanos no circuito são obrigatórias.
- Nível 3 (baixo impacto): Agentes que dão suporte a funções internas, como pesquisas de conhecimento ou elaboração de relatórios. Eles não acionam obrigações de conformidade, mas devem ser registrados e monitorados para evitar uso não regulamentado em fluxos de trabalho críticos. Agentes de Nível 3 podem estar sujeitos a controles mais leves, mas exigem reclassificação se o seu impacto aumentar.
Essa abordagem em camadas está alinhada à governança baseada em risco do OCC e do FFIEC.
2. Arquitetura técnica: sistemas de IA auditáveis e defensáveis
Para os examinadores, a arquitetura faz parte da gestão de riscos. Um sistema de IA em conformidade não é apenas preciso. Ele é auditável, defensável e seguro por concepção:
- Gateway de inferência: Fica entre o usuário e o modelo. Ele mascara ou tokeniza dados pessoais, garantindo que os modelos não acessem informações sensíveis desnecessárias.
- Runtime do agente (container de modelo): Corrige a versão e a configuração do modelo em tempo de execução. Isso evita “atualizações silenciosas” que poderiam comprometer a explicabilidade ou causar desvio em relação à validação.
- Camada de explicabilidade: Gera o raciocínio em cadeia (chain-of-thought), pontuações de confiança e um resumo em uma linha explicando por que o modelo tomou a decisão.
- Registro de auditoria imutável: Cada prompt, entrada, modelo e saída é registrado e transformado em hash. Isso garante prontidão para auditorias da FFIEC e permite que os reguladores reproduzam exatamente o que o modelo viu.
- Camada de garantia de qualidade (QA) para decisões de Agentes: Além do registro em log, os sistemas devem permitir amostragem periódica e revisão estruturada das decisões dos agentes, assim como fariam para tomadores de decisão humanos. Isso permite que as equipes de compliance, auditoria e QA testem regularmente o alinhamento com políticas, façam verificações pontuais de casos extremos e garantam que os resultados permaneçam consistentes com as expectativas. Também apoia a melhoria contínua e atende às expectativas de supervisão em estruturas como SR 11-7, FFIEC e o Artigo 15 da Lei de IA da UE, que enfatizam a supervisão contínua em vez de uma validação única.
- Caminhos de fallback: Integrados para quando o modelo falhar ou a qualidade da resposta cair. O mecanismo de regras aciona ações conservadoras padrão ou encaminha a tarefa para um revisor humano.
- Monitoramento contínuo: Painéis automatizados e alertas para detectar deriva do modelo, comportamentos atípicos ou degradação de desempenho em tempo real.
Ao mapear cada parte do sistema para NIST 800-53 e ISO 27001, sua equipe de segurança da informação pode certificar a prontidão tanto para auditorias internas quanto para exames.
3. Validação de modelos de IA SR 11-7: guia prático em conformidade com a supervisão
Agentes de IA que influenciam de forma material ou executam decisões são tratados como modelos sob a SR 11-7, independentemente de utilizarem aprendizado de máquina tradicional ou LLMs. A validação deve atender às expectativas de supervisão. Assim, a validação deve incluir:
- Adequação à política: Revise se a lógica do agente reflete a política do banco (por exemplo, nega uma transação pelo motivo correto, sinaliza comportamentos suspeitos conforme as regras de BSA/AML).
- Backtesting: Teste o agente em casos históricos. Verifique com que frequência ele toma decisões corretas, gera falsos positivos ou falsos negativos. Em seguida, quantifique o risco.
- Verificações de robustez: Aleatorize ou reformule as entradas para garantir que o modelo não altere as saídas com base em diferenças superficiais.
- Testes adversariais: Forneça entradas maliciosas (injeções de prompt, dados malformados, textos muito longos) e observe os modos de falha. Ele trava, congela ou alucina?
- Revisão independente: O relatório final é assinado por alguém de fora da equipe de desenvolvimento (conforme o requisito de independência SR 11-7). Ele deve ser fácil de entender, não apenas código Python.
- Auditorias de viés e equidade: Avalie periodicamente o impacto desigual, especialmente em crédito, fraude ou onboarding. Acompanhe métricas de equidade por classe protegida e documente as medidas de mitigação.
Esse processo é repetido periodicamente, após qualquer atualização do modelo ou sempre que um desvio for detectado pelo monitoramento contínuo. O que é especialmente importante para a validação de modelos de IA sob a SR 11-7 é que os bancos devem comprovar que as saídas dos agentes são precisas, estáveis, revisadas de forma independente e alinhadas com as políticas.
4. Controles de privacidade de dados e cibersegurança que minimizam lacunas de conformidade
Todo agente deve seguir Zero Trust princípios ao lidar com dados, o que significa que deve verificar a identidade, limitar o acesso apenas aos dados necessários para cada tarefa e registrar todas as interações para auditoria. Nenhum agente deve presumir que sistemas internos ou outros agentes são inerentemente confiáveis. Nenhum modelo, fornecedor ou prompt deve acessar mais do que o absolutamente necessário.
- GLBA: Os dados financeiros devem ser criptografados e acessados apenas para usos permitidos definidos. (15 USC §§ 6801-6809)
- CCPA: As pessoas têm o direito de ser informadas, de solicitar correções e de optar pela exclusão. Se agentes de IA gerarem mensagens para clientes, esses direitos devem estar incorporados. (Cal. Civ. Code §§ 1798.100–1798.199)
- NY DFS: Exige notificação de violação em até 72 horas, planos de resposta a incidentes e certificação anual de conformidade. (23 NYCRR §§ 500.1–500.22)
- Artigo 22 do RGPD: Para operações na UE/Reino Unido, proíbe decisões exclusivamente automatizadas com efeitos significativos sem intervenção humana.
- ISO/NIST: Cada componente do sistema deve ser associado ao seu conjunto de controles para apoiar auditorias e testes de segurança.
- Dados sintéticos: Se usados para testes, treinamento ou validação, os dados sintéticos devem ser avaliados quanto a vazamento de privacidade e risco de inferência de associação, especialmente quando derivados de conjuntos de dados de produção. De acordo com o NIST SP 800-53 Rev. 5 e as orientações emergentes da ISO/IEC 42001, espera-se que os bancos demonstrem que os conjuntos de dados sintéticos não podem ser retroengenheirados para revelar informações pessoais não públicas (NPI).
- Transferências transfronteiriças de dados: Para bancos globais, garanta que os fluxos de dados dos agentes de IA estejam em conformidade com as leis internacionais de transferência de dados (por exemplo, GDPR, UK DPA).
Não presuma que o fornecedor de IA cuidará disso. Seu banco continua sendo o controlador de dados e é responsável por qualquer uso indevido.
5. Explicabilidade, auditabilidade e acesso de reguladores
Se você não consegue explicar uma decisão, não consegue defendê-la. Todo resultado que informa ou executa uma decisão regulada deve ser registrado com:
- Entradas exatas (devidamente redigidas)
- Versões de modelo e parâmetros de configuração
- Justificativas claras e compreensíveis para as decisões.
- Manter trilhas de auditoria reproduzíveis para apoiar exames e processos de contestação de consumidores.
Esses registros devem dar suporte a notificações de ação adversa conforme ECOA/FCRA e ser recuperáveis para investigação de reclamações e garantia de qualidade de conformidade. Quanto mais estruturados forem, mais fácil será passar por uma auditoria de governança de modelos.
6. Risco de IA de terceiros no setor bancário: supervisão de fornecedores e controles contratuais
Quando plataformas ou APIs de terceiros estiverem envolvidas, os contratos devem cobrir explicitamente:
- Direitos de auditoria: Permitir que as equipes internas e os órgãos reguladores inspecionem logs, histórico de versões e linhagem de dados
- Certificações de segurança: Exigir SOC 2 Tipo II, ISO 27001 e testes de penetração documentados.
- Notificação de incidentes: Exigir a divulgação de incidentes de segurança ou de modelo em até 72 horas.
- Saída de dados: Garanta que seus dados possam ser recuperados e excluídos. Caso contrário, você não poderá trocar de fornecedor sem risco.
- Riscos de modelos de código aberto: Se utilizar LLMs ou frameworks de código aberto, garanta a devida avaliação, aplicação de correções e monitoramento de vulnerabilidades.
Essas disposições estão alinhadas com as diretrizes regulatórias sobre gestão de riscos de terceiros.
7. Estrutura de supervisão de agentes de IA: trilhos de segurança, fallback e modos de falha
As equipes de risco operacional devem presumir falhas e definir controles para cada modo.
- Limites de tempo e de tokens: Recurso a mecanismos baseados em regras ou triagem humana.
- Resultados com baixa confiança: Escalar automaticamente para revisão manual.
- Entradas tóxicas e injeção de prompt: Filtrar padrões de ataque conhecidos.
- Desvio de saída: Compare continuamente as saídas com as linhas de base. Re-treine ou reverta conforme necessário.
- Plano de resposta a incidentes: Defina etapas claras de triagem, comunicação, notificação regulatória e remediação (NY DFS § 500.16).
Todos os cenários de falha devem ser mapeados para os procedimentos de resposta a incidentes existentes. Inclua entradas específicas do modelo em seus playbooks operacionais e no planejamento de continuidade de negócios.
8. Alinhamento de relatórios regulatórios: Garantindo prontidão contínua para auditorias
Se um agente interagir com um processo regulamentado, relacione seu papel a cada obrigação de reporte:
- Envio de RAS: Os resultados devem poder ser revisados pela área de compliance. Guarde os registros por 5 anos.
- ECOA/FCRA: Forneça a fundamentação do modelo e os dados de entrada para as comunicações de ação adversa.
- UDAAP: Evitar comunicações automatizadas injustas, enganosas ou abusivas.
- GDPR: Forneça direitos de recurso humano para decisões automatizadas (operações na UE/Reino Unido).
Isso deve ser incluído nos testes de controle e examinado periodicamente pelas áreas jurídica e de conformidade.
9. Comunicação e transparência com o cliente
Para decisões que envolvam clientes:
- Forneça aviso prévio de que IA está sendo utilizada
- Ofereça um canal para recurso humano
- Garantir que as divulgações atendam aos padrões do CFPB e ao Artigo 22 do GDPR
- Evite avisos vagos ou escondidos.
Aqui está um modelo de divulgação de exemplo:
“Esta decisão foi tomada com o auxílio de sistemas automatizados. Se você tiver dúvidas ou desejar solicitar uma revisão manual, entre em contato com o [canal de suporte].”
10. Inventário de modelos e gestão do ciclo de vida
Mantenha um único registro, com controle de versão, de todos os sistemas de IA em uso ou em teste. Inclua:
- Nome do agente
- Nível de risco
- Proprietário
- Última validação
- Histórico de atualizações
- Situação atual
- Localização dos logs de auditoria
Use isto para relatórios trimestrais para as funções de risco de modelo e risco corporativo. Certifique-se de arquivar e aplicar controle de versão a todas as alterações para garantir a prontidão para auditorias. Se um agente não utilizado for desativado formalmente, garanta que existam controles para evitar sua reativação acidental.
11. Lista de verificação de implantação: antes de entrar em produção
Exigir aprovações documentadas de:
- Risco de modelo: Validação, alinhamento com políticas, auditoria de equidade.
- Segurança da informação: Revisão do modelo de ameaças, segurança de endpoints, monitoramento.
- Privacidade: Processamento de dados lícito, minimização e conformidade transfronteiriça.
- Aquisições: Avaliação de risco de fornecedores, salvaguardas contratuais, planejamento de saída.
- Operações: Testes de intervenção humana, resposta em tempo real, prontidão para resposta a incidentes.
- Auditoria interna: Verificação de logs, integridade da trilha de auditoria.
- Conformidade: Confirmação de alinhamento com as leis e regulamentos aplicáveis.
Cada aprovação deve indicar a área de controle específica revisada e quaisquer condições impostas à implantação. Se alguma equipe bloquear o lançamento, essa decisão deve ser documentada com a devida justificativa e a rota de escalonamento.
12. Monitoramento contínuo e melhoria
Uma vez implantados, os agentes devem ser continuamente avaliados por meio de:
- Painéis de monitoramento em tempo real e alertas para detectar desvios e anomalias.
- Testes periódicos de desafio com entradas sintéticas e adversariais.
- Revisões trimestrais da classificação de risco, dos resultados de validação e do registro de modelos.
Estabeleça um protocolo formal de gestão de mudanças que registre, revise e aprove todas as modificações em prompts de agentes, parâmetros de modelos ou ferramentas subjacentes. Isso garante rastreabilidade e alinhamento com as políticas, além de atender às expectativas de supervisão sob estruturas como a SR 11-7 e OCC 2023-17.
É importante incorporar o feedback de incidentes, auditorias e recursos de clientes nas melhorias contínuas. Essas contribuições ajudam a revelar casos extremos que podem não ser capturados por dados sintéticos ou retrotestados e garantem que as funções de controle permaneçam responsivas ao comportamento do mundo real.
Incorpore confiança na arquitetura
Agentes de IA podem reduzir o tempo de tomada de decisão de horas para minutos. Mas, sem controles adequados, eles podem aumentar o risco regulatório. Ao estabelecer uma supervisão em camadas, incorporar salvaguardas técnicas, manter a rastreabilidade e reforçar a responsabilidade humana, os bancos podem implantar agentes de IA que sejam conformes por concepção e defensáveis em auditorias.
Se você quiser ver uma demonstração dos agentes de IA da Sardine em ação, ou quiser saber mais sobre como implantar esses agentes com segurança em produção, entre em contato conosco.
Perguntas frequentes
O que é IA agente no setor bancário?
A IA agêntica no setor bancário é a implementação de agentes de IA que executam ações em múltiplas etapas dentro de limites controlados de risco: triagem de filas de alertas, redação de narrativas de RAS, encaminhamento de revisões manuais, escalonamento de casos de fraude com alta confiança. O ser humano dá a aprovação final em decisões voltadas para clientes ou reguladores.
Como a SR 11-7 se aplica à IA agente?
A orientação SR 11-7 (a diretriz do Federal Reserve para gestão de risco de modelos) se aplica a qualquer modelo que influencie uma decisão regulada. A IA agêntica herda a SR 11-7 mais o suplemento SR 26-2, que adiciona requisitos de explicabilidade, rastreabilidade das decisões e documentação do espaço de ações delimitado.
O que é a orientação SR 26-2 do Federal Reserve?
A SR 26-2 é o suplemento de 2026 do Federal Reserve à SR 11-7, voltado especificamente para IA agentiva no setor bancário. Ela define requisitos de validação para tomada de decisão autônoma, espaços de ação delimitados e rastreabilidade de auditoria, além de incluir um Pedido de Informações (Request For Information) ao setor sobre o cronograma de aplicação das regras.
O que é o Framework de Supervisão Agente (AOF)?
O Agentic Oversight Framework é a implementação de referência da Sardine das normas SR 11-7 e SR 26-2 para IA agentiva. Ele inclui o registro imutável de auditoria de decisões, a documentação do espaço de ação limitado, o fluxo de aprovação com humano na etapa de validação e o rastreamento de linhagem exigido pelos examinadores.
Como o Sonar reduz o risco de IA de terceiros para bancos?
Fornecedores de IA de terceiros introduzem risco na cadeia de suprimentos. O consórcio Sonar pré-avalia esses fornecedores com base em sinais compartilhados pelas instituições-membro, identificando risco de concentração, degradação de desempenho e anomalias de comportamento antes que afetem o tráfego de produção do próprio banco.