Reading Between the Lines of an AI Vendor's DPA

What a DPA Actually Is (And Why AI Makes It Different)

A Data Processing Addendum is the contract that sits between you and your AI vendor when personal data crosses from your systems into theirs. Most procurement teams treat it as a checkbox. With AI SaaS, that is a mistake.

For traditional SaaS (CRM, email, file storage), the DPA answers predictable questions: store it, serve it back, delete it when the contract ends. For an AI vendor, the same document must answer questions nobody asked five years ago. Can they train on your prompts? How long do your embeddings live in their vector database? What happens to inference logs your staff generated on a free tier?

In Australia, the framework rests on Australian Privacy Principle 8 (cross-border disclosure) plus section 16C of the Privacy Act 1988. For APRA-regulated entities, expectations go further under CPS 230, which requires formal agreements and robust monitoring for every material service provider. An AI vendor processing customer data almost certainly qualifies.

Clause 1: Model Training. In the DPA, or Just the Marketing Page?

This is the single most important clause, and the one procurement teams most frequently misunderstand.

The major commercial providers all publicly state they do not train on customer data through their API or enterprise products. That commitment lives on help centres and trust portals. The question is whether it also lives in the DPA. If it does not, the marketing page is not a contract. Defaults shift.

OpenAI flipped its consumer training default to opt-out in late 2025. Anthropic flipped its claude.ai default to opt-in for training on 8 October 2025, with up to five-year retention on opted-in inputs. Neither change affected API or enterprise tiers, but both demonstrate that defaults are fluid. The only durable protection is a contractual commitment in the DPA itself.

The second problem is staff using consumer accounts. If your team tests prompts on a free ChatGPT or Claude plan without an enterprise contract, no DPA applies. Those inputs are governed by consumer terms that likely permit training. We see this in almost every vendor audit: enterprise DPAs negotiated to perfection while team members feed sensitive data into a free-tier browser tab.

Clause 2: Data Deletion After Contract End

A standard DPA says the processor deletes or returns all personal data upon contract termination. AI vendors complicate this in three ways.

First, what counts as "personal data"? Prompts and outputs clearly qualify. But what about embeddings, mathematical representations that cannot be read directly but can reconstruct inputs under certain conditions? What about inference logs capturing metadata (timestamps, token counts) without the content itself?

Second, how long does deletion actually take? OpenAI's API default is 30 days for abuse monitoring. Anthropic dropped its retention from 30 days to 7 days in September 2025. Both offer Zero Data Retention through commercial channels, but ZDR is approval-gated. A buyer who never asks never gets it.

Third, the gap between logical and physical deletion. Some vendors declare data "deleted" when it is flagged in a database but not yet purged from backups. The DPA should specify a maximum retention window for backup systems after logical deletion. It rarely does.

Under APP 8, the overseas recipient's deletion practices are the Australian entity's problem. Section 16C makes the disclosing entity accountable. If your AI vendor in California keeps inference logs for 90 days after you think they are gone, you carry the liability.

Clause 3: Subprocessors. Who Else Sees Your Data?

AI products run on increasingly complex stacks. A single API call to a foundation model might route through a cloud provider, the model provider's infrastructure, and a content safety classifier on a third service. Each layer is a subprocessor.

The DPA should list all subprocessors and specify notification timelines. The standard is 30 days notice with an opt-out right. Some vendors offer 10 days. Some notify only after the fact.

A recent example: Anthropic became a Microsoft 365 Copilot subprocessor on 7 January 2026. Microsoft confirmed Anthropic's processing for Copilot is explicitly out of EU Data Boundary scope. Organisations that certified their Copilot deployment as EU-only suddenly had US-based model inference they did not know existed. If the DPA's subprocessor clause does not capture indirect model providers, this category of change goes unnoticed.

For APRA-regulated entities under CPS 230, a vaguely worded subprocessor clause cannot meet the requirement for formal agreements with clear performance and reporting obligations.

Clause 4: Jurisdiction and Data Sovereignty

The jurisdiction clause specifies governing law and dispute venue. For Australian buyers, two additional layers apply.

Under APP 8.1, before disclosing personal information to an overseas recipient, the Australian entity must take reasonable steps to ensure the recipient does not breach the APPs. The OAIC's APP 8 guidance makes clear this is not passive. You cannot sign a DPA governed by Delaware law that contracts away your APP obligations and call that reasonable.

Under APRA's CPS 230, regulated entities must manage risks from service providers, including concentration risk and jurisdictional risk. If all your AI vendors process data in a single US region, APRA expects you to identify and mitigate that concentration.

The practical question: does the DPA specify where data is processed, or just where the vendor is incorporated? A vendor headquartered in Dublin but running inference in Virginia is a US processor for APP 8 purposes. The processing location is what matters, not the incorporation jurisdiction.

