Sie haben es mit Lovable gebaut — wer ist verantwortlich, wenn Daten durchsickern?

Eine Produktmanagerin benötigt ein internes Dashboard. Statt ein Ticket einzureichen und ein Quartal auf die Entwicklung zu warten, öffnet sie Lovable, beschreibt in einfachem Englisch, was sie möchte, verbindet es mit dem Google Workspace des Unternehmens und liefert noch am selben Nachmittag eine funktionierende App. Diese liest aus Drive, zieht ein paar Tabellen und verschickt wöchentlich eine Zusammenfassung per E-Mail. Es funktioniert. Alle sind zufrieden.

Niemand stellt die Frage, die sechs Monate später wichtig wird, wenn ein Sicherheitsprüfer oder eine Aufsichtsbehörde sie stellt: Wer ist dafür verantwortlich, wie diese App mit den Daten umgeht, mit denen sie in Berührung kommt?

Die Antwort lautet nicht: die Plattform, die den Code generiert hat. Es ist das Unternehmen, das die App eingesetzt hat. Dieser Artikel erklärt, warum „Wir haben es mit KI gebaut“ keine Verteidigung ist, was bei KI-gebauten Apps konkret schiefgeht, und wie Sie sich Transparenz verschaffen, bevor die Frage im Ernstfall gestellt wird.

Was „KI-gebaute App“ tatsächlich bedeutet

Eine neue Kategorie von Tools — Lovable, Base44, Bolt.new, Cursor und eine wachsende Liste weiterer — ermöglicht es Menschen, aus natürlichsprachlichen Prompts echte Webanwendungen zu bauen und bereitzustellen. Sie werden oft als „Vibe-Coding“-Plattformen bezeichnet. Der Reiz liegt auf der Hand: Eine Person ohne Entwicklerhintergrund kann etwas produzieren, wofür früher ein ganzes Team nötig war, und das in wenigen Stunden.

Diese Apps sind kein Spielzeug. Sie werden für echte Nutzer bereitgestellt und verbinden sich routinemäßig über gewöhnliche OAuth-Freigaben mit echten Unternehmenssystemen — Google Workspace, Salesforce, interne Datenbanken. Aus Sicht der Daten sehen eine an einem Nachmittag mit einem Prompt gebaute App und eine über Monate von einem Entwicklerteam gebaute App identisch aus: Beide besitzen ein Zugriffstoken, und beide können lesen, was dieses Token erlaubt.

Diese Symmetrie ist der Kern des Problems. Die Geschwindigkeit, die KI-Builder attraktiv macht, ist dieselbe Geschwindigkeit, die einer App Zugriff auf sensible Daten verschafft, ohne dass jemand überprüft, was sie mit diesen Daten tut.

Mit KI zu bauen ist nicht dasselbe wie sicher zu sein

Es lohnt sich, hier präzise und fair zu bleiben: Eine mit Lovable oder Base44 gebaute App ist nicht per se unsicher. Diese Plattformen können durchaus vernünftige Anwendungen hervorbringen, und viele tun das auch. Das Risiko besteht nicht darin, dass die KI schlechten Code schreibt. Das Risiko ist die Governance, und sie zeigt sich auf drei vorhersehbare Arten.

Die Person, die die App bereitstellt, liest selten den Code. Das gesamte Wertversprechen von Vibe-Coding besteht darin, dass Sie das nicht müssen. Die Person, die die App ausgeliefert hat, kann also oft nicht sagen, wie Daten gespeichert werden, ob sensible Felder protokolliert werden, wohin Informationen gesendet werden oder wie lange irgendetwas aufbewahrt wird. Die verantwortliche Partei hat den geringsten Einblick in genau das, wofür sie verantwortlich ist.

