How to Write a Data Processing Addendum for AI Tools

This is the clause most templates get wrong, because they describe data categories in the language of a file store. For an AI tool, be explicit. A working list:

Two vendor commitments belong in this clause, in plain words. First, a no-training term with no ambiguity: your content is processed to deliver the service and never fed into training, fine-tuning, evaluation or benchmarking. Any vendor can say it, which is why reviewers now look at the parts you can check, like named subprocessors, retention quoted in days, and a closed anonymized-data carve-out (Parseur). Second, a purpose limitation: process the data only to provide the service, with any other use requiring written instruction from you.

The anonymized-data carve-out is the one to watch. A clause that lets the vendor create "aggregated and de-identified data" for product improvement can convert your data into something outside the deletion promise, which is what some vendor templates do (Day AI DPA). Either delete the carve-out or add a standard: de-identification must follow a named method, must not permit re-identification by the vendor or its subprocessors, and the vendor must not sell or share it.

On training, get the vendor to state its default in the DPA itself rather than referencing a marketing page. OpenAI's enterprise terms say it does not train on business data by default and that customers own inputs and outputs where allowed by law, and it offers a DPA for Business, Enterprise and API customers (OpenAI enterprise privacy). That is a good model for the language. It is not a substitute for reading your own vendor's DPA.

One more test worth running: ask what happens with retention after opt-out. Opting out of training does not mean zero retention. Standard opt-out prevents training use but does not eliminate safety monitoring logs, which persist for up to 30 days, and zero data retention is a separate configuration from a no-training promise (Secure Privacy). So write both numbers into the DPA: a no-training commitment and a retention period in days, per category, with a separate number for abuse monitoring logs and backups.

An AI vendor usually has more subprocessors than a normal SaaS vendor: a cloud host, a model provider, a speech-to-text service, a vector database, a content moderation API. Each one expands the blast radius without appearing on your vendor's invoice.

The DPA should do three things. It should attach a named subprocessor list as a schedule, with the processing each one performs and its location. It should require prior written notice, not less than 30 days, before any new subprocessor is added, with a right to object on reasonable data protection grounds. And it should require flow-down: every subprocessor is bound by terms no less protective than the DPA.

This is a live gap, not a theoretical one. Research on business software providers found that 63.6 percent of vendors advertising AI capabilities do not disclose a third-party AI subprocessor anywhere in their legal documentation (Parseur, citing DataGrail). If your vendor is in that group, the list is the first redline you send.

Check how the vendor defines affiliates, too. GitHub's Copilot FAQ separates affiliates (its corporate family) from service providers and subprocessors, and says subprocessors may only process data on GitHub's behalf and at its direction (GitHub community). That distinction is worth copying: an affiliate should not be able to use your data for its own products just because it shares a parent company.

A practical objection procedure: you have 30 days to object in writing, the parties discuss in good faith for 15 days, and if no resolution, you may terminate the affected service and receive a pro rata refund. Without that last step, an objection right is decorative.

GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of a breach, and requires the processor to notify the controller without undue delay after becoming aware (GDPR Article 33). "Without undue delay" is the processor's obligation, and it is a poor basis for planning. You cannot start your 72-hour clock if you learn about the incident on day three.

So put hours in the contract. A workable structure:

For higher-risk data such as health or financial records, tighten the initial notice to 12 hours. Some practitioners in healthcare recommend breach terms with deadlines of 24 to 72 hours as a floor, alongside a signed business associate agreement, a written no-training term, a current SOC 2 Type II report and a subprocessor list (Censinet).

Two extras are worth the ink. First, name the contacts: a security contact, a privacy contact and a legal escalation contact with email and phone, plus a 24/7 line. Second, allocate cost. State that the vendor bears reasonable costs of forensic investigation, notification and credit monitoring where the incident arises from its acts or omissions, subject to a cap you negotiate separately from the general liability cap. A vendor's standard DPA will often promise notice and assistance but stay silent on who pays. OpenAI's DPA, for example, commits to notifying the customer without undue delay after becoming aware of a personal data breach and to providing reasonable assistance, without a fixed hour count (OpenAI DPA). That is normal and it is exactly what you are redlining.

