A IA devia dar vantagem às empresas. Também pode criar uma nova dependência
Ainda há alguns anos, a conversa sobre vendor lock-in referia‑se sobretudo à nuvem, sistemas ERP, bases de dados ou plataformas tecnológicas críticas.
As empresas faziam perguntas: Podemos mover a aplicação para outro provedor de cloud? Podemos mudar a base de dados? Podemos abandonar um sistema específico?
Hoje a essa lista soma‑se mais um elemento – a inteligência artificial.
Organizações cada vez mais constroem sistemas que usam modelos de linguagem, IA generativa, soluções RAG, automação de processos e agentes de IA. Modelos tornam‑se parte de aplicações, processos de vendas, atendimento ao cliente, análise de documentos, sistemas de decisão e do trabalho diário das equipas.
Na prática isto significa que uma empresa pode começar a tornar‑se dependente não só de um software específico, mas também do fornecedor da inteligência que alimenta os seus sistemas.
E aqui surge o problema. Porque usar um serviço de IA é uma coisa. Estar dependente dele é outra bem diferente.
Essa é precisamente a diferença entre uma dependência tecnológica consciente e o vendor lock‑in.
O que é afinal o AI Vendor Lock‑in?
Vendor lock‑in significa uma situação em que uma organização está tão fortemente ligada a um fornecedor de tecnologia que mudar para um concorrente se torna difícil, dispendioso, moroso ou arriscado.
No universo da IA pode assumir muito mais formas do que a clássica dependência de uma única API.
A empresa pode ficar dependente de:
- um modelo de IA específico,
- um fornecedor de API concreto,
- um formato de comunicação determinado,
- funcionalidades disponíveis apenas num fornecedor,
- um sistema de agentes,
- infraestrutura cloud,
- forma de armazenamento de dados,
- um mecanismo de embeddings específico,
- um sistema RAG determinado,
- modo de chamada de ferramentas por agentes,
- prompts otimizados para um modelo concreto,
- competências da equipa centradas num único ecossistema.
Por isso a pergunta: "Usamos a OpenAI?"
é definitivamente demasiado simples.
Uma pergunta melhor seria: "Quão difícil seria para nós trocar de fornecedor de IA se tivéssemos de o fazer em seis meses?"
Se a resposta for: "Não sabemos." — isso pode ser o primeiro sinal de alerta.
OpenAI, Anthropic, Google — a escolha do fornecedor importa?
Hoje existem no mercado vários ecossistemas fortes de modelos e serviços de IA, entre eles soluções oferecidas pela OpenAI, Anthropic e Google.
Cada um desenvolve os seus próprios modelos, APIs, ferramentas e serviços adicionais.
O problema não é que algum deles seja "mau". Pelo contrário.
Usar modelos prontos e de alta qualidade é muitas vezes a melhor decisão de negócio. Nem toda a empresa deve treinar um modelo próprio. Nem todas precisam de infraestrutura GPU própria. Nem todas devem construir toda a stack de IA do zero.
Recorrer a um fornecedor externo permite entrar no mercado mais rápido, reduzir custos iniciais e aproveitar tecnologia cuja criação seria fora do alcance da maioria das organizações.
O problema começa quando a empresa deixa de ver o fornecedor como um componente intercambiável e passa a desenhar o produto como se o fornecedor escolhido fosse permanecer inalterado pelos próximos 10 anos.
E isso ninguém pode garantir...
Modelos são atualizados, versões antigas são descontinuadas, preços mudam, limites mudam, APIs evoluem, surgem novos modelos, termos de licença mudam, capacidades concorrentes evoluem.
Isso é parte normal do mercado tecnológico.
Por isso a arquitetura de IA deve considerar não só: "Qual é o melhor modelo hoje?"
mas também: "Que custo teremos se daqui a um ano quisermos usar outro?"
A maior armadilha — “basta trocar a API”
À primeira vista a migração pode parecer trivial.
Temos a aplicação. A aplicação envia pedidos ao modelo. O modelo responde. Mudamos o fornecedor. Está feito...
Na prática a situação pode ser muito diferente.
Imagine uma aplicação desenvolvida durante dois anos em torno de um único modelo.
Nesse tempo a equipa:
- criou centenas de prompts,
- otimizou o seu conteúdo,
- adaptou o formato das respostas,
- construiu um sistema RAG,
- configurou chamadas a funções (tool calling),
- criou agentes,
- projetou workflows,
- preparou testes,
- ensinou utilizadores a trabalhar com o sistema.
Após dois anos pode acontecer que o modelo deixe de estar disponível na versão utilizada.
Ou o seu preço suba, ou outro modelo competitivo seja muito superior, ou a empresa queira mover parte dos dados para outro ambiente.
Teoricamente basta trocar a API — na prática pode ser necessário retestar toda a lógica do sistema.
Por quê?
Porque modelos não são idênticos:
- Diferem na interpretação das instruções.
- Diferem na qualidade das respostas.
- Diferem no comportamento em contexto longo.
- Diferem na forma de utilizar ferramentas.
- Diferem no suporte a structured output.
- Diferem na multimodalidade.
- Diferem na latência.
- Diferem no preço.
- Diferem também no comportamento em casos limite.
Por isso a migração entre modelos pode assemelhar‑se mais à migração de um componente de negócio inteiro do que a uma mera substituição de URL.
Cinco níveis de AI Vendor Lock‑in
Vale a pena olhar para o vendor lock‑in de forma mais ampla.
1. Lock‑in do modelo
O nível mais simples.
A aplicação foi otimizada para um modelo específico.
Um prompt funciona muito bem com um modelo e pior com outro.
O sistema baseia‑se em capacidades particulares desse modelo.
Mudar implica necessidade de novo ajuste fino.
2. Lock‑in da API
O sistema usa diretamente funções específicas de um fornecedor.
Quanto mais funcionalidades específicas usamos, mais difícil pode ser a migração.
Não se trata apenas de geração de texto.
Também importam:
- structured outputs,
- function calling,
- tool calling,
- multimodalidade,
- gestão de contexto,
- mecanismos de segurança,
- sistemas de agentes.
3. Lock‑in dos dados
Dados podem estar armazenados de forma fortemente ligada a um ecossistema.
Isto inclui:
- embeddings,
- índices vetoriais,
- metadados,
- histórico de interações,
- configurações RAG.
A migração pode exigir não só mover os dados, mas também reprocessá‑los.
4. Lock‑in da arquitetura
Um nível muito mais sério.
Toda a aplicação foi concebida em torno de um fornecedor.
Os seus mecanismos estão presentes em muitos pontos do sistema.
Nesse cenário não se troca apenas um componente.
Reconstrói‑se parte da arquitetura.
5. Lock‑in organizacional
Este é muitas vezes o problema mais subestimado.
A equipa conhece um único ecossistema.
Todas as competências concentram‑se numa única solução.
Documentação, procedimentos, testes e know‑how estão ligados a um fornecedor.
Mesmo que tecnicamente seja possível mudar de modelo, a organização não tem pessoas capazes de o fazer.
Então o vendor lock‑in deixa de ser apenas um problema técnico.
Torna‑se um problema de negócio.
Multi‑Model resolve o problema?
A resposta natural é: "Se um fornecedor é risco, usemos vários."
Mas nem sempre essa é a melhor estratégia.
Arquitetura multi‑modelo tem custos.
É preciso gerir:
- múltiplas APIs,
- diferentes limites,
- modelos de preços distintos,
- níveis de qualidade variados,
- formatos de resposta diferentes,
- testes,
- monitorização,
- segurança.
O sistema fica mais complexo.
Por isso o objetivo não deve ser: "Temos de usar cinco fornecedores."
O objetivo deve ser: "Temos de ter a capacidade de mudar de fornecedor se o negócio o exigir."
Essa é a diferença essencial.
Nem toda empresa precisa de Multi‑Model.
Mas toda empresa deve saber como seria a migração para outro modelo.
AI Gateway e Model Gateway — uma camada que isola a aplicação do fornecedor
Uma maneira de reduzir dependências é introduzir uma camada intermédia.
Ela pode assumir a função de AI Gateway ou Model Gateway.
Simplificando, a arquitetura pode ser assim:
Aplicação de negócio
↓
Camada de abstração de IA
↓
Roteamento de modelos
↓
Adaptador do fornecedor
↓
OpenAI / Anthropic / Google / modelo open‑weight / modelo local
Assim a lógica de negócio da aplicação não precisa de conhecer directamente os detalhes de cada fornecedor.
Podemos ter uma camada responsável por:
- seleção de modelo,
- routing,
- fallback,
- controlo de custos,
- monitorização,
- logging,
- políticas de segurança,
- gestão de limites.
Em caso de falha de um fornecedor, o sistema pode tentar usar outro modelo.
Se os preços subirem, podemos alterar o routing.
Se surgir um modelo melhor, podemos testar e decidir migrar.
Não significa que a mudança será sempre indolor.
Significa, porém, que foi concebida como uma possibilidade real.
Model Router — a IA não tem de escolher sempre o mesmo modelo
Uma solução ainda mais interessante é o roteamento de modelos.
Imagine um sistema que recebe tarefas diversas.
Tarefa simples: "Resuma este texto."
Pode ser enviada para um modelo rápido e barato.
Tarefa mais complexa: "Analise o documento e prepare uma recomendação detalhada."
Pode ir para um modelo mais potente.
Uma tarefa que exige análise de imagem pode ir para um modelo multimodal.
O sistema pode assim seleccionar dinamicamente o modelo adequado à tarefa.
Isso permite optimizar:
- custos,
- qualidade,
- tempo de resposta,
- disponibilidade.
Neste modelo o fornecedor de IA deixa de ser parte integral da lógica de negócio.
Torna‑se um dos elementos da infraestrutura.
E essa é uma mudança arquitectónica importante.
Abstração não significa que todos os modelos são iguais
Aqui é preciso atenção a uma armadilha.
Pode‑se criar uma função: generateText() e achar que o problema está resolvido.
Não está.
Modelos não são blocos LEGO intercambiáveis.
Se a aplicação usa capacidades específicas de um modelo, uma abstração simples pode apenas esconder o problema.
Boa arquitetura deve abstrair o fornecedor, mas gerir conscientemente as diferenças entre modelos.
Na prática, a camada de IA deve saber que um modelo pode ter diferentes:
- capacidades,
- limites,
- custos,
- níveis de qualidade,
- funcionalidades,
- contextos,
- parâmetros.
Portanto ser "provider‑agnostic" não significa fingir que todos os modelos são iguais.
Significa que o sistema sabe tirar partido das diferenças entre modelos de forma consciente.
Evals — sem eles a migração de IA é um palpite
Um dos elementos mais importantes de uma arquitectura resiliente são os evals, ou seja, testes sistemáticos da qualidade dos modelos.
Suponha que temos 1000 casos reais de uso. Executamos‑nos no modelo atual. Depois no novo. Comparamos resultados.
Verificamos:
- qualidade,
- correcção,
- completude,
- alucinações,
- conformidade com requisitos,
- tempo de resposta,
- custo.
Só então podemos dizer: "O novo modelo é suficientemente bom."
Sem evals a migração pode ser um experimento. Com evals torna‑se um processo de engenharia.
Por isso uma empresa que usa IA deve construir os seus próprios conjuntos de testes. Não apenas testar a API. Testar o seu caso de negócio. Essa é uma grande diferença.
Prompt também pode ser fonte de vendor lock‑in
Trata‑se os prompts como textos, mas na prática podem tornar‑se parte da lógica de negócio.
Se ao longo de meses a equipa optimiza instruções para um modelo concreto, o prompt pode começar a funcionar como um fragmento de código.
Por isso devem ser:
- versionados,
- testados,
- documentados,
- monitorizados.
Também é importante saber quais prompts são críticos para o funcionamento do sistema. Se a mudança de modelo degrada a sua eficácia, precisamos saber onde procurar o problema.
Portanto o prompt engineering em sistemas maduros de IA deve ser cada vez mais tratado como parte da engenharia de software.
Modelos open‑weight e próprios — fuga ao vendor lock‑in?
Modelos open‑weight e a capacidade de correr modelos na própria infra aumentam o controlo tecnológico.
Mas isso não garante automaticamente independência total.
Se colocarmos um modelo na nossa infra, ainda precisamos de:
- GPUs,
- infraestrutura,
- MLOps,
- monitorização,
- segurança,
- actualizações,
- competências.
Podemos assim reduzir a dependência do fornecedor do modelo, mas aumentar a dependência do fornecedor da infraestrutura. Podemos também correr modelos open‑weight na cloud — aí o problema reaparece noutra camada. Por isso vale a pena ver a independência tecnológica de forma mais ampla.
Não existe um sistema totalmente livre de dependências.
Existe, sim, um sistema em que as dependências são:
- conhecidas,
- controladas,
- mensuráveis,
- substituíveis quando necessário.
A pior forma de vendor lock‑in pode estar na cabeça da equipa
Imagine uma empresa que usa um fornecedor de IA.
Tecnicamente pode mudar o modelo. Mas ninguém na empresa sabe como fazer isso.
A equipa não conhece alternativas.
Não há benchmarks.
Não há evals.
Não há testes.
Não há experiência com outros modelos.
Todas as soluções foram construídas em torno de um único ecossistema.
Isso é lock‑in organizacional.
Por isso a resiliência ao vendor lock‑in também exige investimento em competências.
A equipa deve entender:
- como os modelos funcionam,
- quais as diferenças entre fornecedores,
- como construir camadas de abstração,
- como testar modelos,
- como medir qualidade,
- como gerir custos,
- como executar uma migração.
Não se trata que cada programador conheça todas as APIs.
Trata‑se de evitar que a organização fique tecnologicamente cega para além de um único ecossistema.
Quando o vendor lock‑in pode ser aceitável?
Vendor lock‑in nem sempre é mau.
Por vezes uma dependência consciente é uma decisão de negócio sensata.
Se:
- o fornecedor oferece uma funcionalidade excepcional,
- a solução reduz significativamente o tempo de implementação,
- o custo de migração é conhecido,
- o risco é aceitável,
- as alternativas são mais fracas,
- o negócio precisa de velocidade,
uma ligação mais forte a um fornecedor pode estar justificada.
O problema não é o lock‑in em si. O problema é o lock‑in inconsciente.
A empresa deve saber:
- de que depende,
- por que depende,
- quanto custaria mudar,
- quanto tempo duraria a migração,
- quais as alternativas.
Só então se pode falar numa decisão arquitectónica consciente.
Como avaliar o AI Vendor Lock‑in na sua empresa?
Vale a pena fazer uma auditoria simples.
Façamos algumas perguntas:
Podemos trocar de modelo sem refazer toda a aplicação?
A lógica de negócio é independente do fornecedor de IA?
Os prompts são versionados?
Temos nossos próprios evals?
Temos testes de regressão para os casos de uso mais importantes?
Podemos exportar e migrar os dados?
Podemos trocar o fornecedor de embeddings sem perder dados?
Os agentes usam uma camada de orquestração ou estão directamente ligados a um ecossistema?
Temos a capacidade de aplicar um modelo alternativo?
Temos fallback?
Saberíamos quanto custaria a migração?
Saberíamos quanto tempo demoraria a migração?
Temos pessoas capazes de a realizar?
Quanto mais respostas "não", maior a dependência.
Também se pode criar um AI Portability Score interno. Por exemplo avaliar a organização em cinco áreas:
Arquitetura - o fornecedor é intercambiável?
Dados - podemos migrá‑los?
Modelos - temos alternativas?
Avaliação - conseguimos comparar modelos?
Competências - a equipa consegue executar a migração?
Esse resultado não precisa de ser um standard formal. Pode ser, contudo, uma excelente ferramenta de gestão.
Porque por vezes o maior problema não é o vendor lock‑in. É o facto da empresa nem saber que o tem.
Como desenhar uma arquitectura de IA resistente a mudanças?
Não existe uma arquitectura universal. Mas há princípios práticos a adoptar.
Princípio 1 — separe a lógica de negócio do fornecedor de IA
Não construa todo o sistema directamente em torno de uma única API.
Princípio 2 — aplique camada de abstração onde faz sentido
AI Gateway ou Model Gateway podem reduzir a dependência da aplicação em relação a um fornecedor.
Princípio 3 — versione prompts
Trate‑os como parte do sistema, não como textos soltos.
Princípio 4 — construa evals
Não presuma que "o novo modelo funciona".
Verifique isso.
Princípio 5 — teste alternativas
Não precisa usá‑las em produção, mas vale a pena saber como se comportam nos seus casos de uso.
Princípio 6 — controle os dados
Não permita que os seus dados de negócio se tornem reféns de uma plataforma única.
Princípio 7 — documente dependências
Saber onde o sistema está ligado a um fornecedor deve fazer parte da documentação arquitectónica.
Princípio 8 — não abstraia exageradamente
Não esconda as diferenças entre modelos apenas para obter uma aparente portabilidade.
Princípio 9 — mensure o custo da migração
Não basta dizer:
"Algum dia podemos mudar de fornecedor."
É preciso saber:
"Precisamos de três meses e cinco pessoas."
Ou:
"Não somos capazes de o fazer sem reconstruir o sistema."
Princípio 10 — tome decisões conscientemente
Por vezes o melhor é ligar‑se fortemente a um fornecedor.
Mas isso deve ser um risco ponderado e consciente.
Não um acidente.
A pergunta que todo CTO deveria fazer
Imagine que amanhã o fornecedor de IA:
- dobra os preços,
- descontinua o modelo que usamos,
- altera limites,
- limita uma função da qual depende o nosso produto,
- deixa de cumprir os nossos requisitos de compliance.
O que fazemos?
Se a resposta for: "Vamos trocar de fornecedor."
a pergunta seguinte deve ser: "Quanto tempo isso nos levaria?"
Um dia?
Uma semana?
Um mês?
Meio ano?
Ou talvez não saibamos?
Essa é a medida da nossa resiliência tecnológica.
Resumo — não se trata de não ter fornecedores
Construir um sistema completamente independente de fornecedores externos de IA pode ser caro, desnecessário ou até impossível.
Não é isso que importa.
O objetivo não é ausência de dependências. O objetivo é a gestão consciente dessas dependências.
Podemos usar OpenAI. Podemos usar Anthropic. Podemos usar Google. Podemos usar modelos open‑weight. Podemos combinar várias soluções.
O mais importante é saber onde fica a fronteira entre: "usar tecnologia" e "estar dependente dela".
No mundo da IA essa fronteira pode ser especialmente difícil de ver. Vendor lock‑in não acontece num dia. Acontece gradualmente. Primeiro integramos uma API. Depois construímos uma funcionalidade. Depois adicionamos RAG. Depois agentes. Depois automatizamos processos. Depois toda a equipa começa a trabalhar segundo esse sistema. E de repente mudar de modelo já não é só mudar de modelo — é mudar parte da organização.
Por isso a arquitectura de IA deve ser desenhada pensando não apenas no que funciona hoje, mas também no que acontecerá se o mundo tecnológico mudar amanhã.
Não precisa de construir um sistema que funcione sem OpenAI, Anthropic ou Google. Deve, contudo, construir um sistema que também consiga funcionar caso um deles deixe de existir.
Essa é a diferença entre usar IA e desenhar conscientemente tecnologia de IA.
