Dependência de fornecedor de IA: como manter o que o agente aprendeu

A dependência de fornecedor de IA (lock-in) acontece quando o que torna o agente útil, ou seja, sua memória, instruções, conexões e resultados de testes, vive dentro do produto de um fornecedor e não em ativos que a empresa controla. Você reduz esse risco mantendo esses ativos em formatos exportáveis, em contas da própria empresa, para que o modelo ou o fornecedor possam mudar sem que o agente esqueça como o seu negócio funciona. O modelo é uma peça que você aluga. O conhecimento acumulado deve ser algo que você possui.

Principais pontos

• A dependência raramente está no modelo em si. Ela está na memória, nos prompts, nas integrações e no histórico de avaliações construídos em torno dele.
• Guarde a memória da empresa em formatos simples e documentados, armazenados por você, e trate embeddings e índices como cópias descartáveis, que podem ser reconstruídas.
• Escreva as instruções como documentos versionados para uma função, com uma camada fina específica do modelo por cima, e mantenha um conjunto de testes com tarefas reais que qualquer modelo precise passar.
• Registre integrações, credenciais e permissões em contas da própria empresa e exponha as ferramentas por padrões abertos sempre que possível.
• Ensaie a troca de modelo em um ambiente seguro antes de precisar dela e meça o que quebra.

Como a dependência de fornecedor de IA aparece na prática?

A maioria dos líderes imagina um contrato difícil de encerrar. No trabalho com IA, o contrato costuma ser o problema menor. O maior é a dependência que se forma em silêncio, à medida que o agente melhora.

As formas mais comuns:

• Memória guardada em um repositório proprietário do fornecedor, sem exportação em formato legível.
• Prompts que existem só no painel do fornecedor ou que dependem das particularidades de um único modelo.
• Integrações criadas com as credenciais do fornecedor, de modo que o acesso desaparece quando a relação termina.
• Modelos com ajuste fino (fine-tuning) que não podem ser levados a outro provedor.
• Resultados de avaliação e logs que o fornecedor guarda e você não consegue inspecionar.

Cada item, isolado, parece razoável. Juntos, significam que, depois de um longo período de melhorias, o agente vale muito para você e é quase impossível de mover. Para o lado contratual do problema, veja Cláusulas de rescisão em contrato de serviços de IA: o que revisar. Este artigo trata de como estruturar os ativos em si.

Por que modelos mais fortes elevam o que está em jogo?

Os modelos mudam o tempo todo. Surgem novos, os termos se alteram e os provedores aposentam versões antigas. Seja qual for o ritmo que você espera de sistemas mais capazes, incluindo os que um dia possam ser chamados de superinteligentes, a pergunta prática para a empresa continua a mesma: quando existir um modelo melhor, com que rapidez você consegue colocá-lo para trabalhar no seu próprio negócio?

Uma empresa que é dona de sua memória, instruções, ferramentas e testes pode experimentar um modelo mais forte, rodar seu conjunto de testes e adotá-lo quando os resultados se confirmarem. Uma empresa com o contexto preso precisa esperar o fornecedor adotar a mudança ou recomeçar em outro lugar. Os ganhos dos modelos melhores vão, então, para quem controla os ativos ao redor. Essa é a lógica de uma camada de superinteligência empresarial com governança de agentes: a parte durável é o que você constrói em volta do modelo.

Seja honesto sobre o que a portabilidade não garante. Um modelo novo vai se comportar de maneira diferente. Portabilidade significa que você consegue medir a diferença e ajustar, não que nada muda.

Como estruturar a memória para que ela continue sendo sua?

A memória reúne três coisas diferentes, e cada uma precisa de um lugar próprio.

• Conhecimento da empresa: políticas, informações de produtos, procedimentos e modelos de documentos.
• Fatos aprendidos: o que o agente registra ao longo do tempo, como o canal preferido de um cliente, uma decisão e quem a aprovou, ou uma exceção recorrente.
• Histórico de conversas: o registro do que foi perguntado e respondido.

Regras que mantêm as três portáteis:

