Vice President · TheGreyMatter.ai
In brief
A promise not to train on your data does not answer where data is stored, who can access it, or when every copy is deleted. Review the exact product, feature, configuration, and agreement.
Key takeaways
- Ask separate questions about training, storage, access, and location.
- Include application logs, retrieval stores, and exports in the data flow.
- Approve a defined use case and configuration, then recheck material changes.
An AI vendor says that customer data is not used for model training. That may be a valuable commitment, but it is only one part of a data handling review. A team deciding whether to connect a confidential document collection needs to understand the entire route from the original file to the generated answer. The following review method turns a broad assurance into a set of specific, testable questions.
Separate the four questions
Training concerns whether data is used to develop or improve a model. Retention concerns what is stored and for how long. Access concerns which people and services can retrieve it. Residency concerns where processing and storage occur. An answer to one does not automatically answer the others, and the meaning of each commitment depends on its scope.
Microsoft's documentation for Foundry Models sold by Azure separates model training commitments from features that persist conversation or file data. Google's Gemini Enterprise Agent Platform documentation likewise distinguishes restrictions on training from the configuration and feature requirements for zero data retention. These are examples of product-specific documentation, not evidence that every enterprise AI plan has identical terms.
Create a data flow evidence sheet
Start with the actual deployment rather than the vendor's broadest marketing statement. Record the product name, plan, enabled features, model endpoint, region settings, identity configuration, and applicable agreement. Ask the vendor to connect each answer to documentation or a contractual provision that covers that configuration.
Then follow one synthetic document through the proposed system. The model endpoint may be only one destination. A connector, extraction service, retrieval index, observability tool, support process, and exported answer can each create additional records. Give every stage an owner who can explain retention and deletion. Mark unknowns explicitly instead of treating an unanswered field as a favorable answer.
| Question | Evidence to request | Owner to identify |
|---|---|---|
| Is this data used for training? | Terms for this product and any enabled opt-in features | Vendor account or privacy contact |
| What is retained? | Data categories, durations, exceptions, and deletion behavior | Application and platform owners |
| Who can access it? | Identity scopes, support access process, and audit evidence | Security and access owners |
| Where is it processed and stored? | Region configuration and feature-specific location terms | Infrastructure and contract owners |
| What copies leave the service? | Logs, exports, integrations, caches, and backup inventory | Owners of each connected destination |
Worked example: a private equity data room assistant
Consider a hypothetical deal team testing an assistant over a limited set of diligence documents. The initial scope could be read access to synthetic documents and a draft answer with source references. The evidence sheet should distinguish the data room, the ingestion service, the search index, the model request, and the answer history. A training restriction at the model provider does not describe the other four stages.
Before adding confidential material, the review team should resolve which deal members may retrieve which files, how a removed member loses access, and how the project is closed. If the assistant exports answers to another workspace, that destination needs its own owner and retention decision. This is a proposed review scenario, not a claim that a particular vendor or portfolio company has passed it.
Test deletion and access with harmless evidence
Create a synthetic document containing a unique marker. In a controlled test, verify that an authorized user can retrieve it and an unauthorized user cannot. Remove the first user's access and repeat the query through the application, not only through the original repository. Record the elapsed time and the policy decision. A permission change is incomplete if an old retrieval path still exposes the content.
Separately, follow the documented deletion process and inspect the destinations listed on the evidence sheet. A failed search is useful evidence about that search path; it does not prove that every log, backup, or support copy has disappeared. Combine observable tests with the relevant retention terms and operator evidence. Keep the distinction between a technical test result and a contractual commitment visible in the approval record.
- Use synthetic content with a distinct marker.
- Test both allowed and denied access before changing permissions.
- Repeat the test after access is withdrawn.
- Check retrieval, saved answers, logs, and exports within the agreed scope.
- Record what the test demonstrated and what still depends on vendor evidence.
Make the approval specific enough to maintain
A useful decision record names the permitted data categories, use case, configuration, business owner, unresolved exceptions, and next review date. It also names changes that require another review: enabling a new feature, adding a connector, changing a region, broadening document access, or moving to a different service plan. Avoid an unlimited approval described only as permission to use AI.
For a pilot, define the smallest document set and user group that can answer the operating question. Keep a route to stop ingestion, revoke access, and retire the project. Assign someone to check whether current settings still match the approved record. The practical deliverable is a maintained boundary around a real workflow, supported by evidence that a later reviewer can inspect.
From reading to doing
Put it to work: turn one assurance into an evidence request
Start with one proposed use case and one synthetic document. Suppose a team wants to summarize diligence files without retaining them after a project closes. Write down what that means for the original repository, uploaded files, retrieval index, conversation history, logs, and exported summaries. A decision about one location cannot silently stand in for the others.
The useful output is a short evidence record, not a green check beside the vendor's name. In this hypothetical review, an answer saying that model inputs are excluded from training leaves application logs unresolved. Mark that item unknown, identify the person who can resolve it, and keep the proposed approval limited to the configuration actually reviewed. An unknown is a follow-up task, not proof of either safety or misconduct.
- Record the exact product, plan, endpoint, enabled features, region configuration, and agreement being reviewed.
- Follow the synthetic document through each destination and list the categories of data retained there. Distinguish content from metadata.
- Ask for the retention period, deletion process, exceptions, access rules, and applicable evidence for each destination.
- Label each answer documented, observed in a test, or unresolved. A source link and a test result answer different kinds of questions.
- Write the permitted use, remaining conditions, accountable owner, and changes that require another review. Have the appropriate internal reviewers evaluate the record.
Common questions
Does no training mean no storage?
No. A service can exclude customer data from model training while storing conversation history, uploaded files, logs, or other state. Review the retention behavior of the exact features in use.
Does one privacy policy cover every AI product from a vendor?
Do not assume so. Check the named product, account type, feature, region, and agreement. Consumer products, APIs, and enterprise applications can have different commitments and settings.
Is zero data retention at the model endpoint enough?
It addresses only the scope covered by that commitment. Your application, retrieval system, integrations, logs, and exports may retain data independently and need their own review.
Sources and evidence
AI assisted editorial analysis. Primary sources checked October 10, 2026. The worked examples and proposed review procedures are editorial illustrations, not reported customer results, vendor guarantees, or claims of personal experience.
One useful next step: Choose one idea from this note and test it at the smallest scale that could teach you something this week.
