KI-generierte Webapps und die DSGVO: Die häufigsten Fallen und was Aufsichtsbehörden konkret prüfen

Eine mit Cursor, v0 oder Lovable in Tagen gebaute Webapp ist rechtlich exakt so verantwortlich wie eine, an der ein Team ein halbes Jahr gearbeitet hat. Die DSGVO kennt keine Ausnahme für „schnell mit KI gebaut". Wenn personenbezogene Daten verarbeitet werden, Login-E-Mail, IP-Adresse, Nutzer-Eingaben mit Namen, greift der volle Rechtsrahmen ab dem ersten echten Nutzer.

Aus unserer Prüfungspraxis mit KI-generierten Webapps kristallisieren sich fünf DSGVO-Fallen heraus, die fast überall auftreten. Dieser Artikel beschreibt sie und was passiert, wenn eine Aufsichtsbehörde nachfragt.

Falle 1: Fehlende oder falsche Rechtsgrundlage nach Art. 6

Der Klassiker. In nahezu jeder Prüfung hatten die Startups eine Datenschutz­erklärung, die Rechtsgrundlagen zitierte, meist „Vertragserfüllung" für alles. In Wirklichkeit werden mehrere Datenarten mit unterschiedlichen Zwecken verarbeitet, und die Rechtsgrundlagen sind oft verschieden:

• Login-Daten und Konto-Verwaltung, meist Art. 6(1)(b) DSGVO (Vertragserfüllung)
• Marketing-E-Mails an eingeloggte Nutzer, Art. 6(1)(a) (Einwilligung), nicht Vertragserfüllung
• Analytics-Tracking, meist Art. 6(1)(a) (Einwilligung), abhängig vom Anbieter und der Ausgestaltung
• Werbe-Kampagnen mit personalisiertem Targeting, Art. 6(1)(a) (Einwilligung)
• Zahlungsabwicklung, Art. 6(1)(b) (Vertragserfüllung) plus Art. 6(1)(c) (rechtliche Verpflichtung) für Aufbewahrung
• Support-Tickets mit personenbezogenen Inhalten, Art. 6(1)(b) oder (f) je nach Kontext

Wer alles unter „Vertragserfüllung" summiert, ist bei einer Prüfung angreifbar, insbesondere für Marketing und Analytics, die separate Einwilligung brauchen.

Was Aufsichtsbehörden bei einer Meldung tatsächlich fragen: „Legen Sie bitte für jede Kategorie personenbezogener Daten die zugrundeliegende Rechtsgrundlage dar." Wer nicht innerhalb weniger Tage strukturiert antworten kann, verlängert das Verfahren und signalisiert mangelnde Vorbereitung, was in die Höhe der eventuellen Bußgeldbemessung einfließt.

Falle 2: Recht auf Löschung technisch nicht umgesetzt

In praktisch allen bisher geprüften Apps gab es kein funktionierendes „Nutzer löschen"-Feature. Häufig konnten Nutzer gar nicht gelöscht werden, weil Foreign-Key-Beziehungen ohne Cascade-Regel angelegt waren. Wenn Löschen technisch möglich war, gab es meist keinen UI-Weg und keinen Support-Prozess.

Art. 17 DSGVO gibt Betroffenen das Recht auf Löschung ihrer Daten unter bestimmten Voraussetzungen. Wenn ein Nutzer das anfragt und Sie nicht innerhalb eines Monats (mit begründeter Verlängerung bis zu drei Monate) reagieren können, ist das eine Datenschutz­verletzung, auch ohne Datenleck.

Was Aufsichtsbehörden bei einer Meldung tatsächlich prüfen: „Zeigen Sie uns den technischen Prozess, mit dem ein Löschungsantrag von der Antragstellung bis zur Bestätigung durchläuft." Ein PDF mit „wir würden dann händisch die Datenbank durchgehen" ist keine Antwort. Aufsichtsbehörden erwarten einen definierten Prozess mit Verantwortlichem, Zeitvorgabe und Nachweisdokumentation.

