Haftung beim Einsatz von VibeCoding und No-Code-Plattformen – Auswirkungen auf die Legal Due Diligence

VibeCoding beschreibt einen aktuellen Trend, bei dem Software nicht mehr manuell programmiert, sondern fast ausschließlich durch den Einsatz von KI-Systemen oder No-Code-Plattformen entwickelt wird. Anstatt klassischen Quellcode zu schreiben, erklären Gründer und Entwickler lediglich in natürlicher Sprache, was ihre Software leisten soll, oder konfigurieren sie über visuelle Oberflächen. Moderne KI-Tools wie Codex, ChatGPT oder spezielle Plattformen übersetzen diese Anweisungen dann automatisch in ausführbaren Programmcode. Als erfahrener IT-Anwalt mit besonderer Leidenschaft für KI-Themen beobachte ich diese Entwicklung fasziniert: Zwar ermöglicht VibeCoding eine beachtliche Effizienzsteigerung und beschleunigt die Entwicklung drastisch – zugleich wirft die automatisierte Codeerstellung aber auch ganz neue juristische Fragen auf.

Noch ist beispielsweise völlig offen, wer haftet, wenn der KI-generierte Code Fehler enthält oder Schäden verursacht, und wem letztlich die Rechte an solchen automatisierten Kreationen gehören. In diesem Beitrag gehe ich daher insbesondere auf die zivilrechtliche Haftung von Tech-Startups bei Nutzung von VibeCoding und No-Code-Tools ein, diskutiere die Verantwortlichkeit der Plattformanbieter und beleuchte auch die damit verbundenen urheberrechtlichen Herausforderungen. Zudem erkläre ich, wie unsichere Schutzrechtslagen rund um KI-generierten Code zu Schwierigkeiten bei einer Legal Due Diligence führen können und was dies für künftige Investorengespräche bedeutet. Dabei nehme ich auch relevante Normen wie §§ 823, 831 und 307 BGB, das Produkthaftungsgesetz (ProdHaftG) sowie Regelungen des Urhebergesetzes (UrhG) und die neuesten Entwicklungen im EU-Recht (z.B. KI-Verordnung) in den Blick, um für Gründer, Entwickler und Investoren praxisnahe Orientierung zu bieten.

Haftungsrisiken für Startups bei KI-generiertem Code

Startups, die weitgehend KI-generierten Code einsetzen, stehen vor der Herausforderung, für die Qualität und Sicherheit dieses Codes rechtlich einzustehen, obwohl er nicht vollständig von Menschen geprüft oder geschrieben wurde. Grundsätzlich gilt: KI-Systeme besitzen keine Rechtsfähigkeit und können daher selbst nicht haften. Die Verantwortung für KI-Ausgaben – sei es Programmcode, Texte oder Bilder – trägt derjenige, der die KI einsetzt und die Ergebnisse verwendet. Ein Unternehmen kann sich also nicht darauf berufen, die KI sei „verantwortlich“ – ein Haftungsausschluss durch bloßen Hinweis auf den KI-Ursprung ist rechtlich unwirksam. Dies hat mehrere Facetten:

