AI Clauses in Customer Contracts: What to Commit to and How to Prove It

Short answer: AI clauses in customer contracts are commitments about how your AI features use, retain and protect customer data, which model providers you rely on, and how you test, disclose and notify. Accept only terms you can evidence today, track each one in a commitment register with an owner and a control, and push back on absolute promises.

Related guides:

• AI governance policy: sections, owners and audit evidence
• The AI vendor questionnaire that exposes hidden security risks
• AI and HIPAA compliance

Key takeaways

• In our experience, enterprise and healthcare buyers now send AI-specific language in MSAs, DPAs or a separate AI addendum.
• The most common ask is a no training on customer data clause. It is easy to sign and easy to break when a provider's terms change.
• Some AI terms are regulatory pass-through: GDPR Article 28 processor terms, HIPAA business associate agreements when PHI reaches an AI provider, and EU AI Act Article 50 transparency duties, which apply from 2 August 2026.
• A commitment register turns every signed clause into an owner, a control and a piece of evidence, using ISO/IEC 42001 and the NIST AI RMF as control sources.
• Negotiate toward commitments you can prove. Absolute promises about accuracy, bias or "no AI" create obligations nobody can evidence.

---

Which AI clauses are customers adding to contracts?

Customers are adding clauses that restrict how their data feeds AI, require disclosure of model providers, and set rules for transparency, oversight, testing and incidents.

In our experience, the same ten themes appear across customer paper. The table pairs each with the evidence you would need to show.

Clause theme	What the customer typically asks	Evidence you should be able to produce
Data use and model training	No use of customer data, prompts or outputs to train or improve models	Model provider terms, configuration settings, internal data use policy
Subprocessors and model providers	A named list of AI providers, with notice before changes	Subprocessor list, change log, notice records
Retention of prompts and outputs	Fixed retention periods and deletion on termination	Retention settings, deletion logs, provider retention terms
Human oversight	A human reviews consequential outputs	Workflow design, review records, role descriptions
Transparency	Users are told when they interact with AI or see AI-generated content	UI labels, product documentation, release notes
Accuracy	Outputs described as assistive, with limits disclosed	Product disclaimers, evaluation results
Opt-out	Ability to disable AI features per tenant	Admin setting, documentation, test record
Security testing	AI features included in penetration tests and threat models	Test scope, findings, remediation tickets
Incident notification	Notice of AI-related incidents, such as data leakage through a model	Incident response plan with AI scenarios, notice templates
Regulatory pass-through	Compliance with GDPR, HIPAA, EU AI Act as applicable	DPA, BAAs, transparency assessment

The no training on customer data clause deserves the most care. It can cover your own models, your providers' models, and derived data such as embeddings. Read your provider's terms before you sign, and define whether prompts, outputs and telemetry count as customer data.

Should AI terms live in the MSA, the DPA or an AI addendum?

Put personal data processing terms in the DPA, commercial and liability terms in the MSA, and AI-specific operational commitments in an AI addendum, so each document stays consistent with its purpose.

A common failure is the same promise written three different ways, which contradict each other the moment you add a model provider. A practical split:

1. MSA: definitions of AI features, customer data and outputs; ownership of outputs; warranty and accuracy disclaimers; liability caps.
2. DPA: processing purposes, subprocessor authorization and objection rights, retention and deletion, security measures, breach notification.
3. AI addendum: model training restrictions, opt-out, human oversight, transparency, AI testing, and a pointer to your published model provider list.
4. BAA (HealthTech): permitted uses of PHI, including whether PHI may be sent to an AI provider at all.

Publishing a standard AI addendum lets you negotiate from your own paper.

Which regulatory obligations flow through to AI terms?

Three regimes most often flow into AI terms for SaaS and HealthTech vendors: GDPR processor rules, HIPAA business associate rules, and EU AI Act transparency duties.

GDPR Article 28. When you process personal data for a customer, you act as a processor. The EDPB guidance on controllers and processors explains that the processor acts only on the controller's instructions and "shall not engage another data processor without prior specific or general written authorisation," and that the controller must have a meaningful possibility to object. An LLM provider that receives prompts containing personal data is usually a sub-processor, so it belongs on your list and under the same notice process as any other.

HIPAA. If PHI flows to an AI provider, that provider is generally a subcontractor business associate. HHS sample business associate agreement provisions require a business associate to ensure that subcontractors that create, receive, maintain or transmit PHI agree to the same restrictions, and to report breaches of unsecured PHI. HHS cloud computing guidance adds that a cloud provider handling ePHI is a business associate even if it stores only encrypted ePHI without the key. Before you promise a customer that PHI may be used with an AI feature, confirm you have a BAA with that model provider.

