What is multi-tenancy?
Multi-tenancy is a way of building a platform so that one deployment serves many tenants, where a tenant is a customer, a subsidiary, or a department whose data and users must stay separate from everyone else’s. The tenants share the servers, the model, and the application code, but each sees only its own documents, conversations, agents, and settings. Nearly every software-as-a-service product is multi-tenant, and so are most hosted AI services. The same problem appears inside a group with several operating companies or at a managed service provider serving many clients.
Isolation can be enforced at different depths. The lightest form tags every record with a tenant identifier and filters on it in application code. Stronger forms give each tenant its own database schema, vector index, encryption keys, or set of containers, while still sharing the GPU that runs the model.
Why multi-tenancy matters
Sharing is what makes AI affordable at small scale. A GPU that serves one model can answer requests from twenty tenants, and the cost of the platform is spread across all of them. The risk is that AI systems create new paths for data to leak between tenants. A retrieval-augmented generation system that searches a shared vector index without tenant filters will quote one client’s contract to another. Agent memory, prompt caches, and logs are further places where one tenant’s data can surface in another’s session. Permission-aware retrieval and tenant-scoped role-based access control are the controls that close these paths.
Multi-tenancy in practice
A managed service provider runs one private AI platform for fifteen small-business clients, from a dental group to a trucking company. Each client has its own tenant with its own users, document store, vector index, and connectors to its own business systems. The language model runs once on a shared GPU server, and the serving layer labels every request with the tenant that sent it. The provider’s engineers can see uptime and usage per tenant but cannot read tenant documents without an access grant that is itself logged. In Kirk Tech Solutions engagements with service providers, tenant isolation is tested directly, by trying to retrieve one tenant’s content from another tenant’s account, before any client is onboarded.
What to watch for
- Ask a vendor exactly how tenants are isolated in the vector store, the model cache, and the logs, since the database is usually the easy part.
- Check whether one tenant’s heavy usage can slow the others and what rate limiting protects them.
- Confirm that per-tenant encryption keys and deletion are supported for when a client leaves or a regulator requires data destruction.
- Decide which tenants need a single-tenant deployment because of contractual or regulatory demands.