Quando a notícia do processo movido por ex-funcionários da Meta veio a público, minha primeira reação não foi de surpresa, mas de um incômodo técnico profundo. Segundo relatos, algoritmos da empresa foram utilizados para decidir quais pessoas seriam demitidas durante as ondas de cortes que marcaram 2022 e 2023. A lista de supostas vítimas inclui uma pesquisadora grávida, demitida dois dias antes do parto. Como engenheiro que já lidou com sistemas de recomendação e ranqueamento em larga escala, fico me perguntando: o que exatamente deu errado no design daquela automação? E, mais importante, o que time de engenharia algum — seja de produto, plataforma ou infraestrutura — deveria aprender com isso?
O problema não é a IA, é o critério que ela aprendeu a otimizar
Do ponto de vista de sistemas, um modelo de machine learning aplicado a RH não é conceitualmente diferente de um modelo que ranqueia anúncios ou recomenda vídeos. Ele recebe um conjunto de features — tempo de casa, avaliações de desempenho, cargo, unidade de negócio, custo salarial — e produz uma pontuação ou uma classificação. O ponto crítico, e onde quase sempre a engenharia falha ao validar modelos com impacto social, é a escolha da função de perda. Em sistemas de recomendação, um click-through rate baixo significa que o usuário não se engajou. Em um sistema de demissão, a perda que o modelo está tentando minimizar é puramente financeira ou de eficiência operacional. Não existe na função de custo uma penalidade para injustiça, para viés não intencional ou para impacto na vida de um ser humano.
Ao reportar o caso, o portal Super Abril destacou a situação da pesquisadora gestante. Isso me soa como um clássico caso de viés de proxy. O modelo, treinado em dados históricos, pode ter associado licenças maternidade iminentes a custos indiretos — treinamento de substituto, redistribuição de carga — e ranqueado aquela profissional como mais custosa de manter. O modelo não sabe o que é gravidez. Ele apenas encontrou uma correlação estatística entre uma combinação de features e um resultado desejado pelo negócio. E nós, como times de engenharia, falhamos em não criar guardrails para evitar que a máquina tomasse o atalho mais frio.
Como validar um modelo que age sobre carreiras
Em projetos que lidam com avaliação de pessoas, o processo de validação precisa ir muito além das métricas tradicionais de acurácia, precisão e recall. Eu já participei de revisões de modelos de scoring para alocação de recursos computacionais em nuvem, onde um falso positivo significa apenas desperdício financeiro. O custo de errar é baixo e reversível. Em um modelo de demissão, o erro é irreversível e tem impacto traumático. Portanto, a estratégia de validação deveria incluir análises de equidade grupais: comparar a taxa de demissão prevista para diferentes grupos demográficos dentro dos dados de treino. Se o modelo aponta maior chance de demissão para mulheres em idade fértil ou para funcionários em licença médica, você não tem um modelo de eficiência. Você tem um modelo discriminatório funcionando perfeitamente.
Ex-funcionários da Meta levaram o caso à Justiça dos EUA, e isso não é pouca coisa. Em tribunais, a defesa baseada em “o algoritmo apenas seguiu os dados” raramente se sustenta quando o resultado pratica discriminação indireta. Leis trabalhistas americanas e brasileiras proíbem demissões motivadas por gravidez. Se o algoritmo usou dados de licença ou previsão de licença para ranquear a funcionária, a empresa é responsável, independentemente de uma pessoa ou uma máquina ter apertado o gatilho. Do ponto de vista de engenharia, a ausência de uma etapa de auditoria humana no pipeline de decisão é uma falha arquitetural grave.
O dilema do gatekeeper humano no loop
Defensores da automação argumentam que um ser humano revisar cada caso inviabiliza a escala dos cortes. A Meta demitiu milhares de pessoas em múltiplas rodadas — fazer isso manualmente seria lento e caro. Mas a solução não é binária entre “IA decide tudo” ou “humano decide tudo”. O caminho tecnicamente correto é um sistema de recomendação com revisão por amostragem estratificada. O modelo pode gerar uma lista ranqueada de funcionários considerados “de risco” para demissão, mas o gestor responsável deve revisar os top N casos, especialmente aqueles que o modelo classifica com baixa confiança. Na prática, a engenharia precisa projetar um sistema que permita ao humano override explícito e que registre em log a razão de cada decisão, para auditoria futura.
Outro ponto que a fonte não menciona, mas que minha experiência em sistemas de ML me faz considerar, é o viés de feedback loop. Se a IA decide quem sai, e depois um novo modelo é treinado nos dados da empresa pós-demissão, ele aprenderá que a empresa funciona bem sem aquelas pessoas. Isso reforça a decisão inicial, criando um ciclo vicioso que valida matematicamente uma decisão que pode ter sido profundamente injusta. Para evitar isso, o dataset de treino precisaria ser marcado para indicar quais demissões foram recomendadas pelo modelo e quais foram decisões independentes. Caso contrário, a empresa constrói um sistema que prova para si mesma que seu viés estava certo.
Implicações para o mercado de trabalho e a cultura de produto
Posso falar por experiência própria: já vi equipes inteiras de engenharia se ressentirem quando uma decisão de corte foi tomada com base em métricas frias de produtividade. O efeito colateral mais perigoso de uma demissão algorítmica é a queda na confiança institucional. Funcionários que sobrevivem ao corte sabem que foram avaliados por um modelo cujos critérios eles desconhecem. Isso gera uma cultura de medo, onde as pessoas passam a otimizar seu comportamento para “enganar” o modelo — aumentar métricas superficiais — em vez de gerar valor real para o negócio.
Para times de produto e engenharia, fica uma lição clara: todo sistema de IA que impacta diretamente a vida das pessoas precisa ser tratado como um produto de alto risco regulatório. Não importa se o modelo é simples ou complexo. A fase de discovery deve incluir não apenas stakeholders de negócio, mas também representantes de RH, jurídico e, idealmente, do comitê de ética. A implementação deve prever feature flags e rollback automático se métricas de equidade violarem limites pré-definidos. Em uma arquitetura responsável, o sistema de demissão nunca deveria estar em produção sem um dashboard de monitoramento de viés sendo observado por um time multidisciplinar.
A Meta, aqui, serve como um estudo de caso para o que não fazer. Empresas menores, que estão começando a adotar IA para processos internos, podem aprender com esse erro sem precisar passar por um processo judicial. O primeiro passo é aceitar que um algoritmo pode tomar decisões melhores que humanos em tarefas repetitivas e previsíveis. Mas a seleção de pessoas para demissão está longe de ser repetitiva ou previsível. Envolve nuances de contexto, potencial futuro, contribuições intangíveis e, acima de tudo, dignidade humana.
A linha entre eficiência operacional e desumanização
Não sou contra automação. Passei anos projetando sistemas de auto-scaling em cloud que decidem, sem intervenção humana, quando desligar instâncias de servidor. A diferença é que servidores não têm sentimentos, famílias ou planos de carreira. Quando aplicamos a mesma lógica a pessoas, o custo de um erro de decisão não se mede em dólares de cloud, mas em vidas profissionalmente desestruturadas.
A demissão de uma pesquisadora grávida dois dias antes do parto não é apenas uma falha de processo. É o sintoma de uma cultura de engenharia que priorizou a eficiência do modelo acima da verificação de humanidade. Como profissionais de tecnologia, temos a obrigação de projetar sistemas que respeitem limites éticos claros, mesmo quando nenhum stakeholder de negócio pede por isso. A Justiça americana agora decidirá sobre o caso Meta, mas o debate que ele abre vai muito além dos tribunais. Ele nos força a responder: até onde estamos dispostos a delegar decisões que moldam o futuro das pessoas a uma função de perda mal projetada?
Na minha prática, adoto uma regra simples para qualquer sistema de IA que classifica pessoas: ele nunca deve ser o veredito final, apenas uma sugestão qualificada. O custo de adicionar um humano no loop é infinitamente menor que o custo reputacional, legal e moral de uma decisão automatizada que destrói uma vida. Se a Meta tivesse aplicado essa máxima, talvez a pesquisadora estivesse em licença maternidade com tranquilidade, e não em um tribunal com o nome da empresa estampado em manchetes negativas. Engenharia não é só sobre o que o sistema pode fazer. É sobre o que ele deve fazer.