Um regulador de serviços financeiros, ao conduzir um exame de supervisão de um fornecedor de pontuação de crédito por IA, solicitou a trilha de auditoria completa das decisões para uma amostra aleatória de cinquenta solicitações de crédito abrangendo os dezoito meses anteriores. O exame do regulador estava focado na governança de modelos de IA, especificamente em saber se o fornecedor conseguia demonstrar que cada decisão havia sido tomada por uma versão do modelo devidamente validada, que os dados de entrada usados em cada decisão eram completos e precisos e que a lógica da decisão podia ser reconstruída para revisão regulatória. A equipe de tecnologia do fornecedor apresentou os logs da API. Os logs confirmavam que chamadas de API de pontuação de crédito haviam sido feitas para cada uma das cinquenta solicitações e que uma pontuação havia sido retornada para cada uma. Os logs capturavam: o carimbo de data e hora da chamada de API, o endpoint de API acessado, o token de autenticação usado e a pontuação de crédito final retornada. Os logs não capturavam: a versão do modelo que havia gerado a pontuação (o sistema usava o modelo de produção, que havia sido atualizado sete vezes no período de dezoito meses), os valores das variáveis de entrada passados ao modelo (a API aceitava um ID de cliente e o modelo recuperava as variáveis internamente) ou as saídas intermediárias do modelo que ligavam as entradas à pontuação final. Em três das cinquenta solicitações, o regulador identificou que o histórico de crédito do solicitante havia sido atualizado após a pontuação original, o que significava que as variáveis usadas pelo modelo no momento da decisão não podiam ser reconstruídas retrospectivamente nem mesmo a partir do cadastro atual do cliente. O fornecedor conseguia confirmar que as decisões de crédito haviam sido tomadas. Não conseguia reconstruí-las.
O que são, de fato, o registro e a rastreabilidade em IA?
O registro e a rastreabilidade em IA são a captura abrangente das informações necessárias para reconstruir a decisão de um sistema de IA a qualquer momento após a decisão ter sido tomada, especificamente a versão do modelo que tomou a decisão, os dados de entrada apresentados ao modelo no momento da decisão, as saídas intermediárias do modelo e a saída final da decisão. A rastreabilidade das decisões de IA é substancialmente diferente do registro de aplicações: o registro de aplicações captura que uma função foi chamada e o que ela retornou; a rastreabilidade das decisões de IA captura informações suficientes para reconstruir a própria decisão e validar que ela foi tomada corretamente por um modelo devidamente validado, com dados de entrada precisos.
O problema da captura da versão do modelo é a primeira lacuna de rastreabilidade. Modelos de IA são atualizados (retreinados, ajustados, com a versão incrementada) em diferentes periodicidades. Um modelo de pontuação de crédito pode ser atualizado mensalmente com base em novos dados de treinamento e no monitoramento de desempenho. Cada versão pode tomar decisões diferentes para as mesmas entradas de um solicitante. Se uma auditoria, um recurso ou uma revisão regulatória exigir a compreensão de uma decisão tomada doze meses atrás, a pergunta relevante é qual versão do modelo estava em produção naquele momento. Sem o registro da versão do modelo no nível de cada decisão, pode ser impossível determinar qual versão do modelo tomou uma decisão histórica específica.
O problema da captura das entradas no momento da decisão é a segunda lacuna de rastreabilidade. Modelos de IA que recuperam variáveis internamente (de um feature store, de um banco de dados de cadastro de clientes ou de uma API externa) tomam decisões com base nos valores das variáveis existentes no momento da decisão. Os cadastros de clientes mudam: históricos de crédito são atualizados, endereços mudam, o histórico de pagamentos evolui. Se as variáveis de entrada não forem capturadas no momento da decisão, a reconstrução retrospectiva do que o modelo usou pode ser impossível, pois o cadastro do cliente que existe hoje pode ser diferente daquele que o modelo acessou quando a decisão foi tomada.
O problema da captura das saídas intermediárias é a terceira lacuna de rastreabilidade. Modelos de IA complexos (ensembles, redes neurais, pipelines de várias etapas) produzem saídas intermediárias que ligam as entradas às decisões finais por meio de várias etapas de processamento. Capturar apenas a pontuação final da decisão não permite reconstruir a lógica que a produziu. Para fins regulatórios, em especial os requisitos do Artigo 22 do GDPR e da Lei de IA da UE, a capacidade de explicar uma decisão individual específica pode exigir acesso às saídas intermediárias que mostram como as variáveis de entrada contribuíram para a pontuação final.
Por que isso importa
O registro e a rastreabilidade em IA são importantes para TPRM porque exames regulatórios, litígios e recursos contra decisões individuais exigem a capacidade de reconstruir decisões específicas de IA a partir de registros históricos. A empresa que implanta a IA de um fornecedor para decisões relevantes e não consegue apresentar a trilha de auditoria das decisões enfrenta exposição regulatória e jurídica, independentemente de o registro de API do fornecedor ser abrangente.
Onde a maioria das equipes erra
A falha mais constante é equiparar o registro de API à rastreabilidade das decisões de IA. O registro de API confirma que o serviço foi chamado e o que ele retornou. A rastreabilidade das decisões de IA permite reconstruir a própria decisão: versão do modelo, variáveis de entrada, lógica intermediária.
- Registro de API equiparado à rastreabilidade das decisões
- Versão do modelo não capturada no nível de cada decisão
- Variáveis de entrada não capturadas no momento da decisão
- Saídas intermediárias não registradas em arquiteturas de modelos complexas
- Requisitos regulatórios de rastreabilidade não mapeados para o desenho dos registros
Como é uma boa prática
Programas maduros de registro em IA capturam o registro completo da decisão em cada inferência: identificador da versão do modelo, valores das variáveis de entrada no momento da decisão, principais saídas intermediárias e decisão final, retidos pelo período exigido pelos regulamentos aplicáveis e pelos requisitos de preservação para litígios.
- Versão do modelo capturada em cada decisão
- Variáveis de entrada registradas no momento da decisão, e não reconstruídas a partir do cadastro atual
- Saídas intermediárias capturadas para reconstrução em nível de auditoria
- Período de retenção alinhado aos requisitos regulatórios
- Trilha de auditoria de decisões demonstrável mediante solicitação: teste antes que a auditoria a exija
Ferramentas
Observabilidade de ML em IA: Arize AI, Whylogs, MLflow com registro de decisões
Plataformas de observabilidade de ML capturam a versão do modelo, as variáveis de entrada e as previsões no momento da inferência, criando o log de decisões de IA que o registro de API não fornece. Para profissionais de TPRM, perguntar se o log de decisões de IA do fornecedor captura a versão do modelo e as variáveis de entrada em cada inferência, separadamente do registro de acesso à API, é uma pergunta específica sobre a rastreabilidade das decisões.
Desafios de governança
O desafio de governança do registro de decisões de IA é o volume e o custo de capturar as variáveis de entrada em cada inferência. Sistemas de IA de alto volume podem pontuar milhões de solicitações por dia, e capturar o vetor completo de variáveis em cada inferência gera necessidades significativas de armazenamento. A solução de governança é o registro estratificado por risco: rastreabilidade completa das decisões para decisões de alto impacto (crédito, seguros, emprego) e registro mais leve para aplicações de menor impacto.
- Exigir registro no nível de cada decisão: versão do modelo e variáveis de entrada em cada inferência
- Testar a trilha de auditoria de decisões antes que uma auditoria regulatória a exija
- Alinhar o período de retenção aos requisitos regulatórios e de litígio
- Solicite uma demonstração da trilha de auditoria de decisões para uma amostra de decisões históricas
- Exigir suporte a auditorias regulatórias como obrigação contratual
Se você faz parte de uma equipe pequena
Faça a pergunta da simulação de auditoria: se um regulador solicitasse a trilha de auditoria completa de uma solicitação de crédito pontuada dezoito meses atrás (a versão do modelo, as variáveis de entrada no momento da decisão e a lógica que produziu a pontuação), você conseguiria apresentar essas informações? E consegue demonstrar isso reconstruindo agora uma decisão histórica a partir dos seus logs? O pedido de demonstração revela a capacidade real por trás da documentação.
- Solicite uma demonstração da trilha de auditoria de uma decisão histórica
- Pergunte se a versão do modelo é capturada em cada decisão
- Pergunte se as variáveis de entrada são capturadas no momento da decisão
- Pergunte sobre o período de retenção dos logs de auditoria de decisões
O que exigir
Pergunte diretamente:
“Vocês conseguem demonstrar a trilha de auditoria completa de uma decisão de crédito tomada dezoito meses atrás, especificamente a versão do modelo que tomou a decisão, as variáveis de entrada no momento da decisão e a lógica que produziu a pontuação final?”
O que esperar como evidência
- Demonstração da trilha de auditoria de decisões históricas
- Confirmação da captura da versão do modelo
- Confirmação do registro das variáveis de entrada no momento da decisão
- Período de retenção dos logs de decisões
Um fornecedor que confirme ter registro abrangente deve ser solicitado a demonstrar a reconstrução de uma decisão histórica. A demonstração revela o que o registro realmente captura e se um registro de API abrangente e uma rastreabilidade abrangente das decisões de IA são a mesma coisa.
Como comprovar
- Registros de demonstração da trilha de auditoria de decisões
- Confirmação do registro da versão do modelo
- Confirmação do registro das variáveis de entrada
- Documentação do período de retenção
Principal conclusão
O auditor solicitou a trilha de auditoria. Os logs mostravam que a API havia sido chamada. A decisão havia sido retornada. A versão do modelo: não capturada. As variáveis de entrada: não capturadas no momento da decisão. Três solicitações em que o cadastro do cliente havia mudado desde a pontuação: variáveis de entrada irrecuperáveis. O registro de API era abrangente. A rastreabilidade das decisões não existia. O registro de API e a rastreabilidade das decisões de IA são capacidades diferentes. Um confirma que o serviço foi usado. A outra permite reconstruir a própria decisão. Versão do modelo no momento da decisão, variáveis de entrada no momento da decisão, saídas intermediárias para reconstrução: esses são os requisitos de registro de decisões de IA que o registro de API não atende. Teste a trilha de auditoria antes que o auditor o faça.