An AI app builder can hand you a working, deployed product in the time it takes to describe it. What it does not hand you is a consent layer: to add one, block analytics, tag managers and embeds until the visitor accepts, show a banner with an equal Reject all, and record each choice. The fonts, analytics, and embeds it wires in by default start firing the moment your first visitor loads the page, and under EU and UK law you, not the platform, are the party answerable for them.

This is the quiet problem with vibe coding. The code runs, the demo looks polished, and the consent work a traditional agency would have scoped never gets mentioned. Base44's own documentation says plainly that it does not add a consent banner to your app, and the code that Lovable, Bolt.new, v0 and Replit generate has none either unless you ask for one.

Getting from a text prompt to an app that meets the GDPR consent rules is mostly an exercise in finding what the generator left out and adding it back. Cookie consent sits near the top of that list.

Why AI builders ship without a consent layer

The tools are built around a single promise: describe an app, get a deployed URL. Speed is the product, and anything that slows the first run down works against it. A consent gate, a script blocker, and a geo-detection rule would all add friction to a funnel designed to remove it.

Adoption has run well ahead of the guardrails, and the output reflects those priorities. In May 2026, the security firm RedAccess told Axios it had found about 380,000 publicly reachable assets built with Lovable, Base44, Replit and Netlify, around 5,000 of them containing sensitive data. The platforms disputed the findings: Lovable and Wix said RedAccess had not shared the URLs they needed to check them. Privacy plumbing that does not exist cannot be enforced, and consent handling is part of that plumbing.

What loads when your AI-built app starts

Before you add a single tracking pixel of your own, a generated front end usually pulls in third-party resources. A typical scaffold loads web fonts from Google's content delivery network, wires in an analytics package, and drops in an embed or two for video or maps. Each of those is a request to an external server, and each one can transfer a visitor's IP address or set a cookie.

ComponentTypical defaultWhat it sets or transfersPrior consent needed?
Web fontsGoogle Fonts via CDNVisitor IP sent to Google serversYes, unless self-hosted
AnalyticsGoogle Analytics 4, hosted dashboards_ga, _ga_<ID>, page-view dataYes
Tag managerGoogle Tag ManagerLoads downstream tags that set _gcl_auYes
Media and social embedsYouTube, maps, share widgetsThird-party cookies, IP transferYes
Session and loginFirst-party session cookieSession ID, or a login token in localStorageNo, strictly necessary
Error monitoringThird-party logging serviceDevice and IP data to a third partyUsually yes

The session cookie that keeps a user logged in is strictly necessary and needs no consent. Almost everything else on that list does. The distinction is not cosmetic, and getting the cookie categories right is the foundation everything else rests on.

The platform built it, but you are the data controller

Vibe coding platforms generate and host code. They do not become the data controller for the app you deploy. That role, and the liability attached to it, belongs to whoever puts the site in front of visitors.

A 2022 ruling by the Regional Court of Munich made the point concrete. A website operator was found to have unlawfully transferred a visitor's IP address to Google by embedding Google Fonts through Google's CDN without consent, and was ordered to pay damages, with the court warning that repeat violations would draw far larger penalties. The same reasoning applies to any third-party asset that pulls a visitor's IP off their device: external stylesheets, JavaScript CDNs, font libraries, and embedded widgets all qualify.

Two fixes exist for that specific problem. Self-host the font files so no third-party request happens, or block the external request until the visitor consents. AI builders default to the CDN version because it is faster to scaffold, which leaves the work to you.

What the GDPR and the ePrivacy Directive require

The rule that catches most AI-built apps is prior consent. Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on a user's device, unless the cookie is strictly necessary for a service the user asked for. Displaying a banner while the analytics cookies have already fired does not satisfy it. The scripts have to be blocked first.

Enforcement has made this expensive. On 1 September 2025 France's CNIL fined Google EUR 325 million, in part because the consent it collected for ad cookies when people created an account was not free and informed, and fined the retailer SHEIN EUR 150 million for placing cookies before consent. Across the year the CNIL issued 83 sanctions worth about EUR 486.8 million, 21 of them over trackers, according to its 2025 enforcement review. The fines for cookie consent failures now reach hundreds of millions of euros for the largest platforms.

One shortcut does not work. Legitimate interest is not a basis for setting analytics or marketing cookies. The exceptions to consent are narrow: the CNIL exempts audience measurement that meets strict conditions, and the UK now exempts some first-party statistical analytics.

