Data Processing Agreements for AI and Cloud Vendors

The Role of a Data Processing Agreement

A data processing agreement records the vendor’s processing instructions and responsibilities. It can be a separate contract or an addendum incorporated into the main services agreement.

The familiar controller–processor DPA structure comes from European data protection law. Under the General Data Protection Regulation (GDPR), a controller decides why and how personal data is processed. A processor handles that data on the controller’s behalf. Article 28 requires a binding contract or other legal act governing that processing. The European Commission’s controller–processor clauses give a formal example.

Australian organisations use DPAs to put privacy safeguards into enforceable vendor terms. The Privacy Act 1988 uses a different framework, centred on Australian Privacy Principle (APP) entities and their handling of personal information. Importing a GDPR document does not establish compliance with Australian obligations.

For an overseas disclosure, the OAIC’s APP 8 guidance generally expects an enforceable contract requiring the recipient to handle information consistently with the APPs other than APP 1. The reasonable steps needed depend on the circumstances. Contract terms and monitoring can both matter.

An overseas contractor can instead be handling information under your effective control, which can constitute a use rather than a disclosure. That distinction needs a factual assessment. A processor label or an Australian storage region does not settle it.

For example, a law firm proposing to send client correspondence to an AI summarisation service needs more than a confidentiality promise. Its agreement needs to cover the correspondence and generated summaries, including who can access them and what happens when the work ends. Confidentiality and professional obligations also require separate consideration.

Clauses That Matter for AI

An AI vendor’s DPA needs to cover the whole processing activity, including any other providers it uses. Read defined terms and incorporated documents before relying on a promise about “your data”. Personal information can appear in uploaded documents, prompts and generated answers.

Use the following clause checks to turn broad assurances into questions the vendor can answer in writing.

Training restrictions and retention limits answer different questions. A promise not to train models can coexist with storage for security or service delivery. A deletion clause triggered by contract termination says little about retention while an account remains open.

Treat zero data retention as a defined contractual arrangement. Identify the covered service and data categories, any approval requirement and the exceptions. The agreement must support the actual configuration your team will use. A general privacy statement cannot resolve a conflicting retention term.

What Published Vendor Addenda Show

Published addenda demonstrate why clause wording needs close reading. They are examples of contract structures, not interchangeable protections for every account or product.

OpenAI’s DPA addresses documented instructions and confidentiality, alongside breach assistance and audit rights. Its audit provision has conditions, including frequency and customer expense. It also assigns certain configuration decisions, such as retention settings, to the customer. A procurement review therefore needs both the contract and the proposed configuration.

Anthropic’s DPA forms part of its commercial agreement. It specifies breach notification without undue delay and within 48 hours of awareness. Its deletion provision contains exceptions for legal requirements, disputes and combating harmful use. Those exceptions need to be assessed against the information you propose to send.

Microsoft’s DPA covers data protection terms across its products and services, with product-specific provisions. Its general online-service exit terms provide a data-extraction period before deletion, subject to exceptions. An exit provision must therefore be read separately from any promise about day-to-day retention or AI training.

Reviewing a Vendor’s Agreement

Review the agreement against a defined use case before granting permission to send client information. A completed checklist needs a written answer and a contract reference for each material issue.

1. Identify the service and contracting parties. Record the account type and features your team will use. Confirm that the DPA is incorporated into that contract.
2. Describe the proposed information flow. List the information sent, the purpose of processing and the outputs retained. Include connected services and external access.
3. Establish authority to share the information. Assess applicable Privacy Act duties and professional confidentiality obligations. The vendor’s willingness to process a file does not provide that authority.
4. Trace each clause in the table to binding wording. Record the DPA section and any incorporated schedule or policy. Ask the vendor to resolve missing terms or conflicts in writing.
5. Test the terms against a realistic matter. If a client document is uploaded and a summary generated, identify who can access each copy and when deletion occurs. This is a review scenario, not a reason to upload real client data during procurement.
6. Record the decision and operating conditions. Name the person responsible for required settings and change notices. Retain the agreed documents and the reasons for accepting any remaining risk.

A wider AI risk assessment considers whether the proposed service suits the task. The DPA review establishes what the vendor is contractually permitted and required to do with the information.

If a clause is missing, record the specific consequence before seeking an amendment. An undefined deletion period, for example, leaves you unable to establish when the vendor’s copies disappear. Obtain a binding answer or narrow the permitted use so it excludes information that requires that protection.