AI Implementation Contracts for SMEs: What Yours Must Contain

Most AI proposals an SME receives run to four pages of scope and half a page of terms, lifted from the template the agency uses for website builds. That imbalance is where the money leaks: not in the day rate, but in who owns the fine-tuned model, what happens when the underlying model is retired mid-project, and what “finished” legally means for a system that is right most of the time.

An AI implementation is not a website. It runs on a third party’s model you don’t control, it produces probabilistic output, and it degrades quietly rather than breaking loudly. The contract has to price that in before you sign, because almost none of it is renegotiable once the work starts.

The short answer: what the contract must contain

An AI implementation contract for an SME has to put eight things in writing. Anything missing from this list becomes a cost you discover later, usually at the worst possible moment.

1. Scope written as measurable outcomes, plus a frozen evaluation set.
2. Rights to every artefact created — prompts, fine-tuned weights, embeddings and evaluation data, not just “the software”.
3. A GDPR Article 28 processor clause naming every sub-processor, the model API provider included.
4. An explicit split of EU AI Act roles: you as deployer, the supplier as provider.
5. An SLA built on AI-specific metrics — answer quality against a held-out set, latency, escalation rate — not uptime alone.
6. Acceptance criteria tested against that same set before the final payment is released.
7. A model-change clause covering version upgrades, deprecations and drift.
8. Exit terms that let you take the system somewhere else.

Why a standard software contract won’t stretch to cover it

Three gaps open up when you paste a web development agreement over an AI project.

Determinism. Ordinary software passes a test or fails it. An AI feature passes most test cases, so the contract has to say which score counts as delivery and which counts as breach.

The supply chain. Your supplier does not own the model. It resells access to OpenAI, Anthropic, Google, Mistral or open weights running on someone else’s GPUs, so every promise about availability, pricing and behaviour is a promise about another company’s product.

The asset. What you are buying is rarely code. It is a prompt library, a retrieval index, evaluation cases and configuration, none of which transfers under a clause about “the Software”.

The eight clauses that do the work

1. Scope written as outcomes, with a frozen test set

The scope schedule should name the process, the volume, the systems it touches and the measurable result: “handles around 500 messages a day from the shared Outlook mailbox, sorts each one into six categories and drafts a reply for human approval.”

Then insist on the artefact almost no supplier offers voluntarily: a fixed set of real, anonymised cases with correct answers agreed by you, frozen before development starts. Acceptance, the SLA and every future dispute are measured against it. Without it, “it works well” is an opinion.

2. Model rights: who owns which artefact

“Model rights” is not one right. It is a list of separate assets, and most supplier templates mention only one or two, which leaves the rest with the supplier by default.

Copyright in the outputs is a separate question, and genuinely unsettled. The US Copyright Office’s January 2025 report on copyrightability confirms that material generated without sufficient human authorship cannot be registered, and the UK provision for computer-generated works in section 9(3) of the Copyright, Designs and Patents Act 1988 has been under review. EU law points the same way: protection depends on the work being the author’s own intellectual creation. So don’t accept a “grant” of something nobody may own. Contract for the artefacts instead.

3. Data protection: Article 28 and the sub-processor list

If the system touches personal data, you are almost certainly the controller and the supplier the processor, which means GDPR Article 28(3) already dictates the contents: subject matter and duration, nature and purpose, types of data and categories of data subject, confidentiality, security measures, sub-processor rules, help with data subject requests, deletion or return at the end, and audit rights. That is a legal minimum, not a drafting option.

The AI-specific part is the sub-processor schedule. Name the model provider, the hosting region and any vector database or observability tool, and require written notice with a right to object before that list changes. “Our sub-processors are listed on our website” is not good enough.

Ask in writing whether inputs sent through the model API are used for training. The major providers say business API traffic is excluded by default, but the answer varies by plan and by region, so make the supplier show you the current terms rather than repeat a line from a sales deck.

4. AI Act roles: deployer, or accidental provider?

The EU AI Act, Regulation (EU) 2024/1689, allocates duties by role. Buy a system and run it inside your own business and you are a deployer; put one on the market under your own name and you are a provider, carrying far heavier obligations. Article 25 turns a deployer into a provider in specific cases, including putting your own trademark on a high-risk system, modifying it substantially, or changing what it is meant to do.

That matters more than most SMEs expect, because Annex III treats employment uses such as CV screening, task allocation and promotion decisions as high risk, and plenty of small firms automate exactly those. The contract should state each party’s role, require the supplier to hand over the technical documentation, logging and instructions for use that a deployer needs, and record whether the system is high risk together with the reasoning behind that conclusion.

Article 4 places an AI literacy duty on providers and deployers alike, so make staff training a named deliverable. The application dates are phased and have been the subject of amendment proposals, so check the consolidated text on EUR-Lex for the deadline that applies to you rather than trusting a date on a supplier’s slide.

