Vibe-Coded für den EU-Markt: Compliance-Lücken, die niemand in KI-generiertem SaaS findet

Du hast schnell etwas gebaut. Ein KI-Coding-Assistent hat dir geholfen, in wenigen Wochen von der Idee zum deploymenten Produkt zu kommen, und jetzt bist du bereit, deine ersten europäischen Kunden zu gewinnen. Das Produkt funktioniert. Der Pitch ist scharf. Die einzige Frage ist, ob das Produkt in der EU tatsächlich legal zu betreiben ist.

Vibe Coding EU Compliance ist kein Kästchen, das sich von selbst ankreuzt. KI-Code-Generatoren sind darauf trainiert, funktionierende Software zu produzieren - sie sind nicht darauf trainiert, Software zu produzieren, die die DSGVO, den Europäischen Barrierefreiheitsgesetz, die ePrivacy-Richtlinie oder den EU-KI-Act erfüllt. Die Lücke zwischen "es läuft" und "es ist compliant" ist genau da, wo Gründer verbrannt werden, oft genau in dem Moment, wenn ein seriöses Enterprise-Prospect einen Datenverarbeitungsvertrag, einen Barrierefreiheitsbericht oder einen DPA-Audit-Fragebogen anfordert.

Dieser Beitrag ist eine Compliance-Audit-Checkliste für Gründer, die ihren SaaS mit einem KI-Coding-Assistenten gebaut haben und jetzt den EU-Markt anvisieren. Er deckt die Lücken ab, die wir konsistent finden, wenn wir vibe-codierte Codebases prüfen: Vibe-Coded Produkte haben Compliance-Lücken, die niemand in KI-generiertem SaaS findet, solange nicht gezielt danach gesucht wird. Keine von ihnen ist exotisch. Alle sind behebbar.

Warum vibe-codierte Produkte dieselben Compliance-Lücken teilen

Wenn du einen KI-Coding-Assistenten aufforderst, einen Benutzerregistrierungsfluss, ein Dashboard, ein Admin-Panel oder eine Zahlungsseite zu bauen, generiert das Modell Code, der die funktionale Spezifikation erfüllt. Es wird nicht von sich aus einen DSGVO-konformen Einwilligungsmechanismus hinzufügen, das Recht auf Datenübertragbarkeit implementieren oder sicherstellen, dass das Farbkontrastverhältnis den WCAG 2.2 AA-Standards entspricht.

Das ist kein Fehler im KI-Coding - es ist eine grundlegende Fehlanpassung zwischen dem, wofür das Tool optimiert, und dem, was das EU-Recht verlangt. Das Ergebnis ist ein vorhersehbarer Satz von Compliance-Schulden, die in fast jedem vibe-codierten SaaS auftauchen, den wir prüfen. Die gute Nachricht ist, dass sie einem Muster folgen, was bedeutet, dass sie systematisch gefunden und behoben werden können.

Lücke 1: Cookie-Banner, die keine echte Einwilligung einholen

Das ist der häufigste einzelne Fund. Die Anwendung wird mit einem Cookie-Banner ausgeliefert - oft einem schön gestalteten - aber die Implementierung entspricht nicht den Anforderungen der ePrivacy-Richtlinie für die EU oder den UK PECR-Anforderungen für das UK.

Was wir finden:

• Analytics-Skripte (Google Analytics, Hotjar, Intercom), die beim Seitenrendering vor jeder Benutzeraktion laden, unabhängig davon, was der Banner sagt
• Banner mit einem prominenten "Akzeptieren"-Button und einem versteckten "Einstellungen verwalten"-Link, der nicht funktioniert
• Einwilligung wird nicht korrekt gespeichert - das Löschen des Local Storage setzt den Banner zurück, aber die Tracking-Skripte wurden bereits ausgeführt
• Kein Einwilligungsprotokoll wird geführt - wenn ein Regulierer fragt "Hat dieser Nutzer eingewilligt?", ist die Antwort technisch nicht feststellbar

