AI contract negotiation has become its own discipline inside privacy and legal teams, and many organizations are still building the skills for it. To be clear on scope, this post covers negotiating the privacy terms in contracts with AI vendors, not using AI to negotiate contracts. It is a privacy-focused playbook, not a complete guide to AI contracting. Ownership, IP infringement, output reliability, and other commercial AI issues are largely outside its coverage.
A standard DPA template was built for fairly predictable data flows. AI makes those flows less predictable, and contracts have to catch up. Below is a practical approach to scoping AI addendums, keeping your templates consistent, and negotiating from documented data use and operational risk.
Mandatory privacy protections are the baseline, not bargaining chips
Where applicable, privacy laws require specific contractual protections. GDPR Article 28 mandates terms for controller–processor relationships, and the CCPA requires specified terms for service providers and contractors. Parties can negotiate how those requirements are implemented and agree to additional commercial protections, but they cannot contract below the applicable legal baseline.
Privacy and InfoSec provisions are often conflated. They have different scopes, but they overlap: Article 28 itself requires commitments on the security measures set out in Article 32.
When parties rely on the EU’s Standard Contractual Clauses for international data transfers, they must preserve the mandatory protections. Permitted adaptations include selecting modules and options and completing the required fields and annexes. Any additional terms must not contradict the SCCs or prejudice data-subject rights. For a primer on what these documents are meant to accomplish, TrustArc’s guide to the foundations of privacy contracting is a good starting point.
AI adds a layer on top of that baseline. Existing privacy law arguably already covers much of what organizations worry about with AI. Model training, however, has become a significant enough concern that many contracts now address it separately.
Get privacy involved early, or risk deals unraveling later
A common risk in privacy contracting is a gap between what the contract says a company will do and what its engineering, product, and marketing teams actually do. The fix is to bring privacy into procurement conversations early, before paper starts moving. When privacy gets pulled in at the last minute and nobody has mapped how data will actually flow, it can delay or derail a deal.
It also helps to retire the idea that privacy and compliance exist to say no. A more useful frame is a “department of how”: give sales and marketing real answers so they don’t have to improvise privacy concepts during a negotiation. A centralized, customer-facing resource can do much of that work. It should document what your technology does, how data moves, and the answers to common questions. TrustArc has written more on what a Trust Center is and why it has become part of this playbook.
Consistency is as important as coverage
As a contract package grows, it can include a DPA, a security addendum, a BAA where HIPAA applies, and an AI addendum. Different teams often draft these documents without coordinating. The result can be conflicting definitions of personal data, different audit cadences, and mismatched notification timelines.
Two checks are worth running. Does the indemnity provision in your Master Services Agreement match the one in your DPA? Does the breach notification timeline in your InfoSec addendum match the one in your DPA? Inconsistencies like these can create confusion for regulators, auditors, and outside counsel trying to work out what your obligations actually are.
Different notification obligations may legitimately sit in different documents. The fix is to name a clear source of truth for each one, use precise cross-references and an order-of-precedence clause, and distinguish personal-data breaches from broader security incidents.
Consistent contracts don’t guarantee consistent behavior on their own. Translate each commitment into operational procedures, escalation paths, and accountable owners so the teams doing the work follow the same obligations the contract describes. TrustArc’s breakdown of decoding data processing agreements covers where these inconsistencies tend to hide.
Timing can affect leverage as much as company size
In practice, negotiating leverage often depends as much on where you sit in the deal cycle as on company size. A privacy conversation that happens before a vendor is chosen looks very different from one at 11:59 p.m. on December 31, when someone’s budget is about to expire. Legal tends to make more progress as a problem-solver than as an obstacle. Leaving ego out of the negotiation and being open about what your business can and cannot operationalize often achieves more than posturing.
Don’t assume size equals leverage. A small vendor offering something unique can have real leverage over a much larger customer if that customer has no appetite to walk away. Leverage depends on what is being bought, the timing, and each side’s actual risk tolerance.
Not every AI vendor is building a large language model
Many AI addendums are written as though every AI vendor builds a large language model. Some vendors instead use behavioral, predictive, or classification models. The privacy risks of any model depend on the signals collected, the inferences it produces, the people affected, and the purposes of processing, not on the model category alone.
When a contract assumes an LLM by default, it can focus on scenarios that don’t apply to the vendor in front of you while missing the ones that do. The better move is to get specific early. Define exactly what “aggregated,” “anonymized,” “pseudonymous,” and “service improvement” mean in the document, rather than leaving them as undefined catch-all terms.
It also matters whether a vendor uses an AI provider’s API or its consumer chat interface. An API is not automatically a privacy-safe channel, though. Check the actual terms, retention settings, training permissions, and downstream providers.
The same goes for internal AI use. An engineer using an AI coding assistant is different from AI generating the product a customer buys. That coding assistant may still receive customer code, confidential specifications, or personal data. Scope AI restrictions to the uses that carry real risk, so they don’t block ordinary engineering work while missing the exposures that matter.
Know your red lines and your fallback positions
Go into any AI contract negotiation knowing your absolute red lines. For many organizations, one red line is an unconditional no on using personal data for model training. Then define separate fallback positions for pseudonymized data and for data demonstrably anonymized under the applicable law. A contractual label alone, or removing direct identifiers, does not prove that privacy obligations no longer apply.
Be precise about which training permissions are on the table. Distinguish:
- Customer-specific fine-tuning from shared or general-purpose training
- Prompts, uploaded files, outputs, feedback, and telemetry
- Service delivery from broader product improvement
- The vendor’s own use from use by downstream model providers
If a vendor later wants broader rights, the parties should agree to them expressly and complete a fresh legal and risk assessment. TrustArc’s AI Compliance Handbook is a useful reference for building this kind of playbook from scratch.
The provisions worth negotiating carefully
Several provisions come up repeatedly, starting with scoping:
- Is the relationship B2B or B2C?
- Are you a controller or a processor?
- Does the service create, receive, maintain, or transmit PHI on behalf of a HIPAA covered entity or business associate, so that a BAA is required? If not, assess any other health-data privacy requirements that apply. A BAA also does not authorize uses that HIPAA otherwise prohibits.
Don’t rely on a narrow understanding of “PII.” Use the definitions in the applicable law, including “personal data” and “personal information.” Assess indirect identifiers and inferences, not just names and email addresses. Depending on context, information such as an IP address, or household-level information under California law, can fall within those definitions.
Limitation of use is its own category. GDPR Article 28 requires the subject matter, duration, nature, and purpose of processing to be clearly defined. That definition shapes internal decisions well beyond legal, down to who inside a company gets access to a given AI reporting tool.
Subprocessor management is another common flashpoint. Where appropriate, use general written subprocessor authorization with three safeguards: advance notice of intended additions or replacements, a meaningful opportunity to object, and agreed grounds and remedies for objections. GDPR does not prescribe a universal 30-day notice period. Name the issues that are real dealbreakers, such as geographic or regulatory restrictions. No category of subprocessor, including cloud infrastructure providers, is exempt from the notice-and-objection process. A public subprocessor list with a subscription mechanism can support that process, but posting a website update doesn’t satisfy it on its own. The contract should address how notice is delivered, the timing for objections, and what happens if an objection can’t be resolved.
On liability, Article 28 does not itself require a general unlimited commercial indemnity, so a counterparty claiming “the law requires” one may be overstating things. Negotiated liability provisions must still preserve applicable statutory rights and mandatory contractual protections, including the liability scheme in the EU transfer SCCs. It’s also worth agreeing how specific costs are treated. Whether a cost counts as direct or consequential damages depends on the governing law and the contract wording. Allocate forensic, notification, remediation, and credit-monitoring costs expressly, rather than assuming how a consequential-damages clause will treat them. TrustArc’s guide to the most negotiated provisions in a data processing agreement gives a fuller rundown of where these provisions tend to get contested.
The one takeaway
Before you sit down at the negotiating table, know what data you have and what your operations can commit to. Know your vendors and what kind of AI they are really running, and be clear on your real timelines before the contract arrives. Almost everything above, from AI addendums to subprocessor notice, comes back to one idea: negotiate based on documented data use and operational risk, not worst-case assumptions.
When customers and counterparties can find accurate answers on their own, negotiations start from shared facts. Give customers one place to find approved privacy documents, AI disclosures, and subprocessor updates.
Explore our Trust Center
