# EU AI Case Law Watch: Liability and Automated Decision‑Making (What Courts Actually Enforce)

Date: 2026-08-12

AI liability is not waiting for the EU to invent an entirely new tort system.

Courts are already allocating responsibility using existing legal tools: GDPR for automated decision-making and transparency, contract law for risk transfer, and national tort principles for harm. The EU AI Act adds governance obligations and enforcement structure—but in disputes, judges still ask a simpler question:

**Who controlled what, who relied on what, and what should have been prevented?**

<!--more-->

## Start With the GDPR: It Already Regulates High‑Impact Automated Decisions

If your AI system influences whether someone gets a loan, a job interview, insurance pricing, healthcare access, or a public benefit, you are already in the GDPR’s core risk zone—regardless of whether your product is labeled “AI.”

Two GDPR concepts are repeatedly litigated:

- **Article 22 GDPR**: restrictions on *solely automated* decisions producing legal or similarly significant effects.
- **Article 15(1)(h) GDPR**: the access right to obtain “meaningful information about the logic involved” in automated decision-making (plus the significance and envisaged consequences).

The most important recent line of CJEU case law comes from the credit‑scoring sector—because it has the cleanest fact pattern: a score, a decision, and measurable consequences.

## Case Law Anchor #1: SCHUFA (C‑634/21) — When “Scoring” Becomes a Decision

In the SCHUFA case (C‑634/21), the CJEU addressed when an automated credit score crosses the line into “automated individual decision‑making” under Article 22 GDPR.

The key practical point: **a service provider can be caught by Article 22 GDPR when its automated score is strongly relied upon by a third party to establish, implement, or terminate a contract with an individual**—even if the provider insists it only produces a “recommendation” and the third party makes the “final decision.”

