KI-generierter Code und Urheberrecht: Was Teams jetzt absichern sollten

Ein Mittwoch im Mai. Termin bei der Justiziarin. Auf dem Tisch liegt der Rollout-Plan für GitHub Copilot: 80 Entwicklerinnen und Entwickler, daneben ein vierzehnseitiges Kanzlei-Memo aus dem Februar. Die Justiziarin will zwei Fragen geklärt sehen, bevor sie unterschreibt. Wem gehört der Code, den die KI schreibt? Und wer haftet, wenn er GPL-Fragmente enthält und beim Kunden in einer proprietären Codebasis landet? Das Memo beantwortet keine von beiden. Es wägt sie siebenmal ab.

Der Engineering-Verantwortliche braucht in diesem Termin keine juristische Grundsatzdebatte, sondern eine belastbare Handlungsrichtung. Für rein maschinell erzeugten Code ist die Linie seit der BMJ-FAQ vom März 2024 klar genug für operative Entscheidungen. Das größere Risiko liegt nicht bei der Werkfrage. Es steckt in der Lizenzkette, in den Verträgen und in der Produkthaftung. Drei konkrete Schutzmaßnahmen senken diese Risiken noch diese Woche.

Vorab eine Klarstellung: Was hier folgt, ist ein Blick aus der Entwicklungspraxis auf eine juristische Debatte, keine Rechtsberatung. Dafür haben Sie Ihre Rechtsabteilung. Wer den urheberrechtlichen Teil neben den anderen Themen einer Coding-Agent-Einführung einordnen will, findet im Leitfaden zu KI-Coding-Agents den Platz dieses Themas neben Tooling, Messung, Rollout und den verwandten Compliance-Beiträgen.

Der maschinelle Anteil ist kein Werk: Was das deutsche KI-Urheberrecht heute sagt

Rein maschinell erzeugter Code ist regelmäßig nicht urheberrechtlich geschützt. Es fehlt die persönliche geistige Schöpfung im Sinne der §§ 2 Abs. 2 und 69a UrhG. Das BMJ beschreibt diese Linie in seiner FAQ vom März 2024: keine bindende Rechtsquelle, aber eine tragfähige behördliche Orientierung für die Praxis. Bei rein maschinell erzeugtem Code fehlt regelmäßig die schutzfähige menschliche Prägung.

Drei Normen stützen diese Einordnung. § 2 Abs. 2 UrhG verlangt eine persönliche geistige Schöpfung. § 7 UrhG nennt den Schöpfer des Werkes als Urheber. Das setzt eine natürliche Person voraus. § 69a Abs. 3 UrhG überträgt diese Logik auf Computerprogramme: Schutz gibt es nur für eine eigene geistige Schöpfung des Urhebers. Rein maschinell erzeugter Code erfüllt das regelmäßig nicht.

Daraus folgt nicht, dass jede Nutzung risikofrei ist. Der maschinelle Anteil ist urheberrechtlich nicht schutzfähig, aber Lizenzherkunft, Vertragszusagen, Datenbankrechte und Drittrechte bleiben eigene Prüfungen. Für die beauftragende Organisation ist das trotzdem nicht die schlechtere Nachricht, es ist die einfachere: Sie verlieren keinen Schutz, den Sie ohnehin nicht hatten, sondern nur die Fiktion, Sie hätten ihn gehabt.

Sobald ein Entwickler den KI-Vorschlag bewertet, anpasst, refaktoriert oder in eine Architektur einbettet, kann Schutz an seinem Beitrag entstehen. Ob das im Einzelfall reicht, hängt vom konkreten Beitrag ab. Ein Entwickler kann den Vorschlag technisch prüfen, ohne urheberrechtlich relevante kreative Entscheidungen zu treffen. Im Regelfall fallen aber genug menschliche Beiträge an, um Schutzpotenzial zu erzeugen: Auswahl, Anpassung, Integration, Refactoring, Architekturentscheidungen.

Wer auf richterliche Bestätigung wartet, findet einen Anhaltspunkt. Das AG München hat am 13. Februar 2026 (Az. 142 C 9786/25) drei mit Prompts erzeugte Logos für nicht schutzfähig erklärt, weil der menschliche Einfluss das Ergebnis nicht hinreichend objektiv und eindeutig prägte. Die Entscheidung schließt Schutz nicht generell aus. Sie knüpft ihn aber an genau diese Bedingung. Das betrifft Bildwerke nach § 2 UrhG, nicht Computerprogramme nach § 69a UrhG, für die ein eigener Maßstab gilt, der regelmäßig als niedriger verstanden wird als bei anderen Werkarten. Außerdem ist die Entscheidung amtsgerichtlich. Eine analoge Linie zeichnet sich ab, mehr nicht.