• Deliktische Haftung (§ 823 BGB): Wenn fehlerhafter KI-Code Schäden verursacht, haftet das Startup nach allgemeinen Deliktsgrundsätzen. § 823 Abs. 1 BGB begründet eine Schadensersatzpflicht, wenn z.B. durch fahrlässig unzureichend überprüften Code ein absolut geschütztes Rechtsgut (wie Leben, Gesundheit, Eigentum) verletzt wird. Das könnte etwa der Fall sein, wenn eine von der KI generierte Software aufgrund eines Programmierfehlers Sachschäden beim Nutzer auslöst (z.B. Datenverlust, Systemausfall mit Folgeschäden). Entscheidend ist, ob das Startup seine Verkehrssicherungspflichten verletzt hat – also die im Verkehr erforderliche Sorgfalt außer Acht ließ. Bei fehlender menschlicher Kontrolle über KI-Code könnte man dem Startup Fahrlässigkeit vorwerfen, insbesondere wenn nach dem Stand der Technik eine Überprüfung oder Tests geboten gewesen wären. Allerdings ist auch zu berücksichtigen, dass Softwarefehler nie vollständig auszuschließen sind; die Haftung setzt daher ein Pflichtwidrigkeitsmoment voraus (z.B. völliges Fehlen von Qualitätssicherung). Neben § 823 BGB kommen deliktische Produzentenhaftung in Betracht: Nach ständiger Rechtsprechung muss, wer ein Produkt (hier: Software) in den Verkehr bringt, hinreichende Kontrolle zur Vermeidung von Gefahren ausüben – anderenfalls haftet er bei Schaden im Wege der Produzentenhaftung auf Basis von § 823 Abs. 1 BGB. Zu beachten ist, dass eine KI selbst kein „Produkt“ im rechtlichen Sinn ist, sondern Teil eines vom Startup angebotenen Softwareprodukts oder -dienstes.
• Vertragliche Haftung und Gewährleistung: Gegenüber Kunden haftet das Startup vertraglich für Mängel seiner Software. Insbesondere im B2B-Kontext versuchen Startups oft, ihre Haftung vertraglich zu begrenzen (Haftungsbeschränkungen in AGB oder Verträgen). In Deutschland stößt dies jedoch auf rechtliche Grenzen: Ein vollständiger Ausschluss für einfache Fahrlässigkeit ist in AGB meist unwirksam, wenn er wesentliche Vertragspflichten umfasst oder den Vertragspartner unangemessen benachteiligt (§ 307 BGB) . Kardinalpflichten – also zentrale Pflichten, deren Verletzung den Vertragszweck gefährdet – dürfen in AGB nicht vollständig ausgeschlossen werden. In individuell ausgehandelten Verträgen unter Unternehmern kann die Haftung zwar weitergehend beschränkt werden, aber Vorsatz kann nie ausgeschlossen werden (§ 276 Abs. 3 BGB), und für grobe Fahrlässigkeit sowie Personenschäden gelten strenge Maßstäbe. Praktisch bedeutet dies: Ein Startup kann seine Haftung für leichte Fahrlässigkeit gegenüber Geschäftskunden in gewissem Umfang begrenzen, nicht jedoch für gravierende Verschulden oder Schäden an Leben, Körper, Gesundheit. Standardklauseln, die jegliche Haftung für KI-Fehler pauschal ausschließen, wären in aller Regel unwirksam. Selbst in einem rein B2B-Verhältnis würde ein vollständiger Haftungsausschluss für vom Startup zu vertretende KI-Fehler einer Inhaltskontrolle nach § 307 BGB oft nicht standhalten, weil der Kunde dann das volle Risiko trägt. Ferner kann sich ein Startup gegenüber Verbrauchern überhaupt nicht auf solche Klauseln berufen (§ 309 Nr.7 BGB verbietet Haftungsausschlüsse für Körperschäden und grobes Verschulden in Verbraucherverträgen).
• Haftung für Rechtsverletzungen (insb. Urheberrecht): Ein weiteres Risiko ist, dass KI-generierter Code fremde Schutzrechte verletzt. KI-Modelle (z.B. Code-Generatoren wie GitHub Copilot) wurden mit riesigen Code-Datensätzen trainiert, in denen auch fremder, urheberrechtlich geschützter Quellcode enthalten sein kann. Es hat sich gezeigt, dass KI-Outputs teils stark dem Trainingsmaterial ähneln). Dadurch besteht die Gefahr, dass neu generierter Code z.B. unter einer Open-Source-Lizenz steht, ohne dass das Startup dies bemerkt. So könnte die KI etwa Code aus einer GPL-lizenzierten Bibliothek reproduzieren – das Startup würde diesen Code in sein proprietäres Produkt integrieren und damit gegen die Lizenzbedingungen und ggf. Urheberrechte verstoßen. Urheberrechtlich geschützte Code-Segmente dürfen nicht ohne Weiteres übernommen werden, ansonsten drohen Unterlassungs- und Schadensersatzansprüche durch die Rechteinhaber (§§ 97, 69c UrhG). Ein Startup haftet hier als Täter oder Störer einer Urheberrechtsverletzung, selbst wenn die Übernahme unbewusst durch die KI geschah, da die Nutzung des Ergebnisses im eigenen Produkt zugerechnet wird. Experten warnen bereits, dass KI-generierter Code die „nächste Abmahnfalle“ für Entwickler sein kann Beispiel: Wenn die KI-Codeausgabe einem auf GitHub veröffentlichten Code eines Dritten entspricht, kann letzterer Abmahnungen verschicken. Ein findiger „Troll“ könnte sogar gezielt Code unter einer strengen Lizenz ins Netz stellen und darauf spekulieren, dass KI-Systeme diesen Code in verschiedene Projekte reinspeisen. Für das Startup bedeutet dies erhebliche Risiken – von Compliance-Verstößen bei Open-Source-Software bis zu Schadenersatzforderungen wegen Urheberrechtsverletzung. Entsprechend muss ein Startup alle KI-Outputs gründlich prüfen (z.B. durch Code-Scanning-Tools auf Übereinstimmungen mit bekannten Codes) und sicherstellen, dass es Rechte an allen Codebestandteilen hat. Unterlässt es solche Prüfungen, könnte das auch als Fahrlässigkeit gewertet werden.
• Produkthaftung: Schäden durch fehlerhaften Code können in seltenen Fällen auch unter das Produkthaftungsgesetz (ProdHaftG) fallen. Die Produkthaftung greift jedoch klassisch bei körperlichen Personen- oder Sachschäden, die durch einen Produktfehler verursacht werden. Ob rein digitale Produkte wie Software unter den Produktbegriff fallen, war lange umstritten. Nach aktueller Rechtslage ist Software als solche (ohne körperlichen Datenträger) nicht eindeutig als „Produkt“ i.S.d. § 2 ProdHaftG definiert. Das bedeutet, ein reiner Softwarefehler, der z.B. zum Datenverlust führt, löst derzeit regelmäßig keine Produkthaftung aus – hier bleibt es bei den deliktischen und vertraglichen Ansprüchen. Anders liegt der Fall, wenn KI-gesteuerte Software in ein körperliches Produkt integriert ist (etwa eine KI steuert eine Maschine oder ein Fahrzeug) und dadurch ein Unfall passiert: Dann kann das gesamte System als fehlerhaftes Produkt gelten, und der Hersteller haftet nach ProdHaftG. Wichtig ist: Die Produkthaftung ist verschuldensunabhängig (der Hersteller haftet bereits bei Fehlern im Produkt, ohne dass Fahrlässigkeit bewiesen werden muss). Daher kommt es insbesondere bei Personenschäden darauf an, ob man das KI-basierte System als Produkt qualifizieren kann. In Zweifelsfällen würde der Geschädigte aber ohnehin parallel deliktisch gegen das Startup vorgehen (etwa wegen Verletzung einer Verkehrspflicht). Vertraglich ausschließen lässt sich die ProdHaftG-Haftung nicht: § 14 ProdHaftG verbietet jede Vorausvereinbarung, die die Herstellerhaftung gegenüber dem Geschädigten ausschließt oder beschränkt; entsprechende Abreden sind nichtig. Ein Startup kann also durch AGB nicht seine Produkthaftung abbedingen – weder gegenüber Verbrauchern noch gegenüber Geschäftspartnern, soweit es um Ansprüche Geschädigter geht. Lediglich im Innenverhältnis (zwischen Hersteller und Zulieferer etwa) sind Regressvereinbarungen zulässig. Für KI-Startups bedeutet dies: Sollten ihre Produkte unter die Produkthaftung fallen, greifen die strengen Haftungsregeln zwingend – eine vertragliche Freizeichnung ist ausgeschlossen. Angesichts der bisherigen Unsicherheit, ob reine Software erfasst ist, war dies praktisch vielleicht kein Hauptthema; doch neue EU-Regeln (siehe unten Abschnitt 2) stehen bevor, die Software eindeutig einbeziehen werden.

Zwischenfazit: Ein Startup, das KI und No-Code beim Programmieren nutzt, haftet grundsätzlich wie jeder Softwarehersteller für Fehler und Schäden, obwohl die Codeerstellung automatisiert ist. Die Herausforderung besteht darin, ausreichende Sorgfaltsmaßnahmen (Qualitätstests, Code-Reviews, Lizenzprüfungen) trotz hoher Automatisierung einzuhalten. Automatisierung befreit nicht von Verantwortung – sie verschiebt nur die Art der Risiken. Fehlende menschliche Endkontrolle über die KI-Ergebnisse kann Haftungsrisiken erhöhen, da Fehler unentdeckt bleiben. Startups sollten daher vertraglich klar regeln, was sie zusichern (ohne unrealistische Garantien zu geben), aber auch wissen, dass sie sich nicht pauschal exkulpieren können. Letztlich trägt derjenige, der KI-Code in den Verkehr bringt, die Haftung für dessen Auswirkungen.

