Boundsmap

Lovable’s terms put the AI contract with Lovable. What does this mean for your users’ data?

By Iain Barclay ·

Lovable's documents as read on 29 October 2026. Platforms change their plans and terms, so check the current pages before you rely on any of this.

Find your part of this page

Two questions. Our analysis is based on Lovable’s documents as read on 29 October 2026.

Which Lovable plan are you on?
How does your app reach the AI model?

The short answer

On Lovable's built-in AI, your contract for the AI in your app is with Lovable, not with OpenAI, Anthropic or Google. Lovable creates and manages the key and bills you in credits, so Lovable's terms are the ones to read first. Those terms also make your use subject to the model provider's own terms, which they don't name.

Lovable's documents offer its data processing agreement (DPA) with the Business and Enterprise plans. Free and Pro are covered by the Terms of Service, which include no DPA. From our read, Lovable's documents don't say whether the DPA covers the AI calls your app makes, on any plan that has one. And Lovable itself keeps some of what passes through, on some plans by default. Here we talk about what the documents do say, and what's still open.

Does your app use AI while it runs?

Lovable's agent writing your code isn't your app using AI. If nothing in your app calls a model when someone uses it, this page doesn't apply to you.

If it does (a chat, a summary, a draft reply, sorting or scoring something), and some of your users are in the EU or the UK, read on, wherever you are based. Boundsmap has rules for the EU and the UK, so that's the law this page covers.

Which plan are you on?

Here is what Lovable's pages say for each plan.

Lovable's Terms of Service (dated 28 August 2026) are "a legal agreement between you and Lovable Labs Incorporated". We found no processing terms in them.

How to tell which route your app uses: with built-in AI, "Lovable automatically generates and manages a LOVABLE_API_KEY for each project", and there's nothing for you to set up. With your own key, you asked Lovable to call the provider's API from a backend function, with your key stored as a secret, and the provider bills you.

Who receives your users' data?

There are three cases, and under the GDPR, in the UK and the EU, each company's role follows what it actually does with the data, not the paperwork.

Built-in AI on Free or Pro. Your contract is with Lovable, and there's no DPA. That doesn't make Lovable a controller, or a processor: the roles follow what each company does. It means the contract the law expects between you and anyone handling your users' data on your behalf (GDPR Article 28(3)) is not in Lovable's Free or Pro terms.

Built-in AI on Business or Enterprise. Lovable's DPA names "End users of published Lovable applications" among the people whose data it covers, and lets Lovable use the sub-processors it lists. But it never mentions Lovable's AI Gateway or the AI features in your app. Two readings are open:

We didn't find a document that says which. We haven't picked one.

Your own key. Your agreement for the AI call is with the model's maker. An account your company pays for, on business terms, usually comes with a processing agreement. A personal, free or consumer account usually doesn't. Our article Who's who in your AI supply chain? discusses this case. If your app uses Lovable's built-in backend, as it does unless you connected your own Supabase project, Lovable hosts it and runs the backend function that makes the call, and your plan's terms with Lovable cover that. On your own Supabase project, the function runs on Supabase, under your Supabase account.

Lovable's sub-processor list is undated. As read on 29 October 2026, it names OpenAI, Anthropic and Google (Vertex AI) as model companies, Microsoft (Azure AI Foundry) "for the AI Gateway", Amazon (Bedrock) and OpenRouter. All are listed in the US, and Microsoft also in the EU. It doesn't say which of them receive your app's AI calls and which serve the agent that writes your code.

Boundsmap, the tool we make to map who is responsible for what in an AI product, asks about this: how your product reaches the model. If you reach it through a cloud platform rather than from the model's maker, or build on a platform that calls the model for you, that platform is the one you contract with.

What Lovable itself keeps, and what it trains on

Three things Lovable's documents say, and one thing they don't:

If you paste real customer records into Lovable's build chat to test with, what you type there is a prompt, and Lovable's Privacy Policy counts prompts as your "Customer Content", which on Free and Pro it trains on unless you opt out. For records copied out of your own app, its definitions pull both ways: Customer Content "does not include Your Users' Data", and Your Users' Data includes "the records in your project's database". Either way, they are still personal data about real people.

What Lovable's rules put on you

Lovable's Provider Rules cover the other companies' services you can turn on inside Lovable, such as Firecrawl or Perplexity, which it calls Add-on Services. For those, they say: "Where the law requires it, tell your app's users which providers your app uses." Its Privacy Policy says "the person or organization that built an App is responsible for the data it collects and how it is used". That's how Lovable divides the work in its own documents. It isn't the law, but here it points the same way: under the GDPR, the people whose data your app handles have to be told who receives it, by name or by type of company (Article 13(1)(e)).

So, whatever your plan, these are the questions to ask about your own position:

Additionally, Lovable's list gives a US location for every model company on it, and EU regions too for Microsoft. Sending personal data to the US is an international transfer with rules of its own, which our Who's who article sets out.

If your customers are businesses

Where your app is used by other companies on their own clients' data, the personal data is theirs and you handle it on their behalf. Where Lovable handles that data on your behalf, it is then your sub-processor, and the model companies are a level further down. Your customers approve that chain, and hear before it changes (Article 28(2)).

On Free and Pro there's no agreement to pass your promises down in. On Business and Enterprise, unless your Order Form changes it, Lovable tells you of changes by updating its list, which "is updated at least annually". Whether you must name the model companies to your customers, or whether naming Lovable is enough, isn't settled. EU guidance leans towards the customer having the full chain to hand.

And the EU AI Act?

The EU's AI Act can reach an app built anywhere, if it's offered to people in the EU or its output is used there (Article 2(1)). Whether you count as the provider of your app's AI is a separate question, and the AI Act doesn't answer it for every system. Our Who's who article sets out what is settled and what is not.

If your app talks to people, as a chat app does, the AI Act asks the provider of the AI system to make sure they are told they are dealing with an AI (Article 50(1)). If it generates text, images, audio or video, the provider must also make sure that output is marked in a machine-readable way (Article 50(2)). Both have applied since 2 August 2026. An app placed on the market before then has until 2 December 2026, and only for the marking. The notice isn't needed where it's obvious to a reasonably well-informed person, given the context, that they're dealing with an AI. The marking isn't needed where the AI only assists with standard editing, or doesn't substantially change the text it was given. The text of Article 50 and the Commission's guidelines on it have the details.

Boundsmap

Whatever plan you're on, you're left to work out your own position: who handles your users' data at each step, on whose terms, and whose obligation each step is. Boundsmap maps your AI product onto five layers and four boundaries, and shows who is responsible for what at each one. The rules engine is deterministic and tested, and it isn't an AI model.

It doesn't give legal advice and doesn't replace an adviser. It gives you a checkable map of your own position, and a place to start the conversation with your team, your customers and a lawyer.

Pick your plan and route and your map starts with those facts filled in. Or see an example map of a chat assistant whose company reaches the model through a cloud provider.

Using Replit instead? Our Replit guide covers its plans the same way.

Explorer is free: map one AI product. See the plans.