AI Liability Framework

PLD (2024/2853) · nationales Delikts-/Vertragsrecht · DSGVO & Antidiskriminierung · AI-Act als Beweismassstab · Dokumentation als Haftungsschutz

Vorbemerkung

Diese Leitfadenreihe ist aus einer spezifischen Perspektive heraus geschrieben: der einer General Counsel / Senior Vice President, die über viele Jahre in leitender Inhouse-Funktion in regulierten Unternehmen gearbeitet hat – in der Schweiz und in der EU. Die Autorin verfügt über eine juristische und betriebswirtschaftliche Ausbildung in der Schweiz und in Deutschland sowie über langjährige operative Erfahrung als interne Rechts- und Compliance-Verantwortliche in internationalen Konzernen und KMU-Umfeldern.

Diese Kombination – juristische Tiefe, operatives Management-Know-how und direkte Erfahrung mit den Realitäten von Lieferketten, Vertragsverhandlungen und Aufsichtsbehörden – ist der Grund, warum die Texte so geschrieben sind, wie sie sind: nicht als formale Gesetzeskommentare, sondern als Arbeitsinstrumente. Sie richten sich gleichzeitig an Führungskräfte, die schnell einordnen müssen, was eine Regulierung für ihr Unternehmen bedeutet, und an Fachabteilungen, die wissen müssen, was operativ zu tun ist.

Der interdisziplinäre Ansatz ist bewusst: Digitale Regulierung berührt gleichzeitig IT, Recht, Procurement, Geschäftsführung, HR und Lieferkette. Eine Perspektive, die nur eine dieser Dimensionen kennt, liefert unvollständige Antworten. Die Leitfäden versuchen, alle relevanten Dimensionen gleichzeitig zu adressieren – mit dem Bewusstsein, dass in der Praxis selten ein Team allein zuständig ist und die wirklichen Herausforderungen meistens an den Schnittstellen entstehen.

Die Perspektive «Schweizer KMU im EU-Kontext» ist nicht zufällig. Sie spiegelt langjährige Arbeit an der Schnittstelle zwischen Schweizer Geschäftspraxis und europäischem Regulierungsrahmen: die Erfahrung, was es konkret bedeutet, wenn ein EU-Kundenvertrag plötzlich DORA-Klauseln enthält, wenn ein Procurement-Fragebogen AI-Act-Anforderungen stellt oder wenn ein Lieferant keine NIS2-konformen Sicherheitsnachweise liefern kann. Diese Leitfäden sind aus genau diesen Situationen heraus entstanden – nicht aus dem Lesen von Gesetzestexten, sondern aus der Erfahrung ihrer Auswirkungen.

Vorwort: Was das AI Liability Framework wirklich bedeutet

Das AI Liability Framework ist kein eigenständiges Gesetz, das Unternehmen direkt verpflichtet. Es ist ein Haftungsrahmen – ein System, das bestimmt, wie Gerichte über Schäden entscheiden, die durch KI entstehen. Das klingt abstrakt, bis der erste Klagefall kommt.

Für Schweizer KMU ist die wichtigste Erkenntnis: Compliance mit dem AI Act ist nicht nur eine regulatorische Pflicht – sie ist Ihr direkter Schutz vor Haftungsrisiken. Wer keine Logs führt, keine Dokumentation hat und kein Risikomanagement betreibt, gerät im Streitfall in eine deutlich schlechtere Beweisposition: Die reformierte Produkthaftungsrichtlinie ((EU) 2024/2853) lässt Gerichte unter bestimmten Voraussetzungen die Fehlerhaftigkeit oder den Ursachenzusammenhang vermuten (widerlegbare Vermutung, Art. 10 PLD) – keine automatische, generelle Beweislastumkehr, aber ein erhebliches Risiko.

1. Die vier Säulen der KI-Haftung (nach Rückzug der AILD)

Nach dem Rückzug der geplanten AI Liability Directive gibt es kein eigenes „KI-Haftungsgesetz". Wer bei KI-Schäden haftet, ergibt sich aus dem Zusammenspiel von vier bestehenden Rechtsquellen: der reformierten Produkthaftungsrichtlinie, dem nationalen Delikts- und Vertragsrecht, dem Datenschutz- und Antidiskriminierungsrecht und – als Sorgfalts- und Beweismassstab – der AI-Act-Compliance.

1.1 Produkthaftungsrichtlinie (PLD) – Reform 2024

Die neue Produkthaftungsrichtlinie schliesst Software und KI-Systeme ausdrücklich ein. Das ist eine fundamentale Änderung gegenüber dem alten Recht.

1.2 Immaterielle & Personen-Schäden: nationales Recht statt AILD

Die geplante AILD hätte immaterielle und KI-spezifische Schäden (Diskriminierung, fehlerhafte Kredit- oder Personalentscheidungen) mit eigenen Beweiserleichterungen erfasst. Sie wurde 2025 zurückgezogen. Solche Schäden richten sich daher nach dem allgemeinen Recht — mit vier tragenden Quellen:

2. Wann bin ich haftungsrechtlich exponiert?

Die Haftungsfrage ist nicht abstrakt. Sie wird konkret, sobald ein Schaden entsteht. Aber die Vorbereitung muss vorher passieren.

