Model lock-in: a dependência que ninguém planeja

O lock-in que todo mundo conhece — e o que ninguém orça

Todo time de engenharia que se preza tem uma opinião sobre vendor lock-in. Discute-se por horas se um banco de dados proprietário da AWS prende a empresa cedo demais a um provedor de nuvem. Pesa-se se uma ferramenta SaaS tranca os próprios dados em um formato do qual não se sai mais. Existem princípios de arquitetura para isso, posts de blog, carreiras inteiras de consultoria. Lock-in de nuvem e lock-in de SaaS são riscos já precificados.

E aí esse mesmo time conecta o seu produto novo mais importante ao modelo de um único fornecedor — os prompts ajustados às manias desse modelo, as chamadas de ferramenta moldadas no formato JSON desse modelo, um fine-tune treinado sobre a base desse modelo, os evals rodados exclusivamente contra esse único modelo — e ninguém chama isso de risco. Não aparece em nenhum architecture review, em nenhum plano de custos, em nenhuma lista de riscos.

Essa é a dependência que ninguém planeja. Model lock-in é vendor lock-in, só que sem a vigilância que o vendor lock-in costuma merecer. E como o modelo é a camada onde o valor de fato é criado — ele escreve a resposta, faz a classificação, extrai os dados —, o fornecedor acaba segurando exatamente a alavanca que decide a sua margem.

Como o lock-in se instala

Ninguém decide numa segunda de manhã se amarrar a um fornecedor para sempre. O lock-in se acumula como a soma de decisões individuais sensatas, cada uma certa por si, uma algema no conjunto.

Prompts ajustados às manias de um modelo. Você começa com um prompt genérico e ele funciona mais ou menos. Então você começa a lapidar. Percebe que esse modelo responde melhor quando você embrulha as instruções em tags XML. Que ele precisa de exemplos no system prompt onde outro se vira com uma instrução seca. Que uma formulação específica o deixa confiável e uma minimamente diferente o deixa instável. Três meses depois, o prompt é um instrumento finamente calibrado — afinado às idiossincrasias desse único modelo. Em qualquer outro a qualidade cai de forma perceptível, e ninguém sabe mais quais das quarenta decisões de prompt são estruturais e quais são superstição.

Recursos específicos do fornecedor. É aqui que a amarração fica técnica. As Structured Outputs da OpenAI com JSON schema estrito garantem JSON válido de um jeito que não é padrão aberto nenhum. O formato de tool-calling difere entre os fornecedores em mais do que cosmética — a estrutura das chamadas, o schema dos argumentos, como as chamadas paralelas de ferramenta voltam. Quem constrói a lógica do agente diretamente contra o formato tools da OpenAI está construindo contra uma API concreta, não contra uma abstração. Migrar para o formato tool-use da Anthropic ou o function calling do Google deixa de ser troca de configuração e vira reescrita.

Fine-tunes sobre exatamente um modelo-base. Essa é a armadilha mais cara, porque parece progresso. Você reúne um conjunto de treino limpo, faz fine-tune sobre gpt-3.5-turbo ou gpt-4o-mini, e os resultados são excelentes. O que você construiu é um ativo que você não possui: os pesos pertencem ao fornecedor, o modelo só roda na infraestrutura dele e está preso a um snapshot específico. Quando o fornecedor aposenta esse modelo-base — e ele aposenta —, o fine-tune não é portável; tem de ser retreinado do zero contra uma base nova. Você não construiu um modelo. Você treinou uma dependência.

Evals contra um só modelo. O mecanismo mais silencioso de todos. Você monta uma suíte de testes para medir o seu recurso de IA — e a roda exclusivamente contra o modelo de produção, porque é ele que importa. Com isso, a suíte de evals deixa de ser um instrumento neutro e passa a estar implicitamente calibrada aos padrões de resposta desse único modelo. Você já não consegue responder em uma hora como o modelo de um concorrente se sai na mesma tarefa. A pergunta "devemos trocar?" fica sem resposta, porque falta a ferramenta para respondê-la. E uma pergunta que não se consegue responder, uma hora se para de fazer.

