Explicabilidade e auditabilidade da IA em finanças

Por Jane Ha · Atualizado em 11 de outubro de 2026

Explicabilidade e auditabilidade na IA financeira são duas promessas distintas: você consegue dizer por que o sistema produziu um resultado específico (explicabilidade) e consegue provar depois o que o sistema fez, com quais entradas, em qual versão e quem o revisou (auditabilidade). Reguladores, auditores e clientes se apoiam cada um em uma metade diferente. Quem teve o crédito negado quer o motivo da recusa. O auditor quer a trilha de evidências. A equipe de risco de modelos quer as duas, além da prova de que alguém independente questionou o modelo.

Este guia é para CFOs, controllers, líderes de risco e gerentes financeiros que estão colocando IA em crédito, fraude, previsões, fechamento ou relatórios. Se você quer a definição em linguagem simples da técnica em si, leia O que é IA explicável?. Este artigo trata da parte específica de finanças: o que precisa ser explicado, para quem e o que você precisa ter em arquivo.

Fatos Principais

• A Regulation B exige que a declaração de motivos de uma ação adversa de crédito "deve ser específica e indicar o(s) motivo(s) principal(is)", e declarações baseadas em padrões internos ou em uma pontuação de crédito abaixo do limite não bastam (12 CFR 1002.9).
• A orientação interagências de risco de modelos de abril de 2026, a SR 26-2, substitui a SR 11-7 e deve ser mais relevante para organizações bancárias com mais de $30 bilhões em ativos totais (Federal Reserve).
• Essa orientação deixa os modelos de IA generativa e agêntica fora do seu escopo, enquanto seus princípios se aplicam a modelos estatísticos tradicionais e a IA não generativa e não agêntica (anexo da SR 26-2).
• O EU AI Act classifica como de alto risco os sistemas de IA destinados a avaliar a solvência de pessoas físicas ou a definir sua pontuação de crédito, e exige que esses sistemas permitam tecnicamente o registro automático de eventos (logs) ao longo de sua vida útil (Anexo III, Artigo 12).
• O NIST separa as duas ideias: a explicabilidade é uma representação dos mecanismos que sustentam a operação de um sistema, enquanto a interpretabilidade é o significado de sua saída no contexto da finalidade para a qual foi projetado (NIST AI RMF 1.0).

Por que finanças exige mais da IA

A maioria das áreas de negócio convive com um modelo que funciona, mas não sabe dizer por quê. Finanças quase nunca pode, por três motivos.

As decisões carregam deveres legais. Quando um credor recusa um solicitante, as regras dos EUA exigem um motivo específico. O motivo precisa refletir o que realmente determinou a decisão, e não um rótulo genérico.

Os números alimentam demonstrações nas quais as pessoas confiam. Se um modelo define uma provisão, redige uma explicação de flux ou concilia lançamentos do razão, alguém precisa conseguir mostrar ao auditor como aquele número passou a existir. O lado dos controles disso é tratado em IA e controles internos. Este artigo cobre a camada que fica por baixo: a documentação e os registros que tornam um controle testável.

Os erros são caros e demoram a ser encontrados. Uma previsão em deriva ou um modelo de pontuação enviesado pode operar por meses até alguém notar, e a única forma de reconstruir o que aconteceu é ter mantido os registros.

O que reguladores e auditores realmente esperam

As expectativas variam conforme a jurisdição e o caso de uso, então vale separá-las.

Decisões de crédito (EUA). A Regulation B, que implementa o Equal Credit Opportunity Act, exige que o credor informe ao solicitante recusado os motivos principais em termos específicos. A norma dá ao credor 30 dias, contados do recebimento de uma solicitação completa, para notificar o solicitante da decisão tomada (12 CFR 1002.9). A consequência prática para a IA: se o seu modelo não consegue produzir motivos que você possa sustentar, você tem um problema de conformidade, por mais preciso que o modelo seja. As ferramentas de explicação posteriores aproximam um modelo em vez de reproduzi-lo, então a equipe precisa conseguir verificar se a aproximação é fiel.

Gestão de risco de modelos (bancos dos EUA). A orientação de 2011, a SR 11-7, foi substituída pela SR 26-2, que adota uma abordagem baseada em risco e afirma que o questionamento efetivo é uma análise crítica feita por especialistas objetivos, executada por pessoas com a expertise certa, independência suficiente e autoridade para fazer as mudanças acontecerem. Ela também diz que um inventário de modelos eficaz contém informação suficiente para entender o risco de modelos em nível individual e agregado, e que uma documentação adequada sustenta a gestão eficaz do risco de modelos (SR 26-2). A orientação exclui do seu escopo a IA generativa e a agêntica, mas também diz que as próprias práticas de governança de um banco devem orientar os controles das ferramentas que ela não cobre. Se você é uma instituição menor ou uma equipe de finanças corporativas, trate-a como um modelo bem testado, e não como um regulamento.

