Como evitar dependência de fornecedor de IA em agentes

A dependência de fornecedor de IA acontece quando a memória, as instruções, as conexões com ferramentas e o histórico de testes do seu agente ficam em formatos que só um provedor consegue ler. Para evitá-la, mantenha esses ativos em sistemas que você controla, coloque uma camada fina entre o seu fluxo de trabalho e qualquer modelo específico e escreva as condições de saída no contrato antes de assinar. O modelo costuma ser a parte mais fácil de trocar. O custo de mudança se acumula em tudo o que o cerca.

Principais pontos

• O lock-in raramente nasce de uma grande decisão. Ele se acumula por pequenas facilidades que depois não podem ser exportadas.
• O modelo é a camada mais substituível. Memória, conexões com ferramentas, permissões e histórico de avaliações são as mais difíceis de mover.
• O contrato deve cobrir propriedade, formato de exportação, exclusão, uso para treinamento, aviso de mudanças e apoio na transição, e não apenas níveis de serviço.
• Instruções em texto simples, padrões abertos para ferramentas e um conjunto de testes seu transformam a troca de provedor em um projeto gerenciado, e não em uma reconstrução.
• Teste sua saída antes de precisar dela, enquanto a relação está boa e nada é urgente.

De onde vem, de fato, a dependência de fornecedor de IA?

A maioria das equipes imagina o lock-in como um contrato que prende. Na prática, ele costuma ser técnico e operacional. Cada recurso de conveniência economiza tempo no dia em que você o adota, e cada um acrescenta, em silêncio, uma dependência. O problema não é usar os recursos de um fornecedor. O problema é não conseguir levar com você o resultado desse trabalho.

Estas são as origens mais comuns em uma operação com agentes de negócio:

• Memória guardada dentro do produto do provedor, sem como lê-la como registros simples nem exportá-la.
• Instruções escritas em uma sintaxe, sistema de modelos ou tela de configuração que só uma plataforma entende.
• Conexões com ferramentas criadas com um formato de conector proprietário, o que obriga a refazer cada integração em outro lugar.
• Resultados de avaliação, registros e rastros que ficam no painel do fornecedor e desaparecem junto com a conta.
• Credenciais e permissões concedidas à conta do fornecedor, e não a uma conta que a sua empresa controla.
• Um modelo ajustado (fine-tuning) que existe em uma única plataforma, treinado com dados que você não consegue reproduzir com facilidade.
• Cláusulas contratuais que tornam a saída lenta: compromissos mínimos longos, exclusão pouco clara ou cobrança para recuperar os próprios dados.

Repare que apenas um item dessa lista trata da qualidade do modelo de IA. O restante diz respeito a onde o trabalho da sua empresa fica guardado e a quem tem acesso a ele.

Quais camadas de um agente são fáceis de trocar e quais não são?

Ajuda separar as peças. A diferença entre modelo, agente e harness importa aqui, porque cada camada tem um custo de troca diferente.

O modelo é o motor de raciocínio. Se o seu fluxo o chama por uma interface estreita, substituí-lo é, em boa parte, uma questão de testes. O harness é o sistema ao redor: como as instruções são montadas, quais ferramentas são oferecidas, como os erros são tratados, onde ocorrem as aprovações. Se você é dono do harness ou consegue lê-lo, pode movê-lo. Se ele for um recurso fechado de uma plataforma, não pode.

Depois vêm as camadas que carregam o trabalho acumulado da sua empresa:

• Memória e conhecimento: o que o agente aprendeu sobre seus clientes, decisões e procedimentos.
• Ferramentas e integrações: as conexões com CRM, agenda, caixa de entrada, canais de mensagem e documentos.
• Permissões: em nome de quem o agente age e o que ele pode ler, preparar ou enviar.
• Avaliações: os exemplos e verificações que provam que o agente ainda faz o trabalho.
• Histórico de operação: registros, incidentes, aprovações e correções.

Uma regra útil: quanto mais contexto do seu negócio uma camada contém, mais cuidado você deve ter com o lugar onde ela vive. Modelos são genéricos e substituíveis. Sua memória, suas permissões e seus casos de teste são específicos da sua empresa, então nunca devem ficar guardados apenas por terceiros.

O que o contrato deve dizer sobre a saída?

