Resposta rápida: Os dez erros que mais derrubam implementação de IA nas empresas: comprar ferramenta antes de definir o problema, automatizar o processo atual sem redesenhar, tocar piloto sem dono nomeado, escolher o processo mais doloroso em vez do mais frequente, esperar o caso de uso perfeito, deixar a média liderança de fora, tratar governança como fase dois, medir adoção em vez de resultado, não desenhar a revisão humana, e não ter plano para o dia em que a pessoa que configurou tudo sai da empresa. Cinco deles acontecem antes de qualquer tecnologia entrar em cena, e outros três durante o piloto, e é por isso que trocar de fornecedor quase nunca resolve.
Eu já entrei em muita empresa depois do fracasso, e a cena costuma ser parecida. Existe uma ferramenta contratada, um grupo de entusiastas, uma apresentação bonita de seis meses atrás e uma diretoria desconfiada. Ninguém sabe dizer direito o que deu errado, e a explicação que circula é que a tecnologia não estava madura.
Quase nunca é isso. Nos casos que eu acompanhei de perto, o projeto morreu por um dos dez motivos abaixo, e a maioria deles é decisão de gestão tomada semanas antes de alguém abrir qualquer sistema.
O critério: erro que mata projeto, e não erro que atrasa
Um erro só entrou nesta lista se eu vi ele matar projeto, e não apenas atrasar. Atraso é normal em qualquer implementação, e a empresa aprende no caminho. Morte é diferente: é o programa que perde patrocínio, some do orçamento do ano seguinte e deixa cicatriz, porque a próxima tentativa começa com a liderança lembrando que já tentaram uma vez.
Organizei por estágio, na ordem da figura acima. Os cinco primeiros acontecem na decisão, antes de existir piloto. Os três seguintes aparecem durante o piloto. Os dois últimos aparecem na passagem para produção e na escala, que é onde a empresa descobre que operar é bem diferente de testar.
Cada item traz como o erro aparece na prática, o que ele custa e o conserto que cabe em um trimestre. Onde já existe um artigo mais fundo, deixei o link, porque vários destes erros merecem texto próprio.
1. Comprar a ferramenta antes de definir o problema
Aparece como uma licença corporativa contratada para toda a empresa, com treinamento de duas horas e a expectativa de que o time descubra sozinho o que fazer com aquilo. Três meses depois, a taxa de uso está em quinze por cento e ninguém consegue apontar um processo que ficou melhor.
O custo é duplo. Tem o dinheiro da licença, que costuma ser o menor dos problemas, e tem o custo político: a diretoria passa a acreditar que já investiu em IA e não deu certo, o que fecha a porta para o projeto seguinte, que talvez fosse o certo.
O conserto é começar pelo processo. Escolha dois processos com volume alto e erro barato, desenhe o fluxo com quem opera, e só então decida qual ferramenta serve. A ordem correta está detalhada em comprar ferramentas de IA antes da estratégia. Empresa que já comprou não precisa desfazer a compra, precisa parar de tratar a compra como projeto. Costuma ajudar reunir num documento de uma página o que foi contratado, quanto custa por mês e qual processo cada licença deveria estar servindo, porque a lacuna fica visível na hora.
2. Automatizar o processo atual sem redesenhar
Este é o erro mais caro da lista, e o mais educado, porque ele parece pragmatismo. O time pega o fluxo existente, com as três aprovações herdadas de uma auditoria de 2019 e o retrabalho que ninguém questiona, e coloca uma camada de automação em cima. Funciona, entrega algum ganho, e trava ali.
O custo é o teto: você fica com uma fração do ganho possível e ainda cristaliza o processo ruim, porque agora existe um sistema construído em cima dele. Mexer no fluxo depois passa a ser projeto de tecnologia, e não mais conversa de gestão.
O conserto tem uma pergunta só, feita antes de qualquer automação: se a gente fosse desenhar isso hoje, do zero, com as ferramentas que existem, este passo continuaria existindo? Em geral três ou quatro passos caem sozinhos, e as pessoas que operam apontam esses passos em quinze minutos de conversa, desde que alguém pergunte e leve a sério a resposta. Esse é o momento em que o projeto deixa de ser de tecnologia e vira de gestão. Escrevi sobre a armadilha em treinar em IA sem mudar o processo.
Leia também
3. Tocar piloto sem dono nomeado
Aparece assim: o piloto é de todo mundo, tem um grupo de mensagens com sete pessoas, uma consultoria envolvida e nenhum nome escrito na linha de responsável. Enquanto tudo corre bem, ninguém sente falta. Na primeira decisão difícil, o projeto para e fica esperando uma reunião que demora duas semanas para acontecer.
O custo é tempo, que neste tema é o recurso mais escasso. Piloto que passa de noventa dias perde a energia inicial e começa a competir com a rotina, e a rotina sempre ganha. O outro custo é a confiança do time, porque quem participou de um piloto que morreu sem explicação entra no seguinte com um pé atrás e com razão.
O conserto é escrever um nome, com autoridade para decidir dentro de um escopo definido e agenda protegida para isso. Não precisa ser gente sênior, precisa ser gente com mandato, com o gestor da área tendo dito em voz alta que aquele tempo está protegido. Vale combinar também o que o dono pode decidir sozinho e o que sobe, para a reunião quinzenal virar exceção. O detalhe está em piloto de IA sem dono.
4. Escolher o processo mais doloroso em vez do mais frequente
A liderança escolhe o processo que mais incomoda, geralmente aquele que já causou uma crise memorável. Costuma ser um processo complexo, de baixa frequência e alto custo de erro, exatamente o pior lugar para começar.
O custo é a ausência de prova. Seis meses depois não há caso para mostrar, o orçamento acabou, e o programa perde a chance de conquistar as pessoas com um ganho visível. A empresa conclui que IA é promessa, quando na verdade escolheu o alvo errado. Pior: o processo complexo costuma ter muita exceção e pouca regra escrita, então a primeira leva de resultados vem cheia de erro, o que alimenta a desconfiança de quem já era cético. O processo complexo continua na fila e merece atenção, só não como primeira aposta.
O conserto é trocar a ordem: comece pelo que acontece muitas vezes por semana e cujo erro alguém pega na revisão. O processo doloroso continua na fila, e chega nele com a operação treinada e a liderança confiante. É a mesma lógica de priorização que eu descrevo em casos de uso de IA por área.
5. Esperar o caso de uso perfeito
Este erro se disfarça de prudência. A empresa passa meses em estudo, mapeia quarenta oportunidades, monta matriz de priorização, contrata diagnóstico, e não coloca nada no ar. Sempre falta um dado, uma política ou uma opinião do jurídico.
O custo é o mais silencioso de todos, porque não aparece em lugar nenhum. Enquanto o comitê estuda, o concorrente aprende operando, e a distância que se abre não é de tecnologia, e sim de repertório: eles já sabem o que quebra, e você ainda não.
O conserto é aceitar um piloto pequeno e reversível, com escopo apertado e dado pouco sensível, rodando em trinta dias. Aprendizado real vale mais que estudo, e o estudo continua acontecendo em paralelo, agora com pergunta melhor, porque quem operou trinta dias sabe o que perguntar ao jurídico e ao time de dados. Um detalhe de condução ajuda muito: combine desde o início que o piloto pode ser desligado, e diga isso em voz alta. Projeto que não pode fracassar não pode ser testado, e é isso que trava a decisão de começar. Tratei disso em o erro de esperar o caso de uso perfeito.
Leia também
6. Deixar a média liderança de fora
O programa é desenhado entre a diretoria e um grupo técnico, e apresentado aos gerentes quando já está pronto. Eles recebem a novidade junto com a meta do trimestre, sem terem participado de nada, e passam a tratar aquilo como mais uma iniciativa que vai passar.
O custo é a morte lenta, e é o padrão mais comum de todos. O gerente não sabota, ele apenas não prioriza, e sem a priorização dele a equipe não muda a rotina. Seis meses depois o uso está concentrado em três entusiastas.
O conserto começa antes: coloque os gerentes no desenho, deixe que escolham o primeiro processo da área deles e resolva o conflito real que existe entre a meta atual e o tempo de aprender coisa nova. Sem tirar peso da agenda, nada acontece. Vale também dar a esse gerente o primeiro resultado para apresentar, porque reconhecimento move mais que comunicado interno, e ele passa a defender o programa por conta própria. Em empresa com muitos gerentes, começar por dois ou três voluntários funciona melhor que anunciar para todos ao mesmo tempo.
7. Tratar governança como fase dois
O piloto roda sem política de uso, sem definição do que pode ser colado em ferramenta externa, sem registro de quem aprovou o quê. A ideia é resolver isso depois que provar valor, o que soa razoável em reunião.
O custo aparece de duas formas. Uma é o incidente, que pode ser dado sensível em conta pessoal ou resposta errada chegando ao cliente. A outra é mais frequente e menos comentada: quando chega o questionário de segurança de um cliente grande, a empresa não tem o que responder e o negócio trava.
O conserto é leve no começo. Uma página de política, uma lista do que não entra em ferramenta nenhuma, e um registro simples de quem aprovou cada uso já resolvem a maior parte. Governança pesada mata piloto, e ausência de governança mata a escala. O teste prático é conseguir responder três perguntas: o que não pode entrar em ferramenta nenhuma, quem aprovou cada uso em produção e o que fazer quando a saída sair errada na frente do cliente. Se as três respostas existirem em uma página, a governança está no tamanho certo para esse estágio.
Leia também
8. Medir adoção em vez de resultado
O painel do programa mostra licenças ativas, número de conversas e percentual de gente treinada. Todos sobem, todo mundo comemora, e o resultado da empresa continua igual.
O custo é a decisão errada com dado bonito. A empresa amplia licença para mais áreas porque a adoção está alta, sem saber se algum processo ficou mais barato, mais rápido ou mais confiável. Quando o CFO pergunta o que voltou dos números, ninguém tem resposta e o orçamento seguinte encolhe.
O conserto é escolher, por processo, uma métrica que já existia antes da IA: horas gastas na tarefa, tempo de resposta ao cliente, custo por atendimento, taxa de retrabalho. Meça antes de começar, o que exige disciplina de duas semanas, e compare depois. Sem a medição anterior, qualquer número posterior vira opinião. Uma medição simples resolve: peça a três pessoas que anotem por duas semanas quanto tempo gastam naquela tarefa, e use essa média como linha de base. Não precisa de precisão contábil, precisa de comparabilidade: a mesma pergunta, feita do mesmo jeito, antes e depois. Esse número é o que sustenta a conversa de orçamento no ano seguinte.
9. Não desenhar a revisão humana
Existem duas versões deste erro, e as duas são caras. Na primeira, ninguém confere nada e o resultado sai direto para o cliente, o que funciona até o dia em que não funciona. Na segunda, tudo é conferido para sempre, com o mesmo rigor do primeiro dia, e o ganho de tempo desaparece dentro da revisão.
O custo da primeira versão é reputacional, e ele contamina até quem nunca usou a ferramenta, porque o time inteiro passa a duvidar da entrega. O custo da segunda é o abandono: as pessoas concluem que dá mais trabalho e voltam ao jeito antigo, geralmente sem avisar ninguém, o que faz o painel de adoção continuar bonito enquanto o uso real já acabou.
O conserto é tratar revisão como desenho, e não como boa vontade. Defina o que é conferido sempre, o que é conferido por amostragem e o que nunca sai sem assinatura de gente, e revise essa régua a cada trimestre com a taxa de erro na mão. Sobre qualidade de saída, a régua que funciona mede a taxa de erro que passa despercebido, e não a de acerto médio.
10. Não ter plano para o dia em que quem configurou sai
Uma pessoa montou tudo. Ela conhece os prompts, sabe quais integrações existem, lembra por que aquele passo foi feito daquele jeito e mantém as coisas de pé com ajustes que ninguém vê. Nada disso está escrito, porque ela sempre esteve por perto.
O custo chega junto com o aviso prévio. A operação continua funcionando por algumas semanas e depois começa a degradar em silêncio, com respostas piores e integrações quebradas que ninguém sabe consertar. Já vi empresa desligar um agente inteiro por não conseguir mantê-lo, jogando fora um ano de ajuste fino porque ninguém sabia mexer sem quebrar. E o risco cresce junto com o sucesso, porque quanto mais a operação depende daquilo, mais cara fica a ausência de documentação.
O conserto é banal e quase nunca é feito: documentar em uma página por agente o que ele faz, com qual acesso, quem é o dono e o que fazer quando ele erra. Vale também exigir que tudo viva em conta corporativa, e não pessoal. Sobre o vale entre piloto e operação, o texto completo está em por que projetos de IA travam no piloto.
Leia também
O mapa em uma tabela
| erro | estágio em que mata | sinal de alerta | conserto |
|---|---|---|---|
| Ferramenta antes do problema | decisão | licença comprada sem processo escolhido | escolher dois processos primeiro |
| Automatizar sem redesenhar | decisão | fluxo antigo intacto | perguntar quais passos cairiam hoje |
| Piloto sem dono | decisão | responsável é um grupo | nome com mandato e agenda |
| Processo doloroso em vez de frequente | decisão | alvo é a crise memorável | começar pelo volume com erro barato |
| Esperar o caso perfeito | decisão | terceiro mês de estudo | piloto pequeno e reversível em 30 dias |
| Média liderança de fora | piloto | gerente soube quando ficou pronto | gerente escolhe o processo da área |
| Governança como fase dois | piloto | nenhuma política escrita | uma página e uma lista de vetos |
| Adoção em vez de resultado | piloto | painel de licenças ativas | métrica que já existia antes |
| Revisão humana sem desenho | produção | tudo conferido, ou nada | régua por tipo de risco |
| Sem plano para a saída da pessoa | escala | tudo em conta pessoal | uma página por agente e conta corporativa |
Quando nenhum destes dez é o seu problema
Existem três situações em que nenhum dos dez explica o fracasso. A primeira é a empresa cujo gargalo real está nos dados, com sistema que não conversa e cadastro duplicado. Ali o projeto não morreu por gestão, morreu porque a informação necessária nunca existiu de forma utilizável, e a contratação certa é engenharia de dados.
A segunda é a operação em que o processo escolhido depende de julgamento denso, com muita exceção e pouca regra. Nesses casos o resultado fraco é diagnóstico correto, e não erro de condução. Vale registrar o aprendizado e mudar de alvo.
A terceira é a mais desconfortável: a empresa que não quer mudar. Quando a liderança pede resultado sem autorizar mexer em processo, em papéis e em rotina, o programa vai entregar a operação de antes com uma fatura nova. Chamar isso de erro de implementação é generoso demais. Trata-se de uma decisão estratégica tomada em silêncio, e ela precisa ser dita em voz alta antes de qualquer projeto começar.
A régua que eu deixo com o líder
Olhe a lista de novo e marque quantos dos dez estão presentes na sua empresa hoje. Se forem três ou mais, o próximo projeto tem chance grande de repetir o anterior, independentemente da ferramenta escolhida e do fornecedor contratado.
E repare na coluna do estágio: oito dos dez matam antes ou durante o piloto, ou seja, antes de a tecnologia ter qualquer chance de mostrar do que é capaz. É por isso que trocar de fornecedor raramente conserta um programa parado. O que conserta é escolher processo com critério, nomear dono, medir o que já era medido e decidir quem confere o quê. São quatro decisões de gestão, todas tomáveis nesta semana, e nenhuma delas depende de orçamento novo ou de fornecedor melhor.