You Built It With Lovable — Who's Responsible When It Leaks Data?

A product manager needs an internal dashboard. Instead of filing a ticket and waiting a quarter for engineering, they open Lovable, describe what they want in plain English, connect it to the company's Google Workspace, and ship a working app the same afternoon. It reads from Drive, pulls a few spreadsheets, and emails a weekly summary. It works. Everyone is happy.

Nobody asks the question that matters six months later, when a security reviewer or a regulator does: who is responsible for how that app handles the data it touches?

The answer is not the platform that generated the code. It is the company that deployed it. This article explains why "we built it with AI" is not a defense, what specifically goes wrong with AI-built apps, and how to get visibility before the question is asked in anger.

What "AI-built app" actually means

A new category of tools — Lovable, Base44, Bolt.new, Cursor and a growing list of others — lets people build and deploy real web applications from natural-language prompts. They are often called "vibe coding" platforms. The appeal is obvious: a non-developer can produce something that previously required a team, and they can do it in hours.

These apps are not toys. They are deployed to real users, and they routinely connect to real company systems — Google Workspace, Salesforce, internal databases — through ordinary OAuth grants. From the data's point of view, an app built in an afternoon with a prompt and an app built over months by an engineering team look identical: both hold an access token and both can read what that token allows.

That symmetry is the heart of the problem. The speed that makes AI builders attractive is the same speed that lets an app reach sensitive data without anyone reviewing what it does with that data.

Building with AI is not the same as being safe

It is worth being precise and fair here: an app built with Lovable or Base44 is not inherently insecure. These platforms can produce perfectly reasonable applications, and many do. The risk is not that the AI writes bad code. The risk is governance, and it shows up in three predictable ways.

The deployer rarely reads the code. The entire value proposition of vibe coding is that you do not have to. So the person who shipped the app often cannot tell you how it stores data, whether it logs sensitive fields, where it sends information, or how long it retains anything. The accountable party has the least visibility into the thing they are accountable for.

The access is broad and invisible. AI builders ask for the scopes that make the demo work, and "make it work" often means broad read access. An internal dashboard that only needed to read one folder may hold read access to all of Drive. Because the grant happened through a normal OAuth consent screen, it never appeared on anyone's security radar — it is, definitionally, shadow IT.

There is no documented data-handling policy. Ask for the retention policy of a hand-built production system and you will usually get an answer. Ask for the retention policy of an app a colleague generated last Tuesday and there is nothing on record. Under data-protection law, "we don't know how long it keeps the data" is not a neutral answer — it is a finding.

Why the company — not the platform — is on the hook

Here is the part that surprises people. When an AI-built app mishandles data, the legal and regulatory responsibility lands on the organization that deployed it, not on the AI builder that generated it.

This is the same accountability shift now reshaping AI law generally. Under the EU's General Data Protection Regulation, the entity that determines the purposes and means of processing personal data is the data controller, and the controller carries the obligations — lawful basis, data minimization, storage limitation, and the duty to demonstrate all of it. When your company deploys an app that processes customer data, your company is the controller. The builder platform is, at most, a tool you used.

The wider 2026 legal landscape points the same way. Courts have begun treating the company using an AI system as responsible for its behavior — the *Mobley v. Workday* litigation in the United States proceeded on an agency theory and later won conditional certification of a nationwide collective action. In Germany, the OLG Hamm addressed responsibility for what an AI system tells customers and signaled that a general "no guarantee" disclaimer does not, by itself, shield the deploying company. The EU AI Act layers deployer-specific obligations on top, with significant penalties for high-risk uses. We cover that shift in depth in our overview of who is liable when an AI agent leaks data.

The common thread: deploying an AI-built app is a decision your organization made, and the law treats decisions as carrying responsibility. The fact that an AI wrote the code changes nothing about who chose to connect it to company data.

The blind spot, concretely

Put the pieces together and a specific, common failure mode appears:

• A non-technical employee builds an app with an AI builder.
• The app connects to Google Workspace through OAuth and is granted broad scopes.
• It reaches customer or employee personal data — contacts, email contents, files.
• Nobody reviewed the data handling, and there is no retention policy on record.
• Security has no inventory entry for the app, because it never went through a review.

Each step is individually reasonable. Together they produce an application that processes personal data, that your company is legally accountable for, and that your security team does not know exists. That is the gap an auditor probes and a breach exploits.

How to close the gap

The fix is not to ban AI builders — that race is already lost, and the productivity is real. The fix is visibility and evidence: know which AI-built apps are connected, know what each can reach, and be able to show you governed them.

That is exactly what 8200.dev does. It discovers the OAuth apps connected to your Google Workspace, and it flags the ones that originate from AI builders — Lovable, Base44, Bolt.new, Cursor and similar — from their app-name and redirect-host signatures, and from the tell-tale pattern of an unverified, recently-created app that already holds broad scopes. For each one you see the builder platform, the exact granted scopes, who authorized it, and a risk score, surfaced in a dedicated AI-Built Apps view alongside the rest of your AI agents and OAuth apps.

When an AI-built app can reach customer PII, or holds broad access with no documented retention policy, it raises a specific finding — so the gap becomes a task with an owner rather than a surprise in an audit. And every AI-built app can be recorded in the AI Agent Registry, so even the ones no connector reaches show up in one complete inventory. You can see the full feature set here.

The point is not to slow your teams down. It is to make sure that when the question comes — from a regulator, an auditor, or a customer security review — you can answer it. Not "we built it with AI, so it's the platform's problem," which is not a defense, but "here is the app, here is exactly what it can access, and here is the evidence we reviewed it." For a deeper look at what reviewers now expect, see what auditors require for AI governance in 2026.

Building with AI is fast. Being accountable for what you built is not optional. The two are reconciled by one thing: knowing what your AI-built apps can actually reach.

Start by seeing what is already connected to your Workspace. You can map your AI-built apps, score their access, and generate your first piece of evidence on the free tier — see plans and start free.

*This article is general information, not legal advice. Consult qualified counsel for guidance specific to your organization.*