Durante vinte anos, a transformação digital teve um aliado discreto: o tempo. Um ERP demorava dezoito meses a implementar, um CRM seis, um portal de clientes um ano. Enquanto a tecnologia se arrastava, as pessoas habituavam-se. Havia reuniões, formações, pilotos, versões beta. A adoção acontecia pelo caminho, quase sem ninguém a gerir.
A IA acabou com esse aliado. Uma equipa consegue ter um assistente a resumir emails, um agente a classificar pedidos de suporte ou um modelo a extrair dados de faturas numa semana — às vezes numa tarde. O que antes era o gargalo (construir) passou a ser rápido. O que antes era invisível (as pessoas mudarem a forma de trabalhar) passou a ser o gargalo.
É por isso que o change management, essa disciplina que durante décadas foi um capítulo no fim do plano de projeto, se tornou o próprio projeto. Este artigo explica o que mudou, quais são as resistências específicas da IA, onde os projetos costumam morrer e o que funciona quando se quer que a mudança pegue.
O que mudou: a tecnologia deixou de ser o caminho crítico
Num projeto tecnológico clássico, o cronograma era dominado pela construção. A gestão da mudança tinha meses para acontecer em paralelo e, quando o sistema entrava em produção, as pessoas já tinham ouvido falar dele vinte vezes.
Com a IA, a ordem inverteu-se. O modelo já existe, a integração faz-se em dias, e a organização recebe uma capacidade nova antes de ter tido tempo de discutir o que ela significa. O resultado é uma ferramenta pronta a usar numa empresa que ainda não decidiu quem a usa, para quê, com que limites e com que responsabilidade.
A BCG resume isto numa regra que vale a pena ter na parede: só cerca de 10% do valor de uma transformação com IA vem do algoritmo em si, outros 20% vêm dos dados e da tecnologia, e os restantes 70% vêm do redesenho do trabalho, da cultura, da governação e da colaboração entre pessoas e IA. Se 70% do valor está nas pessoas e nos processos, então 70% do esforço tem de estar lá também — e é raro estar.
As três resistências que são específicas da IA
A resistência à mudança não é nova. Mas a IA traz três formas que não existiam com a tecnologia anterior, e que os métodos clássicos não estavam a contar encontrar.
Medo de substituição. Quando uma empresa implementava um CRM, ninguém pensava que o CRM ia ficar com o seu emprego. Com a IA, é a primeira pergunta que toda a gente faz, mesmo que não a diga. E é uma pergunta legítima: a ferramenta faz uma parte do trabalho que a pessoa fazia. Um plano de mudança que não responde a isto de forma honesta — o que muda no papel de cada um, o que deixa de se fazer, o que passa a fazer-se — está a pedir sabotagem silenciosa.
Desconfiança do resultado. Os sistemas anteriores eram determinísticos: se o número estava errado, era um bug. A IA generativa erra de forma plausível, com confiança, e às vezes não se percebe. Quem já viu um modelo inventar uma referência ou trocar um valor tem razão em desconfiar. A resistência aqui não é emocional, é epistémica: "como é que eu sei quando isto está certo?" Sem uma resposta prática — onde está a verificação, quem a faz, o que acontece quando falha — as pessoas fazem o trabalho duas vezes ou deixam de usar.
Perda de estatuto. Em muitas equipas, o valor de uma pessoa está em saber o processo antigo: conhecer os atalhos do sistema, saber onde estão as exceções, ser a única que percebe aquele ficheiro de Excel. Quando a IA absorve parte desse conhecimento, essa pessoa perde influência. E é frequentemente a mesma pessoa de quem o projeto mais depende para funcionar.
Nenhuma destas resistências se resolve com uma sessão de formação sobre prompts.
O erro clássico: o piloto que funcionou e ninguém usa
O padrão repete-se em empresas de todos os tamanhos. Uma equipa pequena constrói um piloto — um assistente, um automatismo, um agente. Tecnicamente funciona: a demonstração corre bem, a direção fica entusiasmada, aprova-se a extensão ao resto da organização.
Seis meses depois, a utilização é residual. Não porque a ferramenta seja má, mas porque:
- foi desenhada por quem sabe tecnologia, não por quem faz o trabalho todos os dias;
- resolve o caso médio e falha nas exceções, que são precisamente o que ocupa as pessoas;
- não tem dono depois do piloto: ninguém responde por ela, ninguém a afina;
- mediu-se o deploy (está instalada) e não a adoção (está a ser usada, e o resultado mudou).
O relatório DORA de 2024, sobre equipas de engenharia, dá um aviso que se aplica muito para além do software: a adoção de IA aumentou a produtividade individual, o flow e a satisfação, mas piorou a estabilidade e o débito das entregas. Ou seja, cada pessoa sentiu-se mais rápida, e o sistema como um todo ficou pior. É o retrato de uma mudança feita ao nível do indivíduo sem redesenho do processo à volta.
O que funciona: começar pelo processo, não pela ferramenta
Os métodos clássicos continuam válidos. O modelo ADKAR da Prosci — consciência, desejo, conhecimento, capacidade, reforço — descreve bem as etapas por que cada pessoa passa. Os oito passos de Kotter — criar urgência, formar uma coligação, definir a visão, comunicar, remover barreiras, gerar vitórias rápidas, consolidar, institucionalizar — continuam a ser um bom mapa para a organização. O que muda com a IA é o ritmo a que têm de acontecer e onde se põe o peso. Na prática, o que temos visto funcionar:
Começar pelo processo. Antes de escolher a ferramenta, mapear o processo real — não o que está no manual, o que acontece. Onde entra o pedido, quem decide, onde ficam as exceções, quanto tempo demora cada passo, onde se perde informação. A IA entra depois, num ponto específico, com um objetivo mensurável. Um assistente "para ajudar a equipa" não tem critério de sucesso; um assistente que reduz o tempo de resposta ao cliente de 48 para 4 horas tem.
Desenhar com quem faz o trabalho. As pessoas que executam o processo conhecem as exceções que vão fazer o piloto falhar. Envolvê-las no desenho não é uma cortesia, é a única forma de a ferramenta funcionar na segunda semana. E resolve parte da resistência de estatuto: quem ajuda a desenhar o processo novo não perde influência, ganha-a.
Entregas pequenas e visíveis, todas as semanas. Um projeto de IA de seis meses com uma grande entrega no fim é uma aposta contra as pessoas. Entregas semanais — uma etapa automatizada, um relatório que passou a sair sozinho, uma fila que deixou de existir — dão às pessoas provas de que a mudança lhes serve, e à direção provas de que o investimento está a produzir. As "vitórias rápidas" de Kotter, em ciclos de dias em vez de trimestres.
Medir adoção, não instalação. Quantas pessoas usaram esta semana. Quantos pedidos passaram pelo processo novo em vez do antigo. Quanto tempo mudou. Quantas exceções tiveram de sair para o caminho manual. Se estas métricas não existem, o projeto está a ser gerido pela sensação de quem o patrocina.
Regras claras sobre quem decide. Em cada ponto onde a IA entra, escrever preto no branco: o que a ferramenta faz sozinha, o que propõe e uma pessoa aprova, o que nunca faz. Isto responde à desconfiança do resultado (há verificação, e sabe-se onde) e ao medo de substituição (o papel da pessoa está definido, não é o que sobra).
O papel da liderança: usar antes de mandar usar
Há um teste simples para saber se uma transformação com IA vai pegar: a direção usa a ferramenta? Não para uma demonstração — no trabalho dela, todos os dias.
Uma liderança que pede à organização para adotar IA enquanto continua a trabalhar como antes está a comunicar, sem querer, que aquilo é para os outros. O contrário — um diretor que resume as reuniões com um assistente, que pede à ferramenta a primeira versão de um documento e o diz — legitima a mudança mais do que qualquer plano de comunicação.
O Work Trend Index da Microsoft de 2026 põe a questão de forma direta: à medida que a IA e os agentes assumem a execução, o que sobra e cresce é a capacidade de decidir, e a pergunta é se as organizações estão construídas para aproveitar isso. É uma pergunta para a liderança, não para o departamento de TI.
Três coisas concretas que cabem à direção e a mais ninguém:
- Dizer o que acontece aos postos de trabalho. Se a resposta é "ninguém sai, o trabalho muda", dizê-lo, por escrito, cedo. Se a resposta é outra, também — a incerteza é pior do que qualquer das duas.
- Decidir o que a IA pode e não pode fazer com dados de clientes, com decisões que afetam pessoas, com dinheiro. Estas regras não se delegam.
- Aceitar que a primeira versão vai ser afinada e dar tempo e orçamento para isso, em vez de tratar o primeiro erro como prova de que "a IA não funciona".
Formação que não é formação
A maior parte da formação em IA nas empresas é um curso genérico de duas horas sobre como escrever prompts. Serve para pouco: as pessoas saem a saber pedir uma receita ao ChatGPT e continuam sem saber como é que aquilo se aplica à fatura que têm à frente.
O que funciona é mais parecido com aprendizagem no posto de trabalho:
- Casos da própria empresa. Sessões curtas com os documentos, os emails e os processos reais da equipa. "Isto é o pedido que chegou ontem; vamos fazê-lo com a ferramenta."
- Pares, não instrutores. A pessoa da equipa que já usa bem a ferramenta ensina a que está ao lado. É mais credível e resolve as dúvidas que um instrutor externo nem sabe que existem.
- Um lugar para perguntar. Um canal onde se pergunta "isto pode fazer-se com IA?" e alguém responde em horas. A maior parte das oportunidades de adoção morre porque a pessoa não sabia que era possível.
- Tempo protegido. Meia hora por semana para experimentar, sem ser roubada ao trabalho. Sem isto, a adoção fica reservada a quem já tinha folga.
Formação assim é o "conhecimento" e a "capacidade" do ADKAR feitos a sério, e é o que transforma uma ferramenta instalada numa ferramenta usada.
Sinais de alarme
Uma lista curta para verificar num projeto em curso. Dois ou mais sinais é razão para parar e corrigir antes de continuar.
- A ferramenta foi escolhida antes de o processo estar mapeado.
- Quem faz o trabalho não participou no desenho.
- A métrica de sucesso é "estar em produção" ou "número de licenças".
- Ninguém sabe dizer o que a IA decide sozinha e o que passa por uma pessoa.
- A direção não usa a ferramenta.
- A formação foi um curso genérico, uma vez.
- O piloto não tem dono depois do arranque.
- Não há data marcada para rever o que está a funcionar e o que não está.
- As pessoas fazem o trabalho "à antiga" em paralelo, para garantir.
Como abordamos isto na Scalor
O nosso trabalho é decidir o que a operação precisa de mudar e ficar até estar a funcionar, com entregas todas as semanas. Numa transformação com IA, isso significa que começamos pelo mapa do processo e pelas pessoas que o executam, não pela ferramenta; que cada semana há algo novo em produção que a equipa consegue ver; e que medimos adoção e resultado, não instalação. Quando a tecnologia é a parte fácil, o valor está em fazer a parte difícil com método. É assim que trabalhamos na otimização de processos e na formação em IA; para começar sozinho, o guia de adoção de IA resume os passos.
Perguntas frequentes
O change management é diferente na IA ou é o mesmo de sempre? Os princípios são os mesmos — consciência, envolvimento, capacidade, reforço. O que muda é o ritmo (a tecnologia já não dá tempo) e três resistências novas: medo de substituição, desconfiança de resultados não determinísticos e perda de estatuto de quem dominava o processo antigo.
Por onde começar numa PME sem departamento de gestão da mudança? Por um processo só, mapeado com quem o executa, com uma métrica de resultado definida antes de escolher a ferramenta. Uma pessoa responsável, entregas semanais e uma revisão marcada ao fim de um mês.
Como responder ao medo de perder o emprego? Com uma resposta escrita e cedo, da direção, sobre o que muda no papel de cada pessoa. A incerteza é pior do que qualquer resposta concreta e alimenta a resistência silenciosa.
Quanto tempo demora até a adoção pegar? Numa equipa pequena, com o processo bem escolhido e entregas semanais, os primeiros sinais de adoção real aparecem em duas a quatro semanas. O que demora meses é recuperar um piloto que arrancou sem envolver as pessoas.
Que métricas usar? Utilização semanal (quem usou, quantas vezes), percentagem de pedidos que passam pelo processo novo, tempo de ciclo antes e depois, número de exceções que saem para o caminho manual, e o resultado de negócio que justificou o projeto.
Fontes
Escreve sobre IA aplicada, operação, GEO/SEO e como transformar empresas em máquinas que continuam a funcionar mesmo quando ninguém está a olhar.