IA explicável em BC/FT: SHAP, activação segundo o princípio dos quatro olhos e interruptor de emergência

Um modelo que classifica um cliente como de risco elevado, mas não consegue dizer porquê, não é um activo para o seu programa de conformidade; é um passivo à espera de um inspector. A promessa da inteligência artificial no trabalho de prevenção e combate ao branqueamento de capitais e financiamento do terrorismo (BC/FT) é real — melhor priorização dos alertas, menos horas desperdiçadas com falsos positivos óbvios, detecção mais precoce de padrões que uma regra deixaria escapar. Mas essa promessa só se cumpre se cada decisão em que o modelo intervém puder ser explicada, contestada e anulada por uma pessoa, e se o próprio modelo for governado como a peça de infra-estrutura de grandes consequências que é. A IA explicável em BC/FT — as 3 principais razões SHAP, pontuações de confiança, controlo com intervenção humana (human-in-the-loop), activação segundo o princípio dos quatro olhos, monitorização da deriva e um interruptor de emergência (kill switch) — é o que transforma um modelo engenhoso num modelo defensável.

Este artigo trata dessa distinção. Explica por que razão a pontuação de caixa negra não satisfaz a governação do risco de modelo, o que a explicabilidade tem realmente de apresentar no ecrã diante de um analista e como os controlos em torno de um modelo — registo de modelos, activação, monitorização, reversão e registo das decisões — mantêm a IA dentro dos limites traçados pelas autoridades de supervisão e pela política de risco de modelo da sua própria instituição. Para ver como a IA se integra no programa mais amplo, a par da avaliação de risco, da filtragem, da monitorização e das comunicações, consulte o guia completo da plataforma BC/FT. Este texto concentra-se no próprio modelo e na governação que o envolve.

Porque é que a pontuação de caixa negra falha perante a governação BC/FT

A gestão do risco de modelo tem um conjunto estabelecido de expectativas, anteriores à actual vaga de aprendizagem automática. Um modelo que influencia uma decisão regulada tem de ser compreendido pelas pessoas que dele dependem. Os seus pressupostos têm de estar documentados, o seu desempenho monitorizado, as suas limitações conhecidas e os seus resultados sujeitos a uma contestação humana efectiva. As autoridades de supervisão esperam que as instituições saibam como os seus modelos funcionam, e não apenas que funcionam.

Uma pontuação de caixa negra quebra todas essas expectativas de uma só vez. Quando um modelo devolve «0,87» e nada mais, o analista não consegue dizer se o valor reflecte um verdadeiro sinal de alerta ou um artefacto dos dados de treino. O responsável pela comunicação de operações suspeitas (MLRO) não consegue explicar a um regulador as decisões de risco da instituição. A função de validação não consegue testar se o modelo faz o que afirma fazer. E quando algo corre mal — uma categoria de clientes sistematicamente assinalada em excesso, um corredor de actividade silenciosamente ignorado — não há fio por onde puxar, porque o raciocínio nunca chegou a ser exposto.

A falha não é apenas técnica; é processual. As decisões BC/FT têm de resistir ao escrutínio muito depois de serem tomadas. Uma decisão sobre actividade suspeita tomada hoje pode ser questionada numa inspecção daqui a dois anos. Se o único registo do contributo do modelo for um número opaco, a instituição não consegue reconstituir por que razão um cliente foi escalado ou ilibado. A decisão torna-se indefensável, não por estar errada, mas porque não é possível demonstrar que foi fundamentada. É por isso que a explicabilidade não é uma funcionalidade acessória acrescentada a um modelo BC/FT. É a condição prévia para sequer utilizar o modelo.

O que a explicabilidade tem de pôr no ecrã

A explicabilidade é concreta, não uma aspiração. Na Plataforma BC/FT da Creodata, o serviço de inferência de IA (AI Inference) foi concebido para que cada elemento de IA — onde quer que um modelo contribua para uma pontuação ou uma recomendação — apresente as mesmas quatro informações, visíveis para o analista no momento da decisão.

• Uma etiqueta de identificação. Cada elemento de IA mostra uma etiqueta «AI · modelo · vversão». O analista vê, sem ter de procurar, que houve intervenção da IA, que modelo produziu o resultado e qual a versão desse modelo. Não há nenhum juízo oculto da máquina disfarçado de facto do sistema.
• As 3 principais razões SHAP. Cada pontuação vem acompanhada dos três factores que mais a influenciaram, obtidos por uma atribuição do tipo SHAP. Em vez de «0,87», o analista vê as três variáveis que fazem subir ou descer a pontuação — a exposição por país, o padrão de transacções, o sinal de filtragem — ordenadas pelo seu contributo. O raciocínio está à superfície, e não enterrado num modelo que o analista nunca vai abrir.
• Uma percentagem de confiança. O resultado indica o grau de confiança do modelo. Um alerta com confiança elevada e um alerta marginal lêem-se de forma diferente, e o analista pode ponderá-los em conformidade, em vez de tratar todas as pontuações como igualmente certas.
• Um controlo humano Accept / Modify / Reject (aceitar, modificar, rejeitar). O modelo propõe; a pessoa decide. Cada elemento de IA dá ao analista um controlo explícito para aceitar o resultado do modelo, modificá-lo ou rejeitá-lo por completo. O modelo nunca age por si só. É um contributo para uma decisão humana, nunca um substituto dela.

