Sente-se em um comitê de priorização de inteligência artificial em qualquer empresa que já tenha alguns ciclos de maturidade nesse tema, e vai encontrar a mesma cena. Três times à mesa, cada um com um argumento perfeitamente defensável. O time de modelo mostra uma simulação em que a acurácia sobe oito pontos. O time de dados mostra o tamanho do problema de qualidade na base, com evidência concreta de cadastros incompletos. O time de produto mostra pesquisas de usuário indicando que a interface confunde quem deveria agir sobre a previsão.
Todos estão certos. E essa é exatamente a dificuldade. Não existe, nessa sala, uma resposta tecnicamente errada. Existe uma resposta que importa menos para o negócio neste ciclo, e raramente alguém na sala consegue dizer, com segurança, qual é.
Quando todo argumento é verdadeiro, a decisão vira disputa de influência
A dificuldade real da priorização entre dado, modelo e experiência não está na falta de informação sobre cada frente. Está na ausência de uma moeda comum para comparar três tipos de investimento que, em seus próprios termos técnicos, são incomparáveis. Oito pontos de acurácia, um projeto de qualidade de dados e uma mudança de interface não competem na mesma unidade. Sem um critério externo, a decisão deixa de ser sobre o que move o negócio e passa a ser sobre quem tem mais peso político na sala, qual time é mais numeroso, ou qual argumento foi apresentado com mais confiança.
É por isso que esse tipo de decisão expõe, de forma quase clínica, o nível de maturidade de um time de produto. Times menos maduros tratam a priorização como uma negociação interna, em que cada área defende seu próprio item de backlog e o resultado é uma média aritmética de interesses. Times maduros tratam a mesma reunião como um exercício de tradução: o que a empresa decidiu que precisa mover este ano, e qual dessas três frentes está mais perto de mover exatamente isso.
O ciclo trimestral não é sobre tecnologia, é sobre falta de bússola
É comum observar empresas passarem, em sequência, por um ciclo de investimento em dados, depois em modelo, depois em interface, sem que o indicador de negócio que justificou o projeto se mova de forma perceptível em nenhum dos três ciclos. Cada etapa, isoladamente, foi bem executada. A base de dados realmente melhorou. O modelo realmente ficou mais preciso. A interface realmente ficou mais clara.
O que não existiu, em nenhum dos três ciclos, foi a pergunta que deveria vir antes de qualquer uma delas: qual indicador de negócio este investimento deveria mover, e esse indicador é, hoje, uma prioridade estratégica da empresa, ou é apenas o indicador que a área de tecnologia consegue medir com mais facilidade. Sem essa pergunta, dados, modelo e experiência se tornam três caminhos paralelos, cada um com sua própria métrica de sucesso, e nenhum necessariamente conectado ao que o negócio decidiu que importa agora.
Dois casos em que a estratégia, e não o diagnóstico técnico, decidiu a prioridade
Quando reter clientes era a prioridade do ano.
Uma operação de relacionamento com clientes tinha, ao mesmo tempo, um projeto de evolução de modelo de previsão de cancelamento praticamente pronto para entrar em produção, e uma constatação incômoda: o alerta de risco gerado pelo modelo atual chegava em um relatório semanal que o time comercial raramente abria. Em um ano normal, a decisão óbvia seria seguir com a evolução do modelo, afinal já estava quase pronta, e tratar o problema do relatório como um ajuste menor para depois. Mas aquele ano não era normal. A empresa havia declarado, de forma explícita, que a prioridade estratégica do período era reter a base existente, porque o custo de aquisição havia disparado e crescer por aquisição deixara de ser viável. Diante dessa prioridade, integrar o alerta ao sistema que o time comercial já usava todos os dias, com uma ação sugerida ao lado, deixou de ser um ajuste menor e passou a ser o item de maior potencial de impacto do trimestre, mesmo competindo com um upgrade de modelo tecnicamente mais sofisticado. Sem a estratégia explícita, o comitê quase certamente teria escolhido o caminho mais impressionante tecnicamente, e mais difícil de defender depois, o caminho mais alinhado ao que a empresa havia dito que precisava.
Quando o ticket médio, e não a personalização, era o que precisava mover.
Uma operação de varejo digital tinha um motor de recomendação que poderia evoluir de forma significativa com mais um trimestre de investimento em modelagem. Também tinha, na mesma lista, uma mudança simples de posicionamento da área de recomendações na página de produto. Em termos de prestígio técnico, a evolução do modelo era o projeto mais atraente para a equipe de ciência de dados. Mas a estratégia da empresa para aquele ciclo era explícita: aumentar o valor médio de cada compra dentro da base de clientes já existente, sem depender de mais investimento em aquisição de tráfego. Sob esse critério, a mudança de posicionamento, que afetava diretamente quantas pessoas chegavam a ver e considerar uma recomendação antes de finalizar a compra, tinha uma relação muito mais direta com o indicador que a empresa havia escolhido acompanhar do que qualquer ganho de assertividade do modelo. A decisão não exigiu um diagnóstico técnico elaborado. Exigiu perguntar, sem rodeios, qual das duas frentes estava mais próxima do indicador que a diretoria havia colocado no centro do ano.
O que diferencia um time de produto maduro nessa decisão
A maturidade aparece em comportamentos específicos, e é possível observá-la em qualquer reunião de priorização.
Falar a língua do indicador de negócio, não da métrica técnica. Um time maduro não chega à reunião dizendo que pode subir a acurácia em oito pontos. Chega dizendo o que essa melhora representaria em retenção, em margem, em ticket médio, e com que grau de confiança essa relação existe.
Aceitar desistir do próprio item, com dados. A maturidade mais difícil de desenvolver é a capacidade de uma área concluir que o item mais importante do seu próprio backlog não é o mais importante do backlog da empresa neste ciclo, e comunicar isso antes que alguém de fora precise apontar.
Tratar a fase de diagnóstico como parte do projeto, não como atraso. Investir tempo para entender onde está a perda real, antes de comprometer um time inteiro a um trimestre de trabalho, é frequentemente visto como lentidão. Em times maduros, é visto como a parte do projeto que evita o maior desperdício possível: um trimestre de trabalho tecnicamente correto, na frente errada.
Um mapa de sintomas, útil só depois que a estratégia está clara
Um mapa de sintomas pode ajudar a direcionar a investigação inicial, mas vale uma ressalva importante: ele organiza o diagnóstico técnico, não substitui a pergunta estratégica. Ele responde “onde provavelmente está o problema”. Não responde “este é o problema que vale a pena resolver agora”. Essa segunda resposta só existe se a empresa souber dizer, com a mesma clareza com que define metas financeiras, o que está tentando mover neste ciclo: participação de mercado, margem, retenção, velocidade de lançamento, custo operacional. Sem essa declaração, o mapa abaixo é apenas um inventário de problemas possíveis, todos igualmente urgentes e, por isso, nenhum verdadeiramente prioritário.
| Sintoma observado | Pista | Frente provável | Quem precisa estar na sala | Risco se a estratégia não estiver clara |
| A previsão existe e está correta, mas a ação não acontece | A informação não chega a quem decide, no momento em que decide | Experiência (produto) | Produto, operação, time que recebe o insumo | O time técnico vota em si mesmo e propõe retreinar o modelo |
| A previsão erra com frequência, mesmo em casos simples | O insumo que alimenta o modelo está incompleto ou desatualizado | Dados | Engenharia de dados, áreas donas dos cadastros de origem | O investimento vira projeto de qualidade de dados sem dono nem prazo |
| Dado correto, informação chega, e o resultado ainda é fraco | A lógica de previsão não captura o padrão que importa | Modelo | Ciência de dados, com mandato explícito do negócio | Vira o investimento padrão, mesmo quando não é a causa |
A estratégia como critério de desempate
O ponto central não é que dados, modelo ou experiência sejam mais ou menos importantes de forma genérica. É que, sem uma estratégia de negócio explícita para o ciclo, simplesmente não existe forma de comparar os três. Oito pontos de acurácia contra um projeto de qualidade de dados contra uma mudança de interface é uma comparação sem unidade comum, e por isso tende a ser resolvida por critérios que nada têm a ver com o que a empresa precisa: o time mais influente, o projeto mais fácil de explicar, o que já está mais avançado.
Quando a estratégia está clara, o problema muda de natureza. Já não se trata de comparar acurácia com qualidade de dados com experiência de uso. Trata-se de perguntar, sobre cada uma das três, a mesma pergunta: o quanto isso aproxima a empresa do indicador que ela decidiu que importa este ano. É uma pergunta única, com uma unidade comum, e qualquer time, técnico ou não, consegue responder a ela.
O investimento que realmente falta
A maioria das empresas que investe em inteligência artificial está, de fato, investindo em dados, em modelos e em experiência, com qualidade técnica real em cada uma dessas frentes. O que falta, na maior parte dos casos, não é mais uma dessas três coisas. É o investimento, mais barato e mais raro, em traduzir a estratégia do negócio em um critério simples o suficiente para que um comitê de priorização consiga, em uma reunião, decidir qual das três frentes merece o próximo trimestre. Esse trabalho de tradução não aparece em nenhum dashboard de modelo, não melhora nenhuma métrica de qualidade de dados, e não redesenha nenhuma tela. Mas é, hoje, o que separa empresas que extraem resultado real de IA das que apenas acumulam projetos tecnicamente impecáveis, um atrás do outro, sem que o ponteiro que realmente importa se mova.
