



Volljurist und Compliance-Experte
06 Jan 2026
5 Minuten
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.
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.
Saubere Dokumentation reduziert Haftungsrisiken erheblich.
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.
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:
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).
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 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:
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.
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.

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?
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.
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.
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.
Wie navigieren Sie nun sicher durch dieses Minenfeld? Egal ob Sie Code veröffentlichen oder nutzen, Dokumentation und Sorgfalt sind Ihre besten Schutzschilde.

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.
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.
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.
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.
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.
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.
Automatisieren Sie Ihre Compliance Prozesse mit dem Digital Compliance Office
Die häufigsten Fragen zum Thema

ISMS-Expertentools, Enterprise GRC, Beratung oder Plattform mit optionaler Beratung? Dieser Buyer's Guide ordnet den NIS2-Software-Markt in vier Kategorien und liefert acht Bewertungskriterien für Ihre Auswahl.

Der CEO-Fraud ist eine Variante des „Social Engineerings“, bei welchem die Täter auf das oft schwächste Glied in der IT-Sicherheitskette setzen: Den Menschen. Infolge der immer besseren technischen Schutzmaßnahmen, angefangen bei einer einfachen Firewall bis hin zu Verschlüsselungsmethoden, ist es schwieriger geworden, auf „klassischem“ Weg, wie beispielsweise Hacking, an vertrauliche Informationen zu gelangen. Wie schützt man sich als CEO?

In den vergangenen zwei Jahren waren Verstöße gegen Datenschutzbestimmungen für nur 6 % der Befragten überhaupt relevant. Dies wird sich in den kommenden Jahren erheblich ändern. So sehen es zumindest die fast 200 befragten Entscheider aus Unternehmen ab 250 Mitarbeitern, die an der Studie „Crisis Management“ der Kanzlei Noerr teilnahmen.