Reviewing how an AI vendor handles your data

The data handling review for an AI vendor requires answers to six core questions that go beyond standard data handling review:

1. Is customer data used to train the model — at the vendor level or at any subprocessor level?
2. How long is inference data (prompts and completions) retained, and by whom?
3. Who can access retained inference data within the vendor organisation and within any subprocessors?
4. What is the full subprocessing chain for the AI feature?
5. Where is data processed and stored — and are the residency requirements of applicable regulations met?
6. How is customer data deleted on contract termination, including data held by subprocessors?

These six questions address risks that are categorically different from standard data handling risks. They reflect the fact that AI systems process the semantic content of customer data in ways that conventional software does not — and that the outputs of that processing may be retained, used for training, or transferred to parties outside the customer's direct relationship.

Training data use is the question organisations most frequently fail to ask — and the one with the most significant data protection implications. The question is not just whether the vendor uses customer data for training. It is whether anyone in the subprocessor chain does.

The specific questions for training data use:

• Does the vendor use customer data — including prompts, completions, documents uploaded, or user interactions — to train or fine-tune the model that powers the product? If yes, what is the legal basis and opt-out mechanism?
• Does the model provider use inference data from the vendor's API calls to train or fine-tune their model? Does the vendor's agreement with the model provider opt out of this?
• If an opt-out exists, how does the vendor verify it is in effect? What contractual commitment does the model provider make?
• Has the vendor ever used customer data for model improvement or evaluation purposes, even under a different description?

A vendor response that says “we do not use your data for training” answers one half of the question. The other half is: does your model provider? The two questions are different and require different answers.

Inference data retention covers how long prompts and completions are retained by the vendor and by any subprocessors. Retention practices vary significantly across vendors and model providers:

• No retention: The inference request and response are processed in memory and discarded. The ideal from a data protection perspective, but not universal — some vendors need to retain inference data for audit, debugging, or moderation purposes.
• Short-term retention: Inference data is retained for a defined short period (hours to days) for abuse detection, debugging, or customer support purposes, then deleted.
• Long-term retention: Inference data is retained for extended periods — weeks, months, or indefinitely — for quality improvement, model evaluation, or other purposes.

The review must establish the retention period not just for the vendor's systems but for each subprocessor. A vendor may retain inference data for 30 days; the model provider it uses may retain it for 30 days on a different calendar. The effective retention period for any given inference request is the maximum across all parties in the chain.

The complete subprocessing chain for an AI feature must be documented to understand the full data handling picture. For most enterprise AI features, the chain includes at minimum the SaaS vendor and the model provider. It may include additional parties: AI middleware (orchestration frameworks that route requests), embedding model providers (separate from the generation model), vector database providers (for RAG-powered features), and moderation service providers.

For each party in the chain, the review must document:

• What data they receive as part of the AI feature's operation.
• Their data retention practices for that data.
• Whether they use the data for training or model improvement.
• The contractual basis for the data transfer to that party.
• Their security certifications and data protection commitments.

Data residency for AI inference data is complicated by the geographic distribution of model provider infrastructure. Foundation model providers often process inference requests on infrastructure distributed across multiple regions, with routing determined by capacity rather than the customer's residency requirements.

The review must establish:

• Whether the vendor can commit to processing inference requests within a specified geographic region.
• Whether the model provider offers region-specific inference endpoints for enterprise customers.
• Whether the vendor's enterprise agreement includes data residency commitments for the inference layer.
• Whether there are international transfer mechanisms in place for any transfers that do occur across jurisdictions.

Deletion rights for AI-processed data require attention to several layers. Standard deletion provisions cover data stored in the vendor's platform. AI-specific deletion concerns:

• Inference data deletion:Can retained inference data (prompts and completions) be deleted on request or on contract termination? Within what timeframe? Do the vendor's deletion obligations cascade to subprocessors?
• Model training data deletion:If customer data was used in model training or fine-tuning, deletion rights are complex — data embedded in model weights cannot be deleted in the conventional sense. What is the vendor's position on this? What alternative remedies are available?
• Data subject erasure: How are GDPR erasure requests handled for data that has been processed by the AI feature? Particularly relevant for AI features that process employee data or customer personal data.

The AI data handling review should produce a documented record covering all six core question areas. The checklist:

• Training data use: vendor response documented; subprocessor training data use documented; opt-out mechanism confirmed or gap noted.
• Inference data retention: retention period documented at vendor level; retention period documented at each subprocessor level.
• Access controls: who can access retained inference data documented at each level.
• Subprocessing chain: complete chain documented with each party's data handling terms.
• Data residency: commitments or gaps documented; applicable residency requirements confirmed or noted as unmet.
• Deletion rights: vendor deletion obligations documented; cascade to subprocessors confirmed or gap noted; training data deletion position documented.

Any gap in this checklist is a control gap that should appear in the disposition record with a closure plan or a risk acceptance note. For the full scope of AI vendor subprocessor obligations, see AI subprocessor risk in your vendor chain.