Swiss Room · Leitfaden 3 von 15
FRAMEWORK
Was dieser Leitfaden Ihnen gibt
PLD · AILD · Beweislastumkehr · Dokumentation als Haftungsschutz · Vertragsgestaltung
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.
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, kein Risikomanagement betreibt, verliert im Streitfall die Beweislast automatisch.
Das EU AI Liability Framework besteht aus zwei sich ergänzenden Instrumenten, die zusammen wirken.
Die neue Produkthaftungsrichtlinie schließt Software und KI-Systeme ausdrücklich ein. Das ist eine fundamentale Änderung gegenüber dem alten Recht.
| Aspekt | Was das für KMU bedeutet |
|---|---|
| Was als 'Produkt' gilt | Software, KI-Systeme, Updates und Upgrades, digitale Dienste, die mit Produkten verbunden sind, und bestimmte Open-Source-Komponenten |
| Wer als 'Hersteller' gilt | Wer ein KI-System entwickelt, anpasst, integriert oder unter eigenem Namen vermarktet – nicht nur der Erstentwickler |
| Wofür Hersteller haften | Fehlerhafte Modelle, unzureichende Trainingsdaten, unklare Anweisungen für Deployer, Sicherheitslücken, mangelhafte Updatepolitik |
| Beweislasterleichterung | Gerichte können vermuten, dass ein Produkt fehlerhaft war, wenn Dokumentation fehlt, Logs nicht verfügbar sind, oder AI-Act-Anforderungen nicht erfüllt wurden |
| Verjährungsfrist | 10 Jahre ab Inverkehrbringen – deutlich länger als bisher |
Die AILD ergänzt die PLD um immaterielle Schäden – also Diskriminierung, fehlerhafte Kreditentscheidungen, fehlerhafte KI-Entscheidungen in Bildung oder Beschäftigung.
| Aspekt | Was das für KMU bedeutet |
|---|---|
| Welche Schäden gedeckt werden | Immateriell: Diskriminierung, Datenschutzverletzungen, fehlerhafte KI-Entscheidungen mit persönlichen Konsequenzen |
| Beweislastumkehr bei High-Risk-KI | Wenn ein Unternehmen seine AI-Act-Pflichten nicht erfüllt hat, wird kausal unterstellt, dass dies den Schaden mitverursacht hat |
| Dokumentationszugang | Betroffene können vor Gericht Zugang zu Logs, Dokumentation und technischen Unterlagen verlangen |
| Gilt für CH-KMU wenn... | KI-Entscheidungen EU-Bürger betreffen, unabhängig vom Sitz des Unternehmens |
Die Haftungsfrage ist nicht abstrakt. Sie wird konkret, sobald ein Schaden entsteht. Aber die Vorbereitung muss vorher passieren.
| Use Case | Haftungsrisiko | Beweislastumkehr? | Prioritäre Maßnahme |
|---|---|---|---|
| KI-Recruiting / HR-Scoring | HOCH | Ja – High Risk | Vollständige Doku, Bias-Tests, Human Oversight |
| Kreditwürdigkeits-KI | HOCH | Ja – High Risk | Erklärbarkeit, Logs, Widerspruchsprozess |
| Medizinisches KI-Assistenzsystem | HOCH | Ja – High Risk + Medizinrecht | CE-Kennzeichnung, Klinische Bewertung |
| Predictive Maintenance (Industrie) | MITTEL | Nein – wenn Minimal Risk | Testprotokolle, Systemdokumentation |
| KI-Chatbot im Kundensupport | GERING | Nein – Transparenzpflichten | Kennzeichnung, Eskalationspfad zu Mensch |
| Generative KI für Content | GERING | Nein – wenn kein High Risk | Kennzeichnung synthetischer Inhalte |
| Integriertes Drittmodell (Open Source) | MITTEL-HOCH | Abhängig vom Use Case | Eigene Fehlerprüfung, Dokumentation der Integration |
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.
| Dokument | Was es beweist | Ohne dieses Dokument... |
|---|---|---|
| Risikoklassifizierungsprotokoll | Sie haben das System vor Einsatz sorgfältig bewertet | ...wird angenommen, Sie haben es nicht getan |
| Trainingsdaten-Dokumentation (Data Card) | Daten waren qualitätsgeprüft und bias-kontrolliert | ...wird vermutet, das Modell hat systemische Fehler |
| Human Oversight-Prozess | Mensch konnte eingreifen – System hat nicht autonom entschieden | ...schwer zu beweisen, dass kein autonomer Schaden entstand |
| Logs (Eingaben/Ausgaben/Entscheidungen) | Was das System tatsächlich getan hat, rekonstruierbar | ...kein Beweis möglich, kein Gegenbeweis möglich |
| Incident-Response-Protokoll | Sie haben auf bekannte Probleme reagiert | ...Untätigkeit nach Kenntnis verschärft Haftung |
| AI System Card / Technische Dokumentation | System entspricht Spec und wurde vertragsgemäss geliefert | ...unklar was geliefert wurde, Haftung diffus |
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?
'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?
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.
| Wer haftet wofür | Provider haftet für... | Deployer haftet für... |
|---|---|---|
| Grundprinzip | Fehler im Modell, unzureichende Dokumentation, falsche Anweisungen | Falschen Einsatz, Verstoß gegen Instructions for Use, fehlende Human Oversight |
| Wenn Schaden entsteht | Modell-inhärenter Fehler → Provider | Falscher Use Case, Override ohne Dokumentation → Deployer |
| Grauzone | Wenn Deployer das Modell erheblich angepasst hat → möglicherweise Provider-Haftung | Wenn Deployer sich auf Provider-Garantien verlassen durfte → geteilt |
'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.
Open-Source-Modelle (Llama, Mistral, etc.) sind beliebt. Aber wer sie in seine eigene Lösung integriert und unter eigenem Namen verkauft, übernimmt Herstellerpflichten – einschließlich Haftung für Modellfehler. 'Das Modell ist Open Source, das ist nicht unser Problem' ist vor Gericht keine Verteidigung.
'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.
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 ausschließt, signalisiert, dass er nichts garantieren kann.
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.
| Haftungsklasse | Maximal. High-Risk-KI mit direkten Auswirkungen auf Beschäftigung. |
|---|---|
| Beweislastumkehr | Ja. Fehlende Compliance-Dokumentation = Schuldvermutung bei Klagen. |
| Typisches Haftungsrisiko | Diskriminierungsklage: Eine Person wird abgelehnt und behauptet, das KI-System hat diskriminiert. Ohne Bias-Tests und Dokumentation ist die Verteidigung schwer. |
| Priorität jetzt | Bias-Evaluation dokumentieren, Human-Override-Rate messen und aufzeichnen, Widerspruchsprozess für abgelehnte Kandidaten implementieren |
| Vertragsklausel | Deployer-Kunden müssen vertraglich verpflichtet werden, das System nur für zugelassene Use Cases zu nutzen und Human Oversight sicherzustellen. |
| Haftungsklasse | Hoch. High-Risk-KI, Verbraucherschutz, Finanzrecht. |
|---|---|
| Beweislastumkehr | Ja. Zusätzlich AILD-Haftung für finanzielle Schäden durch fehlerhafte KI-Entscheidungen. |
| Typisches Haftungsrisiko | Kreditantrag abgelehnt aufgrund eines KI-Fehlers. Betroffener klagt auf Erklärung und Schadensersatz. Ohne Logs und Erklärbarkeit keine Verteidigung. |
| Priorität jetzt | Erklärbarkeits-Framework implementieren (warum wurde abgelehnt?), Widerspruchsprozess dokumentieren, Logs mit 10-jähriger Aufbewahrung |
| Besonderer Hinweis | AILD gibt Betroffenen das Recht, Dokumentation vor Gericht anzufordern. Was sie nicht finden, wird zu Ihren Lasten interpretiert. |
| Haftungsklasse | Mittel bis hoch. PLD-Haftung wenn KI-Fehler zu physischen Schäden führt. |
|---|---|
| Beweislastumkehr | Abhängig von Risikoklassifizierung. Wenn High Risk: Ja. |
| Typisches Haftungsrisiko | KI-System erkennt Produktionsfehler nicht, fehlerhafte Produkte gelangen auf den Markt, Personenschaden. Hersteller und KI-Anbieter werden gemeinsam verklagt. |
| Priorität jetzt | Klare Rollentrennung im Vertrag: wer ist Hersteller des Produkts, wer des KI-Systems. Haftungsabgrenzung vertraglich sauber regeln. |
| Vertragsklausel | 'Der KI-Lieferant haftet für KI-inhärente Fehler; der Produkthersteller haftet für die Integration und den Einsatz.' – Mit klaren Definitionen von 'KI-inhärent'. |
Das AI Liability Framework und der AI Act sind keine separaten Regime – sie sind bewusst aufeinander abgestimmt. Jede AI-Act-Compliance-Maßnahme ist gleichzeitig eine Haftungsschutz-Maßnahme.
| AI-Act-Pflicht | Haftungsschutz durch... | Ohne diese Maßnahme... |
|---|---|---|
| Technische Dokumentation | Beweist Systemqualität und -design | Gericht vermutet fehlerhafte Entwicklung |
| Logging | Rekonstruierbar was geschah | Keine Verteidigung möglich |
| Human Oversight | Zeigt, dass kein autonomer Schaden entstand | Autonomhaftung wahrscheinlich |
| Risikomanagement | Beweist proaktive Sorgfalt | Fahrlässigkeitsvermutung |
| Incident Response | Zeigt angemessene Reaktion nach Kenntnis | Haftungsverschärfung durch Untätigkeit |
| Prio | Maßnahme | Warum jetzt |
|---|---|---|
| 1 | Logging-Architektur für alle KI-Systeme überprüfen | Ohne Logs ist jede Haftungsverteidigung unmöglich. Das ist Day-1-Infrastruktur. |
| 2 | Risikoklassifizierung jedes KI-Use-Cases dokumentieren | Bestimmt Beweislastumkehr-Risiko und Dokumentationspflichten. |
| 3 | Haftungsklauseln in KI-Verträgen überprüfen | Pauschalausschlüsse sind riskant. Präzise Begrenzungen schützen besser. |
| 4 | Open-Source-Modelle evaluieren und dokumentieren | Integratorenhaftung gilt unabhängig von Modell-Lizenz. |
| 5 | Human-Oversight-Prozesse auf Realismus prüfen | Formale Oversight ohne echte Kontrolle schützt vor Haftung nicht. |
| 6 | Versionskontrolle und Deployment-Logs implementieren | 10-jährige Verjährungsfrist erfordert langfristige Rekonstruierbarkeit. |
| NBK Legal Rechts- und Compliance-Beratung EU-Digitalregulierung · Datenschutz · Cybersicherheit Schweiz · EU | Website www.nbklegal.online Alle Leitfäden der Serie www.nbklegal.online/leitfäden |
|---|