AI Vendor DPA Checklist: 7 Clauses Governance Teams Miss
Standard SaaS DPA checklists miss critical AI-specific clauses. This practical framework covers 7 clauses every governance team must verify: model training commitments, data deletion timelines, subprocessor notification, jurisdiction/data sovereignty, derived data and inference metadata, the Australian regulatory layer (APP 8, s16C, CPS 230), and the consumer-to-enterprise DPA gap. Each clause includes regulatory hooks, red flags, and practical verification steps.
Why Your Existing DPA Checklist Fails for AI Vendors
If your organisation has been buying SaaS for years, you probably have a standard DPA review checklist covering GDPR Article 28. These are table stakes in 2026. The problem is that AI vendors introduce data processing categories standard DPAs were never designed to address: model training, inference metadata, subprocessor chains that include other foundation model providers, and derived data that doesn't fit neatly into "log files" or "usage data." Australia's regulatory framework adds obligations that GDPR-only checklists simply don't account for.
This checklist walks through seven clauses that separate a real AI vendor DPA review from a box-ticking exercise. Each includes what to look for, the red flags, and the regulatory obligation it maps to.
Clause 1: Model Training Commitment
What to look for: A binding contractual commitment that the vendor will not use your data (prompts, outputs, uploaded files, embeddings) to train, fine-tune, or improve their models. This must live in the DPA itself, not in a trust centre FAQ.
Why it matters: Vendor training policies change without notice. OpenAI flipped consumer training from opt-out by default to opt-out-available in late 2025. Anthropic flipped claude.ai training to opt-in in October 2025. If your training protection lives in a help centre article rather than the DPA, it can disappear in a quarterly update with no notice.
Regulatory hook: Under APP 11.1, your organisation must take reasonable steps to protect personal information from unauthorised use. Under GDPR Article 28, the processor processes only on documented instructions. Training on your data without explicit instruction breaches both.
Red flags: "We may use de-identified data to improve our services" or silence on training in the DPA with a reference to "see our Trust Centre." If the word "training" doesn't appear in the DPA, assume the vendor reserves the right.
Clause 2: Data Deletion Timelines
What to look for: Explicit timelines for both logical deletion (data no longer queryable) and physical deletion (data removed from backup media). Check whether zero data retention (ZDR) is available and whether it requires an opt-in request rather than being the default.
Why it matters: AI inference generates secondary data: safety classifier results, moderation outputs, embedding cache vectors, which live outside the primary data store. A DPA that only addresses "Customer Data" may not cover these categories.
Both OpenAI and Anthropic offer ZDR for API customers, but it is opt-in, not default. Anthropic reduced API retention from 30 days to 7 days in September 2025, a positive move, but still not zero unless you request it.
Regulatory hook: APP 11.2 requires reasonable steps to destroy or de-identify personal information when no longer needed. Under APRA CPS 230, material service providers must have defined exit provisions. If you cannot verify deletion, the exit provision is hollow.
Red flags: "Commercially reasonable efforts" to delete data. Deletion timelines that only start from contract termination. Silence on backup purge windows.
Clause 3: Subprocessor Notification and Chains
What to look for: A list of current subprocessors, a commitment to notify you of changes with a 30-day opt-out window, and critically, whether the vendor's own AI models are provided by a third party that qualifies as a subprocessor.
Why it matters: The AI supply chain is deeper than most procurement teams realise. As of January 2026, Anthropic became a subprocessor for Microsoft 365 Copilot, meaning your data may be processed by Anthropic's infrastructure even though you never signed with them. A vendor that "uses GPT-4" sends your data to OpenAI. A vendor supporting "multiple models" may route your data to different providers based on model selection, and each switch creates a new subprocessing relationship.
Regulatory hook: APP 8.1 requires reasonable steps to ensure overseas recipients do not breach the APPs. Under s16C of the Privacy Act 1988, your organisation is accountable for overseas recipients' acts and practices. Every subprocessor in the chain is an overseas recipient you are accountable for.
Red flags: A subprocessor page listing only infrastructure providers (AWS, Azure) with no model providers. A DPA allowing subprocessors to be added without notice. "Industry-standard AI models" without naming which ones or where they run.
Clause 4: Jurisdiction and Data Sovereignty
What to look for: Specific processing locations, not just the vendor's country of incorporation. An Irish subsidiary with inference running in Virginia means your data is processed in the United States, not the EU. The only location that matters is where computation happens.
Why it matters: Many AI vendors have complex corporate structures designed for tax optimisation, not privacy compliance. Incorporation jurisdiction is not processing location, and APP 8 cares about the latter.
Regulatory hook: APP 8.1 applies based on where the recipient is located and where processing occurs. The OAIC's APP 8 Guidelines (updated October 2025, v1.3) confirm the assessment is about the overseas recipient, not the contractual counterparty.
Red flags: DPA lists headquarters city but not processing locations. "Data may be processed in the United States, EU, or other locations as needed", this is not a commitment, it's a disclaimer.
Clause 5: Derived Data and Inference Metadata
What to look for: A specific definition of "derived data" capturing inference metadata, safety classifier outputs, embedding cache patterns, and model telemetry. If the DPA only addresses "log files" or "usage data," it probably doesn't cover these categories.
Why it matters: Every inference call generates more than just your prompt and the response. Modern platforms log safety classifications, cache embedding vectors, and collect diagnostic telemetry about token usage and latency. This data is not "Customer Data" in the traditional sense. It is generated by the service about your usage. If the DPA doesn't address it, the vendor may treat it as operational data they own, retain indefinitely, and use for model improvement.
Regulatory hook: Under GDPR Article 28, the processor must not process personal data except on documented instructions. If inference metadata contains personal data (and it often does: safety classifiers analyse your content), processing it outside documented instructions is a breach. ISO 42001 Annex A Control A.7.4 requires records of data used in AI system operation, which includes inference metadata.
Red flags: "We collect diagnostic and usage data to improve our services" in the privacy policy but silence on derived data in the DPA. No definition of what happens to safety classifier outputs. Caching policies retaining embedding vectors without deletion rules.
Clause 6: The Australian Regulatory Layer
What to look for: DPA terms addressing APP 8 cross-border obligations, APRA CPS 230 requirements for material service providers, and the accountability chain under s16C of the Privacy Act. These are absent from virtually every standard AI vendor DPA, written for GDPR and occasionally CCPA compliance.
Why it matters: Australian organisations cannot rely on a GDPR-compliant DPA to satisfy their APPs. The Privacy Act imposes direct accountability on the Australian entity for overseas recipients' acts (s16C). The GDPR's controller-processor model lets a controller point to contractual provisions. Australia's model is different: the Australian entity is accountable regardless of what the contract says.
For APRA-regulated entities, CPS 230 requires formal agreements covering service description, performance standards, reporting obligations, and exit provisions. A standard US-law DPA won't address these unless you add them through a schedule.
Regulatory hook: APP 8.1, s16C Privacy Act 1988, APRA CPS 230 (effective July 2025, revised April 2026). The OAIC APP 11 Guidelines require reasonable steps to protect personal information, and this extends to what your vendor does with the data.
Red flags: DPA governed by US or EU law with no acknowledgment of Australian privacy obligations. No mechanism to flow APP obligations to subprocessors. Silence on the Privacy Act entirely.
Clause 7: The Consumer-to-Enterprise Gap
What to look for: Whether the DPA differentiates between consumer/individual accounts and enterprise/team accounts. Free-tier AI tools typically offer no DPA, no audit rights, and no data residency guarantees.
Why it matters: This is the most common failure mode in AI procurement audits. A team signs up with a free account and feeds it real customer data. The free tier has no DPA, no training opt-out, no deletion commitment. By the time procurement gets involved, six months of customer data is already in the vendor's training pipeline with no contractual protection.
Consumer-grade ChatGPT, Claude Free, and Gemini personal accounts all train on your data by default. Enterprise plans: ChatGPT Enterprise, Claude Enterprise, Gemini for Workspace, have contractual training prohibitions, DPAs, and audit rights. The compliance cost of a free AI tool is not zero dollars. It's the cost of explaining to the OAIC why customer data was used to train a model without consent.
For more on this gap, see Free vs Paid AI Tools: The Compliance Cost Nobody Talks About.
Red flags: A "Pro" tier costing $20/month without a DPA. "We don't train on your data" in marketing copy with no contractual backing. A privacy policy where training practices "may vary by plan" without specifying which plan gets which protection.
How to Use This Checklist in Practice
This is a framework for a structured vendor review your legal, procurement, and governance teams can run before signing any AI vendor agreement:
- Request the DPA before the demo. If a vendor cannot produce a DPA on request, that's your first red flag.
- Map the subprocessor chain. Ask: "Which foundation model providers process our data, and where does inference run?" If the vendor resists, assume the worst.
- Score each clause. Green (addressed in DPA), yellow (partially addressed in trust centre docs), or red (not addressed). More than two reds means the vendor is not enterprise-ready.
- Add Australian provisions in a schedule. Supplement a US-law DPA with an Australian-law schedule covering APP 8, s16C, and CPS 230 exit provisions. If the vendor refuses, escalate to your governance committee.
- Re-verify annually. Training policies, subprocessor lists, and processing locations change. Annual re-verification aligns with ISO 42001 Clause 9 (performance evaluation).
For more on building a complete AI procurement review, see our Internal AI Audit Checklist Before Procurement and what ISO 42001 actually requires from vendors.
The Bottom Line
Standard DPA checklists were built for SaaS vendors storing data in a database. AI vendors store your data, run inference on it, generate new data about that inference, and may use everything they learn to train the next model. The contractual obligations need to reflect that gulf in complexity.
If your DPA review process hasn't been updated since 2023, you are reviewing AI vendor contracts with a checklist designed for Salesforce and Workday. That is not diligence. That is paperwork.
When in doubt, talk to us before signing. A 30-minute contract review costs less than a two-year regulatory headache.
Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.
Frequently asked questions
What is an AI vendor DPA and why is it different from a standard SaaS DPA?
A standard SaaS DPA covers data storage, processing, and deletion under GDPR Article 28. An AI vendor DPA must additionally address model training on your data, inference metadata generation, subprocessor chains that include foundation model providers, and data categories that traditional DPAs don't define, such as embeddings and safety classifier outputs.
Does the free version of ChatGPT or Claude have a DPA?
No. Consumer and free-tier AI tools do not offer DPAs. ChatGPT Free, Claude Free, and Gemini personal accounts train on your data by default and provide no contractual data processing commitments, no audit rights, and no data residency guarantees. Enterprise plans (ChatGPT Enterprise, Claude Enterprise, Gemini for Workspace) include DPAs and contractual training prohibitions.
How does APP 8 affect cross-border AI vendor contracts?
APP 8.1 requires Australian organisations to take reasonable steps to ensure overseas recipients of personal information do not breach the Australian Privacy Principles. Under s16C of the Privacy Act 1988, the Australian entity remains directly accountable for the overseas recipient's acts and practices. A GDPR-compliant DPA from a US AI vendor does not automatically satisfy APP 8 obligations.
What is zero data retention (ZDR) and how do I enable it?
Zero data retention means the AI vendor does not store your prompts or outputs after inference completes. Both OpenAI and Anthropic offer ZDR for API customers, but it is opt-in, not default. You must actively request it through the API dashboard or your account manager. Without ZDR, API data is typically retained for 7 to 30 days.
What is derived data in AI systems and why does it matter for DPAs?
Derived data includes inference metadata, safety classifier outputs, embedding cache patterns, and model telemetry generated during API calls. This data often contains personal information but is rarely covered by standard DPA definitions of 'Customer Data.' If the DPA does not explicitly address derived data, the vendor may treat it as operational data they own and can use for any purpose, including model training.
How often should we re-verify an AI vendor's DPA?
Annually at minimum, aligned with ISO 42001 Clause 9 (performance evaluation). Vendor training policies, subprocessor lists, processing locations, and data retention practices change without notice. A DPA signed in January may not reflect the vendor's actual practices by December. Annual re-verification should be part of your AI vendor management program.