Wie Compliance aussieht: Alle nicht wesentlichen Skripte müssen blockiert werden, bis eine explizite, informierte, affirmative Einwilligung gegeben wird. Die Einwilligung muss genauso leicht zu widerrufen wie zu geben sein. Einwilligungsprotokolle müssen gespeichert und zurechenbar sein. Wenn du eine Consent Management Platform verwendest, muss sie korrekt konfiguriert sein - eine CMP, die vor der Einwilligung lädt, ist keine CMP, sie ist Theater.

Wenn du Analytics verwendest, prüfe deinen Netzwerk-Tab vor und nach dem Akzeptieren von Cookies. Wenn Anfragen an Drittanbieter-Domains ausgelöst werden, bevor du auf "Akzeptieren" klickst, ist dein Banner dekorativ.

Lücke 2: DSGVO-Betroffenenrechte, die nicht implementiert sind

Die DSGVO garantiert EU-Bürgern acht Rechte. Die meisten vibe-codierten Anwendungen handhaben höchstens eines davon angemessen - die Kontosperrung, weil Gründer in der Regel daran denken, einen "Konto löschen"-Button einzufügen. Der Rest fehlt oft.

Was wir vermissen:

• Recht auf Auskunft: Kein Mechanismus, damit ein Nutzer alle Daten herunterladen kann, die das System über ihn hält. Ein DSGVO-Auskunftsersuchen (SAR), das per E-Mail eingeht, erfordert einen manuellen Datenbankexport, ohne Tooling, um ihn zu produzieren.
• Recht auf Berichtigung: Nutzer können ihr Profil bearbeiten, aber Daten in Logs, Event-Tabellen, Analytics-Systemen und Drittanbieter-Integrationen werden nie aktualisiert.
• Recht auf Datenübertragbarkeit: Kein Export in einem strukturierten, allgemein gebräuchlichen, maschinenlesbaren Format. Eine CSV der eigenen Datensätze des Nutzers ist das Minimum.
• Recht auf Einschränkung der Verarbeitung: Kein Flag, um die Verarbeitung der Daten eines bestimmten Nutzers während einer Streitbeilegung zu pausieren.
• Recht auf Widerspruch gegen automatisierte Entscheidungsfindung: Wenn das Produkt eine Bewertungs-, Ranking- oder Segmentierungslogik verwendet, gibt es keine Offenlegung und keine Möglichkeit für Nutzer, zu widersprechen.

Wie Compliance aussieht: Baue einen "Datenschutz"-Bereich in den Nutzer-Kontoeinstellungen, der umsetzbare Kontrollen für jedes anwendbare Recht enthält. Für einen B2B-SaaS, zumindest: Datenexport, Kontolöschung mit dokumentierter Datenspeicherungsrichtlinie und eine Kontaktroute für SARs. Stelle sicher, dass die Löschung tatsächlich löscht - kaskadiere durch alle Tabellen, entferne aus Drittanbieter-Integrationen (E-Mail-Plattformen, CRMs, Analytics) und dokumentiere, was wie lange aufbewahrt wird, in deiner Datenschutzhinweis.

Unser Code-Qualitäts-Consulting-Prozess beinhaltet ein Datenflussdiagramm-Audit, das jeden Ort kartiert, an dem persönliche Daten gespeichert oder übertragen werden - die Voraussetzung für die korrekte Implementierung von Betroffenenrechten.

Lücke 3: Fehlende oder falsche Datenverarbeitungsvertrag-Infrastruktur

Wenn dein SaaS persönliche Daten im Auftrag von Geschäftskunden verarbeitet - was die Definition eines B2B-SaaS ist - sind deine Kunden Verantwortliche und du bist Auftragsverarbeiter. Die DSGVO verlangt einen Datenverarbeitungsvertrag (DPA) zwischen euch, bevor die Verarbeitung beginnt.

Was wir finden:

• Kein DPA-Template existiert. Interessenten aus Deutschland, Frankreich oder den Niederlanden werden während der Beschaffung danach fragen, und ein fehlender DPA ist ein hartes Hindernis.
• Unterauftragnehmer-Listen fehlen oder sind ungenau. Dein DPA verpflichtet dich, jeden Drittanbieterdienst aufzulisten, der Kundendaten berührt: dein Hosting-Anbieter, dein E-Mail-Dienst, deine Analytics-Plattform, dein Fehlerüberwachungstool.
• Kein Mechanismus, um Kunden innerhalb der erforderlichen Frist über Änderungen bei Unterauftragnehmern zu informieren.

Wie Compliance aussieht: Beauftragte einen Datenschutzrechtsanwalt, einen DPA zu entwerfen, der deinen tatsächlichen Datenflüsse entspricht. Pflege eine Unterauftragnehmer-Liste und halte sie aktuell. Erwäge, sie unter einer stabilen URL zu veröffentlichen, damit Kunden sie prüfen können, ohne dich zu kontaktieren.

Lücke 4: Audit-Logs, die nicht existieren

Regulierte Branchen - Finanzen, Gesundheitswesen, Recht, HR - erfordern Audit-Trails. Auch außerhalb regulierter Branchen bedeuten DSGVO-Rechenschaftspflichten, dass du nachweisen musst, dass persönliche Daten nur von autorisierten Parteien und aus dokumentierten Gründen zugegriffen wurden.

Was wir finden:

• Keine Audit-Log-Tabelle in der Datenbank. Admin-Aktionen, Datenexporte, Nutzer-Impersonation und Berechtigungsänderungen hinterlassen keinen Datensatz.
• Anwendungslogs existieren (stdout, Sentry), enthalten aber keinen strukturierten Datensatz, wer was mit welchem Datensatz zu welcher Zeit getan hat.
• Log-Aufbewahrung ist nicht definiert - Logs werden entweder für immer aufbewahrt oder nach 7 Tagen rotiert.

Wie Compliance aussieht: Implementiere ein strukturiertes Audit-Log: Akteur (Nutzer-ID und Rolle), Aktion (Verb), Ziel (Ressourcentyp und ID), Zeitstempel, IP-Adresse und Ergebnis. Speichere es wenn möglich separat von der Hauptanwendungsdatenbank. Definiere eine Aufbewahrungsrichtlinie - typischerweise 12 Monate für operative Logs, länger für compliance-kritische Ereignisse.

Lücke 5: Barrierefreiheit, die von Anfang an WCAG 2.2 scheitert

Der Europäische Barrierefreiheitsgesetz (EAA) trat im Juni 2025 für digitale Produkte des privaten Sektors in Kraft. WCAG 2.2 AA-Konformität ist der praktische Standard, den er erfordert. KI-generierte Frontends, insbesondere solche, die mit Komponentenbibliotheken und Tailwind gebaut werden, sehen oft zugänglich aus - sind es aber nicht.

Was wir finden:

• Farbkontrastverhältnis unter 4.5:1 bei Fließtext oder unter 3:1 bei großem Text und interaktiven Elementen
• Formularfelder ohne programmatisch zugeordnete Labels - das <label for>-Attribut zeigt auf eine nicht-existierende ID
• Interaktive Elemente, die nicht per Tastatur erreichbar sind: Dropdowns, Modals und Datumsauswähler, die mit der Maus funktionieren und mit Tab kaputt gehen
• Kein sichtbarer Fokusindikator - der Standard-Browser-Rahmen wurde mit outline: none im globalen CSS entfernt
• Bilder mit fehlenden oder leeren alt-Attributen, einschließlich UI-Icons, die Bedeutung vermitteln
• Fehlermeldungen, die visuell erscheinen, aber für Screenreader nicht angekündigt werden

Wie Compliance aussieht: Führe ein automatisiertes Barrierefreiheits-Audit mit axe-core oder Lighthouse als Basis durch - das erkennt etwa 30-40% der WCAG-Probleme. Teste dann nur mit der Tastatur und teste mit VoiceOver oder NVDA für Screenreader-Abdeckung. Behebe Probleme schichtweise: Farbe und Kontrast zuerst, semantisches HTML als nächstes, ARIA-Rollen zuletzt.

