Research · Version 3
What Makes Business AI Private
Private AI is a label, and the label covers very different arrangements. Two managed private AI providers inspected for this paper describe dedicated, single-tenant, multi-tenant and cloud-hosted options under the same phrase [S6][S7]. This paper helps a business owner look past the label. It separates three kinds of evidence behind any privacy statement: a contractual promise, a technical control, and observed evidence of what actually happened. It follows a single question through a retrieval-based data flow, showing where information is stored, processed, logged and possibly reviewed, and it notes that where data is stored need not be where it is processed [S1]. It compares five common arrangements without ranking them, because each one moves the questions rather than removing them. It treats training use, retention, human review and stored conversation history as four separate questions that documents answer separately [S1][S2]. It closes with a fourteen-question questionnaire and a way to score the answers. The evidence is eight public documents from eight organizations, two of them vendor descriptions. The data flow is a constructed illustration, nothing was tested, and the paper is not legal advice. Dominus Foundry publishes this research and develops Sabina, a commercial interest the reader should weigh.
For an owner or operations lead evaluating whether a business AI offering is private enough for the information involved · Evidence through 2026-10-20
Why "private" needs unpacking
"Private AI" is now a common label on service pages, and it is used for arrangements that differ a great deal. Two providers whose pages we inspected both use the phrase managed private AI. One describes a dedicated environment on its own private cloud, and also offers a multi-tenant option with logical isolation between workloads and an option on Microsoft Azure [S7]. The other describes private, single-tenant infrastructure that it owns and operates [S6]. A buyer who reads only the label would conclude these are the same product. They are not, and neither page claims they are.
This paper gives a business owner a way to look past the label. It does not rank deployment arrangements, because the right one depends on the information involved and the obligations that apply to the company. It does three things instead. It separates three kinds of evidence a privacy statement can rest on. It walks one request through a typical data flow so the places where information travels are visible. And it offers a questionnaire that asks for each answer in a form you can check.
A note on the author's position: Dominus Foundry publishes this research and develops Sabina, a managed private AI service. We state that so the reader can weigh what follows. The paper cites no result from our own product, and it makes no claim that any arrangement it discusses is better than another.
Three kinds of evidence
A statement about privacy can be supported in three different ways, and they are not interchangeable. A contractual promise is a commitment in the agreement or terms that bind the provider. Whether a statement on a marketing page is part of the agreement is something to confirm in the applicable agreement, with counsel, and not to assume. Microsoft's documentation illustrates the distinction in its own wording: it states what happens to prompts, completions, embeddings and training data, and it points to the data protection addendum that governs processing [S1]. Anthropic's privacy center similarly refers the reader to its commercial terms and trust center for the commercial products it covers [S2].
A technical control is a mechanism that limits what can happen whether or not anyone intends to keep the promise: isolation between customers, encryption, access control, network separation, a data store that is logically separated by customer. For Models sold by Azure in Microsoft Foundry, Microsoft documents that data stored by certain features is encrypted at rest by default and can be deleted by the customer, and that the abuse monitoring data store is logically separated by customer resource. The same page warns that models or features in preview might not support all of those conditions, and that preview features may employ different privacy practices [S1]. Hyve lists data location, access control, network separation and data handling as areas that must work together for private AI [S7].
Observed evidence is what a buyer or a third party has actually seen. This includes an access log showing who read a record, a test in which a user without permission was refused, an audit report, or a deletion confirmation. It answers a different question from the other two: whether a control behaved as described, at one time and within one scope. A contract says what the provider must do, a design says what the system is built to do, and a test says what it did when someone looked. One successful test, such as a single refusal in a log, shows that one control worked once for one case. It does not establish that the service is private in general, and a buyer should not read it that way.
A good answer to a privacy question usually draws on more than one. A contract that promises not to train on your data, a technical control that prevents the training pipeline from reaching your store, and a log you can read are three different things. A provider that can show all three has told you more than one that can show only the first.
One request, step by step
The table below follows one question through a retrieval-based service, the pattern in which the application finds relevant company material and gives it to the model as context. Hyve describes this pattern, noting that it can connect a model to approved information without retraining the model on every document [S7]. Microsoft describes its version as grounding on your data, in which the data stays in the source you designate and the service retrieves relevant material and adds it to the prompt [S1]. The steps below are a generic illustration we constructed from those descriptions. They are not a description of any specific product.
Illustrative data flow for one question (generic, not any specific product)
Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.
| Step | What happens | Who or what can see it | Ask the provider |
|---|---|---|---|
| 1. The user asks | A question is typed or spoken and sent to the application | The user, the application, and any logging layer | What is logged, for how long, and who reads it? |
| 2. The system retrieves | The application searches connected sources for relevant material | The connected source and the retrieval component | Does retrieval respect each person's existing permissions? [S7] |
| 3. The prompt is assembled | The question and retrieved material are combined | The application and the model host | Where does the model run, and in which region? [S1] |
| 4. The model responds | The model produces text from the prompt | The model host; any safety or abuse system | Is any sample retained or reviewed by people? [S1] |
| 5. The answer is shown | The application returns the answer, with references if designed that way | The user and the logging layer | Can the user see which sources were used? [S7] |
| 6. Records are kept | Conversation history, feedback and logs may be stored | Whoever holds the store, per its retention settings | What is stored, where, how long, and how is it deleted? [S1] |
Two points in this flow commonly surprise buyers. First, processing location is not always the same as storage location. Microsoft states that prompts and responses are processed within the customer-specified geography for standard deployments, but that deployment types labelled Global or DataZone may process them elsewhere, in any geography where the model is deployed or anywhere within the specified data zone [S1]. The fact that a service stores your data in one place does not tell you where it is processed. Second, some features keep state. For Models sold by Azure in Microsoft Foundry, Microsoft lists stored message history, threads, uploaded files and stored completions as places where the service persists data, and states that such data can be deleted by the customer. It labels the Assistants API and stored completions as preview, and warns that preview models or features might not support all of the stated storage conditions [S1]. A feature that makes a conversation continuous is also a feature that keeps the conversation.
Comparing arrangements fairly
Buyers often contrast public and private AI as if one is inherently safe. The evidence suggests a more nuanced reality. Each configuration shifts where questions arise, but it does not eliminate the need to ask them.
What changes across common arrangements (illustrative, drawn from the inspected documents)
Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.
| Arrangement | Who operates the model service | What the documents show | What still needs verifying |
|---|---|---|---|
| Commercial API or business plan from a model developer | The model developer | Anthropic states that by default it does not use inputs or outputs from its commercial products to train its models, with exceptions such as feedback a user chooses to submit [S2] | Retention period, who can access data, how you would confirm the default applies to your account |
| Model service inside a large cloud customer's own subscription (here, Models sold by Azure in Microsoft Foundry) | The cloud provider, in your cloud tenant | Microsoft states that prompts, completions, embeddings and training data are not available to other customers or to the model's original developer and are not used to train foundation models without the customer's permission; the same page says preview features may differ [S1] | Deployment type and processing region, abuse-monitoring settings, which features store data, whether any feature in use is in preview |
| Provider-operated dedicated environment | A managed service provider, for you alone | Infradapt and Hyve describe single-tenant or dedicated environments with access controls [S6][S7] | Who at the provider can access it, where backups live, what the contract says about subcontractors |
| Provider-operated shared platform with logical isolation | A managed service provider, on shared infrastructure | Hyve describes this as an option, with isolated workloads on shared infrastructure [S7] | How isolation is done and tested |
| Hardware you operate yourself | Your own staff | The NCSC guidelines treat protecting infrastructure and models, incident management and responsible release as part of secure deployment [S5] | That you have the staff and processes to run it |
Fairness cuts both ways. A large cloud provider's documented controls can be stronger than a small provider's undocumented ones. A dedicated environment run by a provider you cannot inspect can be less verifiable than a shared service with published terms and audit reports. And an environment you run yourself moves the work to your own staff. Private does not automatically mean on your premises, on hardware you own, or free of every outside service provider.
Training, retention and review are different questions
Owners often ask one question, "will it learn from our data?", when there are at least four. Whether your inputs are used to train a model is one. Whether they are kept, and for how long, is another. Whether a person at the provider can read them for abuse review is a third. And whether the service stores your own data so that it can answer later is a fourth.
The documents show these come apart. Anthropic's privacy center states that inputs and outputs from its commercial products, and not its consumer plans, are not used for training by default. It describes exceptions: when a user submits thumbs-up or thumbs-down feedback, the related conversation is stored for up to five years and may be used to train models, and explicit bug reports or a choice to allow use of the data can also permit training use. A Primary Owner or Owner of a Team or Enterprise plan can disable the feedback ability [S2]. A statement about training therefore comes with conditions that matter. Microsoft separates training use from abuse monitoring: it states that prompts and completions are not used to train the base models, and also describes an abuse monitoring system in which a sample of prompts and completions may be selected for review, automated by default with additional review by human reviewers where necessary, and that managed customers may apply to modify abuse monitoring. For a customer approved for that, the storage for human review and the human review are not performed, although automated review may still be conducted [S1]. Both statements are true at once.
The vendor pages we read make comparable promises in shorter form. Infradapt's page says documents, prompts and outputs stay inside the private environment and are not used to train others' models [S6]. That is a vendor statement on a marketing page. It is a lead for a contractual question, not a substitute for the contract.
Retrieval and memory also differ from training. Retrieval supplies material to a model at the moment of the question, as in the flow above [S7][S1]. Changing a model's weights is a separate act. A buyer should ask for each of these separately and should be skeptical of any single sentence that claims to cover them all.
What can go wrong
The NIST Generative AI Profile outlines privacy risks associated with generative systems. Models can leak, generate, or infer sensitive personal details. The profile also describes data memorization, where adversarial attacks have forced models to reveal sensitive information from their training sets [S3]. Furthermore, it notes that most model developers do not disclose the specific data sources on which their models were trained [S3]. For a buyer, this is a reason to ask separately about how requests are handled and what is known about the model's training data. The questionnaire should address both.
The OWASP project for large language model applications maintains a list of the most critical security vulnerabilities in such applications and has expanded into a broader generative AI security initiative [S8]. Use this as a reference point. You can ask providers which categories from that list they have tested and how. This paper does not review the list’s contents.
For businesses under UK data protection law, the Information Commissioner's Office publishes guidance on AI and data protection. It is organized around data protection principles, with sections on accountability, governance, transparency, lawfulness, accuracy, and fairness. The page states the guidance was updated on 15 March 2023 and is under review due to changes from the Data (Use and Access) Act [S4]. Other jurisdictions have different rules. This is not legal advice. A lawyer should determine if a specific deployment meets specific obligations.
The privacy questionnaire
Send these questions to each provider and request written responses. For every answer, identify the supporting evidence type: contract, technical control, or observed evidence. If a provider responds only with marketing language, they are offering a fourth type of answer, which is a claim without support.
In the evidence column, C means contractual promise, T means technical control, and O means observed evidence.
Privacy questionnaire for a managed AI provider
Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.
| # | Question | A checkable answer looks like | Evidence kind |
|---|---|---|---|
| 1 | Where is each of these stored: documents, indexes, conversation history, logs, backups? | A list of locations by data type and region | C, T |
| 2 | Where is the model run for each request, and can that location change without notice? | A named region and a change-notice term; for cloud services, the deployment type [S1] | C, T |
| 3 | Which outside services touch our information, including model hosts, search, analytics and support tools? | A named list, with their roles | C |
| 4 | Are our inputs or outputs used to train or improve any model? Under what exceptions? | A contract clause with exceptions listed, such as feedback features [S2] | C |
| 5 | Is any of our information retained after a request, for how long, and who can read it? | Retention periods by data type and a list of roles with access | C, T |
| 6 | Does any person at the provider or its suppliers review prompts or outputs, and when? | A description of abuse review and how to opt out where offered [S1] | C |
| 7 | How does the system decide what a user may see? | A statement that retrieval follows existing permissions, and a demonstration [S7] | T, O |
| 8 | Who at the provider can access our environment, and how is that access granted and recorded? | A role list, approval process, and access log extract | T, O |
| 9 | What is logged, who can read the logs, and can we receive them? | Event types, retention and a sample report | T, O |
| 10 | How is our environment separated from other customers? | A description of the isolation method and how it is tested | T, O |
| 11 | What happens at exit: export, deletion, and confirmation? | Formats, timeline and a written deletion confirmation | C, O |
| 12 | What happens in an incident involving our information? | Notification terms, timelines and contacts | C |
| 13 | Which security and AI-risk practices does the provider follow, and how are they evidenced? | Named documents or audit reports, not a claim of alignment [S3][S5] | O |
| 14 | What do you not control or cannot promise? | A direct answer; an empty answer is itself informative | C |
How to read the answers
Mark answers green if specific and supported by contracts, controls, or observations; amber if specific but only supported by statements; and red if vague or absent. Two or more red answers among questions 4, 8, 10, and 11 is a reason to pause. This is our suggested screening rule, not a validated risk model. Amber answers are reasonable to carry into a pilot if the pilot is built to turn them into observed evidence. For instance, this can be done by asking a person without access to try to retrieve a restricted record and recording the refusal.
Turning claims into observations
A bounded pilot converts amber answers into observed evidence by limiting the information involved on purpose. Before connecting real company records, agree on a short list of observations the provider will help you make, and how long each will take. This list serves as a starting plan. Some items require little time, while the deletion test depends on the provider's stated retention period.
- Permission test. Ask a user who should not have access to a restricted record to request it through the service, and record whether the answer reveals any of its contents. A refusal in the log is observed evidence for question 7.
- Source test. Ask a question whose answer is in exactly one document, and check which source the answer cites. A matching citation in one answer shows only that the citation matched in that case. It does not show that references are reliable in general, and it does not show what the service actually retrieved; ask for a retrieval trace if you need that.
- Log test. Ask for the log of the two tests above. If the provider cannot produce it, you have learned something about question 9 that no proposal would have told you.
- Location test. Ask the provider to show, from its own configuration or a report, the region in which the pilot's requests were processed. Compare it with the answer to question 2.
- Deletion test. Delete a test document from the connected source, wait the stated period, and ask about it. Then request deletion of the pilot's stored history and ask for the confirmation described in question 11. Failing to retrieve the document is not proof that every retained copy, index entry or backup is gone, so ask for the retention and deletion evidence in questions 5 and 11 as well.
- Boundary test. Ask the service to do something outside its stated scope and note how it declines or escalates. A service that cannot say what it will not do is hard to govern.
Use synthetic data for pilots and record dates, testers, requests, and outcomes. This approach creates a small evidence file to compare against the contract. It also gives providers a fair chance to demonstrate their work. This is a better basis for long-term commitments than relying on persuasive marketing materials.
Reading vendor and standards language
Three habits make privacy language easier to read. First, look for the subject of each sentence. A statement like "your data is kept private" has no actor, while "the provider does not access stored conversations except under these conditions" names one. Second, look for exceptions in the same paragraph or the next. The Anthropic and Microsoft statements discussed above each carry specific exceptions, such as submitted feedback or abuse review, and those exceptions are where a buyer's real questions live [S1][S2]. Third, distinguish a framework from a certification. The NIST profile and the NCSC guidelines describe practices and risks, and a provider that cites them has told you which documents it reads, not that an independent party has found it compliant [S3][S5]. Infradapt's page, for example, lists controls designed to support HIPAA, CJIS and PCI, assessed per workload [S6]. These concern compliance requirements, distinct from the AI-risk guidance discussed above. When a provider says its controls are designed to support a framework, ask for the assessment that says they do.
Limitations
- This paper rests on eight public documents from eight organizations, retrieved on the dates listed in the references. Two of them are vendor descriptions of their own services: they show what the vendors say, not what they deliver.
- The Microsoft document covers Models sold by Azure in Microsoft Foundry and warns that preview features may differ. The Anthropic page covers its commercial products, not its consumer plans. Both describe policies as of their page dates and may change; a buyer should read the current version for the product being evaluated.
- The OWASP page was read only as a project overview, and the ICO guidance only as a summary page that states it is under review.
- The data-flow table is a constructed illustration, not a description of any real system, and the arrangement comparison summarizes what these particular documents state, not the market.
- We did not test any provider's service or verify any of its claims. The questionnaire is a practical aid, not a compliance assessment or legal advice.
- This first edition is open for reader review. Check the current provider terms before relying on any vendor statement.
References
- Microsoft, Data, privacy, and security for Models sold by Azure in Microsoft Foundry (Primary vendor documentation; 2026-05-19 (page last updated)). Accessed 2026-10-20.
- Anthropic, Is my data used for model training? (Privacy Center) (Primary vendor documentation; 2026-08-18 (page date)). Accessed 2026-10-20.
- NIST, NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (Primary standards body publication; 2024-07). Accessed 2026-10-20.
- UK Information Commissioner's Office, Guidance on AI and data protection (Primary regulator guidance (UK); 2023-03-15 (updated; page states it is under review)). Accessed 2026-10-20.
- UK National Cyber Security Centre, Guidelines for secure AI system development (Primary government guidance; 2023-11-27 (version 1.0)). Accessed 2026-10-20.
- Infradapt, Managed private AI for business (Vendor description of its own offering, not independent proof of performance; undated page). Accessed 2026-10-20.
- Hyve, Managed private AI hosting (Vendor description of its own offering, not independent proof of performance; undated page). Accessed 2026-10-20.
- OWASP Foundation, OWASP Top 10 for Large Language Model Applications (Project overview page (not the list itself); undated page). Accessed 2026-10-20.
Contributors and disclosure
Dominus Foundry (publisher; develops Sabina and has a commercial interest in managed AI); Drafting: Claude-assisted manuscript, with selected prose revised by Clio's approved internal model and edited by Dominus Foundry.; First edition. Published for reader review.
Published by Dominus Foundry, creators of Sabina. This publication has a commercial interest in managed AI.