Inside a single-client private AI deployment
Private AI deployment architecture for one client, layer by layer: retention, communication, access, model inference, storage and where it runs.
Inside a single-client private AI deployment#
A single-client private AI deployment is one built for one organization, from the hardware to the choice of model provider to where the data is stored, with nothing shared with other customers. You evaluate it as six layers: retention and deletion, communication, access and actions, model inference, data storage, and deployment. Each layer has its own questions and its own options, and the answer at one layer can undo the care taken at another.
This post walks the six layers in that order, for a technical evaluator who has to sign off on one. For the concept itself, start with what private superintelligence is. For how private and public AI services differ, see private AI vs public AI.
1. Retention and deletion: storage periods and deletion#
The first question is how long anything lives, and what "deleted" means. Prompts, outputs, retrieved documents, logs and backups each have their own clock. Ask for every one of them in writing.
Deletion is harder than it sounds. NIST's media sanitization guidelines (SP 800-88 Revision 2, September 2025) define three methods: clear, purge and destroy. Clear "applies logical techniques to sanitize data in all user-addressable storage locations," which protects against simple recovery through the normal interface. The same document describes cryptographic erase, a purge technique "based on the sanitization of keys used to encrypt data," and notes that it lets sanitization "be performed with high assurance much faster than with other sanitization techniques."
That link between deletion and keys is why layer 5 matters here. If the client holds the encryption keys, destroying them can make every copy unreadable, backups included, without a hunt through each disk.
Ask: What is kept, for how long, and in which systems? Which NIST method applies when you delete it? Who can confirm the deletion happened?
2. Communication: recipients and destinations#
An AI system that reads email and documents will meet text written by strangers. Some of it may carry instructions. OWASP's 2025 Top 10 for LLM applications lists prompt injection first and gives an example: a user asks a model to summarize a webpage with hidden instructions, which "cause the LLM to insert an image linking to a URL" and send the private conversation to an outside server.
The defence at this layer is a short, fixed list of where data may go. That covers who may receive a message the system drafts, which network destinations it may reach, and whether rendered output may load remote content. On a cloud provider you can enforce part of this in the network. Amazon's Bedrock documentation, for example, recommends "configuring your VPC so that your data isn't available over the internet" and using AWS PrivateLink "to establish a private connection to your data."
Ask: Which recipients and network destinations can the system reach? Is that list enforced by the network or only by the prompt? Who approves a change to it?
3. Access and actions: permissions and approvals#
An agent that can act (send, file, schedule, pay) needs the same discipline you apply to a new employee. NIST SP 800-53 Revision 5 defines least privilege as: "Each entity is granted the minimum system resources and authorizations that the entity needs to perform its function."
OWASP names the failure at this layer "excessive agency," the vulnerability "that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," and traces it to "excessive functionality," "excessive permissions" and "excessive autonomy." Its mitigations are two you can test: limit permissions "to the minimum necessary," and "require a human to approve high-impact actions before they are taken." OWASP's own example is a mail tool with read-only scope that needs a person to review before anything goes out.
Ask: Which actions can the system take without a person? Can you set those permissions per system and per action, and change them yourself? Is every action logged with the source that prompted it?
4. Model inference: processing and provider access#
Every answer passes through a model, and somebody runs that model. The question is who can see what goes in and comes out.
Three options cover most deployments. You can call a model provider's API directly under its enterprise or zero-retention terms. You can run the provider's model inside a cloud platform you contract with. Amazon Bedrock documents that in each region it keeps one model deployment account per provider, owned by the Bedrock team, and that "Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions." Or you can run open-weight models on hardware the deployment controls, so inference never leaves it.
The right choice depends on which model you need and how far your data may travel. A single-client deployment lets you make that choice per client instead of inheriting one vendor's default. The Private SuperIntelligence guide to zero data retention covers what the provider terms do and do not exclude.
Ask: Which model provider processes the data? Under which terms? Who at that provider, and at the cloud platform, can read prompts or outputs?
5. Data storage: encryption and key control#
AWS encrypts customer data at rest by default, so key control is the part to examine. AWS's KMS documentation draws the line between key types. For customer managed keys, the key policy is "Exclusively controlled by the customer," and the customer manages "rotation, deletion and Regional location." For AWS owned keys, the key policy is "Exclusively controlled and only viewable by the AWS service that encrypts your data," and the customer cannot "change their policies," "audit activities on these keys" or "delete them."
The same trade applies outside AWS. The party that holds the keys decides who can read the data and whether deletion by key destruction (layer 1) is available to you.
Ask: Who generates the keys, who can use them, and who can destroy them? Can you audit every use? Where do the keys live relative to the data?
6. Deployment: isolation and data location#
The last layer decides where all of the above runs. NIST's definition of cloud computing (SP 800-145, September 2011) separates the models. A private cloud "is provisioned for exclusive use by a single organization" and "may exist on or off premises." A public cloud "is provisioned for open use by the general public."
In practice the options run from an isolated environment at a cloud provider, through hardware on the client's own premises, to an air-gapped system with no network path out. Even the air-gapped end is a product you can buy: Google describes its Google Distributed Cloud air-gapped product as letting you "host, control, and manage infrastructure and services directly on your premises," and says it "does not require connectivity to Google Cloud."
More isolation costs more operational effort and narrows which models you can run. Fewer connections also mean fewer paths for data to leave. Pick the level the data calls for, and confirm the other five layers still hold at that level.
Ask: Is any component shared with another customer? In which country and facility does each piece run? What network paths leave the deployment, and who can open one?
The six layers at a glance#
| Layer | The question | Options to compare |
|---|---|---|
| Retention and deletion | How long does each copy live, and how is it erased? | Fixed retention periods; NIST clear, purge or destroy; cryptographic erase |
| Communication | Where can data go? | Allow-listed recipients and destinations; private network endpoints |
| Access and actions | What can the system do without a person? | Least-privilege scopes; human approval for high-impact actions |
| Model inference | Who sees prompts and outputs? | Provider API; model hosted in a cloud platform; open-weight model on controlled hardware |
| Data storage | Who holds the keys? | Customer managed keys; provider managed or provider owned keys |
| Deployment | Where does it run, and what is shared? | Isolated cloud environment; on-premises; air-gapped |
How Private SuperIntelligence approaches it#
Mitosis Labs builds each Private SuperIntelligence deployment for one client, from the hardware to the choice of model provider to where the data is stored, and delivers it in weeks. It works across the client's own email, documents and data, answers with citations, and acts within permissions the client sets. A client deployment captures none of the client's data and sends no telemetry back to Mitosis Labs. It runs on Mitosis, the knowledge graph Mitosis Labs builds for AI agents.
Frequently asked questions#
What is a single-tenant AI deployment?#
It is an AI system whose infrastructure serves one customer, with no compute, storage or model endpoint shared with others. NIST's term for the infrastructure side is a private cloud, which "may exist on or off premises."
What is the difference between on-premises and air-gapped AI?#
On-premises AI runs on hardware at your site but may still connect to outside networks. An air-gapped system has no network connection out, so updates and data move only by deliberate, controlled transfer.
Does a private deployment mean the model provider never sees my data?#
It depends on layer 4. If inference runs on open-weight models inside the deployment, no outside provider processes it. If it calls a hosted model, read that provider's and platform's terms: Amazon Bedrock, for example, documents that model providers cannot see prompts and completions sent through it.
Why does key control matter for deletion?#
If you hold the encryption keys, destroying them makes the encrypted data unreadable. NIST SP 800-88 calls this cryptographic erase and classes it as a purge technique.
Which layer should I check first?#
Start with deployment and model inference, because they decide who else can reach the data at all. Then confirm the other four layers, since a lax retention or communication setting can undo a well-isolated deployment.
Sources#
- Guidelines for Media Sanitization, SP 800-88 Rev. 2 (NIST, September 2025)
- The NIST Definition of Cloud Computing, SP 800-145 (NIST, September 2011)
- Least privilege, glossary entry citing SP 800-53 Rev. 5 (NIST CSRC, accessed 2026-10-15)
- LLM01:2025 Prompt Injection (OWASP Gen AI Security Project, accessed 2026-10-15)
- LLM06:2025 Excessive Agency (OWASP Gen AI Security Project, accessed 2026-10-15)
- Data protection, Amazon Bedrock User Guide (AWS, accessed 2026-10-15)
- Protect your data using Amazon VPC and AWS PrivateLink, Amazon Bedrock User Guide (AWS, accessed 2026-10-15)
- AWS KMS keys, AWS Key Management Service Developer Guide (AWS, accessed 2026-10-15)
- Google Distributed Cloud air-gapped overview (Google Cloud, accessed 2026-10-15)
- What is private superintelligence? (Private SuperIntelligence, accessed 2026-10-15)
- Private AI vs public AI (Private SuperIntelligence, accessed 2026-10-15)
- What is zero data retention AI? (Private SuperIntelligence, accessed 2026-10-15)