Contracts and SLAs for AI: Assigning Responsibility Clearly

Artificial intelligence systems are rarely built from scratch by the organisations that use them. They are assembled, integrated, and operated through a complex chain of suppliers, integrators, cloud providers, and data partners. When an AI system causes harm, produces inaccurate outputs, or exposes personal data, European law does not simply ask what happened; it asks who is responsible and on what legal basis. Contracts and Service Level Agreements (SLAs) are the instruments that translate regulatory obligations and operational risks into a coherent allocation of liability between commercial parties. They are not merely administrative paperwork; they are the governance layer that determines whether a business can absorb an AI incident, recover its losses, or defend its compliance posture.

This article examines how contracts and SLAs should be structured to allocate responsibility for AI systems across the European legal landscape. It combines perspectives from legal analysis, regulatory implementation, and practical AI systems operations. The focus is on what can be contractually agreed, what must be preserved by law, and what typically fails when disputes arise. It distinguishes between EU-level frameworks and national implementations, and it highlights how different Member States approach remedies, liability, and enforcement in practice.

Regulatory Context: Why Contracts Matter for AI Governance

European regulation increasingly shapes the private law of supply contracts. The AI Act (Regulation (EU) 2024/1689) imposes obligations on providers, deployers, importers, and distributors, and it creates conformity assessments, documentation duties, and post-market monitoring. The Product Liability Directive (Directive 85/374/EEC) and its proposed Product Liability Regulation adjust the rules for compensation when products, including AI systems, are defective. The GDPR sets strict duties for data controllers and processors, with significant penalties for breaches. Sectoral rules—such as the Medical Device Regulation, Financial Services requirements (e.g., DORA, MiCA), and public procurement law—overlay additional constraints.

These frameworks do not replace private contracts; they inform them. A contract that ignores regulatory duties is likely to be unenforceable in key parts, or to leave one party exposed to risks it believed it had transferred. Conversely, a contract that aligns with regulatory roles can clarify who must maintain technical documentation, who is responsible for incident reporting, and how audit rights are exercised. In practice, the most resilient contracts treat compliance as a shared operational process, not a one-time warranty.

Allocating Responsibility: Roles, Functions, and Boundaries

Responsibility is not a single label; it is a matrix of duties that map to roles defined by law and by the contract. The AI Act distinguishes between providers, deployers, importers, and distributors. In commercial arrangements, a supplier may be the provider of a high-risk AI system, while the customer is the deployer. The contract must reflect this, but it must also go further by identifying the operational boundaries.

Provider versus Deployer Obligations

The provider of a high-risk AI system is responsible for design, conformity assessment, technical documentation, quality management, and post-market monitoring. The deployer is responsible for using the system as intended, ensuring human oversight, monitoring for risks in the operational context, and notifying the provider of incidents. A contract that simply states “the supplier is the provider” is insufficient. It should specify:

• Who maintains the technical documentation and updates it when the model or data changes.
• Who performs the conformity assessment (or engages a notified body) and who bears the cost.
• Who registers the system in the EU database and keeps the registration current.
• Who provides instructions for use and training to the deployer’s staff.
• Who monitors for model drift and performance degradation in production.

In many supply arrangements, the supplier retains control over the model weights or the core algorithm, while the deployer controls the input data and the operational environment. The contract should delineate these spheres of control. If a defect arises from data provided by the deployer, the provider may not be liable for that defect, but the provider remains responsible for the system’s robustness against foreseeable data variability. Conversely, if the deployer modifies the model or uses it outside the intended purpose, the provider’s liability may be limited, but the deployer may assume broader duties under the AI Act.

Subcontracting Chains and “White-Label” AI

AI systems often rely on third-party components: foundation models, cloud infrastructure, data pipelines, or specialised libraries. A supplier may resell a third-party model under its own brand. The contract should address:

• Flow-down obligations: the supplier must ensure that its own vendors accept equivalent duties regarding compliance, audit, and incident reporting.
• Transparency: the customer must be informed of the use of third-party components and their risk profile.
• Change management: the supplier must notify the customer if the underlying model or infrastructure changes in a way that could affect safety, performance, or regulatory status.

In “white-label” scenarios, the reseller may be the legal provider under the AI Act, even if it does not control the model. This creates a need for strong indemnities, insurance, and access rights to the original provider’s documentation. European regulators are likely to scrutinise such arrangements closely, especially for high-risk systems.

Warranties and Performance Commitments

Traditional software warranties focus on functionality and defects. AI warranties must address probabilistic behaviour, data dependencies, and context sensitivity. A contract that promises “99.9% accuracy” is likely misleading and unenforceable if accuracy is not defined, measured, and scoped to a specific use case.

Defining “Accuracy” and “Performance”

