AI Contracts: What Really Needs to Be in Them — Performance, Liability, IP, Data Protection & SLA

As of: June 2026 · Leon Lotz, commercial lawyer

The most dangerous moment in an AI project isn’t in the code, it’s in the contract: you sign the provider’s standard terms — and, often without noticing, take on the full risk for hallucinations, data leaks, and outages. Provider terms are written from exactly one perspective: the provider’s. They disclaim liability, leave the output rights open, and promise only “efforts” for operations.

A solid AI contract, by contrast, governs five points cleanly: (1) the performance owed, (2) liability for errors and hallucinations, (3) the IP and usage rights in the AI output, (4) data protection/DPA, and (5) the SLA (availability). Since 2026, a sixth has been added: the obligations under the AI Regulation. What matters, and who bears which risk, is laid out here — as negotiable points, not as catch-all formulas.

The five (from 2026: six) building blocks interlock: anyone who negotiates liability without also considering the control layer and the AI Act obligations leaves a flank exposed.

Most articles on this topic come from law firms. They explain the clauses well, but they don’t build the AI solution themselves. I do both: law and code from a single source. That’s why this isn’t only about which clause belongs in the contract, but also about what it means technically — for example, how an SLA availability of 99.9% is actually measured and logged, or how to cleanly delineate AI output from your own work within the pipeline. If you want to know why this dual qualification makes the difference, the reasoning is at Why a commercial lawyer + developer.

AI contract, usage agreement, development agreement — what are we talking about?

“AI contract” refers to two very different setups:

• (a) Procurement/usage agreement for a finished AI service (SaaS or API). You use an existing model. Here you usually negotiate against pre-formulated standard terms.
• (b) Development agreement for a custom-built AI solution (Werkvertrag, German contract for work, or Dienstvertrag, German service contract). Here the deliverable is created for you — and you can shape the contract from the outset.

The five building blocks apply to both cases, but with different weighting. If you procure a finished service, you mainly fight over liability and data training. If you commission development, you must define the scope of work, acceptance, and output rights cleanly. Keep this distinction in mind — it determines which clauses are critical for you.

Building block 1 — Performance: What exactly does the provider owe?

The most common point of dispute arises because no one ever precisely defined what the AI is actually supposed to do. “An AI that writes our proposals” is not a defined scope of work, it’s a wish. The contract needs a scope-of-work catalog: which functions, which data sources, what accuracy, which languages, which integrations? In doing so, separate standard AI (the model as it is) from customization (adaptation, fine-tuning, interfaces) — the two carry different risks and costs.

Werkvertrag or Dienstvertrag? Classifying the AI project correctly

This question has far-reaching consequences but is often only touched on. The difference lies in the owed result:

Contract type	What is owed …	Consequence for you
Werkvertrag (contract for work, secs. 631 ff. BGB)	a concrete result (the finished, working system)	acceptance + warranty/defect rights apply
Dienstvertrag (service contract, secs. 611 ff. BGB)	only the effort/the activity	no owed result, hardly any defect rights
License	grant of use of an existing product	maintenance/updates governed separately

Rule of thumb: anyone who wants a measurable result (acceptance, warranty) should push for a Werkvertrag (contract for work). Providers like to sell AI projects as a Dienstvertrag (service contract) because then they owe no result. For exploratory AI projects, a pilot phase / proof of concept (often 1–3 months) makes sense before you commit long term — precisely because, with generative AI, only testing reveals whether the hit rate is fit for practice.

How such a PoC is set up cleanly and contractually fenced in is something I describe in detail in Setting up an AI pilot project right.

Building block 2 — Liability: Who bears the hallucination and error risk?

This is where the biggest hidden risk lies. The standard terms of AI providers disclaim liability almost across the board: output is provided “at your own risk,” and liability for malfunctions and incorrect results (“hallucinations”) is shifted onto you as the user. The problem: if you reuse unchecked AI output and damage results, you are left standing alone.

