Análise de risco com inteligência artificial

Análise de Risco com IA: Como Eu Realmente Faço no Dia a Dia

Vamos ser francos, antes de tudo: "análise de risco" é uma daquelas expressões que soam grandiosas em apresentações de PowerPoint, mas na realidade, o cenário é bem diferente. Durante anos, para mim, equivalia a horas, dias, ou até semanas, debruçado sobre montanhas de papéis, planilhas monumentais ou plataformas antiquadas com dados insípidos. Já virei noites comparando cadastros de empresas em listas de sanções com informações de fornecedores, buscando indícios de transações atípicas em extratos bancários que se assemelhavam a enigmas, ou dissecando inúmeras cláusulas contratuais em busca de lacunas ou condições desfavoráveis. Uma tarefa exaustiva, passível de falhas e, para ser sincero, agonizantemente demorada. Recordo-me de uma ocasião em que tínhamos que avaliar o risco de crédito de cerca de 300 novas propostas de clientes em tempo recorde. A equipe, com os olhos pesados de tanto analisar dados, estava à beira da exaustão, e ainda assim, tínhamos consciência de que inúmeros pormenores poderiam ser negligenciados. Foi nesse ponto que me ocorreu: "Deve haver um método superior para essa tarefa." Esse "método superior" gradualmente incorporou a inteligência artificial. Não como um passe de mágica, mas como um recurso robusto para aliviar o esforço físico e mental.

Do Papel e Planilha ao Modelo Preditivo: O Primeiro Passo com IA

O contato inicial com a IA para análise de risco não teve nada de espetacular; tratou-se, na verdade, de uma investida quase desesperada para automatizar uma atividade que me roubava tempo precioso: a detecção de fraudes em microtransações online. O processo, em essência, consistia em: um novo registro chegava, e precisávamos verificar múltiplos elementos para atestar a legitimidade do perfil do cliente. Feito à mão, era um suplício. Implica abrir inúmeras abas, pesquisar em diversos portais e cotejar informações. Minha indagação inicial foi: o que aconteceria se a IA pudesse oferecer uma “percepção” de risco para cada novo registro, antes mesmo de eu iniciar uma investigação aprofundada?

Coletando os Dados Certos (e os Errados Também)

Na análise de risco impulsionada por IA, os dados são o fundamento. E, sejamos realistas, informações raras vezes chegam perfeitamente estruturadas. Em minha experiência, os registros de clientes afluíam por diversos canais: um formulário online que alimentava diretamente uma Google Sheet, uma planilha recebida por e-mail, ou até mesmo dados digitados manualmente. A princípio, a árdua missão era consolidar tudo. Desenvolvi um script em Python que operava periodicamente em um pequeno servidor dedicado. Esse script conectava-se a uma Planilha Google específica por meio da API (empregando a biblioteca `gspread`), extraía os novos registros e interagia com outras APIs externas, como as de consulta de CPF/CNPJ (serviços pagos que fornecem dados essenciais) e de validação de e-mails. A padronização representava o obstáculo inicial. Números de telefone apresentavam formatos variados, nomes continham erros de digitação e datas divergiam em suas representações. O Python, com bibliotecas como `pandas`, provou-se crucial para a limpeza, normalização e remoção de duplicatas. Uma verdadeira odisseia de blocos `try-except` e expressões regulares era necessária para assegurar, por exemplo, que telefones sempre seguissem o padrão `(XX) XXXXX-XXXX` e que CEPs contivessem invariavelmente 8 dígitos.

Além disso, empregava o Apps Script, que considero o "cimento" que une os serviços Google. Ao submeter um novo formulário na planilha, uma função `onFormSubmit` do Apps Script era ativada. O script capturava os dados recém-adicionados, realizava uma verificação preliminar (como a presença de campos obrigatórios) e, crucialmente, enviava uma requisição para a minha API Python em execução. Sim, eu configurava um endpoint em meu servidor para que o Apps Script pudesse interagir. Ocasionalmente surgiam erros de CORS ou falhas na autenticação, mas eram problemas que íamos corrigindo. O objetivo era delegar à máquina a tarefa exaustiva de coleta e estruturação, eliminando a necessidade de abrir inúmeras páginas ou realizar cópias manuais.

Montando a Lógica de Risco: Onde a IA Começa a Ajudar

