What should we look for in an AI vendor's data agreement?
Six things: who processes your data and where, whether it can be used to train models, how long it is retained during and after the relationship, who the subprocessors are and how you learn about changes, what a deletion request triggers, and what the breach notification obligation is. A vague answer on any of these is itself the finding. Have your own counsel review anything you sign.
Read it as a list of questions
A data processing agreement is dense and mostly boilerplate, which tempts people to skim it. Reading it as answers to six specific questions makes it tractable in twenty minutes.
- Processing and location. Which entities handle the data, and in which jurisdictions is it stored?
- Training. Is your content excluded from model training, explicitly, including by downstream providers?
- Retention. How long is content kept while active, and how long after termination?
- Subprocessors. Is there a current list, and are you notified before it changes?
- Deletion. What does a deletion request actually reach, and how long does it take?
- Breach notification. Within what window, to whom, and with what detail?
The clause everyone skips is termination
Data agreements get read for privacy and ignored for exit. But the end of the relationship is exactly when you need the terms to be clear: what you can export, in what format, over what window, and what happens to copies afterward.
Ask specifically whether derived outputs travel with you or stay behind. Transcripts often do. Scores, tags, models and configuration frequently do not, and that is where the real switching cost hides.
Promises flow down, and so do their limits
If your vendor is an integrator, their commitments are bounded by the agreements they hold with model providers and cloud platforms. A vendor promising something stronger than their upstream terms allow is either negotiating on your behalf or not thinking carefully.
The right question is which upstream agreements your content is processed under. A vendor doing serious integration work will answer that directly and can usually show you the relevant terms.
Match the paperwork to the actual system
The most common gap is not a missing clause. It is a contract that describes a simpler system than the one that got built — an integration that also writes to your CRM, ships errors to a monitoring service, and populates a warehouse nobody mentioned.
Put the data flow diagram next to the agreement and check that they describe the same thing. If they do not, fix the diagram or fix the contract, and revisit both when the set of connected systems changes.
Topics: contracts · DPA · vendors · due diligence
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.