Isn't Lovable in this case more analogous to a consultancy to whom customers outsourced their website builds — meaning the customers, not Lovable are responsible for these actions?
On a larger note, and not at all to downplay the seriousness of this breach, but this feels like the kind of growing pain we're going to continue going through as we move to an AI-driven world. Who's responsible for the work of the AI? In this case, I think it's pretty cut and dry, since Lovable sells a service that _happens_ to be powered by AI (it could just as easily have been done by an outsourced team instead). But as AI gains more agency, it's going to become less and less clear…
If the consultancy delivers vulnerable software to the customer, the customer would most likely sue the consultancy for any damages they incurred. Especially if there is a maintenance contract, where the consultancy handles any security upgrades etc that are necessary.
# AI Output
The Services may use artificial intelligence models to
generate code, content, or other outputs ("AI Output").
AI Output may contain errors, inaccuracies, or other
issues and should not be relied upon without
independent review and testing. You are solely
responsible for reviewing, validating, and using any
AI Output, whether it is generated through:
- our Platform's integrated AI;
- the AI Gateway (via Third-Party AI Providers); or
- any model or API that you connect to the Services.
I've never used lovable; do they have any sort of human-approval gate step between (or around) generating an app and deployment/availability? INAL but I wonder if that would CYA for responsibility of releasing bad code created by their AI...
Those are all good questions, I think the customers' perception is that they have outsourced this but obviously they too have a responsibility (for instance: to do due diligence on the parties they do business with to make sure that they are observing their duties as controllers). One thing is certain: the data subjects are without blame and their interests have been violated substantially, the question really is what else happened to the data and that is something that nobody knows right now. But if it is true that it ended up on common crawl then that would be quite a big problem.
The controller/processor relationship is very clearly described as part of the GDPR and there is little doubt in my mind that both of these parties jointly and separately carry responsibility here.
To clarify: no PII leaked from Lovable apps ended up in Common Crawl. Common Crawl was used solely to identify Lovable apps—not to retrieve leaked data. It does not store XHR responses, which are how data is retrieved from Supabase.
Any data fetched during the analysis was deleted long ago, though you’ll have to take my word for that. Only metadata was retained.
That said, I fully agree that no one can say for certain whether anyone else collected this data or what happened to it afterward.
[−]unclebucknasty · 2026-11-15 Sun 00:43 UTC ·
link
As with many gray areas in the law, this all likely comes down to a reasonableness test. New laws may be needed but, to the fullest extent possible, these issues will be framed through the lens of existing law—e.g. product liability. And, once tested in court, these will likely lead to new precedents around existing laws.
For instance, questions will arise as to whether it's reasonable for Lovable to hand this kind of power over to a customer. And, if their software is capable of detecting vulnerabilities, but allows the customer to proceed, is that reasonably responsible behavior on Lovable's part?
Then, there are tests regarding what their customers should reasonably be expected to understand. For instance, it might be tempting to compare this to gun liability laws, wherein manufacturers can disclaim responsibility if their guns are mishandled. But, here, what is the level of knowledge required to fully understand the risks—including the risk/cost of breaking a production build? And, is it reasonable that their customer should be expected to understand?
So, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then customers may argue that they were "set up", and it may prove very difficult to pin the blame on those customers.
Attorneys would likely argue that Lovable can't have it both ways—selling to amateurs, then blaming their customers for being amateurs.
Disclaimer: I once played a lawyer in a 7th grade mock court. Oh, and my company was once sued.
Although already mentioned in the research report, the following links show that Lovable explicitly targets non-technical customers, stating that no technical expertise is required:
This fundamentally changes the startup equation:
- No need to convince a developer to join before validation.
- No delays from back-and-forth translation between business and tech.
- Immediate product iterations, turning feedback into new features
within hours.
With Lovable, non-technical founders cut months of friction and focus
entirely on product-market fit, rather than struggling to find a
development team.
All you need to kick off your vibe coding journey is an AI-powered
no-code builder (like Lovable). As long as you can describe what
you're looking to build, you can build it.
On a larger note, and not at all to downplay the seriousness of this breach, but this feels like the kind of growing pain we're going to continue going through as we move to an AI-driven world. Who's responsible for the work of the AI? In this case, I think it's pretty cut and dry, since Lovable sells a service that _happens_ to be powered by AI (it could just as easily have been done by an outsourced team instead). But as AI gains more agency, it's going to become less and less clear…
The controller/processor relationship is very clearly described as part of the GDPR and there is little doubt in my mind that both of these parties jointly and separately carry responsibility here.
Any data fetched during the analysis was deleted long ago, though you’ll have to take my word for that. Only metadata was retained.
That said, I fully agree that no one can say for certain whether anyone else collected this data or what happened to it afterward.
For instance, questions will arise as to whether it's reasonable for Lovable to hand this kind of power over to a customer. And, if their software is capable of detecting vulnerabilities, but allows the customer to proceed, is that reasonably responsible behavior on Lovable's part?
Then, there are tests regarding what their customers should reasonably be expected to understand. For instance, it might be tempting to compare this to gun liability laws, wherein manufacturers can disclaim responsibility if their guns are mishandled. But, here, what is the level of knowledge required to fully understand the risks—including the risk/cost of breaking a production build? And, is it reasonable that their customer should be expected to understand?
So, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then customers may argue that they were "set up", and it may prove very difficult to pin the blame on those customers.
Attorneys would likely argue that Lovable can't have it both ways—selling to amateurs, then blaming their customers for being amateurs.
Disclaimer: I once played a lawyer in a 7th grade mock court. Oh, and my company was once sued.
Although already mentioned in the research report, the following links show that Lovable explicitly targets non-technical customers, stating that no technical expertise is required:
https://lovable.dev/blog/what-is-vibe-coding
https://lovable.dev/blog/2025-01-30-why-non-tech-founders-no... https://lovable.dev/founders https://lovable.dev/vibecodingIf the customer is deploying (“to prod”) they need to know enough to assess their own risks of breaking their software.
I’d want to see the text of the warning to customers before having an opinion on how in/sufficient it was.