AI DPA Checklist: What Enterprise Buyers Actually Verify
There’s a question in nearly every enterprise AI security questionnaire that looks simple but kills deals: “Do you have Data Processing Agreements with each of your AI providers?”
Most vendors say yes. Some actually do. Almost none can produce the evidence on demand.
I’ve been in IT security for 30+ years, and I’ve watched this exact pattern play out with cloud hosting, SaaS subprocessors, and now AI providers. The DPA question isn’t really about the DPA. It’s a proxy question for “do you actually know what happens to our data when you send it to an AI provider?”
The vendors who treat it as a checkbox get follow-up questions. The vendors who treat it as an evidence opportunity close deals.
Why AI DPAs Are Different
A Data Processing Agreement between your company and an AI provider isn’t the same as the DPA you have with your cloud hosting provider or your analytics vendor. AI introduces specific data processing concerns that traditional DPAs weren’t designed to address.
Training data. Does the AI provider train on the data you send through their API? Most major providers offer opt-out or zero-retention API endpoints, but the default varies. OpenAI’s API has zero-retention by default. Their ChatGPT product does not. Anthropic’s API doesn’t train on inputs by default. The distinction between product tiers matters, and your DPA should specify which tier you’re using.
Prompt retention. Even if the provider doesn’t train on your data, how long do they retain prompt and completion logs? For debugging? For abuse detection? For safety monitoring? The retention window matters for regulated industries — a healthcare buyer needs to know that patient data in a prompt isn’t sitting in a provider’s log for 30 days.
Subprocessors. Your AI provider likely uses cloud infrastructure from AWS, GCP, or Azure. They may use content moderation services. They may have monitoring tools that process request metadata. Each of these is a subprocessor, and each subprocessor is a data processing hop that your enterprise buyer’s security team needs to evaluate.
Model outputs. Traditional DPAs focus on input data. AI introduces a new category: outputs generated from input data. If your AI provider generates a response that includes derived insights about a customer, who owns that output? What restrictions apply to it?
The Enterprise Buyer’s DPA Checklist
After reviewing dozens of enterprise vendor questionnaires, here’s the checklist that keeps appearing — sometimes explicitly, sometimes embedded across multiple questions. This is what buyers are actually verifying.
1. DPA existence per provider
What they check: Do you have a signed DPA with every AI provider you use? Not just your primary provider — every one.
Where vendors fail: The main AI provider (OpenAI or Anthropic) has a DPA. The secondary provider that one developer added for a side feature doesn’t. The evaluation account that’s still running in staging doesn’t. The model hosting service for that fine-tuned model doesn’t.
What “good” looks like:
| Provider | DPA Status | Date Signed | Renewal |
|---|---|---|---|
| Anthropic | Signed | Jan 2026 | Annual auto-renewal |
| OpenAI | Signed | Dec 2025 | Annual auto-renewal |
| Google AI | Signed (via Cloud Terms) | Nov 2025 | Tied to GCP agreement |
| Groq | In progress | — | Expected Q1 2026 |
Every provider. With dates. With renewal terms. If a DPA isn’t in place yet, say so and give a timeline. “In progress, expected Q1” is a far better answer than leaving Groq off the list and hoping nobody notices.
2. Training opt-out confirmation
What they check: Written confirmation — in the DPA or in a separate addendum — that the AI provider will not train on your data.
Where vendors fail: Assuming the API terms of service are sufficient. API terms of service can change. A DPA with a specific no-training clause is contractually binding in a way that terms of service aren’t.
What to look for in your DPA:
- Explicit prohibition on using customer data for model training
- Distinction between API and consumer product tiers
- Written confirmation that zero-retention or opt-out is in effect
- Notification requirements if the training policy changes
Strong answer: “Our Anthropic DPA (Section 4.2) explicitly prohibits use of processed data for model training. We use the API tier with zero-retention enabled. Written confirmation of our opt-out status was received on January 15, 2026.”
Weak answer: “Our AI providers don’t train on our data.”
The second answer might be true, but it doesn’t reference a document, a date, or a specific contractual provision. Buyers need auditability.
3. Data retention and deletion
What they check: How long does the AI provider retain the data you send? What’s the deletion mechanism? Is it automatic or do you need to request it?
Provider-specific retention reality:
| Provider | API Data Retention | Deletion Mechanism |
|---|---|---|
| Anthropic | Zero retention (API) | Automatic — no logs retained beyond processing |
| OpenAI | 30 days (abuse monitoring), zero-retention available | API policy; zero-retention via opt-in |
| Google AI | Processing only (Vertex AI) | Configurable per region |
| AWS Bedrock | Processing only (default) | Configurable per account |
| Azure OpenAI | 30 days (abuse monitoring), opt-out available | Microsoft DPA addendum |
| Groq | Check current terms | Varies |
Where vendors fail: Not knowing the distinction between “processing retention” (transient, during the API call) and “log retention” (stored for abuse monitoring, debugging, or safety). Enterprise buyers care about log retention — that’s where data sits for days or weeks.
4. Subprocessor transparency
What they check: Who are the AI provider’s subprocessors? Are they listed? Do you get notified when new subprocessors are added?
What to look for in your DPA:
- Named subprocessor list (or link to a publicly maintained list)
- Notification mechanism for subprocessor changes (email, RSS, page updates)
- Right to object to new subprocessors
- Binding subprocessor agreements that flow down your DPA’s data protection requirements
Most major AI providers maintain public subprocessor lists. Anthropic, OpenAI, and Google publish theirs. If your provider doesn’t publish a subprocessor list, that’s a red flag enterprise buyers will notice.
5. Data residency and transfer mechanisms
What they check: Where is data processed? If it crosses borders, what’s the legal basis for the transfer?
Where vendors fail: Assuming US-based processing is fine for all customers. If your enterprise buyer has EU customers, operations, or data subjects, they need to know that your AI processing happens in a jurisdiction with adequate data protection — or that appropriate transfer mechanisms (Standard Contractual Clauses, adequacy decisions) are in place.
Provider data residency options:
| Provider | Default Region | EU Available? |
|---|---|---|
| Anthropic | US (GCP us-east5) | No (as of March 2026) |
| OpenAI | US | Yes (via Azure OpenAI) |
| Google AI | Configurable | Yes (via Vertex AI region selection) |
| AWS Bedrock | Configurable | Yes (EU regions available) |
| Azure OpenAI | Configurable | Yes (EU regions available) |
| Cohere | US, Canada | Yes (EU available) |
For providers without EU data residency, your DPA should specify the transfer mechanism. Standard Contractual Clauses are the most common. The buyer’s legal team will ask for a copy.
6. Breach notification
What they check: If the AI provider has a data breach, when and how do they notify you? And when do you notify the buyer?
What your DPA should specify:
- Provider-to-you notification timeline (most DPAs specify 72 hours or less)
- You-to-customer notification timeline
- What information is included in the notification
- Cooperation obligations (forensic support, impact assessment)
This matters because GDPR requires 72-hour breach notification to supervisory authorities. If your AI provider takes 30 days to tell you about a breach, your customer can’t meet their regulatory timeline. The DPA should close that gap.
7. Audit rights
What they check: Can the buyer (or the buyer’s auditor) verify that the AI provider is complying with the DPA?
Where vendors fail: The buyer doesn’t need to audit your AI provider directly — they need to know that you can. Your DPA should give you audit rights or access to third-party audit reports (SOC 2, ISO 27001) from the AI provider.
Most enterprise-grade AI providers publish SOC 2 Type II reports. If your provider doesn’t, the buyer will flag it. If your DPA doesn’t reference audit rights or third-party attestation, the buyer’s legal team will push back.
The Five Most Common DPA Gaps
Based on codebase scans and vendor reviews, here are the gaps that show up most:
Gap 1: Missing DPAs for secondary providers. The main provider is covered. The developer who added a Groq integration for internal tooling six months ago? No DPA. This shows up in every codebase scan we run.
Gap 2: Confusing API terms with a DPA. Terms of service are not a Data Processing Agreement. They don’t include GDPR Article 28 clauses, subprocessor lists, or binding deletion obligations. If your “DPA” is actually just the provider’s general terms, you don’t have a DPA.
Gap 3: No training opt-out documentation. The provider probably doesn’t train on API data. But “probably” isn’t auditable. Get it in writing — in the DPA or in a separate written confirmation.
Gap 4: No data residency specification. The DPA says data is processed “in the United States.” But it doesn’t say which state, which data center, or whether the provider might move processing to a different region. For regulated industries, this matters.
Gap 5: Stale DPAs. The DPA was signed when you started using the provider. Since then, the provider added subprocessors, changed retention policies, and updated their infrastructure. Your DPA should specify a review cadence or require notification of material changes.
How to Fix Your DPA Gaps in a Week
Day 1: Inventory. List every AI provider in your codebase. Not the ones you think you use — the ones that are actually imported, called, or referenced in code. A codebase scan is the fastest way to do this.
Day 2: Audit existing DPAs. For each provider, verify: (a) DPA exists, (b) training opt-out is documented, (c) retention terms are specified, (d) subprocessor list is current, (e) data residency is specified.
Day 3-4: Close gaps. For providers without DPAs, request one. Most enterprise-grade providers have a standard DPA you can sign online. For providers where the DPA is missing key clauses, request an addendum.
Day 5: Package. Create a DPA summary table (provider, status, date, key terms) that you can include in questionnaire responses. Store the actual DPA documents in a secure, accessible location so you can produce them when asked.
This is a one-time effort that pays dividends on every future questionnaire response. Update it when you add or remove AI providers.
Key Takeaways
- The DPA question in enterprise questionnaires is a proxy for “do you know what happens to our data when you send it to AI?” — treat it as an evidence opportunity, not a checkbox
- AI DPAs need clauses that traditional DPAs don’t cover: training opt-out, prompt retention, model output ownership, and AI-specific subprocessor chains
- Enterprise buyers verify seven things: DPA existence per provider, training opt-out, data retention, subprocessor transparency, data residency, breach notification timelines, and audit rights
- The five most common gaps: missing DPAs for secondary providers, confusing API terms with a DPA, no documented training opt-out, unspecified data residency, and stale agreements
- You can close DPA gaps in a week — start with a codebase scan to find all providers, audit existing agreements, and request missing DPAs
- Our Trust Pack includes provider-specific DPA status and data residency for every AI provider detected in your codebase — see the full AI Due Diligence Question Bank for the complete DPA question set
Mike Carroll
Founder & Field CTO at SaaSVista
30+ years in IT security and infrastructure. Previously CISSP certified, 2004-2022. Helping B2B SaaS startups prove AI governance readiness to enterprise buyers.
