Consultoria em inteligência artificial: o que dá errado

Quase todo projeto de IA que fracassa produz um laudo técnico inconclusivo, e isso não é acaso. A causa costuma estar longe do modelo, do fornecedor e da integração: ela foi decidida em reunião, meses antes, quando alguém escolheu o caso de uso que demonstrava bem, aceitou um dado que existe mas não é utilizável, manteve o processo antigo de pé e definiu que o sucesso seria medido por acesso. O que segue é o catálogo dos modos de falha que se repetem em projeto de consultoria em inteligência artificial, cada um com o sintoma que o denuncia enquanto ainda dá para corrigir.

Quem procura o método completo — diagnóstico, arquitetura de dado, governança, medição de retorno — encontra em consultoria de inteligência artificial. Este texto olha para o avesso dele, que é a parte menos confortável de escrever. O que vem abaixo é opinião, formada em sala de projeto e não em pesquisa de mercado: nenhum desses modos é exótico, todos são previsíveis, e quase todos são decisões adiadas que reaparecem disfarçadas de falha técnica meses depois.

O caso de uso escolhido para demonstrar não é o caso de uso que importa

O primeiro erro acontece na escolha, e é sedutor porque parece prudência. Diante de uma lista de candidatos, o time escolhe aquele que roda rápido, tem dado limpo e cabe em uma tela de apresentação — geração de texto de marketing, resumo de reunião, rascunho de e-mail. Nenhum deles é inútil. O problema é que nenhum deles estava na lista de dores que motivou o projeto, e o retorno de resolver algo que ninguém sentia é, por definição, imperceptível.

O sintoma denuncia isso na primeira semana: o caso de uso escolhido caberia sem alteração em qualquer empresa do mesmo setor. Dor real é específica. Se o piloto poderia ser copiado e colado para um concorrente sem trocar uma linha, ele não está tocando aquilo que só existe dentro daquela operação — que é exatamente onde a vantagem estaria.

A ferramenta comprada antes do diagnóstico já escolheu o problema

Quando a licença corporativa chega antes do mapa de processos, a ordem do trabalho se inverte de forma difícil de desfazer. A pergunta deixa de ser “o que dói aqui” e passa a ser “o que dá para fazer com o que já compramos”. A partir daí, o roadmap do projeto vira a lista de funcionalidades do fornecedor, e o critério de sucesso vira justificar a compra. Existe agora um custo afundado defendendo cada decisão ruim, e ele tem procuradores dentro da empresa.

Dá para perceber cedo pelo vocabulário das reuniões. Quando a discussão de escopo é conduzida em nomes de módulos e planos de assinatura, e não em etapas de processo com tempo e custo, a ferramenta já ocupou o lugar do diagnóstico. O contraste é direto: um projeto bem colocado consegue descrever o resultado esperado sem citar o nome de nenhum produto.

Dado que existe e dado utilizável são coisas diferentes

Toda empresa tem dado. O que falta quase sempre são três atributos que ninguém cobra na fase de entusiasmo: dono, padrão e lugar único. Sem dono, não há quem decida qual versão vale. Sem padrão, o mesmo campo significa uma coisa no comercial e outra na operação, e ninguém registrou a diferença. Sem lugar único, o sistema vai aprender com a cópia que alguém esqueceu de atualizar. O projeto não trava porque o dado não existe; trava porque esse dado não sustenta uma resposta que alguém assine embaixo.

O agravante é que a fragilidade não aparece na tela. O sistema entrega a versão obsoleta com a mesma segurança da vigente, e é por isso que boa parte do que se chama de alucinação dentro da empresa é, na verdade, acervo contraditório sendo cobrado com atraso — sobretudo quando o desenho depende de recuperação de contexto na base interna. O sintoma é uma pergunta simples que quase nunca é feita a tempo: quem é o dono deste dado? Se a resposta for o nome de um sistema, e não o de uma pessoa, existe um problema anterior a qualquer IA.

O piloto não vira produção porque nunca foi desenhado para sair dele

O piloto que morre bem-sucedido é o modo de falha mais caro, porque consome orçamento, credibilidade e paciência antes de revelar que não levava a lugar nenhum. Ele acontece quando o teste foi construído para provar que a tecnologia funciona, e não para responder às perguntas que produção exige: quem opera isso na segunda-feira, o que acontece com o caso atípico, qual sistema recebe a saída, quem responde quando o resultado sai errado e chega ao cliente.

Nenhuma dessas perguntas é técnica, e todas custam decisão política. Por isso são adiadas — e o piloto termina em um relatório que recomenda “expandir”, sem que ninguém consiga dizer para onde. O sintoma aparece antes do primeiro teste: se, ao desenhar o piloto, não existir um nome de pessoa associado à operação futura do processo, o que está sendo financiado é uma prova de conceito com data de validade.

A adoção morre quando o processo antigo continua de pé ao lado

Este é o modo de falha mais silencioso. A ferramenta entra, o time usa com entusiasmo por algumas semanas, o uso decai e ninguém consegue explicar por quê. A explicação costuma ser simples: o processo em volta não mudou. A pessoa gera o rascunho com a IA e depois preenche o mesmo formulário, aciona a mesma aprovação e refaz a mesma conferência de antes. Ela não ganhou tempo; ganhou uma etapa a mais. Abandonar é a decisão racional.

