Reviewing a Vendor DPA When Buying AI Services: Ten Clauses, Five Common Refusals and the Order of Concessions

When buying AI services, the DPA sits at the back of the contract pack, is the shortest document in it, and is the easiest to sign as an annex. The supplier’s template is usually three or four pages, neatly worded, cross-referenced, and apparently complete.

The difficulty is that the template is written around the supplier’s exposure, not yours. You are the controller: data-subject requests come to you, regulator enquiries come to you, and the duty to notify a breach comes to you. The supplier bears only the part it has agreed to bear. The review exists to establish whether anyone is carrying the rest.

The previous article approached the DPA from the drafting side. This one takes the buyer’s position and proceeds in order: characterise, then check clause by clause, then negotiate.

1. Three questions before signing

First, what is your role? When buying AI services, the enterprise is usually the controller and the supplier the processor. But where the supplier uses the data to improve its own model, for cross-client analytics or for its own marketing, it is an independent controller within that scope. A DPA cannot govern that; only disclosure in the privacy policy and separate consent can. Characterise the role wrongly and every clause that follows misses its target.

Second, what is being processed? Employee accounts and ticket records sit in a different order of risk from customer lists, conversation content and biometric data. The categories in the contract should follow the actual fields, not a catch-all such as “business data”.

Third, is anything cross-border? If the supplier’s model nodes, operations team or backup centres are outside the mainland, there is a cross-border transfer. A domestic product calling an overseas API is the most common case, and many contracts do not mention it at all.

2. Ten clauses to check

1. Scope and written instructions. Article 21 of the Personal Information Protection Law requires the purpose, period, method, categories, safeguards and mutual rights and obligations to be agreed. The common formula — “the supplier processes data solely to perform the services” — looks complete but carries no schedule and no prohibition. The adequate version lists fields and uses in an annex and states that processing for any other purpose is excluded.

2. Use for model training. This is the sharpest difference between buying AI and buying ordinary SaaS. Most suppliers’ general terms permit use of customer data “to improve the services”, and signing that sentence displaces the characterisation as processing on instruction. The clause should prohibit use of customer data for training, fine-tuning, evaluation or cross-client analytics; where there is a genuine need, the scope, de-identification and opt-out should be set out separately and consent obtained.

3. Sub-processors. Article 21 requires consent for onward engagement. Templates usually say the supplier may use affiliates and subcontractors, granting consent once and for all. The points to check are whether there is a list, whether it is kept current, whether new sub-processors trigger prior notice and a right to object, and whether equivalent obligations flow down.

4. Cross-border transfer. Four questions need answers: who transfers to whom, what is transferred, which mechanism applies, and what obligations the recipient bears. “The parties shall comply with applicable law” is not a clause.

5. Security measures. The standard should be verifiable: encryption, access control, log retention, personnel confidentiality, penetration-testing frequency, certifications held. “Reasonable technical and organisational measures” is a disclaimer; it gives you nothing to point to after an incident.

6. Assistance with rights requests. Access, copy, correction, deletion and withdrawal of consent are ultimately executed inside the supplier’s system. The contract should fix the response time, the manner of assistance and who bears the cost. Three business days is a common market position.

7. Deletion and return. Termination, withdrawal of the instruction and user account closure are three separate triggers, and each must be capable of deletion. The scope must reach training copies, logs, caches and backups; backups usually roll off on a fixed cycle, so state the cycle and require a certificate of deletion.

8. Security incident notification. Templates often say the supplier will notify “promptly upon discovery”, with no deadline, no content requirement and no allocation of cost. An adequate clause sets an initial notification deadline, a deadline for the full report, what the report must contain, who bears the cost of notifying users and regulators, and a duty to cooperate with the investigation.

9. Audit rights. At least two routes should survive: remote review of certifications and processing records, and an on-site review triggered by an incident. A supplier that refuses audit altogether on the ground that other clients’ data is involved usually cannot cooperate in practice.

10. Liability and indemnity. Supplier templates commonly cap liability at 100% of fees or the last twelve months’ fees, which is rarely enough for a data incident. Two categories should be separated: losses caused by the supplier’s breach of the DPA, which should sit outside the fee cap or under a higher cap, and external liability arising from your instructions, which you bear and indemnify the supplier for.

3. The five amendments suppliers most often refuse

Of these five, training use and breach notification cannot be conceded. The first determines how the relationship is characterised; the second determines whether you can perform your statutory notification duty.

4. The order of concessions

Negotiation needs sequence rather than even pressure.

The floor can be put in one sentence: if after signing the DPA you still cannot tell a regulator who processes the data, for what, where it is held and whether it has been deleted, the contract has not done its job.

5. Alternatives when the terms will not move

Failure to agree does not leave acceptance as the only option. Four routes exist, at increasing cost.

First, narrow the scope. Transfer no personal information, or only de-identified data. Fewer fields means fewer points of dispute.

Second, change the processing location. On-premise or private deployment keeps data inside the enterprise environment, and the transfer and sub-processor clauses fall away.

Third, change supplier. Treat DPA terms as a selection criterion rather than a signing obstacle, and require a response at the tender stage.

Fourth, supplement notice and separate consent. Where independent processing or cross-border provision genuinely arises, complete the privacy policy and consent mechanics, and accept the obligations that follow from the recharacterisation.

The first three are contract-level adjustments; the fourth is a compliance remedy. Neither substitutes for the other.

6. Pre-signature checklist

Item 12 is the one most often skipped. However well the DPA is drafted, if the third-party categories in the privacy policy do not match the sub-processor list, a cross-check will still require explanation. The three documents describe one data flow, and the wording has to agree.

Related reading: data processing agreements in AI, privacy policies for AI products, personal information protection impact assessment, the core contract set for AI companies, and the commercial contracts and data compliance service pages.

Last updated: 13 August 2026.