Data Privacy Questions AI Buyers Ask

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

The data privacy questions AI buyers ask are a fairly stable set: whether customer data trains the vendor's models, how long data is kept and how it's deleted, which sub-processors and model providers touch it, where it's stored and processed, what the data processing agreement says, and what gets logged. Underneath, they're one question asked from several angles: if we hand you our data, can we prove afterwards that we stayed in control of it?

This page lists the questions, what each one tests, and what a credible answer looks like. Reviewers can't act on a slogan like "we take privacy seriously." They can act on a document, a contract clause or a setting they can verify. For the wider picture of buyer doubt, see selling AI to skeptical buyers. For the technical controls behind the answers, see AI agent data privacy.

Why These Questions Come Up in Every Deal

AI products change what happens to data in three ways buyers have learned to watch. The product often sends customer content to a third-party model provider, it may log prompts and outputs containing personal or confidential information, and the model raises a new question: could what goes in come back out elsewhere?

Regulators have given buyers a vocabulary. The European Data Protection Board's opinion on AI models, adopted in December 2024, says a model can only be considered anonymous if it's very unlikely that individuals whose data built it can be identified, or that personal data can be extracted from it through queries. It also says a model built on unlawfully processed personal data can affect the lawfulness of its deployment, unless it has been duly anonymised. A buyer's counsel who has read that will ask about your training data, not just your hosting.

The Core Questions, What They Test, and the Evidence

Buyer question What it's really testing Credible evidence
Do you train on our data? Whether customer content leaves the engagement A written no-training term in the contract and the model provider's matching terms
How long do you keep it, and how is it deleted? Whether you control the data lifecycle Retention schedule, deletion process and timeline, backup handling
Who are your sub-processors? Who else can see the data A current sub-processor list with purposes and locations, plus a change-notice process
Where is data stored and processed? Cross-border exposure Region options, transfer mechanism, a data flow diagram
What does your DPA say? Whether obligations are contractual A signed DPA with processing scope, security and breach terms
What do you log? Hidden retention in prompts and outputs Logging scope, who can access logs, log retention
How do you handle personal data? Minimization and exposure Data inventory, redaction options, access controls
What's your role under GDPR? Who is accountable for what A stated controller or processor position per data type

1. "Is Our Data Used to Train Models?"

This is usually the first question and often the one that decides whether the deal continues. It tests two things: whether your own company trains on customer content, and whether the third-party model you call does.

A slogan answer ("your data stays yours") fails because it doesn't say which data, which model or what happens by default. A credible answer separates your own models (training, fine-tuning, evaluation, product improvement, and whether any is opt-in), your model providers (what their terms say for the tier you use), and feedback or support data.

Vendors increasingly publish this themselves, which makes it checkable. OpenAI's API data guide states that data sent to the OpenAI API is not used to train or improve its models unless a customer explicitly opts in, and that abuse monitoring logs are retained for up to 30 days by default, with exceptions. Anthropic's privacy center says it won't use inputs or outputs from its commercial products to train its models by default, with exceptions such as feedback a customer chooses to report. Policies change, so buyers will want current terms attached to your documentation.

The pattern: your answer should be only as strong as the weakest term in the chain.

2. "How Long Do You Keep Our Data, and How Is It Deleted?"

Retention questions test whether the vendor has a data lifecycle at all. Buyers want to know what's kept, for how long, where, and what "deleted" means in practice.

GDPR gives the controller a specific lever here. Under Article 28, the contract with a processor must require that, at the end of the services, the processor deletes or returns all personal data to the controller and deletes existing copies, unless Union or Member State law requires storage. So a buyer subject to GDPR is asking you to put something like this in the DPA, whether or not they cite the article.

A credible answer covers retention by data type (prompts, outputs, files, embeddings, account data and logs often differ), deletion triggers, how long deleted data persists in backups, an explicit position on derived data such as embeddings and fine-tuned artifacts, and a deletion confirmation on request.

Be careful with "zero retention." It's often true only for a specific mode of a specific service, with exceptions for abuse monitoring or legal holds. If it's conditional, say so.

3. "Who Are Your Sub-Processors and Model Providers?"

Sub-processor questions test the supply chain. An AI product is rarely one company: it's usually your application, a cloud host, a model provider, and often an observability or vector database vendor. The buyer is asking who among them can see the data.

Article 28 sets the rule for GDPR contracts. A processor may not engage another processor without the controller's prior specific or general written authorisation. Under a general authorisation, the processor must tell the controller about intended additions or replacements so the controller can object. And the same data protection obligations in the contract must be passed down to the sub-processor. A buyer's reviewer will read your DPA against those points.

A credible answer includes a published sub-processor list (name, purpose, location, last-updated date), a change-notice process, named model providers with the terms that apply, and evidence that sub-processors are bound by equivalent terms.

If you route customers to different model providers, say how, and whether a customer can pin one. Silent provider switches are what this question exists to catch.

4. "Where Is Our Data Stored and Processed?"

Residency and transfer questions test cross-border exposure. They matter most to buyers in the EU, the UK and other regions with transfer rules, and to any buyer with contractual or sector residency requirements.

Storage location is where data rests. Processing location is where it's handled, including by the model provider at inference time. A vendor can store data in one region and still send prompts to a model endpoint elsewhere.

Under GDPR, Article 44 provides that a transfer of personal data to a third country may take place only if the conditions in the Regulation's transfer chapter are met, including for onward transfers. For the United States, the European Commission's page on EU-US data transfers explains that its July 2023 adequacy decision on the Data Privacy Framework lets personal data flow to US companies that participate in it. So a buyer may ask whether you and your sub-processors are certified, or what other mechanism you rely on.