But the legal guardrails have limits. In standard terms and conditions, liability for intent and gross negligence cannot be excluded — this is governed by sec. 309 no. 7 lit. b BGB; nor can liability for injury to life, body, and health (lit. a). Excessive blanket disclaimer clauses are challengeable under the content review of standard terms (secs. 305 ff. BGB) and are often invalid. A clause that excludes all liability generally does not survive scrutiny.

What you should negotiate in:

• A reasonable liability cap (e.g., tied to the annual fee) instead of a total disclaimer.
• A clear human-in-the-loop allocation of responsibility: who reviews the AI output before it takes effect? This is also an AI Act obligation (more on this below, Art. 26 AI Act).
• Express confirmation that intent and gross negligence remain unaffected.

An important point for the standard of care: that AI output is error-prone is common knowledge in 2026. Anyone who ignores known weaknesses and forgoes their own review entirely quickly acts grossly negligently themselves by an objective standard. The control layer is therefore not just technology, but liability mitigation — how to actually build it (thresholds, escalation, logging of sign-offs) is at Securing hallucinations: control-layer design.

Building block 3 — IP & usage rights: Who owns the AI output?

In short: pure AI output is, as a rule, not protected by copyright in Germany. Sec. 2(2) UrhG (German Copyright Act) requires a personal intellectual creation — and a model is not a natural person. Protection can only arise if a person shapes the output so formatively that there is an independent creative contribution; merely selecting from several AI suggestions or correcting obvious errors is not enough under current case law.

From this follows the most important consequence for the contract: a clause stating “the provider transfers the copyright in the output” has no effect if no copyright exists at all. Instead, govern contractual usage rights — who may use the output how, where, for how long, and exclusively or not. This is a matter of contract law, not copyright law.

Equally critical: the input and training-data clause. May the provider use your inputs to train its own models? If so, you potentially disclose trade secrets — and protection under the German Trade Secrets Act (GeschGehG) lapses the moment information is no longer secret. Negotiate a training opt-out and review enterprise plans that contractually exclude training with your data.

Note: The legal situation on AI copyright is evolving. The line described here (no protection for pure output, protection where there is sufficient human shaping) is the prevailing view, but it is not a conclusive standard for all cases.

Building block 4 — Data protection: DPA, third-country transfer & DPIA in the contract

As soon as the AI provider processes personal data on your behalf, you need a data processing agreement (DPA) under Art. 28 GDPR — and you need it before the first processing begins. Without a valid DPA, any transfer of data to the service provider is unlawful, regardless of whether it is an AI tool, a cloud service, or a classic IT service provider. Violations can be penalized under Art. 83 GDPR with fines of up to EUR 20 million or 4% of worldwide annual turnover (whichever is higher) as the ceiling.

Further points that belong in the contract or DPA:

• Third-country transfer (Art. 44 ff. GDPR): many AI providers process data in the USA. Clarify data residency and transfer safeguards.
• DPIA: where high risk is likely, a data protection impact assessment (Art. 35 GDPR) is required — readily the case with extensive AI-supported profiling.
• Sub-processors & audit rights: who provides services to the provider, and may you audit this?

Where the data is physically processed is no formality: whether you choose an EU-hosted or a US model shifts third-country risk and negotiating room considerably — see EU-hosted vs. US LLMs: data sovereignty. The DPIA itself I cover in depth at DPIA for AI systems.

Building block 5 — SLA: Availability, response times, consequences

A service level agreement (SLA) turns a vague promise into an enforceable obligation. An AI SLA must contain at least: the availability (e.g., 99.9% per year), response and recovery times, escalation tiers, the reporting/measurement — and, above all, the consequences of falling short (price reduction, service credits, or a contractual penalty). A clause stating “the provider endeavors to achieve high availability” is worth nothing, because it owes nothing.

