Vibe-Coded fur den EU-Markt: Compliance-Lucken, 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 europaischen Kunden zu gewinnen. Das Produkt funktioniert. Der Pitch ist scharf. Die einzige Frage ist, ob das Produkt in der EU tatsachlich legal zu betreiben ist.

Vibe Coding EU Compliance ist kein Kastchen, 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 Europaischen Barrierefreiheitsgesetz, die ePrivacy-Richtlinie oder den EU-KI-Act erfullt. Die Lucke zwischen "es lauft" und "es ist compliant" ist genau da, wo Grunder verbrannt werden, oft genau in dem Moment, wenn ein serioses Enterprise-Prospect einen Datenverarbeitungsvertrag, einen Barrierefreiheitsbericht oder einen DPA-Audit-Fragebogen anfordert.

Dieser Beitrag ist eine Compliance-Audit-Checkliste fur Grunder, die ihren SaaS mit einem KI-Coding-Assistenten gebaut haben und jetzt den EU-Markt anvisieren. Er deckt die Lucken ab, die wir konsistent finden, wenn wir vibe-codierte Codebases prufen. Keine von ihnen ist exotisch. Alle sind behebbar.

Warum vibe-codierte Produkte dieselben Compliance-Lucken 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 erfullt. Es wird nicht von sich aus einen DSGVO-konformen Einwilligungsmechanismus hinzufugen, das Recht auf Datenubertragebarkeit implementieren oder sicherstellen, dass das Farbkontrastverhaltnis den WCAG 2.2 AA-Standards entspricht.

Das ist kein Fehler im KI-Coding - es ist eine grundlegende Fehlanpassung zwischen dem, wofur 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 prufen. Die gute Nachricht ist, dass sie einem Muster folgen, was bedeutet, dass sie systematisch gefunden und behoben werden konnen.

Lucke 1: Cookie-Banner, die keine echte Einwilligung einholen

Das ist der haufigste einzelne Fund. Die Anwendung wird mit einem Cookie-Banner ausgeliefert - oft einem schon gestalteten - aber die Implementierung entspricht nicht den Anforderungen der ePrivacy-Richtlinie fur die EU oder den UK PECR-Anforderungen fur das UK.

Was wir finden:

• Analytics-Skripte (Google Analytics, Hotjar, Intercom), die beim Seitenrendering vor jeder Benutzeraktion laden, unabhangig 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 Loschen des Local Storage setzt den Banner zuruck, aber die Tracking-Skripte wurden bereits ausgefuhrt
• Kein Einwilligungsprotokoll wird gefuhrt - wenn ein Regulierer fragt "Hat dieser Nutzer eingewilligt?", ist die Antwort technisch nicht feststellbar

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

Wenn du Analytics verwendest, prufe deinen Netzwerk-Tab vor und nach dem Akzeptieren von Cookies. Wenn Anfragen an Drittanbieter-Domains ausgelost werden, bevor du auf "Akzeptieren" klickst, ist dein Banner dekorativ.

Lucke 2: DSGVO-Betroffenenrechte, die nicht implementiert sind

Die DSGVO garantiert EU-Burgern acht Rechte. Die meisten vibe-codierten Anwendungen handhaben hochstens eines davon angemessen - die Kontosperrung, weil Grunder in der Regel daran denken, einen "Konto loschen"-Button einzufugen. Der Rest fehlt oft.

Was wir vermissen:

• Recht auf Auskunft: Kein Mechanismus, damit ein Nutzer alle Daten herunterladen kann, die das System uber ihn halt. Ein DSGVO-Auskunftsersuchen (SAR), das per E-Mail eingeht, erfordert einen manuellen Datenbankexport, ohne Tooling, um ihn zu produzieren.
• Recht auf Berichtigung: Nutzer konnen ihr Profil bearbeiten, aber Daten in Logs, Event-Tabellen, Analytics-Systemen und Drittanbieter-Integrationen werden nie aktualisiert.
• Recht auf Datenubertragebarkeit: Kein Export in einem strukturierten, allgemein gebrauchlichen, maschinenlesbaren Format. Eine CSV der eigenen Datensatze des Nutzers ist das Minimum.
• Recht auf Einschrankung der Verarbeitung: Kein Flag, um die Verarbeitung der Daten eines bestimmten Nutzers wahrend 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 Moglichkeit fur Nutzer, zu widersprechen.

Wie Compliance aussieht: Baue einen "Datenschutz"-Bereich in den Nutzer-Kontoeinstellungen, der umsetzbare Kontrollen fur jedes anwendbare Recht enthalt. Fur einen B2B-SaaS, zumindest: Datenexport, Kontoloschung mit dokumentierter Datenspeicherungsrichtlinie und eine Kontaktroute fur SARs. Stelle sicher, dass die Loschung tatsachlich loscht - 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-Qualitats-Consulting-Prozess beinhaltet ein Datenfludiagramm-Audit, das jeden Ort kartiert, an dem personliche Daten gespeichert oder ubertragen werden - die Voraussetzung fur die korrekte Implementierung von Betroffenenrechten.

Lucke 3: Fehlende oder falsche Datenverarbeitungsvertrag-Infrastruktur

