🗺️ Planos de execução

ROI = ganho − (custo de build + custo de operação) ajustado a risco. Ganho é o que o problema custa hoje ou o que a solução gera; build é o que você vai gastar para criar; operação é o custo contínuo depois do lançamento; risco é o fator de desconto pela chance de não funcionar.

Sem essa estrutura, estimativas de "economizar X horas" ficam soltas e o decisor não consegue aprovar nem comparar opções. A fórmula dá linguagem comum entre técnicos e negócio.

ROI ajustado a risco; custo de oportunidade; fator de desconto por probabilidade de sucesso.

O custo total de uma solução de IA inclui: APIs de LLM (cobradas por token), infraestrutura de nuvem, custo de manutenção quando o modelo muda ou os dados derivam, e supervisão humana para revisar saídas. Projetos que ignoram esses custos recorrentes frequentemente ficam no vermelho após o lançamento.

A conta não termina no deploy. Saber estimar o custo operacional muda a decisão entre construir, comprar um SaaS pronto, ou simplesmente não usar IA.

TCO (total cost of ownership); custo por chamada de API; deriva de modelo; custo de supervisão humana no loop.

Linha de base é a medição do processo atual antes de qualquer mudança: quantas horas leva, qual a taxa de erro, quanto custa por unidade, qual o NPS do fluxo. Sem esse número, qualquer melhoria é percepção, não evidência.

A linha de base é o que permite comparar antes e depois de forma objetiva. Projetos que pulam essa etapa não conseguem demonstrar resultado — e perdem o próximo contrato mesmo que tenham entregado valor real.

Medir antes de mudar; métrica de processo vs. métrica de resultado; documentar o baseline como entregável.

Payback é o tempo para recuperar o investimento inicial. Uma solução que custa R$50k para construir e economiza R$5k/mês tem payback de 10 meses. O horizonte define até quando o cálculo é válido — IA muda rápido e soluções têm vida útil.

Projetos de IA com payback acima de 24 meses raramente chegam lá intactos — o contexto muda antes. Saber calcular payback ajuda a dimensionar o escopo certo e a descartar casos que não fecham a conta.

Payback simples e descontado; horizonte de validade; depreciação acelerada em IA.

Métricas de modelo (acurácia, F1, latência) medem a qualidade técnica; métricas de negócio (custo por transação, NPS, receita gerada, erros evitados) medem o resultado. O decisor compra o segundo — o primeiro é argumento interno da equipe técnica.

Apresentar só métricas de modelo para um CFO é o erro mais comum em projetos de IA bem-sucedidos tecnicamente mas rejeitados comercialmente. A tradução é parte do trabalho do consultor.

Outcome vs. output; KPI de negócio; métricas proxy; o decisor compra resultado, não acurácia.

Um business case de uma página contém: problema a resolver, solução proposta (em linguagem leiga), investimento total estimado, ganho esperado e quando se paga, riscos principais e como mitigá-los. Cabe em uma página porque o decisor lê em dois minutos.

O documento que não cabe em uma página costuma não ter clareza suficiente — a restrição de tamanho força o consultor a tomar posição e eliminar a gordura analítica.

Estrutura problema-solução-valor-risco; brevidade como sinal de clareza; aprovação como objetivo do documento.

Crawl é a primeira onda: menor escopo possível, aprendizado máximo, risco controlado. Walk aumenta cobertura e automatiza mais — com a confiança do que crawl provou. Run escala com o que walk validou. Pular ondas é a principal causa de rollback caro em projetos de IA.

A onda não é só ritmo — é metodologia de redução de risco. Cada onda deve ter um resultado de negócio concreto antes de avançar, não apenas uma entrega técnica.

Escopo incremental; resultado por onda; não avança sem validação; rollback barato.

Dependência é tudo o que precisa existir para um caso de uso funcionar: dados limpos e acessíveis, integrações de sistemas, capacidades de equipe, permissões e governança. Construir antes de resolver dependências é construir sobre areia.

O maior desperdício em projetos de IA é construir o modelo antes de ter os dados. Mapear dependências no início do roadmap evita retrabalho e mantém o cronograma.

Árvore de dependências; fundação antes de feature; dado como pré-requisito; integrações como risco.

Para cada caso de uso, avaliar três eixos: valor (qual o impacto se funcionar), risco (qual a chance de dar errado e o custo do erro), e aprendizado (o que esse caso ensina que desbloqueará outros). O melhor candidato para primeira onda tem alto aprendizado, valor visível e risco controlável.

