Abra o seu inventário de software e ordene-o pelo que cada produto faz realmente. Umas quantas plataformas fazem o negócio funcionar. À volta delas há um anel de subscrições mais pequenas cujo único trabalho é ligar as grandes. Uma suite de integração. Uma ferramenta de processamento de documentos. Qualquer coisa que move dados de A para B porque A e B nunca foram devidamente apresentados.
Cada uma dessas compras fez sentido no dia em que foi assinada. Havia uma lacuna, a plataforma não a conseguia preencher e um fornecedor conseguia. Ninguém fez nada de errado.
Mas duas coisas mudaram entretanto. As plataformas cresceram, porque absorver capacidades adjacentes é o que as plataformas fazem. O Azure ganhou serviços de integração, o GitHub ganhou análise de segurança, o seu ERP ganhou uma API que vale a pena usar. E o único trabalho que as plataformas ainda não faziam de raiz, o genuinamente difícil, era a interpretação. Ler input que chega na forma que um parceiro quis enviar. Mapear a ideia de encomenda de um sistema para a de outro. Perceber que "na próxima terça-feira", escrito num portal por um humano, é uma data de entrega.
A interpretação era o que os produtos especializados estavam realmente a vender. E é, por acaso, aquilo em que um modelo de linguagem é bom. Por isso a lacuna que justificava aquelas renovações fechou-se. As faturas ainda não deram por isso.
O argumento em quatro linhas
A construção em si é simples de descrever. O Azure AI Foundry fica entre os seus sistemas, recebe um payload, conhece o schema de destino e produz o resultado mapeado. Provar isso leva um workshop, e a demonstração é impressionante. O que convence um CFO é outra coisa.
A licença acaba. No seu lugar paga consumo, faturado como despesa Azure normal. Se tem um Microsoft Azure Consumption Commitment, o uso do Foundry conta para ele. A despesa passa para um acordo que já negociou e, normalmente, encolhe pelo caminho.
As alterações voltam para casa. A lógica de mapeamento passa a ser código no seu repositório. Quando um parceiro muda um formato, a sua equipa edita-o e envia a correção pelo mesmo pipeline que tudo o resto. Sem ticket ao fornecedor, sem esperar pela janela de release de outra pessoa.
Os dados deixam de andar a passear. Os payloads deixam de fazer a viagem de ida e volta pela infraestrutura do fornecedor. Isso encurta todas as revisões de segurança e resolve a maioria das perguntas de soberania antes de alguém as fazer.
A governação continua sua. Identidade gerida, Azure Policy, Azure Monitor e um teto de orçamento rígido no recurso Foundry. Os mesmos controlos do resto do seu ambiente, em vez de uma página de confiança de um fornecedor que aceita de boa-fé.
Que renovações questionar
Um produto candidato tem um cheiro característico. O seu valor está em regras acumuladas ao longo de anos: mapeamentos, modelos, traduções, lógica de parsing. Pergunte o que custaria reconstruir e a resposta honesta costumava ser anos de casos particulares, redescobertos um incidente de cada vez. Um modelo muda essa resposta, porque lidar com input desarrumado já não significa escrever à mão uma regra para cada variação que o portal de alguém consegue produzir.
Deixe os seus sistemas de registo em paz. O mesmo para qualquer coisa cujo valor seja uma rede, porque ninguém deve reconstruir um esquema de pagamentos, e para produtos que carregam certificações que teria de conquistar por si. O alvo é o tecido conjuntivo: software que interpreta, reformata e reencaminha.
Prove antes de cancelar o que quer que seja
Corra o antigo e o novo lado a lado com tráfego real e compare os resultados até os números o convencerem, e não a demonstração. Valide cada resultado mapeado contra o schema de destino e envie tudo o que falhar para uma fila que uma pessoa revê. Um modelo que para com estrondo é útil. Um que está confiantemente errado é a forma de corromper um livro de encomendas.
Já agora, mantenha os caminhos determinísticos como código simples. Onde uma regra é conhecida e estável, o código é mais rápido, mais barato e mais fácil de auditar do que qualquer modelo. O Foundry ganha o seu lugar na cauda longa, onde as regras nunca foram escritas.
E conte tudo: consumo do modelo, a engenharia de validação e de fallbacks, a responsabilidade que assume. Nada disto torna a IA gratuita. Torna a capacidade sua, a correr sob o seu modelo de identidade, os seus tetos de orçamento e a sua monitorização, em infraestrutura que já governa.
É esse o argumento todo. Menos produtos, mais alavancagem das plataformas que mantém, e uma renovação que se transforma em capacidade que a sua própria equipa controla.
Não há uma abordagem única para a cloud. É por isso que partimos da realidade da sua organização.
