Inteligência artificial nas empresas produziu duas realidades ao mesmo tempo: um punhado de casos que mudaram números de verdade e uma quantidade muito maior de pilotos que terminaram em apresentação. A diferença entre os dois grupos quase nunca é a tecnologia, e é aí que está a informação útil.
Este texto mostra onde a IA está de fato sendo usada, os cinco motivos pelos quais os projetos param, o que separa quem consegue de quem não consegue, os sinais de falha antes da falha e como recuperar um projeto travado.
Onde ela está sendo usada
Separar o que está em produção do que está em piloto muda a conversa:
| Em produção, funcionando | Parado em piloto |
|---|---|
| respostas para as perguntas que mais repetem | substituir o atendimento inteiro |
| triagem e classificação do que chega | previsão com pouco histórico |
| extração de campos de documento | assistente interno que ninguém usa |
| primeira versão de texto revisada por gente | geração de conteúdo em volume, sem revisão |
| apoio ao atendente, com resposta sugerida | painel com indicador gerado por IA |
A coluna da esquerda tem uma propriedade em comum: existe um jeito de saber se o resultado está certo, e alguém confere. A da direita depende de julgamento humano que o sistema não tem, ou de dado que a empresa não acumulou. Os casos concretos da coluna da esquerda estão em exemplos de inteligência artificial.
Os cinco motivos pelos quais falha
- Começou pela ferramenta, não pelo problema. A pergunta foi “qual IA usar” em vez de “qual tarefa repete e tem resultado conferível”. O resultado é assinatura contratada, piloto rodando e nenhuma decisão de negócio afetada.
- Não existia baseline. Ninguém mediu quanto o processo levava antes, então não há como comprovar ganho. O projeto entrega e não consegue provar que entregou, o que é indistinguível de não entregar.
- O material da casa não estava escrito. Política, procedimento e resposta boa viviam na cabeça das pessoas. Sem fonte, o sistema responde pelo que o modelo viu na internet, erra com confiança e perde a confiança do time.
- Faltou integração. A ferramenta explica e não resolve, porque não consulta pedido, agenda ou fatura. Nesse formato ela sempre acaba transferindo para um humano, e o custo de atendimento não cai.
- Ninguém do lado de dentro tinha tempo. É o motivo mais comum e o menos citado nas retrospectivas: decisão sobre prioridade, revisão de resultado e correção de instrução exigem alguém disponível toda semana, com autoridade.
Nenhum dos cinco é resolvido trocando de modelo ou de fornecedor, e é por isso que o segundo piloto costuma falhar pelo mesmo motivo que o primeiro.
O que separa quem consegue
| Quem consegue | Quem não consegue | |
|---|---|---|
| Ponto de partida | uma tarefa específica que repete | uma iniciativa de transformação |
| Métrica | definida antes, com número do antes | avaliada depois, por percepção |
| Escopo | uma área, um caso de uso | toda a empresa ao mesmo tempo |
| Dono | uma pessoa com tempo reservado | um comitê que se reúne por mês |
| Material | escrito e acessível ao sistema | na cabeça de quem trabalha há anos |
| Fim do piloto | entra em uso ou é descartado com motivo | fica em espera indefinida |
A coluna do meio não exige orçamento maior. Exige escolha menor, o que é uma decisão de gestão e não de tecnologia. A decisão de comprar, ajustar ou construir vem depois dessa, e está em inteligência artificial para empresas.
Os sinais antes da falha
- Ninguém consegue dizer qual número vai mudar. Se a resposta é “vamos ganhar eficiência”, o projeto já está sem alvo.
- O piloto está no terceiro mês sem entrar em uso real. Piloto que não vira rotina não acumula aprendizado nenhum.
- Só uma pessoa usa, e é quem defendeu a compra.
- A demonstração é sempre com o mesmo exemplo, que funciona bem e não representa o dia a dia.
- A conversa virou sobre o modelo em vez de sobre a tarefa.
- O fornecedor apresenta o resultado, e não a sua equipe.
Como recuperar um projeto parado
- Reduza o escopo até caber em uma tarefa. Uma, específica, com volume alto. Recortar é o movimento que salva projeto travado.
- Meça o antes agora, mesmo que atrasado. Duas semanas de medição valem mais que seis meses de piloto sem número.
- Escreva o material da casa para aquela tarefa. Se o assunto é atendimento, as vinte perguntas mais frequentes com a resposta boa, em documento.
- Coloque em uso com pouca gente, mas em uso de verdade, com conferência.
- Defina uma data de decisão, em quatro semanas: entra em uso, muda de recorte, ou é descartado com motivo escrito.
Esse quinto passo é o que mais falta. Projeto sem data de decisão não fracassa: ele fica, consumindo assinatura e credibilidade, e envenena a próxima tentativa dentro da empresa.
O que precisa existir antes de começar
- Uma tarefa repetitiva com resultado conferível, escolhida e cronometrada.
- Material escrito sobre aquela tarefa, ainda que curto.
- Uma pessoa responsável, com horas reservadas na agenda e autoridade para priorizar.
- Acesso ao sistema onde o dado da tarefa mora.
- Uma regra de conferência, dizendo o que passa por revisão humana antes de valer.
- Cuidado com dado pessoal definido, porque arrumar isso depois é retrabalho.
Faltando qualquer um dos seis, o mais barato é resolver a falta antes de contratar ferramenta. Os usos que costumam se encaixar nesses requisitos, por área, estão em IA na pequena empresa, e os casos que exigem executar ação e não só responder, em agentes de IA.
O único indicador que importa no começo
Tempo da tarefa, medido antes e depois. Não satisfação, não percentual de automação, não número de interações: tempo, na mesma tarefa, comparado com o número que existia antes.
Ele é o único que não dá para maquiar, que qualquer pessoa da empresa entende, e que dá para medir em duas semanas. Quando ele cai e se mantém caindo, o projeto existe, e aí vale montar a conta completa de retorno, em como calcular ROI.
Fica uma observação sobre o pano de fundo: nada nesta lista é urgente por causa da tecnologia. O que se acumula com o tempo é o histórico de uso, e é ele que faz a diferença entre empresas crescer, como está em vantagem competitiva e em futuro da inteligência artificial. Empresa que fecha um ciclo pequeno por trimestre está em posição muito melhor que a que planeja um projeto grande por ano. E quando o que foi construído passa a resolver problema que outras empresas também têm, vale critérios para saber se uma ferramenta interna tem potencial de produto.
Perguntas frequentes
Onde a inteligência artificial já funciona nas empresas?
Em produção funcionam respostas para as perguntas que mais repetem, triagem e classificação do que chega, extração de campos de documento, primeira versão de texto revisada por gente e apoio ao atendente com resposta sugerida. Todos têm a mesma propriedade: existe um jeito de saber se o resultado está certo e alguém confere antes de valer.
Que projetos de IA costumam ficar parados em piloto?
Substituir o atendimento inteiro, previsão com pouco histórico, assistente interno que ninguém usa, geração de conteúdo em volume sem revisão e painel com indicador gerado por IA. Eles dependem de julgamento humano que o sistema não tem, ou de dado que a empresa nunca acumulou, e por isso não conseguem sair da demonstração.
Por que os projetos de IA falham nas empresas?
Por cinco motivos, e nenhum é técnico. Começou pela ferramenta e não pelo problema. Não existia baseline, então não há como comprovar ganho. O material da casa não estava escrito, e sem fonte o sistema erra com confiança. Faltou integração, então a ferramenta explica e não resolve. E ninguém do lado de dentro tinha tempo, que é o motivo mais comum e o menos citado.
O que separa as empresas que conseguem resultado com IA?
Começam por uma tarefa específica que repete, e não por uma iniciativa de transformação. Definem a métrica antes, com o número do antes. Mantêm escopo de uma área e um caso de uso. Têm um dono com tempo reservado, e não um comitê mensal. Têm o material escrito e acessível ao sistema. E encerram o piloto entrando em uso ou descartando com motivo, em vez de deixá-lo em espera.
Quais os sinais de que um projeto de IA vai falhar?
Ninguém consegue dizer qual número vai mudar. O piloto está no terceiro mês sem entrar em uso real. Só uma pessoa usa, e é quem defendeu a compra. A demonstração é sempre com o mesmo exemplo, que não representa o dia a dia. A conversa virou sobre o modelo em vez da tarefa. E o fornecedor apresenta o resultado, em lugar da sua equipe.
Como recuperar um projeto de IA parado?
Reduza o escopo até caber em uma tarefa específica com volume alto. Meça o antes agora, mesmo atrasado, porque duas semanas de medição valem mais que seis meses de piloto sem número. Escreva o material da casa para aquela tarefa. Coloque em uso com pouca gente, mas em uso de verdade. E defina uma data de decisão em quatro semanas: entra em uso, muda de recorte ou é descartado com motivo escrito.
O que precisa existir antes de contratar uma ferramenta de IA?
Seis coisas: uma tarefa repetitiva com resultado conferível, escolhida e cronometrada; material escrito sobre aquela tarefa, ainda que curto; uma pessoa responsável com horas reservadas e autoridade; acesso ao sistema onde o dado mora; uma regra de conferência dizendo o que passa por revisão humana; e o cuidado com dado pessoal definido. Faltando qualquer uma, é mais barato resolver a falta antes.
Qual indicador acompanhar no começo de um projeto de IA?
Tempo da tarefa, medido antes e depois. Não satisfação, não percentual de automação, não número de interações. É o único que não dá para maquiar, que qualquer pessoa da empresa entende e que se mede em duas semanas. Quando ele cai e se mantém caindo, o projeto existe, e só então vale montar a conta completa de retorno.
Por que o segundo piloto de IA falha pelo mesmo motivo?
Porque a causa não estava no modelo nem no fornecedor, e trocar os dois não muda nada. Sem baseline, sem material escrito, sem integração e sem alguém com tempo, o segundo projeto reproduz o primeiro com outra marca no contrato. A conclusão errada que fica na empresa é que IA não serve para o negócio, quando o que faltou foi recorte e disponibilidade interna.
Projeto grande ou vários pequenos?
Vários pequenos, com data de decisão em cada um. Projeto grande concentra risco, demora a mostrar resultado e costuma terminar em apresentação. Empresa que fecha um ciclo pequeno por trimestre acumula histórico de uso e aprendizado, e fica em posição muito melhor que a que planeja um projeto grande por ano. O que se acumula com o tempo é o histórico, não a tecnologia.
