Toda venda B2B com IA no Brasil chega no mesmo ponto da conversa. O jurídico entra na call e pergunta:
"Esse dado vai treinar modelo de terceiro? Fica isolado do dado de outro cliente? Roda onde?"
São perguntas boas. E a resposta que a maioria dos fornecedores dá — "usamos a API da OpenAI com retenção zero" — é tecnicamente verdadeira e comercialmente insuficiente, porque não responde a segunda pergunta, que é a que o cliente realmente está fazendo: o que é meu continua sendo meu?
Foi tentando responder isso direito que a gente parou de tratar "modelo" como algo compartilhado e passou a tratar como algo que se liga e desliga por cliente.
O impasse
Existem duas formas óbvias de servir modelo em B2B e as duas são ruins por motivos opostos.
Multi-tenant puro. Um modelo, uma fila, todo mundo dentro. Barato, simples, e você passa a vida explicando isolamento em auditoria. Vaza um prompt entre tenants uma vez e a conversa acabou.
Instância dedicada por cliente. Isolamento claro, contrato fácil de assinar, e você acabou de comprar uma GPU parada por cliente. Com trinta clientes de médio porte usando três horas por dia, você mantém trinta placas para aproveitar 12% delas. Não fecha.
O impasse é real. O que destrava não é escolher um lado, é perceber que dedicado não precisa significar permanente.
Dedicado enquanto dura a requisição
A forma que funcionou pra gente: cada cliente tem uma configuração — pesos, adaptadores, prompts, base de conhecimento, chaves —, e essa configuração vira um ambiente vivo só durante a execução. Terminou, morre. Chegou trabalho de novo, sobe de novo.
O isolamento não vem de a máquina ser dele. Vem de nenhum processo carregar dado de dois clientes ao mesmo tempo.
O detalhe que faz isso valer é que o container é descartado no fim. Não tem estado sobrando pra vazar pro próximo, porque não existe próximo naquele processo.
Do lado do contrato, isso vira uma frase que o jurídico consegue ler: o processamento de cada cliente ocorre em ambiente de execução dedicado e efêmero, sem persistência compartilhada entre clientes. É bem mais forte que "temos filtro por tenant_id no WHERE", que é o que a maioria dos SaaS realmente tem.
O que o cliente ganha de verdade
Ajuste sem contaminação. Cliente com vocabulário próprio — no imobiliário, cada rede chama a mesma coisa por três nomes — recebe adaptador próprio. Melhora pra ele e não muda nada pros outros. Isso é diferente de "melhoramos o prompt global e torcemos".
Escolha de modelo por cliente. Um quer o melhor resultado e paga por isso. Outro quer o mais barato que passa no aceite. Como o modelo é parâmetro da configuração, os dois cabem no mesmo produto sem fork.
Desligamento que significa alguma coisa. Cliente cancela, você revoga a configuração e o dado dele para de existir no fluxo — não fica um vetorzinho perdido num índice compartilhado que ninguém sabe reparticionar. Já vi empresa boa travar seis meses tentando responder "como você apaga o que é meu do seu índice?".
O que dói na operação
Não é de graça. Três custos reais:
Configuração vira produto. Trinta clientes com pesos, adaptadores e prompts diferentes é trinta coisas pra versionar, testar e reverter. Sem registro versionado disso, você não tem produto, tem trinta gambiarras com o mesmo nome. A gente demorou pra aceitar que esse registro é a parte importante do sistema, não um detalhe de infra.
Cold start por cliente. O primeiro pedido do dia de cada cliente é o lento. Vale medir e, se for endpoint que humano espera, manter quente na janela conhecida de pico de cada um — que no B2B brasileiro é razoavelmente previsível, porque todo mundo trabalha no mesmo horário comercial.
Teste multiplica. Uma mudança no pipeline precisa passar em N configurações, não em uma. Sem suíte de regressão por tenant, a primeira melhoria vira o primeiro incidente.
E tem um custo que não é técnico: preço. Uso variável com custo variável é lindo na engenharia e horrível no comercial se você vender por assinatura fixa. Ou o preço acompanha volume, ou você desenha o plano com teto de uso explícito. Escolher errado aqui não quebra o sistema, quebra a margem — que é pior, porque demora mais pra aparecer.
Onde LGPD entra
Entra em tudo, e merece post próprio, mas o resumo é: essa arquitetura não te deixa em conformidade sozinha. Ela só torna as respostas verificáveis.
Quando o encarregado do cliente perguntar quem são os subprocessadores, onde o dado é processado, quanto tempo fica retido e como se apaga, você precisa ter resposta escrita e testada. A diferença é que com execução efêmera por cliente essas respostas são demonstráveis, em vez de serem promessas de política de privacidade.
Ter a arquitetura certa e o papel errado é perder venda do mesmo jeito. O papel também é parte do produto.
O critério que eu usaria
Se o seu cliente médio usa a IA menos de seis horas por dia e o jurídico dele faz pergunta sobre isolamento, modelo por demanda por cliente é provavelmente o desenho certo.
Se ele usa a capacidade quase inteira, o dedicado permanente volta a ganhar — e aí a discussão é de contrato, não de arquitetura.
O erro que eu cometi foi tratar isso como decisão de infraestrutura. É decisão de produto: define o que você consegue prometer, quanto custa cumprir, e quão rápido você entrega pro próximo cliente sem virar consultoria.