Gestão de mudança clássica — os modelos ADKAR e de Kotter — foi desenhada para conduzir uma organização de um estado A para um estado B definido, com início, meio e fim. Enablement em IA é uma capacidade permanente, porque a IA não entrega um estado B fixo: ela muda de novo a cada trimestre, e o projeto de mudança já fechou o relatório final quando a próxima versão do modelo chega. A confusão entre os dois não é acadêmica — é a razão pela qual tanto RH quanto diretoria aprovam "programas de change management para IA" que funcionam bem no lançamento e murcham seis meses depois, quando a ferramenta já mudou e o projeto, por desenho, já foi dado como concluído. Este guia mostra onde a gestão de mudança clássica continua certa, onde ela trava estruturalmente diante da IA, e como as duas coisas se encaixam na prática.
Gestão de mudança e enablement em IA resolvem problemas de naturezas diferentes
Resposta direta: gestão de mudança é uma metodologia de projeto, com escopo, cronograma e critério de encerramento; enablement em IA é uma capacidade organizacional permanente, sem data de término, porque o objeto que ela administra — a própria IA — não para de mudar.
O que é gestão de mudança clássica (ADKAR e Kotter, em uma frase cada)
Os dois frameworks mais usados no mundo corporativo compartilham a mesma lógica de fundo: conduzir uma transição específica até um ponto de chegada.
- ADKAR, da Prosci, nasceu da pesquisa de Jeff Hiatt com 700 organizações em 1994 e descreve cinco etapas sequenciais na pessoa que muda — Consciência, Desejo, Conhecimento, Habilidade e Reforço — até que o novo comportamento se sustente sozinho.
- O modelo de 8 passos de Kotter trabalha em nível organizacional: criar urgência, formar uma coalizão, comunicar a visão, remover obstáculos, gerar vitórias de curto prazo e, por fim, ancorar a mudança na cultura — um processo linear com uma última etapa que sinaliza "terminou".
Os dois modelos são bem estabelecidos e continuam certos para o que foram desenhados: uma mudança específica, delimitada, com um estado final definido. A Prosci detalha a comparação completa entre os dois.
O que é enablement em IA
Já cobrimos a definição completa no pilar o que é enablement em IA: é a instalação de capacidade real de uso de IA nos times, combinando diagnóstico, trilha por área, governança e métrica de adoção — operada como programa contínuo, com dono e orçamento próprios, não como projeto com data de encerramento. A diferença com um treinamento pontual já foi detalhada em enablement em IA vs. treinamento em IA; este artigo faz a mesma comparação estrutural, mas contra o modelo de gestão de mudança clássico, que é mais sofisticado que um curso isolado e por isso trava por um motivo diferente.
Por que ADKAR e Kotter travam estruturalmente diante da IA
O problema não é qualidade de execução — as equipes de change management costumam ser competentes. O problema é o desenho dos próprios modelos diante de um objeto que não fica parado.
Os dois modelos assumem um estado final fixo — a IA não tem um
Um levantamento da Prosci com 1.107 profissionais sobre mudança orientada a IA descreve exatamente esse atrito: participantes relataram viver uma "Fase 2 sem fim", com um deles resumindo o problema em uma frase — a tecnologia "muda tão rápido que fica difícil saber o que estamos perseguindo". No modelo de Kotter, a etapa final é "ancorar a mudança na cultura": funciona bem quando a mudança para de se mover. Quando o objeto da mudança é IA generativa ou agêntica, ele não para — e um framework que precisa de um estado estável para declarar vitória não tem onde pousar.
O ritmo de lançamento da própria tecnologia é mais rápido que o ciclo de um projeto de mudança
Não é força de expressão. A indústria de IA já nomeou o fenômeno de "fadiga de modelos": a reportagem do Times Brasil/CNBC sobre o ritmo frenético de lançamentos cita o CEO da Runpod, Zhen Lu, afirmando que "a fadiga de modelos é algo real", e o próprio Sam Altman, da OpenAI, reconhecendo que "todos estamos migrando para ciclos mais rápidos". A mesma reportagem cita projeção da Gartner de que o gasto global com IA deve somar US$ 2,59 trilhões em 2026 — alta de 47% sobre 2025. Um projeto de gestão de mudança típico, do diagnóstico ao "ancoramento na cultura", leva meses; um novo modelo, com capacidades novas o suficiente para mudar o caso de uso que acabou de ser treinado, leva semanas. Quando o ciclo do framework é mais longo que o ciclo do objeto que ele administra, o framework está estruturalmente atrasado antes de terminar.
A IA chega em cima de outras 14 mudanças que já estão em curso
A gestão de mudança clássica também parte de uma premissa que deixou de valer: a de que a organização está parada esperando a próxima transição. O relatório Global Human Capital Trends 2026, da Deloitte, encontrou que um terço dos profissionais entrevistados enfrentou 15 grandes mudanças organizacionais só no último ano, e que apenas 27% dos líderes dizem que suas organizações administram mudança bem. O dado mais revelador do próprio relatório é o descompasso entre intenção e prática: 85% dos líderes afirmam ser crítico construir a capacidade de adaptação da força de trabalho, mas apenas 7% dizem estar de fato liderando essa adaptação contínua (Deloitte, comunicado de imprensa). Tratar a IA como "mais um projeto de mudança" na fila empurra a empresa para dentro dessa estatística, não para fora dela.
A diferença estrutural, lado a lado
| Dimensão | Gestão de mudança clássica (ADKAR/Kotter) | Enablement em IA |
|---|---|---|
| Objetivo | Levar a organização de um estado A a um estado B definido | Manter a capacidade de adotar IA atualizada enquanto a própria IA muda |
| Duração | Projeto com início, meio e fim declarado | Programa permanente, sem data de encerramento |
| Critério de sucesso | Mudança "ancorada" e estável | Adoção medida continuamente, reavaliada a cada nova capacidade |
| Dono típico | Sponsor executivo + equipe de projeto (muitas vezes terceirizada) | Líder de enablement em IA, com mandato e orçamento contínuos |
| O que acontece quando a tecnologia muda de novo | O projeto já fechou; a mudança seguinte abre um novo projeto do zero | O ciclo de diagnóstico e trilha se repete como rotina, não como exceção |
| Métrica-símbolo | Checklist de etapas cumpridas (Kotter) ou estágio ADKAR atingido | Uso recorrente, tarefas redesenhadas, AI fluency |
Onde a gestão de mudança clássica continua indispensável
Descartar ADKAR e Kotter seria um erro na direção oposta. Os dois modelos continuam certos para o que fazem bem: uma transição pontual, delimitada, dentro de um programa de enablement mais amplo — por exemplo, o lançamento de uma ferramenta específica, a migração para uma nova política de uso ou a virada de um piloto para produção. O guia gestão de mudança na adoção de IA detalha as táticas certas para esse tipo de transição pontual — patrocínio executivo, comunicação e capacitação por área — e continua sendo a referência prática para essa camada.
O mesmo levantamento da Prosci sobre mudança orientada a IA mostra por que o patrocínio continua decisivo mesmo dentro de um programa contínuo: em implementações classificadas como "muito tranquilas", o índice de apoio da liderança chegou a +1,65 (numa escala de -2 a +2); em implementações que travaram, o mesmo índice ficou em -1,50. A pesquisa também identificou uma lacuna de confiança por nível hierárquico — colaboradores de linha de frente pontuaram +0,33, contra +1,09 dos executivos, na mesma escala — um sinal de que quem decide confia mais na IA do que quem precisa efetivamente mudar a rotina para usá-la. Gestão de mudança clássica continua sendo a ferramenta certa para fechar exatamente essa lacuna de confiança dentro de um lançamento específico.
Como as duas coisas trabalham juntas na prática
A pergunta certa não é "gestão de mudança ou enablement em IA" — é onde cada uma entra:
- Enablement em IA é a estrutura permanente — o centro de enablement em IA, com dono, orçamento e rotina próprios, sustentando o programa mesmo quando a tecnologia muda de novo.
- Gestão de mudança clássica é a ferramenta usada dentro de cada ciclo — cada rollout específico (uma nova ferramenta, uma política nova, um novo caso de uso) ainda se beneficia de patrocínio visível, comunicação estruturada e um mini-ciclo ADKAR ou Kotter — mas esse ciclo acontece dentro da estrutura permanente, não como projeto isolado que se desmonta depois de "ancorado".
Na Jetpacks, essa integração é o próprio desenho do método Flight Plan: Launchpad (diagnóstico, equivalente a "criar urgência" e "formar uma coalizão" de Kotter, mas repetido a cada nova área ou capacidade, não uma vez só), Flight Plan (plano específico por área), Booster (capacitação aplicada, com certificação Jetpack Certified) e Mission Control (acompanhamento contínuo de métricas de adoção — a etapa que substitui o "ancoramento" único de Kotter por revisão recorrente). Cada ciclo leva cerca de duas semanas por área, e o programa segue rodando depois que a primeira área termina — é assim que evita virar mais um projeto que fecha o relatório final e desaparece. É o mesmo desenho usado com empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil. Quando essa estrutura ganha dono formal, o mandato e o perfil desse papel estão detalhados em líder de enablement em IA; e o estágio de maturidade em que sua empresa está hoje — de ações ad hoc a capacidade permanente — tem um modelo de cinco estágios em maturidade de enablement em IA.
Sinais de que sua empresa está usando o framework errado para o problema
- O projeto de "gestão de mudança para IA" tem uma data de encerramento no cronograma. Se a data existe, o framework escolhido pressupõe um estado final que a IA não vai entregar.
- Cada nova ferramenta de IA abre um projeto do zero, com patrocinador, orçamento e comunicação recomeçando do início. É sinal de que não existe capacidade permanente por trás — só uma sequência de projetos desconectados.
- Ninguém consegue dizer quem é o dono da adoção de IA depois que o último projeto de mudança "fechou". Sem dono contínuo, a estrutura simplesmente não existe entre um lançamento e o próximo.
Se dois ou mais desses sinais são verdadeiros, o gargalo não é a qualidade do projeto de mudança — é a ausência de uma capacidade permanente por trás dele.
FAQ
Enablement em IA substitui a gestão de mudança clássica?
Não substitui — muda o nível em que ela atua. ADKAR e Kotter continuam válidos para conduzir uma transição pontual (uma ferramenta nova, uma política nova); o que muda é que esse ciclo passa a rodar dentro de uma estrutura permanente de enablement, em vez de ser um projeto isolado que se encerra sozinho.
O modelo ADKAR funciona para adoção de IA?
Funciona para uma transição específica e delimitada — por exemplo, fazer um time adotar uma ferramenta de IA determinada. O que não funciona é usar um único ciclo ADKAR para "resolver a adoção de IA" da empresa inteira de uma vez, porque a IA não chega a um estado final estável onde o ciclo possa ser declarado concluído.
O modelo de Kotter serve para projetos de IA?
Serve para a mesma coisa que ADKAR: uma mudança pontual e delimitada. A etapa final do modelo — ancorar a mudança na cultura — pressupõe uma mudança que para de se mover; quando o objeto é IA generativa ou agêntica, a "cultura" precisa se ancorar em cima de algo que muda de novo dentro de poucos meses, o que exige repetir o ciclo, não completá-lo uma vez.
Por que a IA muda mais rápido que outros projetos de tecnologia corporativa?
Porque o ritmo de lançamento de novos modelos acelerou de ciclos anuais para praticamente semanais, segundo reportagem do Times Brasil/CNBC sobre a "fadiga de modelos" na indústria — um padrão sem precedente em outras categorias de tecnologia corporativa, como um ERP ou um CRM, que mudam de versão principal a cada um ou dois anos.
Quem deve liderar: o time de gestão de mudança ou o centro de enablement em IA?
O centro de enablement em IA (ou o líder de enablement, em empresas menores) é o dono da capacidade permanente; o time ou a metodologia de gestão de mudança segue sendo acionado dentro de cada rollout específico, como uma ferramenta tática dentro da estrutura maior — não como proprietário da adoção de IA como um todo.
Preciso de gestão de mudança se já tenho um centro de enablement em IA?
Sim, para cada lançamento pontual dentro do programa — patrocínio executivo, comunicação e capacitação continuam sendo o que garante adesão a uma ferramenta ou política específica. O que muda é que esse esforço passa a ser um ciclo dentro de uma estrutura permanente, não o programa inteiro.
Como saber se minha empresa sofre de fadiga de mudança por causa da IA?
Segundo a Deloitte, o sintoma típico é sobreposição: várias iniciativas de mudança (reestruturação, sistema novo, IA) rodando ao mesmo tempo, sem espaço de consolidação entre elas — cenário enfrentado por um terço das empresas pesquisadas em 2026. Se a IA é só mais uma dessas iniciativas na fila, e não uma capacidade que absorve as demais, a fadiga tende a se acumular.
Enablement em IA é mais caro que um projeto de gestão de mudança pontual?
O investimento inicial pode ser parecido; o que muda é o horizonte. Um projeto de gestão de mudança pontual tem custo e prazo fechados, mas precisa ser refeito do zero a cada nova ferramenta ou capacidade de IA relevante. Uma estrutura permanente de enablement absorve essas ondas sucessivas sem reiniciar o ciclo inteiro — o modelo de financiamento do centro de enablement em IA detalha como orçar essa função de forma recorrente, em vez de projeto a projeto.
Conclusão
ADKAR e Kotter continuam sendo ferramentas válidas — só não para o problema que a maioria das empresas está tentando resolver com eles. Os dois foram desenhados para uma mudança com começo, meio e fim; a IA não oferece um fim, porque o ritmo de lançamento de novos modelos e capacidades já superou o ciclo de qualquer projeto de mudança tradicional. A resposta não é abandonar a gestão de mudança clássica, e sim rebaixá-la de "programa inteiro" para "ferramenta dentro de cada ciclo" — com uma estrutura permanente de enablement em IA por trás, absorvendo a próxima onda antes que o projeto anterior sequer feche o relatório final.
Se sua empresa ainda trata cada nova ferramenta de IA como um projeto de mudança que recomeça do zero, o primeiro passo é entender onde a capacidade permanente já deveria estar e não está. É exatamente o que o diagnóstico gratuito da Jetpacks mapeia em uma conversa de 30 a 45 minutos, usando o método Flight Plan — e, para quem decide o orçamento, o business case de enablement em IA ajuda a levar a decisão à diretoria com número, não com opinião.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.