Building GDPR-compliant software, including with AI and Lovable

1. Roles: controller and processor

The organisation that decides why and how personal data is processed is the controller. As the owner of the application, that is you. Parties that process data on your behalf, such as a hosting provider, a database vendor or an AI service, are processors.

You need a data processing agreement with every processor (Article 28 GDPR). It covers which data is processed, how it is secured and which sub-processors are involved.

• Lovable offers a data processing agreement (DPA) on its Business and Enterprise plans. Free and Pro do not include one.
• Lovable publishes its list of sub-processors, and it belongs in your record of processing activities.
• Every additional integration, such as an email service, payment provider or AI model, is a processor with its own agreement.

2. Security as a legal obligation

Article 32 GDPR requires appropriate technical and organisational measures. In practice, most data leaks in modern web apps are not advanced hacks but configuration mistakes: a table anyone can read, an API key in browser code or an admin feature that is only hidden in the interface.

• Database access rules (Row Level Security) that enforce which rows each user can see.
• Roles and permissions checked on the server, not only in the interface.
• Secret keys kept strictly on the server side.
• Input validation on every server function.
• Encryption in transit and at rest, and up-to-date libraries without known vulnerabilities.

3. Data minimisation and retention

You may only process personal data that is necessary for the purpose (Article 5 GDPR). What you do not store cannot leak. When building quickly with AI, it is easy to end up with tables full of unused fields, or logs containing complete form submissions.

• Decide for each field why it is needed.
• Define retention periods and delete or anonymise data automatically.
• Do not log personal data you do not need for operations or security.

4. AI and personal data

AI raises two separate GDPR questions. The first is about building: what happens to the prompts, code and files you share during development? The second is about how the app works: which data from your users is sent to an AI model?

• With Lovable, development data on Free and Pro may be used for model training unless you opt out. Business and Enterprise are excluded by default. Data from your app's end users is not used for training.
• Only send the data an AI model actually needs, and pseudonymise where you can.
• Check where the AI model runs. Processing outside the EEA requires appropriate safeguards.
• Automated decisions with legal effects fall under Article 22 GDPR. The European AI Act adds its own requirements for transparency and risk management.

5. Data subject rights

People whose data you process have the right to access, rectify, erase, restrict and port their data. You must be able to handle such a request within one month. Without support in the software, this becomes manual database work with a real risk of mistakes.

• A way to find and export all data about one person.
• Deletion or anonymisation without breaking links or reports.
• A record of when and how each request was handled.

6. Transfers outside the EEA

Many cloud and AI services are American. Transfers to the United States are allowed under the EU-US Data Privacy Framework or with standard contractual clauses, but they require deliberate choices and documentation. Even when servers are in Europe, an American parent company can fall under American law. That is the subject of our page on data sovereignty.