Checklist de PoC de IA: o que precisa estar pronto antes, durante e no fim

Uma prova de conceito de IA serve para uma coisa: permitir que alguém com orçamento decida o próximo passo. Se no fim das semanas de trabalho a diretoria recebe um relatório técnico caprichado e continua sem saber se escala, ajusta ou descarta a ideia, a PoC falhou, mesmo que o modelo tenha acertado tudo o que tentou.

Esse tipo de falha é comum e aparece nas pesquisas. Em julho de 2024, o Gartner previu que pelo menos 30% dos projetos de IA generativa seriam abandonados depois da prova de conceito até o fim de 2025, citando dado de baixa qualidade, controle de risco insuficiente, custo crescente e valor de negócio pouco claro. Um ano depois, a mesma consultoria estimou que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo, valor incerto e risco mal controlado.

O relatório da RAND Corporation sobre as causas de fracasso de projetos de IA, publicado em 2024, entrevistou 65 cientistas de dados e engenheiros experientes. A causa mais citada foi entender mal, ou comunicar mal, qual problema a IA deveria resolver. O resultado são modelos otimizados para a métrica errada ou que não cabem no fluxo de trabalho real.

Quase nenhum desses motivos é técnico. Dado ruim, custo que cresce, valor que ninguém definiu, risco que ninguém mediu: tudo isso pode ser descoberto dentro de uma PoC bem desenhada, por uma fração do que custaria descobrir em produção. O checklist abaixo é o jeito que encontramos de fazer a PoC procurar essas respostas de propósito.

Antes do primeiro dia

A maior parte do resultado de uma PoC é decidida antes de alguém escrever código.

1. A pergunta de decisão está escrita em uma frase. Não "testar IA no atendimento", e sim "vale investir na automação da triagem de chamados de segundo nível no próximo semestre?". Se a pergunta não cabe numa frase, o escopo ainda está aberto.
2. Existe um critério de sucesso numérico, com limiares. Taxa de acerto, tempo economizado por caso, custo por transação. Os limiares são combinados antes: acima de um valor escalamos, numa faixa intermediária ajustamos, abaixo descartamos. Critério interpretado depois do resultado sempre favorece continuar.
3. Existe uma linha de base. Quanto tempo o processo leva hoje, qual a taxa de erro humana, o que uma regra simples conseguiria fazer. As Rules of Machine Learning do Google começam por aí: a primeira regra é não ter medo de lançar um produto sem machine learning e começar com heurísticas. Se uma regra de dez linhas resolve boa parte do problema, a IA precisa bater a regra, não o zero.
4. O acesso ao dado real está liberado. Em empresa grande, liberar uma base de produção passa por segurança, jurídico e muitas vezes pelo encarregado de dados, por causa da LGPD. Se isso não estiver resolvido no kickoff, as primeiras semanas vão embora esperando.
5. O dono da decisão tem nome. Uma pessoa, com orçamento, que vai ler o resultado e decidir. Não um comitê genérico.
6. Prazo e orçamento são fechados. Na PoC Factory trabalhamos com 3 a 6 semanas. Prazo aberto transforma a PoC num projeto disfarçado, sem os controles de um projeto.

Durante a construção

• Teste com dado real, incluindo o feio. Amostra escolhida a dedo produz demo boa e decisão ruim. Separe os casos difíceis (documento escaneado torto, cliente que manda áudio, cadastro incompleto) e meça neles.
• Meça o custo por unidade desde o início. Em IA generativa, o custo por chamada de modelo, por documento processado ou por conversa decide se a ideia se paga em escala. Custo crescente é um dos motivos de abandono que o Gartner cita, e é fácil de medir numa PoC.
• Registre os erros, não só a taxa de erro. Uma taxa de acerto alta não diz se os erros restantes são baratos ou se um deles gera multa. Uma planilha com algumas dezenas de erros reais, classificados por gravidade, vale mais para a diretoria do que qualquer gráfico.
• Anote o que ficou fora. Integração com o ERP, volume de pico, idiomas, perfis de usuário. Tudo o que a PoC não testou vira item de risco explícito no relatório.
• Olhe o risco junto com o resultado. Dado pessoal no prompt, resposta que pode ser tomada como aconselhamento, decisão automática sobre cliente. O AI Risk Management Framework do NIST é uma referência gratuita e útil para organizar essa lista.

Na entrega

O entregável final precisa ser lido por quem decide em quinze minutos. Na Cortex IQ chamamos isso de Decision Package, e ele tem sempre as mesmas partes:

1. A pergunta de decisão original, copiada do documento de abertura.
2. O resultado medido contra o critério combinado e contra a linha de base.
3. A estimativa de impacto de negócio, com as premissas escritas: volume mensal, custo da hora, adoção esperada. Premissa escondida é o jeito mais comum de inflar um business case.
4. O custo estimado de operar em produção: infraestrutura, chamadas de modelo, monitoramento, pessoas.
5. As limitações conhecidas e o que a PoC não testou.
6. A recomendação: escalar, ajustar ou descartar, com o porquê.
7. Se a recomendação for escalar, o que falta para produção: integrações, dono operacional, plano de monitoramento.

Um exemplo, com números hipotéticos

Pense numa distribuidora que recebe pedidos de compra por e-mail, em PDF, com layouts de dezenas de clientes diferentes. Hoje, dois assistentes digitam esses pedidos no ERP.

A pergunta de decisão: "vale automatizar a leitura dos pedidos em PDF ainda este ano?". O critério: extrair corretamente os campos obrigatórios em pelo menos 95% dos pedidos, com custo por pedido abaixo do custo atual da digitação. A linha de base: medir, durante uma semana, quanto tempo leva cada pedido e quantos voltam por erro de digitação.

A PoC roda com três meses de pedidos reais, incluindo os escaneados. Suponha que o resultado seja 97% de acerto nos PDFs digitais e 81% nos escaneados, que representam um quinto do volume. Uma PoC mal desenhada entregaria "94% de acerto médio" e deixaria a diretoria adivinhando. A bem desenhada recomenda escalar para os PDFs digitais agora, manter os escaneados com revisão humana e reavaliar os escaneados em seis meses. É uma decisão que alguém consegue tomar numa reunião.

Os erros que mais vemos

Critério definido depois. Quando o resultado sai, sempre aparece um motivo para dizer que 80% é bom o bastante. Se ninguém escreveu antes que o mínimo era 90%, a discussão vira opinião.

A demo no lugar da evidência. Uma demo ao vivo convence a sala e não prova nada sobre o volume real. Use a demo para mostrar como funciona e a planilha de erros para mostrar se funciona.

O "ajustar" que nunca termina. Ajustar é uma recomendação válida quando tem prazo e um critério novo. A segunda rodada de ajuste sem data é uma PoC que ninguém teve coragem de encerrar.

Descartar tratado como fracasso. Uma PoC que conclui "não vale a pena" em cinco semanas economizou o orçamento de um projeto inteiro. Se a cultura da empresa pune esse resultado, os times param de recomendá-lo, e as PoCs viram projetos que ninguém consegue desligar.

Por onde começar

Antes de aprovar a próxima prova de conceito, peça ao time uma página com três coisas: a pergunta de decisão em uma frase, o critério numérico com os limiares de escalar, ajustar e descartar, e o nome de quem vai decidir. Se essa página não ficar pronta em uma semana, o problema não é técnico e nenhuma PoC vai resolvê-lo.

Se quiser um formato pronto, a PoC Factory roda esse processo em AWS ou Google Cloud e termina com o Decision Package descrito acima. Para iniciativas maiores de dados e modelos, veja o trabalho de Dados e IA.