How Do You Evaluate an AI Vendor's Data Processing Agreement?

Detailed Explanation

Adopting a new AI tool means trusting that vendor with whatever data your team feeds it — and the specific terms of that trust live in the vendor's data processing agreement (DPA), not in its marketing copy. A DPA is the contract that governs how a vendor, acting as a data processor, is allowed to handle data on your business's behalf as the data controller. Reading it before adoption, rather than after an employee has already started using the tool, is the difference between a deliberate decision and finding out the terms after the fact.

This is a distinct step from is it safe to put company data into AI tools, which covers classifying what data is sensitive enough to need this scrutiny in the first place. This page covers what to actually check once you've decided a tool is a serious candidate.

Five Things to Check Before Adopting

1. Training defaults. Does the vendor use your conversations or documents to train its models by default, and is opting out actually available on the plan you're evaluating — not just on a higher tier you're not buying? Free consumer tiers have historically trained on data by default more often than paid business plans; confirm this explicitly for the specific plan, rather than assuming it matches the vendor's general reputation.

2. Subprocessors and data location. A DPA should list which third parties (cloud hosting, other service providers) the vendor uses to deliver the product, and where data is actually processed and stored. This matters for businesses with data-residency obligations or customers who require it contractually — a vendor's polished homepage rarely mentions this, but a proper DPA does. See does it matter which country an AI tool stores your data in for when this actually matters and how to confirm it.

3. Retention and deletion. How long does the vendor keep your data after a conversation or a document is processed, and can you request deletion on demand? A vendor with no stated retention limit, or one that can't confirm a deletion process, is a meaningfully weaker position than one with an explicit, configurable retention period.

4. Certifications, and whether they actually apply. SOC 2 and ISO 27001 are useful signals that a vendor has passed an independent security audit, but confirm the certification covers the specific product and plan you're adopting — some vendors certify their core infrastructure but not every product built on top of it. See what do SOC 2 and ISO 27001 actually mean when you're choosing an AI vendor for what each certification actually verifies and its real limits, or what does it take to get your own business ISO 27001 certified if your business is the one pursuing certification rather than evaluating a vendor's.

5. Controller/processor roles, stated explicitly. The DPA should name your business as the data controller and the vendor as the processor acting under your instructions. This isn't just legal formality — it confirms your business retains responsibility (and control) for how the data is used, rather than the vendor treating it as their own to repurpose.

A Practical Evaluation Process

1. Request the DPA before signing up for a paid plan, not after — most vendors publish it or provide it on request, and a vendor reluctant to share it before purchase is itself a signal worth weighing.
2. Check the five points above against the document itself, not a sales conversation or a summary page — verbal assurances aren't the enforceable terms.
3. Confirm the DPA covers the plan you'll actually use in production, since trial, free, and paid tiers sometimes sit under different terms from the same vendor.
4. Record the outcome somewhere the business can find it later — a short internal note (vendor, plan, key DPA terms, date reviewed) saves re-doing this evaluation from scratch at renewal or when someone asks later why a tool was approved.
5. Set a review date, since vendor terms change — a DPA reviewed a year ago may already be out of date if the vendor has updated its data-handling terms since.

Things to Consider

• This is jurisdiction-dependent. An Australian business handling personal information is subject to the Privacy Act 1988 and the Australian Privacy Principles (APPs), which require reasonable steps to protect personal information and, under APP 8, impose accountability for personal information disclosed to an overseas recipient — a vendor's DPA is the practical evidence that step was taken, and the OAIC's Notifiable Data Breaches scheme is what triggers if it wasn't. If your business also has EU customers or an EU presence, GDPR may apply on top of this due to its extraterritorial reach — check current requirements for wherever your business and customers are located rather than assuming one region's rules cover you globally. See does GDPR apply to a business using AI tools for when the EU rules specifically come into play.
• A thorough DPA review only protects a business if the approved tool is actually the one people use. See how do you stop employees from using unauthorized AI tools — a rigorously vetted vendor doesn't help if staff are still routing around it on personal accounts with no DPA at all.
• Vendor terms change over time, sometimes without much notice. Treat this evaluation as something to repeat on the site's 6-month review cycle for compliance-sensitive topics, not a one-time gate at initial adoption.
• The output of this evaluation belongs in the usage policy's approved-tools list. See what should an employee AI usage policy include for turning a vendor evaluation into a rule employees can actually follow.
• This evaluation happens at adoption; a matching check belongs at the other end of the relationship too. See what happens to your data when you stop using an AI tool for confirming a vendor's retention and deletion promises were actually kept once you cancel or switch away.

Common Mistakes

• Evaluating the vendor's marketing page instead of the actual DPA. "We take security seriously" is not an enforceable commitment — the specific terms that matter are in the contract, not the pitch.
• Approving a vendor based on the free trial's terms, then rolling out the paid plan without re-checking. Trial and production terms aren't always identical; confirm the plan you're actually deploying.
• Treating a certification as the whole answer. SOC 2 or ISO 27001 is a strong signal, not a substitute for reading what the DPA actually commits to for retention, training, and subprocessors.
• Skipping this step for a "just testing it" pilot that quietly becomes production use. A tool adopted informally for a small pilot often ends up handling real business data without ever going through this evaluation — apply the same check before a pilot touches anything beyond public or synthetic data.
• Not recording the evaluation anywhere. Without a written record, the same due diligence gets redone from scratch, inconsistently, every time someone asks whether a tool is approved.