Haftung der Betreiber von No-Code-Plattformen und KI-Coding-Tools

Nicht nur die Startups selbst, sondern auch die Anbieter der No-Code-Plattformen oder KI-Coding-Tools könnten in den Blick geraten, wenn über ihre Systeme fehlerhafte oder schädliche Software generiert wird. Hier stellt sich die Frage, inwieweit die Plattform-Betreiber für Ergebnisse haften, die ihre Nutzer mit dem Tool erzeugen.

Grundsätzlich ist ein No-Code- oder KI-Code-Generator ein Werkzeug. Der Betreiber stellt die Infrastruktur und vielleicht vordefinierte Bausteine, der Nutzer (etwa das Startup) baut damit die konkrete Anwendung. Daher versucht die Branche, die Haftung vertraglich weitgehend auf die Nutzer abzuwälzen. Typischerweise enthalten die AGB solcher Dienste Klauseln, wonach der Nutzer für die Einhaltung aller Gesetze verantwortlich ist und der Plattformbetreiber keine Haftung für die Richtigkeit oder Tauglichkeit der erstellten Anwendungen übernimmt. Haftungsfreistellungen in B2B-AGB sind bis zu einem gewissen Grad zulässig – im Unterschied zum Verbrauchergeschäft greift § 309 BGB (Liste verbotener Klauseln) direkt nicht, doch § 307 BGB (Inhaltskontrolle) gilt auch zwischen Unternehmern. Eine gänzliche Freizeichnung des Anbieters für eigenes Verschulden dürfte auch in B2B-AGB unwirksam sein, sofern sie den Kunden unangemessen benachteiligt). Allerdings wird man unterscheiden: Für Fehler, die allein auf der konkreten Umsetzung des Nutzers beruhen, soll der Plattformanbieter typischerweise nicht haften – er wäre hier vergleichbar einem Werkzeughersteller, der nicht für jeden Missbrauch seines Werkzeugs einstehen muss. Anders könnte es aussehen, wenn die Plattform selbst einen Fehler aufweist, der zu Schäden führt (z.B. ein Software-Bug in der No-Code-Engine, der systematisch falsche Berechnungen in allen damit erstellten Apps verursacht). In so einem Fall rückt der Plattformanbieter in die Rolle eines Herstellers eines fehlerhaften Produkts. Dann kommen Mängelhaftung und ProdHaftG ins Spiel: Gegenüber seinem direkten Kunden (dem Startup) haftet der Anbieter nach Vertragsrecht dafür, dass sein Tool die vereinbarte Beschaffenheit hat und funktionstauglich ist. Gegenüber Dritten, die durch den Fehler der generierten Software geschädigt werden, könnte unter Umständen auch der Plattformbetreiber deliktisch haften, falls ihm ein eigenes Verschulden vorzuwerfen ist (z.B. grobe Fahrlässigkeit in der Programmierung der Plattform).

Vertragliche Haftungsbegrenzungen der Plattform-Betreiber: In der Praxis sichern sich Plattformanbieter in ihren Nutzungsbedingungen ab. Haftungsfreistellungen lauten etwa, dass der Anbieter nicht für indirekte Schäden, entgangenen Gewinn etc. haftet und insgesamt nur bis zu einem bestimmten Betrag. In B2B-Verträgen können solche Limitierungen (z.B. Deckelung der Haftungshöhe auf das Jahresentgelt) wirksam sein, sofern keine fundamental wichtigen Pflichten betroffen sind und kein vorsätzliches Verhalten ausgeschlossen wird ). Wichtig ist: Willful misconduct des Anbieters bleibt immer haftungspflichtig. Grobe Fahrlässigkeit kann ein Anbieter in AGB gegenüber einem Unternehmer in gewissem Umfang ausschließen, doch dies ist heikel – deutsche Gerichte neigen dazu, bei Klauseln, die auch grobe Fahrlässigkeit freistellen, eine unangemessene Benachteiligung anzunehmen (insbesondere, wenn der Anbieter faktisch alleinigen Einfluss auf die Fehlerquelle hat). Ferner darf auch in B2B die Haftung für Personenschäden nicht vertraglich ausgeschlossen werden, da dies gegen grundlegende Rechtsprinzipien verstößt (und in Verbraucherkonstellation ohnehin von § 309 BGB verboten wäre).

Produkthaftung der Tool-Anbieter: Wie oben erwähnt, war unklar, ob rein digitale Produkte unter das ProdHaftG fallen. Die Betreiber von No-Code-Plattformen konnten sich bislang darauf berufen, dass Software kein Produkt sei – eine Haftung nach dem ProdHaftG schien also nicht zu greifen. Doch diese Rechtslage steht vor einem Wandel auf EU-Ebene: Im Oktober 2024 wurde eine Novelle der EU-Produkthaftungsrichtlinie verabschiedet, die explizit Software (einschließlich KI-Systemen) als Produkt einstuft. Artikel 4 der neuen RL definiert Software klar als Produkt, sodass künftig in der EU (nach Umsetzung in nationales Recht) Hersteller von Software auch nach ProdHaftG haften müssen. Für Plattform-Betreiber bedeutet dies: Wenn ihr No-Code-Tool selbst fehlerhaft ist und z.B. einen Personenschaden verursacht (etwa die generierte Anwendung steuert ein Gerät fehl und jemand wird verletzt), kann der Geschädigte ab Umsetzung der neuen Richtlinie direkt den Tool-Anbieter auf Produkthaftung in Anspruch nehmen. Ein Haftungsausschluss ist dann ausgeschlossen – wie bereits das geltende deutsche Recht (§ 14 ProdHaftG) vorsieht. Zudem verschärft die RL die Herstellerhaftung: Nach Art. 11 Abs. 2 sollen Hersteller auch haften, wenn Produktfehler durch fehlende Software-Updates entstehen. Das ist relevant, falls der Plattformanbieter es versäumt, bekannte Sicherheitslücken in seinem System per Update zu beheben und dadurch Schaden verursacht wird.

