Do Piloto à Escala: por que provas de conceito falham na transição para produção

Uma pesquisa da IDC com a Lenovo, de 2025, apontou que 88% das provas de conceito de IA não chegam à produção: de cada 33 PoCs, só 4 viram algo usado de verdade. O Gartner previu que 30% dos projetos de IA generativa seriam abandonados depois da PoC até o fim de 2025, por causa de dados ruins, controles de risco fracos, custos crescentes e valor de negócio pouco claro. E a S&P Global mostrou que 42% das empresas abandonaram a maior parte das iniciativas de IA em 2025, contra 17% no ano anterior.

Esses dados são sobre IA, mas o problema não é da IA. Já vi o mesmo acontecer em projetos de identidade, virtualização e automação. Neste artigo quero responder a uma pergunta: por que o piloto dá certo e a produção trava, e o que dá para fazer diferente?

Piloto responde uma pergunta, produção responde outra

Costumo explicar assim para quem não é da área: cozinhar para a família no domingo não é a mesma coisa que abrir um restaurante. A receita pode ser idêntica. Mas o restaurante precisa de fornecedor, estoque, equipe, vigilância sanitária, preço que feche a conta e um plano para quando o fogão quebrar numa sexta à noite.

O piloto responde “isso é possível?”. A produção responde “isso funciona todo dia, para todo mundo, com segurança e a um custo que se paga?”. O erro mais comum que vejo é usar a resposta da primeira pergunta como se fosse a resposta da segunda.

Por que o piloto quase sempre dá certo

O piloto roda em condições que a produção nunca vai ter:

• Poucos usuários, e geralmente os mais animados. Quem se oferece para testar gosta de novidade e tem paciência com falhas.
• Dados escolhidos a dedo. A base real tem cadastro duplicado, campo vazio e atributo preenchido de três jeitos diferentes.
• Especialista do lado. Se algo quebra, alguém resolve na hora. Em produção, quem atende é o service desk às 7h da manhã.
• Exceções empurradas para depois. E esse “depois” é justamente a produção.
• Custo que não aparece. Licença de avaliação, crédito de nuvem e hora de gente que não entra na conta.

Nada disso é errado num piloto. Errado é esquecer que foi assim que ele rodou.

O que eu vi travar na prática

Vou contar alguns casos reais, sem citar clientes, porque eles ensinam mais do que qualquer teoria.

1. O piloto que expôs uma política esquecida

Num piloto de Windows Hello for Business (login no Windows por biometria ou PIN, sem senha), os usuários começaram a perder a sessão sem motivo aparente. A causa não estava no Windows Hello. Estava numa política de Acesso Condicional que já existia em produção: ela exigia um nível de autenticação multifator personalizado que não incluía o Windows Hello como método aceito.

Ou seja, a tecnologia nova funcionava. O que quebrou foi a interação com o que já existia. Em laboratório isso nunca apareceria, porque o laboratório não tem anos de políticas acumuladas. E teve um segundo ponto: o comportamento padrão forçava o cadastro logo após o login, e o piloto precisava de adesão voluntária. Foi preciso ajustar a configuração para respeitar o ritmo das pessoas, não só o da tecnologia.

Lição: o piloto deve rodar no ambiente real, com as políticas reais, ainda que para poucos usuários.

2. Laboratório limpo, produção cheia de histórico

Num projeto de sincronização de atributos entre o Active Directory e o Microsoft Entra ID (datas de admissão e desligamento, usadas para automatizar o ciclo de vida do colaborador), tudo funcionou no laboratório. Na produção apareceram três problemas: conflito de precedência entre regras de sincronização, um erro numa regra antiga e não relacionada que gerava milhares de falhas, e uma permissão de API que ninguém tinha previsto.

Nenhum desses problemas era do projeto em si. Eram do ambiente. Só consegui colocar em produção depois de resolver tudo e formalizar a mudança num documento de GMUD aprovado pelo comitê de mudanças, com plano de retorno.

Lição: o ambiente de produção tem memória. Reserve tempo para o que você não criou, mas vai herdar.

3. Quando o problema está do outro lado da integração

Numa integração do SAP SuccessFactors (sistema de RH) com o Active Directory, a API retornava vazio. Parecia erro de mapeamento. Depois de muito diagnóstico, a conclusão foi que faltava uma configuração do lado do SuccessFactors, que era de responsabilidade de outra equipe.

Lição: integração tem dois donos. Se só um lado está no projeto, o projeto anda na velocidade do lado que não está.

4. A regra de negócio que o piloto não tinha