Contratos de serviços de IA costumam se concentrar em disponibilidade e prazo de resposta do suporte. Isso importa, mas diz pouco sobre portabilidade. Antes de assinar, peça linguagem explícita sobre os pontos abaixo e peça ao seu jurídico que revise o texto final.

• Propriedade: seus dados, instruções, configurações, resultados e qualquer memória derivada das suas informações pertencem à sua empresa.
• Exportação: o fornecedor entrega tudo isso em formato documentado e legível, incluindo memória, registros, conjuntos de avaliação e configurações de ferramentas, dentro de um prazo definido após o seu pedido.
• Exclusão: ao fim da relação, seus dados são apagados, inclusive de cópias de segurança e de suboperadores, e a exclusão é confirmada por escrito.
• Uso para treinamento: seus dados não são usados para treinar modelos de terceiros sem a sua concordância por escrito.
• Aviso de mudanças: você recebe aviso antecipado sobre desativação de modelos, mudanças de comportamento, mudanças na estrutura de preços e novos suboperadores, com tempo para testar antes de entrarem em vigor.
• Credenciais: contas, chaves de API e integrações são criadas em nome da sua empresa sempre que possível, para que o acesso não dependa da boa vontade do fornecedor.
• Apoio na transição: o fornecedor ajuda em uma transição razoável, incluindo a documentação de como o sistema está configurado.
• Localização dos dados e suboperadores: você sabe onde os dados são processados e quem mais tem contato com eles.

Nenhuma dessas cláusulas pressupõe má-fé. Elas apenas transformam uma expectativa vaga em algo que os dois lados podem verificar. Um fornecedor confortável com essa lista costuma ser alguém que já pensou no assunto.

Quais escolhas de arquitetura mantêm suas opções abertas?

A linguagem do contrato só ajuda se o sistema for construído de modo que sair seja tecnicamente possível. Estas escolhas fazem a maior parte do trabalho.

Primeiro, mantenha uma fonte da verdade fora do agente. Detalhes de produtos, políticas, registros de clientes e procedimentos devem ficar em sistemas que a sua equipe já mantém, e o agente deve ler a partir deles. Essa é a ideia por trás de definir fontes oficiais para um agente de IA. O conhecimento que permanece nos seus documentos e é recuperado quando necessário vai com você. O conhecimento embutido em um modelo ajustado não vai. Para a maior parte do conhecimento de negócio, a recuperação também é mais fácil de atualizar e auditar, uma troca explicada em RAG ou fine-tuning para o conhecimento da empresa.

Segundo, guarde a memória como registros legíveis. Se o agente lembra que um cliente prefere ligações pela manhã, esse fato deve ser uma linha em um arquivo ou banco de dados que você consiga abrir, e não um estado opaco dentro de um produto.

Terceiro, escreva as instruções em texto simples e sob controle de versão. Mantenha os ajustes específicos de cada modelo em uma seção pequena e bem identificada, para que trocar de modelo signifique editar poucas linhas, e não reescrever o agente inteiro.

Quarto, conecte as ferramentas por padrões abertos quando fizer sentido. O Model Context Protocol (MCP), descrito na documentação oficial do projeto, existe para que ferramentas possam ser expostas a diferentes aplicações de IA por uma interface comum. Nosso guia sobre MCP para agentes de negócio explica onde ele ajuda e onde uma integração direta ainda é a melhor escolha.

Quinto, coloque um adaptador fino entre o seu fluxo e o modelo. O fluxo deve pedir que uma tarefa seja feita, e não chamar recursos específicos de um provedor espalhados pelo código. Quando toda chamada ao modelo passa por um único ponto, trocar de provedor significa mudar um único ponto.

Sexto, seja dono das suas avaliações. Um conjunto de testes de referência com tarefas reais e resultados corretos conhecidos é o ativo de portabilidade mais valioso, porque permite comparar um novo modelo ou provedor com o atual usando o seu trabalho, e não a demonstração de um fornecedor. Ferramentas de avaliação oferecidas por provedores, como o guia de evals da OpenAI, podem ajudar a executar essas verificações, mas os casos de teste em si devem continuar sendo seus.

Como testar sua saída antes de precisar dela?

Um plano de saída que nunca foi exercitado é só uma esperança. Você pode testá-lo em um projeto pequeno e tranquilo. Use esta sequência:

