Resposta direta
A dependência de um único fornecedor de modelo se administra no contrato e na arquitetura, não na promessa de portabilidade. O que reduz risco é manter o dado e o critério de avaliação sob controle próprio, tratar a integração como camada substituível e registrar o custo de troca em horas de engenharia e retrabalho de validação. Nenhum contrato elimina a dependência: ele define prazo de aviso, formato de saída, histórico de versões e como a qualidade é medida. Quem entra sem esses itens negocia depois com menos margem.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a dependência como cláusula e decisão de arquitetura avaliável, com o custo de troca explicitado, e não como escolha de fornecedor.
O que o contrato precisa prever
Um contrato com fornecedor de modelo precisa fixar prazo de aviso antes de mudança de versão, formato de exportação dos dados de uso e política de retenção. Sem isso, qualquer ajuste de preço ou descontinuação chega sem tempo de reação.
Também importa o que fica do lado da empresa: onde estão os prompts, os casos de teste e o histórico de respostas. Enquanto esse material mora só na ferramenta do fornecedor, a negociação é assimétrica.
Onde separar o que é substituível
A integração com o modelo deve ficar isolada do restante do sistema, atrás de uma camada que traduz pedido e resposta. Trocar de fornecedor passa a ser reescrever essa camada, não o processo inteiro.
Vale manter um conjunto de teste com casos reais e critério de aceitação definido antes da contratação. Ele serve para comparar fornecedores e para verificar se a troca preservou a qualidade.
O que a cláusula não resolve
Contrato nenhum garante que dois fornecedores respondam igual. O comportamento do modelo muda com a versão, e parte da qualidade vem de ajustes específicos do provedor. A troca sempre gera diferença de resultado que precisa ser aceita ou tratada.
Redundância tem custo de operação e de validação contínua. Manter dois fornecedores ativos sem uso não reduz risco real: amplia despesa. A decisão é sobre quanto de perda é tolerável durante uma transição, não sobre eliminar a dependência.
Recurso prático
Custo de troca de fornecedor de modelo
Custo de troca = (horas de reengenharia + horas de revalidação) × custo da hora + custo da operação paralela
- Horas de reengenharia
- horas
- Tempo para reescrever integração, prompts e tratamento de saída no fornecedor de destino.
- Horas de revalidação
- horas
- Tempo para rodar o conjunto de teste e revisar as respostas antes de liberar a troca.
- Custo da hora
- R$ por hora
- Valor interno da equipe envolvida, incluindo encargos.
- Operação paralela
- R$
- Custo de manter os dois fornecedores ativos durante a transição e a comparação de resultados.
O erro mais comum é estimar a troca apenas pelas horas de engenharia. Na prática, a revalidação costuma pesar mais, porque exige rodar o conjunto de teste e revisar caso a caso antes de liberar o fornecedor novo.
Sobre o que está escrito aqui
Conceitos relacionados: custo de troca · portabilidade de dados · acordo de nível de serviço · conjunto de teste e critério de aceitação · histórico de versões do modelo. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Workshop executivo, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- IA aplicada e agentes — Página central do tema
- Ferramentas isoladas: como integrar sem gerar… — ferramentas isoladas
- Ferramentas isoladas: como medir o impacto no… — ferramentas isoladas
Páginas relacionadas
O mesmo problema em outro objetivo
- Fornecedor único de modelo: como medir a dependência — Diagnosticar
- Dependência de um fornecedor de modelo: o que separar — Organizar um processo
- Fornecedor único de modelo: o que comparar na troca — Comparar alternativas
- Dependência de um fornecedor de modelo: o que medir — Explicar medição
- Fornecedor único de modelo: como trocar sem reescrever tudo — Orientar implementação
Outras leituras em IA aplicada e agentes
- Incerteza no início com IA: o que exigir na contratação — Critérios objetivos para selecionar prestadores de serviço de IA quando a empresa ainda não definiu o problema inicial nem o escopo de trabalho.
- Resposta de IA virou fonte única: o que precisa constar — O que precisa estar definido antes de uma resposta de IA ser tratada como fonte única: origem do dado, quem responde pelo erro e como contestar.
- Fonte única de resposta em IA: medir o que ninguém confere — Descreve o que medir quando a resposta de IA passa a ser a versão oficial: origem do dado, cobertura da conferência, taxa de correção e quem responde pelo erro.
- Uso de IA sem finalidade registrada: o que medir — Explica como medir uso de IA sem registro de finalidade, a partir de evidências do trabalho, amostragem de tarefas e critérios de responsabilidade.
- Instrução sem versionamento: como medir o efeito — Registro mínimo, conjunto fixo de tarefas e comparação de respostas para medir o efeito de uma instrução de IA sem histórico de versões.