Todo SaaS multi-tenant que adiciona features de IA herda um problema que as aplicações tradicionais já resolveram há anos, mas que a camada IA traz de volta: o isolamento de dados entre tenants deixa de ser uma questão de filtro SQL e passa a ser uma questão de geometria vetorial, contexto de inferência e contaminação semântica. O risco, invisível aos papers, se apresenta claramente em produção. A OWASP incluiu Vector and Embedding Weaknesses como uma categoria dedicada no Top 10 pra LLMs na edição 2025, publicada no final de 2024, e a OWASP LLM08 documenta cross-tenant leakage como um vetor concreto em vector stores compartilhados sem isolamento estrutural. Fornecedores como a IronCore Labs, especializada em criptografia de vetores pra aplicações de IA, descrevem o mesmo cenário de risco sem exigir qualquer sofisticação técnica do atacante.
Pra mim, o padrão recorrente é previsível: uma equipe de produto implementa RAG sobre uma base de conhecimento multi-tenant, utiliza um único índice no Pinecone ou uma única collection no Milvus, adiciona um campo tenant_id nos metadados e assume que o filtro de metadados na query resolve o isolamento. Apesar de passar nos testes unitários, em produção, um bug no pipeline de ingestão omite o tenant_id em 0,3% dos documentos, ou uma query mal construída esquece o filtro, e o modelo passa a recuperar fragmentos de um tenant pra compor a resposta de outro. O vazamento é consequência direta de tratar isolamento como um filtro opcional, quando deveria ser uma restrição estrutural.
Conheço três estratégias de isolamento em vector stores, cada uma com trade-offs distintos de custo, operação e garantia. Na estratégia silo, cada tenant recebe seu próprio index ou namespace fisicamente isolado. O Pinecone implementa isso via namespaces dentro de um index, onde cada namespace opera e escala de forma independente, de modo que a atividade de um tenant não impacta a latência ou o throughput de outro. O Weaviate oferece shards dedicados por tenant com índices vetoriais separados (tipicamente HNSW, o algoritmo padrão da indústria). Na estratégia pool, todos os tenants compartilham o mesmo index e a separação ocorre via metadata filtering, com custo de infraestrutura menor mas com separação apenas lógica, onde um mero erro de filtro já resulta em vazamento, e o tracking de custo por tenant fica impossível, além de não existir SLA individual. Por fim, na estratégia bridge, namespaces servem tenants com requisitos de isolamento forte enquanto metadata filtering atende aos menores. O Milvus implementa uma variação com partition keys, roteando dados automaticamente pra partições lógicas com base num campo de particionamento e suportando milhões de tenants numa única collection com índices separados por grupo, embora múltiplos tenants possam coexistir na mesma partição. Acredito que a bridge é a estratégia mais subestimada: times começam pelo silo por inércia e acabam migrando pra pool por custo, quando a bridge resolveria os dois problemas sem sacrificar garantias.
Considero que a escolha entre essas estratégias ultrapassa a fronteira da decisão técnica. A LGPD e o GDPR exigem que o controlador demonstre medidas técnicas e organizacionais adequadas pra proteger dados pessoais, e a LGPD prevê multas de até 2% do faturamento ou R$50 milhões por infração. O histórico de enforcement da ANPD ainda é limitado, com valores aplicados na casa dos milhares de reais, mas a trajetória de intensificação é clara e o risco regulatório cresce a cada ciclo de fiscalização. Num pipeline de RAG, os chunks recuperados podem conter dados pessoais de clientes do tenant, e se esses chunks vazam pro contexto de outro tenant, o incidente configura violação de dados sob ambas as legislações. O modelo pool com metadata filtering torna a defesa jurídica mais difícil porque a separação depende de lógica de aplicação, não de fronteiras estruturais. O modelo silo oferece uma narrativa de compliance mais direta: os dados de cada tenant residem num container separado, e a probabilidade de contaminação cruzada é função da arquitetura, não da correção de cada query individual.
O problema se agrava quando a feature de IA envolve fine-tuning. A Microsoft atualizou os termos do Azure OpenAI em março de 2025 pra explicitar que operações de fine-tuning podem envolver relocação temporária de dados pra fora da geografia selecionada pelo cliente. Um modelo fine-tuned com dados de múltiplos tenants absorve padrões de todos eles nos pesos da rede, e não existe mecanismo confiável pra extrair ou isolar a contribuição de um tenant específico após o treinamento. O fine-tuning compartilhado cria um artefato que pertence, na prática, a todos os tenants cujos dados o alimentaram, o que gera problemas de propriedade intelectual, compliance com requisitos de exclusão sob o GDPR artigo 17 e offboarding. Quando um tenant solicita o apagemento dos seus dados, remover os registros do vector store é trivial, mas remover a influência desses dados nos pesos de um modelo fine-tuned é computacionalmente inviável sem retreinar o modelo do zero. A alternativa de manter fine-tuning dedicado por tenant escala linearmente em custo e se torna proibitiva acima de algumas dezenas. Penso que a decisão pragmática pra a maioria dos SaaS é utilizar modelos base sem fine-tuning, maximizando a qualidade via RAG com contexto isolado por tenant, e reservar fine-tuning apenas pra tenants enterprise com contrato e orçamento que justifiquem o custo dedicado.
O padrão arquitetural que equilibra o isolamento e o custo segue uma estrutura previsível: namespaces ou partições dedicadas por tenant no vector store, um middleware de ingestão que rejeita documentos sem tenant_id válido, pre-retrieval authorization que aplica o filtro de tenant antes da busca vetorial, e logging de auditoria registrando qual tenant originou cada query e quais chunks foram recuperados. O princípio operacional é que nenhum path de execução consiga recuperar dados sem especificar o tenant.
O custo adicional desse isolamento é real mas gerenciável: namespaces em Pinecone serverless geram custo proporcional ao armazenamento, não custo fixo, e as partições no Milvus adicionam sobrecarga de metadados sem escalar linearmente o custo computacional. De qualquer forma é caro, mas eu diria que o custo verdadeiramente proibitivo é o do incidente de vazamento cross-tenant, que combina: exposição regulatória, perda de confiança de clientes enterprise e notificação obrigatória à autoridade de proteção de dados dentro de 72 horas sob o GDPR.