Com os dados minimamente higienizados, a etapa decisiva tinha início. De início, a metodologia de risco apoiava-se em um conjunto de regras predefinidas: "se o CPF for inválido, risco alto", "se o e-mail for temporário, risco médio", "se o endereço não bater com o CEP, risco X". Contudo, essa abordagem revela-se restritiva. O que acontece se um fraudador astuto conseguir contornar tais regras? É nesse ponto que a IA, mais precisamente os Large Language Models (LLMs), passa a ser relevante.

Minha abordagem inicial foi descomplicada. Para cada novo registro, eu construía um prompt bem elaborado em Python, consolidando todas as informações disponíveis: nome, CPF, e-mail, endereço, telefone, histórico de compras (se aplicável), e os resultados das consultas externas (como a validade do e-mail ou o status do CPF). A estrutura do prompt era similar a esta:

"Analise o seguinte perfil de cliente para risco de fraude. Considere dados de identificação, contato e histórico. Forneça uma pontuação de risco de 1 (baixo) a 10 (alto) e os três principais motivos para essa pontuação. Dados: [JSON com os dados do cliente]"

Este prompt era então remetido a uma API de um LLM (iniciei com as opções mais acessíveis, como alguns modelos Gemini ou OpenAI, conforme o orçamento do projeto). O LLM me retornava uma resposta em JSON, cuja formatação eu já especificava desta maneira: {"score": 7, "motivos": ["endereço não consistente", "email de domínio incomum", "tentativa de compra com vários cartões"]}.

O aspecto mais fascinante era a capacidade do LLM de discernir sutilezas. Por exemplo, ele identificava discrepâncias sutis em um nome entre diferentes campos, ou um padrão de compra em um e-commerce que fugia ao comum para a região do CEP. Detalhes que uma regra trivial ignoraria, ou que eu, como ser humano, só detectaria após um dispendioso período de análise. Minha solicitação não era para que ele determinasse a fraude, mas para que fornecesse um "alerta perspicaz", um sumário dos motivos pelos quais identificava um risco.

Automatizando a Análise: Apps Script e Python Juntos

A verdadeira eficácia residia na integração. O Apps Script, em minhas Google Sheets, após capturar os dados do novo registro, não se limitava a invocar minha API Python para higienização de dados e consultas externas; ele também remetia o JSON final a outro endpoint Python, responsável por interagir com o LLM. A resposta do LLM era então processada pelo script Python e reencaminhada ao Apps Script. O Apps Script, por conseguinte, atualizava a planilha, inserindo colunas como "Pontuação de Risco IA" e "Motivos de Risco (IA)".

Dessa forma, assim que um novo registro ingressava na planilha, em questão de segundos, eu já dispunha de uma "análise preliminar" de risco gerada pela IA. Evidentemente, eu ainda examinava os casos de alto risco; contudo, a IA peneirava a vasta maioria dos registros de baixo risco, liberando meu tempo para me dedicar ao que era verdadeiramente essencial. Sentir esse alívio foi indescritível. Transitei de "analista manual de dados" para um papel de "curador de informações e validador de IA".

Entendendo o Risco: Mais do que um Número

Uma lição que assimilei rapidamente é que uma mera pontuação de risco (como "7 de 10") é insuficiente. Eu necessitava compreender a "razão". Os LLMs, nesse quesito, são excepcionais. Para além do score, eu solicitava que ele fornecesse os motivos, tal qual o formato JSON ilustrado. Essa informação era crucial. Isso me auxiliava no aprendizado e na formulação de diretrizes mais sólidas para situações de baixo risco. Caso o LLM indicasse repetidamente que e-mails de um domínio específico representavam perigo, eu podia implementar uma regra manual para bloqueio ou sinalização automática. O LLM transcendia a função de um mero classificador; ele se tornava um "orientador", auxiliando-me a aprimorar minhas diretrizes e minha percepção de risco.

Imagine, por exemplo, em uma análise de risco contratual: eu inseria o texto de um contrato de fornecedor no LLM. O prompt instruía-o a apontar cláusulas controversas, termos vagos, atribuições de responsabilidade mal formuladas ou penalidades excessivas. A resposta fornecia uma relação dos segmentos do contrato acompanhada da respectiva explanação do risco. Essa abordagem evitava que eu tivesse de decifrar dezenas de páginas de jargão jurídico a cada vez. Embora não substitua a expertise de um advogado, proporciona uma triagem inteligente inicial, evidenciando os pontos que demandariam a atenção do profissional.