Sem critérios explícitos, o primeiro projeto é escolhido pelo mais entusiasmado ou pelo mais visível — não necessariamente o mais estratégico. Critérios definem o que vai primeiro e tornam a decisão defensável.

Matriz valor × risco; aprendizado como critério de sequência; decisão defensável e reversível.

Capacidades reutilizáveis são blocos que, ao serem construídos num caso de uso, ficam disponíveis para outros: um pipeline de dados limpos, um módulo de extração de entidades, uma integração com o CRM. Planejar o roadmap com reutilização reduz custo marginal das ondas seguintes.

O consultor que pensa em plataforma antes de feature evita que cada novo caso comece do zero. É a diferença entre um portfólio de projetos e uma pilha de silos.

Construir uma vez, usar muitas; plataforma vs. ponto a ponto; custo marginal decrescente das ondas.

O roadmap visual coloca cada caso de uso numa linha do tempo com ondas claramente separadas, marcos de validação (go/no-go), dependências visíveis e um responsável identificado por cada bloco. Não precisa ser ferramenta cara: uma tabela ou diagrama simples cumpre a função.

Sem visibilidade compartilhada, cada pessoa enxerga um roadmap diferente na cabeça. O artefato visual alinha expectativas, facilita a revisão e serve de âncora para a conversa de priorização.

Artefato de alinhamento; marco ≠ entrega; responsável único por onda; visibilidade pública.

O piloto sempre ensina algo que o planejamento não antecipou: dados piores do que o esperado, resistência de equipe, integração mais complexa, ou caso de uso com resultado melhor do que o previsto. Replanejar a partir do que o piloto revelou é a diferença entre um roadmap vivo e um documento que ninguém consulta.

Projetos que não atualizam o roadmap após a primeira onda tratam o plano como sagrado — e perdem a chance de usar os aprendizados mais valiosos do projeto.

Revisão formal pós-onda; aprendizados como insumo do próximo plano; plano como hipótese, não decreto.

Determinístico basta quando: as regras são claras e estáveis, o volume não justifica IA, o erro tem custo alto (100% de acerto exigido) ou os dados não existem ainda. Regras, automações, filtros, integrações e SaaS resolvem a maioria dos casos — e a custo drasticamente menor.

O reflexo de ir direto para IA ignora a base que resolve mais barato, mais rápido e com menos formas de falhar. Treinar o instinto de checar a base primeiro é o principal objetivo da pirâmide.

Regra explícita é melhor que modelo implícito; previsível > inteligente quando possível; base como default.

O meio da pirâmide (IA num passo do fluxo) é indicado quando há linguagem natural, imagens, previsões probabilísticas ou ambiguidade que regras não cobrem com custo razoável. O fluxo continua determinístico nas etapas antes e depois — IA entra cirurgicamente só onde regra não funciona.

Usar IA num passo mantém o restante do fluxo confiável e auditável, enquanto resolve o que regra não resolve. É o padrão mais comum e mais equilibrado para projetos de IA em produção.

IA cirúrgica; wrapper determinístico; validação da saída; fallback para humano.

Agentes são indicados quando: o problema requer múltiplas decisões encadeadas e autônomas, as ferramentas disponíveis (APIs, buscas, execução de código) são necessárias, e o custo do erro por ação é tolerável. São o andar com maior superfície de falha, maior custo e maior exigência de supervisão.

Saber quando um agente se justifica evita usar o padrão mais caro e arriscado onde um workflow com IA num passo resolveria. Agentes são raros nos casos de uso de consultoria típica — e devem ser.

Autonomia requer supervisão; ferramentas ampliam risco; justificar o topo da pirâmide explicitamente.

Cada andar da pirâmide tem um perfil diferente: determinístico tem custo fixo baixo e risco baixo; IA num passo tem custo de API recorrente e risco médio; agente tem custo alto, latência alta e risco alto. Apresentar esse comparativo ao cliente com estimativas reais é parte do business case.

O trade-off explícito evita que o cliente escolha o andar errado por achar que "mais IA = mais resultado". A decisão deve ser informada, não por entusiasmo.

Tabela comparativa por nível; custo fixo vs. variável; risco operacional crescente; latência como custo.

