Dependência de fornecedor de IA: o teste de saída que eu rodo antes de assinar

Dependência de fornecedor de IA se mede em dias para trocar, não em preço por token. Os dois caminhos de arquitetura, o custo de cada um e o teste de saída que roda numa tarde.

Contar em quantos arquivos o SDK do fornecedor aparece leva uma tarde e vale mais que a tabela de preço por token

Antes de colocar um fornecedor de IA no caminho crítico do seu produto, meça uma coisa: quantos dias o seu time leva para arrancar esse fornecedor e pôr outro no lugar, com o produto no ar e o cliente sem perceber nada. Esse número é a sua dependência de fornecedor de IA, e ele já está decidido antes da primeira chamada de API.

Existem duas respostas típicas. Na primeira, a chamada do modelo está espalhada pelo código, dentro da regra de negócio, com o formato de resposta do fornecedor vazando para o banco e para a tela. Trocar aí é projeto. Nos resgates que caem na minha mão, o padrão é uns 11 pontos de chamada espalhados, dois deles em lugar que ninguém lembrava, e a troca vira perto de mês e meio de trabalho, com regressão em cima de coisa que já funcionava.

Na segunda, a chamada vive atrás de uma fronteira sua: uma interface com dois ou três métodos que o resto do sistema conhece, e mais nada. Trocar aí é tarefa de dois a quatro dias, mais o tempo de comparar a qualidade da saída nova. Essa fronteira cobra adiantado, algo entre 2 e 5 dias na primeira implementação, e é o pedaço mais barato do projeto.

A diferença é a mesma da obra. Tubulação embutida na laje funciona igual à que passa por um shaft com tampa de acesso, todos os dias, até o dia da troca. Aí uma custa um parafuso e a outra custa quebrar concreto.

O CIO publicou ontem um texto sobre o dia em que um fornecedor de IA fecha as portas ou é comprado, e o veículo usa a compra da VMware pela Broadcom como retrato do que está em jogo: o produto continua existindo, o contrato que você assinou não. Seu fornecedor pode durar trinta anos. O problema é que você não sabe o número de dias, e quem não sabe o número aceita o reajuste que vier.

Dias para trocar é o número que você leva para a reunião de renovação

Tubulação em shaft com tampa de acesso custa um pouco mais na obra e um parafuso no dia da troca

Preço por mil tokens muda de trimestre em trimestre e não protege ninguém. O número que protege é o prazo de saída, e ele serve para três conversas diferentes: a renovação do contrato, a diligência de quem investe e a reunião em que alguém propõe usar o mesmo fornecedor para mais uma função do produto.

Quando o prazo de saída está medido, a renovação muda de lado. Com saída de três dias, aumento agressivo é problema do fornecedor. Com saída de seis semanas, é problema seu, e ele costuma saber disso antes de você.

Vale também para o caso feliz, que é o mais frequente. Modelo novo aparece a cada poucos meses, mais barato ou melhor em uma tarefa específica. Quem tem fronteira testa num fim de semana. O orquestrador de crescimento que eu escrevo por diversão trocou de modelo mais de uma vez este ano, e cada troca durou uma tarde, porque o resto do sistema nunca soube qual fornecedor estava atrás da interface.

Na laje ou no shaft: onde a chamada do modelo mora

Fronteira aqui não quer dizer camada genérica de abstração com quinze parâmetros para cobrir todos os fornecedores do mundo. É uma interface escrita no vocabulário do seu negócio: classificar o pedido, extrair os campos da nota, resumir o contrato. O que entra e o que sai são tipos seus, validados na porta. O JSON cru do fornecedor morre ali dentro e não passa para o resto do sistema.

Três coisas ficam do seu lado dessa porta, e são elas que derrubam o prazo. O prompt em arquivo versionado, com histórico de quem mudou o que e por quê. A validação do retorno, porque modelo novo erra formato de um jeito novo e você precisa descobrir isso no teste, não no cliente. E o registro de entrada e saída de cada chamada, que é o único jeito de comparar o fornecedor novo com o antigo sem achismo de reunião.