Aspecto	Jeito Manual/Demorado (Antes da IA)	Jeito Automatizado (Com IA e Ferramentas)
Coleta e Normalização de Dados	Cópia manual de dados de formulários, plataformas legadas e planilhas variadas. Normalização artesanal de nomes, endereços, telefones. Elevada suscetibilidade a erros humanos e inconsistências.	Scripts em Python via API para Planilhas, requisições a APIs externas (CPF/CNPJ). Apps Script para orquestrar a automação. Normalização e higienização automatizadas com `pandas` e regex.
Avaliação Preliminar de Risco	Exame minucioso de documentos, cotejo visual, procura manual por "sinais de alerta" em conteúdo textual ou numérico. Lógica fundamentada em regras elementares, facilmente contornáveis.	Remessa de dados estruturados para LLM via API. Geração de score de risco e "justificativas" em segundos. Identificação de padrões intrincados e sutilezas que regras básicas não capturariam.
Análise de Contratos/Documentos Textuais	Exame minucioso de termos e condições, e de contratos extensos, com o fim de identificar riscos jurídicos ou financeiros. Processo moroso e dependente da acuidade do analista.	Python extrai o conteúdo textual do contrato, submetendo-o ao LLM com um prompt direcionado. O LLM identifica cláusulas de risco elevado, ambiguidades ou termos desvantajosos, evidenciando os segmentos relevantes.
Agilidade na Resposta	Dias ou até semanas para processar volumes de propostas ou transações de porte médio a grande.	Minutos ou meros segundos para processar centenas de itens, variável conforme a complexidade do prompt e o volume de dados.
Custo-Benefício e Escalabilidade	Elevado custo de recursos humanos para atividades repetitivas. Obstáculo à expansão sem a adição de mais pessoal.	O custo de APIs (LLM) e da infraestrutura (servidor Python) é variável. Muito maior capacidade de escala, possibilitando o processamento de volumes massivos com a mesma equipe.
Concentração da Equipe	Analistas dedicados a tarefas rotineiras e de baixo impacto estratégico.	Analistas direcionados à validação de cenários complexos, à interpretação dos diagnósticos da IA e ao aprimoramento contínuo dos fluxos.

O Que Dá Errado (E Sempre Dá)

Muito se discute sobre os benefícios da IA, mas poucos abordam os desafios. E, acredite, os obstáculos são concretos.

1. Viés nos Dados e Falsos Positivos/Negativos

A inteligência artificial assimila informações a partir dos dados que lhe são fornecidos. Se seus registros históricos de "fraude" ou "baixo risco" já carregam um viés (por exemplo, a detecção de fraudes se concentrou em um tipo específico de indivíduo ou segmento), a IA irá reproduzir e até intensificar essa parcialidade. Certa vez, observei o modelo LLM categorizar perfis de clientes de uma região específica como de alto risco, não por serem intrinsecamente mais propensos a risco, mas porque, em meus dados históricos, a maior parte das fraudes se originava daquele local (talvez por uma lacuna na investigação de outras áreas). Isso resultou em um excesso de falsos positivos, com situações legítimas sendo indevidamente bloqueadas. A saída? Inserir no modelo uma quantidade maior de dados "neutros" ou retificar o viés nos dados de treinamento, uma empreitada monumental. E, ademais, aprimorar os prompts para que o LLM articule claramente a justificativa, e não apenas o "o que".

Os falsos negativos representam outro desafio – a IA falha em detectar um risco genuíno. Este cenário é ainda mais crítico. Ocasionalmente, o LLM pode negligenciar uma sutileza que um observador humano perceberia, ou o prompt pode não ter sido suficientemente preciso para guiar sua análise. Portanto, a vigilância humana permanece indispensável, em particular para os casos que a IA rotula como "baixo risco", mas que apresentam alguma particularidade que gera apreensão.

2. Custo da API de LLM

A invocação de uma API de LLM não é gratuita. Quando se necessita analisar centenas ou milhares de itens diariamente, o custo se acumula. Já me surpreendi com o valor da fatura. A solução foi otimizar os prompts, buscando a máxima concisão para economizar tokens. Por vezes, dividir um problema complexo em requisições menores e de menor custo. Alternativamente, para análises textuais mais diretas, considerar o uso de modelos mais compactos e econômicos, ou até mesmo modelos hospedados localmente, se a confidencialidade dos dados for uma prioridade máxima e a infraestrutura permitir.

3. Privacidade e Segurança dos Dados

