Credit scoring e decisões automatizadas

Durante anos, a análise regulatória de um modelo de scoring se esgotava na proteção de dados. Hoje há três regimes que se sobrepõem sobre a mesma decisão (conceder ou negar crédito a uma pessoa), e cada um olha para uma coisa diferente:

• A Diretiva (UE) 2023/2225, a CCD2, olha para o resultado perante o consumidor: quais direitos ele tem quando a decisão o afeta, quais dados não podem ser usados e o que deve ser avaliado.
• O Regulamento (UE) 2024/1689, o Regulamento de IA (AI Act), olha para o sistema: como foi construído, com quais dados foi treinado, como é documentado e quem o supervisiona.
• O RGPD olha para o tratamento: a base jurídica, a informação ao titular dos dados e os limites às decisões baseadas exclusivamente em tratamento automatizado.

A consequência prática é que um projeto que tenha trabalhado só uma das três frentes tem, quase com certeza, lacunas nas outras duas. E a lacuna mais comum é a mesma em todos os casos: o modelo funciona, mas não pode ser explicado. Ele pode prever bem e, ao mesmo tempo, ser incapaz de dizer a um cliente por que o crédito foi negado, em termos que ele entenda, ou de demonstrar a um supervisor como foi construído.

Também convém fixar uma ideia que organiza todo o resto. Nenhuma das três normas proíbe automatizar. O que elas fazem é exigir que a automação seja reversível, explicável e supervisionada. Um modelo que decide sozinho, sem possibilidade de revisão humana e sem capacidade de explicar seu resultado, não é um modelo eficiente: é um modelo que não cumpre as normas.

Os três direitos se leem rápido e se implantam devagar, porque cada um toca uma camada diferente do sistema. O de intervenção humana é organizacional: exige pessoas, treinamento e uma definição clara de até onde vai sua capacidade de anular o modelo. O de explicação é técnico: obriga o modelo a produzir razões, e não apenas um número, o que na prática condiciona quais arquiteturas são viáveis. E o de revisão é procedimental: é preciso registrar o que o cliente alega, deixar constância de que isso foi avaliado e fundamentar a nova decisão.

O segundo é o que mais obriga a repensar projetos. Um modelo muito preciso, mas opaco (um ensemble profundo, por exemplo), pode se tornar inutilizável não por seu desempenho, mas porque seu resultado não pode ser traduzido em uma explicação significativa. Essa é uma decisão de arquitetura que convém tomar no desenho, e não quando chega a primeira reclamação.

E há uma conexão que convém não perder de vista: a diretiva de serviços financeiros a distância estabelece, em paralelo, o direito de obter intervenção humana na fase pré-contratual quando são usadas ferramentas automatizadas. São duas normas diferentes apontando para o mesmo lugar (antes de contratar e ao decidir a concessão), de modo que o circuito de escalonamento deve cobrir os dois momentos.

A CCD2 delimita quais informações podem sustentar a avaliação de solvência e exclui expressamente duas fontes que até agora apareciam em modelos alternativos de scoring:

• As categorias especiais de dados do RGPD, com menção expressa aos dados de saúde.
• Os dados provenientes de redes sociais.

A primeira proibição é coerente com o regime geral de proteção de dados e surpreende pouco. A segunda é a que muda projetos: durante anos, o uso de sinais de comportamento digital e de pegada social foi apresentado como o caminho para dar crédito a perfis sem histórico. Esse caminho fica fechado para a avaliação de solvência no crédito ao consumidor.

Mas a consequência que realmente exige trabalho técnico é outra, e não está escrita: as variáveis aproximadas (proxy). Um modelo pode não usar dados de saúde e, mesmo assim, incorporar variáveis que os preveem com alta correlação (padrões de gasto em farmácia, tipo de estabelecimento, frequência de determinadas categorias). Formalmente, o dado proibido não é usado; materialmente, ele entra na decisão. Depurar um modelo dessas aproximações não é uma revisão documental: é um exercício estatístico que precisa ser feito sobre as variáveis reais e ficar documentado.

Essa análise, além disso, serve duas vezes. É o que a CCD2 exige em matéria de dados e é também, em boa medida, o que o Regulamento de IA pede sob o título de governança de dados para os sistemas de alto risco. Convém fazê-la uma vez e aproveitá-la para os dois processos.

A classificação não admite discussão: a avaliação da solvência creditícia de pessoas físicas está expressamente no Anexo III, dentro da categoria de acesso a serviços essenciais. Um credor que use um sistema de inteligência artificial para decidir concessões está operando um sistema de alto risco, com tudo o que isso implica.

