Resposta direta
A dependência de fornecedor se administra por separação, não por troca. O que precisa ficar independente é a camada que monta o pedido, o registro do que foi pedido e do que voltou, e o conjunto de teste que valida a resposta. Com isso, mudar de fornecedor passa a ser uma decisão de custo, qualidade ou risco, tomada com trabalho interno previsível, e não uma emergência.
- Objetivo
- Organizar um processo
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a concentração em um fornecedor como item de inventário e de responsabilidade, com critério de aceite definido antes da troca, em vez de comparação de preços ou de qualidade.
O que costuma ficar colado no fornecedor
A dependência raramente nasce de uma decisão. Ela se acumula em pontos pequenos: instruções escritas dentro do código que chama o modelo, formato de saída aceito por apenas um fornecedor, função específica usada para buscar em documentos, chave de acesso guardada em um só lugar e termos contratuais que ninguém relê desde a assinatura.
Um levantamento inicial útil é listar onde o fornecedor aparece na operação: no produto, no atendimento, na análise interna, em relatórios. Para cada ponto, interessa saber quem responde por ele, o que a área faz quando a chamada falha e quanto tempo consegue operar sem ela. Esse mapa costuma revelar mais do que a comparação de preços.
Um responsável e um critério de aceite
Organizar o processo começa por nomear quem responde pela decisão de troca. Sem isso, cada área assume que o assunto pertence a outra, e a concentração segue. Esse responsável não executa a migração sozinho: mantém o inventário de dependências, acompanha mudanças de contrato e leva o tema para decisão quando muda o custo, o desempenho ou o risco.
O segundo elemento é o critério de aceite. Antes de qualquer troca, a empresa precisa saber o que a resposta do fornecedor candidato tem de cumprir: formato, tempo de retorno tolerado, comportamento em casos ambíguos, tratamento de dado sensível. Sem critério escrito, a troca vira teste de impressão, e a decisão volta a depender de percepção.
O que a separação não resolve
Manter camadas separadas não elimina a dependência. Reduz o custo de saída, mas não cria fornecedor alternativo que atenda o mesmo caso com a mesma qualidade. Em tarefas muito específicas pode não existir segunda opção viável, e a decisão correta passa a ser assumir a concentração e negociar a partir dela.
Também não resolve custo recorrente nem reajuste de preço: contrato, volume e forma de cobrança seguem o fornecedor escolhido. E a separação tem validade curta. Se a camada que monta o pedido não for usada e revisada, ela volta a se fundir ao fornecedor em poucos ciclos. O processo precisa de dono e de rotina, senão vira documentação parada.
Recurso prático
Itens que precisam existir antes de discutir troca de fornecedor
- Listar todo ponto da operação em que há chamada a modelo de linguagem, com a área responsável por cada um.
- Marcar no código ou no fluxo o que é instrução de negócio e o que é detalhe do fornecedor atual.
- Guardar o histórico do que foi pedido e do que voltou, com identificação do modelo usado em cada chamada.
- Definir critério de aceite por caso de uso antes de avaliar qualquer fornecedor alternativo.
- Registrar em contrato o destino do dado enviado, o aviso prévio em caso de mudança e a forma de encerramento.
- Nomear quem responde pela decisão de troca e a frequência de revisão do inventário.
O ponto mais ignorado é o histórico de chamadas. Sem registro do que foi pedido e do que voltou, não existe base de comparação: cada avaliação de fornecedor recomeça com casos montados na hora.
Conceitos usados nesta página
- Critério de aceite — Critério de aceite é a condição objetiva que define quando uma entrega, tarefa ou automação é considerada concluída — verificável por quem recebe, não por quem produziu.
Sobre o que está escrito aqui
Conceitos relacionados: camada de abstração de modelo · registro de chamadas · critério de aceite · inventário de dependências · contrato de serviço. 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
- Por onde começar com IA: o que avaliar antes — não saber por onde começar com IA
- Análise de dados com IA: quando ajuda — análise de dados sem critério de ferramenta
Páginas relacionadas
O mesmo problema em outro objetivo
- Fornecedor único de modelo: como medir a dependência — Diagnosticar
- 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
- Fornecedor único de modelo: o que amarrar antes de assinar — Orientar avaliação e contratação
Outras leituras em IA aplicada e agentes
- Piloto de IA que não virou rotina: o que cobrar na contratação — O que precisa estar definido na contratação de um piloto de IA para que a rotina operacional o absorva, em vez de encerrá-lo na demonstração.
- Instrução de IA sem versão: como comparar o que muda — Mostra o que registrar em cada versão de instrução de IA e como comparar alternativas pelo efeito no processo, não pela impressão de quem escreveu.
- Resposta de IA aceita sem conferência: o que comparar — Compara três formas de tratar resposta de IA: conferir tudo, conferir por amostra e aceitar com critério definido, com o custo de cada escolha.
- Custo de IA que muda todo mês: como medir por etapa — Explica como medir custo de IA por etapa, separar custo fixo de variável e identificar o que fazer quando o gasto varia sem motivo claro.
- Teste só com casos fáceis: o que a avaliação não mede — Mostra por que uma avaliação só com casos fáceis engana, o que incluir no conjunto de teste e como registrar dificuldade, origem e responsável pela decisão.