Enviar informações sensíveis de clientes ou documentos contratuais para uma API externa (como as da OpenAI ou Google) sempre me gera certa apreensão. Qual o destino desses dados? De que forma são empregados? Com o intuito de mitigar riscos, procuro anonimizar ao máximo os dados antes do envio. Removo CPFs, nomes completos que não sejam imprescindíveis para a análise e endereços detalhados. Encaminho apenas a essência das informações requeridas. No caso de dados de altíssima criticidade, avalio o uso de soluções de IA on-premise ou modelos mais leves que possam ser executados em servidores sob meu controle, o que, no entanto, introduz outra camada de complexidade em termos de custo e manutenção.

4. Complexidade da Integração e Manutenção

Conectar Google Sheets, Apps Script, Python, APIs externas e APIs de LLM está longe de ser uma tarefa trivial. Ocorrem falhas de autenticação, restrições de requisições por minuto, e tempos limite nas APIs. Em um dia, a API de consulta de CPF altera seu formato de resposta, desativando meu script Python. No dia seguinte, o Apps Script cessa de operar porque o Google implementou uma nova política de segurança. E o que é ainda mais frustrante: o modelo de IA em uso recebe uma atualização, e subitamente suas respostas ou desempenho se modificam. Trata-se de uma manutenção incessante, uma batalha para assegurar que tudo permaneça operacional e otimizado. Definitivamente não é um processo de "configurar e esquecer".

5. Entendimento Incorreto dos Prompts

Dediquei inúmeras horas ao refinamento de prompts. Ocasionalmente, a IA fornecia uma resposta completamente alheia à minha intenção, seja pela ambiguidade do meu prompt ou pela insuficiência de contexto fornecido. É um processo contínuo de aprendizado sobre como "dialogar" com a IA, como ser preciso, direto e como direcionar o modelo para o tipo de análise desejada. Exige muita experimentação e ajustes iterativos.

FAQ – Perguntas Técnicas Rápidas

1. Qual o melhor modelo de IA para começar a analisar risco de texto?

Recomendo iniciar com modelos de LLM de uso geral, como os da família GPT-3.5/4 da OpenAI ou os Gemini do Google. Esses modelos são adaptáveis e proporcionam um balanço adequado entre custo e performance. No estágio inicial, a flexibilidade dos prompts é mais relevante do que a especialização profunda. À medida que suas exigências evoluem, é possível investigar modelos mais refinados ou especializados.

2. Como garantir a segurança dos dados ao usar APIs de IA externas?

A principal estratégia defensiva é a anonimização: elimine ou generalize os dados sensíveis antes de transmiti-los. Consulte sistematicamente as políticas de privacidade e utilização de dados do fornecedor da API. Para informações de alta criticidade, avalie o emprego de APIs que permitam o processamento de dados sem retenção ou explore soluções on-premise, nas quais você mantém o controle irrestrito sobre o ambiente.

3. É possível integrar modelos de IA personalizados com Google Sheets sem programar muito?

Para integrações mais elementares, é viável utilizar o Apps Script para invocar APIs de IA pré-existentes (aquelas que citei anteriormente). Isso, por si só, demanda um certo nível de codificação. Contudo, se a intenção for empregar modelos genuinamente customizados (treinados com seus próprios conjuntos de dados), será provável a necessidade de um backend em Python (ou outra linguagem) para hospedar seu modelo e disponibilizar uma API, que seria então acessada pelo Apps Script. Ferramentas "no-code" ou "low-code" ainda apresentam restrições para tal grau de personalização e acoplamento com modelos complexos.

Conclusão Simples e Humana

Em última análise, a análise de risco com inteligência artificial não visa substituir o fator humano. Trata-se, antes, de potencializar as capacidades humanas. Eu, que outrora me sentia subjugado por planilhas e relatórios, hoje consigo direcionar minha energia para decisões estratégicas, para a compreensão das exceções apontadas pela máquina e para o aprimoramento contínuo do processo. Continuo a cometer erros e a me frustrar com APIs que falham e prompts que não respondem como esperado logo de início. A perfeição não existe e jamais será alcançada neste domínio. Contudo, o volume de trabalho que consigo processar e a acuidade da análise que agora alcanço superam imensamente o que eu era capaz de fazer anteriormente. É um instrumento, uma ampliação de nossa capacidade, e, como qualquer ferramenta, demanda compreensão, manutenção e a sabedoria de discernir quando confiar e quando questionar. E essa discernimento, meu caro, só se adquire na prática, através da experiência direta.