An enterprise AI contract needs to reflect how the service works, which suppliers it depends on and what the customer will use it for. Licentium’s AI supplier contract review covers the customer agreement, data terms and supporting procurement evidence for vendors selling into the EU and UK.
The review identifies which commitments the vendor can accept, which need negotiation and which require changes before production. It covers services delivered through the vendor’s own API with third-party models, including pilots moving into enterprise use.
Contracts for AI services sold to enterprises
The service is for founders, sales leads and general counsel negotiating customer paper or preparing a supplier contract pack. The scope covers the master services agreement, statement of work, data processing agreement, service levels and incorporated policies. Order forms, security questionnaires and model-provider terms also matter when they add commitments or override negotiated wording.
The first decision is who supplies and controls each system. A vendor that develops an AI application and supplies it under its own name can be its provider while using another company’s model. A customer using that application under its authority can be a deployer. Commissioning an application under the customer’s own name can change that allocation. Contract labels do not replace the statutory tests. (Regulation (EU) 2024/1689, Articles 2 and 3(3), (4), (68).)
The review records the intended use, product boundaries and each party’s responsibilities. Our guide to responsibility across the EU AI supply chain explains these role distinctions. For an acquisition or investment, AI due diligence addresses the wider business and asset review.
Customer data and downstream model access
A no-training clause needs a defined subject and permitted uses. The schedule should cover prompts, uploaded files, retrieved material, outputs, embeddings, feedback and logs. It should distinguish inference, customer-specific evaluation, support and security monitoring from training, fine-tuning and general product improvement.
The proposed starting position prohibits using customer content for general model training, cross-customer evaluation or general product improvement. Any customer-specific training or evaluation needs an express instruction, a lawful data-use basis, a defined purpose and agreed retention. Feedback channels must not create an unintended permission to reuse confidential content. Any exception for anonymous statistics needs a defined process and evidence of anonymity.
Privacy roles require a separate assessment. Processing personal data on the customer’s behalf calls for Article 28 terms, including instructions, confidentiality, security, assistance, deletion and audit provisions. If the vendor determines a separate reuse purpose, its controller responsibilities must also be assessed. Describing every operation as processing for the customer cannot settle that question. (EU GDPR, Articles 4(7)–(8), 28(3), (10); UK GDPR, corresponding provisions.)
The same restrictions must reach model suppliers and other subprocessors. The review checks their actual contracts, settings, recipients and retention periods. A promise against training does not establish immediate deletion, exclude human review or cover every endpoint.
Before customer data enters the service, map the vendor’s origin country, hosting locations and overseas support access. EU and UK transfer requirements need separate treatment, including the available transfer mechanism and destination assessment. (EU GDPR, Articles 44–46; UK GDPR, Article 46.) Broader lawful-basis assessments and privacy notices can be scoped through data protection for AI.
Terms for changes, performance and regulated buyers
Model changes and human approval
Model-change clauses should identify the approved model, version and configuration. A material change can affect permitted data use, output behaviour, security, location, licensing or the customer’s approved purpose. The proposed schedule provides advance notice, relevant test evidence and an approval or objection process for defined changes. It also addresses model retirement, emergency security changes and what happens when an acceptable replacement is unavailable.
Performance commitments should identify the task, test conditions, agreed measures and remedies. Availability and response times need separate treatment from output quality. The contract should explain known limitations and allocate review responsibilities without promising universal accuracy.
Human approval must match the product’s operation. Identify who can reject an output, stop an action and review a disputed result. Decisions with legal or similarly significant effects require separate EU and UK automated-decision analysis. A signature box cannot establish meaningful human involvement. (EU GDPR, Article 22; UK GDPR, Articles 22A–22D.)
The AI Act timetable also affects contract duration and change control. Following Regulation (EU) 2026/1744, the principal Annex III high-risk duties apply from 2 December 2027; the corresponding duties for AI in products covered by Annex I apply from 2 August 2028. Transparency duties have generally applied since 2 August 2026. Systems placed on the market before that date have until 2 December 2026 for Article 50(2) output marking. The review identifies the provisions and transitional conditions relevant to the actual service. (AI Act, Articles 50, 111(4) and 113.)
Intellectual property, liability and remedies
Customer input permissions, rights in the vendor’s application, third-party model licences and output rights need separate provisions. The review checks what the vendor can grant and what remains subject to upstream restrictions. An output assignment should cover the rights the vendor actually holds; exclusivity and third-party clearance require separate assessment.
An infringement warranty and an indemnity perform different functions. The contract should identify covered claims, exclusions, defence control and the response if continued use becomes unavailable. Replacement, modification, a continuing licence and termination with an appropriate refund should be considered against the supplier chain.
Liability review addresses the general cap, any separate caps, confidentiality, data incidents, IP claims and losses caused by customer misuse. Cap amounts and exclusions require a commercial decision and governing-law review. Insurance evidence should confirm the insured entity, territory, relevant cover and exclusions. A policy certificate alone does not establish that a particular AI claim is covered.
Security, continuity and audit
Security commitments need evidence that matches the service: access controls, incident procedures, testing records and relevant independent assurance. The incident clause should require prompt initial notice, continuing updates and assistance with the customer’s reporting duties. A processor must notify its controller of a personal-data breach without undue delay. (EU GDPR and UK GDPR, Article 33(2).)
For EU financial customers within DORA, the contract requirements depend partly on whether the service supports a critical or important function. Required provisions cover service description, data locations, access and recovery, incident assistance, cooperation and termination. Enhanced requirements include audit rights and exit arrangements. The financial entity retains its regulatory responsibility. UK customers need assessment under the rules applicable to their particular firm. (Regulation (EU) 2022/2554, Articles 28(1)(a), 30(2)–(3); FCA Handbook, SYSC 8.1.)
Suspension and exit clauses should preserve a controlled route to retrieve customer data and move the service. Specify export content and format, transition assistance, charges, deletion and legally required retention. Where the service falls within the EU Data Act’s data-processing-service rules, statutory switching requirements also apply. Continuity promises must account for upstream termination and model licences. (Regulation (EU) 2023/2854, Articles 23–31.)
Documents produced for negotiation and procurement
The proposed scope produces four connected deliverables:
- An MSA, SOW and DPA review, with proposed amendments, document precedence and a negotiation issues list.
- An AI contract schedule covering permitted use, customer content, model changes, performance, human review, incident support and exit.
- A model-provider dependency review recording licence limits, data-use terms, service changes and gaps between upstream rights and customer commitments.
- A procurement response pack linking answers to available evidence, with missing records and actions assigned to their owners.
Scoping starts with the service, countries, customer sector and intended use. Drafting then connects the customer documents to the product and supplier chain. The final review identifies decisions for the vendor, evidence still needed and conditions to close before live data or production use.
Technical testing, certification, regulatory applications, disputes and wider market-entry work require separate scope. Any regulated activity performed by the supplier needs its own permission assessment. The customer’s authorisation does not establish the supplier’s position.
What to send for scoping
Send the available documents and identify what is still being negotiated:
- Customer MSA, order form, SOW, DPA, security schedule and procurement questionnaire.
- Model and hosting agreements, incorporated policies, subprocessor list and relevant account settings.
- A service description showing the API, retrieval sources, model access, outputs and human approval points.
- Vendor and customer countries, customer sector, data categories, storage locations and support-access countries.
- Available security evidence, proposed service levels, model-change plans, incident procedures and export capabilities.
Identify the contracting entities, proposed governing law, negotiation stage and the customer’s intended production use. These facts determine the review perimeter and any local-law work needed.
Request an AI contract scope
Review an enterprise AI contract. Send the customer terms and a short description of the AI service. Licentium can scope the contract amendments, model-provider checks and procurement evidence needed for the proposed enterprise deployment.