Existe uma frase que todo engenheiro de software deveria ter em mente ao construir sistemas de risco: "Acreditei em tudo o que disseram". Ela foi dita por uma locadora que alugou um apartamento a dois homens depois condenados por envolvimento nos atentados de 11 de Setembro, e que decidiu falar publicamente pela primeira vez em uma entrevista à BBC. A história é um retrato incômodo da confiança humana — e um ponto de partida excelente para discutir as limitações das nossas checagens automatizadas.
Quando uma pessoa diz que acreditou em tudo o que ouviu, costumamos interpretar como ingenuidade pessoal. Mas, para quem projeta produtos digitais, a frase revela algo mais profundo: a confiança que um sistema entrega é diretamente proporcional ao que ele decide verificar, e inversamente proporcional ao que ele ignora. Não existe formulário capaz de mapear intenções. O máximo que uma plataforma consegue é reduzir a incerteza com base em sinais indiretos, e mesmo isso exige decisões de engenharia que quase nunca aparecem nas telas de cadastro.
O caso dos ataques de 2001 é extremo, mas a mecânica é a mesma de qualquer relação contratual: uma pessoa avalia uma contraparte a partir de documentos, conversas e impressões, e uma empresa automatiza parte desse processo com algoritmos. O erro da locadora não foi humano versus máquina; foi a ausência de um sistema que transformasse dúvidas em verificações concretas. E é exatamente esse o desafio que engenheiros de software enfrentam quando projetam mecanismos de confiança para locação, fintechs, marketplaces ou plataformas de trabalho.
A falsa sensação de segurança das checagens
Quem trabalha com produtos digitalizados conhece o ritual: CPF, consulta a birôs de crédito, análise de antecedentes, comprovante de renda. Para o usuário final, parece uma muralha. Para o engenheiro, é apenas uma camada fina. Esses sistemas verificam o que está registrado, não o que está oculto. Uma pessoa pode passar em todas as etapas e ainda representar um risco que nenhuma base de dados captura no momento da consulta, seja por falha de integração, seja porque o evento adverso simplesmente ainda não aconteceu.
No caso da locadora, não importa quantas camadas tecnológicas existissem na porta de entrada: se a informação disponível naquele contexto não continha sinais de alerta, o algoritmo também não encontraria nada. É por isso que a indústria de verificação de identidade avançou tanto nos últimos anos, com biometria facial, prova de vida e análise de documentos via OCR, mas a indústria de avaliação de risco comportamental ainda engatinha. A diferença entre "quem é você" e "o que você vai fazer" é a zona mais difícil da engenharia de confiança.
Integrações com bases governamentais, consultas a cadastros de inadimplentes e APIs de checagem de antecedentes reduzem a probabilidade de fraude de identidade, mas não eliminam a lacuna entre a identidade oficial e a intenção real. Um sistema que cruza um CPF com listas de sanções e processos judiciais pode revelar passado, mas não prevê futuro. A verificação é uma fotografia do passado; risco é uma aposta no futuro. A distância entre essas duas coisas é onde moram os eventos que nenhum formulário antecipa.
Por que uma única fonte de dados nunca é suficiente
Bons sistemas de decisão usam múltiplas fontes e atribuem pesos diferentes a cada sinal. Um modelo de risco de inadimplência que usa apenas score de crédito passado não captura mudanças de comportamento recentes; um modelo de locação que ignora histórico de ações judiciais perde sinais objetivos. A arquitetura ideal combina dados estruturados, documentos, biometria, redes de relacionamento e, em alguns casos, sinais comportamentais em tempo real. Mas cada fonte adicional aumenta a superfície de privacidade e o custo de manutenção, e esse equilíbrio é uma decisão de engenharia, não de marketing.
Na prática, a maioria dos times começa com um baseline barato e rápido, regras simples e integrações essenciais, e só aciona verificações mais caras quando o risco estimado passa de um limiar. Essa estratégia funciona bem até aparecer um evento de cauda — algo tão raro que o modelo nunca teve dados suficientes para aprender. Foi o que aconteceu com o 11 de Setembro no mundo físico, e é o que acontece com fraudes complexas no mundo digital: o modelo de risco é calibrado para a média, não para a extremidade. A consequência é que o sistema produz uma pontuação de confiança alta para pessoas que jamais apareceriam em uma lista de suspeitos, simplesmente porque ninguém as procurou.
Essa é uma limitação estrutural, não um bug. Ela só aparece quando analisamos casos extremos, e por isso tende a ser ignorada em testes com dados históricos. Um modelo que nunca errou em um conjunto de validação pode ser o mesmo que aprova um estelionatário sofisticado que construiu uma identidade limpa ao longo de anos. Para lidar com isso, a engenharia de risco precisa incorporar incerteza no próprio desenho: devolver ao usuário final não apenas uma aprovação ou rejeição, mas um nível de confiança e as razões daquela decisão.
O algoritmo também tem ponto cego: viés e privacidade
Não é só a falta de dados que limita os sistemas; os dados que existem carregam distorções históricas. Modelos treinados para prever um "bom inquilino" com base em inadimplência passada podem aprender indiretamente a penalizar bairros, profissões ou perfis demográficos que historicamente foram mais negligenciados pelo sistema financeiro. Isso cria discriminação algorítmica silenciosa, que se manifesta em taxas de aprovação desiguais sem que nenhuma regra explícita mencione raça, gênero ou origem. Para o engenheiro responsável, o problema é sutil: a métrica de acurácia continua boa, mas a justiça do sistema é pífia.
A LGPD adiciona uma camada de complexidade: há princípios de minimização, finalidade e transparência que limitam o que uma plataforma pode coletar e armazenar. A tentação de usar dados não estruturados — como posts públicos em redes sociais ou comportamento de navegação — como sinal preditivo esbarra em uma questão regulatória e, mais importante, em uma questão de robustez. Dados de baixa qualidade geram decisões frágeis. Um modelo que usa conexões sociais para calcular risco pode condenar um inquilino simplesmente por ter um amigo inadimplente, sem que isso tenha qualquer relação causal com o comportamento daquela pessoa.
A saída não é abandonar algoritmos, mas projetá-los com camadas de governança: auditoria periódica de viés, métricas de equidade em subgrupos e um canal real de contestação humana. Engenheiros de software que trabalham com risco precisam entender que toda decisão automatizada é uma política pública disfarçada de matemática. Ignorar isso não é neutralidade técnica; é uma escolha de produto que pode prejudicar exatamente quem o sistema deveria proteger.
Monitoramento contínuo e análise de redes: o que vem depois do cadastro
Uma checagem estática na entrada do contrato é insuficiente para qualquer relação de longo prazo. Produtos maduros adotam monitoramento contínuo: reconsultar bases de dados periodicamente, observar sinais de atraso em outras contas, identificar mudanças de padrão de uso. A lógica é simples: a confiança deve ser reavaliada com o tempo, e não congelada no momento do aceite. Um inquilino que estava empregado na data da assinatura pode ficar desempregado três meses depois; um vendedor de marketplace que operava dentro da normalidade pode começar a acumular reclamações.
A análise de redes, por sua vez, pode revelar conexões entre pessoas e empresas que nenhum cadastro individual mostra. Saber que duas contas compartilham o mesmo dispositivo, endereço ou número de telefone ajuda a detectar fraude organizada e esquemas de locação fictícia. Mas esse tipo de dado levanta questões éticas sérias: até onde uma empresa pode investigar a vida de um usuário para decidir se ele pode alugar um imóvel? A resposta não é puramente técnica, é uma decisão de produto que precisa ser explícita no termo de uso e respeitar o princípio da proporcionalidade.
O ponto central é que nenhuma dessas abordagens deve ser tratada como uma verdade absoluta. Monitoramento contínuo gera alertas que precisam de interpretação humana; análise de redes gera correlações que podem ser coincidências estatísticas. Um bom sistema apresenta esses achados como pistas, não como sentenças. E a interface com o usuário final deve permitir que uma pessoa que foi negada entenda o que aconteceu e apresente sua versão dos fatos. Sem isso, a tecnologia vira um tribunal sem direito de defesa.
O que isso significa para quem constrói produtos digitais
Recomendo pensar em três camadas em qualquer sistema de confiança: verificação de identidade, validação de histórico e análise de contexto. A primeira responde a "quem é essa pessoa"; a segunda, a "o que ela já fez"; a terceira, a "em que situação ela está agora". A primeira é a mais madura, com biometria e documentos digitais consolidados. A segunda é a mais usada, mas depende da qualidade das bases consultadas. A terceira é a mais negligenciada, porque exige dados dinâmicos e uma modelagem que combina renda, comportamento e sinais externos.
Um bom produto combina as três camadas com pesos explícitos e expõe ao usuário final apenas o resultado da decisão e o direito de contestar. Para o engenheiro, isso significa construir pipelines de dados com qualidade, monitorar drift dos modelos, instrumentar métricas de viés e desenhar fallbacks manuais que acionam quando a incerteza é alta. É um trabalho menos glamouroso do que treinar um modelo de deep learning, mas é o que separa uma plataforma que decide com responsabilidade de uma que apenas automatiza preconceitos.
Também há uma lição de carreira aqui: quem domina a interseção entre engenharia, privacidade e análise de risco está cada vez mais raro no mercado. Empresas precisam de profissionais que saibam não só implementar uma API de checagem de antecedentes, mas também questionar se aquela integração faz sentido sob a ótica de produto, custo e responsabilidade legal. A técnica é necessária, mas não é suficiente. É preciso entender o domínio de negócio e as consequências humanas das decisões que você automatiza.
Entre a ingenuidade e a paranoia
O oposto de "acreditei em tudo o que disseram" não é "desconfie de tudo", e sim "verifique o que importa, registre o que não foi verificado e esteja preparado para o que escapar da rede". Essa é a filosofia que eu aplico em sistemas de risco: transparência sobre as limitações é mais valiosa do que a ilusão de precisão. Uma pontuação de 1 a 1000 que resume o caráter de uma pessoa em um número é confortável, mas perigosa. O mesmo vale para uma taxa de aprovação altíssima que esconde uma base de dados vazia.
A história da locadora não é um argumento contra confiar nas pessoas. Ela é um lembrete de que confiança sem verificação é uma escolha, e que sistemas digitais podem — e devem — reduzir o custo dessa escolha. Mas não podem eliminá-la. O risco sempre existirá, porque seres humanos são imprevisíveis e os dados que coletamos são apenas uma projeção imperfeita deles. O papel da engenharia não é prometer um mundo sem surpresas; é construir ferramentas que tornem as surpresas menos devastadoras, para as empresas e para as pessoas do outro lado da tela.