Parties should define performance metrics with precision. For classification tasks, this may include precision, recall, F1 score, or ROC-AUC, with clear definitions of the positive and negative classes. For generative systems, it may include factual correctness rates, hallucination rates, or policy compliance rates (e.g., refusal of harmful prompts). The contract should specify:

• The dataset(s) used to measure performance, including representativeness and time relevance.
• Acceptable performance ranges and the conditions under which they must be maintained.
• How performance is measured in production (e.g., rolling windows, sampling strategies).
• How changes in input data distribution affect the warranty.

It is advisable to avoid unconditional warranties about “bias-free” outputs. Instead, the contract can warrant that the system has been developed in accordance with good practices, that bias mitigation measures have been applied, and that the deployer will be provided with documentation describing the system’s limitations.

Regulatory Compliance Warranties

Parties often request a warranty that the system “complies with all applicable laws.” This is too broad to be meaningful. A better approach is to warrant specific, verifiable obligations:

• The supplier warrants that, as of delivery, the system conforms to the AI Act’s requirements for its risk classification and intended purpose.
• The supplier warrants that the training data sources and processing do not violate applicable IP or data protection laws to the best of its knowledge and subject to disclosed limitations.
• The deployer warrants that it will use the system only within the intended purpose and will provide necessary information for conformity.

Where the system is high-risk, the supplier should warrant that it has completed the relevant conformity assessment and that the technical documentation is available for inspection. The deployer should warrant that it will perform the required human oversight and monitoring.

Disclaimers and Limitations

European law limits the ability to exclude liability for death or personal injury caused by defective products. In B2B contexts, parties have more freedom to allocate economic risk, but terms that are “unfair” under the Unfair Contract Terms Directive (and its upcoming replacement) may be void. Disclaimers that attempt to negate liability for regulatory non-compliance are risky; regulators may impose fines regardless of contractual limitations. A balanced approach is to cap liability for indirect and consequential losses while preserving remedies for regulatory breaches, data protection incidents, and IP infringement.

Audit Rights and Transparency Obligations

Audit rights are the practical mechanism for verifying compliance. In AI supply chains, audits must cover not only code and infrastructure, but also data, model evaluation procedures, and governance documentation.

Scope and Frequency of Audits

Parties should agree on:

• Who can audit: the customer, an independent third party, or a regulator.
• What can be audited: technical documentation, training data provenance, model evaluation reports, incident logs, change management records, and security controls.
• When audits occur: on request, at defined intervals, or after significant changes.
• Confidentiality: how trade secrets and personal data will be protected during audits.

In practice, suppliers may resist broad data audits due to IP or privacy concerns. A pragmatic compromise is tiered access: initial documentation review, followed by targeted inspections if risks are identified. For high-risk systems, the contract should explicitly permit audits required by the AI Act or sectoral regulators.

Reporting Obligations

Reporting duties arise from multiple sources. The AI Act requires providers of high-risk systems to report serious incidents to national authorities. GDPR mandates notification of personal data breaches to supervisory authorities and affected data subjects. Financial services rules (e.g., DORA) impose incident reporting to financial regulators. Contracts should specify:

• Who is responsible for detecting incidents (e.g., model drift, data leakage, misuse).
• Timelines for escalation to the other party (e.g., within 24 hours of detection).
• Responsibility for regulatory notifications, including drafting, review, and submission.
• Cooperation duties: providing evidence, facilitating root cause analysis, and implementing remediation.

Clear reporting chains reduce the risk of missed deadlines and inconsistent narratives to regulators.

Data Governance, Provenance, and IP

Data is often the most contentious element in AI contracts. The legality of training data affects both IP exposure and regulatory compliance.

Training Data and Rights of Use

Suppliers should disclose, at a high level, the provenance of training data. The contract should include warranties that the supplier has the necessary rights to use the training data and that personal data has been processed lawfully. For deployers providing fine-tuning data, the contract should specify:

• Whether the data is used solely to train a model for the deployer or becomes part of a shared model.
• How the model’s weights or embeddings might contain derivatives of the deployer’s data.
• What safeguards prevent cross-contamination between different customers’ data.
• Retention and deletion rights, including “right to be forgotten” implementation under GDPR.

In some jurisdictions, such as France (CNIL guidance) and Germany, the use of personal data for training may require explicit consent or a robust legitimate interest assessment. Contracts should not assume that “anonymised” data is automatically compliant; re-identification risks must be assessed.

Open-Source Components and Licenses

Many AI systems incorporate open-source libraries or models. The contract should require disclosure of these components and their licenses. Copyleft licenses may impose obligations to share modifications. Suppliers should warrant that open-source use does not contaminate proprietary code and that compliance obligations are met.

Limitations of Liability and Indemnities

