Você escolheu o fornecedor pelo preço. Ele escolheu os limites do seu produto.

Uma startup de SaaS fecha o ano com margens melhores do que o esperado. O motivo: escolheu o modelo de linguagem mais barato por token, integrou tudo via SDK proprietário e partiu para o produto. Dezoito meses depois, o modelo escolhido começa a perder desempenho em casos de uso mais complexos. A empresa tenta migrar. Descobre que o contexto está armazenado em um formato exclusivo do provedor, que os embeddings — representações numéricas do significado de textos, usadas para busca e memória — foram gerados pela API deles, e que o SDK cobre abstrações que não existem em nenhum concorrente. Migrar significa reescrever o núcleo do produto.

Isso não é um caso isolado. É o padrão.

O que parece decisão técnica é decisão estratégica

Quando a equipe de engenharia pergunta "qual SDK vamos usar?", parece uma escolha de infraestrutura. Não é. É uma aposta sobre quem vai controlar as capacidades do seu produto daqui a dois anos.

Três decisões arquiteturais concentram a maior parte do risco de dependência:

• Qual SDK ou framework usar. SDKs proprietários de provedores específicos costumam expor funcionalidades exclusivas que não existem em alternativas abertas. Conveniente no início, problemático quando você quer trocar.
• Como e onde armazenar contexto. Contexto é o histórico e as informações que o modelo usa para responder de forma coerente. Se ele fica em formato ou banco de dados atrelado ao provedor, sair significa perder memória do produto.
• Onde rodar os embeddings. Embeddings gerados por um modelo específico não são diretamente compatíveis com outro. Trocar de provedor pode invalidar toda a base vetorial que sustenta busca, recomendação e memória de longo prazo.

Cada uma dessas escolhas, individualmente, parece razoável. Em conjunto, formam uma corrente.

Por que o custo de saída cresce invisível

O problema não aparece no primeiro trimestre. Ele cresce silencioso enquanto a empresa escala.

No início, o produto tem dez funcionalidades usando o modelo. Com o tempo, passa para cinquenta. Cada nova feature assume os mesmos padrões arquiteturais das anteriores. Quando a empresa percebe que quer negociar preço, testar um modelo concorrente ou adicionar uma capacidade que o provedor não suporta, o custo de saída já não é técnico: é estratégico. Mudar significa parar o roadmap por meses, reescrever lógica de negócio e, em muitos casos, degradar temporariamente a experiência do usuário.

O provedor não fez nada errado. Ele simplesmente ficou indispensável enquanto você não estava prestando atenção.

Como avaliar seu grau de dependência hoje

Existe uma pergunta simples que revela muito: se o seu provedor principal de LLM subir o preço em 40% amanhã, o que você faz?

Se a resposta for "pagamos", você já tem o diagnóstico. Mas há formas mais precisas de mapear o risco antes que ele vire custo real:

• Teste de substituição parcial. Escolha uma funcionalidade não crítica e tente rodar com um modelo alternativo sem mudar a arquitetura. Se não der para fazer em menos de uma semana, a dependência já é estrutural.
• Inventário de superfície proprietária. Liste quantas chamadas de API, tipos de resposta e formatos de dados no produto existem apenas na documentação do provedor atual. Quanto maior a lista, maior a âncora.
• Custo de portabilidade dos embeddings. Estime o tempo e o custo de regenerar toda a base vetorial com um modelo diferente. Em produtos com anos de dados, isso pode ser a barreira mais cara.

Não é sobre trocar de provedor. É sobre ter a opção.

A estratégia correta não é necessariamente usar múltiplos provedores ao mesmo tempo — isso adiciona complexidade operacional sem benefício imediato. A estratégia é construir com portabilidade suficiente para que a opção exista quando você precisar.

Na prática, isso significa algumas escolhas deliberadas desde o início:

• Preferir frameworks de orquestração agnósticos (que funcionam com vários provedores) em vez de SDKs proprietários quando a funcionalidade for equivalente.
• Armazenar contexto e histórico em formatos abertos, independentes do provedor.
• Gerar embeddings com modelos que têm alternativas reais no mercado ou, quando possível, com modelos próprios rodando em infraestrutura própria.
• Documentar internamente quais partes do produto dependem de capacidades exclusivas de um fornecedor específico.

Nenhuma dessas escolhas é gratuita. Elas custam um pouco mais de tempo no início. O que elas evitam é chegar em uma reunião de planejamento estratégico e descobrir que a arquitetura técnica já tomou a decisão por você.

O que levar desta leitura

Antes do próximo sprint de desenvolvimento ou da próxima renovação de contrato com seu provedor de LLM, vale fazer uma pergunta para o time: quais partes do nosso produto só funcionam com este fornecedor específico?

Se ninguém souber responder com clareza, esse é o primeiro problema a resolver. Não porque a resposta precise ser "nenhuma" — dependências razoáveis existem e são aceitáveis. Mas porque uma empresa que não conhece suas próprias dependências não está tomando decisões estratégicas. Está sendo levada por elas.