• Guarde tudo na conta de nuvem ou na infraestrutura da própria empresa, em formatos legíveis: markdown ou texto para documentos, JSON ou CSV para fatos estruturados, um banco de dados padrão para registros.
• Dê a cada fato aprendido uma fonte, uma data e um responsável. Um fato sem fonte não pode ser conferido depois de uma migração.
• Separe as fontes originais dos resumos gerados pelo agente. Resumos podem ser regenerados. Fontes, não.
• Trate embeddings e índices de busca como descartáveis. Eles são derivados das suas fontes e ligados a um modelo de embedding específico, então planeje reconstruí-los em vez de movê-los.
• Prefira recuperação de informação ao ajuste fino para o conhecimento da empresa. O conhecimento recuperado pode ser editado, apagado e movido, enquanto o conhecimento embutido nos pesos do modelo geralmente não pode. O material da AWS que compara recuperação e ajuste fino é uma boa referência.

A memória que o agente grava também precisa de governança: quem pode corrigir um fato errado e como a correção é registrada. E você precisa conseguir restaurá-la. Vale ter uma rotina de backup e restauração do agente, definindo o que salvar e como testar a recuperação.

Como escrever prompts e testes que sobrevivem à troca de modelo?

É nos prompts que o julgamento da empresa fica escrito: o que a função faz, o que nunca deve fazer, quando escala para uma pessoa, como fala com os clientes. Esse julgamento é seu, mesmo que a redação esteja ajustada a um modelo.

Estruture em camadas:

• Definição da função: finalidade, escopo, público e critério de sucesso, em linguagem simples.
• Regras e limites: faixas de aprovação, assuntos a recusar, contatos de escalonamento.
• Exemplos: casos reais anonimizados, mostrando respostas boas e ruins.
• Adaptador do modelo: a pequena camada de redação, formatação e instruções de chamada de ferramentas de que um modelo específico precisa. Espere reescrevê-la quando o modelo mudar.

Mantenha tudo em um repositório com controle de versão que a empresa consiga ler, com uma nota curta sobre o motivo de cada alteração. Os textos da Anthropic sobre engenharia de contexto para agentes são um bom guia do que pertence ao contexto de trabalho e do que deve ser buscado sob demanda, o que também mantém pequena a camada específica do modelo.

O ativo mais portátil não é um prompt. É um conjunto de testes. Reúna tarefas reais com resultados esperados e um critério de avaliação: o pedido de cotação que exige uma pessoa, o reembolso dentro da política, o e-mail ambíguo. O guia de evals da OpenAI e os textos da Anthropic sobre avaliação de agentes descrevem essa prática. Rode o conjunto a cada mudança de modelo ou de prompt. Quando o fornecedor mudar, o conjunto de testes diz em uma tarde se o substituto é bom o bastante, em vez de um mês de reclamações dizer isso por ele.

Como configurar integrações e permissões?

É nas integrações que a dependência deixa de ser incômoda e passa a ser operacional. Se o agente lê a caixa de entrada e grava no CRM com credenciais que o fornecedor criou e guarda, quando o fornecedor sai, o acesso vai embora com ele.

• Registre aplicativos e contas de serviço no seu próprio provedor de identidade e nas contas das suas ferramentas. Use autorização padrão, como OAuth 2.0, com escopos limitados à função.
• Guarde os segredos em um cofre administrado pela empresa. O fornecedor recebe permissão para usá-los, não a propriedade.
• Coloque uma camada fina de ferramentas entre o modelo e seus sistemas, com nomes que descrevam ações de negócio (criar rascunho de cotação, consultar um pedido) e não funções internas do fornecedor. Assim, uma troca de modelo mexe no adaptador, não nos seus sistemas.
• Exponha as ferramentas por um padrão aberto quando puder. O Model Context Protocol existe para que ferramentas e fontes de dados se conectem a diferentes aplicações de IA de forma comum.
• Hospede endpoints de webhook e automações no seu próprio domínio e documente a configuração.
• Mantenha os logs de ação no seu próprio armazenamento. Eles mostram o que o agente fez e servem de evidência em qualquer auditoria.

Mantenha também um inventário do que o agente pode ler, gravar e aprovar. Toda revisão de permissões futura fica mais fácil quando essa lista já existe.

Como é um ensaio de troca de modelo?