O detalhe que mais vejo dar errado tem a ver com quem escreveu essa integração. Agente de IA escreve do jeito mais curto, e o mais curto é chamar o SDK direto de dentro do serviço, com o modelo escolhido em string no meio do arquivo. Se ninguém revisa com esse olho, a dívida técnica que o agente deixa aparece exatamente no dia em que você precisa de velocidade para sair.

O teste de saída, rodado numa tarde

O prazo de saída precisa estar escrito antes da assinatura, não descoberto na reunião de renovação

1. Conte em quantos arquivos o SDK do fornecedor aparece. Se o número for maior que a quantidade de casos de uso que ele atende, você já tem a resposta sobre o prazo.
2. Procure o formato deles persistido no seu banco: identificador de resposta, estrutura de mensagens, nome do modelo gravado em coluna. Cada ocorrência dessas é migração de dados no dia da troca, e migração de dados não cabe em uma tarde.
3. Tente apontar, em dez segundos, o arquivo onde está o prompt. Se o prompt vive em string no meio de um serviço, alguém vai reescrever prompt sob pressão, com o fornecedor já desligado.
4. Pergunte quem já rodou o mesmo caso de uso em um segundo fornecedor e onde está o comparativo salvo. Sem esse arquivo, trocar deixa de ser engenharia e passa a ser aposta.

Anote os quatro resultados e converta em dias de trabalho com o time que você tem hoje, não com o time ideal do slide. Esse número é o seu custo de saída. Escreva ele no mesmo lugar onde está guardado o contrato, porque é lá que alguém vai procurar quando a notícia chegar.

"Isso é frescura de arquitetura, eu preciso lançar em três semanas"

Concordo em parte, e vale dizer em voz alta: para uma validação de três semanas que pode morrer no mês seguinte, fronteira é custo sem retorno. Embuta, lance, descubra se alguém paga. Eu faria igual.

O que não funciona é a frase "depois a gente arruma" sem gatilho escrito. O gatilho que eu uso é simples: no dia em que a função entra num fluxo que o cliente paga, ou passa a rodar sem gente olhando, a fronteira entra junto, antes da próxima feature. É a mesma lógica de migrar um pouco por sprint em vez de parar tudo para trocar: o trabalho é quase o mesmo, o preço é outro quando feito com o prazo estourando.

E tem a conversa de antes da assinatura, que é onde isso custa zero. Se você contrata gente de fora para integrar, as perguntas que dão para fazer sem ler código ganham uma bem específica: em que ponto do sistema fica a chamada do fornecedor, e o que exatamente eu troco se ele sair do mercado. A resposta vem na hora ou não vem.

O pedaço que não dá para isolar

Fronteira derruba a troca de projeto para tarefa, nunca para zero, e quem promete zero está vendendo. Três coisas continuam presas do lado de lá:

• O prompt calibrado para o jeito daquele modelo responder, que no concorrente rende diferente e exige ajuste fino de novo.
• O que foi treinado ou indexado na casa deles: ajuste fino do modelo, base vetorial, histórico de conversa, avaliações acumuladas.
• A latência e o limite de contexto que você usou como premissa de produto, e que podem não existir igual no próximo.

Dá para reduzir as três com disciplina chata. Exportação do que é seu escrita no contrato, em formato aberto e com prazo em dias. Seu próprio conjunto de casos de avaliação guardado fora do fornecedor, porque cobertura que não compara saída não garante nada. Uns trinta casos reais com a resposta esperada já dizem, numa tarde, se o fornecedor novo serve para o seu caso ou só para o benchmark dele.

O prazo que você consegue dizer em voz alta

Responda sem consultar ninguém: se o seu fornecedor de IA avisasse hoje que encerra em 30 dias, qual pedaço do produto para de funcionar, e em quantos dias você volta ao ar? Se a resposta começa com "preciso ver com o time", o risco não está no balanço do fornecedor. Está no seu código.

Conte os pontos de chamada hoje. Leva uma tarde e você sai com um número. Depois escolha com calma: deixa na laje ou passa pelo shaft. As duas opções se defendem numa reunião, desde que a escolha seja sua e esteja escrita em algum lugar antes de a notícia sair.