Modelos de fornecedores. A mesma orientação afirma que a boa prática inclui entender a solidez conceitual, o desenho, os dados de desenvolvimento e o desempenho de um modelo de fornecedor, e monitorar seus resultados, mesmo quando o fornecedor não revela o código ou os dados (SR 26-2). "O fornecedor diz que é preciso" não é documentação.

União Europeia. A pontuação de crédito de pessoas físicas é um uso de alto risco segundo o Anexo III do AI Act, e os sistemas de alto risco precisam permitir tecnicamente o registro automático ao longo de sua vida útil (Anexo III, Artigo 12). O cronograma da lei foi alterado, e o texto consolidado atual indica 2 de dezembro de 2027 como a data de aplicação para os sistemas do Anexo III (Artigo 12). As equipes jurídicas devem confirmar a situação no seu caso, mas a lição de engenharia é a mesma de qualquer forma: construa o registro agora, porque adaptá-lo depois é mais difícil.

Auditores de relatórios financeiros. Os auditores externos não pedem os detalhes internos do modelo em abstrato. Eles querem saber se a etapa de IA é uma parte conhecida, com responsável definido, de um processo documentado, com evidência de que alguém conferiu a saída.

Explicabilidade por função: o que "explicado" significa na prática

"Explicável" não é uma coisa só. A explicação certa depende de quem pergunta e do que está em jogo.

O padrão ao longo da tabela é o mesmo. A explicação trata dos direcionadores e da base, e a auditabilidade trata do registro. Um modelo pode ter uma sem a outra: um modelo de pontuação simples, baseado em regras, é fácil de explicar, mas continua inútil para um auditor se não registrar nada.

O kit de explicação e onde ele fica a dever

Duas técnicas aparecem o tempo todo em modelos complexos. O SHAP "atribui a cada variável um valor de importância para uma previsão específica" (Lundberg e Lee). O LIME explica uma previsão individual ajustando um modelo simples e interpretável na vizinhança dessa previsão, tratando o modelo subjacente como uma caixa-preta (Ribeiro et al.).

Ambos são úteis para a pergunta "por que este resultado". Nenhum substitui a governança, por três motivos:

• Eles explicam uma previsão, não a adequação do modelo. Uma explicação limpa de uma pontuação enviesada continua sendo uma pontuação enviesada.
• São aproximações. Trate a saída como evidência a ser validada, e não como o raciocínio real do modelo.
• Sozinhos, não produzem um motivo pronto para o cliente. Alguém precisa traduzir as contribuições dos fatores nos motivos principais que uma notificação possa declarar com exatidão.

Em decisões de alto risco, vale testar se um modelo mais simples abre mão de pouca acurácia, porque um modelo que você consegue inspecionar diretamente é mais fácil de defender do que um que precisa ser aproximado.

Documentação que se sustenta: fichas de modelo e inventários

Uma ficha do modelo (model card) é um documento curto que acompanha um modelo. A proposta original descreve as fichas como a documentação do desempenho medido em diferentes condições, do contexto de uso pretendido e de como a avaliação foi conduzida, para que os usuários saibam onde o modelo funciona e onde não funciona (Mitchell et al.). Os autores se concentram em visão e linguagem e dizem que a ideia vale para qualquer modelo treinado. Para uma equipe financeira, a ideia se transpõe diretamente. Veja fichas de modelo de IA para o formato geral.

Uma versão financeira pode incluir:

1. Finalidade e responsável. Qual decisão ou processo ela apoia e o responsável de negócio designado.
2. Uso pretendido e uso fora do escopo. Por exemplo, "pontua solicitações de crédito pessoal sem garantia; não serve para crédito a pequenas empresas".
3. Dados. Fontes de treinamento, janela de tempo, lacunas conhecidas e as exclusões aplicadas.
4. Método em um parágrafo. Tipo de modelo, variáveis principais e como as saídas viram decisões.
5. Desempenho. Medidas de acurácia, tolerância, resultados por segmento e o backtest contra os valores realizados.
6. Método de explicação. Como os motivos ou direcionadores são produzidos e quão fiéis se mostraram.
7. Limites e modos de falha conhecidos. Onde ele é fraco e o que aciona o tratamento manual.
8. Controles. Revisor, limites, alternativa se ele sair do ar e histórico de mudanças.
9. Validação. Quem o questionou, quando e o que encontrou.

Combine as fichas com um inventário: uma lista de todos os modelos e ferramentas de IA em uso, com responsável, finalidade, nível e local da ficha. A própria SR 26-2 observa que um inventário eficaz tem informação suficiente para entender o risco de modelos, e esse é o teste a aplicar ao seu. No caso de ferramentas de fornecedores, a ficha ficará parcialmente vazia. Registre isso por escrito em vez de deixar em branco e decida se as lacunas são aceitáveis para o nível de risco.

Trilhas de auditoria: o registro do que realmente aconteceu

