Um modelo de linguagem monta uma alocação de custos em dois dias. Uma equipa financeira defende depois essa alocação perante operações, comercial e um auditor durante os seis meses seguintes. A distância entre estes dois calendários é todo o argumento deste texto: o modelo é agora a parte barata, e a validação é para onde o trabalho se mudou.

O que mudou quando o modelo ficou rápido?

Durante a maior parte dos nossos 25 anos, construir o modelo era o estrangulamento. Mapear atividades, entrevistar donos de processo, estimar equações de tempo, ligar os drivers. Meses disto. A validação era quase uma formalidade no fim, porque, quando se tinha construído a coisa à mão, conhecia-se a coisa intimamente.

Essa ordem inverteu-se. Um modelo pode agora aparecer em dias, montado por alguém que nunca se sentou com os donos de processo e não sabe dizer por que um determinado driver foi escolhido. O artefacto parece igual. A compreensão por detrás dele ainda não existe. A validação já não é a formalidade do fim. É o sítio onde a compreensão em falta tem de ser reconstruída.

Por que a construção rápida torna a validação mais difícil, e não mais fácil?

Um modelo construído à mão carrega o seu próprio rasto de auditoria na cabeça de quem o construiu. Pergunte-se por que o custo de setup é alocado por lote e alguém se lembra da discussão que teve sobre isso em março.

Um modelo rápido não carrega essa memória. Dá-lhe uma alocação de setup, vai soar confiante, e não há ninguém na sala que tenha lutado por essa escolha. Por isso a validação não se pode apoiar em recordações. Tem de reconstruir de forma independente se a escolha estava certa: este driver reflete consumo real, o total reconcilia, a margem sobrevive a um teste de esforço. Isto é mais lento do que carimbar um modelo que se construiu, e deve ser.

Há um segundo problema, mais subtil. Um modelo que se constrói à mão ensina-nos o negócio enquanto o construímos. Descobre-se que duas linhas de produto que se julgavam parecidas consomem tempo de setup de forma muito diferente, e essa descoberta muda em silêncio a forma como se lê cada número seguinte. Um modelo entregue já pronto salta essa educação. Herdam-se as conclusões sem o estágio, o que significa que a primeira vez que se compreende mesmo o negócio é durante a validação, com o tempo a apertar e um resultado já em cima da mesa que toda a gente na sala preferiria acreditar.

Para onde devem ir agora as horas de engenharia?

Para depois de o modelo existir. Em concreto:

– Reconciliação primeiro. Antes de discutir qualquer alocação isolada, confirme-se que os totais do modelo batem certo com o razão. Um modelo que não reconcilia não merece ser discutido linha a linha. – Escrutínio dos drivers a seguir. Percorra-se o punhado de alocações que carrega mais custo e pergunte-se se o driver reflete como o recurso é de facto consumido. A maior parte do risco está num pequeno número de pools grandes. – Esforço e desvio por último. Forcem-se os pressupostos e depois decida-se com que frequência o modelo é reverificado. Um modelo é uma fotografia de um negócio num momento, e os negócios mexem-se.

É esta a lógica de correr a validação como um passo distinto e independente, em vez de uma caixa para assinalar no fecho. Descrevemos como o sequenciamos em /how-we-work/.

Como é que isto se liga à regulação?

Ligeiramente, mas vale a pena dizê-lo. O EU AI Act empurra as organizações para conseguirem demonstrar que um sistema influenciado por IA foi verificado, documentado e governado. Um modelo de custos que, em silêncio, conduz decisões de preço ou de investimento é exatamente o tipo de sistema que beneficia de um registo de validação defensável. A validação lenta não é só boa engenharia. Calha ser o rasto em papel que se quer ter quando alguém pergunta como é que o número foi verificado. As organizações que vão sofrer são as que tratam um modelo de custos gerado por IA como uma resposta acabada em vez de um rascunho que tem de ser defendido. Um passo de validação produz, quase como subproduto, a documentação que um regulador ou um auditor acabará por pedir: o que foi verificado, o que foi encontrado, o que foi aceite e porquê.

Construir o modelo depressa é mau?

Não. Usamos estas ferramentas e ainda bem que a construção ficou barata. Construção barata significa poder construir três modelos candidatos e compará-los, o que antes era um luxo. O erro é tratar a velocidade da construção como se fosse a velocidade da confiança. Não é. O modelo está pronto em dois dias. A confiança é ganha ao longo dos meses que se passa a prová-lo. Vimos modelos tecnicamente corretos na entrega perderem utilidade em silêncio dentro de dois trimestres porque ninguém assumiu a reverificação. A construção nunca foi o risco. O risco é tratar um primeiro rascunho rápido como facto assente.

Conclusão: orce-se a validação como o evento principal, não como o remate. Se a construção levou dois dias, isso é informação sobre a construção e não diz nada sobre se o modelo está certo. Comece pela reconciliação, escrutine os maiores pools e mantenha registo. Mais sobre o passo de validação em /ai-profitability/.