KI/AI-Recht9 Min. Lesezeit

Vibe-Coding und Recht: Wie Sie ein selbst entwickeltes Produkt sicher an den Markt bringen

Veröffentlicht: 01. August 2026·Aktualisiert: 01. August 2026
LinkedIn E-Mail

Mit KI-Assistenten entstehen Produkte in Wochen statt Monaten – die rechtlichen Anforderungen sinken dabei nicht mit. Der Beitrag zeigt, wem KI-generierter Code gehört, welche Open-Source-Lizenzen unbemerkt mitkommen, wann die KI-Verordnung Anbieterpflichten auslöst, was die neue Produkthaftung für Software bedeutet und in welcher Reihenfolge sich der Markteintritt absichern lässt – Stand 2026.

Es beginnt fast immer gleich: Jemand hat eine Idee, beschreibt sie einem KI-Assistenten in normaler Sprache, lässt sich Schritt für Schritt eine funktionierende Anwendung bauen – und steht nach wenigen Wochen vor einem Produkt, das Nutzer anmelden, Daten verarbeiten und Rechnungen schreiben kann. „Vibe-Coding" nennt sich diese Arbeitsweise, bei der nicht mehr Zeile für Zeile programmiert, sondern in Dialogform entwickelt wird. Sie hat die Eintrittsschwelle in den Softwaremarkt dramatisch gesenkt: Gründerinnen ohne Informatikstudium, Fachabteilungen ohne IT-Budget und Einzelunternehmer bringen Produkte an den Start, für die es früher ein Entwicklerteam gebraucht hätte.

Was sich nicht gesenkt hat, sind die rechtlichen Anforderungen. Das Recht fragt nicht, wie ein Produkt entstanden ist, sondern was es tut, für wen es bestimmt ist und wer dafür einsteht. Die Erfahrung aus der Beratungspraxis ist eindeutig: Die technische Umsetzung ist selten das Problem – zum Risiko wird, was beim Bauen nie zur Sprache kam. Dieser Beitrag ordnet ein, welche Pflichten ein selbst entwickeltes digitales Produkt auf dem Rechtsstand 2026 treffen, wo die spezifischen Fallstricke KI-gestützter Entwicklung liegen und in welcher Reihenfolge sich der Markteintritt absichern lässt.

Der Code: Wem gehört, was die Maschine geschrieben hat?

Am Anfang steht eine Frage, die viele Gründer überrascht: Software ist urheberrechtlich als Computerprogramm nach § 69a UrhG geschützt – aber nur, soweit sie eine eigene geistige Schöpfung ihres Urhebers ist. Diese Schöpfung setzt einen Menschen voraus. Code, den ein Modell im Wesentlichen selbstständig erzeugt hat, genießt daher keinen Urheberrechtsschutz; was bleibt, ist der Schutz der menschlichen Beiträge – Auswahl, Anordnung, Architektur, die konkrete Ausgestaltung. Praktisch bedeutet das: Gegen eine Nachahmung des generierten Codes lässt sich urheberrechtlich häufig wenig ausrichten. Der Wert des Produkts liegt dann nicht im Code, sondern in Marke, Daten, Nutzerbeziehung und Betriebswissen – und genau die sollten gesichert werden, etwa durch Markenanmeldung, konsequenten Geheimnisschutz nach dem GeschGehG und saubere Regelungen mit allen Beteiligten.