A documentação diz o que um sistema deve fazer. Uma trilha de auditoria mostra o que ele fez em um dia específico. O princípio de registro da norma europeia é um bom padrão geral: registrar eventos ao longo da vida útil do sistema, de um modo que apoie o monitoramento e a investigação (Artigo 12). Para um tratamento mais aprofundado das trilhas quando a IA executa ações dentro de sistemas, veja trilhas de auditoria para ações de IA.

Uma trilha de auditoria financeira útil captura, para cada item relevante influenciado por IA:

• Entrada: os dados ou o documento que o sistema recebeu, ou uma referência a eles
• Versão: modelo, prompt ou conjunto de regras e configuração em vigor na época
• Saída: a pontuação, o lançamento, o alerta ou o texto produzido
• Explicação: os direcionadores ou motivos gerados junto com ela
• Ação humana: quem revisou, o que alterou ou substituiu e quando
• Resultado posterior: a decisão, o lançamento ou a notificação que se seguiu

A retenção deve acompanhar o registro que ela sustenta. Pergunte às suas equipes de registros e jurídica por quanto tempo é preciso manter os dossiês de crédito, os comprovantes de lançamentos e os papéis de trabalho, e garanta que os logs de IA não sejam excluídos antes disso. O tratamento de dados desses logs é um tema à parte, abordado em segurança de dados financeiros com IA.

Como construir explicabilidade e auditabilidade, passo a passo

1. Faça o inventário de todos os modelos e ferramentas de IA em finanças. Inclua os recursos de fornecedores ativados dentro de sistemas existentes. Você não consegue documentar o que não encontrou.

   

2. Classifique por consequência. Um modelo que define o resultado de crédito de um cliente ou uma provisão pertence a um nível mais rigoroso do que uma ferramenta que redige um resumo interno.

3. Defina o requisito de explicação por nível. Diga quem precisa conseguir obter uma explicação, com que rapidez e em que forma (notificação ao cliente, visão do analista, papel de trabalho do auditor).

4. Escolha os modelos já pensando no requisito. Nos usos de nível mais alto, teste se um modelo mais transparente é quase tão preciso antes de aceitar uma caixa-preta.

5. Escreva a ficha do modelo antes de entrar em produção. Condicione a aprovação do lançamento a uma ficha completa e a um responsável designado.

6. Obtenha questionamento independente. Alguém com a expertise e a independência adequadas revisa o modelo e seu método de explicação e pode exigir mudanças.

7. Ative o registro desde o primeiro dia. Capture entradas, versões, saídas, explicações e ações humanas. Teste se você consegue reconstruir uma única decisão de ponta a ponta a partir dos logs.

8. Faça um exercício de reconstrução. Escolha dez decisões passadas ao acaso e peça a alguém de fora da equipe de construção que explique cada uma apenas a partir dos registros. As lacunas aparecem rápido.

9. Monitore e documente de novo. Acompanhe acurácia, deriva e taxas de substituição. Atualize a ficha e repita o questionamento quando o modelo, os dados ou o uso mudarem. Veja controles de acurácia da IA em finanças para ideias de monitoramento.

Erros comuns

• Explicar o modelo, mas não a decisão. A importância global das variáveis não responde por que este solicitante foi recusado nem por que este lançamento foi sinalizado.
• Motivos genéricos. Enviar o motivo de checklist mais próximo quando o fator real é outro não passa no teste de especificidade da Regulation B.
• Confiar cegamente na ferramenta de explicação. Os métodos posteriores aproximam o comportamento. Teste-os contra casos conhecidos.
• Ficha do modelo como um PDF feito uma única vez. Uma ficha que não muda quando o modelo muda vira um registro falso.
• Logs sem versões. Saber qual foi a saída não adianta se você não consegue dizer qual modelo ou prompt a produziu.
• Opacidade do fornecedor aceita por padrão. "Proprietário" é motivo para monitorar os resultados com mais rigor, e não para dispensar a documentação.
• Revisão sem evidência. Um revisor que aprova, mas não deixa registro do que conferiu, não dá ao auditor nada para testar.
• Explicabilidade construída depois do lançamento. Adaptar logs e documentação custa muito mais do que projetá-los desde o início.

O que medir

• Cobertura: parcela dos modelos e ferramentas de IA com responsável, nível e ficha atualizada
• Taxa de reconstrução: parcela das decisões amostradas que podem ser totalmente explicadas apenas pelos logs
• Qualidade da explicação: com que frequência revisores ou validadores rejeitam os motivos gerados por serem imprecisos ou vagos demais
• Taxa de substituição: com que frequência as pessoas alteram a saída e por quê
• Atualização: tempo desde a última atualização de cada ficha e validação, em relação ao histórico de mudanças
• Encerramento de pendências: tempo para resolver as constatações de validação e de auditoria

Próximos passos

Comece pelo inventário e pela classificação em níveis, depois escreva as fichas do seu nível mais alto e faça um exercício de reconstrução. Se você ainda está mapeando onde a IA se encaixa, IA em finanças e contabilidade oferece a visão mais ampla.