Wenn dein SaaS personliche Daten im Auftrag von Geschaftskunden 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 wahrend 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 beruhrt: dein Hosting-Anbieter, dein E-Mail-Dienst, deine Analytics-Plattform, dein Fehleruberwachungstool.
• Kein Mechanismus, um Kunden innerhalb der erforderlichen Frist uber Anderungen bei Unterauftragnehmern zu informieren.

Wie Compliance aussieht: Beauftragte einen Datenschutzrechtsanwalt, einen DPA zu entwerfen, der deinen tatsachlichen Datenflusse entspricht. Pflege eine Unterauftragnehmer-Liste und halte sie aktuell. Erwage, sie unter einer stabilen URL zu veroffentlichen, damit Kunden sie prufen konnen, ohne dich zu kontaktieren.

Lucke 4: Audit-Logs, die nicht existieren

Regulierte Branchen - Finanzen, Gesundheitswesen, Recht, HR - erfordern Audit-Trails. Auch ausserhalb regulierter Branchen bedeuten DSGVO-Rechenschaftspflichten, dass du nachweisen musst, dass personliche Daten nur von autorisierten Parteien und aus dokumentierten Grunden zugegriffen wurden.

Was wir finden:

• Keine Audit-Log-Tabelle in der Datenbank. Admin-Aktionen, Datenexporte, Nutzer-Impersonation und Berechtigungsanderungen 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 fur 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 moglich separat von der Hauptanwendungsdatenbank. Definiere eine Aufbewahrungsrichtlinie - typischerweise 12 Monate fur operative Logs, langer fur compliance-kritische Ereignisse.

Lucke 5: Barrierefreiheit, die von Anfang an WCAG 2.2 scheitert

Der Europaische Barrierefreiheitsgesetz (EAA) trat im Juni 2025 fur digitale Produkte des privaten Sektors in Kraft. WCAG 2.2 AA-Konformitat ist der praktische Standard, den er erfordert. KI-generierte Frontends, insbesondere solche, die mit Komponentenbibliotheken und Tailwind gebaut werden, sehen oft zuganglich aus - sind es aber nicht.

Was wir finden:

• Farbkontrastverhaltnis unter 4.5:1 bei Fliesstext oder unter 3:1 bei grossem 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 Datumsauswahler, 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, einschliesslich UI-Icons, die Bedeutung vermitteln
• Fehlermeldungen, die visuell erscheinen, aber fur Screenreader nicht angekundigt werden

Wie Compliance aussieht: Fuhre 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 fur Screenreader-Abdeckung. Behebe Probleme schichtweise: Farbe und Kontrast zuerst, semantisches HTML als nachstes, ARIA-Rollen zuletzt.

Unser Web-Anwendungsentwicklungs-Prozess beinhaltet Barrierefreiheitstests bei jedem Meilenstein, genau weil das nachtragliche Hinzufugen von Barrierefreiheit deutlich teurer ist als das Einbauen von Anfang an.

Lucke 6: Keine EU-KI-Act-Compliance-Betrachtung fur KI-Features

Wenn dein Produkt KI-generierte Inhalte, KI-basiertes Scoring, automatisierte Entscheidungsfindung oder KI-gestutzte 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 Grunderteam erkennt, dass es in den Anwendungsbereich fallt.

Was wir finden:

• Keine Risikokclassifications-Ubung wurde durchgefuhrt. Das Team weiss nicht, ob sein KI-Feature unter dem Gesetz minimales Risiko, begrenztes Risiko oder hohes Risiko ist.
• Keine Transparenzhinweise fur Nutzer, die mit KI-generierten Outputs interagieren, wie es fur Systeme mit begrenztem Risiko erforderlich ist.
• Kein menschlicher Uberwachungsmechanismus fur automatisierte Entscheidungen, die Nutzer erheblich betreffen.

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

Das Kumulationsproblem

Keine dieser Lucken ist fur sich allein katastrophal, wenn du klein bist. Das Kumulationsproblem ist, dass sie alle gleichzeitig ankommen, wenn ein serioses Prospect einen Beschaffungs-Sicherheitsreview durchfuhrt, wenn ein DSB eine Auskunftsanfrage sendet, die dein fehlendes Tooling offenbart, oder wenn ein Wettbewerber eine Barrierefreiheitsbeschwerde einreicht. Zu diesem Zeitpunkt ist das gleichzeitige Schliessen von funf Compliance-Lucken bei gleichzeitiger Aufrechterhaltung der Produktvelocity teuer und storend.

Der kosteneffektivere Weg ist ein strukturiertes Compliance-Audit, bevor du deinen ersten bedeutenden EU-Deal abschliesst, 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 Loschung als Minimum
3. Einen Datenschutzrechtsanwalt beauftragen, ein DPA-Template zu entwerfen
4. axe-core gegen deine funf meistgenutzten Seiten ausfuhren und jeden kritischen und ernsthaften Fund beheben

Wenn du einen strukturierten Review deiner Codebase gegen diese Anforderungen mochtest, fuhrt das Team bei Wolf-Tech compliance-fokussierte Code-Qualitats-Consulting fur EU-Markt-SaaS-Produkte durch. Wir auditieren Datenflusse, 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 fruher im Verkaufszyklus du diese Lucken schliessen kannst, desto unwahrscheinlicher ist es, dass sie einen Deal fur dich schliessen.