Clause 5: Derived Data. The Clause Nobody Reads

Derived data is information the vendor generates from your usage that is not your raw inputs or outputs. It includes usage patterns, token volumes, feature adoption metrics, and aggregated statistics.

Most DPA checklists skip this category because traditional SaaS does not generate meaningful derived data beyond log files. AI vendors do. Inference metadata, safety classifier results, embedding cache patterns, and model performance telemetry all qualify. Some of it may be re-identifiable when combined with other datasets.

The DPA should define what derived data the vendor creates, what it is used for, whether it is shared with third parties, and how long it is retained. If the clause says the vendor can use "anonymised and aggregated data" for product improvement, ask what anonymised means in practice. Differential privacy? K-anonymity? Or just stripping the customer ID field?

For APRA-regulated entities this matters acutely. A vendor who knows which models you query, how frequently, and with what token volumes can infer a great deal about your operations.

How APP 8 and CPS 230 Change the Stakes

Generic DPA checklists are built for GDPR Article 28 compliance: scope, instructions, security, subprocessors, transfers, deletion, audit, breach. All necessary. None sufficient for an Australian entity under APRA's purview or handling personal information under the Privacy Act.

APP 8 creates accountability that follows the data. Section 16C of the Privacy Act makes the Australian entity liable for the overseas recipient's breaches of the APPs. If your AI vendor in another jurisdiction mishandles the personal information you disclosed, the OAIC comes after you. The only defence is having taken reasonable steps. A DPA lacking training prohibitions, defined deletion timelines, and meaningful audit rights is not reasonable.

CPS 230, effective July 2025, raises the bar further. Material service providers require formal agreements with clear descriptions of the service, performance standards, reporting obligations, and exit provisions. An AI vendor DPA covering GDPR Article 28 but not CPS 230 operational risk management expectations leaves a gap APRA will notice.

The intersection is where the real risk lives. APP 8 makes you accountable for the vendor. CPS 230 requires you to manage the vendor. If the DPA does not give you the contractual tools to do both, you are exposed on two regulatory fronts simultaneously.

Red Flags: Ten Things to Check Before You Sign

1. Training commitment only on the website. If the DPA does not contain the no-training commitment, assume training is permitted.
2. Consumer-tier usage not covered. The DPA applies only to the enterprise product. Free-tier usage by your team is governed by different terms.
3. Vague deletion timelines. "Commercially reasonable efforts" is not a timeline. Demand specific windows for logical deletion, backup purging, and derived data.
4. Subprocessor list updated after the fact. Notification after a new subprocessor is added, with no opt-out, means you cannot manage concentration risk.
5. Governing law in a non-equivalent jurisdiction. A DPA governed by Delaware law with no GDPR-equivalent framework weakens your APP 8 reasonable steps argument.
6. No audit rights. If you cannot verify the vendor's claims about training, retention, and subprocessors, you cannot demonstrate APP 8 compliance.
7. Derived data clause silent on AI-specific outputs. If it only covers "logs" without addressing inference metadata, safety classifications, and embeddings, it is outdated.
8. Processing location not specified. A vendor with a Dublin sales office but Virginia inference infrastructure is a US processor, not an EU one.
9. Consumer terms changed recently. If the vendor flipped consumer training defaults in the last 18 months, enterprise terms may follow.
10. No exit assistance provision. If the DPA does not oblige the vendor to assist with data extraction and deletion upon contract end, you have no clean exit path.

What the Checklists Miss

Search "AI vendor DPA checklist" and you will find articles covering Article 28 requirements. That is the table stakes. What they miss is the AI-specific surface area that has emerged since 2023.

They do not ask whether the training prohibition is in the DPA or just the trust centre. They do not address the consumer-enterprise gap. They do not cover derived data beyond log files. They do not mention APP 8 accountability or CPS 230 requirements. They rarely flag subprocessor complexity from multi-cloud AI infrastructure.

An AI vendor DPA is not a traditional SaaS DPA with one extra clause about training. The surface area of what the vendor does with your data is larger, the subprocessor chain is deeper, the retention questions are harder, and the regulatory exposure under Australian law is higher than most procurement teams realise.

If you are an APRA-regulated entity procuring AI SaaS, the DPA is not a procurement checkbox. It is the primary document determining whether your APP 8 reasonable steps defence holds up and whether your CPS 230 obligations are met. Read it like your compliance posture depends on it. It does.

Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.

Related reading

Always-On AI Wearables — The Hidden Recording Devices in Your Workplace

Free vs Paid AI Tools: The Compliance Cost Nobody Talks About

Enterprise-Grade Doesn't Mean Compliant — What ISO 42001 Actually Requires