Protótipo aprovado: o que falta para virar sistema
Um protótipo aprovado provou que existe demanda. Não provou que a arquitetura aguenta. Antes de promovê-lo a sistema, quatro perguntas precisam de resposta: de onde vem o dado verdadeiro, o que acontece quando o caso foge do padrão, quem pode ver o quê e quem mantém isso daqui a um ano.
Por que o piloto que deu certo não vira sistema?
Porque validação e operação respondem a perguntas diferentes. O protótipo responde se as pessoas usam e se o resultado melhora. O sistema responde se aquilo continua verdadeiro no dia em que o volume dobra, o dado chega errado e a pessoa que construiu sai de férias.
Os números mostram onde a fila trava. Na edição 2026 do relatório State of AI in the Enterprise, da Deloitte, feita entre agosto e setembro de 2025 com 3.235 líderes de negócios e TI, sendo 115 brasileiros, 58% das organizações brasileiras afirmam que no máximo 20% dos seus pilotos chegaram à implementação. Apenas 23% escalaram 40% ou mais.
O Brasil não está atrás na ambição. Na mesma pesquisa, 42% dos respondentes brasileiros dizem usar IA para promover mudanças estruturais, contra 34% da média global, e 30% redesenham fluxos críticos em torno da tecnologia. A intenção existe. O que falta é a passagem.
O que o protótipo prova, e o que ele não prova
Ele prova demanda. Alguém usou, o número melhorou, o time pediu mais. Isso é informação cara e você já pagou por ela.
O que ele não prova são quatro coisas, e cada uma delas é uma decisão de arquitetura, não uma tarefa de desenvolvimento.
A primeira é de onde vem o dado verdadeiro. No protótipo, quase sempre alguém exportou uma planilha, limpou na mão e importou. Funciona uma vez. Em produção, o dado precisa ter uma origem definida, uma regra de atualização e um responsável quando divergir. A Pesquisa sobre Tendências Digitais em Operações 2026 da PwC, com 767 líderes de operações e cadeia de suprimentos nos Estados Unidos, ouvidos entre janeiro e fevereiro de 2026, coloca a complexidade de integração no topo das barreiras à geração de valor, seguida por problemas de dados. E 87% dos entrevistados dizem que a má qualidade dos dados atrapalhou o progresso das iniciativas digitais.
A segunda é o que acontece fora do caminho feliz. O piloto roda com os casos que alguém escolheu. A operação real traz o pedido cancelado depois de faturado, o cliente com dois cadastros, o campo obrigatório que veio vazio. Um protótipo trata exceção com uma mensagem de erro. Um sistema precisa de um caminho de saída para cada uma delas, e alguém precisa decidir quais.
A terceira é quem pode ver o quê. Protótipo costuma nascer com um acesso só, o de quem construiu. Sistema precisa de perfil por função e de trilha de auditoria. E precisa que o acesso caia junto com o crachá, no dia do desligamento. Esse é o item que mais se adia e o que mais custa depois.
A quarta é quem mantém. Um protótipo tem autor. Um sistema precisa de dono, com orçamento de manutenção no nome dele. E precisa de alguém que saiba mexer quando o autor não estiver. Sem isso, o que você promoveu não foi um sistema. Foi uma dependência.
A mesma pesquisa da PwC ajuda a calibrar a expectativa: 89% dos líderes apontam pelo menos uma razão pela qual os investimentos em tecnologia não entregaram todos os resultados esperados, e apenas 4% relatam sucesso simultâneo em quatro frentes, entre elas ausência de barreiras significativas para escalar e investimentos que entregam o previsto. Vale a ressalva de que a amostra é de empresas norte-americanas de grande porte. O número brasileiro equivalente é o da Deloitte, citado acima, e ele aponta na mesma direção: o gargalo não está na ambição, está na passagem.
O que acontece quando ninguém decide
O protótipo não some. Ele fica.
Em maio de 2026, pesquisadores da empresa israelense Red Access mapearam cerca de 380 mil aplicações e ativos publicamente acessíveis criados com ferramentas de desenvolvimento assistido por IA. Por volta de 5.000 continham informação corporativa sensível. O Axios verificou parte dos casos: escalas de atracação de uma empresa de navegação, conversas de atendimento sem qualquer tarja e informação financeira interna de um banco no Brasil. Muitas dessas aplicações estavam indexadas por buscadores.
As plataformas contestaram a leitura. A Replit respondeu publicamente que aplicações públicas ficarem acessíveis na internet é comportamento esperado e que a configuração de privacidade muda com um clique. O argumento é razoável e não muda o problema de fundo: a decisão de expor ou não ficou com quem construiu, e quem construiu estava resolvendo um problema de trabalho, não desenhando um controle de acesso.
Esse é o retrato do protótipo que virou sistema por omissão. Ninguém aprovou a promoção. Ela aconteceu porque o protótipo era útil e ninguém definiu o que precisava ser verdade antes de ele carregar operação de verdade. A Deloitte encontrou o mesmo desencontro pelo lado da governança: 95% das empresas brasileiras planejam adotar IA agêntica em até dois anos, e só 27% dizem ter modelos de governança maduros hoje.
Promover, reescrever ou desligar
Três destinos, todos legítimos. O erro é não escolher.
Promover faz sentido quando o protótipo já roda em cima da fonte de dado certa, o fluxo é estável e o que falta é acabamento: perfis de acesso, tratamento de exceção, monitoramento. Aqui o trabalho é somar camadas, não recomeçar.
Reescrever faz sentido quando o protótipo prova o valor mas apoia a lógica em atalhos que não sobrevivem à escala: dado copiado à mão, integração por exportação manual, regra de negócio espalhada em fórmulas. Vale dizer com clareza que reescrever não é jogar fora. O protótipo continua entregando duas coisas caras: a especificação e a certeza de que alguém usa.
Desligar faz sentido quando o número melhorou por causa da atenção do piloto, não do sistema. Acontece mais do que se admite. Um fluxo acompanhado de perto por três pessoas dedicadas melhora sozinho, e a melhora não sobrevive ao fim do piloto.
O critério que separa os três é uma pergunta só: quanto do resultado vem do software e quanto vem do arranjo temporário montado ao redor dele? Se ninguém no time consegue responder isso com um número, a decisão ainda não está madura, e a resposta certa é medir mais um ciclo antes de investir.
Um exemplo, e ele é uma hipótese
Considere uma indústria de médio porte no interior de São Paulo, com 180 pessoas. O cenário abaixo é ilustrativo, montado a partir de padrões que aparecem com frequência, e não descreve um cliente.
O time de qualidade monta um formulário digital para registrar não conformidades de linha, substituindo um caderno e uma planilha. Em seis semanas, o tempo entre a ocorrência e o registro cai de dois dias para poucos minutos, e a gerência passa a ver o problema no mesmo turno. É um ganho mensurável, e ele aparece rápido.
Quando surge a proposta de estender aos três turnos e às duas outras plantas, aparecem as quatro perguntas. O cadastro de produto vem de uma planilha que alguém atualiza toda segunda, e o ERP tem outro. Não existe caminho para a não conformidade que envolve fornecedor terceiro. Todo mundo enxerga todos os registros, inclusive os que mencionam pessoas. E o formulário foi construído por um analista que sai da área em três meses.
Nenhum desses quatro pontos é motivo para descartar o piloto. Todos os quatro são motivo para não copiar e colar o piloto nas outras plantas. A saída é promover com escopo: definir o ERP como fonte única do cadastro, desenhar o fluxo de exceção que falta, separar dois perfis de acesso e nomear um dono. Depois disso, replicar.
É a mesma lógica que sustenta um sistema que precisa crescer por anos sem virar dependência de uma pessoa, como no case da UniTrust, onde a primeira versão entrou no ar em duas semanas e a arquitetura foi sendo promovida ao longo do tempo, ou no case da Repap On, em que a consultoria de processos virou produto e a nova geração da plataforma já nasceu com outra fundação.
A promoção é uma decisão de arquitetura
O protótipo terminou o trabalho dele quando provou que alguém usa. Decidir o que fazer com ele depois é outra pergunta, e ela é sobre fonte de dado, exceção, acesso e propriedade. Nenhuma dessas quatro se resolve escolhendo uma ferramenta melhor.
Perguntas frequentes
A implementação vai exigir tempo demais do meu time?
Exige menos tempo do que a alternativa, que é replicar o protótipo em três lugares e descobrir os quatro problemas em produção. A parte que precisa do seu time é curta e não é técnica: definir a fonte da verdade de cada dado, listar as exceções reais do processo e dizer quem pode ver o quê. Isso costuma caber em duas sessões com quem opera. A construção em si é delegável.
Não consigo justificar o investimento agora. Dá para adiar?
Dá, desde que a decisão de adiar seja escrita e tenha data. O que custa caro é o estado intermediário, em que o protótipo continua rodando, carregando dado real, sem dono e sem controle. Se o investimento não cabe neste trimestre, a decisão honesta é congelar o piloto ou reduzir o escopo dele, não deixá-lo em produção informal.
Como eu mensuro o resultado da promoção, e não só do piloto?
Compare com a linha de base que existia antes do piloto, não com o desempenho durante o piloto. Registre três números antes de promover: o indicador do processo, o tempo gasto pelas pessoas envolvidas e a quantidade de exceções tratadas fora do sistema. O terceiro é o mais revelador, porque mostra quanto da operação ainda acontece por fora.
O próximo passo
Se você tem um piloto que funcionou e a dúvida agora é como levá-lo à operação sem carregar os atalhos junto, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para separar o que promove, o que reescreve e o que desliga: agende a conversa.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico