Como aprovar um PoC de IA: o que a diretoria deve exigir

A resposta curta

Uma prova de conceito não é um produto menor. É um experimento controlado para reduzir incerteza antes de você comprometer dinheiro de verdade. Aprove só quando ela tem uma pergunta clara, uma nota de aprovação acordada antes e um caminho para produção se passar.

Por que a maioria dos PoCs não vai a lugar nenhum

A maioria dos PoCs é aprovada como forma de experimentar a tecnologia. Termina com uma demo bonita, um relatório dizendo que é promissor, e nenhuma decisão. Seis meses depois a mesma empresa aprova outro PoC sobre outra ideia.

O problema não é a tecnologia. É que ninguém escreveu, antes de começar, qual resultado justificaria o próximo investimento.

Seis coisas para exigir antes de aprovar

• A pergunta: um problema operacional, dito em termos de negócio, com quanto ele custa hoje.
• Os critérios de sucesso: a métrica, a linha de base e a meta que contam como aprovação, assinados por quem é dono do orçamento.
• Os dados: confirmação de que os dados necessários existem, estão acessíveis e podem ser usados legalmente.
• A integração: quais sistemas o PoC precisa tocar para ser realista, mesmo numa versão enxuta.
• Os modos de falha: o que acontece quando o sistema erra, e quem revisa.
• O caminho para produção: quanto custaria e quanto tempo levaria para entrar no ar se o PoC passar.

O que um bom PoC mede

Um bom PoC mede duas coisas. A primeira é qualidade técnica: quantas vezes o sistema acerta, quantas erra e com que velocidade responde. A segunda é valor operacional: quantas horas, perdas ou dias de espera ele elimina numa fatia real do processo. A decisão de escalar deve se apoiar na segunda, não só na primeira.

Quanto tempo e quanto custa

Um PoC focado costuma levar de quatro a seis semanas. Mais que isso, ele tende a virar uma construção não planejada. O custo deve ser pequeno em relação à perda que ele ataca; se não for, o problema provavelmente é pequeno demais para valer a pena.

Um briefing de PoC em uma página

Antes de assinar, peça um briefing de uma página que responda, em linguagem simples:

• Qual processo, e quanto ele custa hoje, com a fonte do número.
• A métrica que vai decidir o resultado, a linha de base e a meta.
• Os dados que serão usados, quem é dono deles e se podem ser usados legalmente.
• Quais sistemas o PoC vai tocar e quem do seu lado vai liberar acesso.
• Quem revisa os erros do sistema durante o teste.
• Quanto custaria e quanto levaria a produção se o PoC passar, em faixa.
• A data da reunião de decisão.

Se um fornecedor não consegue preencher essa página, o PoC não está pronto para começar.

Erros que desperdiçam um PoC

Testar com dado limpo de demo. O resultado não se sustenta no dado real, então teste numa fatia real da operação, com a bagunça dela.

Mudar a pergunta no meio. Se o problema se mostrar outro, pare e escreva um novo briefing, em vez de esticar o PoC.

Ninguém do negócio envolvido. Se as pessoas donas do processo não participam da revisão, a decisão no fim não vai ter credibilidade.

Nenhuma reunião de decisão na agenda. Marque no primeiro dia. Um PoC sem data de decisão vira um piloto que nunca termina.

A decisão no fim

No fim só existem três resultados honestos: escalar, ajustar e testar de novo, ou parar. Decida antes qual resultado leva a cada um. Um PoC que falha com clareza é bom uso de dinheiro; um PoC que termina em "promissor" não é.