Liability allocation is the heart of risk management. European law distinguishes between contractual liability and statutory liability (e.g., product liability, data protection fines). The contract can allocate economic risk, but it cannot override statutory duties.

Product Liability and Defective Products

Under the Product Liability Directive (and the proposed Regulation), a product is defective if it does not provide the safety a person is entitled to expect. For AI, this includes foreseeable misuse and the ability to control risks. Contracts can limit liability for economic losses, but they cannot exclude liability for personal injury caused by defects. The supplier’s liability for defects may be limited if the deployer modified the system or used it outside the intended purpose. The contract should define the intended purpose precisely.

Indemnities

Indemnities are common for IP infringement and regulatory fines. A supplier may indemnify the customer if a third party claims that the model infringes copyright or if the supplier’s non-compliance causes a regulatory fine. Conversely, the customer may indemnify the supplier if misuse or unauthorised modification causes harm. Indemnities should be mutual and clearly scoped. They should also include cooperation duties in defending claims.

Force Majeure and Change in Law

AI systems are sensitive to changes in law (e.g., new data restrictions) and in third-party services (e.g., API changes). Contracts should address:

• Force majeure: what events excuse performance, and for how long.
• Change in law: who bears the cost of compliance with new regulations.
• End-of-life: rights to terminate if a model or service becomes non-compliant or unsupported.

SLAs: Metrics, Monitoring, and Remedies

SLAs translate performance expectations into measurable targets and remedies. For AI systems, SLAs must be designed with care to avoid perverse incentives and to reflect the probabilistic nature of the technology.

Key SLA Metrics

Typical metrics include:

• Availability: uptime of the service, but also availability of model endpoints and data pipelines.
• Latency: response times for inference, with acceptable ranges for different workloads.
• Accuracy: defined as above, with measurement methodology and sampling frequency.
• Fairness: monitoring for disparate impact across protected groups, with thresholds and remediation steps.
• Data quality: error rates in input data, completeness, and timeliness.

SLAs should also include “health checks” for model drift and calibration. If the model’s performance degrades beyond agreed thresholds, the supplier should be obligated to retrain, recalibrate, or provide a corrective update.

Remedies and Service Credits

Remedies may include service credits, extended service periods, or termination rights. For AI systems, monetary credits may be insufficient if the harm is reputational or regulatory. Contracts should include:

• Root cause analysis obligations after incidents.
• Corrective action plans with timelines.
• Escalation to termination if repeated breaches occur.
• Right to engage third-party auditors if SLA breaches are disputed.

It is advisable to avoid “accuracy guarantees” that trigger automatic penalties; instead, tie remedies to documented failures to follow agreed measurement procedures or to address known issues.

Public Sector Contracts and Procurement Rules

Public authorities deploying AI must comply with public procurement law and the specific obligations of the AI Act. EU procurement directives require transparency, equal treatment, and proportionality. Contracts for AI systems in the public sector should include:

• Clear specifications of the intended purpose and risk classification.
• Access rights for the contracting authority to technical documentation and audit logs.
• Data sovereignty clauses: data remains under public control, with no secondary use by the supplier.
• Explainability requirements: the supplier must provide means for the authority to explain decisions to affected individuals.
• Exit strategies: data portability and the ability to switch providers without lock-in.

Some Member States (e.g., France, Germany) have additional guidance for public sector AI procurement, emphasising transparency and human oversight. Contracts should reflect these national practices.

Insurance and Financial Assurance

Insurance is a practical complement to contractual allocation. Cyber insurance and professional indemnity policies may cover AI-related incidents, but exclusions are common. Parties should:

• Verify that policies cover AI-specific risks (e.g., algorithmic errors, data misuse).
• Ensure that the supplier maintains adequate coverage for product liability and cyber risks.
• Consider specialised AI liability policies where available.
• Align contract requirements (e.g., security controls) with insurance policy conditions.

What to Avoid in Vendor Promises

Some contractual clauses are common but ineffective or risky in AI contexts.

• “Guaranteed bias-free outputs”: Bias is context-dependent; absolute guarantees are misleading and may violate consumer protection rules.
• “Fully compliant with all laws”: Overbroad and unverifiable; specify the relevant laws and obligations.
• “Training data is completely anonymised”: Difficult to prove; instead, warrant that reasonable measures were taken and disclose residual risks.
• “No third-party dependencies”: Rarely true; disclose dependencies and manage licences.
• “Unlimited liability for any misuse”: Unfair and likely unenforceable; define misuse and allocate responsibility.
• “Accuracy measured on a single test set”: Insufficient for production; require ongoing monitoring and reporting.

Vendor promises should be specific, measurable, and tied to documented processes. If a promise cannot be measured, it should be reframed as a commitment to follow best practices and provide transparency.

National Implement