This is where technical understanding pays off: 99.9% sounds good — but how is availability measured and logged? 99.9% per year allows about 8.8 hours of downtime; 99.9% per month is only about 43 minutes. Define the measurement interval, the measurement point, and what counts as “downtime.” With AI services, additional peculiarities arise that classic SLAs do not know:

• Model deprecation: what happens if the provider deprecates or replaces your model? Output and behavior can change.
• Rate limits and latency: an API can be “available” yet unusably slow — also govern response times and throughput.

Data exit & vendor lock-in

Think about the end from the start: how do you get your data back and out of the contract? The EU Data Act strengthens your position here. Providers of data processing services must enable switching contractually and technically — with exit clauses, data export in common formats, and a gradual phase-out of switching fees; from January 2027, switching fees are generally prohibited (as of June 2026). Even so, anchor concretely: free data export, formats, deadlines, and a clean termination path. Which technical and contractual levers avoid lock-in beyond the Data Act is at Avoiding vendor lock-in with AI.

Building block 6 (mandatory in 2026) — The AI Regulation in the contract

The EU AI Act introduces contractual responsibilities that many older contract templates do not reflect:

• Art. 25 AI Act: responsibilities along the value chain — who bears which obligation in the chain should be mirrored contractually.
• Art. 26 AI Act: deployer obligations, in particular human oversight — this dovetails directly with the liability and control layer from building block 2.
• Art. 4 AI Act: the obligation to ensure AI literacy among those involved. (Note on factual accuracy: Art. 4 is not backed by its own fine provision.)

In practice, this means: include a compliance/adaptation clause that governs who makes the necessary changes in the event of legal amendments and who bears the costs. This is especially important right now, because the timeline is in flux: with the Digital Omnibus package (presented by the EU Commission on 19 November 2025, politically agreed by the EU bodies on 7 May 2026, with final adoption still pending as of June 2026), key high-risk deadlines were postponed — for standalone high-risk systems under Annex III to 2 December 2027, and for systems embedded in products to 2 August 2028. The transparency obligations (labeling of AI-generated content) are to become binding from 2 August 2026. Since the legal position is not yet final, an adaptation clause belongs in the contract all the more.

Checklist — What belongs in every AI contract

1. Scope of work precisely: functions, data sources, accuracy, customization vs. standard.
2. Contract type clarified: Werkvertrag (result), Dienstvertrag (effort), or license — with acceptance and warranty where a result is owed.
3. Pilot phase/PoC before a long-term commitment.
4. Liability: cap instead of total disclaimer; intent/gross negligence unaffected (sec. 309 no. 7 BGB); human-in-the-loop defined.
5. IP: contractual usage rights in the output (not “copyright transfer”); exclusivity and reuse governed.
6. Training data: opt-out against the use of your inputs for training; trade-secret protection.
7. Data protection: DPA under Art. 28 GDPR before the first processing; third country, DPIA, sub-processors, audit rights.
8. SLA: measurable availability, response/recovery times, reporting, consequences of falling short.
9. Data exit: free export, formats, termination path (EU Data Act).
10. AI Act clause: responsibilities (Art. 25/26 AI Act) and adaptation in the event of legal change.

Clause-risk table: typical provider clauses and what to counter with

Building block	Typical provider clause	Risk for you	What to negotiate in
Liability	blanket disclaimer	you bear the hallucination/error damage	cap + human-in-the-loop; intent/gross negligence unaffected
IP/output	”output at your own risk”	output possibly unprotected/disputed	usage rights + exclusivity made explicit
Data/training	inputs may be used for training	loss of trade secret/GDPR compliance	training opt-out + DPA
SLA	”reasonable efforts”	no enforceable availability	measurable uptime + consequences of falling short
Exit	no/expensive data return	vendor lock-in	free data export + termination path

The examples show typical patterns, not a binding contract template. Every clause must be assessed in the individual case.

FAQ

Are the AI provider’s standard terms enough?