Matheson’s analysis captures the operational implication: Article 22 compliance risk may attach not only to the downstream decision‑maker, but to the upstream scoring provider where the score is decisive in practice.  
See: [Matheson — SCHUFA (C‑634/21) summary and implications](https://www.matheson.com/insights/cjeu-delivers-important-decision-on-automated-decision-making-under-the-gdpr/).

### Why this matters beyond credit scoring

Replace “credit score” with:

- recruitment ranking scores
- “risk of fraud” flags that block accounts
- insurance risk pricing models
- healthcare triage or prioritisation tools

If your customer “draws strongly” on your score, you may be treated as part of the automated decision system—not just a neutral analytics vendor.

> **Key takeaway:** If your output is effectively decisive, courts can treat you as making the decision—even if you don’t sign the rejection letter.

## Case Law Anchor #2: D&B / Transparency vs Trade Secrets (C‑203/22)

Automated decisions don’t only raise “decision” questions. They raise “explanation” questions.

In Case C‑203/22, the CJEU addressed the balance between transparency duties (what the data subject can learn about the logic) and the protection of secrets. A practical summary from Bird & Bird emphasises several points that matter for real systems:

- Data subjects are entitled to **intelligible** information about key parameters and their influence.
- Controllers cannot satisfy the obligation with a complex formula or generic statements alone.
- Trade secrets are relevant, but **cannot be invoked as an absolute refusal**; the controller may need to disclose information to a supervisory authority or court so it can balance rights and determine what must be provided.  
See: [Bird & Bird — C‑203/22 transparency vs secrets](https://www.twobirds.com/en/insights/2025/cjeu-decision-on-algorithmic-transparency-and-secret-protection-(cjeu-c-20322)).

### “Meaningful” explanation is an operations problem

This is where many AI programs fail. They build models, then realise the UI and support processes cannot provide:

- what inputs mattered most in *this case*
- what would have changed the outcome
- how a human can contest the result

If your explanation capability depends on your ML engineer being online, your compliance posture is fragile.

## “Meaningful Human Review” Is Not a Checkbox

Organisations often respond to Article 22 and AI‑risk arguments by saying: “A human reviews the output.”

Courts and regulators increasingly treat this as a factual claim that must be proven:

- Is the human empowered to override, or only to rubber‑stamp?
- Do they have enough context to disagree (inputs, confidence, error modes)?
- Is intervention logged (who overrode, why, what changed)?
- Is review timely, or after harm occurs?

If the human cannot realistically contradict the model, you have “ceremonial oversight,” not meaningful review.

## Where Liability Debates Are Heading (AI Act + Civil Liability Instruments)

The AI Act’s risk tiers and obligations provide governance scaffolding, especially for high‑risk systems and certain transparency duties. The Commission’s overview is the best short reference.  
See: [European Commission AI Act overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) and the official text [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng).

Separately, the EU has been exploring how to adjust civil liability rules for AI—primarily to address proof and causation challenges. The Commission’s AI liability page (built around the AI Liability Directive proposal) frames the policy objective: ensure harmed persons have comparable protection and that justified claims aren’t blocked by AI opacity.  
See: [EU Commission — liability rules for AI](https://commission.europa.eu/topics/business-and-industry/doing-business-eu/contract-rules/digital-contracts/liability-rules-artificial-intelligence_en).

### The open questions courts will keep answering

1. **Causation in mixed human+AI systems**  
   When AI “contributes” to harm, how much reliance is enough to allocate responsibility upstream?
2. **Responsibility mapping in supply chains**  
   Provider vs deployer vs integrator: who had the last clear chance to prevent the harm?
3. **Proof burdens and access to evidence**  
   Can a claimant obtain enough evidence to show that an automated decision was unfair, discriminatory, or unlawfully made?

## Practical Allocation of Responsibility (Provider, Deployer, User)

If you want a board‑ready responsibility model, use this simplified split:

- **Provider (model / system builder)**: training and design choices; known limitations; documentation; baseline safety controls; update mechanisms.
- **Deployer (enterprise user of the system)**: purpose limitation; governance; human oversight; monitoring; contestability; local policy enforcement.
- **User (frontline operator)**: correct use; escalation; evidence capture; compliance with prompts and workflows.

Courts don’t care about your org chart. They care about **control** and **foreseeability**:

- Who chose to automate?
- Who decided the threshold?
- Who ignored known error modes?
- Who could have detected drift earlier?

## What to Do Now (Before the Dispute)

### 1) Map “significant effect” decisions

List every place your systems influence legal or similarly significant outcomes:

- access (approve/deny)
- pricing (insurance, credit)
- prioritisation (healthcare, services)
- surveillance or sanctions (account restrictions)

If it’s in that list, treat it as Article 22‑adjacent even if you believe a “human is in the loop.”

### 2) Prove oversight with logs

Build audit trails that show:

- what the model output was
- who reviewed it
- whether it was overridden
- what evidence was considered

### 3) Build explanation capability into the product

Not “explainability research.” Practical explanation outputs:

- key parameters/inputs for the outcome
- sensitivity (“if X were different, outcome changes”)
- a contestability pathway a real person can use

### 4) Fix contracts to match reality

If your customer “draws strongly” on your score/output, your contract should reflect:

- cooperation on regulatory inquiries and data subject requests
- incident reporting and model update duties
- indemnities that align with the actual risk surface (not just generic boilerplate)

## Closing

EU AI liability is not coming “someday.” It is already here—through the GDPR and the courts’ insistence that automation must be contestable, explainable, and genuinely overseen.

The lesson from SCHUFA and C‑203/22 is operational:

- If your output is decisive, you may be treated as making the decision.
- If you can’t explain your logic in an intelligible way, secrets won’t save you.
- If your oversight is ceremonial, judges will treat it as absent.

That is how EU case law converts AI governance from a policy statement into a compliance obligation you must be able to prove.

---

### Suggested reading (sources)

- CJEU / SCHUFA (C‑634/21) analysis: https://www.matheson.com/insights/cjeu-delivers-important-decision-on-automated-decision-making-under-the-gdpr/  
- CJEU C‑203/22 transparency vs secrets: https://www.twobirds.com/en/insights/2025/cjeu-decision-on-algorithmic-transparency-and-secret-protection-(cjeu-c-20322)  
- EU AI Act overview: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai  
- EU AI Act text (EUR‑Lex): https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng  
- EU Commission: AI liability rules / AILD proposal: https://commission.europa.eu/topics/business-and-industry/doing-business-eu/contract-rules/digital-contracts/liability-rules-artificial-intelligence_en