2.1 Der Expositions-Schnelltest

2.2 Haftungsrisiko-Matrix nach Use Case

3. Dokumentation als Haftungsschutz – was wirklich zählt

Die wichtigste praktische Erkenntnis: Im Schadensfall entscheidet nicht, was Ihr System tatsächlich getan hat, sondern was Sie beweisen können. Dokumentation ist nicht Bürokratie – sie ist Ihr Anwalt.

3.1 Was vor Gericht wirklich zählt

3.2 Logging: Was aufgezeichnet werden muss

Logging ist kein optionales Feature. Es ist Haftungsschutz. Was aufgezeichnet werden muss:

Eingaben: Was wurde dem System übergeben? Für High-Risk-KI: vollständig. Für andere: ausreichend für Rekonstruktion.

Ausgaben und Entscheidungen: Was hat das System empfohlen oder entschieden? Mit Zeitstempel.

Human-Override-Ereignisse: Wann hat ein Mensch eine KI-Empfehlung überstimmt und warum?

System-Anomalien: Unerwartetes Verhalten, Fehler, Ausfälle.

Modell-Versionen: Welche Version des Modells war zum Zeitpunkt X aktiv?

3.3 Erklärbarkeit – was Gerichte verlangen werden

'Das Modell hat so entschieden' ist vor Gericht keine akzeptable Antwort. Gerichte werden fragen: Können Sie erklären, warum das Modell diese Entscheidung getroffen hat?

Für High-Risk-KI: Erklärbarkeit ist eine gesetzliche Anforderung unter dem AI Act und direkt mit der Haftungslogik verknüpft.

Für andere KI: Erklärbarkeit ist kein gesetzliches Muss, aber faktischer Haftungsschutz – besonders wenn Schadensfälle eintreten.

Was 'ausreichend erklärbar' bedeutet: Nicht vollständige technische Transparenz (das ist bei modernen Modellen ohnehin begrenzt), aber: Welche Faktoren hatten den grössten Einfluss? Was hätte zu einer anderen Entscheidung geführt?

4. Vertragsgestaltung: Haftung sauber verteilen

Die wichtigste Erkenntnis für Vertragsverhandlungen: Das AI Liability Framework verschiebt Haftung nicht pauschal auf Provider oder Deployer. Es hängt davon ab, wer welche Pflicht verletzt hat. Verträge müssen das abbilden.

4.1 Provider-Deployer-Haftungsteilung

4.2 Klauselbeispiele aus der Praxis

Haftungsbegrenzung für Provider

Dokumentationspflichten im Vertrag

Open-Source-Komponenten

5. Die fünf häufigsten Fehler in der Praxis

Fehler 1: Logging als nachträgliches Feature behandeln

'Das bauen wir nach dem Launch ein.' Das ist zu spät. Ohne Logs von Anfang an können Ereignisse vor dem Nachbau nicht rekonstruiert werden. Der erste Schadensfall tritt meist früher auf als erwartet.

Fehler 2: Open-Source-Modelle ohne eigene Fehlerprüfung integrieren

Open-Source-Modelle (Llama, Mistral, etc.) sind beliebt. Aber wer sie in seine eigene Lösung integriert und unter eigenem Namen verkauft, übernimmt Herstellerpflichten – einschliesslich Haftung für Modellfehler. 'Das Modell ist Open Source, das ist nicht unser Problem' ist vor Gericht keine Verteidigung.

Fehler 3: Human Oversight als formale Checkbox behandeln

'Wir haben einen Menschen im Loop.' Aber dieser Mensch sieht 500 KI-Empfehlungen pro Tag, hat für jede 20 Sekunden, und hat noch nie eine überstimmt. Das ist kein Human Oversight im Sinne des AI Acts – das ist eine Formalität. Gerichte werden das durchschauen.

Fehler 4: Haftungsausschlüsse statt Haftungsbegrenzungen

Pauschalausschlüsse ('keine Haftung für Schäden durch KI') sind in mehreren EU-Ländern unwirksam und werden zunehmend in Verhandlungen als Qualitätssignal interpretiert – negativ. Wer alles ausschliesst, signalisiert, dass er nichts garantieren kann.

Fehler 5: Versionskontrolle vernachlässigen

KI-Modelle werden aktualisiert. Wenn ein Schaden eintritt, muss rekonstruierbar sein, welche Modellversion zum Zeitpunkt des Schadens aktiv war. Ohne Versionskontrolle und Deployment-Logs ist das unmöglich.

6. Branchenprofile: Haftungsrisiken konkret

Profil A: HR-Tech-Anbieter (Recruiting-Software mit KI-Scoring)

Profil B: Fintech mit KI-gestützter Kreditentscheidung

Profil C: Industrieautomation mit KI-Fehlererkennung

7. Verbindung zum AI Act: Compliance ist Haftungsschutz

Das AI Liability Framework und der AI Act sind keine separaten Regime – sie sind bewusst aufeinander abgestimmt. Jede AI-Act-Compliance-Massnahme ist gleichzeitig eine Haftungsschutz-Massnahme.

8. Was Sie jetzt tun – priorisiert

Kontakt & weitere Informationen