Juristisch breiter belegt und für Entwicklungsverantwortliche operativ wichtiger ist die Beweislast-Frage, die Leonardo Braguinski im Juni 2025 in beck-aktuell überzeugend herausgearbeitet hat. Wer Schutz für seinen Code geltend macht, trägt die Darlegungs- und Beweislast für menschliche Schöpfungshöhe. Substantiiertes Bestreiten der Gegenseite reicht, um die Last zu verschieben. Für Sie heißt das: Git-History, Reviews und Herkunftsnachweise sind nicht nur Lizenz-Hygiene, sondern Beweismittel.

Was sich durch die Clean-Room-Debatte verschoben hat

In der Praxis erzeugt die BMJ-Position trotzdem Reibung. Im März 2026 veröffentlichte Dan Blanchard, langjähriger Maintainer der Python-Library chardet, Version 7.0.0, die er mit Claude Code neu geschrieben hatte, und wechselte die Lizenz von LGPL auf MIT. Argument: ein Clean-Room-Rewrite auf Basis der Test-Suite. In einem GitHub-Issue widersprach ein Nutzerkonto, das nach eigener Darstellung Mark Pilgrim gehörte, dem Original-Autor von 2006: Ein Maintainer mit über zehn Jahren am Code könne nicht mehr clean-room arbeiten. Drei Wochen später wechselte Blanchard die Lizenz erneut, diesmal auf das noch permissivere 0BSD, um die Debatte zu entschärfen.

Ein zeitgleich kursierender Source-Map-Dump von @anthropic-ai/claude-code und ein ebenfalls veröffentlichter Rewrite, der als Clean Room deklariert wurde, verschärfen die Frage nur. Heather Meeker hat den Komplex am 9. April eingeordnet: Der Clean-Room-Standard stammt aus dem Phoenix-IBM-BIOS-Verfahren von 1984 und trennt Dirty Room (analysiert) von Clean Room (implementiert ohne Zugriff auf den Originalcode nach Spezifikation). Ein Modell dazwischenzuschalten löst das Problem nicht. Es macht die Grenze nur schwerer kontrollierbar.

Für die urheberrechtliche Ausgangsfrage am rein maschinellen Anteil ist die Richtung damit weiter klar. Wer Code neu lizenzieren, neu schreiben oder weiterverbreiten darf, ist im Mai 2026 offener als vorher.

Risiko Nummer eins: die Lizenzkette

Das praktisch größte Risiko bei KI-generiertem Code liegt nicht bei der Frage der Schutzfähigkeit, sondern in einer unbemerkten Open-Source-Lizenz, die ein Modell beim Training aufnimmt und im erzeugten Code wieder auftauchen lässt. Landen GPL-Fragmente in einer proprietären Codebasis, drohen bei der Weitergabe an Kunden Copyleft-Pflichten und Nachlizenzierungsrisiken.

GitHub Copilot und das Urheberrecht: Stand der US-Sammelklage

In den USA hat genau dieses Risikomuster eine Sammelklage ausgelöst. DOE v. GitHub, Microsoft, OpenAI wurde 2022 mit zweiundzwanzig Klagepunkten eingereicht. Am 24. Juni 2024, entsiegelt am 5. Juli, hat Richter Jon Tigar den Großteil abgewiesen, die DMCA-§-1202(b)-Ansprüche endgültig, also ohne Möglichkeit, sie erneut geltend zu machen. Übrig blieben zwei: Verletzung von Open-Source-Lizenzbedingungen und Vertragsbruch. Die mündliche Verhandlung vor dem Ninth Circuit fand am 11. Februar 2026 statt, eine Entscheidung steht im Mai 2026 noch aus. Das ist US-Recht und für deutsche Gerichte nicht bindend. Aber das Risikomuster ist bekannt, und unter §§ 69c, 97, 97a UrhG wäre es auch in Deutschland gerichtlich verfolgbar.

