Ist Lovable DSGVO-konform? AVV, Serverstandort und was eure App selbst erfüllen muss

„Ist Lovable DSGVO-konform?“ klingt nach einer Ja-Nein-Frage. Ist es nicht. Die DSGVO verpflichtet nicht das Werkzeug, sondern den Verantwortlichen — also euch, sobald eure App personenbezogene Daten verarbeitet. Lovable sagt das in der eigenen Datenschutzerklärung ziemlich direkt: Wer eine App baut, „decides what data it collects and why, so they are responsible for that data“.

Ebene 1 — das Werkzeug. Euer Lovable-Konto, eure Prompts, euer Code. Hier ist Lovable Vertragspartner, und es geht um den AVV, um Drittlandtransfer und um die Frage, ob eure Inhalte zum Training von KI-Modellen genutzt werden.

Ebene 2 — das Backend eurer App. Die Datenbank, in der die Daten eurer Nutzer liegen: Lovable Cloud oder ein eigenes Supabase-Projekt. Hier entscheidet sich, wo die Daten physisch gespeichert werden und ob die Datenbank sie gegen fremden Zugriff schützt.

Ebene 3 — eure App selbst. Impressum, Datenschutzerklärung, Einwilligung für Tracker, Kennzeichnung von KI, Barrierefreiheit. Diese Pflichten habt ihr gegenüber euren Besuchern, egal mit welchem Werkzeug die App gebaut ist. Und hier entstehen in der Praxis die meisten Abmahnungen — weil man sie von außen sieht.

Sobald ein Dienstleister personenbezogene Daten in eurem Auftrag verarbeitet, braucht ihr einen Vertrag nach Art. 28 DSGVO — den Auftragsverarbeitungsvertrag. Er legt fest, dass der Dienstleister nur auf eure Weisung arbeitet, die Daten schützt, Unterauftragnehmer offenlegt und am Ende löscht. Bei einer Lovable-App ist das spätestens dann der Fall, wenn sich Nutzer registrieren, Formulare abschicken oder Daten in Lovable Cloud landen.

Bei Lovable steht auf der DPA-Seite wörtlich: „If you're on a Business or Enterprise plan, your usage includes our Data Processing Agreement.“ Zu Free und Pro sagt die Seite nichts. Wer auf diesen Tarifen echte Nutzerdaten verarbeitet, sollte das schriftlich mit Lovable klären oder den Tarif wechseln, bevor die App live geht — nicht danach.

Bei Supabase ist es einfacher: Der DPA ist Teil der Nutzungsbedingungen und gilt mit deren Annahme, inklusive der EU-Standardvertragsklauseln. Ihr müsst nichts unterschreiben, solltet die aktuelle Fassung aber herunterladen und ablegen — im Ernstfall müsst ihr nachweisen können, auf welcher Grundlage ihr gearbeitet habt.

Ein Detail, das fast alle übersehen: Für eigene Zwecke (Service-, Log- und aggregierte Daten) tritt Lovable laut DPA als eigenständig Verantwortlicher auf, nicht als Auftragsverarbeiter. Das gehört in eure Datenschutzerklärung — und erklärt, warum echte Lovable-Apps Lovable mal als Auftragsverarbeiter und mal als Verantwortlichen nennen. Außerdem könnt ihr in den Kontoeinstellungen der Nutzung eurer Inhalte für das Modelltraining widersprechen; laut Lovable geht das „on any plan, at no cost“. Die Daten eurer Nutzer in der Projektdatenbank nutzt Lovable nach eigener Aussage nicht zum Training.

Diese Pflichten habt ihr unabhängig von Lovable. Der Baukasten generiert euch zwar auf Zuruf eine Impressums- oder Datenschutzseite — ob sie stimmt, prüft er nicht.

Impressum. In Deutschland verlangt § 5 DDG (das frühere TMG) Name, Anschrift, Rechtsform, Vertretungsberechtigte und eine schnelle elektronische Kontaktmöglichkeit — „leicht erkennbar, unmittelbar erreichbar und ständig verfügbar“. Österreich regelt das in § 5 ECG, die Schweiz in Art. 3 Abs. 1 lit. s UWG. Ein fehlendes oder lückenhaftes Impressum ist ein klassischer Abmahngrund, weil Mitbewerber es mit einem Klick finden.

Datenschutzerklärung. Art. 13 DSGVO verlangt unter anderem Verantwortlichen, Zwecke, Rechtsgrundlagen, Empfänger und Drittlandübermittlungen. Der typische Fehler bei KI-gebauten Apps: Die Erklärung kommt aus einem Generator, die App spricht aber Dienste an, die dort nicht stehen — Lovable Cloud, Supabase, eine KI-API, ein Mail-Dienst. Öffnet eure App, schaut im Netzwerk-Tab des Browsers, welche Domains angesprochen werden, und vergleicht das mit dem Text.

