Depender de um único modelo de IA é um risco de negócio

A API responde, o painel está verde e o atendimento pelo WhatsApp continua no ar. Só que o assistente da loja passou a prometer trocas que a política comercial não permite. Para a engenharia, a integração funciona. Para o lojista, o serviço falhou.

Essa cena hipotética expõe um risco que costuma ficar escondido na discussão sobre inteligência artificial: manter o sistema disponível não basta para preservar o produto. O cliente paga pelo que ele entrega, não pela conexão com o modelo.

Defendo que a liberdade para trocar de modelo de IA deve ser tratada como ativo estratégico. Isso não exige contratar todos os fornecedores nem correr atrás de cada lançamento. Exige saber se uma escolha técnica pode acabar ditando sua margem e sua relação com o cliente.

O fornecedor decide. A cobrança chega para você.

Quem constrói um produto sobre modelos de terceiros aceita decisões que não controla. O fornecedor define preços e condições de acesso, lança funcionalidades e encerra versões. Quando alguma dessas mudanças prejudica o serviço, porém, o cliente cobra de quem lhe vendeu a solução.

A documentação da Anthropic sobre descontinuação de modelos deixa claro que versões têm um ciclo de vida. Não vejo nada de errado nisso: software evolui e fornecedores precisam administrar sua infraestrutura. O erro é montar um negócio como se essa evolução nunca fosse exigir trabalho da sua equipe.

Contratar tecnologia externa é uma decisão perfeitamente razoável. Não saber quanto o negócio depende dela, nem o que seria necessário para substituí-la, já é descuido.

A solução provisória que vira dona da casa

No começo, concentrar tudo em um modelo pode ser a escolha certa. A equipe é pequena, o prazo é curto e ainda falta descobrir se alguém paga pelo produto. Construir uma arquitetura sofisticada antes de validar a demanda pode ser uma maneira cara de adiar o contato com o mercado.

Por isso, discordo da ideia de que toda startup precisa nascer com vários modelos em produção. Esse esforço pode roubar tempo de conversas com clientes e de melhorias que fariam diferença imediata. O problema aparece quando a empresa cresce, mas continua chamando de provisória uma dependência que já sustenta o serviço inteiro.

Voltemos ao software de atendimento para lojistas brasileiros. Aos poucos, a equipe ajusta instruções e integrações ao comportamento de um modelo específico. As respostas melhoram, os clientes ficam satisfeitos e mexer no que está funcionando parece desperdício.

Só que esses ajustes vão se acumulando. O produto passa a contar com a maneira como aquele modelo interpreta uma mensagem incompleta, decide consultar o estoque ou reconhece a hora de chamar um atendente. Trocar o fornecedor significa mexer em comportamentos que o lojista já considera parte do serviço contratado.

A consequência chega ao caixa. Um aumento de preço pode apertar a margem, enquanto uma indisponibilidade deixa clientes sem atendimento. Ter uma alternativa viável não impede esses problemas, mas permite reagir com algo melhor do que um pedido de paciência.

Mudar a API é a parte fácil de enxergar

Alterar credenciais, adaptar requisições e receber uma resposta válida dá uma sensação tentadora de missão cumprida. É um avanço técnico real. Ainda assim, diz pouco sobre a qualidade do serviço depois da troca.

Modelos diferentes podem reagir de formas distintas à mesma instrução. Uma orientação que produz respostas objetivas em um deles pode gerar explicações longas em outro; uma integração com ferramentas pode exigir novos ajustes. Nada disso deveria ser descoberto pelo cliente.

Pense em um assistente usado por um escritório contábil. A nova conexão funciona, mas o modelo começa a tratar documentos ausentes como se as informações estivessem confirmadas. Se também deixa de encaminhar dúvidas que exigem análise profissional, a migração pode ter sido bem executada no código e malsucedida no produto.

É aqui que entram as avaliações. A documentação da OpenAI sobre avaliações apresenta testes como parte do desenvolvimento de aplicações com modelos. O princípio interessa mesmo a quem usa outro fornecedor: comparar resultados com critérios explícitos, em vez de aprovar uma troca porque algumas respostas pareceram excelentes.

Essa comparação precisa usar casos representativos do serviço, com os devidos cuidados de privacidade. O cliente escreve com erro, manda uma mensagem ambígua, pede algo fora do escopo. Se a amostra só contém pedidos claros e integrações funcionando perfeitamente, você está testando uma demonstração.

O trabalho também não fica restrito à engenharia. O suporte terá de reconhecer novos erros, e promessas comerciais talvez precisem ser revistas. A migração só termina quando o serviço volta a entregar com consistência, não quando o código entra em produção.

A saída precisa existir antes da emergência

Preservar a capacidade de troca começa por não deixar todas as regras do negócio nas mãos do modelo. Uma política de reembolso ou uma permissão de acesso não deveria depender exclusivamente de uma instrução em linguagem natural. O modelo pode ajudar a executar o serviço sem ser a única barreira contra uma decisão errada.

Também faz sentido manter uma alternativa testada nas tarefas críticas. Ela não precisa reproduzir cada detalhe do modelo principal nem receber parte do tráfego todos os dias. Você precisa saber o que ela consegue entregar e em quais situações será necessário restringir uma função ou chamar uma pessoa.

Na hora da mudança, proteger a promessa central do serviço importa mais do que preservar toda a automação. Uma liberação gradual, com acompanhamento de falhas e possibilidade de voltar atrás, dá espaço para corrigir problemas. Às vezes, oferecer temporariamente menos funções é uma decisão melhor do que manter uma experiência imprevisível.

Há um contraponto que merece respeito: recursos exclusivos de um fornecedor podem criar uma vantagem real. Padronizar tudo pelo que todos os modelos conseguem fazer também tem custo e pode empobrecer o produto. Eu não abriria mão de uma boa diferenciação só para tornar a troca mais fácil; exigiria, porém, clareza sobre o preço dessa dependência.

Liberdade de escolha não significa viver sem depender de ninguém. Significa conseguir administrar essa dependência quando os interesses deixam de coincidir. Você não precisa adivinhar qual será o melhor modelo daqui a alguns anos, mas deveria desconfiar de um negócio que só sobrevive se a escolha de hoje continuar certa.

Fontes consultadas

• Anthropic: descontinuação de modelos
• OpenAI: avaliações de aplicações com modelos