IA mais barata não salva um produto construído sobre o problema errado

O texto da Forrester parte de uma tese direta: conforme o custo de produtos com IA cai, a qualidade do problema resolvido pesa mais no valor entregue. Muitas equipes ainda começam por um mandato de usar IA e depois procuram um problema que o justifique. A Forrester chama isso de build trap e pede que a ordem seja invertida: validar a causa-raiz, testar soluções contra ela e só então definir as capacidades de IA necessárias.

O texto traz quatro práticas. Tratar cada solução como hipótese (a Netflix criou várias variantes de arte por título, cada uma uma hipótese sobre sinais visuais de relevância). Entregar capacidades, não só a funcionalidade, o que inclui pessoas, processo, dados, governança, arquitetura e tecnologia (a Allianz precisou montar várias delas junto com os agentes do Project Nemo). Nomear o mecanismo de valor antes de construir: produtividade, conversão, retenção, custo operacional ou diferenciação. O Nemo reduziu em 80% o tempo de processamento e liquidação de sinistros. E dimensionar cada capacidade sem partir do modelo mais sofisticado: o Kaiser Permanente Intelligent Navigator prioriza precisão em risco de alta gravidade e abrangência na navegação de cuidados, com cerca de 54% de sucesso em agendamentos.

A tese conversa com uma sequência que o CEVIU vinha registrando. Em 26 de agosto de 2026, a matéria "O paradoxo do desenvolvimento de software: IA barateia a construção, mas não o erro" já deslocava o desafio para definir o que construir. Em 8 de setembro de 2026, "O Risco da Construção Desenfreada na Era da IA" descrevia o acúmulo de funcionalidades sem propósito (o "slop-creep"). A novidade agora é o recorte da Forrester, que propõe um caminho prático: da causa-raiz validada às capacidades mínimas, com um mecanismo de valor declarado.

Para quem gerencia produto, a leitura é que o custo menor de construir não reduz a necessidade de descoberta, e sim a aumenta. Um roteiro que começa em "temos que usar IA" tende a produzir funcionalidade sem métrica de valor. Declarar o mecanismo (retenção, custo operacional, conversão) antes do build e dimensionar precisão e autonomia por capacidade ajuda a priorizar o que entra no backlog e o que fica de fora.