# AI-built apps holding EU personal data: the GDPR exposure Lovable, Bolt, Base44 and Bubble never mention

**Answer first:** Most AI-built apps that hold EU personal data sit outside the GDPR in four places at once: an open backend that is a reportable breach in waiting, a platform processing your users' data without the contract Article 28 requires, data stored or processed in the United States without anyone deciding that, and generated schemas that keep everything and can delete nothing cleanly. Lovable's own DPA page states the agreement comes with Business and Enterprise plans (last updated November 6, 2025); Base44 documents that all its servers "are currently located in the United States" (docs, 2026). This guide maps the exposure, gives you a twenty-minute self-check, and separates what a patch fixes from what needs a rebuild.

*Updated August 2026 · By Henrik Hallengren, independent rebuild specialist*

Canonical version: https://rebuild.hallengrens.com/articles/gdpr-ai-built-apps-eu-personal-data/

---

## Why AI-built apps land on the wrong side of the GDPR

The short answer: the platforms optimise for a working demo, and the GDPR judges the system behind it. Lovable, Bolt, Base44 and Bubble each make a stack of default decisions on your behalf, where the database lives, which sub-processors touch it, what gets logged, what the schema stores, and none of them were made with your users' rights in mind. That isn't malice. It's that the founder is the controller under Article 4(7) of the GDPR, and the controller carries the obligations whether or not the founder ever saw the settings. The [Lovable page](https://rebuild.hallengrens.com/lovable/) covers the technical wall; this piece covers the legal one that arrives with the same product.

A hand-built product has an engineer who once made each of these decisions and can explain them; an AI-built product has a prompt history. When a supervisory authority, a customer's procurement team or an acquirer's due diligence asks "who processes this data, where, under what contract, and how do you delete it," the honest answer for many AI-built apps in August 2026 is "I don't know." Under the GDPR, not knowing is itself the finding: Article 5(2) makes the controller responsible for demonstrating compliance, not merely having it.

## Exposure one: an open backend is a reportable breach, and the clock is 72 hours