Was Sie technisch brauchen: Ein DELETE /api/user/self-Endpunkt, der alle personenbezogenen Daten des Nutzers löscht oder anonymisiert. Foreign Keys mit ON DELETE CASCADE oder expliziter Nullifizierung. Ein Backup-Retention-Konzept, das dokumentiert, wann Backups mit personenbezogenen Daten überschrieben werden, typisch 30 Tage.

Falle 3: Datenexport in Nicht-EU-Regionen ohne Nachweis

Cursor, v0 und Lovable sind US-amerikanische Werkzeuge. Der generierte Code ist neutral, aber die vorgeschlagenen Services meist US-basiert: Vercel (Hosting, meist US-Regionen als Default), Supabase (bis Frühjahr 2025 nur US-Regionen bei kostenlosem Tier), Clerk (US-Auth-Provider), Stripe (US-Zahlungsdienst), OpenAI-API (US-Server für die meisten Endpunkte).

Nach Schrems II (2020) und dem EU-US-Data-Privacy-Framework (2023) ist der Transfer personenbezogener Daten in die USA nicht per se unzulässig, aber er verlangt Standardvertragsklauseln, Angemessenheitsbeschluss oder eine andere Rechtsgrundlage aus Art. 44–49 DSGVO. In den meisten geprüften Setups gab es keine dokumentierten Standardvertragsklauseln.

Was Aufsichtsbehörden bei einer Meldung tatsächlich prüfen: „Legen Sie die Auftragsverarbeitungsverträge und Standardvertragsklauseln aller Ihrer Datenverarbeiter mit Sitz außerhalb der EU vor." Wer keinen AV-Vertrag mit Vercel/Supabase/Clerk hat, hat einen dokumentierten Rechtsmangel, unabhängig davon, ob Daten geleakt sind.

Was Sie tun sollten: Für jeden externen Dienst, der personenbezogene Daten verarbeitet, den AV-Vertrag herunterladen (Vercel, Supabase, Clerk, Stripe stellen alle Standard-DPAs online zur Verfügung), unterzeichnen und im Firmenarchiv ablegen. Für sensiblere Daten: Migration auf EU-Regionen, die bei allen genannten Anbietern seit 2024/2025 verfügbar sind.

Falle 4: Cookie-Banner ohne echte Ablehnungs-Option

In den meisten geprüften Setups war der Cookie-Banner nicht DSGVO-konform. Häufigstes Muster: „Alle akzeptieren" als grüner Button, „Einstellungen" als grauer Textlink, und wenn man klickt, ist es nicht möglich, alle nicht-notwendigen Cookies mit einem Klick abzulehnen. Nach der Entscheidung des BGH von 2020 (Planet49) und den ergänzenden Vorgaben der Aufsichtsbehörden gilt: Ablehnen muss so einfach sein wie Akzeptieren.

KI-Assistenten generieren häufig Cookie-Banner-Komponenten mit dem Muster ihrer Trainingsdaten, was meist heißt, Muster aus 2019/2020. Die haben Ablehnen-Optionen absichtlich unauffällig gemacht.

Was Aufsichtsbehörden bei einer Meldung tatsächlich prüfen: Screenshots des Cookie-Banners im Auslieferungs-Zustand. Zusätzlich: Analyse, welche Cookies vor der Einwilligung gesetzt werden. Wer Analytics oder Werbe-Cookies vor der Einwilligung setzt, hat einen weiteren Verstoß.

Was Sie brauchen: Einen Cookie-Banner mit gleichwertigem „Alle akzeptieren" und „Alle ablehnen"-Button auf der ersten Ebene, granularer Einstellungsoption dahinter, und einer technischen Kontrolle, dass ohne Einwilligung keine nicht-notwendigen Cookies gesetzt werden. Für die meisten Setups reicht Cookiebot, Usercentrics oder das Open-Source-Tool Klaro, alle drei sind DSGVO-konform konfigurierbar.

Falle 5: Kein dokumentierter Prozess für Datenschutz-Verletzungen

Art. 33 DSGVO verlangt, dass Datenschutz­verletzungen binnen 72 Stunden an die zuständige Aufsichtsbehörde gemeldet werden. Art. 34 verlangt zusätzlich Meldung an die Betroffenen, wenn hohes Risiko besteht. In den meisten geprüften Setups gibt es keinen dokumentierten Prozess für den Ernstfall.

