Reading Between the Lines of an AI Vendor's DPA
Standard DPA checklists were written for SaaS tools that store data, not AI systems that learn from it. Five clauses separate an AI-ready DPA from a generic one: model training commitments, data deletion timelines that account for model retraining windows, subprocessor chains that capture indirect model providers, jurisdiction claims that distinguish incorporation from inference location, and derived data coverage beyond standard log files. Australian organisations face an additional layer under APP 8, s16C of the Privacy Act, and APRA CPS 230 that GDPR-only templates miss entirely.
The DPA Checklist That Was Not Built for AI
Data Processing Addendums predate the current generation of AI tools by about a decade. The standard DPA checklist, the one your legal team runs through before signing off on a new vendor, was designed for SaaS products that stored data in a database and retrieved it on request. It was not designed for systems that train on data, generate inferences from it, and route processing through chains of model providers whose names do not appear anywhere in the contract.
When you run a standard DPA checklist against an AI vendor's paperwork, most of the boxes get ticked. The vendor has a DPA. It references GDPR Article 28. It lists subprocessors. It includes a data deletion clause. But ticked boxes do not mean the document actually covers what an AI deployment needs it to cover.
Here are the five clauses that separate an AI-ready DPA from a generic one, and the Australian regulatory layer that GDPR-only templates miss entirely.
Clause 1: The Model Training Commitment
This is the clause most people look for first, and the one most likely to be missing from the DPA itself. Many AI vendors state their training policy in a trust centre FAQ, a blog post, or a help centre article. Anthropic, for example, announced in October 2025 that claude.ai consumer conversations would no longer be used for training unless the user opted in. OpenAI flipped consumer training to opt-out in late 2025. Both are documented. Neither is in the DPA by default.
A trust centre statement is not a contractual commitment. It can change. The DPA is the durable document. If your vendor's DPA does not include an explicit clause stating that customer data will not be used for foundation model training, you are relying on marketing. The ISO 42001 framework, specifically Annex A controls A.7.4 and A.7.5, expects organisations to document data provenance and establish formal agreements for AI system data, not informal assurances.
The practical test: search the DPA for the word "training." If it is not there, or if it appears only in a preamble about the vendor's commitment to privacy without an operative clause, the document fails this check.
Clause 2: Data Deletion, Logical vs Physical, and the Retraining Window Problem
Nearly every DPA includes a data deletion clause. Most of them mean logical deletion: the data is marked as deleted in the application layer but may persist in backups, logs, or analytics pipelines for weeks or months. Physical deletion, scrubbing data from all storage tiers including backups, is rarer and usually requires a specific request.
AI systems add a complication that standard SaaS products do not have: the retraining window. If a model was trained on your data (even with permission), and you later invoke your deletion rights, a logically deleted record does not un-train the model weights. Anthropic reduced API data retention from 30 days to 7 days in September 2025 and offers Zero Data Retention (ZDR) for qualifying enterprise accounts, but ZDR is approval-gated, not on by default. OpenAI offers a similar mechanism through its API platform, not its consumer products.
If your organisation operates under Australian Privacy Principle 11 (security of personal information), you need to know not just that data will be deleted, but how, from where, and on what timeline. A DPA that says "upon termination, data will be deleted within 30 days" without specifying logical versus physical deletion, backup purge windows, or model retraining implications is incomplete.
Clause 3: Subprocessor Chains and the Indirect Model Provider Problem
The subprocessor list in a standard AI vendor's DPA typically shows cloud infrastructure providers (AWS, GCP, Azure) and maybe a few service-specific vendors. What it usually does not show is the foundation model provider behind the vendor's own product.
This matters because the subprocessor landscape in AI is shifting fast. In January 2026, Microsoft disclosed that Anthropic had become a subprocessor for Microsoft 365 Copilot. Organisations using Copilot were indirectly routing data through Anthropic's infrastructure, potentially under terms they had not reviewed. If your DPA's subprocessor notification clause only covers direct additions to a public list, it will not catch indirect model providers that enter the chain through your vendor's own vendor relationships.
A robust AI DPA should require notification when a new model provider joins the processing chain, regardless of whether the contract is between the vendor and the provider or between the vendor's provider and a third party. APRA's CPS 230 standard, effective since July 2025, explicitly requires material service provider agreements to address the full service delivery chain, not just the first contractual link.
Clause 4: Jurisdiction, Incorporation, and Where Inference Actually Happens
This is the clause that trips up Australian organisations most frequently. You see "Incorporated in Ireland" or "Australian entity: [Pty Ltd]" in the DPA and assume your data stays within a friendly jurisdiction. But the incorporation jurisdiction of the vendor's local entity has nothing to do with where the inference servers run.
An AI vendor can have a Dublin headquarters, an Australian sales office, and Virginia-based GPU clusters that run every inference request. The DPA needs to specify processing locations, not corporate registration addresses. Under APP 8.1, before an Australian organisation discloses personal information to an overseas recipient, it must take reasonable steps to ensure the recipient does not breach the APPs. Section 16C of the Privacy Act 1988 goes further: the Australian entity is accountable for the overseas recipient's acts and practices as if they were its own.
If your vendor's DPA says "data may be processed in the United States" without specifying which states, which data centres, or what safeguards apply, you have not taken reasonable steps under APP 8. The EU AI Act adds another layer here. Article 59 requires high-risk AI system providers to document processing locations and data flows in technical documentation. A DPA that treats jurisdiction as an afterthought is a red flag.
Clause 5: Derived Data, the Category Standard DPAs Do Not Name
Standard DPA clauses cover "log files" and "usage data." In a traditional SaaS product, that means access logs, error logs, and maybe analytics events. In an AI system, the equivalent category is vastly broader: inference metadata (which model version processed which request), safety classifier results (what the content filter flagged and why), embedding cache patterns (how your queries cluster in vector space), model performance telemetry (latency, token counts, failure rates), and prompt-completion pairs that may be retained for abuse monitoring.
Most of this data is generated by the AI system as a byproduct of normal operation. None of it fits neatly into the "log files" definition that standard DPAs were written around. If your DPA does not explicitly define what derived data the vendor collects, how long it is retained, and whether it can be used to improve services (which may include training future safety classifiers, not just foundation models), you are signing up for processing you cannot audit.
ISO 42001 Clause 8.1 (operational planning and control) expects organisations to document the data flows of their AI systems. If your vendor's DPA cannot tell you what derived data exists, you cannot document it. And if you cannot document it, you cannot assess the privacy impact under APP 1.2 or the risk under CPS 230.
The Australian Layer Most Templates Ignore
Most AI vendor DPAs are built on GDPR templates. GDPR Article 28 provides a solid structural starting point. It specifies what a processor agreement must contain, mandates subprocessor consent mechanisms, and establishes data deletion obligations. It is a good foundation. But it is not sufficient for Australian organisations.
Three Australian requirements sit on top of the GDPR baseline:
APP 8.1 (Cross-border disclosure). Before personal information goes overseas, the Australian entity must take "reasonable steps" to ensure the recipient handles it consistently with the APPs. Checking that the vendor has a DPA is a step. Verifying that the DPA actually addresses Australian-specific requirements is a better one. The OAIC updated its APP 8 Guidelines to version 1.3 in October 2025, reinforcing the reasonable steps requirement.
Section 16C (Accountability for overseas acts). If the overseas AI vendor breaches an APP while handling your data, the Privacy Act treats the Australian organisation as having done the same thing. This is not a theoretical risk. If your vendor's inference servers in Virginia retain prompt data longer than their DPA says they will, and that data includes personal information, the Australian company carries the liability.
APRA CPS 230 (Operational risk management). Effective since July 2025 and revised in April 2026, this standard requires APRA-regulated entities to have formal agreements with material service providers covering service descriptions, performance standards, reporting obligations, and exit provisions. An AI vendor processing customer data or supporting critical business processes qualifies. The standard demands more than a signed DPA. It wants a contract that actually describes what the service does and how it is governed.
A Practical Red-Flags Checklist
Before signing an AI vendor's DPA, run through these five questions. If the answer to any is no, or if the DPA is silent on the point, you have found a gap worth addressing before procurement proceeds:
- Training: Does the DPA contain an operative clause, not just a preamble or trust centre reference, stating whether customer data is used for model training?
- Deletion: Does the deletion clause distinguish between logical and physical deletion, specify backup purge windows, and address whether data in model training sets is covered?
- Subprocessors: Does the subprocessor notification mechanism capture indirect model providers, not just the vendor's direct subcontractors?
- Jurisdiction: Does the DPA specify where inference processing occurs, not just where the vendor is incorporated?
- Derived data: Does the DPA define and constrain derived data, including inference metadata, safety classifier outputs, and telemetry, beyond standard log files?
These five questions take about ten minutes to check against an actual DPA document. They will surface more genuine compliance exposure than a forty-question vendor security questionnaire.
What This Means for Australian Organisations
The Australian regulatory environment is moving in the same direction as the EU's, but the accountability mechanism is different. The EU AI Act creates direct obligations on providers. Australia's Privacy Act, and particularly section 16C, places the burden on the Australian adopter, not the overseas vendor. You cannot outsource compliance by pointing at the vendor's DPA. If the DPA does not cover the specific risks that AI systems introduce, the gap belongs to you.
The direction of travel is clear: organisations adopting AI tools are expected to understand what happens to their data, where it goes, and what the vendor does with the byproducts, and to have that understanding reflected in contracts, not marketing pages.
None of this requires rejecting standard vendor DPAs outright. It requires reading them against the right checklist, one that was designed for AI systems, not database-as-a-service products from 2016.
Written by David Swan, reviewed and fact-checked against primary regulatory sources including the OAIC APP 8 Guidelines (v1.3, October 2025), APRA CPS 230 (revised April 2026), the Privacy Act 1988 (Cth), GDPR Article 28, ISO 42001, and vendor DPA documentation from Anthropic and OpenAI. AI-assisted but human-directed.
Frequently asked questions
What makes an AI vendor's DPA different from a regular SaaS DPA?
AI vendors process data differently. They may use customer data for model training, retain inference metadata, and run processing through indirect model provider subprocessors. Standard DPA checklists cover data storage and access controls, but miss model training commitments, derived data retention, and subprocessor chains that include the foundation model provider behind your vendor's API wrapper.
How does APP 8 affect Australian companies using overseas AI vendors?
APP 8.1 requires Australian entities to take reasonable steps to ensure overseas recipients comply with the APPs. Section 16C of the Privacy Act makes the Australian entity accountable for the overseas recipient's acts. If a US-based AI vendor processes customer data on Virginia servers under a DPA that does not address the APPs, the Australian company carries the compliance risk.
Should we accept an AI vendor's standard DPA or negotiate?
Standard AI vendor DPAs are a starting point, not a final position. At minimum, verify the five AI-specific clauses: model training commitment (not just a trust centre statement), data deletion timelines that account for backup and retraining windows, subprocessor notification that captures indirect providers, processing jurisdiction distinct from incorporation, and derived data coverage. Enterprise plans often come with stronger DPA terms than consumer or free tiers.
What is derived data and why does it matter in an AI DPA?
Derived data includes inference metadata, safety classifier outputs, embedding cache patterns, model performance telemetry, and usage analytics. Standard DPA log-file clauses were designed for access logs and error files. They do not capture the telemetry that AI systems generate by design. A comprehensive AI DPA should explicitly define and constrain derived data processing.
Does APRA CPS 230 apply to AI vendor relationships?
Yes. CPS 230 requires material service providers to have formal agreements with specified content: service description, performance standards, reporting obligations, and exit provisions. An AI vendor handling customer data or supporting a critical business process qualifies as a material service provider. The standard took effect in July 2025 and was revised in April 2026.