Geplante EU-KI-Haftungsregeln: Neben der Produkthaftung verfolgt die EU einen umfassenden Ansatz zur Regulierung von KI. Die EU-KI-Verordnung (AI Act) wurde 2024 als erster globaler Rechtsrahmen für KI verabschiedet. Sie tritt großteils ab 2026 in Kraft  und verpflichtet Anbieter von KI-Systemen zu Risikobewertung, Transparenz und Sicherheitsvorkehrungen. Allerdings enthält die KI-VO keine unmittelbaren Haftungsregelungen  – sie ist ein Marktzulassungs- und Aufsichtsrecht, kein Haftungsrecht. Man findet darin keine neuen Deliktstatbestände; vielmehr sollen die Pflichten bei KI-Bereitstellung technisch-organisatorisch die Risiken vermindern. Ergänzend hatte die EU-Kommission 2022 eine KI-Haftungsrichtlinie (AI Liability Directive) vorgeschlagen, um opfern den Zugang zu Schadensersatz zu erleichtern. Diese sollte u.a. Beweiserleichterungen und Vermutungen zugunsten Geschädigter einführen – etwa einen Auskunftsanspruch, um den Entwickler eines KI-Systems zu identifizieren, und eine Kausalitätsvermutung, wenn eine KI-Pflichtverletzung wahrscheinlich zum Schaden führte . Insbesondere war geplant, bei Verstößen gegen die KI-VO (z.B. Nichteinhaltung vorgeschriebener Sicherheitsmaßnahmen) einen Anspruch nach § 823 Abs. 2 BGB i.V.m. der KI-VO als Schutzgesetz zu etablieren. Damit wären KI-Verstöße direkt zivilrechtlich sanktionierbar gewesen. Allerdings hat die neue EU-Kommission Ende 2024 entschieden, diesen Richtlinienentwurf vorerst zurückzuziehen.

Für Betreiber von No-Code-Plattformen ist wichtig: Sie müssen bereits nach KI-VO ggf. als Anbieter von Hochrisiko-KI-Systemen strenge Pflichten erfüllen (falls ihr Tool z.B. für sicherheitskritische Anwendungen eingesetzt wird). Haftungsrechtlich sollten sie sich aber nicht in falscher Sicherheit wiegen – auch wenn die spezielle KI-Haftungsrichtlinie gestoppt wurde, bleiben sie nach allgemeinem Recht angreifbar. Disclaimer-Klauseln helfen nur begrenzt: Eine KI kann nicht als “Verantwortliche” zwischengeschaltet werden, letztlich haftet immer ein menschlicher oder juristischer Akteur. Die Praxis wird zeigen, ob Geschädigte versuchen, Plattformanbieter verstärkt in die Pflicht zu nehmen, etwa mit dem Argument einer Produktähnlichkeit des angebotenen Tools oder einer Mitverursachung. Anbieter sollten daher vertraglich klar regeln, was der Nutzer zu tun hat (z.B. Testpflichten, Hinweispflichten bei Fehlfunktionen) und ggf. Rückgriffsmöglichkeiten vorsehen. Letztlich aber kann ein Plattformbetreiber, der grob pflichtwidrig ein unsicheres KI-Tool bereitstellt, nicht erwarten, sich durch AGB völlig zu exkulpieren – gesetzliche Leitplanken wie § 307 BGB, das ProdHaftG und zukünftig das EU-Haftungsregime setzen Grenzen, damit die Risiken nicht einseitig auf den Anwender abgewälzt werden.

Urheberrechtliche Schutzfähigkeit von KI-generiertem Code (VibeCoding)

Eine Kernfrage für Startups, die KI-Code nutzen, lautet: Ist der KI-generierte Code überhaupt urheberrechtlich geschützt? Nur wenn ein Programm Quellcode als persönliche geistige Schöpfung eines Menschen anzusehen ist, genießt es Schutz nach dem Urheberrechtsgesetz (UrhG). Das deutsche UrhG verlangt in § 2 Abs. 2 ausdrücklich, dass es sich beim Werk um eine „persönliche geistige Schöpfung“ handelt. Computerprogramme werden urheberrechtlich wie Sprachwerke geschützt (§ 2 Abs. 1 Nr. 1 i.V.m. § 69a UrhG), allerdings nur, wenn sie Schöpfungshöhe erreichen – d.h. ein Mindestmaß an Individualität durch menschliche Gestaltung aufweisen.

Bei vollständig KI-generiertem Code fehlt es gerade an diesem menschlichen Schöpfungsakt. Eine KI „denkt“ nicht kreativ im urheberrechtlichen Sinne, sondern erzeugt Inhalte anhand von Wahrscheinlichkeiten und Trainingsdaten. Nach geltendem Verständnis kann eine KI daher nicht Urheber sein. Der Bundesgerichtshof (BGH) hat in der Patentrechtssache DABUS 2024 klargestellt, dass eine Erfindung keinen nicht-menschlichen Erfinder haben kann. Diese Wertung lässt sich auf das Urheberrecht übertragen: Auch dort gilt das Schöpferprinzip, wonach der Urheber immer der menschliche Schöpfer des Werks ist. Autonom von KI geschaffene Werke – also Werke, die ohne jeden prägenden menschlichen Einfluss entstehen – sind zweifelsfrei nicht urheberrechtlich geschützt. Denn es fehlt „das menschliche Substrat“ in der Entstehung, wie es juristisch formuliert wurde Die europäischen Gerichte betonen, dass nur ein menschlicher Urheber Originalität im Rechtssinne schaffen kann. Der Europäische Gerichtshof (EuGH) definiert ein schutzfähiges Werk als Ergebnis der eigenen geistigen Schöpfung des Urhebers, was implizit einen Menschen voraussetzt. Beispielsweise hat der EuGH in Entscheidungen wie Infopaq ausgeführt, dass Individualität und kreative Entscheidungen des Autors wesentlich sind – beides kann eine Maschine nicht aufweisen.

Für VibeCoding-Code bedeutet dies: Sofern der Code ohne schöpferischen Beitrag eines Menschen generiert wurde, genießt er keinen Urheberrechtsschutz. Er wäre quasi gemeinfrei, von niemandem als eigenes Werk monopolisierbar. Jeder Dritte könnte solchen Code kopieren und nutzen, ohne das UrhG zu verletzen. Das hat gravierende Folgen für ein Startup: Der KI-Code könnte nicht exklusiv verwertet werden; Konkurrenten dürften ihn legal übernehmen, was die Wettbewerbsposition schwächt.