Das ist rechtlich riskant, weil die Meldepflicht objektiv besteht, egal ob Sie einen Prozess haben oder nicht. Wenn ein Ereignis eintritt und Sie nicht wissen, wer zu welcher Aufsichtsbehörde meldet, verlieren Sie Stunden, im ungünstigsten Fall Tage, und verlängern damit das Meldefenster.

Was Aufsichtsbehörden bei einer Meldung tatsächlich prüfen: „Wie sieht Ihr Meldeprozess nach Art. 33 aus? Wer ist verantwortlich, welche Informationen werden erhoben, wie erreichen Sie uns außerhalb der Geschäftszeiten?" Wer keinen Prozess dokumentiert hat, muss ihn ad hoc definieren, was in der Krise noch schwerer ist.

Was Sie brauchen: Ein einseitiges internes Dokument, das folgende Fragen beantwortet:

• Wer bemerkt Vorfälle? (Meist: Founder oder DevOps)
• Wer klassifiziert die Meldepflicht? (Bei Startups typisch: Founder mit DSB-Kontakt, ggf. externer Datenschutzbeauftragter)
• Welche zuständige Aufsichtsbehörde nach Bundesland? (Für Bayern: BayLDA. Für Berlin: BlnBDI. Für Baden-Württemberg: LfDI BW.)
• Welche Informationen brauchen wir für die Meldung? (Art der Verletzung, ungefähre Anzahl Betroffene, Datenkategorien, mögliche Folgen, geplante Maßnahmen)
• Wer schreibt an Betroffene, wenn Art. 34 greift?

Das Dokument braucht drei Seiten und rettet in der Krise Tage.

Was Aufsichtsbehörden nicht prüfen, aber Investoren

Zwei Punkte, die für die Aufsichtsbehörde weniger relevant sind, aber bei Investoren-Due-Diligence ab Series A regelmäßig aufkommen:

• Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO). Bei mehr als 250 Mitarbeitern verpflichtend, für Startups meist nicht, außer bei sensibleren Datenkategorien. Investoren erwarten es trotzdem als Nachweis strukturierter Verantwortung.
• Datenschutz­beauftragter (Art. 37). Erforderlich, wenn die Kerntätigkeit umfangreiche regelmäßige Überwachung ist (Analytics-Startups, Adtech), oder bei besonderen Datenkategorien nach Art. 9 (Gesundheit, biometrische Daten). Wer im Zweifel ist: externen DSB für ~€400/Monat beauftragen, spart in der Due-Diligence Wochen.

Praktische Reihenfolge

Für den Founder, der einen KI-generierten Prototypen jetzt in Production schiebt und DSGVO-belastbar machen will, ist die Reihenfolge:

Woche 1 (2 Tage Aufwand): Datenschutz­erklärung nach Rechtsgrundlagen strukturieren; AV-Verträge mit allen externen Diensten unterzeichnen und archivieren; Meldeprozess-Dokument nach Art. 33 aufsetzen.

Woche 2 (3 Tage Aufwand): Nutzer-Löschung technisch umsetzen und im UI zugänglich machen; Cookie-Banner auf gleichwertige Zustimmung/Ablehnung überarbeiten.

Woche 3 (1 Tag Aufwand): Verzeichnis der Verarbeitungstätigkeiten anlegen (auch wenn nicht verpflichtend); externen DSB engagieren wenn Datenkategorien sensitiv sind.

Nach diesen sechs Tagen sind Sie in einem Zustand, in dem eine Aufsichtsbehörden-Anfrage strukturiert beantwortbar ist. Nicht perfekt, aber verteidigbar.

Nächster Schritt

Unser KI-Code-Audit prüft die genannten fünf DSGVO-Fallen zusammen mit fünfundzwanzig weiteren Sicherheits- und Compliance-Punkten. 1 Tag, €3.500 fix, schriftlicher Bericht mit priorisierten Fixes.

Wenn Sie unsicher sind, wo Ihre App aktuell steht: 30-min Termin buchen, kostenlos, unverbindliche Einschätzung.

---

Verwandte Artikel: Was in KI-generierten Apps in Production wirklich bricht · Vibe Coding zu Production: die Checkliste