Um ensaio de troca é uma simulação da mudança para outro modelo ou fornecedor, feita em ambiente seguro, sem acesso de escrita à produção. Use-o como um plano passo a passo:

• Passo um: liste onde ficam hoje memória, instruções, ferramentas, credenciais, testes e logs, e quem tem direitos de administrador sobre cada um.
• Passo dois: classifique cada ativo como exportável, reconstruível a partir de outros ativos ou preso.
• Passo três: resolva primeiro os ativos presos. Exporte-os, mova-os para as suas contas ou registre a lacuna e decida se o risco é aceitável.
• Passo quatro: atualize o conjunto de testes com trabalho real, com um limite de aprovação acordado com o dono do processo.
• Passo cinco: aponte o agente para outro modelo, reconstrua os índices a partir das fontes e reescreva apenas o adaptador do modelo.
• Passo seis: rode o conjunto de testes e registre onde a nova configuração é pior, igual e melhor.
• Passo sete: revise as falhas com o dono do processo e separe-as em ajustes de prompt, problemas de ferramenta e limites do modelo.
• Passo oito: anote o esforço que o ensaio exigiu e repita-o periodicamente ou quando surgir um modelo novo relevante.

Cenário ilustrativo: uma distribuidora tem um agente que redige respostas a avisos de atraso de fornecedores. Com o tempo, ele aprende quais fornecedores têm exceções permanentes e quais contatos aprovam mudanças. Em uma configuração, essas anotações ficam no recurso de memória hospedado pelo fornecedor. Em outra, são registros datados no armazenamento da própria empresa, com as instruções em um repositório e as credenciais em contas da empresa. Quando surge um modelo novo, a primeira empresa só pode perguntar ao fornecedor se haverá suporte. A segunda roda seu conjunto de testes em uma tarde, descobre que o novo modelo lida bem com exceções, mas formata mal os escalonamentos, corrige o adaptador e o adota com aprovação. Os acontecimentos são os mesmos. A propriedade é diferente.

Como a Be Human trata esse tema?

A Be Human projeta e opera agentes de modo que identidade, memória, canais, ferramentas, permissões e contexto operacional permaneçam sob controle humano. Na prática, a memória fica em formatos e contas a que o cliente tem acesso, as instruções são documentos versionados, as integrações usam escopos aprovados e um conjunto de avaliação é definido junto com a primeira função e seu critério de sucesso. A operação gerenciada inclui avaliações recorrentes, manutenção das integrações, revisão de permissões e melhorias controladas, para que o ensaio de troca possa ser repetido quando um modelo mudar. Os termos de exportação e de saída pertencem ao escopo escrito, como descrito em Escopo de trabalho para implantação de agente de IA: o que incluir.

Perguntas frequentes

Escolher um único provedor de modelo de propósito já é dependência? Não necessariamente. Usar um só provedor é uma escolha. A dependência existe quando você não consegue sair sem perder o trabalho. Se memória, instruções, ferramentas e testes são seus e você já ensaiou uma troca, um único provedor é uma decisão defensável.

Devemos fazer ajuste fino de um modelo com os dados da empresa? Em geral, comece por recuperação de informação e instruções bem escritas, porque são editáveis e portáteis. O ajuste fino pode fazer sentido para tarefas restritas e estáveis, mas os pesos resultantes costumam ficar presos a um provedor. Se fizer, mantenha os dados de treinamento e o conjunto de testes no seu próprio armazenamento, para que o trabalho possa ser repetido em outro lugar.

Usar vários modelos elimina a dependência? Ajuda, mas não é a cura. Vários modelos atrás de uma única camada de ferramentas e de um único conjunto de testes dão opções reais. Vários modelos, cada um ligado separadamente aos seus sistemas, apenas multiplicam as dependências.

O que perguntar a um fornecedor sobre portabilidade? Pergunte onde a memória é armazenada e em que formato, quem é dono das credenciais e dos registros de aplicativos, se prompts e logs podem ser exportados e quanto tempo a exportação leva. Depois, teste as respostas com uma exportação pequena antes de depender delas. Um fornecedor que recebe bem o teste está lhe dando uma informação útil.

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