Procurement doesn't reject AI vendors for bad products. It rejects them for a DPA that never mentions subprocessors, training data, or where the data actually lives.
- A DPA that omits subprocessor flow-down terms is the single most common reason enterprise legal stalls an AI agent deal
- Clause 28 of GDPR's Article 28 requires specific, not general, subprocessor consent language, and generic SaaS DPA templates usually only grant general consent
- OpenAI, Anthropic, and Microsoft all publish separate enterprise addenda that explicitly carve out customer data from model training by default, and your DPA should mirror that structure
- Data residency commitments must be contractual, not just a dropdown in your admin console, because enterprise legal reviews the contract, not your settings page
- Salesforce's own AI DPA for Agentforce names retention periods, deletion timelines, and training exclusions in the base agreement, not a separate email thread
Here's the thing about selling an AI agent into a large company: your champion loves the product, your pricing is fine, and then the deal sits for six weeks because someone in legal asked one question your data processing addendum can't answer. Which subprocessors touch customer data. Whether their prompts and outputs train your model. Where the data physically sits. If your DPA is silent on any of those three, the deal doesn't die loudly. It just stops moving.
Founders selling AI agents into enterprise keep assuming a generic SaaS DPA, the kind generated by a $200 legal template service, will clear review. It won't, and not because enterprise lawyers are being difficult. An AI agent is a different animal from a CRM or a ticketing tool. It ingests live customer data, often routes it through a third-party model provider, and in many architectures retains some of it for fine-tuning or evaluation. A standard DPA written for a database-backed SaaS product doesn't ask any of the questions that matter for that.
A typical SaaS DPA covers four things: what data is processed, for what purpose, how long it's retained, and who else can touch it. That fourth point, the subprocessor clause, is where most AI agent contracts fall apart under enterprise legal AI vendor security review. Article 28(2) of GDPR requires that a processor get the controller's prior written authorization, either specific or general, before engaging a subprocessor. General authorization is allowed, but it has to come with the right to object to any new subprocessor and reasonable notice before one is added.
Most AI startups build on top of OpenAI, Anthropic, or AWS Bedrock, and that provider is a subprocessor the moment customer data flows through it. If your DPA doesn't name that relationship, enterprise legal will find it anyway, usually during the security questionnaire, and then ask why it wasn't disclosed upfront. That single gap turns a two-week legal review into a two-month one, because now the reviewer doesn't trust the rest of the document either.
How to Set an AI Agent Data Retention Policy Before a Security Review Security teams now ask whether training use is opt-in, whether a specific customer's data can be deleted on request, and whether SOC 2 Type II audits can prove the stated retention period is actually followed. - data retention policy for AI agent startups - enterprise security questionnaire data retention requirements
The fix is boring and specific: list every subprocessor by name, state what each one does with the data, and commit to 30 days' notice (not 10, not "reasonable notice") before adding a new one. Anthropic's own commercial terms for enterprise customers list exactly this kind of subprocessor schedule as an exhibit, updated on a defined cadence, not buried in a privacy policy that changes without notice. That's the model to copy, not invent.
Training data use is the clause that kills deals fastest #
If there's one line item that gets an AI agent contract escalated straight to a company's chief privacy officer, it's training data use. Enterprise legal has been burned enough times by vague "we may use your data to improve our services" language that they now read it as a red flag by default, regardless of what the vendor actually does with the data. Say it plainly in the DPA, not the terms of service, not an FAQ page: customer data is not used to train, fine-tune, or evaluate any model unless the customer opts in, in writing, for a specific use case. OpenAI's enterprise and API data usage policies draw this exact line, with zero-retention and no-training defaults for API customers that differ sharply from consumer ChatGPT terms. Salesforce built the same carve-out into its Agentforce DPA, naming training exclusion directly in the contract body rather than leaving it to a side letter procurement has to go dig up.
If your product genuinely needs customer data to improve the model, say so, and give the customer a separate, revocable opt-in with its own retention terms. Don't bundle it into the general processing clause and hope nobody reads closely. They will. That's their job.
Data residency has to be a contract term, not a product setting #
Founders tend to treat data residency as an infrastructure decision: pick AWS us-east-1 or eu-west-1, flip a toggle, done. Enterprise legal doesn't review your infrastructure. It reviews your contract. If the DPA doesn't name the region where data is processed and stored, and doesn't commit to keeping it there, the admin console setting is worthless to the reviewer sitting across the table.
This matters most for companies with EU, UK, or financial-services customers, where data residency isn't a preference, it's a regulatory requirement tied to frameworks like GDPR's Chapter V transfer rules or, for banks, local data localization rules that vary by jurisdiction. Write the actual commitment into the DPA: which regions data is processed in, whether it ever crosses a border for backup or support purposes, and what happens on contract termination, specifically a deletion timeline. Thirty days is a reasonable standard; anything open-ended or silent gets flagged immediately.
What actually goes in the addendum #
Strip away the legal boilerplate and a DPA that clears enterprise review has five load-bearing sections, and none of them is optional for an AI agent vendor specifically. The subcontractor schedule, named above, with notice periods and the right to object. A training-data clause, with the no-training default and an explicit opt-in path if you need one. A data residency commitment tied to actual regions, not vague geography. A security section that maps to SOC 2 Type II or ISO 27001, whichever you actually hold, because enterprise legal will ask for the report, not the badge on your website. And a breach notification clause with a real number of hours, 72 to match GDPR's own regulator notification window, not "promptly."
How to Structure an AI Agent Pilot So Procurement Actually Says Yes Sierra, the customer service AI company founded by Bret Taylor, scopes pilots around a measurable outcome, such as a resolution rate against a defined ticket volume, rather than an open-ended trial. OpenAI applies similar sequencing on security reviews. - how to structure AI agent pilot programs - getting enterprise approval for AI agent contracts
Don't write a sixth section trying to cover every hypothetical edge case your lawyer can imagine. A DPA that tries to anticipate everything reads as padding to a reviewer who's seen hundreds of these, and padding slows review down rather than speeding it up. The five sections above are what gets checked. Everything else is negotiated case by case, usually in redlines, after the base document has already earned trust.
One more practical note: have this document ready before the first security questionnaire lands, not after. A startup that produces a tight, specific DPA unprompted, the moment procurement asks, signals it has done this before. A startup that scrambles to draft one in response to a questionnaire signals the opposite, and enterprise buyers read that signal correctly almost every time.
Also read: How to Structure a Founder Deadlock Clause Before You Split • How to Set an AI Agent Data Retention Policy Before a Security Review • How to Structure a Customer Advisory Board Before It Becomes Free Support
This article is posted in Startup News, check it out for more related stories.
Join the discussion #
Open in the community → Almost there. Sign in and your reply posts straight away.