Vibecoding – also das Erzeugen von Software, indem man einem KI-Modell in natürlicher Sprache beschreibt, was es bauen soll – liefert in kurzer Zeit sichtbare Ergebnisse. Genau das erklärt die Begeisterung, mit der die Methode derzeit in Teams ausprobiert wird. Der Rechtsanwalt Niklas Mühleis weist allerdings darauf hin, dass die juristische Lage dabei alles andere als geklärt ist.

Für Unternehmen ist das kein akademisches Problem. Ein Prototyp, der am Freitagnachmittag entsteht, landet erfahrungsgemäß schnell in einer Diskussion darüber, ob man ihn nicht einfach produktiv stellen könnte. Spätestens an diesem Punkt zählen nicht mehr Geschwindigkeit und Demo-Effekt, sondern Fragen nach Rechten, Pflichten und Verantwortlichkeiten.

Drei Felder, in denen es unübersichtlich wird

Urheberrecht. Wem gehört Code, den ein Modell auf Zuruf erzeugt hat? Klassischerweise setzt Urheberrechtsschutz eine menschliche schöpferische Leistung voraus. Wie viel eigener Beitrag in einem Prompt steckt und ob das Ergebnis überhaupt schutzfähig ist, lässt sich nicht pauschal beantworten. Für ein Unternehmen bedeutet das im Zweifel: Man kann nicht ohne Weiteres davon ausgehen, exklusive Rechte an dem zu halten, was gerade entstanden ist.

Lizenzen. Modelle sind auf großen Mengen fremden Codes trainiert. Ob und in welchem Umfang Trainingsmaterial in generierten Ausgaben wiederauftaucht, ist von außen kaum nachvollziehbar. Damit steht auch die Frage im Raum, welche Lizenzbedingungen sich an solchen Code heften könnten – ein Thema, das bei Open-Source-Lizenzen mit Weitergabepflichten besonders unangenehm werden kann.

Haftung. Wenn generierter Code eine Sicherheitslücke enthält, Daten falsch verarbeitet oder einen Ausfall verursacht, haftet nicht das Modell. In der Kundenbeziehung steht weiterhin das Unternehmen gerade, das die Software ausgeliefert hat. Der Hinweis, ein Assistent habe den Abschnitt geschrieben, entlastet niemanden.

Warum das gerade jetzt relevant wird

Die Diskussion verschiebt sich, weil Vibecoding die Schwelle senkt. Früher hat Code geschrieben, wer programmieren konnte – und wer damit meist auch ein Grundverständnis für Lizenzen, Abhängigkeiten und Reviews mitbrachte. Heute entstehen funktionsfähige Anwendungen auch in Fachabteilungen, in denen diese Fragen nie eine Rolle gespielt haben.

Hinzu kommt die schiere Menge. Ein Team kann an einem Tag mehr Code erzeugen, als es sorgfältig prüfen kann. Wer die Prüfschritte nicht mitskaliert, verlagert Risiko einfach nach hinten – in den Betrieb, in Audits, in Vertragsverhandlungen mit Kunden.

Was Unternehmen praktisch tun können

Die rechtliche Unsicherheit lässt sich nicht wegorganisieren, aber sie lässt sich eingrenzen. Bewährt haben sich vor allem organisatorische Maßnahmen:

  • Klare Zonen definieren. Festlegen, wo prompt-generierter Code erlaubt ist – etwa in internen Werkzeugen und Prototypen – und wo nicht, etwa in sicherheitskritischen oder stark regulierten Komponenten.
  • Herkunft dokumentieren. Nachvollziehbar halten, welche Teile eines Systems maschinell entstanden sind. Ohne diese Information ist eine spätere Prüfung kaum möglich.
  • Review nicht abschaffen. Menschliche Durchsicht bleibt der entscheidende Filter, gerade weil generierter Code auf den ersten Blick oft sauber wirkt.
  • Abhängigkeiten prüfen. Automatisierte Lizenz- und Sicherheitsanalysen im Build-Prozess erkennen zumindest die offensichtlichen Fälle.
  • Verträge anpassen. Mit Kunden und Dienstleistern klären, wie mit KI-Anteilen umgegangen wird, wer Rechte einräumt und wer wofür einsteht.
  • Die Nutzungsbedingungen der Werkzeuge lesen. Anbieter regeln unterschiedlich, was mit Eingaben passiert und welche Rechte an Ausgaben eingeräumt werden.

Prototyp ist nicht gleich Produkt

Der wichtigste Schritt ist häufig eine schlichte Unterscheidung: Ein Prototyp darf schnell, unsauber und experimentell sein. Er dient dazu, eine Idee zu prüfen. Ein Produktivsystem verlangt Wartbarkeit, Testabdeckung, dokumentierte Herkunft und jemanden, der die Verantwortung trägt.

Der Übergang zwischen beiden Zuständen sollte eine bewusste Entscheidung sein, kein Nebeneffekt eines gelungenen Demos. Wo dieser Übergang klar definiert ist – mit einer Prüfliste, einem Review und gegebenenfalls einer teilweisen Neuimplementierung – verliert die rechtliche Unsicherheit einen Großteil ihrer Sprengkraft.

Für Web- und Softwareprojekte heißt das: Prompt-getriebene Entwicklung ist ein legitimes Werkzeug, aber kein Ersatz für Architektur, Review und saubere Vertragsgestaltung. Wer KI-Anteile von Anfang an dokumentiert und den Sprung vom Prototyp ins Produktivsystem als eigenen, geprüften Schritt behandelt, kann das Tempo nutzen, ohne die Verantwortung aus der Hand zu geben. Da sich die Rechtslage weiterentwickelt, lohnt es sich, diese Regeln als lebendes Dokument zu führen und regelmäßig gegen den aktuellen Stand zu prüfen.

Quellen