Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Separate five questions that often get blurred: whether data is used for training, how long the provider retains it (including for abuse monitoring), where it is processed and stored, which sub-processors touch it, and what your own product stores in logs, caches and evaluation sets. Get each answered in the contract, offer zero-retention and regional options where available, and publish a clear data-handling page customers can hand to their security team.
How to approach it
Recognise that customers' security and legal teams ask precise questions, and "we use a reputable provider" does not answer them. List the distinct questions, then cover both the provider's side and your own system, since most leakage risk sits in what your product stores.
A strong answer
Five separate questions.
| Question | Why it matters | What to secure |
|---|---|---|
| Is customer data used to train models? | Customers fear their content improving models others use | Contractual commitment of no training use for API data; check default terms per product tier |
| How long is it retained, and why? | Retention for abuse monitoring or debugging is still retention | Retention period in writing; zero-data-retention options where offered, and what they exclude |
| Where is it processed and stored? | Residency requirements (EU, India, sector rules) | Regional endpoints; written processing location |
| Who else touches it? | Sub-processors extend the trust chain | Sub-processor list with notification of changes |
| What security and certifications apply? | Procurement checklists | Security reports and certifications, breach notification terms |
Your own system is half the answer. Customers' data also lives in your:
- Prompt and response logs and traces.
- Caches (prompt caches, any response caches).
- Vector indexes and embeddings.
- Evaluation datasets built from production traffic.
- Support tooling where staff can view conversations.
- Backups.
For each, define retention, location, access controls, and whether customer data can be used to improve your product. If you use customer conversations to build evaluation sets or train anything, that must be in the contract, with an opt-out for enterprise customers.
What to offer.
- A clear default: no training on customer data, defined retention, regional processing for customers who need it.
- Options for stricter needs: zero retention of prompts and outputs in your logs (accepting harder debugging), dedicated regional deployments, customer-managed encryption keys where feasible.
- A public data-handling page and a standard security questionnaire response, so sales does not improvise answers.
Pitfall: zero retention is rarely absolute. Read the terms feature by feature and model by model, and describe them precisely to customers. Two providers' published terms, checked 6 November 2026, show why.
| Anthropic (retention docs) | OpenAI (your data) | |
|---|---|---|
| Training | Retained data is never used for training without express permission | API data not used for training by default since 1 March 2023 |
| Abuse monitoring | Flagged chats or sessions may be retained up to 2 years, even under ZDR | Abuse monitoring logs kept up to 30 days by default |
| Zero retention | ZDR by arrangement; the Fable and Mythos models require 30-day retention and are outside ZDR unless Anthropic expressly authorises it | ZDR needs OpenAI's approval |
| Features outside ZDR | Batch (29-day retention), Files, code execution containers (up to 30 days) and others | Files, vector stores, batches, fine-tuning, evals, assistants and others |
| Region | inference_geo controls where inference runs and is ZDR-eligible | Regional storage in ten regions; regional processing only in the US, Europe and the UAE |
Two lines in that table change product decisions. Anthropic's documentation says that under ZDR the API does not block ineligible features: calling Batch or Files is a choice to step outside the arrangement for that data. So a cost team that moves a nightly job to batch pricing can break a promise sales made, with no error to warn anyone, and the control has to live in your gateway, because the provider's contract will not stop the call. And OpenAI distinguishes storage from processing: a customer promised "EU data stays in the EU" needs regional processing, which covers fewer regions than storage.
What interviewers probe next
"A big prospect wants a guarantee that no data ever leaves their country." Check whether the provider offers in-country processing; if not, consider a self-hosted open model for that customer, priced accordingly. Never promise what the architecture cannot enforce.
"Finance wants batch pricing for the nightly summarisation job. Any problem?" Check the contract first. If the customer was promised zero retention, batch endpoints at both providers sit outside it, so either route that customer's data through the synchronous path or get their agreement in writing.
"Can we use customer conversations to improve our prompts?" Aggregate learnings, yes, if the contract allows. Copying customer content into shared eval sets needs explicit permission.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Questions | "They don't train on our data" | Training and retention | Training, retention, location, sub-processors and security as distinct questions |
| Own system | Not considered | Mentions logs | Every store in our product with retention, location and access defined |
| Offer | Improvised answers | Contract terms | Clear defaults, stricter options, zero-retention caveats per feature and model enforced in the gateway, published data page |
Common mistakes
Answering every data question with "no training".
Forgetting your own logs and evaluation sets.
Promising residency the architecture does not enforce.