Coding-Modelle werden typischerweise mit großen Mengen öffentlich verfügbaren Codes trainiert; bei GitHub liegt das Risiko besonders nahe, weil dort Repositories mit sehr unterschiedlichen Lizenzen nebeneinanderstehen. Dass Modelle in seltenen Fällen Trainingsdaten wörtlich oder leicht modifiziert reproduzieren, ist empirisch belegt: Carlini, Ippolito, Tramèr und andere haben 2023 gezeigt, dass Filter, die nur exakte Wort-für-Wort-Treffer blockieren, einen falschen Sicherheitseindruck geben. Auch leicht veränderte Ausgaben können memorisierte Trainingsdaten enthalten.

GitHubs eigener Filter für öffentliche Code-Treffer vergleicht jeden Vorschlag ab etwa 150 Zeichen mit öffentlichem Code. Auf Organisationsebene ist er standardmäßig deaktiviert. Für den Copilot Cloud Agent dokumentiert GitHub Code References in den Session Logs, die passende öffentliche Treffer mit Link zu Details ausweisen. Wer Agents außerhalb der IDE in der Pipeline einsetzt, sollte nicht davon ausgehen, dass der IDE-Filter allein die gesamte Pipeline absichert.

Veröffentlichte deutsche Rechtsprechung zu Copilot oder vergleichbaren Werkzeugen, in der GPL-Regurgitation entschieden wäre, gibt es bis Mai 2026 nicht. Eine produktive Engineering-Organisation kann nicht warten, bis sich das ändert. Sie kann das Risiko mit überschaubarem Aufwand senken. Wie, steht weiter unten.

Risiko Nummer zwei: die vertragliche Absicherung gegenüber Kunden

Das zweite Risiko liegt nicht im Code, sondern in einem Word-Dokument. Standardklauseln zur Rechteübertragung und Werkgarantie in deutschen B2B-Softwareverträgen laufen für den KI-Anteil ins Leere, weil sich nicht übertragen oder zusichern lässt, was urheberrechtlich nicht entsteht.

In den meisten deutschen B2B-Softwareverträgen steht eine Klausel der Form „Der Lieferant überträgt sämtliche Rechte am gelieferten Quellcode auf den Auftraggeber" oder „Der Quellcode ist geistiges Eigentum des Lieferanten und wird zur Nutzung lizenziert". Beide Klauseln stammen aus einer Welt, in der der Lieferant den gelieferten Code selbst geschaffen hat oder daran Rechte hält.

Sobald ein nennenswerter Anteil des Codes KI-generiert ist, läuft die Klausel für den KI-Anteil ins Leere. ADVANT Beiten hat das in einer Analyse zu Unternehmenskäufen auf den Punkt gebracht: Wenn kein Urheberrecht entsteht, kann auch keines übertragen werden. Die Übertragung von Nutzungsrechten am nicht-schutzfähigen Anteil ist gegenstandslos, der Vertrag verspricht etwas, was nicht existiert. Heikler ist eine Garantie, der Code sei eine eigene schöpferische Leistung: Wenn der Vertrag „eigenes Werk" zusichert, kann der KI-Anteil eine Garantieverletzung sein. Und die Freistellung gegen Drittrechte, also der GPL-Fall aus dem vorigen Abschnitt, ist eine eigene Baustelle.

Bei CMS Law sieht man dieselbe Frage inzwischen routinemäßig in der M&A-Due-Diligence. Welcher Anteil ist KI-generiert, welche Anbieterfreistellung deckt das ab und welche Klauseln im Bestand sind davon betroffen. Wer keine Antworten hat, riskiert Preisabschläge oder zusätzliche Garantien. In Software-Due-Diligences wird diese Frage häufiger auftauchen.

Risiko Nummer drei: die Haftung im Produktivbetrieb

Verursacht ein KI-generiertes Code-Fragment einen Fehler in einem ausgelieferten Produkt, trägt in der Regel der Hersteller des Endprodukts das produkthaftungsrechtliche Risiko, nicht automatisch der Anbieter des Coding Agents oder des zugrunde liegenden LLMs. Das ist die Logik der neuen EU-Produkthaftungsrichtlinie, deren Umsetzungsfrist am 9. Dezember 2026 endet und die für Produkte gilt, die danach in Verkehr gebracht oder in Betrieb genommen werden.