Der Zugriff ist weitreichend und unsichtbar. KI-Builder fordern die Berechtigungen an, die die Demo zum Laufen bringen, und „zum Laufen bringen“ bedeutet oft weitreichenden Lesezugriff. Ein internes Dashboard, das nur einen einzigen Ordner lesen musste, verfügt möglicherweise über Lesezugriff auf das gesamte Drive. Da die Freigabe über einen normalen OAuth-Zustimmungsbildschirm erfolgte, erschien sie nie auf dem Sicherheitsradar irgendeiner Person — sie ist per Definition Schatten-IT.

Es gibt keine dokumentierte Richtlinie zum Umgang mit Daten. Fragen Sie nach der Aufbewahrungsrichtlinie eines von Hand gebauten Produktivsystems, und Sie erhalten in der Regel eine Antwort. Fragen Sie nach der Aufbewahrungsrichtlinie einer App, die ein Kollege letzten Dienstag generiert hat, und es gibt nichts Dokumentiertes. Nach Datenschutzrecht ist „Wir wissen nicht, wie lange die Daten aufbewahrt werden“ keine neutrale Antwort — es ist ein Befund.

Warum das Unternehmen — nicht die Plattform — in der Verantwortung steht

Hier kommt der Teil, der Menschen überrascht. Wenn eine KI-gebaute App Daten falsch handhabt, landet die rechtliche und regulatorische Verantwortung bei der Organisation, die sie eingesetzt hat, nicht beim KI-Builder, der sie generiert hat.

Dies ist derselbe Verantwortungswechsel, der derzeit das KI-Recht insgesamt neu gestaltet. Nach der Datenschutz-Grundverordnung der EU ist die Stelle, die über Zwecke und Mittel der Verarbeitung personenbezogener Daten entscheidet, der Verantwortliche (data controller), und der Verantwortliche trägt die Pflichten — Rechtsgrundlage, Datenminimierung, Speicherbegrenzung und die Pflicht, all dies nachzuweisen. Wenn Ihr Unternehmen eine App einsetzt, die Kundendaten verarbeitet, ist Ihr Unternehmen der Verantwortliche. Die Builder-Plattform ist bestenfalls ein Werkzeug, das Sie genutzt haben.

Die breitere rechtliche Landschaft 2026 weist in dieselbe Richtung. Gerichte haben begonnen, das Unternehmen, das ein KI-System nutzt, für dessen Verhalten verantwortlich zu machen — der Rechtsstreit *Mobley v. Workday* in den Vereinigten Staaten wurde auf Grundlage einer Vertretungstheorie (Agency-Theorie) fortgeführt und erhielt später die vorläufige Zulassung als landesweite Sammelklage (collective action). In Deutschland befasste sich das OLG Hamm mit der Verantwortung dafür, was ein KI-System Kunden mitteilt, und signalisierte, dass ein allgemeiner „Keine Gewähr“-Haftungsausschluss das einsetzende Unternehmen allein nicht schützt. Der EU AI Act legt darüber hinaus einsatzspezifische Pflichten für Betreiber fest, mit erheblichen Sanktionen bei Hochrisiko-Anwendungen. Wir behandeln diesen Wandel ausführlich in unserem Überblick darüber, wer haftet, wenn ein KI-Agent Daten leakt.

Der gemeinsame Nenner: Der Einsatz einer KI-gebauten App ist eine Entscheidung, die Ihre Organisation getroffen hat, und das Recht behandelt Entscheidungen als verantwortungsbehaftet. Die Tatsache, dass eine KI den Code geschrieben hat, ändert nichts daran, wer entschieden hat, sie mit Unternehmensdaten zu verbinden.

Der blinde Fleck, konkret

Setzt man die Teile zusammen, ergibt sich ein spezifisches, häufiges Fehlermuster:

• Eine nicht-technische Mitarbeiterin baut eine App mit einem KI-Builder.
• Die App verbindet sich über OAuth mit Google Workspace und erhält weitreichende Berechtigungen.
• Sie erreicht personenbezogene Daten von Kunden oder Mitarbeitern — Kontakte, E-Mail-Inhalte, Dateien.
• Niemand hat den Umgang mit den Daten überprüft, und es gibt keine dokumentierte Aufbewahrungsrichtlinie.
• Die Sicherheitsabteilung hat keinen Eintrag für die App im Inventar, da sie nie einer Prüfung unterzogen wurde.

Jeder einzelne Schritt ist für sich genommen nachvollziehbar. Zusammen ergeben sie eine Anwendung, die personenbezogene Daten verarbeitet, für die Ihr Unternehmen rechtlich verantwortlich ist und von deren Existenz Ihr Sicherheitsteam nichts weiß. Das ist die Lücke, die ein Prüfer aufspürt und ein Sicherheitsvorfall ausnutzt.

Wie Sie die Lücke schließen

Die Lösung besteht nicht darin, KI-Builder zu verbieten — dieses Rennen ist bereits verloren, und der Produktivitätsgewinn ist real. Die Lösung ist Transparenz und Nachweisbarkeit: wissen, welche KI-gebauten Apps verbunden sind, wissen, worauf jede zugreifen kann, und belegen können, dass Sie sie governiert haben.

Genau das leistet 8200.dev. Es erkennt die OAuth-Apps, die mit Ihrem Google Workspace verbunden sind, und markiert diejenigen, die von KI-Buildern stammen — Lovable, Base44, Bolt.new, Cursor und ähnliche — anhand ihrer App-Namen- und Redirect-Host-Signaturen sowie anhand des verräterischen Musters einer nicht verifizierten, kürzlich erstellten App, die bereits über weitreichende Berechtigungen verfügt. Für jede sehen Sie die Builder-Plattform, die genau erteilten Berechtigungen, wer sie autorisiert hat, und einen Risikowert — dargestellt in einer eigenen AI-Built Apps-Ansicht neben dem Rest Ihrer KI-Agenten und OAuth-Apps.

Wenn eine KI-gebaute App auf personenbezogene Kundendaten zugreifen kann oder weitreichenden Zugriff ohne dokumentierte Aufbewahrungsrichtlinie hält, löst dies einen konkreten Befund aus — sodass die Lücke zu einer Aufgabe mit Verantwortlichem wird, statt zu einer Überraschung im Audit. Und jede KI-gebaute App kann im AI Agent Registry erfasst werden, sodass selbst die, die kein Connector erreicht, in einem vollständigen Inventar erscheinen. Sie können hier den vollständigen Funktionsumfang einsehen.

Es geht nicht darum, Ihre Teams auszubremsen. Es geht darum, sicherzustellen, dass Sie die Frage beantworten können, wenn sie kommt — von einer Aufsichtsbehörde, einem Prüfer oder einer Kunden-Sicherheitsprüfung. Nicht „Wir haben es mit KI gebaut, also ist es das Problem der Plattform“, was keine Verteidigung ist, sondern: „Hier ist die App, hier ist genau, worauf sie zugreifen kann, und hier ist der Nachweis, dass wir sie geprüft haben.“ Für einen tieferen Einblick, was Prüfer heute erwarten, siehe was Auditoren 2026 für KI-Governance verlangen.

Mit KI zu bauen geht schnell. Für das Gebaute verantwortlich zu sein, ist keine Option. Beides lässt sich durch eine Sache vereinbaren: zu wissen, worauf Ihre KI-gebauten Apps tatsächlich zugreifen können.

Beginnen Sie damit, zu sehen, was bereits mit Ihrem Workspace verbunden ist. Sie können Ihre KI-gebauten Apps kartieren, deren Zugriff bewerten und im kostenlosen Tarif Ihren ersten Nachweis erstellen — Tarife ansehen und kostenlos starten.

*Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Wenden Sie sich für auf Ihre Organisation zugeschnittene Beratung an qualifizierte Rechtsberater.*