É isto que a intervenção humana significa na prática. Não se pede ao analista que carimbe um número que não consegue interrogar. Recebe uma sugestão identificada, explicada e quantificada, e um meio claro de a rejeitar. O mesmo raciocínio das 3 principais razões SHAP que aqui aparece transita também para a investigação do caso, pelo que, quando um alerta chega a um caso, o analista já vê por que razão o modelo contribuiu e pode investigar a pontuação da IA a par da lógica baseada em regras que disparou, em vez de tratar ambas como sistemas separados e sem responsabilização.

A explicabilidade traz um segundo benefício que as equipas de conformidade sentem de imediato: permite que a IA reduza os falsos positivos sem se tornar uma nova fonte de ruído inexplicado. Quando um modelo baixa a prioridade de uma correspondência, mostra as razões, pelo que o analista pode confiar nessa redução de prioridade em vez de a temer. É a diferença entre um modelo que suprime alertas em silêncio e um modelo que ajuda o analista a encerrá-los de forma defensável — um tema tratado em profundidade em como a IA reduz os falsos positivos de uma forma que pode defender perante um inspector.

Governar o modelo, e não apenas o resultado

Explicar uma pontuação isolada é necessário, mas não suficiente. O próprio modelo é um objecto controlado, com um ciclo de vida, e a governação BC/FT exige, em torno desse ciclo de vida, controlos tão rigorosos como os que envolvem qualquer outra alteração relevante a um sistema de conformidade. O serviço de inferência de IA trata um modelo da mesma forma que o resto da plataforma trata qualquer acção sensível.

Um registo de modelos e activação segundo o princípio dos quatro olhos

Os modelos não aparecem em produção por acaso. O serviço mantém um registo de modelos próprio — um registo controlado de cada modelo e versão disponível para o inquilino (tenant). Colocar um modelo em produção é um acto de grandes consequências, pelo que está protegido pela activação segundo o princípio dos quatro olhos: uma pessoa propõe a activação e uma segunda pessoa, independente, aprova-a. Nenhum indivíduo, sozinho, pode introduzir um novo modelo, ou uma nova versão de um modelo existente, em decisões que afectam clientes. Isto espelha o princípio dos quatro olhos que protege todas as outras acções relevantes na plataforma, das derrogações da classificação de risco à submissão de comunicações, e dá à função de validação um ponto de controlo natural: um modelo não pode entrar em produção enquanto um segundo par de olhos autorizado não o tiver aprovado.

Um interruptor de emergência

Quando um modelo se comporta mal — deriva, um padrão de resultados inesperado, uma conclusão da validação —, esperar não é opção. O serviço disponibiliza um interruptor de emergência (kill switch): um meio imediato de retirar um modelo de serviço. A activação é deliberada e lenta por concepção; a desactivação é rápida por concepção. A assimetria é precisamente o objectivo. Ligar um modelo deve exigir cuidado e uma segunda assinatura; desligá-lo quando algo parece errado não deve exigir nem demora nem debate.

Monitorização da equidade e da deriva

Um modelo que era exacto no momento da activação não se mantém exacto por si só. O comportamento dos clientes altera-se, as tipologias evoluem e os dados que alimentam o modelo mudam por baixo dele. O serviço executa continuamente a monitorização da equidade e da deriva (drift), vigiando a degradação do desempenho do modelo ou o enviesamento dos seus resultados contra um grupo de clientes, de formas que a instituição nunca pretendeu. É a monitorização que converte o interruptor de emergência de botão de pânico em controlo governado — diz-lhe quando o utilizar, antes que um inspector ou uma comunicação que ficou por fazer o façam por si.

Reversão

A activação pode ser revertida. A combinação de um registo com controlo de versões e da reversão (rollback) significa que, se uma nova versão do modelo tiver um desempenho inferior, a instituição pode regressar de forma limpa à versão anteriormente validada, sem ter de a reconstruir manualmente. As alterações de modelo tornam-se decisões reversíveis, e não portas de sentido único, que é exactamente a propriedade que uma função de validação pretende quando aprova a entrada em produção de uma nova versão.

Registar a decisão para que resista à auditoria

A última camada de governação é o registo. Uma decisão de IA que não possa ser reconstituída mais tarde não é, para efeitos de auditoria, decisão nenhuma. O serviço de inferência de IA regista cada decisão de IA relevante com três elementos que a tornam reconstituível: a versão do modelo que a produziu, um hash dos dados de entrada que capta exactamente o que o modelo viu e o resultado SHAP que explica por que razão pontuou como pontuou.