Most vendor templates grant an audit right on paper and then require 60 days' notice, restrict it to once per year, limit it to business hours at the vendor's office, and require you to pay the vendor's costs. That is not an audit right. It is a permission slip.

Redraft it around evidence you will actually use. Google's Cloud DPA takes this approach, defining which services are in scope for a certification or report and tying compliance obligations to that published list (Google Cloud DPA). OpenAI's DPA similarly limits the compliance evidence obligation to a reasonable written request, no more than once per year, and to the extent required by data protection law (OpenAI DPA). Use those structures as the benchmark.

Your clause should accept, as full satisfaction of the audit right: a current SOC 2 Type II report, its bridge letter covering any gap period, a summary of the most recent penetration test with findings and remediation status, and responses to a standardized security questionnaire. Ask for the report scope, not just the badge. A SOC 2 report with a narrow system description covering only the marketing site tells you nothing about the inference pipeline.

Then keep a real audit as a backstop for cause: after a confirmed breach, after two missed report deliveries, or on a regulator's written request. That triggers a shorter notice period (10 business days), allows a third-party auditor bound by confidentiality, and puts the cost on the vendor when the audit finds a material control failure.

The evidence map is the artifact that makes this work in a risk committee. Build it once, reuse it for every vendor.

That table mirrors the evidence requests that procurement and security teams now standardize on, including SOC 2 Type II or ISO 27001, pen test summaries and remediation processes, breach notification timelines with hours and days in the contract, and named subprocessors with data location (CTO Input).

Deletion is the clause where AI tools diverge most from SaaS. Deleting a document does not necessarily delete the embeddings derived from it, the fine-tuned adapter trained on it, the cached prompt, or the copy in an evaluation set. Write the clause to cover each.

The clause should require, within 30 days of termination or written request: return of customer data in a structured, commonly used format, deletion of all customer data including prompts, outputs, embeddings, indexes, caches and backups, and written certification of deletion signed by an authorized officer. Backups can carry a longer outer limit, commonly 90 days, provided they are isolated and not restored except for disaster recovery.

The certificate should state more than "data deleted." Ask for: the categories deleted, the systems and environments covered (production, staging, disaster recovery, analytics warehouse), the date of deletion, the method (cryptographic erasure counts), confirmation that subprocessors were instructed and confirmed, and any residual copies with the legal basis for keeping them.

Two exceptions to name in advance so nobody argues later. First, legally required retention, such as records you must keep for tax or regulatory reasons, with the legal basis and retention period stated. Second, safety and abuse-monitoring logs, which commonly persist for a defined window even under no-training terms. If the vendor's standard position is a 30-day abuse-monitoring retention window that survives opt-out, get that number written down rather than discovering it in an incident review (Secure Privacy).

A worked example shows why the certificate matters. Say you run a support tool that ingests 40,000 tickets a quarter, each with an average of two attachments and a chat transcript. On termination you need four categories deleted across at least three environments: ticket text, attachments, transcripts and the vector index built from them. A certificate that says "customer data deleted" covers none of those specifically and gives your auditor nothing to check. A certificate that lists each category and each environment, with dates and a signatory, closes the file.

Use this as a pre-flight list. Each line should be answerable with a number, a name or a document title.

The last row is easy to forget. Many vendors update their terms by posting a revised page, and a DPA that does not state its own precedence can be overwritten by a click-through. Include an order of precedence: DPA, then the signed order form, then the master agreement, then online terms.

If you are assembling the model layer yourself rather than buying a single vendor tool, the same clauses apply to your inference provider, and consolidating to one API with one contract reduces the number of subprocessor schedules you have to track. That is the argument for a single endpoint across text, image, video, audio and embedding models, priced in dollars and OpenAI-compatible, which is what Quanta Inference provides.