Every SaaS platform solved tenant isolation years ago. Row level security, tenant scoped keys, separate schemas for the larger accounts, and an audit trail that proves customer A has never seen a byte belonging to customer B. That work is finished, hardened, and mostly forgotten. Then the team ships an AI feature, and every one of those guarantees has to be established again in a stack that was never designed with tenancy in mind.
The retrieval layer breaks first. A vector index holds embeddings of documents whose access rules live somewhere else, usually in the application database. Unless every query carries a tenant filter that the index itself enforces, a similarity search will happily return the closest match from another customer’s data, and it will do so with complete confidence. Metadata filtering makes this work, but it is a soft boundary. It fails open the moment a developer forgets a parameter or a new code path skips the shared query builder. A separate index per tenant is a hard boundary that fails closed, and it costs more to run. That tradeoff is a genuine architectural decision with commercial consequences, and it deserves to be made deliberately rather than discovered during a customer security review.
Caching is the second surprise. Semantic caches key on meaning rather than exact text, which is exactly what makes them effective and what makes them dangerous in a shared platform. Two tenants asking a similar question can collide, and the lever you added to protect margin becomes the mechanism that leaks one customer’s answer to another. Cache keys must include the tenant identifier. That is trivial to state and remarkably easy to omit under delivery pressure.
Capacity is the third. Token throughput is a shared and rate limited resource, so a single tenant running a bulk import can exhaust a deployment and degrade the experience for everyone else on it. Traditional SaaS solved this with connection pools and request throttling. AI workloads need the same thinking applied to tokens: quotas per tenant, priority tiers that reflect what customers actually pay, and dedicated deployments for the accounts large enough to warrant them.
The fourth is commercial rather than technical. AI features carry a real marginal cost per use, which is unfamiliar territory for teams accustomed to amortizing compute across the whole customer base. Without token accounting attributed at the tenant level, you cannot tell which customers are profitable, which pricing tier is underwater, or whether your heaviest user is your best account or your worst. That visibility has to be instrumented at the call site. It cannot be reconstructed from a cloud bill afterward.
None of this is difficult when it is designed in. All of it is expensive to retrofit once real customer data is flowing through the feature. If you are adding AI to a multitenant platform, settle the isolation model before the first prototype ships. Book a free discovery call and we will work through the tradeoffs with your architecture, or read how we engage first.
