Existe um padrão previsível: a demonstração impressiona, todo mundo aprova, e seis meses depois ninguém usa. A causa raramente está no modelo.
Escolher o caso: três filtros
O primeiro filtro é dor real e medida. Se ninguém consegue dizer quantas horas por semana a tarefa consome ou quantos erros ela gera, não há como demonstrar ganho — e sem ganho demonstrado não há continuidade.
O segundo é dono claro. Alguém que sofre com o problema, participa do desenho e vai usar o resultado. Projeto patrocinado só pela área de tecnologia morre quando a atenção muda.
O terceiro é verificabilidade rápida. Casos em que dá para saber em minutos se a saída está certa permitem iterar. Casos cujo acerto só se confirma meses depois não são bons pilotos, por melhores que sejam como oportunidade.
O que definir antes de começar
| Item | Pergunta a responder | Erro comum |
|---|---|---|
| Critério de sucesso | Que número justifica continuar? | Definir depois de ver o resultado |
| Linha de base | Como está hoje, medido? | Comparar com uma impressão |
| Conjunto de avaliação | Quais casos reais servem de prova? | Testar com exemplos escolhidos a dedo |
| Prazo | Quando decide seguir ou parar? | Piloto sem data de fim |
| Custo estimado em escala | Quanto custaria rodar para todos? | Descobrir isso depois da aprovação |
| Caminho para produção | Quem opera e onde roda? | Tratar como problema futuro |
O conjunto de avaliação é o coração
Trinta a cem casos reais, escolhidos sem seleção favorável, com o resultado esperado escrito por quem entende do assunto. Isso leva alguns dias e resolve a pergunta mais difícil do projeto: está bom o suficiente?
Sem esse conjunto, a avaliação vira demonstração — e demonstração seleciona os casos que funcionam. Com ele, dá para comparar modelos, medir o efeito de cada mudança e mostrar evolução com números em vez de entusiasmo.
Escopo: pequeno e completo
Piloto bom é estreito e vai até o fim. Automatizar um tipo de documento, de ponta a ponta, incluindo o que acontece quando falha, ensina mais do que um protótipo amplo que resolve metade de cinco problemas.
A razão é prática: os obstáculos que matam projetos aparecem na última etapa — integração, permissão, exceção, revisão, responsabilidade. Um piloto que para antes disso não testou o que precisava testar.
A conversa do dia seguinte
- Quem opera isso depois? Se a resposta for “a gente vê”, o projeto já tem data de validade.
- Quanto custa por mês em escala? Piloto com cem casos não revela o custo de cem mil.
- Onde entra no fluxo existente? Ferramenta separada do sistema que a pessoa já usa é abandonada.
- O que acontece quando erra? Precisa haver caminho de exceção antes de ir ao ar.
- Como saberemos que degradou? Monitoramento definido antes, não depois do primeiro incidente.
- Quem aprova a mudança de processo? A parte difícil quase sempre é organizacional.
Saber encerrar também é resultado
Um piloto que demonstra, com evidência, que a tecnologia ainda não resolve aquele caso entregou informação valiosa e economizou um projeto inteiro. O desperdício não é parar — é continuar por inércia, ou repetir a mesma tentativa em outra área sem ter registrado o que se aprendeu.
A diferença entre empresas que extraem valor de IA e as que colecionam pilotos costuma ser essa disciplina: caso escolhido por dor medida, critério definido antes, escopo estreito até o fim e decisão explícita de seguir ou encerrar na data combinada.