O projeto que quase parou uma operação inteira
Vou começar com um erro meu — porque os erros ensinam mais do que os acertos, e porque qualquer consultor que diz que nunca cometeu erros em projetos de IA está mentindo ou nunca fez projetos de verdade.
Era meu terceiro projeto de IA como consultor independente. Um cliente do setor de logística, operação de distribuição urbana, queria implementar um modelo de roteirização otimizada com IA para substituir o sistema manual que usava há anos. A proposta era sólida, o cliente estava entusiasmado, e eu estava confiante.
O problema foi que projetamos o rollout de uma forma que exigia que toda a equipe de roteirização migrasse para o novo sistema ao mesmo tempo — um big-bang. Na primeira semana de operação com o novo sistema, três erros de modelagem que não havíamos identificado no teste causaram atrasos em 40% das rotas. A operação do cliente ficou parcialmente comprometida por 72 horas.
Resolvemos o problema, o projeto no final foi bem-sucedido, mas aquelas 72 horas me custaram a noite de sono mais longa da minha carreira — e me ensinaram uma lição que nunca mais esqueci: projetos de IA precisam ser entregues de forma que a operação do cliente continue funcionando em qualquer ponto do processo, inclusive nos cenários de falha.
A partir desse episódio, desenvolvi o que chamo de metodologia Milestone — uma abordagem de entrega de projetos de IA em fases cumulativas, com pontos de verificação obrigatórios e mecanismos de reversão em cada etapa.
Por que a maioria dos projetos de IA é entregue de forma disruptiva
Antes de explicar a metodologia, quero entender o problema. Por que a maioria dos projetos de IA é entregue de forma que interrompe ou arrisca a operação?
A resposta tem três componentes:
Pressão para mostrar resultado rápido: O cliente quer ver o novo sistema funcionando logo. O consultor quer impressionar. O resultado é um prazo comprimido que elimina as margens de segurança necessárias para uma transição gradual.
Subestimação da dependência entre sistemas: Em empresas estabelecidas, os processos operacionais são teias de dependências implícitas que nenhuma documentação captura completamente. A integração de um novo sistema de IA com ERP, CRM e processos manuais existentes quase sempre revela surpresas que um planejamento de big-bang não consegue absorver.
Ausência de plano de reversão: Projetos de IA frequentemente são planejados apenas para o cenário de sucesso. O plano de contingência — o que fazer se algo der errado depois que o novo sistema está no ar — é uma reflexão tardia, quando deveria ser parte central do design do projeto.
'Um projeto de IA bem entregue não é aquele onde tudo dá certo. É aquele onde, mesmo quando algo dá errado, a operação do cliente continua funcionando enquanto o problema é resolvido.'
Os princípios da metodologia Milestone
A metodologia que desenvolvi está fundamentada em quatro princípios inegociáveis:
Princípio 1: Operação paralela sempre
Nenhuma funcionalidade do sistema legado é desligada antes de a funcionalidade equivalente no novo sistema estar validada em produção. Isso parece óbvio, mas exige disciplina para resistir à pressão de 'desligar o velho logo para economizar custos de manutenção paralela'.
Princípio 2: Rollout incremental por unidade operacional
O novo sistema é introduzido primeiro em um subconjunto controlado da operação — um departamento, uma região, um tipo de produto ou serviço. Só depois de validar resultados nesse subconjunto, o rollout avança para o próximo segmento. Essa abordagem limita o blast radius de qualquer problema.
Princípio 3: Ponto de reversão a cada marco
Em cada Milestone, existe um processo documentado de reversão para o estado anterior. Se o novo sistema apresenta problema no Marco 3, o cliente volta ao Marco 2 em no máximo 4 horas — sem perda de dados e sem interrupção da operação. Esse mecanismo precisa ser testado, não apenas documentado.
Princípio 4: Validação humana antes de automação total
Mesmo quando o modelo de IA já está treinado e operacional, as decisões do modelo passam por revisão humana durante um período de shadowing — o modelo recomenda, um operador valida. Só depois de atingir uma taxa de concordância satisfatória (definida previamente com o cliente), a automação total é ativada.
Como a metodologia Milestone se estrutura na prática
A metodologia tem cinco marcos obrigatórios. Em projetos maiores ou mais complexos, alguns marcos podem ser subdivididos — mas a sequência nunca é alterada.
Marco 1: Fundação de dados
Antes de qualquer modelo ser construído, a infraestrutura de dados precisa estar estabilizada. Isso inclui pipeline de extração e transformação dos dados do cliente, storage estruturado e documentado, e validação de qualidade de dados. O critério de avanço para o Marco 2 é simples: os dados que vão alimentar o modelo estão disponíveis, limpos e documentados em produção por pelo menos 2 semanas sem incidentes.
Muitos projetos querem pular esse marco. Não deixo. Um modelo treinado em dados instáveis é um modelo que vai falhar em produção — e a falha vai acontecer na pior hora possível.
Marco 2: Modelo em ambiente de homologação
O modelo é treinado e validado em um ambiente separado, com dados históricos. O critério de avanço são as métricas de performance do modelo — definidas previamente — e a aprovação do modelo pelo stakeholder técnico do cliente. Nenhum impacto na operação real ainda.
Marco 3: Shadowing (modelo à sombra)
O modelo roda em paralelo com o processo atual, mas suas decisões não são aplicadas automaticamente — são registradas e comparadas com o que o processo atual decide. Isso permite medir em ambiente real a concordância entre o modelo e o processo humano, identificar casos em que o modelo erra, e coletar feedback para refinamento.
O Marco 3 é onde aprendo mais sobre o modelo — e onde mais vezes já pedi para pausar e refinar antes de avançar. A pressão para pular essa fase é sempre grande. A disciplina para mantê-la é o que separa projetos bem-sucedidos dos problemáticos.
Marco 4: Rollout piloto
O modelo começa a operar com autonomia em um subconjunto da operação — com o sistema legado ainda ativo e pronto para ser acionado em caso de problema. O operador humano ainda está no loop, mas agora valida as decisões do modelo em vez de tomar as decisões do zero.
Marco 5: Rollout completo e handover
Expansão do modelo para toda a operação, desligamento progressivo do sistema legado, treinamento da equipe interna, documentação completa e plano de manutenção. O Marco 5 só acontece depois que o Marco 4 rodou sem incidentes significativos por pelo menos 4 semanas.
Como integro a metodologia Milestone ao framework Trilion
O método que uso é baseado na Trilion, que tem uma abordagem específica para gestão de risco em projetos de transformação digital. O que aprendi com a Trilion foi que projetos de IA falham quase sempre por razões organizacionais, não técnicas — e a metodologia Milestone endereça exatamente isso.
A Trilion define três tipos de risco em projetos de IA que a metodologia Milestone precisa cobrir:
- Risco técnico: O modelo não funciona como esperado em produção. Coberto pelo shadowing e pelo critério de performance no Marco 2.
- Risco operacional: A integração do modelo com os processos existentes causa interrupções. Coberto pelo princípio de operação paralela e pelos pontos de reversão.
- Risco de adoção: A equipe não usa o novo sistema corretamente ou o sabota passivamente. Coberto pelo período de shadowing (que envolve a equipe desde cedo) e pelo treinamento estruturado no Marco 5.
O terceiro tipo de risco — adoção — é o mais subestimado e o mais frequente. Por isso dedico atenção especial a ele desde o início do projeto, não apenas no final.
'Nos projetos de IA que vi falhar, o modelo técnico raramente foi o problema. O problema quase sempre foi a resistência silenciosa da equipe que deveria usar o sistema — e que nunca foi adequadamente incluída no processo de design e validação.'
Como envolvo a equipe do cliente ao longo do processo
Uma das inovações que a metodologia Milestone tem em relação a abordagens tradicionais de entrega de software é o envolvimento contínuo e progressivo da equipe operacional do cliente.
No Marco 1, identifico os 'usuários-chave' — as pessoas da equipe do cliente que vão interagir com o sistema no dia a dia. Elas participam da validação de qualidade dos dados e ajudam a identificar lacunas na modelagem do processo que a documentação não captura.
No Marco 3 (shadowing), os usuários-chave são os avaliadores principais da concordância entre o modelo e o processo humano. Eles estão, literalmente, comparando as decisões do modelo com as deles — e isso cria um entendimento e uma confiança no modelo que nenhum treinamento teórico consegue substituir.
No Marco 4, os usuários-chave são os primeiros operadores do piloto. Eles têm acesso direto a mim para reportar problemas e inconsistências, e suas observações são integradas no refinamento do modelo antes do rollout completo.
Esse processo faz com que, quando o sistema é finalmente lançado para toda a organização, ele não seja mais 'o sistema do consultor' — é 'o sistema que nós ajudamos a construir'.
Lidando com a pressão do cliente para acelerar
Essa é a parte mais delicada da gestão de projetos de IA com essa metodologia. O cliente quer resultado logo. Os marcos parecem conservadores demais. A tentação de comprimir os timelines é constante.
Minha abordagem é endereçar essa pressão de frente, desde a proposta. Quando apresento o projeto, apresento dois cronogramas: o cronograma Milestone (com todas as fases) e o que eu chamo de 'cronograma de big-bang' — que seria mais rápido, mas que apresenta os riscos específicos que o projeto do cliente enfrenta. Deixo claro que não executarei o cronograma de big-bang porque os riscos são inaceitáveis para o tipo de operação do cliente.
Essa transparência antecipada funciona por dois motivos: o cliente entende que o cronograma conservador é uma proteção para ele, não uma forma de eu cobrar mais. E o cliente que não aceita esse argumento provavelmente não é o cliente certo para esse tipo de projeto — o que também é uma informação útil antes de fechar o contrato.
Os resultados que essa abordagem gera
Desde que formalizei e comecei a comunicar ativamente a metodologia Milestone, tenho dois indicadores que falo abertamente com prospects:
Primeiro: nos últimos 18 projetos de IA que entreguei com essa metodologia, zero causaram interrupção significativa na operação do cliente. Nenhum rollout precisou ser revertido inteiramente. Isso não significa que não houve problemas — significa que os problemas foram identificados e resolvidos dentro dos marcos, antes de impactar a operação.
Segundo: a taxa de adoção efetiva do sistema — medida pela frequência de uso real versus esperado 90 dias após o Marco 5 — é de 87% em média. Em projetos de tecnologia onde não se usa essa abordagem, a taxa média de adoção efetiva costuma ficar entre 30% e 50%.
Quando a metodologia precisa ser adaptada
A metodologia Milestone não é uma receita rígida. Em projetos urgentes com clientes com alta maturidade operacional, os marcos podem ser comprimidos. Em projetos altamente inovadores (IA generativa em processos que nunca usaram automação), os marcos podem ser expandidos.
O que nunca é negociável são os princípios: operação paralela, rollout incremental, ponto de reversão e validação humana antes de automação total. A flexibilidade existe na duração e no escopo de cada marco — nunca na presença deles.
'Uma metodologia que não tem princípios não é uma metodologia. É apenas um cronograma. Os princípios da metodologia Milestone existem porque cada um deles foi aprendido da forma mais cara possível — com um erro em um projeto real.'
Próximos passos
Se você quer entender em detalhe como a metodologia Milestone funciona na prática, tenho um material específico para isso.
Ver metodologia Milestone — acesse o documento completo da metodologia com os cinco marcos, os critérios de avanço para cada fase e os templates de gestão de risco que uso em todos os meus projetos.
Ou entre em contato para discutirmos como essa metodologia pode ser aplicada a um projeto específico de IA que você está considerando.