O dia em que a conta chega

Enquanto o fornecedor se comporta de forma benigna, o lock-in não custa nada. Essa é a armadilha: a conta só chega quando os seus interesses e os dele divergem — e aí ela chega de três formas.

O fornecedor aumenta os preços. Os preços de inferência caíram na maior parte dos últimos anos, o que tenta a gente a supor que sempre cairão. Mas o preço não é o ponto — o poder de preço é. Quem não tem opção de saída não negocia. Quando o fornecedor introduz um tier de prioridade para o seu volume, reestrutura a precificação para janelas de contexto grandes, ou simplesmente corta o desconto que você tinha orçado, a pergunta não é se você acha aquilo justo. A pergunta é qual é a sua alternativa dentro de duas semanas. Sem portabilidade, a resposta é: nenhuma. O seu fornecedor então tem acesso direto à sua margem, e ele sabe disso.

O fornecedor aposenta o modelo. Isso não é preocupação hipotética, é o caso comum. A OpenAI aposentou os antigos snapshots gpt-4-0314 e gpt-3.5-turbo-0613, enterrou toda a era Completions junto com o text-davinci-003 e dobrou o gpt-4-vision-preview num sucessor. O Google desligou toda a API PaLM junto com o text-bison e redirecionou todo mundo para o Gemini. A Anthropic mandou o Claude 2 para a aposentadoria. Modelos têm ciclos de vida de meses a poucos anos, não de décadas. Quem fixou um snapshot específico — por bom motivo, porque fixar é a única defesa contra mudanças silenciosas de comportamento — uma hora recebe um e-mail com uma data de desligamento. E aí o relógio corre, convenha ou não.

O fornecedor degrada a qualidade em silêncio. O caso mais traiçoeiro. Um modelo por trás do mesmo nome de API recebe uma atualização, e o comportamento muda — às vezes melhor, às vezes pior, às vezes só diferente. Os seus prompts cuidadosamente ajustados estavam calibrados contra um alvo em movimento. Sem uma suíte de evals que você possa rodar com um clique, você não percebe a mudança como número, mas como uma maré difusa de tickets de suporte três semanas depois. E mesmo que perceba: qual é a sua jogada quando você está acorrentado exatamente a esse modelo?

Os três casos têm o mesmo núcleo. O problema não é o fornecedor se comportar mal — fornecedores se comportam de forma sensata do lugar onde estão. O problema é a assimetria: eles podem agir, e você só pode reagir.

Portabilidade como trabalho de engenharia

A boa notícia: portabilidade não é questão de esperança, é questão de como se constrói. Quatro medidas, em ordem crescente de esforço.

• Uma camada fina de abstração ou gateway. Em vez de chamar o SDK de um fornecedor direto de todo canto do código, você chama uma interface interna enxuta atrás da qual o fornecedor é trocável. Você não precisa construir isso sozinho: o LiteLLM coloca um proxy compatível com OpenAI na frente de mais de cem fornecedores, o OpenRouter roteia a mesma requisição para modelos diferentes, o Vercel AI SDK abstrai as diferenças de provedor numa interface comum, o AI Gateway da Cloudflare e o Portkey ficam no meio como intermediários neutros. O ponto não é a ferramenta específica, mas que o nome do fornecedor viva em um lugar do código, não em quarenta.
• Prompts agnósticos de fornecedor. Escrever prompts que se sustentam pelo sentido, não por um truque de modelo. Tags XML onde estruturam, mas não como culto. Separar as instruções estruturais das cosméticas e documentar quais estão ali e por quê. Um prompt que você consegue explicar é um prompt que você consegue portar.
• Uma suíte de evals que roda contra qualquer modelo. Essa é a medida de maior alavancagem de todas. Quem tem uma suíte de testes que pode rodar de forma independente de fornecedor contra qualquer modelo, transforma a pergunta "devemos trocar?" de guerra santa em uma medição da noite para o dia. Você vê preto no branco o que uma troca custa ou rende em qualidade — e é esse número a diferença inteira entre uma opção de saída real e a mera sensação de que você tem uma.
• Um fallback de peso aberto. Como expusemos num artigo anterior sobre LLMs de peso aberto versus a API, a distância para a fronteira já é pequena o bastante em muitas tarefas para que um modelo rodado por conta própria — Llama, Mistral, Qwen — seja um plano B realista. Você não precisa rodá-lo em produção. Basta que a arquitetura pudesse: aí nenhum fornecedor de API tem mais a certeza de que você não tem escolha. E um fine-tune sobre um modelo de peso aberto entrega algo que um fine-tune hospedado nunca entrega — pesos que são seus.