Im Detail: Die Richtlinie (EU) 2024/2853 zur Produkthaftung ist seit dem 8. Dezember 2024 in Kraft. Software, einschließlich KI-Systeme, gilt nach Art. 4 ausdrücklich als Produkt, unabhängig von der Lieferform. Der Fehlerbegriff in Art. 7 bezieht den Cyber Resilience Act, den AI Act und NIS-2 in den produkthaftungsrechtlichen Sicherheitsmaßstab ein.

Deutschland setzt das Modernisierungsgesetz parallel um. Den Kabinettsbeschluss gab es am 17. Dezember 2025, die erste Lesung im Bundestag am 4. März 2026, eine Anhörung im Rechtsausschuss am 13. April 2026. Bis zum 9. Dezember 2026 muss es in Kraft getreten sein. Der Coding Agent ist in der Regel keine ausgelieferte Komponente, sondern Werkstattwerkzeug. Vertraglich kann sich der Hersteller über die Tool-AGB absichern. Gegenüber Dritten ist Produkthaftung nicht abdingbar.

Drei Schutzmaßnahmen, die Sie diese Woche aufsetzen können

Die drei Risiken sind handwerklich einfach anzugehen. Was sie aufhält, ist nicht juristische Komplexität, sondern die organisatorische Neigung, eine ungelöste Rechtsfrage als Ersatz für eine fehlende technische Kontrolle zu behandeln.

Schutzmaßnahme 1: Lizenz-Scanner in der CI. Snyk License Compliance, FOSSA mit Snippet Scanning, Black Duck mit seiner Snippet-API oder das Open-Source-Toolkit ScanCode sind im Mai 2026 die plausiblen Kandidaten. Eine Standardregel blockiert AGPL und GPL-Treffer, die nicht freigegeben wurden, beim Merge, markiert LGPL und MPL als Warnung und lässt permissive Lizenzen wie MIT, Apache und BSD durch. In reinen SaaS-Backends kann die Regel für klassische GPL- und LGPL-Fälle weicher ausfallen, weil ohne Verbreitung keine Copyleft-Pflicht ausgelöst wird. AGPL bleibt wegen der Netzwerk-Klausel auch dort gesondert kritisch und gehört auf die Blockliste. Das ist nicht KI-spezifisch, sondern eine Disziplin, die viele Häuser seit Jahren vor sich herschieben. Die KI-Welle erzwingt sie endlich. Aufwand für ein Standard-Setup in einer neuen Codebasis: etwa zwei Engineering-Tage. In einer Codebasis, die noch nie systematisch geprüft wurde, sind es sechs Wochen, davon die meiste Zeit für die Bereinigung der Altlasten.

Schutzmaßnahme 2: Herkunftsnachweis für KI-Beiträge im Pull Request und Commit. Ein Standardfeld in der PR-Template-Beschreibung. Drei Zeilen, keine Doktorarbeit: KI-assistierter Anteil, ja oder nein. Welches Werkzeug und welches Modell. Wofür. Im Commit-Footer ein Git-Trailer: Assisted-by: claude-code:claude-sonnet-4.6 oder das jeweilige Äquivalent. Mehrere Open-Source-Projekte nutzen oder diskutieren inzwischen den Assisted-by-Trailer für KI-assistierte Beiträge; für interne Codebasen gibt das der Disziplin einen anschlussfähigen Standard, der sich später an maschinenlesbare SBOMs anschließen lässt. Das Ergebnis ist ein nachvollziehbarer Audit-Trail: für spätere Streitfälle, DSGVO-Auskunftsersuchen, Due-Diligence-Datenräume und die interne Revision. Derselbe PR-Workflow, der im Engpass-Beitrag die Review-Disziplin sichert, sorgt hier für saubere Herkunftsnachweise. Aufwand: ein halber Tag für PR-Template, CI-Gate und eine kurze Engineering-Mitteilung.