• Faça o inventário de cada componente da operação e anote onde ele está guardado e quem detém as credenciais.
• Peça uma exportação completa de memória, instruções, registros e configurações, e confira se uma pessoa da sua equipe consegue lê-las sem ajuda do fornecedor.
• Confirme que integrações e contas estão registradas em nome da sua empresa.
• Execute o seu conjunto de testes em um segundo modelo, pela camada de adaptação, e registre onde os resultados diferem.
• Opere o segundo modelo em paralelo, sem autoridade, comparando seus rascunhos com os atuais, como descrito em testar um agente de IA em modo de observação.
• Liste o que quebrou ou não pôde ser movido e decida o que corrigir agora e o que aceitar como custo de troca conhecido.
• Repita o exercício em uma periodicidade regular e depois de qualquer mudança importante na operação.

O objetivo não é sair. O objetivo é saber, com evidência, que você poderia. Esse conhecimento muda o rumo das conversas de renovação.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: uma pequena empresa de serviços profissionais usa um agente para redigir acompanhamentos de clientes e propor atualizações no CRM. O provedor anuncia que o modelo em uso será desativado e que o substituto se comporta de outra forma.

A empresa que deixou a portabilidade de lado enfrenta uma reconstrução. As instruções estão misturadas aos recursos de uma plataforma, a memória dos clientes está dentro do produto e ninguém guardou um conjunto de exemplos de referência. Cada acompanhamento agora exige conferência manual, e a equipe não sabe dizer se o novo modelo é melhor ou pior.

A empresa que se preparou enfrenta uma tarefa de testes. As instruções são texto simples, a memória é um conjunto de registros legíveis e o conjunto de testes contém acompanhamentos reais com resultados aprovados. Ela executa os testes no substituto e em uma alternativa, revisa as diferenças, opera a opção preferida em modo de observação por um período e só então a promove. A mudança é um projeto planejado, com um fim claro, e não uma emergência.

Nada na segunda empresa exigiu prever o futuro. Bastou manter os próprios ativos nas próprias mãos.

Como a abordagem gerenciada da Be Human trata o lock-in?

A Be Human projeta, implementa e opera uma infraestrutura de IA personalizada em que identidade, memória, canais, ferramentas e permissões do agente permanecem sob controle humano. Na prática, isso significa que a configuração é documentada, os limites de aprovação são escritos e avaliações recorrentes rodam contra um conjunto de testes ligado ao critério de sucesso da função. A operação gerenciada cobre monitoramento, manutenção de integrações, revisão de permissões e melhorias controladas. Um serviço gerenciado também é uma dependência, então as mesmas perguntas deste artigo valem para nós: pergunte o que você pode exportar, quais contas estão em seu nome e como seria uma transição. Se você está comparando alternativas, o guia para decidir entre construir, comprar ou contratar gestão ajuda a comparar o que ficaria sob o seu controle em cada caso.

Perguntas frequentes

Alguma dependência de fornecedor de IA é inevitável? Sim, algum custo de troca sempre existe, porque qualquer integração real dá trabalho para ser movida. O objetivo é tornar esse custo conhecido, limitado e suportável, e não eliminá-lo. Se você consegue descrever o que uma mudança exigiria e quanto tempo ela levaria, mais ou menos, a sua posição é boa.

Devemos usar vários modelos ao mesmo tempo para evitar o lock-in? Não necessariamente. Operar vários modelos aumenta o trabalho de testes, monitoramento e manutenção. Um primeiro passo melhor é projetar a capacidade de trocar, com uma camada de adaptação e um conjunto de testes próprio, e só acrescentar um segundo modelo quando uma tarefa específica se beneficiar dele.

O fine-tuning aumenta a dependência? Muitas vezes sim, porque o modelo ajustado costuma viver em uma única plataforma e depende de dados de treinamento que você precisa guardar e saber reproduzir. Para conhecimento que muda, a recuperação a partir dos seus próprios documentos costuma ser mais portátil e mais fácil de revisar. Se você optar pelo fine-tuning, mantenha em armazenamento próprio os dados de treinamento, as notas do processo e o conjunto de avaliação.

Quando devemos fazer o teste de saída? Faça antes de ampliar as responsabilidades do agente e de novo depois de mudanças importantes ou antes de uma renovação. Fazer cedo custa pouco, porque há menos o que mover, e gera evidências para usar em negociações. Esperar até que um provedor mude as condições deixa você testando sob pressão.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.