Isn't Lovable in this case more analogous to a consultancy to whom customers outsourced their website builds — meaning the customers, not Lovable is 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…

[delayed]

This is what Lovable's terms say:

  # 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.

https://lovable.dev/terms

Disclaimers don't trump law. I'd love to see this tested in court.

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.

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.

Ok. One commenter in this thread was adamant that that was the case: https://news.ycombinator.com/item?id=50501973 you may want to clarify this there as well.

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?

And, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then 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 I've been sued.

> including the risk/cost of breaking a production build

If 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.