Quando uma empresa decide automatizar um processo, ela está, na prática, tomando uma decisão de design de sistema que pode eliminar dezenas ou centenas de postos de trabalho. Os quase 600 mil empregos perdidos nos EUA em janeiro de 2026 não são fruto de uma fatalidade econômica: são o resultado de escolhas arquitetônicas, de alocação de capital e de priorização de produto. Como engenheiro que já liderou projetos de automação em operações logísticas, afirmo com segurança: a narrativa de que "a tecnologia substitui o trabalho humano" é simplista demais. O que de fato acontece é que os sistemas são projetados para prescindir do humano, e essa decisão técnica deveria ser revista com muito mais rigor do que tem sido.
A fonte do Economic Times relata o aumento de 15% nas demissões em relação ao ano anterior, com setores como logística e atendimento ao cliente sendo os mais impactados. Mas a pergunta que não se faz nos veículos generalistas é: que tipo de arquitetura de automação foi escolhida? Automação total ou assistida? Quem definiu os thresholds de confiança dos modelos? Como a governança de dados foi estruturada antes do rollout? Ignorar essas questões é perpetuar um debate raso sobre futuro do trabalho, quando o que precisamos é de uma discussão técnica profunda sobre trade-offs que continuam sendo mal avaliados.
O paradoxo dos lucros recordes e da redução de força de trabalho
Empresas como Amazon e UPS reportaram resultados financeiros sólidos no mesmo período em que cortaram milhares de vagas. Do ponto de vista de produto, isso é coerente: automação reduz custos fixos de mão de obra e aumenta a previsibilidade operacional. O que não se discute é o impacto na resiliência do sistema. Quando você elimina operadores humanos de um fluxo logístico, está removendo a capacidade de adaptação em tempo real a exceções não previstas nos dados de treinamento. Já vi, em primeira mão, um centro de distribuição automatizado parar por horas porque um sensor de esteira falhou e não havia ninguém para interpretar o erro e aplicar um workaround manual. O custo dessa parada superou em muito a economia salarial do turno.
O trade-off real não é entre eficiência e emprego, mas entre eficiência em condições ideais e resiliência em condições adversas. A maioria dos modelos de negócio atuais opta pelo primeiro, mas essa escolha raramente é questionada nos comitês de arquitetura. Cabe a nós, engenheiros, trazer esses riscos para a mesa antes que a decisão seja tomada exclusivamente pela diretoria financeira.
A falácia do "custo total de operação" na automação
Toda planilha de ROI de automação que já vi considerava salários, benefícios e encargos trabalhistas como custo direto, e comparava com o custo de implementação e manutenção do sistema automatizado. Raramente entra nessa conta o custo implícito da perda de conhecimento tácito. Um operador experiente de depósito sabe, por exemplo, que determinado corredor tem piso irregular e que carrinhos com rodas gastas travam ali. Esse conhecimento simplesmente não está nos logs do sistema. Quando o robô autônomo é implantado, ele quebra com frequência nesse mesmo ponto, e a manutenção corretiva se torna recorrente. O custo de engenharia para mapear e tratar todas essas exceções é subestimado nos estudos de viabilidade.
Para agravar, a decisão de substituir por automação total em vez de assistida (human-in-the-loop) é muitas vezes tomada para "maximizar o corte de custos", sem considerar a complexidade de integração com sistemas legados. Conheci casos em que a implementação de RPA em um sistema de faturamento antigo gerou mais erros do que resolveu, porque a interface não possuía APIs estáveis e o robô dependia de scraping de tela. O resultado? Retrabalho manual ainda maior e demissões que poderiam ter sido evitadas se a arquitetura tivesse sido pensada com mais cuidado.
Arquitetura em camadas e o ponto sem retorno
O modelo típico de automação que leva a demissões em massa segue uma decomposição em três camadas: sensoriamento (IoT e câmeras), processamento (ML e otimização) e execução (robôs físicos ou software). A cada camada automatizada com sucesso, a equipe humana correspondente é reduzida. O problema é que, uma vez que o sistema entra em produção e a operação se torna dependente dele, reverter a decisão é extremamente caro. É o que chamo de "ponto sem retorno arquitetônico". Depois que o contrato de locação dos robôs é assinado e os operadores humanos são demitidos, não há mais opção de voltar atrás — mesmo que o sistema apresente falhas recorrentes.
Esse cenário é agravado pela falta de métricas de qualidade operacional nos dashboards de automação. As métricas que importam para a diretoria são throughput e custo por unidade processada. Raramente se mede taxa de exceções não tratadas, tempo médio de resolução de incidentes ou perda de conhecimento tácito. Sem esses indicadores, a ilusão de eficiência se mantém até que um evento crítico exponha a fragilidade do sistema.
O que a governança de dados tem a ver com demissões
Um aspecto técnico pouco explorado é que os modelos de IA que substituem funções humanas precisam ser treinados com dados representativos do cenário operacional real. Muitas empresas utilizam dados históricos que contêm vieses de processos manuais — por exemplo, rotas definidas por motoristas experientes que evitavam certas ruas em horários de pico por conhecimento empírico. Se o modelo de otimização de rotas não incorporar esse conhecimento, ele pode gerar rotas "ótimas" no papel, mas que na prática aumentam atrasos e consumo de combustível. O resultado é que o sistema automatizado piora a operação, e a culpa é atribuída aos dados, não à decisão de demitir os motoristas.
A governança de dados deveria incluir um processo de validação de que o conhecimento tácito foi capturado antes da transição. Isso pode ser feito por meio de entrevistas estruturadas, gravação de decisões em logs durante um período de operação híbrida, ou mesmo pela criação de um conjunto de regras de negócio extraídas da experiência humana. Ignorar essa etapa é uma falha grave de engenharia, e não apenas uma questão ética.
Implicações para engenheiros e gestores de produto
Para quem está na linha de frente do desenvolvimento de sistemas de automação, a lição mais importante é: inclua a transição da força de trabalho como requisito funcional do roadmap. Isso significa prever fases de operação híbrida, onde humanos e sistemas automatizados coexistem, e onde o conhecimento tácito é transferido para o sistema de forma explícita. Significa também projetar indicadores de resiliência que vão além do ROI financeiro, como tempo de recuperação de falhas e taxa de exceções não previstas.
Outro ponto prático: sempre que possível, opte por arquiteturas de automação assistida em vez de total. Sistemas human-in-the-loop não apenas mantêm empregos, como também criam um ciclo de feedback que permite ao modelo aprender continuamente com a supervisão humana. Empresas que adotaram essa abordagem relataram menos incidentes críticos e maior adesão dos times operacionais. Não é uma decisão "menos tecnológica"; é uma decisão de engenharia mais robusta.
Riscos que todo engenheiro deveria documentar
Ao final de cada sprint de automação, sugiro incluir no artefato de arquitetura uma seção de riscos operacionais com ao menos três itens:
- Perda de conhecimento tácito: quais decisões humanas não foram capturadas nos dados de treinamento?
- Dependência de dados de treinamento: qual a cobertura de cenários excepcionais no dataset?
- Custo de reversão: qual o esforço para retornar ao modo manual caso o sistema automatizado falhe?
Um chamado à responsabilidade técnica
Não defendo aqui que a automação seja interrompida ou que inovação tecnológica deva ser freada. Pelo contrário: acredito que sistemas bem projetados podem aumentar a produtividade sem eliminar completamente o papel humano. O que defendo é que a decisão de eliminar postos de trabalho seja tomada com total consciência dos riscos arquitetônicos envolvidos, e não apenas como consequência colateral de um dashboard de economia de custos. Como engenheiros, temos o dever de apontar esses riscos antes que a implementação avance. Se não o fizermos, seremos cúmplices técnicos de um design de sistema que desconsidera a resiliência operacional em nome de uma eficiência de curto prazo.
Os 600 mil empregos perdidos em janeiro de 2026 são um número que deveria nos fazer refletir sobre os critérios com que projetamos automação. Mais do que isso, deveria nos levar a revisar urgentemente a forma como mensuramos sucesso em projetos de IA e robótica. Enquanto métricas de produtividade ignorarem a perda de capacidade adaptativa, continuaremos repetindo o mesmo erro em escala industrial.