Resposta direta
Avaliar proposta de IA exige seis filtros antes do piloto: dono da decisão identificado, custo de erro mapeado, estratégia de dado clara, orçamento agêntico definido, eval acordada antes do início e plano de sunset escrito.
A maioria dos pilotos de IA não vira produção. Pesquisa do MIT NANDA sobre adoção corporativa de GenAI estimou que apenas 5% dos projetos passam da fase exploratória pra geração consistente de valor, e a barreira não é tecnologia, é desenho. Pilotos que viram post de LinkedIn em vez de produção compartilham um padrão: começam sem critério explícito do que conta como sucesso, sem dono da decisão e sem plano pra desligar quando não funcionar. Esse texto entrega seis filtros pra aplicar antes de aprovar piloto.
Filtro 1: Quem é o dono da decisão
Não o dono do projeto técnico. O dono da decisão. A pergunta que precisa estar respondida antes do piloto: quem define o que conta como output certo, qual o threshold de quando o sistema escala pra humano em vez de seguir sozinho, e quem audita se as decisões automatizadas continuam batendo com a realidade ao longo do tempo.
Pilotos sem dono identificado terminam em duas formas conhecidas. A primeira é morte por consenso: três áreas opinam, ninguém decide, o piloto roda sem critério até o orçamento acabar. A segunda é descoberta tardia: três meses depois alguém pergunta "quem aprovou esse threshold?" e descobre que ninguém aprovou, o threshold foi escolhido pelo cientista de dados que tinha o teclado.
O Translator é tipicamente quem faz essa pergunta na sala de kickoff. Engenheiro responde "configuro o sistema". Produto responde "defino UX". Negócio responde "quero o resultado". Falta o nome de quem assume a decisão sobre o que é certo. Se a pergunta não tem resposta clara, o piloto não está pronto pra começar.
Filtro 2: Qual o custo de erro
Custo de erro determina o nível de instrumentação necessária. Output que vira rascunho interno tem custo baixo; uma alucinação a cada 100 saídas é tolerável e barato de revisar. Output que influencia decisão de cliente, decisão executiva ou ação regulada tem custo alto; alucinação tolerável é zero, e o desenho precisa garantir isso por estrutura.
Pra cada caso de uso, três perguntas:
- Qual a consequência se o output estiver errado e ninguém perceber?
- Quanto tempo até a equipe descobrir o erro depois que aconteceu?
- Quanto custa corrigir, reverter, comunicar e mitigar quando descobrir?
Custo de erro alto exige verificação humana proporcional, eval com fact-checking, guardrails de domínio e processo de auditoria periódica. Esse custo precisa entrar no business case, não aparecer como surpresa três meses depois.
Filtro 3: Qual a estratégia de dado
Caso de uso que precisa de conhecimento da empresa exige fundação de dado: inventário de fonte, parser confiável, governança de acesso, atualização. Empresa que entra em RAG sem essa fundação rebobina o projeto em três meses.
A pergunta-chave é uma só: o dado que vai alimentar a IA está disponível, atualizado, com qualidade conhecida e permissão de uso definida? Se a resposta envolve "vamos extrair de PDF mal escaneado", "está só no email do diretor" ou "preciso pedir pro time de governança", o piloto está sendo aprovado em cima de fundação que não existe.
Particularmente em RAG, a qualidade do parser determina a qualidade da resposta. Parser que perde tabela, lista ou estrutura entrega lixo pro modelo, que gera resposta plausível baseada em lixo. Resposta plausível baseada em lixo é pior que ausência de resposta, porque ninguém percebe.
Filtro 4: Qual o orçamento agêntico
Custo de IA é tokenizado. Cada chamada custa por token de entrada e saída. Em arquitetura agêntica, o custo escala com número de iterações por tarefa. Sistema que faz 10 chamadas por execução custa 10 vezes mais que chamada única.
Pilotos baratos viram operações caras. Volume × custo unitário × iterações precisa estar na conta antes do go-live. Quatro variáveis a estimar:
| Variável | Exemplo |
|---|---|
| Tokens por requisição (input + output) | 5.000 |
| Iterações por tarefa | 4 |
| Tarefas por usuário ativo / dia | 8 |
| Usuários ativos | 200 |
Conta direta: 5.000 × 4 × 8 × 200 = 32 milhões de tokens / dia. A R$ 6 / 1M tokens (custo médio de modelo de capacidade média), vira R$ 192 / dia ou R$ 5.760 / mês. Em escala de 5.000 usuários, vira R$ 144.000 / mês. Volume × custo escala rápido.
A decisão entre modelo top-of-line e modelo médio, entre cache agressivo e cache mínimo, entre chunking otimizado e despejo, vira diferença de uma ordem de grandeza no custo. Translator participa dessa decisão porque ela tem efeito direto em margem.
Filtro 5: Qual a eval definida antes
Sem eval, a equipe debate se "está funcionando" baseado em sensação. Com eval, a conversa muda de "achei melhor" pra "subiu de 73% pra 81% no benchmark X". Investir em eval antes do piloto é o que separa projeto que vira produção de projeto que vira post de LinkedIn.
Quatro perguntas pra acordar antes de começar:
- Qual o conjunto de casos representativos do uso real? Mínimo de 50, idealmente 200.
- Qual a métrica objetiva (acurácia, precision/recall, taxa de alucinação) e qual o threshold de aceitação?
- Qual a métrica subjetiva (qualidade percebida, satisfação) e como vamos medir?
- Qual a frequência de re-eval depois do go-live, e quem é responsável?
Stack típica: Braintrust, LangSmith, Promptfoo, OpenAI Evals, Anthropic Evals ou framework próprio. A escolha de stack importa menos que ter eval definida; equipe que tem eval ruim em ferramenta boa supera equipe que tem ferramenta boa sem eval.
Filtro 6: Qual o plano de sunset
A regra que separa projeto sério de teatro: quando paramos esse piloto, e em que condições? Pilotos que rodam indefinidamente porque "deu trabalho montar" são desperdício institucionalizado.
Três cenários de sunset que precisam estar escritos:
A. Não atingiu o threshold de eval em três ciclos consecutivos. Sunset com retrospectiva: o que aprendemos, o que fica como ativo, o que descontinuamos.
B. Atingiu o threshold de eval, e a economia projetada não se materializou. Sunset com análise de gap: estimativa estava errada, ou a operação não absorveu o ganho?
C. Atingiu eval e economia, e o caso de uso virou comoditizado por capacidade nativa do modelo ou por concorrente. Sunset por obsolescência, com migração pra próximo caso de uso.
Sunset não é fracasso. Sunset é maturidade operacional. Empresa que aprende a desligar o que não funcionou aprende mais rápido que empresa que mantém todo piloto vivo por inércia.
Como aplicar os seis filtros na próxima reunião
A frase que vale carregar pra reunião de kickoff: nenhuma proposta de IA está pronta sem os seis filtros respondidos por escrito. Filtro sem dono é piloto que não tem destino. Filtro sem custo de erro mapeado é alucinação esperando pra virar fato organizacional. Filtro sem estratégia de dado é projeto que vai rebobinar. Filtro sem orçamento é surpresa de fim de mês. Filtro sem eval é debate de sensação. Filtro sem sunset é desperdício institucionalizado.
Aprofundamento de vocabulário no glossário de IA pro Translator, com 18 termos em quatro níveis. O critério estruturado é parte do módulo ML e IA sem Hype da formação Data Translator, e o desenho de governança aparece em IA, Agentes e Futuro. Pra mapear gaps específicos do seu repertório, faça o Radar de Competências em 5 minutos.
Referências
- MIT NANDA (2025). The State of AI in Business 2025.
- McKinsey (2024). The state of AI: How organizations are rewiring to capture value.
- Coimbra, V. (2026). Você ainda lê o que assina? O gap de percepção entre o que a IA entrega e o que o time entende. Medium.