Automatizar uma parte de um fluxo sem redesenhar o restante produz trabalho duplo disfarçado de inovação. O sintoma é observável em qualquer acompanhamento honesto: pergunte a quem usa o que ela deixou de fazer desde que a ferramenta chegou. Se a resposta for “nada, só ficou mais rápido escrever”, o processo continua inteiro e o ganho vai evaporar assim que a novidade passar.

Medir uso é medir a si mesmo

Painel de adoção é confortável porque sempre tem número para mostrar: usuários ativos, sessões, mensagens trocadas, licenças ocupadas. Nada disso é resultado. São métricas que descrevem o esforço do próprio projeto — quanta gente foi treinada, quanta gente entrou — e não o efeito dele sobre quem paga a conta. É perfeitamente possível exibir uso crescente por meses seguidos sem que uma única linha de custo, prazo ou qualidade tenha se mexido.

O modo de falha não é olhar essa métrica; é olhar só para ela, porque ela nunca desmente ninguém. Adoção só desaba quando o projeto já morreu, e a essa altura não há mais o que corrigir. O sintoma está no slide de abertura da primeira reunião de acompanhamento: quem tem efeito no processo abre por ele; quem não tem, abre por adoção. E confirma-se na conversa lateral — se ninguém consegue nomear qual indicador do processo era acompanhado antes de o projeto começar, não existe linha de base, e sem linha de base não haverá prova nenhuma no fim.

Quem segura o prompt e o dado segura o processo

Há um arranjo comercial comum em que o fornecedor entrega a saída, mas retém o meio: os prompts, as regras de recuperação, os critérios de classificação, os logs de decisão e o dado tratado que alimenta tudo. Funciona bem enquanto a relação vai bem. No dia em que o preço sobe, a qualidade cai ou o time do fornecedor muda, a empresa descobre que trocar de parceiro significa refazer o projeto inteiro — e renova em condições ruins porque a alternativa é pior.

Isso raramente é má-fé; é o desenho seguindo o incentivo de quem vende, e cabe ao contratante enxergá-lo enquanto ainda tem poder de barganha. O sintoma é fácil de provocar sem constranger ninguém: peça, no meio do contrato, a exportação dos prompts, das regras e dos registros de decisão. O tempo de resposta a esse pedido — e a naturalidade dele — diz mais sobre o risco de dependência do que qualquer cláusula. Os critérios que evitam cair nesse arranjo já na seleção estão em empresa especialista em inteligência artificial.

O comitê que decide tudo é o lugar onde nada é decidido

Quando o assunto ganha visibilidade de diretoria, a resposta organizacional padrão é criar um fórum com todas as áreas envolvidas. A intenção é boa e o efeito é previsível: com dez cadeiras à mesa e nenhum dono nomeado, cada decisão vira alinhamento, cada alinhamento vira nova pauta, e o projeto avança na velocidade da agenda mais cheia. O colegiado não é o problema — a ausência de um responsável por decisão pendente é.

O sintoma é documental e inequívoco: o mesmo item reaparece na ata de reuniões seguidas com redação levemente diferente, sinal de que ninguém presente tem autoridade para encerrá-lo. A correção não é técnica nem cara: atribuir um nome e um prazo a cada pendência, e reservar a mesa cheia para o que de fato a exige — risco, dado sensível e exposição ao cliente.

A expectativa é calibrada por uma demonstração ensaiada

O último modo de falha é de expectativa, e contamina todos os outros. Uma demonstração é um espetáculo bem ensaiado: caso escolhido a dedo, base preparada, operador que conhece o caminho feliz e nenhuma pergunta fora do roteiro. Ela é honesta sobre o que a tecnologia consegue fazer quando tudo colabora, e silenciosa sobre a frequência com que tudo colabora. A diretoria sai da sala com um número na cabeça, e é contra esse número que o projeto será julgado depois, ainda que ninguém tenha prometido nada por escrito.

A distância aumenta quando a arquitetura encadeia vários passos, porque o erro de cada etapa se compõe ao longo da cadeia: uma sequência de acertos razoáveis produz um resultado final ruim. O sintoma é de bastidor e está na pergunta que ninguém fez depois da apresentação. Se ninguém quis saber quantas tentativas foram necessárias para gravar aquela demonstração, nem o que acontece quando a entrada chega fora do formato previsto, a expectativa já está calibrada num lugar que a operação não alcança.

O padrão por trás de todos eles

Reunidos, esses nove modos têm um denominador comum, e ele não é tecnológico. Todos são decisões que alguém precisava tomar e não tomou: quem é o dono, o que se mede, o que muda no processo, o que se aceita como risco, o que é entregável da empresa. A IA apenas fez essa dívida vencer mais rápido, porque expôs em semanas uma desorganização que antes se acomodava em anos de planilha. Projeto de IA não morre no deploy — morre na primeira reunião, e leva meses para alguém perceber.

Daí sai a recomendação que atravessa a lista inteira: antes de discutir modelo, plataforma ou fornecedor, escreva as respostas dessas cinco perguntas em uma página e circule entre quem decide. Se a página não fechar, o problema não é de inteligência artificial, e nenhuma tecnologia vai resolvê-lo por ninguém.

---

Se você reconheceu mais de dois desses sintomas em um projeto em andamento, o defeito provavelmente está no desenho, e trocar de tecnologia não vai encostar nele. É essa conversa que costumo conduzir primeiro, apoiado no BrainPilot para organizar diagnóstico e implantação: começa pelo processo que dói e por quem é dono do quê, não pela ferramenta que se pretende comprar. O caminho mais curto é o contato.