Allerdings ist die Realität oft komplexer. Selten entsteht Software völlig ohne menschliches Zutun. Meist gibt es einen Entwickler, der die KI promptet, lenkt, das Ergebnis auswählt, vielleicht Teile kombiniert oder nachbearbeitet. Die juristische Frage ist, ob dieser menschliche Beitrag ausreicht, um von einer Miturheberschaft oder Werkherrschaft des Menschen zu sprechen. Hier differenziert die Rechtsprechung und Literatur nach dem Grad der menschlichen Prägung:

• Autonome KI-Erzeugnisse: Wenn die KI wirklich eigenständig schafft und der Mensch nur einen allgemeinen Auftrag gibt („Schreibe mir ein Programm, das X tut“), dann liegt keine persönliche Schöpfung des Menschen vor. Ein einfaches Prompting („Entwickle Code für Funktion Y“) ohne konkrete inhaltliche Vorgaben wird dem Nutzer nicht die Urheberschaft verschaffen. Das Werk stammt dann geistig von der KI, weshalb mangels menschlichem Schöpfer kein Schutz entsteht.
• Computerimplementierte Werke mit KI-Unterstützung: Hier liefert der Mensch wesentliche Vorgaben, die KI dient nur als Werkzeug zur Umsetzung. Der BGH deutete im DABUS-Patentfall an, dass ein erheblicher menschlicher Einfluss eine Zurechnung ermöglichen kann Im Urheberrecht entspricht dies dem Fall, dass der Nutzer der KI bereits eine ausformulierte Idee oder Struktur vorgibt – etwa eigenen Quellcode-Entwurf oder detaillierte Anweisungen, die die KI nur verfeinert. Hier könnte man argumentieren, der Mensch habe die „geistige Schöpfung“ geliefert, die KI fungierte als verlängerter Arm (vergleichbar vielleicht einem Autocomplete, das der Mensch aber steuert). Der urheberrechtliche Schutz würde dann dem Menschen zukommen, sofern dessen Beitrag Schöpfungshöhe erreicht. Ein Beispiel: Ein Entwickler entwirft die Softwarearchitektur und Kernalgorithmen konzeptionell selbst (schöpferische Leistung), und nutzt dann KI, um Routinen auszuprogrammieren oder Code zu optimieren. In diesem Fall liegt im Ergebnis eine persönliche Prägung des Entwicklers vor, die sich im Code manifestiert – der Code wäre als Computerprogramm geschützt, und der Entwickler bzw. sein Unternehmen wäre Urheber bzw. Inhaber der ausschließlichen Rechte.
• Grenzfälle: Schwierig sind Konstellationen, in denen die KI und der Mensch eng verzahnt arbeiten. Hat der Mensch nur grobe Ideen skizziert und die KI generiert doch eigenständig den kreativen Codefluss? Oder hat der Mensch viele kleine Vorschläge der KI ausgewählt und zusammengesetzt (Kuratorrolle)? Hier stellt sich die Frage nach der Schöpfungshöhe des menschlichen Beitrags. Die derzeit herrschende Meinung sagt: Die bloße Auswahl oder Auftragserteilung („Mach mal Code für X“) reicht nicht für Urheberschaft. Es müsste ein qualitativ-schöpferischer Einfluss vorliegen. Wenn die KI den Großteil eigenständig erzeugt hat und der Mensch nur minimal korrigiert, wird man eher keinen Schutz annehmen. Im Zweifel bliebe der Code gemeinfrei, da keine ausreichende menschliche Gestaltung erkennbar ist.

Deutlich wird: Urheberrechtlicher Schutz von KI-Code ist möglich, aber nur wenn die KI wirklich als untergeordnetes Hilfsmittel agiert und der kreative Wertgehalt letztlich vom Menschen stammt). In vielen VibeCoding-Szenarien, wo Entwickler 95% des Codes von der KI generieren lassen, ist diese Schwelle wohl nicht erreicht – das Gros der kreativen Programmierleistung erbringt die Maschine, nicht der Mensch. Entsprechend werden die resultierenden Codebestandteile schutzlos sein.

Diese Einschätzung spiegelt sich auch in Expertenempfehlungen wider: Unternehmen wird geraten, vertraglich und organisatorisch zu klären, wie mit KI-Output umgegangen wird, da „KI-Output in der Regel nicht geschützt“ ist. Man kann daran „keine Rechte geltend machen“, was für die kommerzielle Verwertung entscheidend ist. Startups sollten sich dessen bewusst sein: Code, den ein KI-System erzeugt hat, bietet unter Umständen keinen urheberrechtlichen Abwehrschirm gegen Nachahmer. Es verbleiben allenfalls alternative Schutzmechanismen wie Geschäftsgeheimnisschutz (wenn der Code geheim gehalten wird) oder Patente für zugrundeliegende technische Lösungen (wobei KI-erzeugte Erfindungen wieder das Dilemma mit dem Erfinder haben – analog DABUS muss dann ein menschlicher Erfinder benannt werden, der den KI-Einsatz wesentlich gesteuert hat.

Zusammenfassend: Ohne menschliche Kreativität kein Urheberrechtsschutz. KI-generierter Code fällt damit oft in eine Schutzlücke. Ein Startup muss daher genau prüfen, welchen Anteil menschliche Entwickler an einem KI-erstellten Code haben und diese Anteile dokumentieren, um im Streitfall überhaupt einen Schutz argumentieren zu können. Andernfalls riskiert es, dass sein zentrales Softwareprodukt rechtlich als „frei verfügbar“ angesehen wird – was die Investitions- und Innovationsschutzstrategien erheblich beeinträchtigt.

Auswirkungen auf Legal Due Diligence bei Venture-Investments

Für Investoren und deren juristische Berater in einer Legal Due Diligence (LDD) ist der Umgang eines Startups mit KI-generiertem Code ein wachsendes Augenmerk. In Finanzierungsrunden oder bei Tech-M&A prüft man sorgfältig die IP-Position und Haftungsrisiken des Zielunternehmens. Wenn ein Startup stark auf automatisierte Codegenerierung (VibeCoding) setzt, ergeben sich hierbei besondere Erschwernisse:

a) Fehlende IP-Schutzrechte und Wertminderung: Wie oben dargelegt, kann KI-generierter Code oft nicht als geistiges Eigentum geschützt werden. Für Investoren, die in ein Software-Startup investieren, ist jedoch die Einzigartigkeit und Rechtssicherheit des Codes ein wichtiger Wertfaktor. Hat das Startup keine patentierbaren Erfindungen und noch dazu keinen urheberrechtlich geschützten Code (weil viel von der KI stammt), fehlen ihm wesentliche Schutzmechanismen gegen Wettbewerber. Jeder Konkurrent könnte den offenbarten Code nachnutzen, ohne Lizenz zu zahlen. In einer Due Diligence wird dies als Schwäche identifiziert – das IP-Portfolio wirkt dünn. Typischerweise fragen Investoren gezielt: „Welche urheberrechtlich geschützten Software-Komponenten oder Patente besitzt das Startup? Sind alle Rechte an der Software geklärt?“ Wenn die Antwort lautet, die Software sei größtenteils KI-generiert und daher quasi gemeinfrei, schrillen Alarmglocken. Das Startup besitzt dann vor allem Know-how, Marke oder Kundenzugang, aber keinen exklusiven Code. Aus Investorensicht kann dies die Bewertung drücken, da zukünftige Wettbewerbsvorteile unsicher sind. Zudem wird man im Beteiligungsvertrag auf umfangreiche Garantien dringen, dass kein Dritter Rechte am Code geltend machen kann – was schwer zu versichern ist, wenn es eigentlich gar keine eigenen Rechte gibt.