Einwilligung für Tracker und Cookies. Nach § 25 TDDDG braucht ihr eine Einwilligung, bevor ihr Informationen auf dem Gerät eurer Besucher speichert oder auslest — es sei denn, es ist für den gewünschten Dienst unbedingt erforderlich. Ein vorangekreuztes Kästchen zählt nicht (BGH, I ZR 7/16). Auch Google Fonts, die zur Laufzeit von Google-Servern nachgeladen werden, sind angreifbar: Das LG München I hat dafür 100 € Schadensersatz zugesprochen (3 O 17493/20). Prompts wie „füg Google Analytics hinzu“ bauen das Skript ein — die Einwilligung davor oft nicht.

Zugriffsschutz der Datenbank. Art. 32 DSGVO verlangt angemessene technische Maßnahmen. Bei Supabase-Backends heißt das konkret: Row Level Security auf jeder Tabelle, die über die Schnittstelle erreichbar ist — so steht es in der Supabase-Doku. Fehlt sie, kann jeder mit dem öffentlichen Schlüssel aus dem Browser die Daten aller Nutzer abfragen. Wie das passiert, steht in unserem Artikel zur Lovable-App-Sicherheit.

KI-Kennzeichnung. Seit dem 2. August 2026 gilt Art. 50 KI-Verordnung: Menschen müssen erfahren, dass sie mit einem KI-System interagieren, spätestens bei der ersten Interaktion. Die Pflicht trifft den Anbieter des KI-Systems — wer einen Chatbot unter eigenem Namen in seine App einbaut, sollte davon ausgehen, dass er gemeint sein kann. Erzeugt eure App Bilder, Audio, Video oder Text, kommt die maschinenlesbare Kennzeichnung nach Abs. 2 dazu; für Systeme, die schon vor dem 2. August 2026 auf dem Markt waren, gilt dafür eine Frist bis zum 2. Dezember 2026. Der Bußgeldrahmen liegt bei bis zu 15 Mio. € oder 3 % des Umsatzes.

Barrierefreiheit. Verkauft eure App an Verbraucher — Buchung, Abo, Shop —, greift seit dem 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz. Ausgenommen sind Kleinstunternehmen (weniger als zehn Beschäftigte und höchstens 2 Mio. € Umsatz oder Bilanzsumme), aber nur, wenn sie Dienstleistungen anbieten. Bußgelder reichen bis 100.000 €.

Ehrlich gesagt: Dieser Artikel ist eine technische und organisatorische Einordnung, keine Rechtsberatung im Einzelfall. Für eure konkrete Situation gehört ein Blick von Datenschutzbeauftragten oder Anwält:innen dazu — der Artikel und der Scan sagen euch, wo überhaupt hingeschaut werden muss.

Lovable hat inzwischen einen eingebauten Security-Scan: Der Quick Scan läuft bei jedem Veröffentlichen und prüft unter anderem Datenbank-Zugriffsregeln und Abhängigkeiten, der Deep Scan untersucht auf Anfrage die Logik eurer App. Das ist gut, und ihr solltet ihn nutzen. Lovable schreibt aber selbst, dass die Scans „cannot guarantee complete security“.

Was der Lovable-Scan laut Doku nicht abdeckt: Impressum, Datenschutzerklärung, Einwilligung, KI-Kennzeichnung, Barrierefreiheit. Kein Wunder — das ist DACH-Recht, kein Sicherheitsthema. Genau hier setzt der decivo Scan an. Er prüft von außen, ohne Zugang, unter anderem: ob Impressum und Datenschutzerklärung verlinkt sind, ob im Impressum Anschrift, Kontakt und Register- oder Steuerkennung stehen, ob die Datenschutzerklärung die Pflichtangaben nach Art. 13 enthält und ob eure App Dienste anspricht, die dort nicht genannt sind. Dazu kommen Google Fonts zur Laufzeit, US-Tracker ohne erkennbare Einwilligung, KI-Endpunkte ohne sichtbaren KI-Hinweis und Hinweise auf BFSG-Relevanz.

Auf der Sicherheitsseite fragt der Scan die eigentliche Frage: Kommen mit dem öffentlichen Schlüssel aus dem Browser tatsächlich Zeilen aus eurer Datenbank? Gezählt wird nur über einen Header, es wird keine einzige Zeile abgerufen. Dazu Schlüssel im ausgelieferten Code, etwa ein service_role-Key. Alle Prüfungen stehen offen im Regelkatalog.

Der Scan hat drei Stufen, alle kostenlos: von außen ohne Zugang; mit Betreibernachweis per DNS-Eintrag, damit wir euch auch die Fundstellen zeigen dürfen; und mit lesendem GitHub-Zugriff für Architektur und Code. Was er nicht sieht, steht im Ergebnis als „braucht Zugang“, nicht als „bestanden“ — und einen AVV sieht von außen niemand. Wenn ihr danach Hilfe bei der Umsetzung wollt, gibt es mit dem Rescue Scoping einen klaren nächsten Schritt; der Scan selbst verpflichtet zu nichts.