Três premissas matam a maioria dos projetos de IA vertical antes do terceiro mês. Nenhuma delas é verificada antes de a arquitetura ser escolhida, antes de a engenharia começar e antes de o orçamento ser comprometido.
A primeira premissa: os dados existem e estão limpos o suficiente para uso. A segunda: o processo é estável o suficiente para ser automatizado. A terceira: existe um responsável pela decisão que vai agir com base no output da IA. As três estão frequentemente erradas. O custo de descobrir isso no oitavo mês não é o mesmo de descobrir na segunda semana.
Um sprint de discovery é o mecanismo para validar ou invalidar essas premissas antes que se tornem caras. Custa quatro semanas de trabalho estruturado. Poupa o restante.
As Três Premissas Que Matam Projetos de IA Vertical
Os dados existem e estão acessíveis. A maioria dos dados empresariais está em silos, é inconsistente, não está documentada ou está com controle de acesso de maneiras que bloqueiam o caso de uso pretendido. O dataset que foi descrito na reunião de kickoff como “prontamente disponível” acaba exigindo aprovação de três departamentos, extração de um sistema sem API documentada e trabalho de limpeza que foi estimado em duas semanas e leva quatro meses.
O sistema de IA que foi projetado em torno desses dados não pode ser construído como projetado. As opções no sexto mês são: reconstruir o pipeline de dados (o que muda o cronograma), reduzir o escopo (o que muda o valor) ou cancelar. As três são mais caras do que um inventário de dados de duas semanas na fase de discovery.
O processo é estável o suficiente para ser automatizado. O processo conforme documentado e o processo conforme praticado diferem. Diferem em toda organização que opera há mais de cinco anos. O sistema de IA treinado em procedimentos documentados encontra operadores reais que desenvolveram workarounds, taxonomias informais e tratamento de exceções que não existem em nenhum registro escrito.
O resultado é um sistema que performa bem em testes controlados e falha nas mãos de usuários reais. Não porque o modelo está errado, mas porque o modelo foi treinado em um processo que os usuários não seguem.
Existe um responsável pela decisão que vai agir com base no output da IA. Um sistema de IA sem um responsável pela decisão é um projeto de pesquisa. O sistema pode produzir excelentes recomendações, e nada muda, porque ninguém tem poder ou responsabilidade para agir com base nelas. Implantações fantasmas se acumulam nas empresas dessa forma: sistemas que geraram bons outputs que ninguém estava estruturado para usar.
O Que um Sprint de Discovery Realmente Produz
Um sprint de discovery não produz um roadmap em slides com fases e marcos. Produz um conjunto de hipóteses validadas ou invalidadas sobre um caso de uso específico.
Os cinco outputs são entregáveis concretos, não análises:
Mapa de processo. O que realmente acontece, documentado a partir da observação, não a partir da documentação do processo. Inclui as exceções, os workarounds, as decisões de julgamento não documentadas. É construído conversando com os operadores reais, não com os donos do processo.
Inventário de dados. O que existe, onde reside, quem controla o acesso, quais problemas de qualidade estão presentes e quais transformações seriam necessárias para torná-los utilizáveis. Cada premissa de dados é testada contra a realidade, não contra o que alguém acredita ser verdade.
Mapa de responsáveis por decisões. Para cada output proposto da IA, quem toma essa decisão hoje, quem vai tomá-la após a introdução da IA, quem é responsável quando a IA está errada e qual é o caminho de escalação para outputs de baixa confiança. Este é um entregável de pessoas e governança, não técnico.
Estimativa de valor. Quanto o problema custa hoje em tempo de pessoal, erros, oportunidades perdidas ou serviços externos? Esta é a base para uma conversa realista sobre ROI e uma verificação de realidade sobre se o caso de uso vale o investimento.
Inventário de riscos. Restrições regulatórias, requisitos de privacidade de dados, complexidade de integração, requisitos de rollback e os modos de falha que devem ser tratados antes da implantação.
A duração do sprint é tipicamente de duas a quatro semanas. Requer especialização no domínio, um arquiteto de IA que consiga traduzir os achados em restrições do sistema e acesso aos tomadores de decisão que são donos do processo. Não pode ser delegado inteiramente ao time de TI.
A Verificação de Realidade dos Dados
O achado de discovery mais comum é que os dados que alimentam o caso de uso pretendido não existem em forma utilizável.
As formas específicas que isso assume importam para o escopo do que vem a seguir. Os dados existem em PDFs sem extração de texto confiável. Os dados exigem a junção de três sistemas sem schema documentado. Os dados existem, mas o processo de aprovação de acesso leva mais tempo do que o cronograma do projeto. Os dados existem, mas são muito escassos no domínio relevante para suportar o uso pretendido.
Cada um desses é um problema diferente com uma solução diferente. Saber qual forma tem a lacuna antes de se comprometer com um design de sistema é a diferença entre um escopo construível e uma promessa não entregável.
O gradiente de maturidade de dados se aplica à maioria dos ambientes empresariais. Algumas organizações têm dados estruturados e acessíveis onde projetos de IA podem avançar rapidamente. A maioria tem dados estruturados mas em silos que exigem trabalho de integração antes que uma camada de recuperação seja útil. Muitas têm dados não estruturados e dispersos que exigem um pipeline de ingestão como pré-requisito para todo o resto.
Escopo do primeiro projeto para o que os dados realmente disponíveis suportam, não para o que os dados teoricamente deveriam existir, é a disciplina de dados que o discovery impõe. Construir um sistema que depende de dados que ainda não existem é um risco de cronograma que se compõe a cada sprint.
O Problema de Fidelidade do Processo
A documentação de processo padrão descreve o processo ideal. A IA treinada nela aprende uma versão do processo que os funcionários reconhecem mas não seguem.
A técnica de discovery que revela o processo real é o shadowing de processo: observar ou entrevistar os operadores reais, não os donos do processo. O objetivo é registrar as exceções, os workarounds e as heurísticas não documentadas que distinguem como o trabalho realmente acontece de como está documentado para acontecer.
Um sistema de classificação de documentos treinado na taxonomia formal classifica incorretamente documentos que os profissionais rotulam usando atalhos informais. Uma IA de suporte ao cliente treinada na base de conhecimento falha em consultas que agentes experientes tratam usando informações que vivem na prática, mas não em nenhuma fonte documentada.
O entregável de fidelidade de processo de um sprint de discovery é um mapa de onde o processo documentado e a prática real divergem. Esse mapa orienta a decisão mais importante antes do início da engenharia: qual versão do processo o sistema deve ser treinado para seguir? A versão documentada, que é mais limpa e manutenível, mas pode não corresponder ao comportamento do usuário? Ou a versão praticada, que corresponde à realidade, mas é mais difícil de documentar e manter?
Não há resposta universal. Ambas têm custos. O sprint de discovery é o que torna a decisão deliberada em vez de implícita.
O Pré-requisito do Responsável pela Decisão
Um sistema de IA sem um responsável pela decisão é um projeto de pesquisa. Isso não é uma crítica. É uma propriedade estrutural.
O responsável pela decisão é a pessoa, ou cargo definido, que age com base no output da IA, revisa casos extremos, aprova recomendações de alto risco e é responsável quando o sistema está errado. Sem esse papel definido e ocupado antes da implantação, várias falhas previsíveis se seguem.
O sistema é usado de forma inconsistente, porque pessoas diferentes aplicam limiares diferentes para quando confiar no output. Casos extremos se acumulam sem feedback, porque ninguém é responsável por revisá-los. O sistema deteriora silenciosamente até que uma falha force um desligamento.
Governança mínima viável antes do lançamento: um responsável pela decisão nomeado, uma cadência de revisão definida para outputs de baixa confiança e um caminho de escalação documentado. Isso não é um exercício de conformidade. É a condição estrutural para um sistema que melhora ao longo do tempo, em vez de um que deriva para a irrelevância.
Discovery como Produto Pago
O sprint de discovery não é um isca ou um brinde de consultoria precedendo o engajamento real. É um produto pago com um entregável definido.
O pacote de cinco outputs, mapa de processo, inventário de dados, mapa de responsáveis por decisões, estimativa de valor e inventário de riscos, tem valor independentemente de um projeto de IA seguir ou não. Uma empresa que queria automatizar um processo e descobre na segunda semana que os dados são insuficientes poupou o orçamento de um projeto de doze meses. Esse é um resultado concreto, não um preliminar.
Escopo do discovery por processo, e não por day rate, alinha os incentivos: o entregável é o output, não o tempo gasto. O engajamento de acompanhamento, se acontecer, é escopo a partir dos achados do discovery, não das premissas iniciais que acabaram sendo parcialmente erradas.
Os clientes que resistem a pagar pelo discovery tendem a ser os que mais precisam dele. A premissa de que tudo será validado durante a fase de construção é cara. O discovery externaliza esse custo para um ponto do projeto onde a informação é mais barata de adquirir.
Os cinco outputs de um sprint de discovery valem mais antes do início da construção do que a mesma informação vale após o sexto mês. O escopo define o que o discovery cobre; o mapa de processo é onde a maioria das surpresas mora.
Relacionados: IA Vertical Vence Onde a IA Genérica Falha e Seu Setor Não Precisa de uma Plataforma de IA