1) What changed in 2026 (and why contracts matter more)

First and foremost, three shifts make AI contracts materially different from standard SaaS procurement:

• AI is embedded into core operations: support, marketing, finance, HR, fraud, and analytics workflows increasingly depend on AI features.
• Models update continuously: what you buy today can change next month affecting accuracy, cost, and risk.
• Evidence expectations increased: partners and enterprise customers now ask for vendor terms, security posture, and governance controls as part of due diligence.

Helpful global implementation references include the NIST AI RMF and NIST Privacy Framework.

2) The AI procurement risk map: what you’re really buying

Before negotiating clauses, align internally on what the tool actually does. In fact, most surprises happen because procurement teams don’t map data and decision pathways.

Questions your team should answer before signing

• Inputs: What data goes in (customer tickets, IDs, HR data, financial data, call recordings)?
• Outputs: What comes out (recommendations, replies, scores, summaries)?
• Training: Does the vendor train on your content by default?
• Location: Where is data stored and processed? Additionally, are there any cross-border processing concerns?
• Third parties: Which sub-processors or model providers are involved?
• Change control: Can the vendor materially change the model or terms without notice?

3) The 12 clauses to demand in 2026

1) Data use restrictions (purpose limitation)

Limit processing strictly to service delivery. Consequently, avoid broad “business purposes” language that could expose your data.

2) Training and improvement: opt-in, not default

Require an explicit opt-in before your data, prompts, or outputs are used to train or improve models. Otherwise, your confidential information could become part of a vendor’s training dataset.

3) Retention, deletion, and exit obligations

Define retention periods, deletion timelines, and how deletion is confirmed after termination. Furthermore, ensure you have audit rights to verify compliance.

4) Confidentiality covering prompts, outputs, and derived data

Prompts can contain trade secrets and personal data. Similarly, outputs can create sensitive derivatives. Therefore, your contract must cover both.

5) Security controls that are specific (not vague)

Anchoring security to concrete commitments is essential: encryption, access controls, logging, vulnerability management. In other words, demand specifics, not platitudes.

6) Sub-processor controls and change notifications

Get an up-to-date list, notice periods for changes, and a right to object where risk is high. Moreover, ensure flow-down obligations are in place.

7) Incident and breach notification timelines

Define notice timelines and cooperation obligations so you can meet regulatory and client requirements. As a result, you’ll be prepared to respond quickly.

8) Audit rights and reporting (reasonable but real)

Where full audits aren’t feasible, require structured alternatives: SOC2/ISO reports, pen test summaries, security questionnaires. Ultimately, you need visibility.

9) Change control for material model updates

Require notice of material changes, transparency on impact, and exit/rollback rights where risk or performance materially changes. After all, the model you signed up for may not be the one you’re using next month.

10) IP and output rights

Clarify rights to use outputs commercially and address restrictions and third-party claims. Meanwhile, ensure your inputs remain your property.

11) Warranties and disclaimers

For critical uses, avoid “as-is” posture without meaningful commitments on security, performance, or compliance. Instead, negotiate warranties that match your risk profile.

12) Liability allocation that matches risk

Caps and exclusions should reflect sensitivity of data and use-case impact. Finally, consider tailored indemnities where appropriate.

For governance thinking, see global guidance such as the EDPB and UK ICO.

4) Case example: SME adopts an AI support tool

Consider this scenario: A growing services company implements an AI support assistant integrated into its helpdesk. Initially, staff start pasting screenshots into the tool to speed up ticket resolution screenshots that include customer IDs, account details, and internal notes.

Subsequently, a customer complains after receiving a response that reveals information that should not have been shared. Importantly, no “hack” occurred. Nevertheless, the business now faces a confidentiality issue, a data protection question (what data was processed, where, and under what terms), and commercial risk (clients asking for vendor due diligence evidence).

In situations like this, the first document everyone opens is the vendor agreement: what it says about data use, retention, training, security, incident notice, and cooperation determines how fast you can respond.

5) Common mistakes companies make

• Shadow procurement: teams buy AI tools without legal/security review. Consequently, risk accumulates unnoticed.
• No AI use register: the business cannot state what AI tools are in use and what data they touch.
• Assuming terms are non-negotiable: many vendors negotiate, especially for business plans. Therefore, always ask.
• Ignoring cross-border processing: the tool stack is often global by default.
• Relying on “staff will be careful”: without policy + training + technical restrictions, sensitive data will be pasted in.

6) 30-minute AI contract review checklist

7) What businesses should do next (30-day plan)

Week 1: Inventory and ownership

• Create an AI use register: tool, owner, purpose, data types, vendor, risk rating.
• Flag high-risk uses (customer decisions, HR screening, sensitive data).

Week 2: Procurement controls

• Set a minimum contract standard (DPA/security/change control/incident notice).
• Define when legal + security sign-off is mandatory.

Week 3: Contract cleanup

• Negotiate high-risk vendor terms or implement an addendum.
• Document cross-border processing and sub-processors for critical tools.

Week 4: Training and operational rules

• Train teams on what data cannot be entered into external AI tools.
• Implement practical escalation for AI incidents (harmful outputs, data exposure).

8) How MN Legal helps

At MN Legal, we support organisations adopting AI by reviewing and negotiating AI vendor contracts and DPAs, mapping cross-border and vendor risk, drafting AI usage policies and governance frameworks, and advising on incident readiness where AI touches personal or confidential data.

FAQ

Are AI vendor terms negotiable?

Often yes especially for business and enterprise tiers. However, where standard terms apply, use addenda for data use, security, incident notice, audit, and change control.

Do we need a DPA when buying AI tools?

If the vendor processes personal data on your behalf, you typically need data processing terms covering purpose, security, sub-processors, transfers, and deletion.

What if the vendor changes the AI model after we sign?

Include change control: notice of material changes, transparency on impact, and rights to pause, rollback, or terminate if risk/performance materially changes.

What’s the biggest contractual risk in AI procurement?

Unrestricted data use (including training), unclear retention/deletion, weak incident obligations, and liability caps that don’t match the sensitivity of data or use case.

How can MN Legal help?

We help businesses implement practical procurement controls and defensible vendor terms for AI aligned with privacy, security, and commercial realities.