5. The SLA: uptime is the least interesting number

A 99.9% availability promise tells you nothing about whether the assistant is answering correctly. Build the SLA on four layers.

Availability of the supplier’s own integration layer, with an honest pass-through for the model provider’s outages, because no supplier can promise more uptime than it buys upstream. Performance, expressed as 95th-percentile response time under a stated load. Quality, expressed as the pass rate against the frozen evaluation set, re-measured at an agreed interval, with a threshold that triggers remediation at the supplier’s cost. Support, with severity levels that cover the category most templates miss: the system is up, it is fast, and it is confidently wrong at scale.

Attach service credits worth claiming, a right to terminate for repeated breach, and an obligation to report the monthly measurement without being asked.

6. Acceptance: define “done” before you agree the price

Acceptance is the clause that decides whether you ever have leverage. Agree the test plan as a schedule before work begins: which cases run, what pass rate counts as a pass, how defects are graded, and how long your acceptance testing window runs in business days.

Watch for deemed acceptance. Wording that treats five days of silence as approval is common, and on a project that lands while half the team is on holiday it is expensive. Negotiate that the clock starts only once a complete test package has been delivered, that you get a retest after remediation, and that a second failure entitles you to reject the milestone outright.

Then tie the money to it: a deposit, a milestone payment at integration, and a final tranche released only after acceptance plus a stability period in live use.

7. Model change, deprecation and drift

The model your system runs on will change whether or not the contract mentions it. Providers deprecate versions, retune behaviour and adjust pricing on their own schedule, not yours.

Require written notice before the supplier switches base model or version, and require the evaluation set to be re-run and the results shared before the switch, not after. State that a deprecation forced by the model provider is a maintenance event under the existing agreement, not a chargeable new project. Set out how often drift is checked, who pays for remediation inside the warranty period, and how token price changes pass through, ideally at a fixed unit price or under a cap.

8. Exit, portability and escrow

The most effective clause here is administrative rather than legal: every account is opened in your company’s name from day one, including the model API account, the cloud tenancy, the repository and the domain. A supplier holding those in its own name controls your exit whatever the contract says.

Then list the exit deliverables and the formats they come in: prompts, weights, index, evaluation set, documentation and runbooks, plus transition assistance for a set number of days at a pre-agreed rate. Source code escrow earns its fee only where the supplier hosts the system, and only in verified form, where the escrow agent checks that the deposit actually builds. The EU Data Act’s switching provisions, in force since September 2025, help with cloud providers, but they will not rescue you from a small agency sitting on your credentials.

Liability, indemnities and insurance

Small-supplier templates often cap total liability at a month or two of fees. Push for a cap of at least the total contract value, with higher caps, or no cap at all, for breaches of confidentiality, data protection failures and third-party IP infringement.

Ask for an IP indemnity that covers claims arising from the outputs. Several model providers publish copyright indemnity commitments, but those run to their direct customer, usually your supplier, and are conditional on using the provider’s safety features, so require the benefit to be passed through to you. Then ask for the insurance certificates: professional indemnity and cyber.

Red flags in a supplier’s draft

• “The Supplier retains all intellectual property in the Deliverables.”
• “The Supplier may use Customer Data to improve its products and services.”
• Deemed acceptance after a handful of days, with no retest right.
• “Reasonable endeavours” as the only quality standard in the document.
• No named sub-processors, and no notice when they change.
• Liability capped at one month’s fees, with no carve-outs.
• Accounts and API keys held in the supplier’s name.
• “Compliance with AI regulation is the Customer’s responsibility,” with no documentation duty attached.

Where to get a usable starting draft

You do not have to write this from scratch. The European Commission’s model contractual clauses for AI procurement (MCC-AI) are heavier than an SME needs, but they work well as a clause checklist. ISO/IEC 42001:2023 gives you something concrete to demand of a larger supplier. The NIST AI Risk Management Framework supplies the vocabulary for the risk schedule.

Then spend the legal budget where it earns its keep: the schedules. Scope, acceptance, SLA, data and exit decide an SME contract. The boilerplate body does not.

Before you sign: the one-page check

1. Can you point to the frozen evaluation set and the pass threshold in a schedule?
2. Does the IP clause list prompts, weights, embeddings and evaluation data separately?
3. Is every sub-processor named, with a right to notice when the list changes?
4. Does the contract say who is provider and who is deployer under the AI Act?
5. Are the API and cloud accounts in your company’s name?
6. Is the final tranche released only after acceptance and a live stability period?

If you cannot answer all six from the document in front of you, you are not looking at an AI implementation contract yet. You are looking at a quote.

Educational material, not legal advice. As of 2026 — interpretation of the EU AI Act may change.