Die zweite, gefährlichere Frage betrifft nicht das eigene Recht, sondern fremde. Modelle sind auf großen Mengen öffentlich zugänglichen Codes trainiert worden, darunter Code unter Open-Source-Lizenzen. Wenn ein Assistent längere Passagen erzeugt, die erkennbar aus solchen Quellen stammen, können deren Lizenzbedingungen mitgelten – ohne dass der Lizenztext je zu Gesicht kam. Bei permissiven Lizenzen bleibt es meist bei Hinweispflichten. Bei strengem Copyleft, wie es die GPL und in Netzwerkkonstellationen die AGPL vorsehen, kann die Verpflichtung entstehen, den eigenen Quellcode offenzulegen – für ein Geschäftsmodell, das auf Exklusivität baut, ein existenzielles Thema. Hinzu kommen die Abhängigkeiten, die ein Assistent beiläufig einbindet: Bibliotheken werden importiert, ohne dass jemand die Lizenz prüft. Vor dem Launch gehört deshalb eine Lizenzinventur zum Pflichtprogramm, idealerweise werkzeuggestützt und mit einer Stückliste aller eingesetzten Komponenten. Dass die urheberrechtliche Dimension generativer Systeme kein theoretisches Risiko ist, hat das Landgericht München I im Verfahren GEMA gegen OpenAI (Az. 42 O 14139/24) deutlich gemacht; die Entscheidung ist nicht rechtskräftig, markiert aber die Richtung.

Die Rolle unter der KI-Verordnung

Wer sein Produkt mit KI gebaut hat, ist deshalb noch lange kein KI-Anbieter im Sinne der Verordnung (EU) 2024/1689. Entscheidend ist nicht das Entwicklungswerkzeug, sondern das Ergebnis: Enthält das fertige Produkt selbst eine KI-Funktion, die Nutzern gegenüber erbracht wird? Wer ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt, ist Anbieter mit den entsprechenden Pflichten. Wer lediglich ein Werkzeug zum Bauen genutzt hat und ein klassisches, deterministisches Produkt ausliefert, ist es nicht. Die häufigste Konstellation liegt dazwischen: Das Produkt bindet eine fremde KI über eine Schnittstelle ein – ein Chat-Assistent, eine Textzusammenfassung, eine automatische Klassifizierung. Dann kommt es darauf an, wie eigenständig die Funktion nach außen auftritt und ob sie unter eigenem Namen angeboten wird; wer ein fremdes System wesentlich verändert oder umbenennt, kann selbst zum Anbieter werden.

Zeitlich ist die Lage 2026 klar strukturiert. Die Verbote unannehmbarer Praktiken und die Pflicht zur KI-Kompetenz nach Art. 4 KI-VO gelten bereits seit Februar 2025 – letztere trifft auch kleine Teams, die KI im beruflichen Kontext einsetzen. Ab dem 2. August 2026 greifen die allgemeinen Regeln einschließlich der Transparenzpflichten des Art. 50 KI-VO: Wer mit einem Chatbot interagiert, muss erkennen können, dass er mit einer Maschine spricht; synthetisch erzeugte oder veränderte Inhalte sind maschinenlesbar zu kennzeichnen. Für viele KI-gestützte Produkte ist das die praktisch wichtigste Pflicht überhaupt – und eine, die sich mit wenigen Zeilen im Interface erfüllen lässt, wenn man sie kennt. Die anspruchsvollen Pflichten für Hochrisiko-Systeme nach Anhang III wurden durch den Digital Omnibus auf den 2. Dezember 2027 verschoben; das ist ein Aufschub, kein Erlass, und relevant für alle, deren Produkt in Bereiche wie Beschäftigung, Bildung, Kreditwürdigkeit oder kritische Infrastruktur hineinreicht. Durchgesetzt wird all das in Deutschland seit dem 29. Juli 2026 vor allem durch die Bundesnetzagentur als zentrale Marktüberwachungsbehörde. Der Sanktionsrahmen des Art. 99 KI-VO – bis zu 35 Millionen Euro oder sieben Prozent des weltweiten Jahresumsatzes – gibt der Sache das nötige Gewicht.

Datenschutz ist eine Architekturentscheidung

Ein KI-Assistent baut, worum man ihn bittet – und niemand bittet um Datensparsamkeit. Deshalb entstehen beim Vibe-Coding regelmäßig Anwendungen, die mehr protokollieren als nötig, Daten unbegrenzt aufbewahren und personenbezogene Informationen an Dienste weitergeben, die nie unter diesem Gesichtspunkt ausgewählt wurden. Art. 25 DSGVO verlangt das Gegenteil: Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, und zwar bereits bei der Festlegung der Mittel der Verarbeitung – also beim Bauen, nicht danach. Nachträglich ist das ungleich teurer.