**Answer first:** the pattern documented in the [Row Level Security exposure guide](https://rebuild.hallengrens.com/articles/lovable-supabase-rls-exposure/), a Supabase backend reachable with the public key and no row-level policies, is not only a security bug. If the tables hold personal data, unauthorised access to them is a personal data breach as Article 4(12) defines it, and Article 33 requires notification to the supervisory authority "without undue delay and, where feasible, not later than 72 hours" after you become aware, unless the breach is unlikely to result in a risk to the people affected. Where the risk is high, Article 34 adds a duty to tell the users themselves.

Two details make this worse for AI-built apps. First, awareness is hard to time when there are no logs: many generated apps ship without access logging on the database, so you cannot say whether anyone read the open table, for how long, or what they took. The Finnish Data Protection Ombudsman's Vastaamo decision (December 2021) shows how that ends: the company could not reconstruct the intrusion because "sufficient log data had not been kept," and was fined €608,000, of which €291,200 was for the notification failures alone. Second, the failure that lets the data out and the failure to notify are separate infringements, fined separately, and Article 83(2)(h) explicitly weighs how the authority found out: whether you told them, or someone else did.

## Exposure two: your platform is a processor, and Article 28 wants a contract

**Answer first:** every platform that hosts your users' data is a processor, and Article 28(3) says the processing "shall be governed by a contract" binding it to documented instructions, confidentiality, security, sub-processor control and deletion at the end. That contract is the Data Processing Agreement, and whether you have one depends on your plan and on whether you ever asked. Lovable's DPA page (last updated November 6, 2025) says: "If you're on a Business or Enterprise plan, your usage includes our Data Processing Agreement." Supabase publishes a DPA (Version 1, August 1, 2026) and a sub-processor list (updated June 1, 2026). Base44 publishes a DPA at base44.com/dpa; Bubble's manual states Bubble "serves as a data processor for your company" with the EU Standard Contractual Clauses built into its DPAs. Bolt is the odd one out: StackBlitz's privacy policy (May 12, 2026) says it "does not apply to personal data processed by customers within applications they build," which is "governed by applicable customer agreements and data processing addenda, where applicable"; I found no public self-serve DPA, so if you build on Bolt, ask.

The layer founders miss is the chain below the platform: each of these lists sub-processors you have a right to object to under Article 28(2) (Lovable's DPA gives twenty business days). If you never read the list, you never exercised the right. Article 28 sits in the €10 million or 2% tier of Article 83(4), the same tier as Articles 32 and 33.

## Exposure three: where the data actually lives, and the US question in 2026

**Answer first:** on all four platforms, "in the EU" is a setting you had to choose, not a default you got. Lovable Cloud lets you pick a region, and its docs are clear on the consequence: "Once Cloud is enabled for a project, the selected region is locked and cannot be changed. Existing projects cannot be moved across regions." Supabase's docs add a subtler trap: the general "Europe" grouping "includes London and Zurich, which are not EU member states," and "choosing a region is a data-location control and does not make your application GDPR compliant on its own. Backups, logs, data exported to external systems, Edge Function execution, and sub-processors can affect your data residency." Base44's docs say all servers are in the United States by default; since April 16, 2026, Elite and Enterprise workspaces can choose EU or UK clusters, for apps created after that date only, and "data residency controls where your data is stored, not where it is processed."

Transfers to the US are lawful today under the EU–US Data Privacy Framework and the Standard Contractual Clauses all four platforms reference. But the ground is contested: the General Court dismissed Philippe Latombe's challenge on September 3, 2025 (IAPP), and his appeal, Case C-703/25 P, filed October 31, 2025 (WilmerHale), is pending before the Court of Justice, the court that struck down the two previous frameworks. Nobody can tell you how it ends. What a founder can do is know which data ever crosses the Atlantic, so that a ruling changes a setting, not the business.

| Platform | DPA | EU data location | In the platform's own words |
|---|---|---|---|
| Lovable (Lovable Cloud) | Included on Business and Enterprise plans (DPA page, Nov 2025); signed version dated Nov 17, 2025 | Region chosen at Cloud setup, locked afterwards | "Existing projects cannot be moved across regions." (docs) |
| Supabase (direct) | Published, Version 1, Aug 1, 2026 | Specific EU regions: Ireland, Paris, Frankfurt, Stockholm; general "Europe" includes London and Zurich | Region choice "does not make your application GDPR compliant on its own." (docs) |
| Base44 (Wix) | Published at base44.com/dpa | US by default; EU/UK clusters for Elite/Enterprise, new apps only, since Apr 16, 2026 | "All Base44 servers are currently located in the United States." (docs) |
| Bubble | DPA with SCCs; grandfathered into DPF (manual) | EU dedicated servers on Enterprise | "Merely storing data in an EU data center doesn't meet all the necessary requirements." (manual) |
| Bolt (StackBlitz) | No public self-serve DPA found; "where applicable" (privacy policy, May 2026) | Depends on the backend you connect, typically Supabase | Users told not to put sensitive personal data in prompts (privacy policy) |

## Exposure four: schemas that hoard, and deletion that doesn't delete

**Answer first:** Article 5(1)(c) requires personal data to be "limited to what is necessary," Article 5(1)(e) limits how long you keep it, and Article 17 gives users a right to erasure. Generated schemas fail all three by default, because a generator asked for a feature adds columns and never asks what the product needs to know. The result is the "save everything" schema: full addresses where a country would do, uploads kept after processing, event tables that grow forever, and, in every AI-built app with a chat feature, the entire conversation history. Under Article 4(1), a chat transcript that relates to an identifiable person is personal data, and it usually holds more of it than the profile table does.

Deletion is where these apps break most quietly. A generated "delete account" button typically deletes one row in one table. It rarely reaches storage buckets, third-party services the app pushed data to, analytics, the platform's own backups, or the AI logs. Article 28(3)(g) also requires the processor to delete or return your data when the contract ends, so leaving a platform is itself a deletion event to verify, not assume.

## Check your own app in twenty minutes

**Answer first:** four checks, no lawyer needed, in this order.

1. **The contract check (5 min).** Find the DPA that applies to your plan on every platform that touches user data: builder, backend, auth, email, analytics, payments. Save the PDF and the sub-processor list with a date. If a page says the DPA comes with a plan you are not on, that is your first gap.
2. **The location check (3 min).** Open each backend and read the region. Note whether it is a specific EU region or a general grouping, and which services and backups sit outside the EU. That list is your transfer analysis, in embryo.
3. **The exposure check (10 min).** Run the Row Level Security test from the [RLS guide](https://rebuild.hallengrens.com/articles/lovable-supabase-rls-exposure/) against every table holding personal data, then check whether database access logging is on. Real rows back and logging off means you cannot rule out a breach you would have to report.
4. **The deletion check (2 min).** Delete a test account and look for its traces: storage, related tables, the AI conversation table, the email provider, analytics. Every place the record survives is an Article 17 gap.

## What a patch fixes and what needs a rebuild

**Answer first:** the contract and location gaps are usually paperwork and settings; the exposure and deletion gaps split between quick fixes and structural ones. Signing the right DPA, reading the sub-processor list and documenting your region choices is a day of founder time, and it moves you from "don't know" to "can demonstrate," which is what Article 5(2) asks. Enabling RLS and logging is quick; designing correct policies is finite work, as the RLS guide sets out.

The structural line runs through the platform layer. If your access control and deletion logic live inside a platform whose region is locked, whose logs you can't configure and whose schema regenerates when you prompt, every fix can be silently undone by the next generation, and you cannot show an auditor a system, only a history of prompts. That is where the honest answer is a rebuild: your product on infrastructure you control, in a region you chose, with logging, retention and deletion designed in from the first table, which is what Article 25 means by data protection by design. The ten-question patch-or-rebuild assessment on the [Lovable page](https://rebuild.hallengrens.com/lovable/) tells you which side of the line you are on; a regulated vertical (health, finance, HR, anything involving minors) puts a thumb on the rebuild side.

## What the alternatives cost

**Answer first:** the reference numbers are public. Article 83 caps fines at €10 million or 2% of worldwide turnover for security, processor and notification failures (Articles 28, 32, 33) and €20 million or 4% for breaches of the principles, of data subject rights and of transfer rules. Those are ceilings for large undertakings; the small-company reality is smaller and closer. CNIL's official sanctions list (page dated April 14, 2026) shows the simplified procedure it uses against smaller organisations, which it does not name: on April 30, 2025 a dating-site operator was fined €20,000 for, among other things, missing processor contracts, insufficient security and failing to notify both the authority and the people affected; on September 4, 2025 a recruiting-software company was fined €7,000 for processor contracts, records, security and breach documentation; on December 15, 2025 a payroll-software company was fined €15,000 for insufficient security. The CMS Enforcement Tracker counted 2,685 fines across the EU by March 1, 2026, up 440 in a year. Vastaamo shows the tail: €608,000 in fines, and bankruptcy in February 2021, before the fine was even issued.

Against that: a privacy lawyer or fractional DPO gets your paperwork and record of processing right for a few thousand euros, and cannot fix a schema. My diagnosis is [€7,500, fixed, one week](https://rebuild.hallengrens.com/engagement/): what your system actually does with personal data, mapped to these four exposures, and a priced answer for each, patch or rebuild. Full rebuilds of proven products land, in my band and in published market spans, between €50,000 and €150,000; one designed for EU data from the start doesn't cost more than one that isn't, retrofitting does. The wrong purchase is compliance documents describing a system nobody can verify.

## Built inside the EU's frame, by someone who has worked in it

I am not a lawyer, and this is not legal advice; for a DPIA, a records-of-processing review or a notification decision, you want counsel, and I will say so in the first call. What I am is a builder who has worked inside European frameworks for twenty years, in Swedish and European companies where the GDPR was a design input rather than a slide at the end. That shows in how a rebuild is scoped: region and processor choices made before the first table, retention as a column, deletion as a tested path, logs that exist because someone will one day ask. It's a structural advantage over an agency for which the EU is an export market, and the plain reason this guide exists.

## Questions founders actually ask

**My app is on Lovable's Pro plan. Do I have a DPA?**
Lovable's DPA page (November 2025) says the DPA comes with Business and Enterprise plans. What lower plans include is not stated on that page, and I've left it unverified rather than guess. Check your plan against lovable.dev/data-processing-agreement, and if you hold personal data on a plan the page doesn't cover, upgrade or ask Lovable in writing.

**I picked "Europe" for my Supabase project. Am I in the EU?**
Not necessarily. Supabase's docs say the general "Europe" grouping includes London and Zurich, neither an EU member state, and that if you need EU specifically you should choose a specific region such as Ireland, Paris, Frankfurt or Stockholm. Read the same docs' caveat: backups, logs, exports, Edge Functions and sub-processors can sit elsewhere.

**Is the EU–US Data Privacy Framework still valid?**
Yes, as of August 2026. The General Court upheld it on September 3, 2025, and the appeal, Case C-703/25 P, is pending at the Court of Justice with no hearing date announced as of mid-2026. Plan for both outcomes: know which data crosses to the US and under which mechanism, so a ruling changes a setting, not the product.

**If my Supabase table was open, do I have to report it?**
If it held personal data and you can't rule out that someone accessed it, treat it as a personal data breach and start the Article 33 clock the moment you become aware. Notification is required unless the breach is "unlikely to result in a risk"; missing logs don't make it unlikely, they make it unprovable. Get counsel the same day, and note that Article 83 counts self-notification in your favour.

**Can I just move to an EU-hosted platform and be done?**
No, and the platforms say so themselves: Bubble writes that an EU data centre alone doesn't make an app compliant, and Supabase writes that region choice "does not make your application GDPR compliant on its own." Location is one of four exposures. Contract, minimisation and deletion are the other three, and they live in how the system is built.

---

**Henrik Hallengren** rebuilds proven products to production grade: product, business, design and tech in one head, across 20+ years and brands from Google to Mondelēz, worked with across roles and projects. Independent: no platform partnerships, no referral fees. More at [hallengrens.com/henrik](https://hallengrens.com/henrik/) · [LinkedIn](https://www.linkedin.com/in/henrikhallengren)

Holding EU personal data on an AI-built stack and not sure where you stand? Take the ten-question patch-or-rebuild assessment → [/lovable/](https://rebuild.hallengrens.com/lovable/) — or book a straight 20-minute read → [/contact/](https://rebuild.hallengrens.com/contact/)