Vibe Coding rechtssicher machen – Leitlinien, Konfigurationen, Prozesse

Vibe Coding – das Entwickeln von Software durch KI, bei dem KI-Agenten und KI-Assistenten wie Cursor, GitHub Copilot oder Claude Code den eigentlichen Code schreiben – hat sich in kürzester Zeit vom Experiment zur Praxis entwickelt. Was als produktivitätssteigerndes Werkzeug für Entwickler begann, stellt Unternehmen vor rechtliche Fragen, die bislang kaum systematisch adressiert werden: Wem gehört der generierte Code? Was passiert, wenn der KI-Assistent geschützten Code reproduziert? Und wer haftet, wenn ein KI-generierter Fehler eine Sicherheitslücke öffnet? Und wie gehe ich damit in der Praxis um?

Die zentralen Rechtsfragen

Vibe Coding ist rechtlich kein weißes Blatt. Drei Bereiche verdienen besondere Aufmerksamkeit:

• Urheberrecht und Code-Ownership: KI-generierter Code ist nach deutschem Recht mangels menschlicher Schöpfungshöhe grundsätzlich nicht urheberrechtlich geschützt – der Entwickler, der nur einen Prompt eingibt, erwirbt kein Urheberrecht am Output. Anders kann es liegen, wenn der Mensch den Code substantiell weiterentwickelt. Das wird in der Praxis aber immer seltener. Für Unternehmen bedeutet das: rein KI-generierter Code in einem Softwareprodukt kann kein urheberrechtlich schützenswertes Alleinstellungsmerkmal begründen. Umso wichtiger wird der Geschäftsgeheimnisschutz als Fallback, insbesondere technische und organisatorische Maßnahmen und vertragliche Absicherung.
• Open-Source-Lizenzen und Memorization: KI-Modelle wurden aus großen Open Source-Bestandteilen trainiert – darunter GPL-, LGPL- oder AGPL-lizenzierter Code. Durch Memorization kann der Assistent Codeabschnitte reproduzieren, die urheberrechtlich geschützt sind oder Copyleft-Pflichten auslösen. Wer solchen Code ungeprüft in ein proprietäres Produkt integriert, riskiert Lizenzverstöße, die zu Unterlassungs- und Schadensersatzansprüchen und sogar zur Strafbarkeit führen können. Mitigierende Maßnahmen sind Duplikatsfilter, Schulungen, Policies, Freistellungen u.v.m.
• Datensicherheit und Vertraulichkeit: Wer proprietären Code in Cloud-basierte KI-Tools eingibt, überträgt diesen an den jeweiligen Anbieter. Ohne vertragliche Absicherung – insb. Regelungen zur Nichtverwendung für Trainingszwecke – können Geschäftsgeheimnisse gefährdet werden. Gerade bei sensitiven Projekten ist zu klären, ob eine lokale Deployment-Option verfügbar und vorzuziehen ist.

Konfigurationen als erste Verteidigungslinie

Viele Risiken lassen sich durch gezielte technische Konfigurationen reduzieren:

• Systemprompts: Viele KI-Coding-Tools erlauben die Definition von Systemregeln, die das Verhalten des Assistenten steuern. Hier können Vorgaben eingebettet werden – z.B. keine Übernahme von Code ohne nachgewiesene Lizenz, Kennzeichnung von KI-generiertem Code, Hinweise auf Sicherheitsanforderungen.
• Dateisystemzugriff einschränken: Der Zugriff sollte auf das Projektverzeichnis begrenzt werden. Dateien mit Zugangsdaten oder Schlüsseln (z.B. .env, .ssh, *.pem) sollten in der Deny-List eingetragen werden.
• Minimale Systemberechtigungen: Das KI-System sollte ohne Root- oder Administratorrechte betrieben werden; eine vom Tool angebotene Sandbox- oder eingeschränkte Ausführungsumgebung sollte aktiviert werden.
• Netzwerkzugriff beschränken: Zugriff auf interne Produktiv- oder Kundensysteme sollte beschränkt werden. Soweit das Tool einen Offline- oder lokalen Modus bietet, ist dieser zu bevorzugen.
• Lizenzfilter: Tools wie GitHub Copilot bieten Einstellungen zur Filterung von Code-Vorschlägen, die öffentlich verfügbarem Code ähneln. Diese Funktion sollte standardmäßig aktiviert sein.
• Lokale Modelle: Für besonders sensible Projekte kann der Einsatz lokal deploybarer Modelle (z.B. über Ollama) eine datenschutzrechtlich sichere Alternative darstellen – auch wenn Leistungseinbußen in Kauf zu nehmen sind.
• v.m.

Leitlinien: Die AI Coding Policy

Technische Konfigurationen allein reichen nicht aus. Unternehmen benötigen eine AI Coding Policy, die über eine allgemeine AI Policy hinausgeht und spezifisch den KI-Einsatz in der Softwareentwicklung adressiert. Mindestinhalt:

• Zugelassene Tools und Modelle (Whitelist)
• Vorgaben zum Umgang mit proprietärem Code als KI-Input
• Pflicht zur Lizenzprüfung von KI-generiertem Code (insb. Nutzung von Duplikatsfiltern)
• Sicherstellung eines ausreichenden menschlichen Beitrags
• Kennzeichnungspflicht für KI-generierten Code im Repository
• Regelungen zum Code Review bei KI-Output
• Schulungspflicht für Entwickler
• Hinweispflichten

Eine AI Coding Policy schafft nicht nur Compliance – sie schützt auch die Entwickler, die sonst im Unklaren über erlaubtes Verhalten sind.

Prozesse: Was keine Konfiguration ersetzen kann

Leitlinien und Konfigurationen greifen nur, wenn sie in lebende Prozesse eingebettet sind:

Code Review bleibt Pflicht: KI-generierter Code muss menschlich geprüft werden – nicht nur auf Funktion, sondern auch auf Lizenzkonformität und Sicherheit. Automatisierte SAST-Tools können unterstützen, ersetzen aber das Vier-Augen-Prinzip nicht.

SBOM-Integration: Der Cyber Resilience Act verpflichtet Hersteller digitaler Produkte ab Dezember 2027 zur Erstellung einer Software Bill of Materials (SBOM). KI-generierter Code muss in diesen Prozess integriert werden – auch wenn seine Herkunft schwerer nachzuvollziehen ist als bei klassisch eingebundenen Bibliotheken.

Incident-Management: Wenn ein KI-generierter Fehler zu einer Sicherheitslücke führt, muss klar sein, wer informiert wird, wie der Fehler dokumentiert wird und ob eine Meldepflicht – z.B. nach NIS2 – besteht.

Vibe Coding ist kein Risiko per se – aber unkontrolliertes Vibe Coding ist eines. Wer heute die richtigen Leitlinien, Konfigurationen und Prozesse einführt, kann die KI-Produktivitätsgewinne nutzen, ohne die rechtliche Kontrolle zu verlieren.