As seis armadilhas do lock-in em provedores de inferência de IA

O mito da compatibilidade OpenAI

Todo provedor de inferência de LLMs anuncia a mesma coisa: “somos compatíveis com a API da OpenAI”. A promessa implícita é que migrar de um provedor para outro é uma simples troca de URL e chave de API. Na prática, porém, a compatibilidade no transporte não se traduz em portabilidade real.

O artigo publicado pela DigitalOcean detalha as seis superfícies onde o lock-in se acumula silenciosamente em sistemas de produção — e por que trocar de provedor de inferência é um projeto de engenharia, não uma mudança de configuração.

As seis superfícies do lock-in

1. Calibração de prompts

Cada modelo responde de forma diferente ao mesmo prompt — mesmo entre modelos “compatíveis”. Instruções de formatação que funcionam perfeitamente no GPT-4o produzem saídas inconsistentes no Claude ou no Gemini. Migrar significa reexecutar toda a suíte de avaliação automatizada para cada prompt em produção e reajustar os que regridem. Para uma equipe com 40 prompts em produção, isso leva dias ou semanas.

2. Suposições sobre formato de saída

O suporte a structured output (JSON garantido) varia radicalmente. O modo estrito da OpenAI sempre produz JSON válido. O da Anthropic tem exceções documentadas para truncamento. Together.ai e Fireworks exigem que você reescreva o schema no próprio prompt. Um sistema que depende de JSON estruturado para sua lógica de negócio não pode simplesmente trocar de provedor sem reescrever o parser de saída.

3. Tratamento de erros e retry

Cada provedor retorna códigos de erro diferentes sob carga. O que é um 429 (rate limit) em um provedor pode ser um 503 (serviço indisponível) em outro. A lógica de retry com backoff exponencial calibrada para um fornecedor pode ser agressiva demais (gerando mais erros) ou lenta demais (degradando a experiência do usuário) em outro.

4. Arquitetura de cache

As regras de prompt caching são substancialmente diferentes. A Anthropic cobra um premium de escrita com TTL curto (5 minutos padrão). O caching da OpenAI é majoritariamente automático. O Google cobra uma taxa de armazenamento separada que nenhum outro provedor cobra. Um sistema que depende de cache para reduzir custos em 80% pode ver esse número despencar ao trocar de provedor.

5. Calibração de custos

Dois modelos com o mesmo preço por token podem ter custos reais muito diferentes. As duas maiores causas são: diferenças de tokenização (o mesmo texto gera contagens de tokens diferentes em cada modelo) e tokens de raciocínio invisíveis, que são cobrados como saída mesmo que o usuário nunca os veja. Modelos como o o1 da OpenAI geram milhares de tokens internos de raciocínio que entram na conta.

6. Ferramental operacional

Logging, monitoramento, painéis de custo, alertas — todo o ferramental operacional construído em torno de um provedor específico precisa ser reescrito ou reconfigurado. Não é só trocar a URL da API; é trocar o pipeline de observabilidade inteiro.

A camada contratual: o que “sem lock-in” realmente significa

Os contratos de nível de serviço (SLAs) e políticas de depreciação de modelos são, surpreendentemente, mais transparentes nos provedores mais associados ao risco de concentração. OpenAI e Anthropic publicam políticas detalhadas de depreciação e aviso prévio para mudanças de preço. Vários provedores menores, ironicamente comercializados como “lock-in-free”, são menos transparentes nesses pontos.

Mas um aviso de depreciação generoso não ajuda se seus prompts, parsers e lógica de retry estão calibrados para o comportamento específico daquele provedor. Liberdade contratual e portabilidade prática são coisas diferentes.

Quando aceitar lock-in é a decisão racional

O artigo argumenta que há cenários onde o lock-in é a escolha de engenharia correta. Se você está usando structured output estrito da OpenAI como parte crítica do seu pipeline, a confiabilidade dessa feature específica pode valer mais do que a liberdade teórica de trocar de provedor. A portabilidade tem um custo de desenvolvimento e manutenção — e esse custo precisa ser comparado ao risco real de precisar migrar.

O investimento de maior retorno contra lock-in

Não é uma camada de abstração. É uma suíte de avaliação automatizada. Ter um conjunto de testes que roda contra cada prompt de produção, comparando saídas esperadas com reais, é o que permite migrar de provedor com confiança. Gateways de API devem lidar apenas com autenticação, transporte e logging — abstrair a lógica de prompts tende a custar mais e produzir saídas piores do que manter versões específicas por provedor.

O que isso significa para o ecossistema brasileiro

No Brasil, onde muitas empresas estão começando a integrar LLMs em produção, a lição é preventiva: projete para avaliação automatizada desde o primeiro dia. Não espere ter 40 prompts em produção para descobrir que mudar de provedor é um projeto de semanas. Invista em testes automatizados de saída, documente os pressupostos de formato e mantenha a lógica de retry configurável — não hardcoded para um fornecedor específico.