The picture has tightened in the United Kingdom too. Since 5 February 2026, the Data (Use and Access) Act 2025 lets the ICO fine PECR breaches up to GBP 17.5 million or 4% of global turnover, in line with UK GDPR, as the ICO's commencement statement confirms. The same Act added the narrow consent exemptions, so the change cuts both ways.

Six steps from prompt to consent

The work breaks into a handful of concrete tasks. None of them is large, but a generator will not do them for you.

  1. Scan the deployed app. You cannot consent-gate cookies you do not know about. A cookie scanner crawls the live site and lists every cookie and third-party request, including the ones the AI added silently.

  2. Categorise what you find. Sort each cookie into strictly necessary, functional, analytics, or marketing. Only the first group is exempt from consent.

  3. Block non-essential scripts before consent. This is the step generators skip entirely. Analytics, tag managers, and embeds must be prevented from running until the visitor opts in. Conditionally loading scripts on consent is the mechanism that makes the banner mean anything. With Kukie.io, the consent script goes first in <head> and each tag that must wait is marked as text with its category:

    <script src="https://cdn.kukie.io/s/YOUR_SITE_KEY/c.js" async></script>
    <script type="text/plain" data-cc-category="analytics"
      src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>

    Paste the same lines into a prompt and ask the builder to put them at the top of index.html.

  4. Add a banner that offers a real choice. Reject has to be as easy as accept, nothing can be pre-ticked, and a cookie wall that blocks the site until acceptance is not a valid choice under EDPB guidance.

  5. Self-host fonts and assets where you can. Pulling the font files onto your own server removes the third-party IP transfer and the consent question that comes with it.

  6. Keep a consent record and publish a policy. You need to be able to show what each visitor agreed to and when, and a cookie policy has to list what runs and why.

A prompted banner is not a consent layer

It is tempting to type "add a GDPR cookie banner" into the same tool that built the app. The generator will produce a banner component, and it will look correct. What it will not reliably do is block the scripts behind the banner, detect which visitors fall in scope by region, keep consent logs for audit, or update the cookie list when you add a new integration next month.

That distance between a banner that looks right and a system that blocks, records and updates is the real gap in vibe-coded apps. A static banner with no script blocking behind it can be worse than none at all, because it signals awareness of the rule while still breaching it.

This is the part a consent management platform handles end to end: it scans the app, categorises the cookies, blocks tagged scripts before consent, applies region rules, and stores the consent records. Kukie.io covers those functions for apps built on any of the major AI builders.

How the gap differs from builder to builder

The consent gap looks slightly different on each builder, because each ships a different default stack and deployment model. The AI builders hub collects a guide for each, with the cookies and integrations particular to that tool.

Builders that compile a full front end, such as Bolt.new and v0, tend to lean on Google Fonts and analytics out of the box. IDE-style assistants like Cursor and Windsurf leave the integration choices to you, so the consent work depends on what you wire in. Hosted platforms including Firebase Studio, a0.dev, and Cloudflare VibeSDK bundle their own analytics and edge features that carry their own consent implications.

AI-built apps and consent: quick answers

Do AI-generated apps include cookie consent by default?

No. AI app builders optimise for fast deployment, not consent, so they scaffold working code without a consent banner or script blocking. The cookies they wire in still fire on the first page load.

If an AI-built app sets cookies without consent, who is liable?

The person who deploys and runs the app is the data controller, not the platform that generated it. Liability for cookie and data-transfer breaches sits with the site owner.

Can I just ask the AI builder to add a cookie banner?

It can produce a banner that looks correct, but it will rarely block scripts before consent, apply region rules, or keep consent logs. A banner with no script blocking behind it still breaches the prior-consent rule.

Does an app built with Lovable, Bolt, or v0 need a cookie banner?

If it serves visitors in the EU or UK and sets any non-essential cookies, yes. The requirement depends on the cookies and the audience, not the tool that built the app.

Are Google Fonts a GDPR problem in AI-built apps?

They can be. Loading Google Fonts through Google's CDN transfers a visitor's IP address to a third party, which a German court ruled unlawful without consent. Self-hosting the font files removes the issue.

What happens if I deploy an AI-built app without cookie consent?

You risk complaints, cease-and-desist letters, and fines. The CNIL fined SHEIN EUR 150 million in September 2025 for cookies placed before consent, and UK fines under PECR now reach GBP 17.5 million or 4% of global turnover.

Add the consent layer your builder skipped

If you shipped an app from a prompt and have never checked what it sets on a visitor's device, start with a scan. Kukie.io detects the cookies and third-party requests your AI builder added, sorts them into categories, and blocks the non-essential ones until your visitor chooses. The Free plan covers up to 5 websites.

Start free