O que uma prova de conceito de IA de quatro semanas deve provar antes de escalar

Uma prova de conceito que impressiona numa demonstração pode, ainda assim, ser a coisa errada a escalar. O modelo trata os casos de exemplo, a sala fica convencida e, uns meses depois, o projeto parou sem que ninguém desse por isso. A Gartner indicou em janeiro de 2026 que, até ao final de 2025, pelo menos metade dos projetos de IA generativa tinha sido abandonada após a prova de conceito, devido a fraca qualidade dos dados, controlos de risco insuficientes, custos crescentes ou valor de negócio pouco claro.

Nenhuma destas razões tem a ver com a capacidade do modelo para fazer a tarefa. Essa costuma ser a parte fácil. Uma boa prova de conceito é desenhada para responder às perguntas mais difíceis enquanto ainda há pouco em jogo. Se ainda está a escolher que processo testar, comece pelas cinco perguntas para escolher a primeira automatização.

Uma demonstração não é uma prova

Uma demonstração mostra que algo é possível. Uma prova mostra que funciona com os seus dados, com o seu volume, para as pessoas que o vão usar. A diferença importa porque o modelo é apenas uma pequena parte de um sistema que funciona. Num artigo conhecido sobre machine learning em produção, engenheiros da Google mostraram que o código do modelo é uma pequena fração de um sistema real e que a infraestrutura à sua volta é vasta e complexa.

Por isso, um teste de quatro semanas deve fazer mais do que perguntar se o modelo consegue fazer o trabalho. Deve pôr a funcionar a versão real mais estreita de todo o percurso: a informação real a chegar, o modelo a fazer o seu passo, o resultado a aparecer onde as pessoas trabalham e alguém capaz de o corrigir.

Defina a fasquia antes da primeira semana

Um piloto sem uma definição de sucesso acordada tende a arrastar-se, porque cada resultado fica aberto a interpretações. Acorde três coisas antes de construir o que quer que seja.

• Um conjunto de testes com casos reais. Reúna exemplos históricos com o resultado correto conhecido, na proporção em que realmente chegam, incluindo os difíceis. As orientações da Anthropic sobre avaliações recomendam conjuntos de testes que reflitam a distribuição real da tarefa e incluam casos-limite.
• Uma base de comparação. Meça como o trabalho é feito hoje: tempo por item, taxa de erro, prazo de resposta. As Rules of Machine Learning da Google põem as métricas em primeiro lugar e aconselham a registar o máximo possível no sistema atual antes de definir o que o novo vai fazer.
• Um limiar para cada medida. Escreva o resultado que justificaria escalar e o resultado que o levaria a parar. Torne cada um específico e mensurável: "a categoria certa nos pedidos de rotina e nenhum erro dado com confiança nos reembolsos" em vez de "funciona bem".

Cinco coisas que quatro semanas devem provar

Cada linha abaixo corresponde a uma razão pela qual os pilotos falham mais tarde. Use a tabela como agenda da revisão final.

Quanto aos dados: se os casos de teste contêm dados pessoais, o RGPD aplica-se ao piloto tal como à produção. Use apenas os dados de que o teste precisa (o princípio da minimização dos dados, no artigo 5.º) e confirme como os pode usar antes da primeira semana.

O custo merece uma verificação própria. A Gartner observa que projetos que parecem viáveis numa prova de conceito podem tornar-se um problema de orçamento em produção, porque pequenos custos por utilização se multiplicam por utilizadores e casos de uso. Meça o custo por item durante o piloto e leia o custo real de criar um sistema de IA para saber o que mais deve orçamentar.

Um plano de quatro semanas que deixa espaço para a resposta

Quatro semanas chegam quando o âmbito é um processo e uma decisão. Uma estrutura que funciona:

1. Semana 1: acordar e reunir. Defina a fasquia, monte o conjunto de testes, obtenha acesso aos dados reais e indique as pessoas que vão experimentar o sistema.
2. Semana 2: construir o percurso mínimo. Ligue a entrada, o modelo e a saída de ponta a ponta, apenas para o caso principal. Corra o conjunto de testes completo no fim da semana, mesmo que os resultados sejam fracos.
3. Semana 3: pôr nas mãos dos utilizadores. Deixe a equipa usá-lo em trabalho real, em paralelo com o processo normal, para que nada dependa ainda dele. Registe cada correção e meça o custo por item.
4. Semana 4: corrigir, repetir, decidir. Trate os tipos de erro mais frequentes, volte a correr o conjunto de testes e escreva uma nota de decisão de uma página que compare os números com a fasquia.

Correr o mesmo conjunto de testes na segunda e na quarta semana é precisamente o objetivo. Transforma o progresso num número e evita que a revisão final se torne um debate de impressões. O AI Risk Management Framework do NIST diz que os sistemas de IA devem ser testados antes da implementação e regularmente durante o funcionamento, e o conjunto de testes que constrói agora pode tornar-se o teste de regressão do sistema em produção.

Escalar, ajustar ou parar

No fim da quarta semana há três resultados honestos.

• Escalar quando cada linha da tabela tem provas, a fasquia foi atingida e uma pessoa identificada no negócio é responsável pelo resultado. A fase seguinte é trabalho de engenharia: integração, monitorização, controlo de acessos e suporte.
• Ajustar quando uma ou duas linhas estão fracas e a correção é clara, por exemplo uma fonte de dados em falta. Acorde uma extensão curta, com data de fim fixa e a mesma fasquia. Ajustar não deve tornar-se um estado permanente.
• Parar quando a qualidade está longe da fasquia, ou quando o valor desaparece depois de contar o custo de funcionamento e o tempo de revisão. Um piloto que termina assim ao fim de quatro semanas cumpriu a sua função: poupou-lhe um projeto muito maior.

Nos nossos projetos, os pilotos que passam sem sobressaltos para produção são aqueles em que as regras de decisão foram escritas primeiro. Para definir uma fasquia realista, estime quanto vale hoje o processo na calculadora de ROI ou veja fluxos de trabalho comuns por área de negócio para encontrar candidatos que valha a pena testar.