Als Jurist mit langjähriger Erfahrung als Anwalt für Datenschutz und IT-Recht kennt Niklas die Antwort auf so gut wie jede Frage im Bereich der digitalen Compliance. Er war in der Vergangenheit unter anderem für Taylor Wessing und Amazon tätig. Als Gründer und Geschäftsführer von SECJUR, lässt Niklas sein Wissen vor allem in die Produktentwicklung unserer Compliance-Automatisierungsplattform einfließen.
Key Takeaways
Open Source schützt nicht vor Haftung nach dem EU AI Act.
Wer ein KI-Modell kommerziell nutzt, wird rechtlich zum Anbieter.
Fine-Tuning kann die volle Compliance-Pflicht auslösen.
Stellen Sie sich folgendes Szenario vor: Ein Entwickler veröffentlicht ein KI-Modell zur Bilderkennung als Open-Source-Projekt auf GitHub. Es ist ein Hobbyprojekt, entwickelt an Wochenenden. Monate später integriert ein Startup dieses Modell in eine Software zur automatischen Überwachung von Sicherheitskameras im öffentlichen Raum. Plötzlich macht das System einen Fehler, und es kommt zu einem rechtlichen Vorfall.
Wer haftet nun? Der ursprüngliche Entwickler, der den Code frei zur Verfügung gestellt hat? Oder das Startup, das die Technologie kommerziell nutzt?
Dies ist keine hypothetische Frage aus einem Jura-Seminar, sondern eine der dringendsten Realitäten unter dem neuen EU AI Act. Die Schnittstelle zwischen der kollaborativen Welt von Open Source und der strengen Regulierung der EU sorgt für Verunsicherung. Viele Entwickler fragen sich: "Bin ich plötzlich haftbar für das, was andere mit meinem Code tun?" Und Unternehmen fragen sich: "Kann ich Open-Source-Modelle nutzen, ohne mir unkalkulierbare Risiken ins Haus zu holen?"
In diesem Beitrag entwirren wir das juristische Knäuel. Wir erklären verständlich, wer wann als "Anbieter" gilt, was "kommerzielle Aktivität" wirklich bedeutet und wie Sie sich – ob als Entwickler oder Nutzer – absichern können.
Foundation: Der EU AI Act: Grundkonzepte und risikobasierter Ansatz
Um die Haftungsfrage zu klären, müssen wir zunächst verstehen, wie der EU AI Act die Welt sieht. Anders als das Urheberrecht, das sich darauf konzentriert, wem etwas gehört, konzentriert sich der AI Act darauf, welches Risiko von einer Anwendung ausgeht.
Das Gesetz unterscheidet dabei strikt zwischen verschiedenen Akteuren. Die zwei wichtigsten Begriffe, die Sie kennen müssen, sind:
Der Anbieter (Provider): Dies ist die Person oder Organisation, die ein KI-System entwickelt (oder entwickeln lässt) und es unter eigenem Namen oder eigener Marke in den Verkehr bringt. In der klassischen Software-Welt wäre dies der Hersteller.
Der Betreiber / Anwender (Deployer): Dies ist die Person oder Organisation, die das KI-System in eigener Verantwortung nutzt (z. B. ein Unternehmen, das eine KI für das Screening von Bewerbungen einsetzt).
Warum ist diese Unterscheidung so wichtig? Weil die Hauptlast der Compliance-Pflichten – und damit der Haftung – meist beim Anbieter liegt. Doch in der fließenden Welt von Open Source können diese Rollen schnell wechseln.
Die Haftung hängt zudem stark von der Risikoklasse ab. Ein Open-Source-Spamfilter (geringes Risiko) wird rechtlich völlig anders behandelt als ein Open-Source-Tool zur Kreditwürdigkeitsprüfung (Hochrisiko).
Building: Open Source KI unter dem AI Act: Wann die Ausnahme greift – und wann nicht
Hier liegt das größte Missverständnis: Viele glauben, das Label "Open Source" sei ein Freifahrtschein, der von jeglicher Haftung befreit. Das ist ein gefährlicher Irrtum.
Der EU AI Act sieht zwar Ausnahmen für kostenlose und quelloffene Lizenzen vor, aber diese Ausnahme ist an Bedingungen geknüpft. Sobald Sie diese Bedingungen verlassen, landen Sie in der vollen Regulierung.
Die Falle der "Kommerziellen Aktivität"
Die Open-Source-Ausnahme gilt nicht, wenn das KI-Modell im Rahmen einer kommerziellen Aktivität bereitgestellt wird. Hier wird es knifflig, denn "kommerziell" bedeutet nicht zwingend, dass Sie eine Lizenzgebühr für den Code verlangen.
Indikatoren für eine kommerzielle Aktivität können sein:
Kostenpflichtiger Support: Sie bieten den Code gratis an, verlangen aber Geld für technische Unterstützung.
Monetarisierung durch Daten: Sie tauschen die Nutzung des Modells gegen personenbezogene Daten der Nutzer.
Freemium-Modelle: Eine Basis-Version ist offen, die Pro-Version kostet Geld.
Wenn Sie als Entwickler in diese Kategorien fallen, könnten Sie rechtlich zum "Anbieter" werden und müssen sicherstellen, dass Ihre AI Act Software und Dokumentation den EU-Standards entsprechen.
Hochrisiko- und verbotene Systeme
Selbst wenn absolut kein Geld fließt: Wenn Ihr Open-Source-Modell als "verbotene KI-Praktik" eingestuft wird (z. B. Social Scoring), ist die Bereitstellung illegal. Bei Hochrisiko-KI-Systemen (z. B. KI in der kritischen Infrastruktur oder Bildung) greift die Ausnahme für Open Source ebenfalls oft nicht oder nur eingeschränkt, insbesondere wenn das System als fertiges Produkt in den Verkehr gebracht wird.
Mastery: Haftung in der Open-Source-Lieferkette: Wer ist wann verantwortlich?
Die vielleicht komplexeste Frage ist die der "Haftungsverschiebung". In der modernen Softwareentwicklung wird Code selten von Grund auf neu geschrieben. Man nimmt ein Modell von Hugging Face, trainiert es nach (Fine-Tuning) und integriert es in eine App.
Wer haftet hier für Fehler?
1. Der ursprüngliche Entwickler (Upstream)
Solange keine kommerzielle Aktivität vorliegt und es sich nicht um ein GPAI-Modell (General Purpose AI) mit systemischen Risiken handelt, ist die Haftung für den ursprünglichen Open-Source-Entwickler oft begrenzt. Wichtig ist jedoch Transparenz: Eine klare Dokumentation (z. B. Model Cards) schützt vor Missverständnissen.
2. Der Integrator / "Fine-Tuner" (Downstream)
Hier entsteht oft die neue Haftung. Wenn ein Unternehmen ein Open-Source-Modell nimmt und eine "wesentliche Änderung" vornimmt, wird dieses Unternehmen rechtlich zum neuen Anbieter.
Beispiel: Sie laden ein allgemeines Sprachmodell herunter und trainieren es speziell für medizinische Ratschläge. Durch diese Zweckänderung machen Sie aus einem allgemeinen Modell ein potenzielles Hochrisiko-System. Sie erben damit die Pflichten eines Anbieters – inklusive Risikomanagement und Qualitätskontrolle.
3. Der reine Nutzer (Deployer)
Auch ohne den Code zu ändern, haben Unternehmen Pflichten. Sie müssen sicherstellen, dass die AI Open Source-Komponente für ihren Einsatzzweck geeignet ist. Wer blindlings eine KI einsetzt, ohne die Anweisungen des Anbieters zu befolgen (menschliche Aufsicht, Eingabedaten-Qualität), haftet für daraus entstehende Schäden.
Action: Praktische Compliance für Open-Source-KI: Checklisten und Best Practices
Wie navigieren Sie nun sicher durch dieses Minenfeld? Egal ob Sie Code veröffentlichen oder nutzen, Dokumentation und Sorgfalt sind Ihre besten Schutzschilde.
Für Entwickler (Upstream)
Klare Lizenzierung: Nutzen Sie Standard-Lizenzen, aber seien Sie sich bewusst, dass diese das EU-Recht nicht aushebeln.
Model Cards nutzen: Dokumentieren Sie die Grenzen Ihres Modells. Wofür ist es gedacht? Wofür ausdrücklich nicht?
Status prüfen: Klären Sie, ob Ihre Aktivitäten (Spenden, Support) als "kommerziell" gewertet werden könnten.
Für Unternehmen / Integratoren (Downstream)
Due Diligence: Prüfen Sie vor dem Einsatz jedes Open-Source-Modells dessen Herkunft und Trainingsdaten.
Risiko-Assessment: Fällt die geplante Nutzung in den Hochrisiko-Bereich? Wenn ja, sind Sie bereit, die Anbieter-Pflichten zu übernehmen?
Systemisches Monitoring: Überwachen Sie das System im laufenden Betrieb. KI-Modelle können "driften" und ihr Verhalten ändern.
Fazit: Compliance als Qualitätsmerkmal
Die Haftungsregeln des EU AI Act mögen auf den ersten Blick wie eine Innovationsbremse wirken, besonders für die dynamische Open-Source-Community. Doch bei genauerem Hinsehen bieten sie auch eine Chance: Klare Regeln schaffen Vertrauen.
Unternehmen werden in Zukunft bevorzugt Open-Source-Komponenten nutzen, die gut dokumentiert sind und deren rechtlicher Status geklärt ist. Compliance wird damit vom lästigen Übel zum Wettbewerbsvorteil.
Der Schlüssel liegt darin, Compliance nicht als nachträglichen Gedanken zu behandeln, sondern von Anfang an in den Entwicklungsprozess zu integrieren. Mit den richtigen automatisierten Tools und einer klaren Strategie lässt sich auch die Hürde der KI-Regulierung meistern – damit Sie sich wieder auf das konzentrieren können, was wirklich zählt: großartige Technologie zu bauen.
FAQ: Häufige Fragen zur Haftung bei Open-Source-KI
Gilt der AI Act für mein kleines Hobbyprojekt auf GitHub?
In der Regel nicht, solange es nicht Teil einer kommerziellen Aktivität ist und es sich nicht um ein verbotenes KI-System handelt. Sobald Sie jedoch Geld damit verdienen oder es in einem professionellen Kontext einsetzen, sollten Sie die Compliance prüfen.
Was passiert, wenn ich die Regeln nicht befolge?
Die Strafen sind empfindlich und können bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes betragen. Auch für Open-Source-Akteure, die als "Anbieter" eingestuft werden, gelten diese Sanktionsrahmen.
Muss ich meine gesamten Trainingsdaten offenlegen?
Für GPAI-Modelle (General Purpose AI) müssen Anbieter eine detaillierte Zusammenfassung der für das Training verwendeten Inhalte veröffentlichen. Dies dient dem Urheberrechtsschutz. Dies gilt auch für Open-Source-Modelle, die als GPAI klassifiziert sind.
Hilft mir eine "No Liability"-Klausel in meiner Lizenz (z.B. MIT License)?
Nur bedingt. Zivilrechtliche Haftungsausschlüsse in Lizenzen sind wirksam zwischen den Vertragsparteien, können aber gesetzliche Pflichten aus dem AI Act (öffentliches Recht) nicht aushebeln. Wenn das Gesetz Sie als Anbieter eines Hochrisiko-Systems sieht, müssen Sie die Anforderungen erfüllen, egal was in Ihrer Lizenz steht.
Als Jurist mit langjähriger Erfahrung als Anwalt für Datenschutz und IT-Recht kennt Niklas die Antwort auf so gut wie jede Frage im Bereich der digitalen Compliance. Er war in der Vergangenheit unter anderem für Taylor Wessing und Amazon tätig. Als Gründer und Geschäftsführer von SECJUR, lässt Niklas sein Wissen vor allem in die Produktentwicklung unserer Compliance-Automatisierungsplattform einfließen.
Über SECJUR
SECJUR steht für eine Welt, in der Unternehmen immer compliant sind, aber nie an Compliance denken müssen. Mit dem Digital Compliance Office automatisieren Unternehmen aufwändige Arbeitsschritte und erlangen Compliance-Standards wie DSGVO, ISO 27001 oder TISAX® bis zu 50% schneller.
Compliance, completed
Automatisieren Sie Ihre Compliance Prozesse mit dem Digital Compliance Office
Die Evidenzsammlung für Ihr ISO 27001 Audit muss kein zeitfressender Kraftakt mehr sein. Erfahren Sie, wie KI-gestützte Compliance-Plattformen Screenshots, Logs und Nachweise vollautomatisch erfassen, Fehlerquellen eliminieren und Ihre Audit-Vorbereitung drastisch beschleunigen. Dieser Leitfaden zeigt praxisnah, wie Sie manuelle Prozesse hinter sich lassen, kontinuierliche Compliance etablieren und Ihr ISMS strategisch stärken – für Audits, die Sie nicht nur bestehen, sondern souverän meistern.
ISO/IEC 27001: Die Norm für Informationssicherheitsmanagementsysteme (ISMS) ist ein wesentlicher Leitfaden für Unternehmen. Erfahren Sie, wie diese Norm die Informationssicherheit gewährleistet, Risiken mindert und Wettbewerbsvorteile schafft. Die jüngste Aktualisierung, ISO/IEC 27001:2022, reflektiert moderne Bedrohungen, wie Cybersicherheit und Datenschutz, und bietet erweiterte Kontrollmechanismen. Entdecken Sie die Neuerungen, Umstellungsfristen und die Bedeutung dieser Norm für Ihr Unternehmen in 2023.
Viele Unternehmen führen Risikobewertungen noch statisch durch, doch die ISO 27001:2022 macht mit A.5.7 klar: Ohne aktuelle Threat Intelligence bleibt jedes ISMS blind. Erfahren Sie, wie Sie generische Risiken durch konkrete, reale Bedrohungen ersetzen, Ihr Risikomanagement dynamisch weiterentwickeln und Cyberangriffe proaktiv abwehren. Dieser Leitfaden zeigt praxisnah, wie CTI Ihr Sicherheitsniveau messbar erhöht und Ihr ISMS von reaktiv zu vorausschauend transformiert.