Jens
Engelhardt
Softwareentwicklung per Zuruf ist in vielen Unternehmen längst Alltag: Entwickler beschreiben, was eine Anwendung leisten soll, KI-Agenten schreiben den Code. Die Produktivitätsgewinne sind erheblich – die rechtlichen Folgen werden dagegen häufig unterschätzt. Denn am selbst erzeugten Code entsteht oft kein Urheberrecht, während die Rechte Dritter an reproduziertem Code unberührt bleiben. Hinzu kommen neue Dokumentationspflichten aus Cyber Resilience Act und Produkthaftungsrecht. Wir beantworten die wichtigsten Fragen.
Was versteht man unter Vibe Coding?
Den Begriff prägte der KI-Forscher Andrej Karpathy im Februar 2025. Gemeint ist eine promptbasierte Softwareentwicklung, bei der funktionale Anforderungen in natürlicher Sprache formuliert werden und ein Sprachmodell den Quellcode weitgehend selbständig erzeugt – nicht selten, ohne dass der Mensch die Änderungen im Einzelnen liest. Die menschliche Tätigkeit verschiebt sich von der Implementierung hin zu Spezifikation, Prüfung und Integration. Rechtlich bedeutsam ist, dass der Output nicht deterministisch entsteht, kaum reproduzierbar ist und Fehler oder gar halluzinierte Programmbibliotheken enthalten kann. Das wirkt sich unmittelbar auf Zurechnung, Kontrolle und Sorgfaltspflichten aus.
Ist KI-generierter Code urheberrechtlich geschützt?
In aller Regel nicht. Computerprogramme sind nach § 69a Abs. 3 UrhG nur geschützt, wenn sie auf einer eigenen geistigen Schöpfung beruhen, und Urheber kann nach § 7 UrhG nur eine natürliche Person sein. Entscheidend ist dabei nicht die Schöpfungshöhe, sondern das Schöpferprinzip: Ein Modul, das ein Agent selbständig erzeugt, bleibt auch mit zehntausend Zeilen schutzlos, während zwanzig Zeilen menschlich gestalteter Code geschützt sein können.
Auch der Prompt hilft meist nicht weiter. Ideen, Funktionalität und Programmiersprache sind nach § 69a Abs. 2 S. 2 UrhG frei (Rechtssache C-406/10 – SAS Institute Inc. gegen World Programming Ltd). Das AG München (Urt. v. 13.2.2026 – 142 C 9786/25) hält einen Schutz über den Prompt zwar grundsätzlich für denkbar, bewertet allgemein gehaltene Anweisungen aber nicht anders als einen Auftrag an einen menschlichen Entwickler; die kreativen Entscheidungen trifft dann die Maschine. Das OLG Düsseldorf (Beschl. v. 2.4.2026 – 20 W 2/26) ist dem gefolgt. Schutz kommt deshalb vor allem in Betracht, wenn der Entwickler Architektur, Modulzuschnitt, Datenstrukturen und Fehlerbehandlung selbst vorgibt und der Agent lediglich ausfüllt, oder wenn der Output substanziell nachbearbeitet wird – dann allerdings nur für den eigenen Beitrag. Die Schutzfähigkeit ist folglich nicht pauschal für ein Produkt, sondern modulweise zu beurteilen.
Wer muss im Streitfall was beweisen?
Hier zeichnet sich eine abgestufte Darlegungslast ab. Nach dem LG Frankfurt a. M. (Urt. v. 17.12.2025 – 2-06 O 401/25) muss zunächst der Verletzer konkrete Anhaltspunkte dafür vortragen, dass der Code KI-generiert ist. Gelingt ihm das, muss der Rechteinhaber im Einzelnen darlegen, wie der Schaffensprozess verlief und welche Gestaltungselemente auf menschlicher Leistung beruhen. Commit-Nachrichten allein werden dafür kaum genügen, zumal KI-Systeme auch diese inzwischen selbst verfassen. Wer Urheberrechtsschutz für seine Software beanspruchen will, sollte Prompt-Verläufe, Änderungshistorien und Review-Kommentare daher planmäßig aufbewahren.
Wie lässt sich der Code trotzdem schützen?
Der praktisch wichtigste Auffangschutz ist das Geschäftsgeheimnisgesetz, denn es setzt keine Werkqualität voraus. Quellcode ist regelmäßig ein Geschäftsgeheimnis – sofern angemessene Geheimhaltungsmaßnahmen bestehen. Genau hier wirkt der Tooleinsatz zurück: Wer proprietären Code an einen Cloud-Assistenten überträgt, ohne Trainingsnutzung und Speicherung über die Sitzung hinaus vertraglich auszuschließen, gefährdet das Tatbestandsmerkmal selbst. Die Konfiguration der Werkzeuge – Zugriff nur auf das Projektverzeichnis, keine Anmeldedaten, keine Administratorrechte – ist damit nicht bloß IT-Hygiene, sondern Voraussetzung des Schutzes.
Da Reverse Engineering nach § 3 Abs. 1 Nr. 2 GeschGehG grundsätzlich erlaubt ist, bedarf es zudem wirksamer vertraglicher Beschränkungen unter Beachtung von § 69g Abs. 2 UrhG. Ergänzend gewinnen faktische Mechanismen an Gewicht, etwa die Bereitstellung als Dienst statt als Kopie. In der Due Diligence verschiebt sich die Frage entsprechend: nicht mehr, ob der Zielgesellschaft der Code „gehört“, sondern ob er technisch und vertraglich geschützt und frei von Rechten Dritter ist.
Welche Risiken birgt fremder Code im Output?
Sprachmodelle können Trainingsinhalte memorisieren und im Output wiedergeben – das LG München I hat dies im Verfahren GEMA/OpenAI (Urt. v. 11.11.2025 – 42 O 14139/24) für Liedtexte ausdrücklich festgestellt. Für Anwender ist entscheidend: Wer reproduzierten Drittcode vervielfältigt, verbreitet oder öffentlich zugänglich macht, begeht eine eigene Verletzungshandlung. Kurze, idiomatische Sequenzen und Standardmuster sind zwar nicht geschützt; das Risiko konzentriert sich auf längere, charakteristische Passagen aus weit verbreiteten Repositorien.
Das eigentliche Problem liegt in den Open-Source-Lizenzen. Wird Copyleft-Code unbemerkt übernommen, greifen (z.B.) die Weitergabebedingungen der GPL, deren Missachtung zum automatischen Rechteverlust führen kann – ein Mechanismus, den deutsche Gerichte seit Jahren anerkennen. Häufiger ist der Verstoß gegen die Hinweispflichten permissiver Lizenzen wie MIT, BSD oder Apache-2.0, weil der Urhebervermerk bei der Reproduktion regelmäßig verloren geht. Für den Schadensersatz nach § 97 Abs. 2 UrhG genügt Fahrlässigkeit, und der Sorgfaltsmaßstab wird durch die verfügbaren Werkzeuge geprägt: Wer Duplikatsfilter deaktiviert oder vor dem Release auf eine Software Composition Analysis verzichtet, wird sich kaum entlasten können. Freistellungszusagen der Tool-Anbieter helfen nur begrenzt – sie wirken im Innenverhältnis, setzen meist aktivierte Filter voraus und wehren den Unterlassungsanspruch des Rechteinhabers nicht ab.
Was verlangen Cyber Resilience Act, Produkthaftung und KI-Verordnung?
Der Cyber Resilience Act verpflichtet Hersteller unter anderem zu einer Software-Stückliste (SBOM); seine Meldepflichten für aktiv ausgenutzte Schwachstellen gelten bereits seit dem 11.9.2026, die übrigen Herstellerpflichten ab dem 11.12.2027. Reproduzierter Fremdcode erscheint jedoch als Eigenentwicklung und taucht in keiner aus dem Build-System erzeugten SBOM auf – eine „Phantomkomponente“, deren Schwachstellen weder erkannt noch sauber gemeldet werden können. Es empfiehlt sich daher, die SBOM um Provenienzangaben (Werkzeug, Modell, Version, Filterstatus) zu ergänzen.
Das neue Produkthaftungsrecht erfasst Software ausdrücklich als Produkt; das neu gefasste Produkthaftungsgesetz soll am 9.12.2026 in Kraft treten. Gehaftet wird für das ausgelieferte Produkt, gleichgültig, wer den Code geschrieben hat. Im Vertragsverhältnis stellt eine Schutzrechtsverletzung durch gelieferte Software einen Rechtsmangel dar – ein Punkt, den Entwicklungs- und Überlassungsverträge bislang selten ausdrücklich auf den KI-Einsatz beziehen.
Nach der KI-Verordnung ist das einsetzende Unternehmen Betreiber eines KI-Systems; eine Hochrisiko-Einstufung scheidet für die reine Entwicklungsunterstützung regelmäßig aus. Umstritten ist, ob die Transparenzpflichten des Art. 50 KI-VO generierten Quellcode erfassen. Teile der Literatur sehen Code als Textinhalt, den Anbieter nach Art. 50 Abs. 2 KI-VO als KI-generiert kennzeichnen müssen. Die Ausnahme für bloße Hilfsfunktionen bei der Standardbearbeitung soll dann zwar für in die Entwicklungsumgebung eingebettete Assistenten greifen, kaum aber für Werkzeuge, die Anwendungen eigenständig erstellen (Domokos in LTZ 2026, 213). Andere verneinen jedenfalls eine Pflicht des Betreibers, weil Quellcode schon vom Wortlaut des Art. 50 Abs. 4 KI-VO nicht erfasst sei (Siglmüller in GRUR-Prax 2026, 607). Praktisch hilft die Kennzeichnung ohnehin wenig: Sie weist nur die KI-Herkunft aus, nicht aber Quellen oder Lizenzen des reproduzierten Codes. Den Nachweis der Rechtekette nimmt sie Unternehmen nicht ab. Bestehen bleibt Art. 4 KI-VO, den die Digital-Omnibus-Verordnung (EU) 2026/1744 mit Wirkung zum 27.7.2026 zwar zu einer Unterstützungspflicht abgeschwächt, aber nicht abgeschafft hat.
Welche Rolle spielt der Datenschutz?
Eine größere, als man zunächst annimmt. Art. 25 Abs. 1 DSGVO verlangt Datenschutz durch Technikgestaltung – und betrifft damit genau die Architektur- und Sicherheitsentscheidungen, die beim Vibe Coding faktisch das Modell trifft. Die DSGVO kann deshalb auch dann relevant werden, wenn im Entwicklungsprozess selbst keine personenbezogenen Daten verarbeitet werden: Unsichere Abhängigkeiten, fehlende Zugriffsbeschränkungen oder unerkannte Datenflüsse materialisieren sich erst im späteren Betrieb. Wie real das Risiko ist, zeigt ein viel diskutierter Fall aus 2025, in dem ein Coding-Agent entgegen ausdrücklicher Anweisung eine produktive Kundendatenbank löschte und seinen Fehler anschließend zu verschleiern versuchte. Agenten gehören daher nicht ohne menschliche Freigabe an Produktivsysteme.
Was sollten Unternehmen jetzt tun?
Vibe Coding ist kein Rechtsrisiko per se. Problematisch wird es erst in Kombination mit unveränderten Vertrags- und Produktprozessen und fehlender Dokumentation. Unternehmen sollten deshalb eine verbindliche AI Coding Policy einführen, die freigegebene Werkzeuge mit zentral vorgegebener Konfiguration festlegt, Duplikats- und Lizenzfilter verpflichtend aktiviert, die Eingabe proprietären Codes regelt und KI-generierten Code im Repository kennzeichnet. Vor jedem Release gehört eine dokumentierte Composition-Analyse zum Standard, ebenso ein an den Tooleinsatz angepasstes Geheimhaltungskonzept und Schulungen der Entwicklungsteams. Parallel sollten IT-Verträge – auf Anbieter- wie auf Kundenseite – den KI-Einsatz ausdrücklich adressieren: Zulässigkeit, Offenlegung, Rechtsmängelfreiheit, Nachweispflichten und Freistellungen. Wer beides anpasst, kann die Produktivitätsgewinne heben, ohne die rechtliche Kontrolle über das eigene Produkt zu verlieren.
Sie setzen KI-Assistenten in der Softwareentwicklung ein, verhandeln Entwicklungs- oder Lizenzverträge oder bereiten eine Transaktion vor? Wir unterstützen Sie bei der Erstellung Ihrer AI Coding Policy, der Vertragsgestaltung und der rechtlichen Due Diligence – sprechen Sie uns an.