O preço da abstração

Agora o outro lado honesto, senão uma observação certa azeda num dogma caro. Portabilidade não é de graça, e abstração prematura é um imposto por si só.

Uma camada de abstração que se propõe a suportar todos os fornecedores converge inevitavelmente para o menor denominador comum. Justamente os recursos que tornam um único modelo superior — o schema estrito de Structured Outputs da OpenAI, o comportamento de tool-calling que encaixa perfeito, uma janela de contexto especialmente grande, o prompt caching de um fornecedor específico — são os recursos que não passam pela camada neutra. Manter tudo portável hoje é abrir mão do melhor que está disponível hoje — como seguro contra uma troca que você talvez nunca faça.

E esse seguro tem um prêmio corrente: velocidade. Cada indireção que você mantém, cada prompt que você achata para a média medíocre entre vários modelos, cada eval que você mantém duplicado por neutralidade de fornecedor é tempo que não vai para o produto. Para muitos times — sobretudo no começo, sobretudo quando um modelo resolve a tarefa claramente melhor — "apostar num modelo excelente e ser rápido" ganha do hedging com folga. Uma startup que constrói o protótipo com o modelo mais forte disponível na metade do tempo ganha mais do que a portabilidade teórica jamais lhe pouparia.

A saída não está em nenhum extremo. Lock-in não é um interruptor, é um espectro, e o objetivo não é acoplamento zero — isso é impagável e quase sempre desnecessário. O objetivo é uma saída barata. Você pode apoiar-se com força no melhor recurso de um modelo, desde que saiba onde esse acoplamento está e quanto custaria desfazê-lo. O lock-in caro nunca é o deliberado; é o que ninguém tinha na lista. Um fine-tune cujo custo de reposição você conhece é uma decisão. Um fine-tune que você só descobre não ser portável quando chega o e-mail de aposentadoria é um acidente.

Conclusão

Lock-in de nuvem e lock-in de SaaS estão em toda lista de riscos porque os times aprenderam a temê-los. Model lock-in não está em nenhuma, porque a camada do modelo é nova e se instala por baixo do pano — um prompt ajustado aqui, um recurso específico de fornecedor ali, um fine-tune que parece ativo e é na verdade dependência. Até o dia em que o preço sobe, o modelo é aposentado ou a qualidade escorrega em silêncio — e você descobre que não tem jogada.

A lição não é evitar todo acoplamento. É tornar o acoplamento uma decisão deliberada em vez de um acidente operacional. Saiba onde você está amarrado, saiba o preço de se desamarrar, e mantenha esse preço baixo o bastante para que "vamos trocar" continue sendo uma opção real e não um desejo piedoso.

É exatamente assim que trabalhamos na NH Labs. Usamos o modelo que melhor resolve cada tarefa — recursos específicos de modelo incluídos, quando fazem a diferença. Mas embaixo há sempre uma abstração fina e uma suíte de evals portável que rodamos contra qualquer modelo com um clique. Isso mantém a troca como uma medição de uma noite em vez de um rewrite de um trimestre — e impede que os nossos clientes virem reféns de uma única tabela de preços.