Every vendor in this market uses the word. Almost none of them will tell you where the line is.
Here it means one thing: the cloud account you own and are billed for directly. Inside it, at rest, sits everything the platform holds about your organization. One thing crosses it on purpose, and this page is mostly about that one thing, because a boundary described only by what stays inside it is a boundary nobody has actually drawn.
A deployment is not a tenant in our system. It is a separate cloud account, opened for one organization, billed to that organization by the cloud provider at list price. Isolation here is not a row in a database with your identifier on it. It is an account boundary, the same one the provider uses to separate unrelated companies. That is the whole reason this page can be specific.
The boundary is the cloud account you own. When we write "inside the boundary", we mean inside that account. When something crosses it, we name what crosses, where it goes, under whose terms it is processed, and what comes back. Nothing on this site uses the word to mean "somewhere safe".
Uploads, attachments and intake sit in your storage. The knowledge index built over them sits in the storage region you chose. Retrieval happens in your account before any question reaches a model.
Sessions, message history, document metadata, per-person usage and metering records are stores in your account. Deleting them is an operation on your data, in your account, not a support request to us.
Each module's own stores, the access record written for every credential grant, retained 400 days, and the application audits: administrator transcript reads, restricted-field reveals, promotions with their approvers.
Encryption keys are the one item whose ownership moves with the posture: provider-owned at Baseline, provider-managed at Standard, customer-managed with rotation at Strict. The data they protect is in your account at all three.
A frontier model is a managed service. Nobody runs one inside your network, ours included, and a vendor who implies otherwise is either describing a much smaller model or hoping you will not ask. So the honest architecture is not "nothing leaves". It is: one governed path leaves, it carries a request and returns an answer, and every other path is denied by cloud policy.
The major cloud providers all publish the same three commitments for their managed model services: prompts and outputs are not used to train foundation models, they are not shared with the model makers, and the service can be reached over private network connectivity rather than the public internet. That is the default retention posture your deployment runs under. All of them also document narrow abuse-monitoring or safety review processes, so the exact claim is "not used for training, not shared with the model makers", never "nothing is ever retained". Provider service documentation, reviewed 20 September 2026.
The account boundary is the same at every posture. What changes is the character of the one crossing: whether it travels over a private network path, where it is allowed to be processed, and who holds the keys to what stays behind.
| Property of the crossing | Baseline | Standard | Strict |
|---|---|---|---|
| Path to the model service | ✕Signed request over the public network path | ✓Private network endpoint, network-attached chat compute | ✓Same |
| Where inference may run | △Global routing, provider chooses the region | △Global routing, disclosed and recorded | ✓Pinned in-country, refused in words when no route exists |
| Who holds the keys at rest | △Provider-owned | △Provider-managed | ✓Customer-managed, rotation on |
| Account-level audit trail | ✕Not on | ✓Multi-region, file validation, one year | ✓Same |
| Our reach into the account | ✓No cross-account role exists | △Scoped, session-capped role | △Same |
A judgment, stated plainly: the last row is the one place where Baseline is stricter than Standard. No role means we cannot help without you granting access first. That is a real tradeoff, not a feature list. Full matrix on posture tiers.
On the private-network postures the model traffic uses a private endpoint. A deployment is a live system rather than a sealed box, so the claim we stand behind is the precise one: your data at rest stays in your account, and the inference request is the crossing.
The default retention posture across the catalogue is the one described above. One vendor's newest frontier tier is different: it is offered only with provider-side data sharing and retention of up to thirty days. That is a change to the boundary, so it is not ours to make quietly.
Most "private AI" means they hold your data privately. Ours means you do.The distinction this page exists to make
Self-hosting an open-weight model is the real alternative to this tradeoff, and it is a different product with a different cost curve. We compare the two on self-hosted models.
Your data at rest does not. The content of a request does: the prompt, and whatever context the platform attached to it, go to the managed model service and the answer comes back. Your documents, index, message history and records are not copied out. Under default global routing the request may be processed in a region other than your storage region, which is the decision made on data residency.
Not under the default retention posture. The managed model service documents that prompts and outputs are not shared with the model makers and are not used to train foundation models. The one exception is the newest frontier tier described above, which is refused until you elect it. All providers also document narrow abuse-monitoring processes, so the accurate claim is "not used for training, not shared with the model makers", never "never retained".
Yes. The knowledge index is built in your storage region and retrieval runs there. The passages retrieved then travel with the request like any other context. One limit to hold: everything loaded into a deployment's knowledge base is readable by every user of that deployment, so load only what everyone may see. Detail and the rest of the limits on chat and knowledge.
A module runs on its own origin with a per-request content security policy built from its manifest, and reaches platform resources only through credentials that last at most fifteen minutes, tagged to the named person using it. The access record is written before the credential exists; if the record cannot be written, no credential is issued. Most modules never call a model at all. See modules.
No. We hold the platform source, the deployment factory and your parameter file, which describes your deployment rather than containing its data. At Baseline no cross-account role exists, so support means you granting access. At Standard and Strict the role is scoped and session-capped, and its use is in your account audit trail.
Read the resolved controls on your plan page inside the product, then check them against the account: the policies attached to the chat role, the invocation log, the stores and their regions. Everything described here is visible from inside an account you own, with your own credentials, without asking us. That is the point of the arrangement.
The assessment ends in a network topology and data-flow map of your own deployment, drawn against this boundary, and it is yours to keep.