PoC, MVP e produto respondem a três perguntas diferentes. A PoC pergunta se dá para fazer. O MVP pergunta se alguém usa e paga. O produto pergunta se isso aguenta escala com qualidade e margem. Quando uma empresa pede "um MVP" querendo saber se a tecnologia funciona, ou aprova "uma PoC" esperando usuário real em produção, o problema começa antes da primeira linha de código: o orçamento, o prazo e a expectativa foram montados para a pergunta errada.
Em projetos de IA a confusão custa mais, porque a distância entre uma demo convincente e um sistema confiável é maior do que em software tradicional. Um modelo que acerta 20 perguntas de teste na frente da diretoria parece pronto. Não está.
PoC: dá para fazer?
A prova de conceito responde a uma pergunta técnica e de negócio bem delimitada: esta abordagem funciona com os nossos dados, dentro de um custo aceitável? Ela não precisa de interface bonita, de login, nem de aguentar mil usuários. Precisa de dados reais (ou representativos), de um critério de sucesso escrito antes e de uma estimativa honesta de quanto custaria em produção.
O que a PoC entrega é uma decisão, não um sistema. O resultado certo pode ser "descartar", e isso é bom: descobrir em quatro semanas que a ideia não se paga é muito mais barato do que descobrir em um ano. A Gartner projetou em 2024 que ao menos 30% dos projetos de IA generativa seriam abandonados depois da PoC até o fim de 2025, por dados ruins, riscos mal controlados, custos crescentes e valor pouco claro. Uma boa PoC existe para expor esses quatro problemas cedo.
Duração típica: 3 a 6 semanas. Quem usa: o time do projeto e alguns especialistas do negócio. Erro comum: tratar a demo da PoC como um produto quase pronto.
MVP: alguém usa e paga?
Eric Ries, que popularizou o termo, define o MVP como a versão de um novo produto que permite ao time coletar o máximo de aprendizado validado sobre os clientes com o menor esforço (Startup Lessons Learned, 2009). A palavra importante é clientes. O MVP assume que a viabilidade técnica está resolvida e testa comportamento: as pessoas adotam, voltam, pagam, mudam o jeito de trabalhar?
Isso exige usuários reais, fora do time do projeto, e o mínimo de produto para que a experiência seja honesta. Em IA, isso inclui coisas que a PoC ignorou: tratamento de erro quando o modelo não sabe a resposta, um caminho para o usuário corrigir o sistema, monitoramento básico de custo e de qualidade.
Para uma empresa, o "cliente" do MVP pode ser interno: a área de crédito, o time de atendimento. A pergunta é a mesma: eles usam sem que ninguém obrigue?
Duração típica: 2 a 4 meses. Quem usa: um grupo real e limitado de usuários. Erro comum: encher o MVP de funcionalidades e atrasar o aprendizado que ele deveria trazer.
Produto: aguenta escala com qualidade e margem?
Produto assume que tecnologia e demanda já foram validadas. A pergunta agora é operacional e financeira: funciona com dez ou cem vezes mais usuários do jeito que funcionou com poucos? A margem se sustenta quando o custo do modelo cresce com o volume?
É aqui que aparece a maior parte do trabalho que ninguém vê na demo. O artigo Hidden Technical Debt in Machine Learning Systems, de engenheiros do Google (NeurIPS 2015), mostra que o código de machine learning é uma parte pequena de um sistema real, cercada por coleta e validação de dados, configuração, monitoramento, infraestrutura de serviço e gestão de processos. Com IA generativa, a lista ganha avaliação contínua de respostas, controle de custo por token, proteção contra prompt injection e trilha de auditoria.
Duração típica: contínua. Quem usa: todos os usuários previstos. Erro comum: escalar o código da PoC em vez de reconstruir o que precisa ser reconstruído.
E o piloto?
Muita empresa usa uma quarta palavra: piloto. Na prática, piloto costuma ser o MVP de uma iniciativa interna, com usuários reais de uma área ou unidade e prazo definido. O nome importa menos do que a pergunta. Se o piloto tem usuários reais usando no trabalho de verdade, trate como MVP, com critério de adoção e de qualidade. Se é só o time do projeto testando com dados reais, é uma PoC com outro nome, e deve terminar numa decisão, não numa expansão automática. O risco mais comum é o piloto que nunca termina: fica ativo por meses, com poucos usuários, sem ninguém decidir se ele vira produto ou é desligado.
Exemplo hipotético: análise de contratos no jurídico
O cenário a seguir é um exemplo hipotético, criado para mostrar a diferença entre as etapas. Não é um cliente.
Um departamento jurídico revisa cerca de 150 contratos de fornecedores por mês. A ideia é usar IA para extrair cláusulas de risco (multa, reajuste, foro, limitação de responsabilidade) e sinalizar desvios da política interna.
Na PoC, o time pega 100 contratos já revisados por advogados e mede se o modelo encontra as mesmas cláusulas. Critério combinado: encontrar pelo menos 90% das cláusulas de risco, com custo estimado abaixo de R$ 10 por contrato. Nenhum advogado usa o sistema no dia a dia. Em quatro semanas, sai uma decisão.
No MVP, três advogados passam a receber a análise da IA antes de revisar cada contrato novo, durante dois meses. A pergunta muda: eles confiam, revisam mais rápido, pedem para continuar? Se voltarem a ler o contrato inteiro do zero, o MVP mostrou algo que a PoC não podia mostrar.
No produto, o sistema atende o jurídico inteiro e está integrado à ferramenta de gestão de contratos, com registro de cada análise para auditoria, monitoramento de precisão por tipo de contrato e um orçamento mensal de modelo acompanhado pelo financeiro.
Perceba que o mesmo "sistema de análise de contratos" tem três escopos, três orçamentos e três critérios de sucesso diferentes. Aprovar o orçamento de produto antes da PoC seria apostar no escuro. Pedir o prazo de PoC para o produto seria garantir um projeto atrasado.
Como saber em que etapa você está
Responda na ordem. A primeira resposta "não" indica a etapa em que você está:
- Já foi demonstrado, com dados reais e um critério escrito antes, que a abordagem funciona e que o custo em produção é aceitável? Se não, você está na PoC.
- Usuários reais, fora do time do projeto, usam o sistema por vontade própria há pelo menos algumas semanas? Se não, você está no MVP.
- O sistema tem monitoramento de qualidade e custo, dono definido, trilha de auditoria e plano para dez vezes mais volume? Se não, você está construindo o produto, e ainda não chegou lá.
Checklist para a reunião de escopo
- A pergunta que esta etapa precisa responder está escrita numa frase.
- O critério de sucesso tem número e foi combinado antes de começar.
- O orçamento e o prazo são compatíveis com a etapa, não com a seguinte.
- Está definido o que acontece se o resultado for negativo.
- Quem aprova a próxima etapa sabe que vai ter que decidir, e quando.
Próximo passo
Na próxima reunião sobre um projeto de IA, antes de discutir preço, escreva a pergunta que a etapa precisa responder. Ela define o escopo certo.
É por isso que oferecemos as etapas como serviços separados. A Cyborg Forge testa uma hipótese em 3 a 6 semanas e termina com um Decision Package. O MVP As a Service constrói um MVP enxuto para founders que já validaram a ideia e precisam de execução disciplinada. E a nossa metodologia mostra como uma etapa passa para a seguinte.