Konkret sind vier Dinge zu klären, bevor der erste echte Nutzer Daten eingibt: Auf welche Rechtsgrundlage stützt sich jede Verarbeitung? Welche Dienstleister verarbeiten in wessen Auftrag, und liegen die Verträge nach Art. 28 DSGVO vor – einschließlich der Frage, ob Eingaben zum Training fremder Modelle verwendet werden dürfen? Verlassen Daten den europäischen Rechtsraum, und wenn ja, auf welcher Grundlage? Und erreicht die Verarbeitung eine Schwelle, ab der eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO erforderlich wird – was bei KI-gestützter Auswertung personenbezogener Daten schnell der Fall ist? Wer diese vier Fragen beantworten kann, hat den größten Teil des Datenschutzrisikos im Griff. Dazu kommen die Pflichtangaben: Datenschutzerklärung, Verarbeitungsverzeichnis, Anbieterkennzeichnung nach dem Digitale-Dienste-Gesetz.

Haftung: Software ist jetzt ein Produkt

Die vielleicht wichtigste Verschiebung der letzten Jahre betrifft die Haftung. Die neue Produkthaftungsrichtlinie (EU) 2024/2853, die bis zum 9. Dezember 2026 in nationales Recht umzusetzen ist, behandelt Software und KI-Systeme ausdrücklich als Produkte. Damit greift eine verschuldensunabhängige Haftung für Schäden durch fehlerhafte Produkte – flankiert von Beweiserleichterungen zugunsten der Geschädigten, wenn die technische Komplexität den Nachweis erschwert. Ein fehlendes Sicherheitsupdate kann einen Produktfehler begründen. Für Einzelgründer, die ihr Produkt bislang als Nebenprojekt betrachtet haben, ist das eine ernst zu nehmende Zäsur: Neben die vertragliche Haftung gegenüber Kunden tritt eine gesetzliche gegenüber jedermann, die sich vertraglich nicht wegbedingen lässt. Die richtige Antwort darauf ist selten juristisch allein – sie besteht aus dokumentierten Tests, einem funktionierenden Update-Prozess, einer Möglichkeit, Schwachstellenmeldungen entgegenzunehmen, und einer angemessenen Versicherung. Wer sein Produkt an Unternehmen verkauft, sollte zudem wissen, dass die europäische Cyberresilienz-Verordnung Sicherheitsanforderungen für Produkte mit digitalen Elementen gestaffelt in Kraft setzt.

AGB, Nutzungsbedingungen und die Pflicht zu aktualisieren

Am Ende steht das Vertragswerk – und hier rächt sich, was aus dem Internet zusammenkopiert wurde. Nutzungsbedingungen unterliegen als Allgemeine Geschäftsbedingungen der Inhaltskontrolle nach §§ 305 ff. BGB; Haftungsausschlüsse, die für Vorsatz und grobe Fahrlässigkeit oder für Körperschäden gelten sollen, sind unwirksam und reißen im Zweifel die gesamte Klausel mit sich. Richtet sich das Produkt an Verbraucher, gelten zusätzlich die Vorschriften über Verträge mit digitalen Produkten nach §§ 327 ff. BGB, einschließlich einer echten Aktualisierungspflicht: Der Anbieter schuldet über den maßgeblichen Zeitraum Updates, die den Fortbestand der Vertragsmäßigkeit sichern – eine Dauerverpflichtung, die bei der Preisgestaltung und beim Betriebskonzept mitgedacht werden muss. Hinzu kommen Widerrufsrecht, Informationspflichten im elektronischen Geschäftsverkehr, die Gestaltung des Bestellvorgangs und – für an Verbraucher gerichtete Dienste im elektronischen Geschäftsverkehr – die Anforderungen des Barrierefreiheitsstärkungsgesetzes, das seit dem 28. Juni 2025 gilt und in der Gründerpraxis noch immer regelmäßig übersehen wird.

Ein Fahrplan, der funktioniert

