Compraste as licenças do copiloto. Houve um email de lançamento, talvez uma formação. E três meses depois, quando olhas para o uso real, a maioria não o abriu esta semana. Não és só tu: a Microsoft reportou cerca de 15 milhões de utilizadores pagos do Copilot para uns 450 milhões de licenças Office comerciais —cerca de 3% de adoção real— e em 2026 o uso semanal ativo típico anda nos 20-30% dos lugares com licença. A conclusão incómoda é esta: o copiloto de IA interno não falha no modelo. Falha porque ninguém o usa.
A tese numa frase: um copiloto interno morre na adoção, não na capacidade. O modelo é quase sempre suficientemente bom; o que falha é o encaixe no fluxo de trabalho real e o acesso aos dados que tornam a resposta útil. Sem essas duas coisas, a licença cara fica por abrir —e o problema não se resolve comprando um modelo melhor.
Porque é que o copiloto de IA interno fica por abrir
O padrão de abandono é tão consistente que já está documentado: as pessoas experimentam o copiloto uma ou duas vezes, percebem que rever e corrigir o rascunho que gera leva mais tempo do que escrevê-lo elas próprias, e deixam de o usar. A queda de uso acontece na primeira semana, não no primeiro ano. Não é preguiça nem resistência à mudança: é uma decisão racional. Se a ferramenta te custa mais do que te poupa na tua tarefa concreta, abandoná-la é a escolha certa.
E eis o erro de diagnóstico que se paga caro: quando a adoção estagna, a reação típica é pensar que o modelo fica aquém e procurar um melhor. Mas os dados apontam para o contrário —a perceção do utilizador diverge da qualidade do modelo— o que aponta para a experiência de produto e a execução da integração, não para a capacidade. Mudar de modelo quando o problema é o encaixe é gastar na alavanca errada.
As três razões reais pelas quais a adoção cai
Debaixo do «não o usam» há causas concretas, e nenhuma se resolve com um modelo mais potente.
- Não encaixa no fluxo de trabalho. O copiloto vive num separador à parte e o trabalho vive noutro sítio. Se usá-lo obriga a sair do fluxo, copiar contexto e voltar, o atrito come a poupança. A ferramenta tem de estar onde já se trabalha, não numa janela que é preciso ir buscar.
- Não tem os dados à mão. Um copiloto que não conhece as tuas políticas, o teu histórico nem os teus sistemas responde genérico —e o genérico tem de ser reescrito por inteiro. O salto de «assistente que redige coisas plausíveis» para «assistente que responde com os teus dados» é o que separa um brinquedo de uma ferramenta.
- Ninguém mostrou que funciona numa tarefa real. Sem um caso visível na equipa —alguém que o usa para algo concreto e poupa mesmo tempo— não há prova social que arraste os restantes. As pessoas não adotam por um email; adotam quando veem um colega resolver em dois minutos o que a elas leva vinte.
Há uma quarta, silenciosa: as dúvidas sobre segurança e dados que ninguém esclareceu. Se a equipa não sabe se os seus prompts treinam o modelo ou se pode meter dados de cliente, muitos simplesmente não o usam —e não o dizem. Essa incerteza mata a adoção sem deixar rasto em nenhum inquérito.
Um copiloto não é um agente: a nuance que muda o projeto
Parte do problema é esperar do copiloto algo que, por desenho, não faz. Um copiloto assiste uma pessoa: espera a tua instrução, redige, resume, procura. Brilha no pontual e morre no repetitivo que atravessa várias apps —recolher o que entra por email e deixá-lo estruturado, manter uma ficha coerente em três sítios, montar um dossiê a partir do disperso. Isso não o faz um copiloto que espera ordens; fá-lo um agente administrativo que trabalha sozinho. Decidir qual precisas é a primeira pergunta de que processos automatizar com IA: se o trabalho é assistir pessoas, copiloto; se é tirar trabalho de teclado repetitivo, agente. Vender um copiloto onde era preciso um agente é garantia de deceção, e vice-versa.
Como se resolve a adoção (e não é com outro modelo)
Se a adoção é o problema, a adoção é onde se investe. Na prática são quatro movimentos, nenhum sobre o modelo:
- Meter o copiloto no fluxo real. Onde já se trabalha —o CRM, o helpdesk, o documento— não num separador à parte. Se é preciso ir buscá-lo, não se usa.
- Dar-lhe os dados à mão. Ligá-lo às tuas políticas, ao teu histórico e aos teus sistemas para que responda com os teus dados e não com o genérico. É aqui que um copiloto passa de plausível a útil.
- Escolher 2-3 tarefas concretas e demonstrá-las. Não «usem a IA»: «para este tipo de email, este prompt poupa-te quinze minutos». Um caso visível que funciona arrasta mais do que dez formações.
- Responder à pergunta de segurança antes de a fazerem. O que acontece aos dados, o que se pode meter e o que não. A confiança é um pré-requisito de uso, não um extra.
É, no fundo, a mesma razão pela qual os projetos de automação com IA fracassam: compra-se tecnologia e salta-se o encaixe com o trabalho real e as pessoas que o fazem. A tecnologia é a parte fácil; que seja usada é a difícil, e é a que decide o retorno. Por isso o trabalho que mexe mesmo o ponteiro não é escolher um modelo, é a adoção da IA nas equipas: encaixe no fluxo, dados ligados, casos demonstrados e dúvidas esclarecidas.
A pergunta a fazer antes de renovar licenças
Quando chegar a renovação e vires o uso plano, a tentação será mudar de fornecedor ou de modelo. Antes, faz a pergunta que ordena o problema: as pessoas não o usam porque o modelo é mau, ou porque não encaixa no seu trabalho e não tem os dados à mão? É quase sempre a segunda. E isso não se resolve comprando —resolve-se montando a adoção como um projeto com dono, não como um email de lançamento. Um copiloto que ninguém usa não é um problema de IA: é uma licença cara à espera de que alguém faça o trabalho de a pôr a ser usada.