Este trio é importante porque responde às três perguntas que um inspector ou um revisor interno fará sobre qualquer decisão passada. Que modelo decidiu isto? A versão. Com base em quê? O hash dos dados de entrada, que fixa os dados exactos fornecidos ao modelo, para que não possam ser discretamente contestados mais tarde. Porque decidiu assim? O resultado SHAP, preservado a par da pontuação. Em conjunto, permitem à instituição assumir uma decisão tomada meses ou anos antes, não por se lembrar dela, mas por a reproduzir a partir do registo.

Como estas decisões ficam no mesmo registo de auditoria imutável e só de acréscimo (append-only) em que escreve o resto da plataforma, ficam ao lado das acções humanas que as rodeiam — quem aceitou ou rejeitou o resultado do modelo, quem activou o modelo, quem aprovou essa activação. O contributo do modelo não é uma camada separada e sem responsabilização; faz parte de um registo probatório único e contínuo. Para ver como esse registo é construído e protegido em toda a plataforma, consulte como as decisões de IA são registadas no trilho de auditoria sob o controlo dos quatro olhosEN.

Como a interface e o registo se alinham

As duas metades da IA explicável — o que o analista vê e o que o sistema regista — são deliberadamente a mesma informação, captada no mesmo momento.

Nada daquilo em que o analista se apoia no momento da decisão se perde depois, e nada do que consta do registo foi ocultado ao analista nesse momento. É este alinhamento que torna a IA defensável: a explicação mostrada e a explicação guardada são uma e a mesma.

Como é uma boa prática

Uma capacidade de IA bem governada num programa BC/FT é reconhecível. Cada resultado de IA que um analista vê está identificado, explicado com as 3 principais razões SHAP, quantificado com uma percentagem de confiança e acompanhado de um controlo para o aceitar, modificar ou rejeitar. Nenhum modelo chega à produção sem que duas pessoas autorizadas concordem em activá-lo. Um modelo que se comporta mal pode ser parado em instantes. A equidade e a deriva são vigiadas continuamente, e não auditadas uma vez por ano. As versões podem ser revertidas, e cada decisão relevante é registada com a versão do modelo, o hash dos dados de entrada e o raciocínio, para que possa ser reconstituída muito depois dos factos.

O resultado é uma IA que conquista o seu lugar no programa, em vez de o minar. O modelo torna a detecção mais precisa e reduz o esforço desperdiçado, enquanto a governação mantém cada decisão dentro dos limites que a sua política de risco de modelo e a sua autoridade de supervisão esperam. É o único tipo de IA que vale a pena utilizar numa função BC/FT regulada — útil porque é explicável, e utilizável porque é governada.

Perguntas frequentes

Utilizar IA em BC/FT significa que é o modelo que toma a decisão?

Não. Na plataforma da Creodata, o modelo nunca decide sozinho. Cada elemento de IA apresenta uma sugestão identificada, explicada com SHAP e acompanhada de uma pontuação de confiança, e é o analista quem decide, através de um controlo explícito Accept, Modify ou Reject. O modelo é um contributo para uma decisão humana, e a acção humana fica registada a par do resultado do modelo.

O que é o SHAP e porque é importante para a conformidade?

O SHAP é um método de atribuição que quantifica em que medida cada variável de entrada contribuiu para a pontuação de um modelo. Para a conformidade, é importante porque substitui um número opaco pelas 3 principais razões que o explicam, de modo que um analista pode interrogar a pontuação, um MLRO pode explicar uma decisão a um regulador e uma função de validação pode testar se o modelo está a raciocinar como deve.

Como se coloca em produção, com segurança, um novo modelo BC/FT?

Através do registo de modelos e da activação segundo o princípio dos quatro olhos. Um modelo e a sua versão residem num registo controlado, e colocá-lo em produção exige que uma pessoa proponha a activação e que uma segunda pessoa, independente, a aprove. Se, mais tarde, o modelo se comportar mal, um interruptor de emergência retira-o imediatamente de serviço, e a reversão devolve o inquilino à versão anteriormente validada.

Como se prova, a posteriori, uma decisão assistida por IA?

Reproduzindo-a a partir do registo. Cada decisão de IA relevante fica registada com a versão do modelo, um hash dos dados de entrada que fixa exactamente o que o modelo pontuou e o resultado SHAP que explica a pontuação, tudo no registo de auditoria só de acréscimo da plataforma. Isso permite à instituição reconstituir com precisão o que foi decidido, com base em que dados e porquê — meses ou anos depois.

Uma IA explicável e governada é a diferença entre um modelo que ajuda os seus analistas e um modelo que expõe o seu programa. Para ver como as explicações SHAP, a activação segundo o princípio dos quatro olhos, o interruptor de emergência, a monitorização da deriva e o registo das decisões funcionam em conjunto num programa BC/FT real — e como os mesmos controlos se estendem às comunicações goAML e à nossa consultoria de conformidade em crime financeiro —, marque uma demonstração da Plataforma BC/FT da Creodata.