In der Beratung hat sich eine Reihenfolge bewährt, die den größten Hebel zuerst ansetzt. Zuerst die Einordnung: Was tut das Produkt, wer sind die Nutzer, enthält es eine KI-Funktion, und welche Rolle nimmt das Unternehmen unter der KI-Verordnung ein? Daraus ergibt sich der gesamte Pflichtenkatalog. Zweitens die Bestandsaufnahme des Codes: Lizenzinventur, Abhängigkeiten, Herkunft. Drittens der Datenschutz: Rechtsgrundlagen, Auftragsverarbeitung, Drittlandtransfers, gegebenenfalls Folgenabschätzung. Viertens das Vertragswerk: Nutzungsbedingungen, Datenschutzerklärung, Pflichtangaben, Verbraucherinformationen. Fünftens die Haftungsvorsorge: Testdokumentation, Update- und Meldeprozess, Versicherungsschutz. Und schließlich die Kennzeichnung: Transparenzhinweise für KI-Funktionen dort, wo Nutzer ihnen begegnen.

Ist das Produkt bereits am Markt, ändert sich an dieser Reihenfolge nichts – nur der Zeitdruck ist ein anderer. Die gute Nachricht: Fast alles lässt sich nachziehen, solange es geschieht, bevor eine Abmahnung, eine Datenschutzbeschwerde oder eine behördliche Anfrage den Takt vorgibt. Die schlechte: Je länger ein Produkt ohne Fundament läuft, desto teurer wird der Umbau – und desto mehr Nutzerdaten stehen im Feuer.

Häufige Fragen

Bin ich KI-Anbieter, nur weil ich mein Produkt mit einem KI-Assistenten gebaut habe? Nein. Maßgeblich ist nicht das Entwicklungswerkzeug, sondern das ausgelieferte Produkt: Anbieterpflichten treffen denjenigen, der ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt. Enthält Ihr Produkt selbst keine KI-Funktion, sind Sie kein Anbieter im Sinne der KI-Verordnung. Bindet es fremde KI über eine Schnittstelle ein, kommt es auf die Ausgestaltung an – und wer ein fremdes System wesentlich verändert oder umbenennt, kann selbst zum Anbieter werden.

Muss ich offenlegen, dass mein Code von einer KI stammt? Gegenüber Kunden und Nutzern besteht keine allgemeine Pflicht, den Entstehungsweg der Software offenzulegen. Etwas anderes kann gelten, wenn Sie in Ausschreibungen, Investorenunterlagen oder Verträgen Zusicherungen zur Rechteinhaberschaft am Code abgeben – dort sollten Sie wissen und offenlegen können, welche Teile Sie tatsächlich exklusiv kontrollieren. Bei Due-Diligence-Prüfungen wird genau danach zunehmend gefragt.

Wir sind schon live – ist es zu spät? Nein, aber die Reihenfolge ändert sich zugunsten des Risikos: Zuerst werden die Punkte geschlossen, die laufend Schaden anrichten können – ungeklärte Datenverarbeitung, fehlende Auftragsverarbeitungsverträge, unwirksame Haftungsklauseln, fehlende KI-Kennzeichnung. Danach folgen Lizenzinventur, Dokumentation und Haftungsvorsorge. Wichtig ist, den Zustand und die Abarbeitung zu dokumentieren: Wer nachweisen kann, dass er die Themen erkannt und geordnet abgearbeitet hat, steht sowohl gegenüber Aufsichtsbehörden als auch in Haftungsfragen deutlich besser da.

Dieser Beitrag gibt einen allgemeinen Überblick auf dem Rechtsstand 2026 und ersetzt keine Rechtsberatung im Einzelfall. Für eine Einschätzung Ihres konkreten Anliegens vereinbaren Sie gern ein Erstgespräch mit KALER.

Keinen Beitrag mehr verpassen

Jeden Freitag erscheint ein neuer Fachbeitrag – als kompakte Zusammenfassung direkt in Ihr Postfach. Kostenlos und jederzeit abbestellbar.

Rechtsgebiet:KI/AI-Recht

Verfasst von

Darius Kaler
Darius Kaler

Founder & Managing Partner · Rechtsanwalt

Schwerpunkte: Unternehmensrecht · M&A · Venture Capital · Transatlantisch