b) Unklare Urheber- und Lizenzketten: Ein Due-Diligence-Team wird genau prüfen, wer als Urheber der Software gilt und ob alle Rechte wirksam übertragen wurden. Bei klassischen Startups gibt es in der Regel Entwickler (Angestellte oder Freelancer), die per Vertrag ihre Urheberrechte an den Auftraggeber abtreten (§ 69b UrhG bei Programmen). Bei KI-generiertem Code stellt sich: Wem sollen Rechte übertragen werden, wenn die KI keinen Urheberstatus hat? Oftmals erklären die Anbieter von KI-Coding-Tools in ihren Nutzungsbedingungen, dass der Nutzer die Rechte am Output erhält. Doch solche Klauseln haben rechtlich eher deklaratorische Wirkung – sie können kein Urheberrecht schaffen, wo keines ist. Bestenfalls wirken sie als vertragliche Zusage, dass der Tool-Anbieter keine eigenen Ansprüche erhebt und dem Nutzer die Nutzung gestattet. In der Due Diligence müsste man diese Nutzungsbedingungen sichten, um sicherzustellen, dass kein Catch verborgen ist (z.B. dass der Plattformbetreiber doch gewisse Nutzungsrechte behält). Außerdem prüfen Investoren, ob alle menschlichen Mitwirkenden (z.B. prompt-engineers oder Mitarbeiter, die KI-Ergebnisse kuratiert haben) Arbeits- oder Dienstverträge mit IP-Klauseln haben, damit das Unternehmen jedenfalls alle etwaigen entstehenden Rechte innehat. Ein Risiko wäre z.B., wenn ein freier Berater Prompts erstellt hat, die KI daraus Code generierte und dieser Berater später Ansprüche auf Miturheberschaft erhebt, weil sein Beitrag schöpferisch war. Aufgrund der Unsicherheit werden Investoren verlangen, dass das Startup alle Beteiligten rechtlich gebunden hat (via IP-Assignment und Vertraulichkeitsvereinbarungen).

c) Risiken durch Open-Source- und Drittcode: Ein besonders heikler Punkt in der DD sind Open-Source-Compliance und mögliche Verletzungen fremder Rechte. Bei traditionell entwickelter Software untersucht man, welche Open-Source-Komponenten verwendet wurden und ob Lizenzen (GPL, MIT, etc.) eingehalten wurden. Bei KI-generiertem Code ist das schwieriger, da das Startup möglicherweise gar nicht weiß, wenn und welche fremden Code-Snippets eingeflossen sind. Wie Chan-jo Jun (IT-Anwalt) hervorhebt, hat KI-Code oft erhebliche Ähnlichkeit mit dem Trainingsmaterial, je nach Lizenz des Ursprungsmaterials kann das bedeuten, dass der neue Code ebenfalls lizenzpflichtig ist. In der Due Diligence werden versierte Prüfer daher fragen: „Setzt Ihr KI für Code ein? Wenn ja, welche Maßnahmen habt ihr getroffen, um lizenzrechtliche Risiken auszuschließen?“ Sie könnten verlangen, dass der Code einer Audit-Prüfung unterzogen wurde, etwa durch Tools, die Quellcode mit bekannten Repositories abgleichen (Black Duck, Fossology etc.). Chan-jo Jun empfiehlt Käufern ausdrücklich, KI-generierten Code zeilenweise auf Übereinstimmungen mit vorhandener Software zu prüfen. Finden sich dabei identische oder sehr ähnliche Abschnitte, muss geklärt werden, ob diese unbedenklich sind (z.B. triviale Codezeilen, die keinen Schutz genießen) oder ob eine Lizenzverletzung droht. Das Ergebnis einer solchen Prüfung kann ein Dealbreaker sein: Wenn herauskommt, dass zentrale Teile des Codes eigentlich unter GPL stehen müssten oder proprietären Dritten gehören, verlangt der Investor entweder Bereinigung (Re-Implementierung der betreffenden Teile ohne KI) oder bewertet das rechtliche Risiko als zu hoch, um zu investieren. Bereits in der frühen Phase kann ein VC im Term Sheet zusichern lassen, dass kein wesentlicher Teil der Technologie auf problematischen KI-Outputs beruht – andernfalls drohen Schadensersatzansprüche gegen die Gründer nach Vertrag.