Schutzmaßnahme 3: Anbieterfreistellung im Beschaffungsvertrag. Bei der nächsten Verlängerung oder spätestens beim nächsten Tool-Wechsel gehört eine Anbieterfreistellung, also eine Vendor Indemnification, zu den verbindlichen Anforderungen. Microsoft verspricht seit dem Copilot Copyright Commitment vom 7. September 2023, Verteidigungskosten und Vergleichssummen bei Urheberrechtsansprüchen gegen den erzeugten Code zu tragen; die erforderlichen Schutzmaßnahmen für GitHub-Angebote, die „Required Mitigations", wurden am 3. April 2026 vereinfacht. Anthropic hat in den Commercial Terms vom 17. Juni 2025 eine vergleichbare Klausel, mit sechs Ausnahmen, die bei der normalen Integration in eine Codebasis kritisch werden können: Modifications, Combinations, Inputs, wissentliche Verletzung, Patentpraxis und Trademark. Die Standard-AGB von Cursor enthalten keine Anbieterfreistellung gegenüber dem Kunden, die einzige Klausel läuft in die andere Richtung. Wer Cursor Enterprise einkauft, muss die Freistellung individuell aushandeln, sie kommt nicht von allein. Aufwand: keine Engineering-Arbeit, eine Frage im Ausschreibungsprozess und ein Beschaffungszyklus von vier bis zwölf Wochen.

Zusammen ergibt das gut zweieinhalb Engineering-Tage Setup und einen Beschaffungszyklus. Mehr braucht es operativ zunächst nicht. Mehr Memo ersetzt keine dieser Schutzmaßnahmen.

Was nicht in diesem Beitrag steht

Drei Themen schließen daran an und gehören in eigene Beiträge. Wenn personenbezogene Daten durch Prompts oder Repository-Kontext fließen, ist das ein DSGVO-Thema, der Beitrag zum DPO-Termin ordnet das. Wenn Sie in der Finanzaufsicht arbeiten, kommen MaRisk und DORA dazu, BaFin, MaRisk und Coding Agents macht die Trennung zwischen Agent und Code-Ausgabe deutlich. Wenn die Einführung über den Betriebsrat läuft, liefert der Beitrag zum Betriebsrat den Einstieg.

Das deutsche Urheberrecht ist für KI-generierten Code klarer, als die Anwalts-Memos andeuten. Ungelöst sind die Lizenzkette, die vertragliche Absicherung und die Haftung im Produktivbetrieb. Diese drei Probleme löst kein weiteres Memo, sondern drei Schutzmaßnahmen, die zusammen etwa drei Engineering-Tage Setup und einen Beschaffungszyklus brauchen.

Stehen Sie genau hier, mit Memo in der Schublade, Rollout vor der Tür und ohne eine der drei Schutzmaßnahmen, schreiben Sie mir. Dreißig Minuten reichen oft, um die nächsten zwei Wochen zu sortieren. Für Teams, die den Rollout noch planen, gibt es den 3-Tage-Intensivworkshop für Entwicklerteams.

Dieser Artikel ersetzt keine Rechts- oder Compliance-Beratung; für konkrete Fälle empfiehlt sich die Abstimmung mit der zuständigen Compliance-Funktion und bei Bedarf einem Fachanwalt für Urheber- und IT-Recht.

Quellen

• BMJ: FAQ Künstliche Intelligenz und Urheberrecht (5. März 2024)
• gesetze-im-internet.de: § 2 UrhG, § 7 UrhG, § 69a UrhG
• beck-aktuell / Braguinski: Wie soll ich beweisen, dass mein Code nicht KI-generiert ist? (18. Juni 2025)
• LWN: The relicensing of chardet (5. März 2026) und GitHub Issue chardet/chardet#327
• Heather Meeker: The chardet controversy: Open source and the AI clean room (9. April 2026)
• Heise: GitHub-Copilot-Sammelklage verliert an Boden (Juli 2024) und CourtListener Docket 9th Cir. 24-7700
• Carlini et al.: Preventing Verbatim Memorization in LLMs Gives a False Sense of Privacy (INLG 2023)
• GitHub Docs: Finding public code that matches Copilot suggestions
• ADVANT Beiten: KI-generierte Software bei Unternehmenskäufen
• CMS Law: KI-generierter Softwarecode in der Due Diligence (30. Oktober 2025)
• EUR-Lex: Richtlinie (EU) 2024/2853 (Produkthaftung)
• Bundesregierung: Kabinettsbeschluss Produkthaftung, Digitalisierung, KI (17. Dezember 2025)
• All Things Open: Assisted-by: How open source projects are drawing the line on AI contributions (11. Mai 2026)
• Microsoft: Copilot Copyright Commitment (7. September 2023) und Customer Copyright Commitment Required Mitigations
• Anthropic: Commercial Terms of Service (17. Juni 2025)
• Cursor: Terms of Service
• Tools: Snyk License Compliance, FOSSA AI Coding Guardrails, ScanCode toolkit