Numa implantação de redefinição de senha self-service (SSPR), o requisito parecia simples: o usuário troca a própria senha sem ligar para o suporte. Na hora de pensar na escala, apareceram as regras reais do negócio. Matriz, centros de distribuição e lojas precisavam de restrições diferentes por localidade. Em algumas unidades, só determinados cargos podiam usar o recurso. E a licença disponível não cobria toda a base de usuários.

Por isso optei por testar num tenant de laboratório separado e alimentar o grupo de escopo de forma automatizada, com Lifecycle Workflows, para controlar exatamente quem entra em cada onda.

Lição: o requisito de verdade quase nunca está no primeiro briefing. Ele aparece quando você pergunta “e na loja, como fica?”.

5. A licença que ninguém orçou

Num projeto de governança de identidade para remover acessos de colaboradores afastados de forma automática, a solução técnica ficou pronta no laboratório. O que travou foi o licenciamento: o recurso exige um plano específico que não estava previsto no orçamento.

Lição: custo e licença são critério técnico, não detalhe administrativo. Descobrir isso no final mata o projeto.

Como faço a transição hoje

Depois de apanhar algumas vezes, passei a seguir alguns princípios.

Critérios: combinar a saída antes de entrar Antes de começar, deixo escrito:

• qual problema de negócio estamos resolvendo;
• qual número prova que deu certo (por exemplo, “reduzir X% dos chamados de senha”);
• o que faz a gente parar;
• quem decide e quando.

Sem isso, o piloto termina em “achei bom” e fica esperando uma decisão que nunca chega.

Métricas: olhar além da parte técnica Meço em quatro frentes:

Um piloto medido só na parte técnica mostra metade da história.

Governança: dono, papéis e mudança formal

• Patrocinador que garante orçamento e prioridade.
• Dono da solução depois da entrada em produção, não só durante o projeto.
• Segurança, operação e suporte envolvidos desde a primeira semana, não na véspera.
• Gestão de mudança formal, com janela, plano de retorno e aprovação.
• Documentação ao final de cada etapa. Tenho o hábito de fechar cada assunto com um artigo de base de conhecimento, para que a solução não dependa da minha memória.

Arquitetura: construir o piloto como se fosse ficar

Na migração de cargas de VMware para OpenShift Virtualization de que participei num grande ambiente financeiro, o que fez diferença foi não tratar nada como provisório: automação com Ansible, padrões definidos, estratégia de recuperação de desastre com RPO e RTO claros. Na prática, recomendo:

• Infraestrutura como código: se o ambiente não pode ser recriado por script, ele não está pronto.
• Segurança desde o desenho: privilégio mínimo, nada de conta genérica “só para testar”.
• Observabilidade desde o primeiro dia: logs, métricas e alertas.
• Pelo menos uma integração real no piloto, para os problemas aparecerem cedo.
• Nomenclatura rígida quando o teste precisa rodar em produção, para isolar o piloto dos usuários reais.
• Plano de retorno para toda mudança.

O passo a passo que eu sigo

• Defina o problema de negócio, não a ferramenta.
• Combine critérios de sucesso e de parada.
• Valide licenciamento e custo em escala antes de começar.
• Teste em laboratório, mas pilote no ambiente real, com as políticas reais.
• Escolha um grupo piloto que represente todos os perfis (matriz, loja, remoto), não só a TI.
• Expanda em ondas, revisando as métricas a cada etapa.
• Formalize a mudança, com documentação, treinamento do suporte e dono definido.
• Continue medindo depois do go-live.

Erros que eu evito

• Piloto eterno: estender o teste para não ter que decidir.
• Grupo piloto só com a TI: ele não representa a empresa.
• Segurança no fim: vira retrabalho, e às vezes o projeto não passa.
• Licença e custo “para depois”: é onde muito projeto morre.
• Herói no lugar de processo: se só funciona com você do lado, não está pronto.
• Ignorar o ambiente legado: as políticas e regras antigas vão interagir com a solução nova.
• Não ter caminho de volta: toda mudança precisa de rollback.

Conclusão

Quase nenhum dos projetos que vi travar falhou por causa da tecnologia. Eles travaram porque o piloto respondeu “é possível?” e alguém tratou isso como “está pronto”. O que separa as duas coisas é bem pouco glamouroso: critério combinado antes, métrica além da técnica, dono definido, segurança desde o início e uma arquitetura que não precisa ser jogada fora.

E vale lembrar: encerrar um piloto com base em dados também é um sucesso. Ruim é gastar um ano empurrando algo que nunca iria se sustentar. É nesse caminho que a DBC pode contribuir, conectando tecnologia, eficiência operacional e governança para transformar pilotos em resultados sustentáveis e escaláveis.