d) Reputations- und Haftungsrisiken: Investoren betrachten auch das Haftungsrisiko und die damit verbundene finanzielle Exponierung. Falls ein Startup Software vertreibt, die mit KI-Unterstützung entwickelt wurde, wird in der Due Diligence auch geprüft, ob es bereits Haftungsfälle gab oder drohen. Beispielsweise: Gab es Kundenbeschwerden oder Schadensfälle im Zusammenhang mit einem Softwarefehler? Gibt es vertragliche Haftungsbegrenzungen und sind diese wirksam? Ein Startup, das fahrlässig unsicheren KI-Code ausgeliefert hat, könnte latent mit Haftungsprozessen konfrontiert werden – das schreckt Investoren ab. Sie werden wissen wollen, ob das Startup Versicherungen (z.B. Produkthaftpflicht, Tech E&O) abgeschlossen hat, um solche Risiken zu decken. Zudem spielt die künftige Regulierungslandschaft eine Rolle: Ein Investor, der ein Startup 2025 finanziert, muss antizipieren, welche Compliance-Pflichten und Haftungsregeln in den nächsten Jahren greifen. Die EU-KI-Verordnung etwa wird ab 2026 einzuhalten sein, was für ein auf KI-Code spezialisiertes Unternehmen ggf. Registrierungs- und Dokumentationspflichten bedeutet. Wenn das Startup hier ignorant wäre, wäre das ein rotes Tuch in der Due Diligence. Ebenso die kommende Produkthaftungsreform: Die Investoren werden einpreisen, dass ab Geltung der neuen Regeln Schadensfälle teurer werden könnten, weil dann auch Softwarehersteller ohne Verschulden haften.

e) Empfehlungen und Maßnahmen: Aus der Investorensicht werden typischerweise folgende Feststellungen und Auflagen in einer Due Diligence gemacht, wenn stark automatisierte Softwareentwicklung vorliegt:

• Transparenz über KI-Einsatz: Das Startup sollte offenlegen, in welchem Umfang und für welche Komponenten KI eingesetzt wurde. DD-Berater fordern oft eine Liste aller KI-Tools und eine Einschätzung, welcher Code-Anteil davon stammt. Nur so kann man den Umfang des potenziell ungeschützten Codes abschätzen .
• IP-Policy und Kontrollen: Hat das Startup interne Richtlinien, wie mit KI-Outputs umzugehen ist? (Etwa eine Vorgabe: „Kein ungeprüfter KI-Code direkt in Produktivsystem übernehmen.“) Ein verantwortungsbewusstes Startup implementiert Qualitätskontrollen, um die Risiken zu mindern. Dazu zählen Code-Reviews auch für KI-generierten Code, Einsatz von Plagiatsscannern und Dokumentation aller KI-Einsätze (Nachvollziehbarkeit). In der LDD werden solche Policies positiv vermerkt, da sie zeigen, dass das Management das Thema erkannt hat.
• Rechtsmeinung zur Urheberrechtssituation: Gegebenenfalls lässt sich das Startup von einem Juristen bestätigen, wie es die Schutzrechtslage sieht. Zwar bleibt die Unsicherheit, aber ein Investor hört lieber, dass zumindest geprüft wurde, ob ein ausreichender menschlicher Beitrag an kritischem Code vorhanden ist. Falls nein, muss ein Alternativschutz her: Viele Startups setzen dann verstärkt auf Geheimhaltung (Trade Secrets). Der Due-Diligence-Prozess schaut dann, ob z.B. der Quellcode nicht publik ist, ob Maßnahmen nach GeschGehG (Gesetz zum Schutz von Geschäftsgeheimnissen) getroffen wurden. Wenn kein Urheberrecht greift, kann ein Geschäftsgeheimnis-Schutz wenigstens verhindern, dass Dritte unautorisiert an den Code gelangen – vorausgesetzt, das Startup schützt ihn entsprechend (Zugriffskontrollen, NDA mit Partnern etc.).
• Versicherungen und Freistellungen: Investoren werden fordern, dass das Startup für den Fall von IP-Streitigkeiten oder Produkthaftungsfällen Versicherungsschutz hat oder dass die Gründer bis zu einem gewissen Grad persönlich haften, falls sie Risiken verschwiegen haben. In Beteiligungsverträgen sind Gewährleistungen üblich, z.B. dass der gesamte eigene Code frei von Ansprüchen Dritter ist. Wenn Gründer wissen, dass sie KI-Code genutzt haben, müssen sie diese Gewährleistung sehr vorsichtig formulieren – schlimmstenfalls müssen sie Ausnahmen (Disclosure Schedules) angeben, was wiederum dem Investor das Problem offenlegt.
• Zukünftige IP-Strategie: Ein Startup, das bislang auf KI-Code setzte, sollte bei Due Diligence erläutern können, wie es künftig sein IP stärken will. Das könnte sein: gezielte Eigenentwicklungen besonders kritischer Komponenten, Patentstrategien für KI-entwickelte Erfindungen (mit Nennung menschlicher Erfinder, um Patentfähigkeit sicherzustellen), oder exklusive Trainingsdaten, die andere nicht haben. Investoren wollen sehen, dass das Startup einen Plan hat, um trotz Automatisierung einzigartige Assets zu schaffen.

f) Spezifische Erschwernisse bei stark KI-lastigen Startups: Wenn ein Startup in kurzer Zeit mit wenig Personal eine komplexe Software erstellt hat, die auf KI-Generierung beruht, mag das betriebswirtschaftlich beeindruckend sein – in der juristischen Due Diligence hingegen macht es skeptisch. Typische Risiken sind:

• Codequalität und Wartbarkeit: Zwar kein primär juristischer Punkt, aber Tech-Due-Diligence und Legal DD verzahnen sich hier. KI-generierter Code könnte schwer wartbar oder verständlich sein, gerade wenn kein Entwickler ihn ganz durchdringt. Das kann zu Verzögerungen beim Beheben von Mängeln führen – was wiederum juristisch relevant wird, wenn z.B. vertragliche Service-Level oder Gewährleistungsfristen nicht eingehalten werden können.
• Abhängigkeit von Drittanbietern: Setzt das Startup fremde KI-APIs (z.B. von OpenAI, Google) ein, dann besteht eine vertragliche Abhängigkeit. Die Due Diligence prüft: Hat das Startup stabile Lizenzbedingungen mit diesen Anbietern? Was, wenn der Dienst eingestellt wird oder die Konditionen ändern (Preise, Nutzungsrechte am Output)? Diese Fragen gehen über klassisches IP hinaus, betreffen aber operationelle Risiken, die im Investment berücksichtigt werden.
• Regulatorisches Umfeld: Bei sehr innovativen KI-Startups schauen Investoren auch nach zukünftigen Regulierungskosten. Etwa: Fällt das Produkt in den Anwendungsbereich der KI-VO (evtl. als generative AI, möglicherweise mit Pflichten zur Anmeldung oder Konformitätsbewertung)? Kommen Zertifizierungspflichten auf das Unternehmen zu? In der Due Diligence kann z.B. festgestellt werden: „Das Unternehmen muss innerhalb von 2 Jahren ein KI-Compliance-System implementieren, Kosten ca. XYZ.“ Solche Aspekte werden dann in der Bewertung berücksichtigt oder als Bedingungen (Conditions Subsequent) im Investmentvertrag festgehalten.

