Uma pequena empresa contrata um fornecedor de IA para atender cliente, gerar orçamento ou produzir conteúdo. Em poucos meses, a ferramenta vira parte da operação — a equipe aprende os comandos certos, o processo passa a depender dela, os relatórios saem sem esforço. Quase ninguém para para perguntar o que acontece quando esse fornecedor dobra o preço, descontinua a funcionalidade usada todo dia, ou aposenta o modelo de IA que roda por trás da interface. Essa pergunta costuma chegar tarde — só depois que o aviso de mudança já caiu na caixa de entrada.
IA não é como trocar de planilha: o motivo técnico
Trocar de fornecedor de planilha ou de CRM é trabalhoso, mas previsível: o dado exporta num formato padrão e a lógica do sistema não muda de comportamento sozinha enquanto ninguém mexe nela. Com IA generativa, a mecânica é outra. O mesmo comando — “resuma este contrato destacando os riscos” — pode produzir um resultado consistente num modelo e um resultado genérico ou impreciso em outro, porque cada modelo é treinado com dado próprio, passa por um ajuste de comportamento próprio (o processo que calibra tom, formato de resposta e limites do que o modelo aceita fazer) e opera com uma janela de contexto própria. Não existe “prompt universal” que funcione de forma idêntica em qualquer motor de IA — o comando é, na prática, ajustado ao modelo específico que está respondendo.
Some a isso um fator que a maioria das empresas desconhece: fornecedores de modelo de IA aposentam versões com regularidade, publicando aviso de alguns meses antes de desativar a versão antiga. Quando isso acontece, a ferramenta que a empresa usa no dia a dia pode trocar de motor por baixo do capô mesmo sem a empresa trocar de fornecedor — e o mesmo comando que funcionava bem meses atrás passa a responder diferente, exigindo reajuste de prompt que ninguém previu no orçamento nem no cronograma do trimestre.
As quatro camadas de dependência que a pequena empresa não vê
Dependência de fornecedor de IA raramente aparece como uma linha única no contrato — ela se acumula em quatro camadas distintas, cada uma mais cara de desfazer do que a anterior:
1. Dado. Histórico de conversa, base de conhecimento carregada, resultado de cada interação — tudo isso costuma viver só dentro do formato proprietário do fornecedor, sem exportação simples para uso em outro lugar.
2. Prompt e regra de negócio. As instruções refinadas ao longo de meses — o que a IA deve aprovar, como deve responder, o que nunca deve fazer sem checagem humana — normalmente só existem dentro da configuração da própria ferramenta, nunca documentadas em nenhum lugar fora dela.
3. Integração. Chamadas de API específicas desse fornecedor, embutidas em automações de planilha, no chatbot do site ou no sistema de atendimento — cada uma é um ponto que precisa ser reescrito, não copiado, numa eventual troca.
4. Conhecimento da equipe. As pessoas aprenderam a operar aquela interface específica — os atalhos, os limites, os jeitos de contornar erro comum — e não necessariamente o raciocínio de negócio por trás da tarefa, que é o que de fato precisaria sobreviver a uma migração.
Três perguntas antes de aprofundar o uso de um único fornecedor
Nenhuma dessas quatro camadas é motivo para evitar IA ou espalhar o orçamento entre fornecedores redundantes — isso tem custo próprio e raramente compensa para uma operação pequena. O ponto é saber o tamanho real da dependência antes de aprofundá-la. Três perguntas simples resolvem a maior parte do diagnóstico:
Eu consigo exportar meu próprio dado hoje, em formato aberto, sem abrir chamado de suporte? Se a resposta exige esperar um retorno do fornecedor, o dado não é seu — é um favor que o fornecedor concede.
As regras de negócio estão escritas em algum lugar fora da ferramenta? Um documento simples — o que aprovar, como responder, o que escalar para humano — que sobrevive independente da interface é o que permite reconstruir o comportamento em outro motor de IA sem começar do zero.
Já testei rodar a mesma tarefa num fornecedor alternativo, mesmo sem intenção de trocar? Esse “teste de troca” periódico — trimestral, por exemplo — é o único jeito confiável de saber quanto custaria migrar de verdade, antes que a migração seja forçada por um aumento de preço ou uma descontinuação.
O lock-in não está no contrato, está no que a empresa deixou de guardar
Na visão de João Paulo Batistella, executivo de inovação com passagens por Ericsson, Telefônica/Vivo e cinco anos como CEO da EISA, a IA só sustenta valor de verdade quando o processo de negócio está formalizado em dado — não preso na cabeça de uma pessoa. A mesma lógica vale, ponto por ponto, para a relação com fornecedor de IA: o risco real não é a cláusula de reajuste no contrato, é a regra de negócio que a empresa nunca escreveu em lugar nenhum fora da ferramenta. Uma empresa que documenta o próprio raciocínio troca de fornecedor com dor administrativa. Uma empresa que deixou o raciocínio morar só dentro da configuração de terceiro troca de fornecedor reconstruindo do zero — e geralmente descobre isso no pior momento possível, sob pressão de prazo.
Isso também qualifica quando vale a pena aprofundar o uso de um fornecedor específico — por exemplo, ajustando um modelo com dado próprio da empresa (fine-tuning), o que aumenta a dependência ainda mais, porque aquele ajuste fica preso ao fornecedor que o processou. Fine-tuning pode valer a pena quando o ganho de qualidade é real e mensurável; o problema é fazer isso antes de ter respondido as três perguntas acima, comprando lock-in mais profundo sem saber o preço.
Acompanhe a Eleva Tecnologia para mais análises sobre tecnologia aplicada a negócios: siga @ElevaTechno no X, @elevatechnologies no Instagram ou a Eleva Technologies no LinkedIn, ou conheça o grupo em elevatec.net/sobre.