A credible answer includes region options by plan, a data flow diagram showing storage, processing and model calls, the transfer mechanism for each cross-border flow, and a statement on whether staff outside the region can view customer data.

Don't promise residency you can't enforce end to end. If inference happens in a different region than storage, a buyer's reviewer will find it in the diagram, and finding it there is worse than reading it in your first answer.

5. "What Does Your Data Processing Agreement Say?"

The DPA tests whether your promises are contractual. Many buyers won't proceed on a terms-of-service page alone, and they'll compare the signed DPA with your questionnaire answers.

A DPA typically specifies the subject matter and duration of processing, the type of data, the instructions the processor works under, confidentiality, security measures, sub-processor rules, assistance with data subject requests, deletion or return, and audit rights. Article 28 lists these as required contract content for GDPR purposes.

Breach terms deserve attention. Under Article 33, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, and a processor must notify the controller without undue delay after becoming aware of one. That's why buyers ask for a specific notification window in the DPA instead of a vague "promptly."

Have a standard DPA ready before the first request, make sure it matches the product, and keep questionnaire answers consistent with it.

6. "What Do You Log, and Who Can See It?"

Prompts and outputs often contain exactly the sensitive material the buyer wanted to protect, and logs can outlive the data they came from. This question tests whether there's hidden retention. A credible answer states what's logged (full content, metadata only, tool calls), why, who can access it, how long it's kept, whether the customer can shorten that, and whether logs feed anything else such as evaluation sets.

The OpenAI guide cited above shows the level of detail buyers expect: it distinguishes abuse monitoring logs from application state and lists retention by endpoint.

7. "How Do You Handle Personal Data?"

This question tests minimization and exposure: what personal data the product needs, what it collects beyond that, and what happens if personal data reaches a prompt that shouldn't have it.

The UK Information Commissioner's Office covers this ground in its guidance on AI and data protection, which includes chapters on lawfulness, transparency, fairness, security and data minimisation, and individual rights in AI systems. The ICO notes the guidance is under review following the Data (Use and Access) Act.

A credible answer includes a data inventory with reasons, minimization options such as redaction before data reaches a model, a stated position on special category data, how individual rights requests are handled, and access controls.

On tenant isolation, "your data is separate" isn't a control. A description of how retrieval indexes, caches and fine-tuned artifacts are scoped per customer is.

8. "Are You a Controller or a Processor?"

Buyers ask about GDPR roles because the answer determines who is accountable. Under Article 4, a controller determines the purposes and means of processing, while a processor processes personal data on the controller's behalf. In a typical B2B AI deployment, the customer is the controller of its own data and the vendor is the processor, acting on documented instructions.

Where it gets contested is when the vendor wants to use customer data for its own purposes, such as improving its product. That can make the vendor a controller for that processing. So the training question and the role question are connected: if your answer to the first is "we may use data to improve our service," your answer to the second can't be a simple "we're only a processor."

State your position per data category and purpose, put it in the DPA, and make the privacy notice match.

9. EU AI Act Touchpoints

The EU AI Act is a different law with different questions. The European Commission's AI Act page says the Act entered into force on 1 August 2024, that prohibited practices and AI literacy obligations applied from 2 February 2025, and that governance rules and obligations for general-purpose AI models applied from 2 August 2025. It also says high-risk rules for certain sensitive areas, including employment and education, have been moved to 2 December 2027 under the AI Omnibus simplification. Dates have been moving, so confirm them before quoting.

For privacy conversations, the practical touchpoints are your role (provider, deployer, or builder on someone else's general-purpose model), transparency duties such as telling people they're interacting with a chatbot, your risk classification and the basis for it, and the documentation you hold.

Don't claim "AI Act compliant" as a blanket statement. Say which provisions apply, how you assessed that, and what you've documented.

What a Credible Answer Package Looks Like

Buyers want a package they can hand to legal and security without a meeting. A workable set is a DPA matching the product, a dated sub-processor list, a data flow diagram, a retention and deletion schedule, a short statement on training and model providers, a security overview with any audit reports you actually hold, and a named owner with a response time.

Date everything and review it on a schedule, because stale documents cause most contradictions. And answer "no" or "not yet" plainly: a buyer who learns a limit from your documentation trusts the rest more than one who finds out later.

For how privacy review fits into the wider buying process, including who else gets involved, see the AI buying committee. For how contract terms and pilot criteria interact, see AI pilots to contracts. For the compliance and security sides, see AI agent compliance and AI agent security.

Key Facts

  • Anonymity bar: the EDPB's December 2024 opinion on AI models says a model is anonymous only if identification and extraction of personal data are both very unlikely.
  • Sub-processors: under GDPR Article 28, a processor needs written authorisation to engage another processor, and the contract must require deletion or return of data at the end.
  • Breach timing: a controller notifies the authority within 72 hours where feasible, and a processor tells the controller without undue delay (Article 33).

About the author

Brian Tr

Brian Tr

Co-Founder & COO

Brian Tr is Co-Founder and COO of Rework, with 12+ years in B2B go-to-market and operations. Brian scaled Rework from 0 to 10,000+ B2B customers across CRM and productivity tools. Brian writes for founders and owner-CEOs: startup fundamentals, founder-led and family businesses, partnerships, and how SaaS, marketplace, AI and EdTech companies grow.