Unser Web-Anwendungsentwicklungs-Prozess beinhaltet Barrierefreiheitstests bei jedem Meilenstein, genau weil das nachträgliche Hinzufügen von Barrierefreiheit deutlich teurer ist als das Einbauen von Anfang an.

Lücke 6: Keine EU-KI-Act-Compliance-Betrachtung für KI-Features

Wenn dein Produkt KI-generierte Inhalte, KI-basiertes Scoring, automatisierte Entscheidungsfindung oder KI-gestützte Empfehlungen mit bedeutenden Auswirkungen auf Nutzer beinhaltet, operierst du jetzt unter dem EU-KI-Act. Die meisten vibe-codierten SaaS-Produkte im Jahr 2026 beinhalten mindestens eines dieser Features, oft ohne dass das Gründerteam erkennt, dass es in den Anwendungsbereich fällt.

Was wir finden:

• Keine Risikoklassifizierungs-Übung wurde durchgeführt. Das Team weiß nicht, ob sein KI-Feature unter dem Gesetz minimales Risiko, begrenztes Risiko oder hohes Risiko ist.
• Keine Transparenzhinweise für Nutzer, die mit KI-generierten Outputs interagieren, wie es für Systeme mit begrenztem Risiko erforderlich ist.
• Kein menschlicher Überwachungsmechanismus für automatisierte Entscheidungen, die Nutzer erheblich betreffen.

Wie Compliance aussieht: Für die meisten B2B-SaaS in der Kategorie begrenztes Risiko: Füge klare Offenlegung hinzu, wenn Nutzer mit KI-generierten Inhalten interagieren, stelle sicher, dass es einen menschlichen Eskalationspfad für folgenreiche Entscheidungen gibt, und dokumentiere das KI-System in einer technischen Akte. Hochrisiko-Systeme (Einstellung, Kredit, Gesundheit) erfordern erheblich mehr.

Das Kumulationsproblem

Keine dieser Lücken ist für sich allein katastrophal, wenn du klein bist. Das Kumulationsproblem ist, dass sie alle gleichzeitig ankommen, wenn ein seriöses Prospect einen Beschaffungs-Sicherheitsreview durchführt, wenn ein DSB eine Auskunftsanfrage sendet, die dein fehlendes Tooling offenbart, oder wenn ein Wettbewerber eine Barrierefreiheitsbeschwerde einreicht. Zu diesem Zeitpunkt ist das gleichzeitige Schließen von fünf Compliance-Lücken bei gleichzeitiger Aufrechterhaltung der Produktvelocity teuer und störend.

Der kosteneffektivere Weg ist ein strukturiertes Compliance-Audit, bevor du deinen ersten bedeutenden EU-Deal abschließt, nicht danach.

Wo du anfangen solltest

Wenn du diese Checkliste gelesen und dein Produkt erkannt hast, sind die hochwertigsten ersten Schritte:

1. Deinen Cookie-Banner reparieren - teste ihn noch heute im Netzwerk-Tab deines Browsers
2. Betroffenenrechte implementieren - SAR, Export und Löschung als Minimum
3. Einen Datenschutzrechtsanwalt beauftragen, ein DPA-Template zu entwerfen
4. axe-core gegen deine fünf meistgenutzten Seiten ausführen und jeden kritischen und ernsthaften Fund beheben

Wenn du einen strukturierten Review deiner Codebase gegen diese Anforderungen möchtest, führt das Team bei Wolf-Tech compliance-fokussierte Code-Qualitäts-Consulting für EU-Markt-SaaS-Produkte durch. Wir auditieren Datenflüsse, Frontend-Barrierefreiheit, Einwilligungsimplementierung und Audit-Logging und liefern einen priorisierten Sanierungsplan, auf den dein Team handeln kann.

Melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io, um deine Situation zu besprechen. Je früher im Verkaufszyklus du diese Lücken schließen kannst, desto unwahrscheinlicher ist es, dass sie einen Deal für dich schließen.