O padrão híbrido mantém a lógica de negócio em código determinístico (previsível, testável, barato) e usa IA apenas no ponto onde regra não resolve: classificar intenção num campo livre, extrair entidade de texto, resumir documento longo. O resultado vai de volta para o fluxo determinístico.

O híbrido combina a confiabilidade da base com o poder da IA onde ela realmente agrega. É o padrão mais recomendável para produção em consultoria — e o que diferencia uma solução madura de um protótipo.

Determinístico como container; IA como módulo substituível; testabilidade preservada; fallback explícito.

Para cada caso de uso, registrar explicitamente: qual nível foi escolhido, por que os andares abaixo não resolvem, e quais critérios tornariam o andar acima justificável no futuro. O registro protege o consultor, alinha a equipe e serve de referência quando o contexto muda.

Decisões sem registro são refeitas repetidamente. A documentação mínima da escolha de nível cria memória de projeto e permite revisão inteligente quando o piloto retorna com dados reais.

ADR (architecture decision record) simplificado; critérios de revisão; decisão como hipótese revisável.

Antes de escrever uma linha de código ou configurar qualquer ferramenta, o sucesso do piloto precisa estar definido em números: qual métrica, qual valor mínimo aceitável e qual prazo. Sem isso, o piloto termina com "ficou legal" — que não é dado para decidir nada.

Definir sucesso depois do resultado é viés de confirmação garantido. O critério definido antes protege a objetividade da avaliação e torna o go/no-go defensável para todas as partes.

Pré-registro do critério; métrica vs. intuição; o que vai nos slides de resultado antes de ver os dados.

PoC (prova de conceito) responde "isso é tecnicamente possível?" com o mínimo de esforço — frequentemente sem dados reais. Piloto responde "isso funciona neste contexto específico?" com dados reais e usuários reais, mas escopo restrito. Produção é quando escalar com confiança. Pular etapas é o principal motivo de rollback caro.

Misturar os estágios cria expectativas erradas: tratar um PoC como piloto leva a decisões baseadas em dados de laboratório. Saber distingui-los define o tom correto das conversas com o cliente.

PoC = viabilidade técnica; piloto = validade operacional; produção = escala validada; cada etapa tem entregável distinto.

O escopo mínimo do piloto é o menor experimento que responde à pergunta mais importante do projeto. Se a pergunta é "a IA consegue classificar intenção com 80% de acerto?", o piloto testa só isso, com volume mínimo, sem construir toda a integração antes de saber a resposta.

Escopo inflado é a principal causa de pilotos que demoram meses e terminam sem resposta clara. O menor escopo que ensina o máximo é sempre o alvo — não o mais completo, o mais inteligente.

MLP (minimum learning pilot); pergunta principal do piloto; não construir o que não responde à pergunta.

Humano no loop significa que toda saída da IA tem um ponto de revisão humana durante o piloto. O plano de falha define o que acontece quando a IA erra: quem reverte, em quanto tempo, como a operação continua sem a solução. Pilotos sem plano de falha estão assumindo que o sistema nunca vai errar.

O piloto é o momento de maior incerteza. Ter humano no loop permite capturar erros antes que cheguem ao cliente final e alimenta os dados de melhoria. O plano de falha garante que um erro não interrompe a operação do cliente.

Human-in-the-loop; fallback operacional; SLA de revisão; custo da supervisão no piloto.

Durante o piloto, medir a mesma métrica que foi registrada na linha de base — com a mesma definição, no mesmo período equivalente. A comparação antes/depois é o único argumento que transforma percepção em evidência e justifica a decisão de escalar ou abandonar.

Pilotos que não comparam com baseline produzem histórias, não dados. A comparação rigorosa é o que separa uma decisão de escalar informada de uma decisão por entusiasmo.

Mesma definição de métrica antes e depois; período comparável; variação atribuível; evidência vs. história.

Go/no-go é a decisão formal ao final do piloto: os critérios foram atingidos? Se sim, escalar — com o que aprendeu e ajustando o roadmap. Se não, matar ou pivotar — sem culpa, porque pilotos existem exatamente para responder essa pergunta. Matar um piloto que não funcionou é sucesso do processo, não fracasso do projeto.

Sem um critério formal de go/no-go, todo piloto vira produção por inércia. A capacidade de matar um projeto que não funciona é o que mantém o portfólio saudável e a confiança do cliente intacta.

Critério pré-registrado; matar sem culpa; pivotar vs. escalar; próximos passos explícitos em ambos os casos.