horia Falar com a Horia

Por que projetos de IA param depois do piloto (e como evitar)

Um piloto de IA costuma parar depois da prova de conceito por quatro motivos: não tinha meta medida, não tinha dono no negócio, era uma ferramenta solta fora do processo e não estava integrado aos sistemas. Para evitar, o piloto precisa nascer com meta, dono, processo real e plano de operação definidos antes de começar.

Por Eduardo Vieira · · 5 min de leitura

O piloto de IA funciona, a demonstração impressiona, todo mundo concorda que "tem potencial". E três meses depois ninguém usa. Já vi esse filme muitas vezes, e o motivo quase nunca é o modelo de IA.

Não é um problema raro. O Gartner previu em 2024 que 30% dos projetos de IA generativa seriam abandonados após a prova de conceito até o fim de 2025. Neste artigo, explico as causas que vejo na prática e o que faço para que o piloto vire operação.

O que é um piloto de IA, e o que ele não é?

Um piloto de IA é um teste com prazo, em um processo real, com usuários reais e uma meta medida, feito para decidir se a solução entra em operação. A palavra-chave é decidir.

Uma prova de conceito mostra que algo é possível. Um piloto mostra se vale a pena. A diferença parece sutil, mas muda tudo:

Prova de conceitoPiloto
PerguntaDá para fazer?Vale a pena colocar em operação?
DadosExemplos escolhidosDados reais do dia a dia
UsuáriosQuem construiuQuem vai usar todo dia
ResultadoDemonstraçãoNúmero comparado com a linha de base
FimAbertoData marcada e decisão: seguir, ajustar ou parar

Muitos projetos param porque nunca saíram da coluna da esquerda. Chamaram de piloto o que era só demonstração.

Quais são as causas mais comuns?

Quatro causas respondem pela maioria dos pilotos que morrem. Quase sempre aparecem juntas.

1. Não tinha meta medida

Sem meta, o fim do piloto vira uma conversa de opinião. Alguém acha que ficou bom, outro acha que não mudou nada, e a decisão empurra para o próximo trimestre.

A meta precisa de três coisas: o indicador, a linha de base de hoje e o alvo. Um exemplo: "tempo para responder uma cotação, hoje em dois dias, alvo de meio dia". Sem a linha de base medida antes, não há como provar ganho depois.

Vale também combinar uma meta de qualidade, não só de velocidade. Responder mais rápido com mais erro não é ganho. Por isso costumo acompanhar dois números juntos: o tempo do processo e a taxa de retrabalho, ou seja, quantas entregas do agente precisaram ser corrigidas pela pessoa antes de seguir. Os dois precisam melhorar, ou pelo menos o segundo não pode piorar.

2. Não tinha dono no negócio

Quando o piloto é da TI ou do "time de inovação", e não da área que usa, ele não sobrevive. A área tem suas metas e sua rotina. Se ninguém dela responde pelo resultado, o agente vira tarefa extra.

O dono precisa ser alguém com autoridade sobre o processo: o gerente de compras, a coordenadora do financeiro, o diretor comercial. É essa pessoa que decide no fim.

3. Era uma ferramenta solta

Dar acesso a uma ferramenta de IA e esperar que a equipe descubra o uso não é um piloto. É uma aposta. Algumas pessoas vão usar muito, a maioria vai esquecer em duas semanas.

O piloto que vira operação mexe em um processo específico: entra um pedido, o agente faz uma parte definida, a pessoa confere, o resultado sai. O uso não depende de lembrar de abrir a ferramenta.

4. Não estava integrado

Se o agente obriga a pessoa a copiar dados de um sistema, colar na IA e copiar a resposta de volta, o ganho some no trabalho manual. A equipe volta para o jeito antigo.

No piloto, a integração pode ser simples: ler de uma pasta, escrever em uma planilha, mandar por e-mail. Mas ela precisa existir, e o plano para integrar com o sistema principal precisa estar escrito.

Como montar um piloto de IA que vira operação?

O roteiro que uso tem seis passos, e os três primeiros acontecem antes de construir qualquer coisa.

  1. Escolher um processo com volume e dor. Repetitivo, com regra clara e com gente reclamando dele. Escrevi sobre isso em 10 usos práticos de IA nas empresas.
  2. Medir a linha de base. Quanto tempo leva hoje, quantos erros, quantos pedidos por semana.
  3. Definir dono, meta e data de decisão. Por escrito, com o critério de "seguir, ajustar ou parar".
  4. Construir no fluxo real. O agente recebe o que a equipe já recebe e entrega onde ela já trabalha.
  5. Acompanhar toda semana. Quinze minutos com o dono: o que o agente acertou, onde errou, o que mudou na regra.
  6. Decidir na data. Comparar com a linha de base e tomar a decisão combinada. Parar também é um bom resultado, se for por dado.

O que precisa estar pronto para sair do piloto?

Sair do piloto exige mais do que um bom número. Antes de chamar de operação, confiro esta lista:

  • Quem cuida do agente no dia a dia e quem atende quando ele erra.
  • Como as regras são atualizadas quando a política da empresa muda.
  • Onde ficam os registros de cada ação e aprovação.
  • Qual o custo mensal de uso e quem paga.
  • Como os novos funcionários aprendem a trabalhar com o agente.

Se essas respostas não existem, o piloto até dá certo, mas a operação se desfaz no primeiro problema. A pessoa que construiu sai do projeto, uma regra muda, e ninguém sabe ajustar.

Sinais de que seu piloto está indo para a gaveta

Alguns sinais aparecem cedo e dá tempo de corrigir:

  • As reuniões de acompanhamento são remarcadas.
  • O número de pedidos que passam pelo agente cai semana a semana.
  • A equipe pede "mais uma funcionalidade" antes de usar a que existe.
  • Ninguém sabe dizer qual era a meta.

Quando vejo dois desses sinais, paro e volto ao passo três: dono, meta e data. Quase sempre o problema está ali.

Um piloto de IA bem feito é curto, medido e tem dono. Na Horia, o piloto tem 90 dias e começa com a linha de base medida, porque é ela que transforma uma boa demonstração em decisão.

Perguntas frequentes

Quanto tempo deve durar um piloto de IA?

O suficiente para ter volume real de uso e comparar com a linha de base, sem virar projeto sem fim. Para processos administrativos, algo entre 60 e 90 dias costuma bastar. O importante é a data de decisão estar marcada desde o início.

Qual a diferença entre prova de conceito e piloto?

A prova de conceito mostra que a solução é possível, normalmente com dados escolhidos. O piloto roda no processo real, com usuários reais, e mede o resultado contra a situação anterior para decidir se a solução vai para a operação.

Quem deve ser o dono de um piloto de IA?

Alguém da área que usa o processo e tem autoridade sobre ele, não só a TI. Essa pessoa define a meta, acompanha o uso e toma a decisão no fim do piloto.

O que fazer quando o piloto não atinge a meta?

Primeiro, entender por quê: regra mal definida, dados ruins, falta de uso ou processo errado. Se o ajuste for claro, vale um ciclo curto de correção. Se não, parar com base em dados é um resultado válido e evita gastar com algo que não funciona.

Eduardo Vieira · Eduardo Vieira é sócio da Horia. Conduz a implantação de agentes de IA dentro da operação das empresas: escolha do processo, construção, integração com os sistemas e medição do resultado. Outros artigos

Quer olhar isso na sua operação? Converse 45 minutos com a gente, sem custo →