O piloto é o experimento mais valioso do projeto — e o mais arriscado de fazer errado. Errar no piloto é barato. Errar em produção, caro. A diferença está em como você estrutura o piloto: com critério de sucesso definido antes, escopo mínimo e humano no loop.
Fluxo de piloto — o critério de sucesso vem antes, não depois de ver os resultados.
🎯 Definir sucesso antes de começar
O critério de sucesso definido depois dos resultados é viés de confirmação garantido. A pergunta que o piloto responde precisa estar escrita antes de qualquer execução.
✓ Critério definido antes
- ✓"O modelo classifica com >85% de acurácia em 200 casos reais"
- ✓"Tempo médio de triagem cai de 4h para <60min"
- ✓Avaliado em 4 semanas com dados de produção
✗ Critério definido depois
- ✗"Achamos que ficou bem"
- ✗"O time adorou usar"
- ✗Sem número — sem decisão defensável
📝 Template de critério de sucesso
🔬 PoC vs. piloto vs. produção
Três estágios, três objetivos, três conjuntos de dados diferentes. Misturar os estágios é a origem de expectativas erradas que depois destroem o projeto.
Prova de Conceito — "isso é possível?"
Dados de laboratório, sem integração real, sem usuários reais. Responde se a tecnologia consegue resolver o problema em condições ideais.
Duração: 1-2 semanas. Resultado: viável / inviável tecnicamente.
Piloto — "isso funciona aqui?"
Dados reais, usuários reais, mas escopo e volume controlados. Responde se a solução funciona neste contexto operacional específico.
Duração: 4-8 semanas. Resultado: evidência para go/no-go.
Produção — "escalar com confiança"
Volume completo, SLA definido, monitoramento em produção. Piloto validou que funciona — agora escala.
Pré-requisito: piloto com go aprovado. SLA e runbook documentados.
💡 Dica prática
Quando apresentar o PoC ao cliente, deixe claro: "Isso demonstra que a tecnologia consegue fazer — mas ainda não testamos com seus dados reais e seus usuários. O piloto faz isso." Gerencia expectativas antes que virem decepções.
🔭 Escopo mínimo que ensina
O piloto ideal é o menor experimento que responde à pergunta mais importante. Não o mais completo, não o mais impressionante — o mais inteligente.
✓ Escopo mínimo que ensina
- ✓Uma categoria de tickets (não todas as 12)
- ✓Um departamento piloto (não toda a empresa)
- ✓200 casos reais (não 50.000)
- ✓Integração manual OK (automação vem depois)
✗ Escopo inflado
- ✗Construir toda a integração antes de validar o modelo
- ✗Cobrir todos os casos de uso no piloto
- ✗Piloto de 6 meses que não tem data de decisão
💡 Pergunta-teste do escopo
Antes de planejar o piloto, pergunte: "Qual é a pergunta que mais importa?" Então: "Qual é o menor experimento que responde essa pergunta?" Tudo que não responde essa pergunta está fora do escopo do piloto.
👤 Humano no loop + plano de falha
Durante o piloto, toda saída da IA passa por revisão humana. Isso não é ineficiência — é o mecanismo que captura os erros antes do cliente final e alimenta os dados para melhoria.
🔄 Estrutura do humano no loop
IA processa
gera saída com confiança
Humano revisa
aprova, corrige ou rejeita
Dado registrado
erros viram dados de melhoria
🚨 Plano de falha — obrigatório
O plano de falha define o que acontece quando a IA errar ou ficar indisponível:
- →Quem reverte: responsável identificado por nome, não por cargo
- →Em quanto tempo: SLA de reversão (ex: dentro de 2h)
- →Como a operação continua: processo manual temporário documentado
- →Quando acionar: critério claro (ex: taxa de erro >10% por 1h)
📊 Medir vs. linha de base
A comparação antes/depois é o único argumento que transforma percepção em evidência. A métrica precisa ser definida com a mesma definição da linha de base — senão estamos comparando coisas diferentes.
📐 Regras para uma comparação válida
Se a baseline mediu "tempo médio de triagem por ticket", o piloto mede a mesma coisa — não "tempo total de triagem do dia".
Medir em semanas comparáveis (mesmo volume, mesma sazonalidade). Evitar comparar segunda-feira da baseline com sexta do piloto.
Isolar o que mudou por causa da IA vs. o que mudou por outras razões (equipe diferente, volume diferente, treinamento).
📊 O que documentar no relatório do piloto
🚦 Critérios go/no-go: escalar ou matar
Go/no-go é a decisão mais importante do processo. O critério foi atingido? Go: escala com o que aprendeu. Não foi? No-go: mata ou pivota — sem culpa, com dados, com próximos passos claros.
🟢 GO — critérios atingidos
Próximos passos ao decidir GO:
- • Atualizar o roadmap com o que o piloto ensinou
- • Documentar capacidades reutilizáveis geradas
- • Definir SLA e runbook para produção
- • Comunicar resultado ao sponsor com os dados
- • Planejar a Wave 2 com escopo expandido
🔴 NO-GO — critérios não atingidos
Próximos passos ao decidir NO-GO:
- • Documentar por que não funcionou (dados? tecnologia? processo?)
- • Avaliar se há pivot viável (escopo menor? nível diferente?)
- • Cancelar formalmente o projeto se não há pivot
- • Registrar aprendizados para os próximos pilotos
- • Comunicar ao sponsor: "matar foi a decisão certa"
💡 Por que matar é sucesso
Um piloto que termina em no-go e é cancelado entregou exatamente o que deveria: a resposta "não faça isso" antes de gastar 10× mais em produção. Isso protege o orçamento, preserva a confiança e libera a equipe para o próximo caso mais promissor. O consultor que consegue encerrar um projeto que não funciona é mais valioso do que o que deixa continuar por inércia.
🎒 Resumo do módulo
Próxima trilha:
T5 — Entrega & Negócio da consultoria