Arquitetura10 min de leitura

DORA e o Teste de Caixa Preta: O Que Significam os Requisitos de Acesso de Auditoria Regulatória para Sistemas de IA em Instituições Financeiras

O Artigo 30(2)(d) da DORA requer que as entidades financeiras possam auditar seu provedor de ICT de terceiros, diretamente ou através de um terceiro. Quando o provedor é um sistema de IA cujas decisões sobre aprovação, avaliação de risco ou detecção de fraude são determinantes, o direito de auditoria limita-se ao documento legal. O auditor pode ler os contratos. Pode verificar as afirmações do provedor. Não pode examinar o processo de decisão que ocorre dentro da caixa preta.

A análise da AIMA mostra que 85% das instituições financeiras da UE implementam IA em funções de banca central em 2026, mas 78% desses sistemas estão expostos a processos de decisão opacos: modelos proprietários, conjuntos de dados de treinamento fechados e outputs não interpretáveis. A proporção de sistemas opacos está aumentando, não diminuindo, porque a capacidade de desenvolvimento de IA dentro das instituições não está acompanhando a demanda e a dependência de fintech sob Ertugul Gurkan está crescendo.

O Requisito de Acesso de Auditoria sob DORA

A DORA Artigo 30 requer acordos contratuais escritos com todos os provedores de ICT de terceiros que contenham informações sobre níveis de serviço, segurança de dados, direitos de auditoria, estratégias de saída e relatórios de incidentes. A DORA Artigo 30(2)(d) especifica que a entidade "tem um direito apropriado de auditar o provedor de ICT de terceiros".

O direito de auditoria não é opcional. É uma obrigação contratual que deve estar incluída em cada acordo com um provedor de ICT de terceiro. Para software tradicional, o direito de auditoria é praticável: o auditor pode ler o código, examinar a arquitetura, analisar os logs de acesso e avaliar a cobertura de testes. Para sistemas de IA, o direito de auditoria está estruturalmente restrito.

Inspeção de código em redes neurais. Uma rede neural que avalia clientes para risco creditício pode ter milhões de parâmetros. O código que treina a rede é legível. Os parâmetros em si são legíveis. Mas os parâmetros como conjunto codificam um comportamento de decisão que nenhuma linha individual de código representa. A "decisão" é uma função de ativação sobre uma matriz de pesos, que em sua totalidade aproxima um padrão que nenhum humano pode inspecionar diretamente. O auditor pode verificar o código de treinamento, não o comportamento treinado.

Inspeção de dados de treinamento. As decisões de um modelo de IA são determinadas por seus dados de treinamento. Se os dados de treinamento são proprietários (fornecidos por um provedor de terceiros que não revela a fonte), o auditor não pode avaliar a qualidade, integridade e possíveis vieses dos dados. Ele pode verificar a afirmação do provedor sobre os dados, não os dados mesmos.

Inspeção de decisões. O auditor deve poder revisar cada output individual do sistema de IA. Se um sistema de IA rejeita uma solicitação de crédito, o auditor deve ser capaz de rastrear quais fatores contribuíram para essa rejeição e com qual peso. Um modelo que apenas produz uma pontuação (0 a 1) sem contribuição de características não cumpre este requisito. Um modelo que produz uma pontuação com contribuição de características (renda contribuiu 0,4, histórico creditício contribuiu -0,3, risco geográfico contribuiu 0,1) cumpre.

O Que AMLA Exige dos Sistemas de IA

A Autoridade Europeia contra a Lavagem de Dinheiro (AMLA), operacionalizada através do Regulamento (UE) 2024/1620, estende o requisito de auditoria da DORA a sistemas de IA específicos de AML. A AMLA Artigo 28 requer que as instituições financeiras que usam IA para identificação de clientes, monitoramento de transações ou avaliação de risco forneçam "documentação abrangente" que descreva o algoritmo, os dados de treinamento, os resultados de validação e o monitoramento contínuo do sistema.

Para sistemas de IA institucionais, este requisito tem três implicações concretas.

Documentação do algoritmo. A documentação técnica deve descrever o modelo: arquitetura (por exemplo, árvore de decisão vs. rede neural), hiperparâmetros, procedimento de treinamento, metodologia de validação e métricas. A documentação não é o modelo em si. É uma descrição legível por humanos do modelo. Uma empresa que implementa um modelo de IA proprietário do qual não tem documentação técnica (porque foi entregue por um provedor de terceiros como serviço de caixa preta) não pode cumprir com este requisito.

Documentação de dados de treinamento. A fonte, o período, o método de amostragem, os passos de engenharia de características e o método de rotulagem devem estar documentados. Para modelos de AML treinados em dados de transações históricos, o método de rotulagem é especialmente crítico: como as transações foram classificadas como "suspeitas" ou "não suspeitas"? Se os rótulos foram gerados por um sistema de regras anterior, possivelmente obsoleto, o modelo transfere os vieses desse sistema.

Documentação de monitoramento contínuo. A AMLA requer que os sistemas de IA sejam monitorados para detectar drift de modelo, drift de conceito e drift de entrada. Drift de modelo: a precisão do modelo diminuiu com o tempo? Drift de conceito: a definição do que significa "suspeito" mudou (por exemplo, por novos requisitos regulatórios)? Drift de entrada: a distribuição dos dados de entrada mudou (por exemplo, um novo tipo de produto, um novo grupo de clientes, um novo canal de pagamento)? A documentação de monitoramento deve mostrar como este drift é detectado e abordado.