As a rule, no. Provider terms are written from the provider’s perspective: they largely disclaim liability, often leave output rights and data training open, and promise only “efforts” for the SLA. For real protection, liability, IP, data protection, and the SLA must be renegotiated or supplemented.

Who owns the AI-generated output?

Pure AI output is usually not protected by copyright in Germany, because there is no personal intellectual creation within the meaning of sec. 2(2) UrhG (German Copyright Act). Protection can only arise where there is a sufficient level of human creative input. For that reason, govern contractual usage rights instead of a — often ineffective — copyright transfer.

Who is liable if the AI delivers incorrect results?

Providers usually disclaim liability contractually and shift the risk onto the user. But this disclaimer has limits: intent and gross negligence cannot be excluded in standard terms under sec. 309 no. 7 BGB, and excessive clauses are invalid. What matters in practice is whether you have placed a human review upstream.

Do I need a DPA in the AI contract?

Yes, if the provider processes personal data on your behalf — and specifically under Art. 28 GDPR before the first processing, in writing or electronically. Without a valid DPA, the data transfer is unlawful and subject to fines.

Is an AI project a Werkvertrag or a Dienstvertrag?

It depends on the owed result. If a concrete, working result is owed, that points to a Werkvertrag (contract for work) with acceptance and warranty. If only an activity is owed, it is a Dienstvertrag (service contract) without liability for the result. The classification determines your defect rights.

---

Law + code from a single source. The most expensive and trust-sensitive step of an AI project — signing the contract — is not one you should leave to the provider alone. If you want to have an AI contract reviewed or have a legally sound custom solution developed, get in touch for an initial consultation. From the commercial lawyer who also builds the solution.

This is general information, not legal advice for the individual case. As of: June 2026.

Sources — as of 03.06.2026

• § 309 BGB — Clause prohibitions without the possibility of evaluation: https://www.gesetze-im-internet.de/bgb/__309.html
• Liability & AI — Who is liable for AI damage in 2026?: https://anwalt-tomas-krause.de/haftung-ki/
• AI & copyright 2026 (SRD Rechtsanwälte): https://www.srd-rechtsanwaelte.de/blog/ki-urheberrecht-2025-was-jetzt-rechtlich-wichtig-ist
• AI and copyright in Germany 2026 (windweiss.de): https://www.windweiss.de/ratgeber/ki-urheberrecht/
• AI logos and copyright — Munich Local Court ruling 2026 (lawschoolgermany.de): https://lawschoolgermany.de/blogs/blog-recht-ditigal/ki-generierte-werke-urheberrecht-ag-muenchen-2026
• Data processing agreement (DPA) for AI services (Plotdesk): https://plotdesk.com/magazin/auftragsverarbeitungsvertrag-avv-ki-dienste
• Art. 28 GDPR — Processors (dsgvo-gesetz.de): https://dsgvo-gesetz.de/art-28-dsgvo/
• EU AI Act 2026 — What the Digital Omnibus changes for SMEs (allbytes.de): https://www.allbytes.de/blog/eu-ai-act-digital-omnibus-kmu/
• AI ban from December 2026 — EU sets deadlines for high-risk systems (börse-express): https://www.boerse-express.com/news/articles/ki-verbot-ab-dezember-2026-eu-setzt-fristen-fuer-hochrisiko-systeme-917491
• EU AI Act timeline (DataGuard): https://www.dataguard.de/eu-ai-act/timeline
• Art. 25 AI Act — Responsibilities along the value chain: https://ai-act-law.eu/de/artikel/25/
• EU Data Act cloud switching (NMMN): https://nmmn.com/eu-data-act-cloud-switching/
• Service level agreement — the 6 most important components (SRD Rechtsanwälte): https://www.srd-rechtsanwaelte.de/blog/service-level-agreement-sla
• Norton Rose Fulbright — Generative AI: structuring AI contracts with legal certainty: https://www.nortonrosefulbright.com/de-de/wissen/publications/64f48ffc/generative-ai-ki-vertrage-rechtssicher-gestalten