Vibe-Coded for the EU Market: The Compliance Gaps Nobody Catches in AI-Generated SaaS

You built something fast. An AI coding assistant helped you go from idea to deployed product in weeks, and now you are ready to sign your first European customers. The product works. The pitch is sharp. The only question is whether the product is actually legal to operate in the EU.

Vibe coding EU compliance is not a box that checks itself. AI code generators are trained to produce working software — they are not trained to produce software that satisfies the GDPR, the European Accessibility Act, the ePrivacy Directive, or the EU AI Act. The gap between "it runs" and "it is compliant" is exactly where founders get burned, often right at the moment a serious enterprise prospect asks for a data processing agreement, or an accessibility report, or a DPA audit questionnaire.

This post is a compliance audit checklist for founders who built their SaaS with an AI coding assistant and are now targeting the EU market. It covers the gaps we find consistently when we review vibe-coded codebases. None of them are exotic. All of them are fixable.

Why vibe-coded products share the same compliance gaps

When you prompt an AI coding assistant to build a user registration flow, a dashboard, an admin panel, or a payment page, the model generates code that satisfies the functional specification. It will not, on its own initiative, add a GDPR-compliant consent mechanism, implement the right to data portability, or ensure the color contrast ratio meets WCAG 2.2 AA standards.

This is not a flaw in AI coding — it is a fundamental mismatch between what the tool optimises for and what EU law requires. The result is a predictable set of compliance debts that appear in nearly every vibe-coded SaaS we audit. The good news is that they follow a pattern, which means they can be found and fixed systematically.

Gap 1: Cookie banners that do not actually obtain consent

This is the single most common finding. The application ships with a cookie banner — often a nicely styled one — but the implementation does not meet the ePrivacy Directive requirements for the EU or the UK PECR requirements for the UK.

What we find:

• Analytics scripts (Google Analytics, Hotjar, Intercom) that load on page render before any user action, regardless of what the banner says
• Banners with a prominent "Accept" button and a buried "Manage preferences" link that does not work
• Consent not stored correctly — clearing local storage resets the banner, but the tracking scripts were already fired
• No record of consent kept — if a regulator asks "did this user consent?", the answer is technically unknowable

What compliant looks like: All non-essential scripts must be blocked until explicit, informed, affirmative consent is given. Consent must be as easy to withdraw as to give. Consent records must be stored and attributable. If you use a Consent Management Platform, it must be configured correctly — a CMP that loads before consent is given is not a CMP, it is theater.

If you are using analytics, audit your network tab before and after accepting cookies. If requests to third-party domains fire before you click "Accept," your banner is decorative.

Gap 2: GDPR data subject rights that are not implemented

The GDPR grants EU residents eight rights. Most vibe-coded applications handle at most one of them adequately — account deletion, because founders generally think to include a "delete my account" button. The rest are commonly absent.

What we find missing:

• Right to access: No mechanism for a user to download all the data the system holds about them. A GDPR Subject Access Request (SAR) received by email requires a manual database export, with no tooling to produce it.
• Right to rectification: Users can edit their profile, but data held in logs, event tables, analytics systems, and third-party integrations is never updated.
• Right to portability: No export in a structured, commonly used, machine-readable format. A CSV of the user's own records is the minimum.
• Right to restriction of processing: No flag to pause processing of a specific user's data while a dispute is resolved.
• Right to object to automated decision-making: If the product uses any scoring, ranking, or segmentation logic, there is no disclosure and no way for users to opt out.

What compliant looks like: Build a "Privacy" section in user account settings that surfaces actionable controls for each applicable right. For a B2B SaaS, at minimum: data export, account deletion with documented data retention policy, and a contact route for SARs. Ensure deletion actually deletes — cascade through all tables, remove from third-party integrations (email platforms, CRMs, analytics), and document what is retained and for how long in your privacy notice.

Our code quality consulting process includes a data flow audit that maps every location where personal data is stored or transmitted — the prerequisite for implementing data subject rights correctly.

Gap 3: Missing or incorrect Data Processing Agreement infrastructure

If your SaaS processes personal data on behalf of business customers — which is the definition of a B2B SaaS — your customers are data controllers and you are a data processor. The GDPR requires a Data Processing Agreement (DPA) between you before processing begins.

What we find:

• No DPA template exists. Prospects from Germany, France, or the Netherlands will ask for one during procurement, and a missing DPA is a hard blocker.
• Sub-processor lists are absent or inaccurate. Your DPA commits you to listing every third-party service that touches customer data: your hosting provider, your email service, your analytics platform, your error monitoring tool.
• No mechanism to notify customers of sub-processor changes within the required timeframe.

