Sim, quando o discovery compra uma decisão que ainda não pode ser tomada com segurança. Ele deve esclarecer qual problema merece investimento, quem é afetado, qual baseline existe, se dados e integrações são viáveis, quais riscos limitam a solução e qual próximo experimento reduz mais incerteza. Não pague por uma apresentação genérica nem por uma implementação disfarçada; pague por evidência reutilizável e por uma recomendação que também possa ser parar.
Discovery não é piloto. O discovery decide se e como avançar; um alpha, protótipo ou piloto testa uma solução e suas hipóteses mais arriscadas. Implementação transforma a opção validada em capacidade operável. Misturar as três fases cria cronogramas falsos, código descartável tratado como produto e um compromisso com o fornecedor antes de existir evidência.
AI Discovery Decision Gate-8: matriz de 32 pontos
Pontue cada prova de zero a quatro: zero é ausente; um, opinião; dois, evidência parcial; três, evidência consistente; quatro, evidência validada e entregue. Exija pelo menos 24 de 32, nenhum zero e aprovação dos bloqueadores. O score não decide sozinho; ele mostra se a incerteza caiu o suficiente para escolher a próxima fase.
- Problema e resultado — decisão de negócio, usuários, fluxo, dor, fronteiras e resultado mensurável.
- Evidência de usuário e operação — pesquisa, observação do trabalho, exceções, volume, responsáveis e contramétricas.
- Baseline e valor — desempenho atual, unidade econômica, custo de não agir, faixa de benefício e premissas.
- Dados — fontes, direitos, qualidade, representatividade, acesso, retenção, atualização e lacunas.
- Tecnologia e integração — opções, APIs, identidade, ambientes, modelos, dependências e teste de viabilidade.
- Risco e governança — impacto, privacidade, segurança, revisão humana, accountability e controles necessários.
- Adoção e operação — mudança de processo, treinamento, observabilidade, suporte, custos recorrentes e ownership.
- Próxima decisão — alternativas, roadmap, estimativa em faixas, riscos, critérios de aceite e recomendação go/no-go.
Quando o discovery pago faz sentido
- O problema é relevante, mas solução e fronteiras ainda não estão claras.
- Dados, integrações ou requisitos de risco podem inviabilizar a ideia.
- Vários stakeholders descrevem resultados ou processos diferentes.
- O investimento seguinte é grande demais para depender de premissas comerciais.
- A organização precisa comparar construir, comprar, integrar ou redesenhar o processo.
- Uma decisão negativa economizaria mais que o custo da fase.
O Service Manual britânico recomenda entender problema, usuários e restrições antes de construir e observa que o tempo depende do objetivo; quatro a oito semanas é uma referência, não uma regra. Para uma empresa privada, use duração e equipe proporcionais à decisão. Um caso estreito pode precisar de duas ou três semanas; uma plataforma multissistema e regulada pode exigir mais.
Quando não comprar
- A decisão já é clara e a próxima incerteza só pode ser reduzida por protótipo ou piloto.
- O fornecedor oferece o discovery gratuitamente, mas condiciona acesso aos artefatos ou à contratação seguinte.
- A fase repete pesquisa, arquitetura e dados que já foram validados.
- Não haverá acesso a usuários, owners de processo, dados ou sistemas.
- O escopo pede estratégia corporativa ampla sem uma decisão delimitada.
- O resultado obrigatório é confirmar a solução preferida pelo patrocinador.
Exija oito entregáveis utilizáveis por outro fornecedor
- Definição do problema e mapa do fluxo atual.
- Registro de evidências de usuários, operação e exceções.
- Baseline, fórmula de valor e premissas econômicas.
- Inventário de dados, acessos, qualidade e gaps.
- Opções de solução e arquitetura com trade-offs.
- Registro de riscos, controles, owners e risco residual.
- Plano do próximo teste, avaliação e critérios de aceite.
- Roadmap, estimativa em faixas, dependências e recomendação executiva.
O contrato deve dizer que o comprador recebe documentos editáveis, mapas, inventários, decisões, premissas, avaliações e resultados de testes produzidos. Dependências proprietárias e licenças precisam aparecer. O fornecedor seguinte deve conseguir entender a recomendação sem refazer a fase inteira, respeitados direitos preexistentes e a legislação aplicável.
Use a equipe certa e teste sua independência
A equipe deve combinar liderança de produto ou estratégia, pesquisa de usuário e processo, dados e IA, arquitetura e integração, segurança e risco, além dos especialistas do comprador. Peça nomes e dedicação. Uma equipe composta apenas por vendas e arquitetura tende a encontrar a solução que já vende.
Inclua um gate intermediário: após a primeira semana, peça hipóteses, evidências faltantes e opções descartadas. Se nenhum achado puder reduzir, redirecionar ou interromper o investimento, o discovery não está funcionando como mecanismo de decisão.
Separe discovery, alpha/piloto e implementação
- Discovery — reduz incerteza sobre problema, valor, contexto, dados e riscos; termina em decisão.
- Alpha ou protótipo — experimenta opções e testa as hipóteses mais arriscadas com o mínimo necessário.
- Piloto — mede um fluxo delimitado com dados, usuários, guardrails e critérios combinados.
- Implementação — constrói, integra, avalia, opera, transfere e escala uma capacidade escolhida.
A orientação britânica para alpha recomenda protótipos apenas complexos o suficiente para testar ideias e admite descartar código. A GAO reforça que maturidade deve ser demonstrada antes da integração. Portanto, não aceite que um protótipo de discovery seja vendido automaticamente como fundação de produção.
Defina preço, prazo e saída
Prefira fase timeboxed, preço ou teto claro, equipe nomeada, checkpoints e entregáveis de saída. Retenha parte do pagamento até a entrega do pacote de evidências e da reunião executiva. Não vincule remuneração ao volume de oportunidades de IA encontradas; isso premia listas longas em vez de decisões melhores.
O Digital, Data and Technology Playbook afirma que investir no início pode evitar erros caros depois e conecta preparação, modelo de entrega, testes e contratação. Use essa lógica como princípio, não como licença para alongar workshops: cada atividade deve responder uma pergunta de decisão.
Conecte priorização, discovery, piloto e cronograma
Use https://makinai.co/insights/pt/framework-pratico-priorizar-casos-de-uso-de-ia para escolher a hipótese, https://makinai.co/insights/pt/como-estruturar-piloto-pago-contratar-empresa-ia para testar a solução e https://makinai.co/insights/pt/avaliar-cronograma-projeto-ia-realista-antes-contratar para validar o plano seguinte. Conheça https://makinai.co/services/pt/consultoria-estrategia-ia-transformacao.
Quando envolver a MAKINAI
A MAKINAI pode estruturar um discovery independente da venda de implementação, reunir negócio, usuário, dados, tecnologia e risco e transformar achados em uma decisão executiva auditável. O resultado deve permitir avançar, mudar de abordagem ou parar sem perder o conhecimento produzido.