Um cenário ilustrativo. Uma equipa administrativa automatiza a entrada de faturas: o agente lê, classifica e concilia. O piloto arranca, o painel diz que funciona. A Marta, que fazia essa tarefa há oito anos, não se queixou de nada. E, no entanto, as exceções chegam tarde, mal explicadas ou nem chegam. Ninguém sabotou o projeto por maldade. Simplesmente, ninguém disse à Marta o que vai fazer na segunda-feira seguinte.
A tese numa linha: decidir o que faz amanhã a pessoa cujas tarefas o agente absorve faz parte do âmbito do projeto, não é um anexo de RH. Sem essa decisão, o piloto não falha por causa da tecnologia: falha porque quem melhor conhece o processo tem razões racionais para não ajudar.
Realocar colaboradores ao automatizar com IA: porque faz parte do âmbito
Um projeto de IA define-se com um processo, uns sistemas, uns dados e uma métrica. A pessoa que hoje faz o trabalho aparece como «utilizadora» ou «stakeholder», e o seu futuro, se aparecer, despacha-se com um diapositivo de gestão da mudança no fim do documento.
É um erro de desenho, não de sensibilidade. Essa pessoa conhece as exceções que não estão escritas em lado nenhum, valida o que o agente produz e decide todos os dias, com os seus atos, se o sistema vive ou não. É um componente do sistema. Se a tratares como um efeito secundário, o sistema comporta-se como um componente que ninguém especificou.
O que é a sabotagem passiva e porque aparece?
A sabotagem passiva é deixar de ajudar sem nunca se opor: não há conflito, não há queixa, há fricção. Aparece por pura racionalidade. Se o teu trabalho é o que vai desaparecer e ninguém te diz o que vem a seguir, o prudente é não te tornares tu próprio dispensável. Não é maldade; é o que qualquer pessoa faria.
Reconhece-se por sintomas concretos:
- As exceções não são documentadas. «Isso toda a gente sabe», diz quem sabe, e o agente tropeça nisso vezes sem conta.
- O agente é revisto com uma lupa que nunca se usou no trabalho humano. Cada falha é mostrada na reunião; cada acerto passa sem comentário.
- O trabalho continua a ser feito à mão «por precaução». O agente corre e a pessoa repete o mesmo em paralelo, por isso a poupança nunca chega a existir.
- Ninguém corrige o agente. Se corrigi-lo é treinar quem te substitui, o sensato é deixá-lo errar.
É uma das causas mais repetidas de um piloto que funciona na demonstração e nunca chega à produção; o padrão completo está no guia sobre porque falham os projetos de automatização com IA. Aqui ficamos com o mecanismo: a resistência não é um problema de atitude, é a resposta lógica a uma pergunta sem resposta.
O que é preciso decidir antes de começar?
Quatro decisões, por escrito, antes de aprovar o piloto:
- Que tarefas desaparecem e quais ficam. É preciso olhar para tarefas, não para postos: um posto raramente é uma só tarefa. Esse inventário é metade do trabalho de escolher que processos automatizar com IA, e costuma revelar que o que se absorve é uma parte do posto, não o posto inteiro.
- Para onde vai cada pessoa. Com nome e com data. Os destinos reais são poucos: supervisionar o agente (exceções, qualidade, casos duvidosos), passar para trabalho que antes não se fazia por falta de tempo, ou mudar para outra função na empresa. «Logo se vê» não é um destino.
- O que tem de aprender e quem paga. Em horário de trabalho, sobre o trabalho real e com alguém que responda às dúvidas. Não é um curso genérico: é disso que trata a rubrica de formação que ninguém orçamenta.
- O que acontece à poupança. Se o que se liberta são horas, tornam-se capacidade, menos contratações ou menos pessoas? Dizê-lo com clareza evita que a equipa o deduza sozinha, e quase sempre deduz o pior. A diferença entre horas libertadas e poupança real está em as horas libertadas não são poupança.
Supervisionar o agente não é um prémio de consolação. Um agente em produção precisa de alguém que decida nas exceções, e essa é uma função real, descrita no guia sobre o humano no circuito de uma automatização com IA. Quem mais sabe do processo costuma ser quem melhor a ocupa, desde que a função exista de verdade e não seja uma etiqueta.
E se não houver lugar para essa pessoa?
Às vezes não há, e prometer o contrário é pior do que não dizer nada. Realocar não significa garantir que ninguém perde o posto; significa que a decisão se toma de forma explícita, antes do piloto e não depois, e que a pessoa a conhece por ti e não pelo corredor.
Em Espanha, além disso, não é só uma questão de boas maneiras. O Estatuto dos Trabalhadores espanhol (Estatuto de los Trabajadores) regula a modificação substancial das condições de trabalho (art. 41) e, para o despedimento por falta de adaptação a alterações técnicas razoáveis do posto, obriga a oferecer antes um curso de adaptação (art. 52 b). Não é aconselhamento jurídico e cada caso é diferente: antes de falares com a equipa, fala com quem trata do vosso direito do trabalho. Outros países têm outras regras; este parágrafo vale só para Espanha.
Quando não é preciso tanto?
Se o que o agente absorve é uma fração pequena do trabalho de muita gente, um pouco de copiar-colar por semana, ninguém vê o seu trabalho desaparecer e basta dizê-lo com clareza. E se o objetivo declarado do projeto é reduzir pessoal, di-lo: chamar-lhe «realocação» e não a cumprir é pior do que a conversa difícil. A realocação é um compromisso, não um eufemismo.
A linha para levares: antes de aprovar o piloto, escreve uma frase por cada pessoa afetada. «Na segunda-feira a seguir à entrada em produção, X fará Y.» Se não a consegues escrever, o âmbito não está fechado, e o piloto tem data de validade mesmo que a tecnologia funcione.
Fonte consultada a 19 de outubro de 2026: Estatuto dos Trabalhadores espanhol, texto consolidado (BOE-A-2015-11430). Sobre a adoção como alavanca do ROI, ver a adoção, não o modelo, decide o ROI da tua IA.