What compliant looks like: Engage a data protection solicitor to draft a DPA that matches your actual data flows. Maintain a sub-processor list and keep it current. Consider publishing it at a stable URL so customers can check it without contacting you.

Gap 4: Audit logs that do not exist

Regulated industries — finance, healthcare, legal, HR — require audit trails. Even outside regulated verticals, GDPR accountability requirements mean you need to demonstrate that personal data was accessed only by authorised parties, and for documented reasons.

What we find:

• No audit log table in the database. Admin actions, data exports, user impersonation, and permission changes leave no record.
• Application logs exist (stdout, Sentry) but contain no structured record of who did what to which record at what time.
• Log retention is not defined — logs are either kept forever or rotated out of existence after 7 days.

What compliant looks like: Implement a structured audit log: actor (user ID and role), action (verb), target (resource type and ID), timestamp, IP address, and outcome. Store it separately from the main application database if possible. Define a retention policy — typically 12 months for operational logs, longer for compliance-critical events.

Gap 5: Accessibility that fails WCAG 2.2 from the start

The European Accessibility Act (EAA) came into force for private sector digital products in June 2025. WCAG 2.2 AA conformance is the practical standard it requires. AI-generated frontends, particularly those built with component libraries and Tailwind, often look accessible — they are not.

What we find:

• Color contrast ratios below 4.5:1 on body text, or below 3:1 on large text and interactive elements
• Form fields without programmatically associated labels — the <label for> attribute points to a non-existent ID
• Interactive elements that are not keyboard-reachable: dropdowns, modals, and date pickers that work with a mouse and break with Tab
• No visible focus indicator — the default browser outline has been removed with outline: none in the global CSS
• Images with missing or empty alt attributes, including UI icons that convey meaning
• Error messages that appear visually but are not announced to screen readers

What compliant looks like: Run an automated accessibility audit with axe-core or Lighthouse as a baseline — this catches roughly 30-40% of WCAG issues. Then test with a keyboard only, and test with VoiceOver or NVDA for screen reader coverage. Fix issues by layer: color and contrast first, semantic HTML second, ARIA roles third.

Our web application development process includes accessibility testing at each milestone, precisely because retrofitting accessibility is significantly more expensive than building it in.

Gap 6: No EU AI Act compliance consideration for AI features

If your product includes AI-generated content, AI-based scoring, automated decision-making, or AI-powered recommendations that have meaningful impact on users, you are now operating under the EU AI Act. Most vibe-coded SaaS products in 2026 include at least one of these features, often without the founding team realising it falls within scope.

What we find:

• No risk classification exercise has been performed. The team does not know whether their AI feature is minimal risk, limited risk, or high risk under the Act.
• No transparency notices for users who interact with AI-generated outputs, as required for limited-risk systems.
• No human oversight mechanism for automated decisions that significantly affect users.

What compliant looks like: For most B2B SaaS in the limited-risk category: add clear disclosure when users are interacting with AI-generated content, ensure there is a human escalation path for consequential decisions, and document the AI system in a technical file. High-risk systems (hiring, credit, health) require considerably more.

The compounding problem

None of these gaps is catastrophic in isolation when you are small. The compounding problem is that they all arrive at once when a serious customer runs a procurement security review, when a DPA sends a data subject request that exposes your lack of tooling, or when a competitor lodges an accessibility complaint. At that point, fixing five compliance gaps simultaneously while maintaining product velocity is expensive and disruptive.

The more cost-effective path is a structured compliance audit before you close your first significant EU deal, not after.

Where to start

If you have read this checklist and recognised your product, the highest-value first steps are:

1. Fix your cookie banner — test it in your browser's network tab today
2. Implement data subject request handling — SAR, export, and deletion as a minimum
3. Engage a data protection solicitor to draft a DPA template
4. Run axe-core against your five most-used pages and fix every critical and serious issue

If you want a structured review of your codebase against these requirements, the team at Wolf-Tech performs compliance-focused code quality consulting for EU-market SaaS products. We audit data flows, frontend accessibility, consent implementation, and audit logging, and deliver a prioritised remediation plan your team can act on.

Reach out at hello@wolf-tech.io or visit wolf-tech.io to talk through your situation. The earlier in the sales cycle you close these gaps, the less likely they are to close a deal for you.