EU AI Act. Article 50 of Regulation (EU) 2024/1689 sets transparency obligations for certain AI systems. Providers must tell people when they interact directly with an AI system, unless that is obvious, and providers of systems that generate synthetic audio, image, video or text must mark outputs in a machine-readable, detectable way, subject to exceptions. Deployers have separate duties, for example for deepfakes. As of October 2026, the Commission's Article 50 FAQ states that Article 50 applies from 2 August 2026, with a grace period until 2 December 2026 for the marking obligation in Article 50(2) for systems placed on the market before 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved high-risk obligations under Article 6(2) and Annex III to 2 December 2027, according to the AI Act Service Desk text of Article 113. For a deeper walkthrough, see our EU AI Act compliance guide.

When customers ask you to "comply with the EU AI Act" in general terms, narrow it to the obligations that apply to your role and systems.

How do you build an AI commitment register?

An AI commitment register is a list of every AI promise you have signed or published, each mapped to an owner, a control and the evidence that proves it.

Build it in five steps:

1. Extract. Pull AI language from signed MSAs, DPAs, AI addenda, BAAs, questionnaire answers and trust center statements.
2. Normalize. Group similar wording into one standard commitment, and note each customer with a stricter variant.
3. Assign an owner. One named person per commitment.
4. Map to a control. Use recognized sources so auditors and customers understand the mapping. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, which gives you a management system to attach each commitment to. The NIST AI Risk Management Framework, released in January 2023 for voluntary use, organizes AI risk work into Govern, Map, Measure and Manage, and NIST's Generative AI Profile (NIST AI 600-1) adds generative AI specific actions.
5. Attach evidence and review. Link the artifact that proves the control works, and set review triggers such as a model provider change.

An example row:

Field	Example value
Commitment	Customer prompts and outputs are not used to train models
Source documents	AI addendum v2, DPA section on processing purposes, questionnaire answers
Owner	Head of engineering
Control	Model provider configuration and contract review before onboarding
Evidence	Provider terms excerpt, configuration screenshot, quarterly review record
Review trigger	New model provider, provider terms change, new AI feature

Which red flags should you push back on in customer paper?

Push back on any clause that promises an outcome you cannot measure, bans something your product already does, or gives the customer unlimited rights over your AI supply chain.

Common red flags:

• "Vendor shall not use AI." Blanket bans often conflict with existing features. Propose a scoped definition and a per-tenant opt-out.
• Accuracy warranties. "Outputs will be accurate and free of bias" cannot be evidenced. Offer a description of evaluation practices and an assistive-use disclaimer.
• Undefined "customer data." If it silently includes telemetry, normal product analytics may breach the clause.
• Prior consent for every model change. Article 28 allows general written authorization with notice and an objection right. Specific consent for every change can freeze your roadmap.
• Instant notice for any "AI issue." Tie notification to defined incidents and timelines in your incident response plan.
• Unlimited audit rights over model providers. You cannot grant access to a third party's systems. Offer their attestations and your review records.
• Uncapped liability for AI outputs. Route this to legal counsel. It is a commercial question, not a control question.

What belongs on your AI contract negotiation checklist?

Your checklist should confirm that every AI term is defined, consistent across documents, backed by a control, and owned before signature.

Run through these before you sign:

• Definitions of AI features, customer data, prompts and outputs match across documents.
• Model provider terms support every training and data use commitment.
• Subprocessor list names each AI provider, with notice matching your DPA.
• Retention periods match your actual settings and providers' terms.
• PHI is excluded from AI features unless a BAA covers the provider.
• Transparency commitments match your UI and any Article 50 duties.
• Human oversight and opt-out promises describe features that exist today.
• Security testing scope includes AI features you actually test.
• Incident notice timelines match your incident response plan.
• Register has an owner, control and evidence for each new commitment.

If a clause fails a check, change the clause or fix the control before you sign.

How SecureSlate helps

Built-in ISO 42001 and EU AI Act frameworks give you a starting set of AI controls, and custom controls let you add a control for each customer-specific commitment in your register, mapped alongside SOC 2, ISO 27001, HIPAA and GDPR through multi-framework control mapping. Vendor risk management tracks each model provider, its terms and review dates, so a provider change prompts a review of the commitments that depend on it. The trust center lets you publish your subprocessor list and standard AI documentation, and security questionnaire automation helps keep AI answers consistent with what you have signed. SecureSlate does not provide legal advice or draft contracts.

Start your free SecureSlate trial

FAQ

What is an AI addendum?

An AI addendum is a contract schedule that sets AI-specific terms, such as training restrictions, model provider disclosure, retention of prompts and outputs, opt-out, human oversight and transparency. It sits alongside the MSA and DPA and should use the same definitions.

Should we sign a no training on customer data clause?

Only if your own practices and every model provider's terms support it, and only once "customer data" is defined. Then record it in your register with a review trigger for provider changes.

Is an LLM provider a subprocessor?

Usually yes, when it processes personal data on your behalf to deliver the service. Under GDPR Article 28 it then needs to be authorized by the controller, generally through your subprocessor list and notice process, and bound by equivalent data protection terms.

Do we need a BAA with our AI provider?

If PHI is sent to the provider, it is generally a subcontractor business associate, and HHS guidance says you must ensure it agrees to the same restrictions. If you cannot get a BAA, keep PHI out of that AI feature.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.