Vale a pena se deter em duas das obrigações, porque são as mais mal interpretadas. A supervisão humana não se cumpre com um botão de anulação que ninguém usa: a norma exige um desenho que permita uma supervisão efetiva, o que implica que a pessoa que supervisiona entenda o resultado, tenha tempo hábil para avaliá-lo e capacidade real de se afastar dele. E a manutenção de registros não é o log da aplicação: são os rastros que permitem reconstruir por que o sistema decidiu o que decidiu, em uma operação concreta, meses depois.

A boa notícia é que há sobreposição com o que a CCD2 já exige. O circuito de intervenção humana pedido pela diretiva de crédito é, em boa parte, a supervisão humana pedida pelo Regulamento de IA; e a rastreabilidade que permite explicar uma recusa é a mesma que permite manter registros. Desenhá-los separadamente duplica o trabalho. Se você já está trabalhando o Regulamento de IA por outra via, convém cruzá-lo com a análise do Regulamento de IA.

O artigo 22 do RGPD reconhece ao titular dos dados o direito de não ficar sujeito a uma decisão baseada exclusivamente no tratamento automatizado que produza efeitos jurídicos sobre ele ou que o afete significativamente de forma similar. Negar um crédito se enquadra plenamente nessa hipótese, e por isso a maioria das instituições já tem uma posição tomada sobre essa questão.

O que muda agora é que essa posição precisa ser reexaminada à luz das outras duas normas, porque o padrão subiu. Muitos modelos se apoiavam na ideia de que a decisão não era «exclusivamente» automatizada porque existia uma revisão humana nominal. A CCD2 e o Regulamento de IA endurecem essa leitura por dois ângulos: a primeira reconhece um direito expresso à intervenção humana, à explicação e à revisão; o segundo exige que a supervisão humana seja efetiva desde o desenho. Uma revisão meramente formal deixa de sustentar o argumento.

O resultado é que as três normas convergem para o mesmo entregável prático, e convém construí-lo uma única vez: um dossiê de decisão por operação que registre quais dados entraram, qual resultado o sistema produziu, quem o revisou, o que o cliente alegou (se alegou algo) e como a decisão final foi fundamentada. Esse dossiê é ao mesmo tempo a prova do cumprimento do RGPD, a evidência da intervenção humana da CCD2 e o registro que o Regulamento de IA pede.

Dois trechos dessa tabela merecem atenção, porque são os que mais trabalho geram. O primeiro é «a devida consideração das obrigações atuais»: não basta conhecer a renda, é preciso incorporar a carga financeira que o cliente já suporta. Isso obriga a definir de onde vem esse dado (consulta a bureaus de crédito, informações fornecidas pelo cliente, agregação de contas) e a documentar a escolha.

O segundo é «de modo adequado ao volume de operações». É uma cláusula de proporcionalidade, e convém lê-la nas duas direções. Para um credor pequeno, significa que não lhe será exigida a estrutura de uma grande instituição. Para um grande, significa exatamente o contrário: o padrão esperado cresce com o volume, de modo que um procedimento artesanal deixa de ser defensável a partir de certo tamanho. A proporcionalidade nem sempre é um alívio.

Imagine a cena, porque é ela que precisa ser resolvida: um cliente que teve o crédito negado liga e pergunta por quê. A resposta «você não passou no nosso sistema de avaliação» já não serve. A diretiva reconhece o direito a uma explicação significativa e compreensível, e esses dois adjetivos têm conteúdo.

Significativa quer dizer que a explicação precisa se referir aos fatores que efetivamente pesaram naquela decisão concreta, e não a uma descrição genérica do modelo. Compreensível quer dizer que ela precisa estar na linguagem do cliente, e não na da equipe de riscos: falar em «percentil da variável de tempo de emprego» não explica nada.

Isso exige três coisas que precisam ser construídas antes de receber o primeiro pedido:

• Capacidade técnica de atribuição. O sistema precisa conseguir dizer quais fatores moveram a decisão naquela operação, e não em média. Isso condiciona a arquitetura do modelo.
• Um catálogo de razões em linguagem clara. Traduções pré-redigidas e revisadas de cada fator para uma frase que um consumidor entenda, para que a explicação não dependa de quem atende a ligação.
• Um circuito de alegação e revisão. Por onde entra o que o cliente apresenta, quem o avalia e como a nova decisão é fundamentada.

Também convém cuidar de um limite: explicar não é revelar o modelo. Há um equilíbrio entre o direito do consumidor de entender a decisão e o interesse legítimo da instituição em não expor seu sistema de avaliação à engenharia reversa nem à fraude. Esse equilíbrio se resolve no desenho do catálogo de razões (concretas o suficiente para serem úteis, agregadas o suficiente para não virarem um manual de como enganar o modelo), e convém deixá-lo fundamentado por escrito.