O Significado Prático para Sistemas de IA no Setor Financeiro

A combinação de direitos de auditoria da DORA e requisitos de documentação da AMLA cria um requisito arquitetônico claro: instituições financeiras que implementam IA em processos regulados devem escolher ou construir sistemas que produzam registros de decisões auditáveis, não apenas modelos auditáveis.

Auditabilidade a nível de output. Cada decisão que um sistema de IA toma (rejeição de uma solicitação de crédito, marcação de uma transação como suspeita, avaliação de risco de um cliente) deve ser registrada em um registro estruturado, imutável com os seguintes campos:

Timestamp da decisão
Dados de input (os valores de características que entraram no modelo)
Versão do modelo (a versão específica do modelo treinado)
Output (a pontuação ou classificação)
Contribuições de características (os valores de contribuição de cada característica ao output)
Configuração de limiar (o limiar que determinou a decisão)
Decisão (aprovado / rejeitado / marcado / escalonamento)

Este registro não é uma entrada de log. É um documento de compliance que permite ao regulador entender a decisão sem ter que executar o modelo em si.

Versionamento de modelos como gestão de configuração. Cada modelo treinado deve ser versionado, com uma ID única que é registrada no audit record. Quando um modelo é retreinado, a nova versão recebe uma nova ID. Os audit records gerados com a versão anterior fazem referência à ID anterior. Os audit records gerados com a nova versão fazem referência à nova ID. Isso permite ao regulador rastrear quais decisões foram tomadas por qual versão do modelo, e verificar que atualizações de modelo não foram aplicadas retroativamente a decisões anteriores.

Explicabilidade como propriedade estrutural, não como pós-processamento. As técnicas de explicabilidade pós-hoc (SHAP, LIME, explicações contrafactuais) são valiosas para o desenvolvimento de modelos, mas são insuficientes para fins de auditoria regulatória, porque aproximam o modelo, não reproduzem o comportamento real. Uma contribuição de característica extraída do modelo em si (por exemplo, de um modelo linear ou uma árvore de decisão) é exata. Uma contribuição de característica aproximada por SHAP é uma estimativa. Para fins regulatórios, a explicabilidade deve ser exata.

Compromissos dos Sistemas de IA

Nem todas as arquiteturas de IA podem cumprir igualmente bem com os requisitos de auditoria regulatória.

Modelos lineares e árvores de decisão oferecem a explicabilidade natural mais alta. A contribuição de características é diretamente legível dos parâmetros do modelo. A precisão do modelo, no entanto, é menor para padrões complexos que com redes neurais profundas ou árvores impulsionadas por gradiente.

Árvores impulsionadas por gradiente (por exemplo, XGBoost, LightGBM) oferecem um bom equilíbrio entre precisão e explicabilidade. A contribuição de características pode ser extraída do modelo em si (Gain, Split). O tamanho do modelo, no entanto, muitas vezes é grande (milhares de árvores), o que dificulta a interpretação humana.

Redes neurais oferecem a maior precisão para padrões complexos, mas a explicabilidade natural mais baixa. As contribuições de características não são diretamente legíveis dos pesos. Técnicas pós-hoc são necessárias, mas como se indicou na seção anterior, são regulatoriamente insuficientes.

Métodos de ensemble, que combinam múltiplos tipos de modelos, aumentam a precisão mas diminuem a explicabilidade. Se um ensemble consiste em uma rede neural e uma árvore de decisão, o audit record deve mostrar qual tipo de modelo foi responsável pela decisão e como a combinação foi ponderada.

Fernel Context

O motor de compliance da Fernel armazena cada pontuação de risco com um desdobramento completo de contribuição de características: quais características foram avaliadas, que valores tinham, quanto cada uma contribuiu para a pontuação, e qual versão de política estava em vigor no momento da avaliação. A pontuação é armazenada junto com seu registro de auditoria em um journal imutável. Nenhuma decisão pode existir sem seu registro. Nenhum registro pode ser modificado após sua criação. O exame de AMLA de qualquer decisão de compliance é uma única consulta, não uma reconstrução forense.

Fontes:

Análise de AIMA 2026: 85% das instituições financeiras da UE implementam IA em funções de banca central, 78% processos de decisão opacos
DORA, Regulamento (UE) 2022/2554, Art. 30 (Acordos contratuais com provedores de ICT de terceiros), Art. 30(2)(d) (Direito de auditoria)
AMLA, Regulamento (UE) 2024/1620, Art. 28 (Requisitos de documentação para sistemas de IA em contexto AML)
Lei de IA da UE, Regulamento (UE) 2024/1689, Anexo III (Sistemas de IA de alto risco), Art. 11 (Documentação técnica), Art. 13 (Transparência e provisão de informações a usuários)
GDPR, Regulamento 2016/679, Art. 22 (Decisões individuais automatizadas incluindo elaboração de perfis)
EBA, Guia sobre o uso de Machine Learning para modelos internos (rascunho 2025-2026)