Mittwoch im Mai, Termin mit der Hausjuristin. Auf dem Tisch liegt der Rollout-Plan für GitHub Copilot, achtzig Engineers, daneben ein vierzehnseitiges Memo der Kanzlei 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 Codebase landet? Das Memo beantwortet beide nicht, es wägt sie sieben Mal ab.
Die Antwort, die der Engineering Lead in diesem Termin braucht, ist nicht juristisch komplex. Für den rein maschinellen Anteil ist die Richtung seit der BMJ-FAQ vom März 2024 klar genug, um operativ damit arbeiten zu können. Das eigentliche Risiko liegt zwei Ebenen tiefer, in der Lizenzkette, im Vertragsdach und in der Produkthaftung. Drei konkrete Controls bringen diese Risiken in dieser Woche unter Kontrolle.
Vorab eine Klarstellung: Was hier folgt, ist ein Blick aus der Engineering-Praxis auf eine juristische Debatte, keine Rechtsberatung. Dafür haben Sie Ihre Rechtsabteilung. Wer den urheberrechtlichen Teil neben den anderen Spuren 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 ordnet diese Linie in seiner FAQ vom März 2024 ein: keine bindende Rechtsquelle, aber eine tragfähige behördliche Orientierung für die Praxis. Beim rein maschinellen Output fehlt regelmäßig die schutzfähige menschliche Prägung.
Drei Normen tragen das. § 2 Abs. 2 UrhG verlangt eine persönliche geistige Schöpfung. § 7 UrhG benennt als Urheber den Schöpfer des Werkes, 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 die Nicht-Schutzfähigkeit trotzdem nicht das schlechtere Ergebnis, es ist das einfachere: Sie verlieren keinen Schutz, den Sie ohnehin nicht hatten, sondern nur die Fiktion, Sie hätten ihn gehabt.
Sobald ein Engineer den Output bewertet, anpasst, refactored oder in eine Architektur einbettet, kann Schutz an seinem Beitrag entstehen. Ob das im Einzelfall reicht, hängt am konkreten Beitrag. Ein Engineer kann Output 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 den Output nicht hinreichend objektiv und eindeutig prägte. Schutz schließt die Entscheidung nicht generell aus, sie knüpft ihn 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 Engineering Leads operativ wichtiger ist die Beweislast-Frage, die Leonardo Braguinski im Juni 2025 in beck-aktuell sauber durchdekliniert 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 Provenance-Spuren sind nicht nur Lizenz-Hygiene, sondern Beweismittel.
Was die Clean-Room-Frage im März 2026 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, eine mit Claude Code neu geschriebene Version 7.0.0 und wechselte die Lizenz von LGPL auf MIT. Argument: ein Clean-Room-Rewrite auf Basis der Test-Suite. In einem GitHub-Issue widersprach ein Account, der sich als Mark Pilgrim, der Original-Autor von 2006, ausgab: 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 dazu veröffentlichtes, als Clean-Room dargestelltes Rewrite 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 dazwischenzuschieben verschiebt die Grenze nicht, es macht sie schwerer einzuhalten.
Für die urheberrechtliche Ausgangsfrage am rein maschinellen Anteil ist die Richtung damit weiter klar. Wer was relizenzieren, neu schreiben oder weiterverteilen darf, ist im Mai 2026 offener als vorher.
Risiko Nummer eins: die Lizenzkette
Das praktisch größte Risiko bei KI-generiertem Code liegt nicht in der Werkfrage, sondern in einer unbemerkten Open-Source-Lizenz, die ein Modell beim Training aufnimmt und beim Generieren wieder ausspuckt. Landen GPL-Fragmente in einer proprietären Codebase, drohen im Distributionsfall 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 mit Prejudice. Ü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 präjudiziell. Aber das Risikomuster ist bekannt, und unter §§ 69c, 97, 97a UrhG wäre es hier wie dort justiziabel.
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. Memorisierung schlägt auch bei leicht umformulierten Outputs durch.
GitHubs eigener Duplicate-Detection-Filter 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 in der Pipeline laufen lässt, sollte nicht davon ausgehen, dass der IDE-Filter allein die Agent-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: das Vertragsdach zum Kunden
Das zweite Risiko liegt nicht im Code, sondern in einem Word-Dokument. Standard-Rechteübertragungs- und Werkgarantieklauseln in deutschen B2B-Softwareverträgen laufen am KI-Anteil leer, 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 am gelieferten Code Schutz hat.
Sobald ein nennenswerter Anteil des Codes KI-generiert ist, läuft die Klausel im KI-Anteil leer. 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 wird die Garantie für eigene Schöpfungshöhe: 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 Vendor-Indemnification 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 nicht seltener werden.
Risiko Nummer drei: die Haftung im Produktivbetrieb
Trägt ein KI-generiertes Code-Fragment einen Defekt in ein ausgeliefertes Produkt ein, steht in erster Linie regelmäßig der Hersteller des Endprodukts im produkthaftungsrechtlichen Risiko, nicht automatisch der Coding-Agent-Anbieter oder das LLM dahinter. Das ist die Logik der neuen EU-Produkthaftungsrichtlinie, die ab dem 9. Dezember 2026 anwendbar wird.
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 zieht den Cyber Resilience Act, den AI Act und NIS-2 in den produkthaftungsrechtlichen Sicherheitsmaßstab hinein.
Deutschland setzt das Modernisierungsgesetz parallel um. Den Kabinettsbeschluss gab es am 20. August 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 verabschiedet sein. Der Coding Agent ist in der Regel keine ausgelieferte Komponente, sondern Werkstatt-Werkzeug. Vertraglich kann sich der Hersteller über Tool-AGB rückversichern. Gegenüber Dritten ist Produkthaftung nicht abdingbar.
Drei Controls, die diese Woche aufgesetzt werden
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 ungesetzte technische Kontrolle zu behandeln.
Control 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 Standardpolitik blockiert AGPL und nicht freigegebene GPL-Funde 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 Politik 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 auf einer Neu-Codebase: etwa zwei Engineering-Tage. Auf einer Codebase, die noch nie systematisch geprüft wurde, sind es sechs Wochen, davon die meiste Zeit für die Bereinigung der Altlasten.
Control 2: Prompt-Provenance im Pull Request und im 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 Codebases gibt das der Disziplin einen anschlussfähigen Standard, der sich später in maschinenlesbare SBOM-Lieferketten einklinken lässt. Was die Disziplin liefert: ein nachvollziehbarer Audit-Trail bei jedem späteren Streit, im DSGVO-Auskunftsanspruch, im DD-Datenraum und in der internen Revision. Derselbe PR-Workflow, der im Engpass-Beitrag die Review-Disziplin trägt, trägt hier die Provenance-Disziplin. Aufwand: ein halber Tag für PR-Template, CI-Gate und eine kurze Engineering-Mitteilung.
Control 3: Vendor-Indemnification im Beschaffungsvertrag. Bei der nächsten Verlängerung oder spätestens beim nächsten Tool-Wechsel gehört die Indemnification-Klausel zu den verbindlichen Anforderungen. Microsoft verspricht seit dem Copilot Copyright Commitment vom 7. September 2023, Verteidigungskosten und Vergleichssummen bei Urheberrechtsansprüchen gegen den Output zu tragen; am 3. April 2026 wurden die Required Mitigations für GitHub-Offerings vereinfacht. Anthropic hat in den Commercial Terms vom 17. Juni 2025 eine vergleichbare Klausel, mit sechs Carve-outs, die in der normalen Codebase-Integration kritisch werden können: Modifications, Combinations, Inputs, wissentliche Verletzung, Patentpraxis und Trademark. Die Default-AGB von Cursor enthalten keine Vendor-zu-Kunde-Indemnification, die einzige Klausel läuft in die andere Richtung. Wer Cursor Enterprise einkauft, muss die Indemnification individuell aushandeln, sie kommt nicht von allein. Aufwand: keine Engineering-Arbeit, eine RFP-Frage und ein Procurement-Zyklus von vier bis zwölf Wochen.
Zusammen ergibt das gut zweieinhalb Engineering-Tage Setup und einen Procurement-Zyklus. Das ist der Apparat. Mehr Memo ersetzt keines dieser Controls.
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-Output explizit. Wenn die Einführung über den Betriebsrat läuft, ist der Beitrag zum Betriebsrat der Anfang.
Das deutsche Urheberrecht ist für KI-generierten Code klarer, als die Anwalts-Memos andeuten. Ungelöst sind die Lizenzkette, das Vertragsdach und die Haftung im Produktivbetrieb. Diese drei Probleme löst kein weiteres Memo, sondern drei Controls, die zusammen etwa drei Engineering-Tage Setup und einen Procurement-Zyklus brauchen.
Wenn Sie an dieser Stelle stehen, mit Memo in der Schublade, Rollout vor der Tür und ohne ein einziges der drei Controls aufgesetzt zu haben, 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 internen 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 (20. August 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