Fazit zu Due Diligence: Für Gründer bedeutet dies, dass ein starker KI-Einsatz in der Softwareentwicklung zwar die Entwicklung beschleunigt, aber später beim Investmentprozess Mehraufwand und Unsicherheit schafft. Viele der Vorteile (schnell viel Code erzeugt) müssen dann gegen die Nachteile (weniger klare IP-Lage, potenzielle Rechtsrisiken) abgewogen werden. Aus Investorensicht ist ein Startup am attraktivsten, wenn es einerseits die Effizienz von KI nutzt, andererseits aber proaktiv die juristischen Hausaufgaben gemacht hat: also Compliance-Richtlinien eingeführt, IP-Rechtsfragen durchdacht, Vertragswerke (AGB, Lizenzverträge) entsprechend angepasst und Risikoversorge betrieben hat. Ein solches Unternehmen kann im DD-Prozess überzeugen, dass es trotz VibeCoding „investierbar“ ist. Im Gegensatz dazu dürfte ein Startup, das naiv davon ausging „der KI-Code gehört schon uns und wird schon passen“, erhebliche Schwierigkeiten bei der Prüfung bekommen. Im schlimmsten Fall führen ungeklärte IP-Verhältnisse oder schwebende Haftungsrisiken dazu, dass ein Investor abspringt oder nur zu deutlich schlechteren Konditionen einsteigt.

Schlussbetrachtung

Die Verwendung von KI und No-Code-Plattformen in Tech-Startups bewegt sich derzeit schneller als der Rechtsrahmen. Haftungsfragen sind nach wie vor anhand allgemeiner Prinzipien zu beantworten – wer KI-Tools einsetzt, haftet für deren Output wie für eigenes Handeln . Weder Startups noch Plattformbetreiber können sich hinter der „Verantwortung“ einer Maschine verstecken. Zivilrechtlich greifen die bewährten Normen (§ 823 BGB, Produkthaftung, Vertragspflichten), die jedoch flexibel genug sind, um auf KI-Konstellationen angewandt zu werden. Die kommenden EU-Regeln – allen voran die KI-Verordnung 2024/1689/EU und die novellierte **Produkthaftungsrichtlinie (voraussichtlich 2024/2853/EU) – werden den Rahmen weiter konkretisieren, ohne ihn auf den Kopf zu stellen. KI-Systeme werden reguliert und Softwareprodukte ausdrücklich in die Herstellerhaftung einbezogen, was Verantwortlichkeiten eher verschärft als mindert. Die ausdrücklich geplante, dann aber zurückgezogene KI-Haftungsrichtlinie zeigt, dass der Gesetzgeber um Erleichterungen für Geschädigte rang, diese aber vorerst der Entwicklung überlässt.

Urheberrechtlich offenbart VibeCoding eine Schutzzone: Solange kein menschlicher schöpferischer Beitrag vorliegt, bleibt KI-Code schutzlos. Für Startups bedeutet das, dass ihr „USP“ schwerer rechtlich zu sichern ist. Innovative Lösungen könnten künftig in Erwägung gezogen werden – etwa neue Schutzrechtskategorien oder Anpassungen im Urheberrecht, was jedoch kontrovers wäre (derzeit hält man bewusst daran fest, den Schutz an die menschliche Kreativität zu knüpfen. International gibt es unterschiedliche Ansätze (bspw. erkennt das britische Copyright Law sog. computer-generated works mit kurzer Schutzdauer an, wohingegen das US Copyright Office KI-Werke ablehnt), aber in Deutschland/EU dürfte vorerst die Linie bleiben: kein Schutz ohne menschlichen Autor.

Für die Legal Due Diligence bei Investitionen in KI-lastige Startups heißt dies, dass Sorgfalt und Transparenz essenziell sind. Startups sollten idealerweise schon vor einer Finanzierungsrunde ihre rechtlichen Risiken auditieren und bereinigen. Dazu gehört, KI-generierte Codebestandteile zu identifizieren, zu überprüfen und – wo nötig – zu ersetzen oder abzusichern. Auch sollten sie ihre Verträge (mit Kunden, Lieferanten, Plattformen) so gestalten, dass KI-Einsatz geregelt ist (z.B. Disclaimer, soweit zulässig, und Informationspflichten gegenüber Kunden, falls KI genutzt wurde). Im Umgang mit No-Code-Plattformen empfiehlt es sich, auf vertragliche Zusicherungen der Anbieter zu achten (etwa, dass deren Tool keine Rechte Dritter verletzt und dem Stand der Technik entspricht). Manche KI-Plattformen bieten inzwischen Haftungsübernahmen oder Garantien an, um vertrauenswürdiger zu wirken – diese sollten genutzt werden, wo möglich, um eigene Risiken zu reduzieren.

Insgesamt zeigt sich: Haftung und IP beim VibeCoding sind komplex, aber beherrschbar, wenn man die traditionellen Rechtsgrundsätze sorgfältig auf die neue Technologie anwendet. Für Gründer und Entwickler lautet die Botschaft, proaktiv juristische Expertise einzubeziehen, statt erst im Streitfall reagieren zu müssen. Investoren wiederum müssen neue Bewertungskriterien entwickeln, um den Wert eines Unternehmens zu ermessen, dessen Produkte zwar technisch innovativ sind, aber vielleicht kein klassisches IP-Portfolio haben. Möglicherweise verschiebt sich der Wert von statischem IP hin zu dynamischer Fähigkeit, schnell mit KI zu entwickeln – doch solange Rechtssysteme Wettbewerbsvorteile stark an rechtliche Ausschließlichkeit knüpfen, bleibt fehlender IP-Schutz ein harter Faktor.

Zum Schluss sei betont, dass die technologische Entwicklung rasant ist: Ebenso schnell sollten Startups ihre Compliance und Vertragswerke weiterentwickeln. Die geplanten EU-Regelungen werden voraussichtlich 2026ff. wirksam – kluge Unternehmer nutzen die Übergangszeit, um ihre KI-gestützten Prozesse so aufzusetzen, dass sie dann konform und abgesichert sind. Dann steht dem vollen Potenzial von VibeCoding nichts im Wege – ohne böse juristische Überraschungen.