Quando o algoritmo não enxerga a trajetória
Há alguns anos, li um relatório técnico de uma grande plataforma de recrutamento que utilizava inteligência artificial para ranquear candidatos. O modelo, treinado com dados históricos de contratações bem-sucedidas, apresentava um problema sutil, porém devastador: penalizava sistematicamente candidatos que haviam estudado em universidades públicas, mas cujo histórico escolar indicava um tempo de conclusão acima da média. O argumento do modelo era simples — "maior tempo de formação correlaciona-se com menor produtividade". O que o algoritmo não capturava, e dificilmente capturaria sem intervenção explícita, era que aquele candidato havia trabalhado durante todo o curso para se sustentar, algo que um aluno de escola particular ou de elite raramente precisa fazer.
A história de Angélica Toledo, médica formada pela USP que saiu da escola pública em Cidade Tiradentes, extremo leste de São Paulo, me trouxe de volta àquele relatório. Não porque sua trajetória seja incomum — na verdade, é perturbadoramente comum para quem vem da periferia — mas porque ela expõe uma questão que o mercado de tecnologia ainda trata como periférica: como construir sistemas de IA que não repliquem, de forma automatizada e em escala, as desigualdades estruturais que já conhecemos?
O gargalo não está nos dados, está no desenho do problema
Quando falamos de IA aplicada a processos de seleção, avaliação de talentos ou mesmo alocação de recursos educacionais, o discurso dominante é quase sempre o mesmo: "precisamos de mais dados". A premissa é que, com volume suficiente de informações, o algoritmo encontrará os padrões "verdadeiros" de sucesso. Essa visão, que ecoa fortemente no Vale do Silício e nas startups brasileiras de HR Tech, carrega um equívoco fundamental. O problema não é a quantidade de dados, mas como definimos o que é "sucesso" e, mais importante, como o modelo é autorizado a chegar até essa definição.
No caso de Angélica, se um sistema de IA analisasse seu currículo contra o de um colega que cursou Medicina em escola particular, com cursinho preparatório, inglês fluente desde os 12 anos e estágios em hospitais de elite desde o segundo ano, o modelo provavelmente apontaria o segundo como "mais apto". Não por maldade, mas porque os sinais tradicionalmente associados a "excelência acadêmica e profissional" — publicações em revistas internacionais, intercâmbios, prêmios em Olimpíadas do Conhecimento — são desproporcionalmente acessíveis a quem já nasceu em posição de privilégio. O algoritmo, nesse caso, não está errado: ele está sendo honesto com as variáveis que lhe foram dadas. O erro está no desenho do problema.
Três falhas estruturais no design de sistemas de IA para RH
Minha experiência implementando soluções de IA para processos corporativos me mostrou que existem três camadas de falha que precisam ser endereçadas antes mesmo de escrever a primeira linha de código de um modelo preditivo para seleção de pessoas. A primeira é a falha de representação: quando o dataset de treinamento contém majoritariamente históricos de profissionais de classes A e B, o modelo aprende que "sucesso" se parece com aquilo. Ele não tem como aprender que alguém como Angélica — que fez cursinho comunitário, estudou em escola sem laboratório e passou em Medicina na USP em uma época sem cotas — representa um tipo de resiliência e capacidade de execução que não aparecem em features tradicionais.
A segunda é a falha de validação. Grande parte dos modelos de matching de currículos é validada contra "contratações bem-sucedidas" definidas por métricas como tempo de permanência na empresa ou avaliação de gestores. O problema é que gestores também têm vieses. Um gerente que prefere contratar profissionais que "se encaixam na cultura" pode estar, conscientemente ou não, favorecendo perfis homogêneos. O modelo, então, aprende a reproduzir essa homogeneidade, criando um ciclo vicioso de exclusão que o departamento de diversidade e inclusão depois tenta quebrar com ações paliativas.
A terceira, e talvez mais perigosa, é a falha de feedback loop. Sistemas de recomendação de candidatos que não recebem retorno explícito sobre contratações rejeitadas ou candidatos ignorados tendem a reforçar seus próprios vieses. Se o sistema aprendeu que universidades federais são um sinal "fraco" e passa a rebaixar esses currículos, a taxa de contratação desses profissionais cai, o que "confirma" para o modelo que aquilo realmente era um sinal fraco. O sistema se retroalimenta do próprio erro.
O custo de ignorar trajetórias não lineares
Li recentemente um paper do grupo de ética em IA do MIT que demonstrava algo que qualquer pessoa que já liderou times diversos sabe na prática: equipes com alta diversidade de background socioeconômico — e não apenas de gênero ou raça — tendem a ser mais inovadoras em contextos de resolução de problemas complexos. O mecanismo é intuitivo: pessoas que precisaram superar barreiras estruturais desenvolvem um repertório de soluções de contorno que profissionais de trajetórias lineares simplesmente não têm.
Angélica não entrou na USP por um caminho direto. Ela fez cursinho popular, trabalhou, estudou em condições adversas. Cada uma dessas experiências gerou um aprendizado tático — como otimizar tempo, como negociar recursos escassos, como se adaptar a ambientes hostis — que um sistema de IA que lê apenas "escola pública + aprovada em Medicina na USP" não consegue capturar. O algoritmo vê o resultado, não o processo. E no mundo real, especialmente em carreiras que exigem julgamento clínico, tomada de decisão sob pressão e resiliência emocional, o processo importa tanto ou mais que o destino.
Como projetar sistemas de IA que enxerguem além do currículo
Não estou sugerindo que devemos abandonar o uso de IA em processos de RH. Longe disso. A automação de triagem de currículos, quando bem feita, pode liberar recrutadores para se concentrar em entrevistas aprofundadas e avaliação qualitativa. Mas é preciso redesenhar a arquitetura desses sistemas com algumas premissas diferentes do que se faz hoje.
A primeira mudança é incluir variáveis de contexto no modelo. Em vez de apenas "nota no ENEM", o sistema pode considerar "renda per capita da família" ou "indicador de vulnerabilidade social da região". Isso não é criar um viés inverso ou uma "cota algorítmica" — é dar ao modelo informações que permitam distinguir entre um aluno de escola pública que teve acesso a cursinho privado e um que não teve. A granularidade importa. Um modelo treinado com dados do Censo Escolar e do CadÚnico pode fazer essa distinção com muito mais precisão do que um recrutador humano que olha para o currículo em 30 segundos.
A segunda mudança é adotar métricas de fairness durante o treinamento. Em vez de otimizar apenas por acurácia preditiva (qual candidato tem mais chance de ser contratado e ficar na empresa), o modelo deve ser treinado com restrições explícitas de equidade entre grupos. Existem frameworks matemáticos maduros para isso — como demographic parity, equal opportunity e equalized odds —, mas são raramente aplicados em soluções de RH comerciais. A justificativa técnica para não aplicá-los é sempre a mesma: "reduz a acurácia geral do modelo". E é verdade. Mas a pergunta que os engenheiros de machine learning precisam se fazer é: a acurácia geral sobre qual população? Se o modelo é acurado para 80% dos candidatos, mas sistematicamente erra nos 20% que vêm de periferia, ele não é um bom modelo — é um modelo enviesado que gera falsa segurança para quem o utiliza.
O papel do engenheiro de software e do líder de produto
Sempre que palestro sobre vieses algorítmicos em eventos de tecnologia, ouço a mesma objeção de profissionais da área: "mas quem define as variáveis e as métricas de sucesso não é a engenharia, é o negócio". Há uma dose de verdade nisso, mas também uma transferência de responsabilidade que não se sustenta. Engenheiros de software que constroem sistemas de recomendação, matching ou triagem tomam dezenas de decisões técnicas que têm impacto direto no viés do modelo — desde a escolha do algoritmo (árvores de decisão são mais interpretáveis, mas também mais propensas a overfitting em subgrupos minoritários), passando pela estratégia de tratamento de dados faltantes (candidatos que não preencheram campos como "idiomas" ou "intercâmbio" são penalizados de forma desproporcional), até a definição dos thresholds de corte.
Líderes de produto, por sua vez, têm o dever de questionar as métricas de sucesso de seus sistemas. Se o KPI do seu sistema de seleção é "reduzir o tempo de preenchimento de vagas", você está incentivando o algoritmo a recomendar candidatos "seguros" que se parecem com os já contratados. Se o KPI é "aumentar a diversidade do pipeline", o algoritmo precisa ser desenhado de outra forma. Produto define o que é otimizado. E o que é otimizado, via de regra, é o que se obtém. Não se trata de culpabilizar a tecnologia: trata-se de reconhecer que sistemas de IA são artefatos de engenharia que carregam, em cada linha de código, as premissas e os valores de quem os construiu.
O que a trajetória de Angélica nos diz sobre o futuro da IA no trabalho
A história de superação que o G1 registrou não é apenas inspiradora — é um dado estrutural sobre como o talento no Brasil está distribuído de forma profundamente desigual, e sobre como nossos sistemas de avaliação (sejam eles humanos ou algorítmicos) falham em capturar essa distribuição. Enquanto tratarmos a IA como uma ferramenta neutra que "encontra os melhores talentos" sem questionar o que significa "melhor" nesse contexto, continuaremos projetando sistemas que favorecem quem já está em posição de vantagem.
Na prática, a IA aplicada a processos de seleção deveria fazer o oposto do que faz hoje. Em vez de replicar os critérios de um mercado que já é excludente, deveria ser usada para ampliar o radar — para identificar talentos que os filtros tradicionais jamais enxergariam. Isso exige coragem técnica para questionar premissas estabelecidas e coragem de produto para defender métricas que, no curto prazo, podem parecer menos eficientes.
Angélica chegou à Medicina na USP sem IA. A questão que fica para quem constrói a próxima geração de sistemas de talento é: se ela estivesse se candidatando hoje a uma vaga de emprego filtrada por um algoritmo, ele a reconheceria como o talento extraordinário que ela é? Se a resposta for "provavelmente não", então temos trabalho a fazer — e ele começa muito antes do deploy em produção.