In Brief
- ✅ A business AI falls under the GDPR the moment it processes personal data: a customer email, a CV, a case file, a voice recording are each enough to trigger your obligations.
- ✅ Four obligations switch on with an AI project: define a legal basis, inform the people concerned, keep your record of processing activities, and run a data protection impact assessment (DPIA) when the processing is high risk.
- ✅ The hard part stays the non-EU transfers: a consumer tool often exports data to the United States, where the Cloud Act applies. Hosting in Europe with a non-US provider closes that door.
- ✅ In Luxembourg, the CNPD is the supervisory authority. The GDPR and the AI Act are two distinct frameworks: here we cover GDPR compliance for the data, not the AI regulation.
Introduction: your AI processes data, so the GDPR steps in
You are planning an AI project: an internal assistant, a chatbot, an agent that sorts your documents. The first question before you sign: what does it trigger under the GDPR?
The answer fits in one sentence: the moment your AI touches personal data, you enter the scope of the GDPR, with precise obligations. This article walks through the practical steps in Luxembourg, not a law course but a roadmap. The GDPR governs the data; it is a separate framework from the AI regulation (the AI Act), which we cover separately in our comparison of the AI Act, the Cloud Act and the GDPR.
1. Why a business AI falls under the GDPR (and exactly when)
A business AI falls under the GDPR the moment it processes personal data. Under EU Regulation 2016/679, personal data is any information relating to an identified or identifiable natural person: a name, an email, a case number, a recorded voice, a photo.
In practice, almost every business AI project touches this perimeter: an assistant that summarises customer emails, a chatbot that collects prospect messages, an agent that reads CVs all process personal data. The question is therefore not whether your AI is concerned, but how to make it compliant.
The threshold is low, and the right time for these questions is before deployment, not after an inspection. If your staff already use consumer tools without any framework, see our guide on protecting your business data against AI use.
2. The 4 GDPR obligations triggered by an AI project
When your AI processes personal data, four obligations switch on, summarised in the table below and detailed afterwards.
The 4 GDPR obligations triggered by a business AI project, with their reference article.
|
Obligation |
GDPR Article |
What it means |
|---|---|---|
|
Define a legal basis |
Article 6 |
Choose one of the six bases (consent, contract, legal obligation, vital interests, public interest task, legitimate interests) before connecting the AI to the data. |
|
Inform the people concerned |
Articles 13 and 14 |
State who processes, why, on what basis, where the data goes and for how long: privacy policy plus a clear notice about the AI. |
|
Keep the record of processing activities |
Article 30 |
Log the AI project as a new processing activity, with purpose, data categories, recipients and retention periods. |
|
Run a DPIA if the risk is high |
Article 35 |
Conduct the impact assessment before going live when the processing is high risk (sensitive data at scale, profiling, systematic monitoring). |
Obligation 1: define a legal basis
Before connecting an AI to a data flow, you need to know which of the six bases in Article 6 of the GDPR applies: often contract or legitimate interests for a support chatbot, consent for marketing. This qualification governs what you are allowed to do with the data.
Obligation 2: inform the data subjects
The people whose data passes through your AI must be informed (Articles 13 and 14 of the GDPR): through your privacy policy, and with a clear notice when a visitor is talking to an AI assistant rather than a human.
Obligation 3: keep the record of processing activities
The record of processing activities (Article 30 of the GDPR) lists every processing operation in the company. An AI project is a new one: it must appear there, or justify creating the record if one does not yet exist.
Obligation 4: run an impact assessment (DPIA) if the processing is high risk
The DPIA (Article 35 of the GDPR) is mandatory when a processing operation is likely to result in a high risk to individuals. The CNPD publishes the list of processing operations for which a DPIA is required in Luxembourg (list updated in 2019, supplemented by the criteria of the European Data Protection Board). When in doubt, the DPIA is the cautious reflex.
3. The real sticking point: data transfers outside the EU
The four obligations above are manageable with a method. The real sticking point is elsewhere: where does the data actually go?
With a consumer AI tool backed by a US vendor, your data can be processed outside the European Union or accessible to a provider under US law. The GDPR strictly governs these non-EU transfers (Chapter V, Articles 44 onward): they are lawful only under conditions, for example an adequacy decision or appropriate contractual safeguards.
A subtlety many executives discover late: a US vendor can host its servers in Europe and still be subject to the Cloud Act, because that law follows the nationality of the provider, not the location of the data centre. A server in Frankfurt operated by a company under US law is therefore not an absolute guarantee. We detail this interplay in our analysis of the AI Act, the Cloud Act and the GDPR: which law applies.
The cleanest exit for sensitive data is structural: host the AI in Europe, with a provider not subject to US law, and with data that never leaves the controlled perimeter. That is the logic of a private AI for business in Luxembourg: the non-EU transfer simply does not happen.
4. The role of the CNPD in Luxembourg
In Luxembourg, the supervisory authority for the GDPR is the Commission nationale pour la protection des données (CNPD), the national data protection commission. It oversees the application of the regulation, publishes guidelines and handles complaints and inspections.
What it expects is the ability to demonstrate compliance: a documented legal basis, a record kept up to date, information of the data subjects in place, a DPIA run when it was required. This is the accountability principle: you must not only be compliant, you must be able to prove it.
In an inspection, the company that planned ahead presents a tidy file; the one that improvised looks afterward for a legal basis for processing that is already live. Planning ahead turns an inspection into a routine check.
5. GDPR and AI Act: two frameworks, not the same one
A clarification that comes up often: the GDPR and the AI Act are not the same text and do not cover the same thing.
The GDPR (EU Regulation 2016/679, applicable since 2018) governs personal data: collection, processing, movement. That is the subject of this article.
The AI Act (EU Regulation 2024/1689, fully applicable on 2 August 2026) governs the AI system itself, classified by its level of risk. It is a distinct framework, with its own obligations.
The two stack up: a single business AI can fall under the GDPR (personal data) and the AI Act (AI system). Our overview of AI agent use cases in business places each obligation against concrete examples; this article stays focused on the GDPR.
6. How a sovereign AI simplifies your GDPR compliance
GDPR compliance is simpler when the architecture works in your favour from the start. A sovereign AI, hosted in Europe and operated by a provider not subject to US law, removes several locks:
- Non-EU transfers: the data stays within the European perimeter; Chapter V of the GDPR stops being a headache.
- Data not shared: your content does not train a third-party model, which simplifies the legal basis and the information of data subjects.
- Controlled legal basis: you know who processes what, where, and with which contractual safeguards.
- Reversibility: you keep your hand on your data and can retrieve it, a sound governance requirement.
That is why we recommend this approach to organisations handling sensitive data. See why choose a private AI, and the comparison with a consumer tool on our page about the ChatGPT alternative in Luxembourg for businesses.
7. Your compliance roadmap in practice
- Map the data: which personal data will your AI actually process, and where does it come from?
- Qualify the legal basis: consent, contract, legitimate interests? One purpose, one basis.
- Trace the data journey: where is it processed, by whom, does it leave the EU? This is where the essentials are decided.
- Log the processing in the record and update the information given to data subjects.
- Decide on the DPIA: high-risk processing? If so, you run it before going live.
- Choose an architecture that simplifies the whole thing: an AI hosted in Europe closes the transfer question at the design stage.
This sequence is not reserved for large organisations: a Luxembourg SME can hold it with the right support. That is the ground we work on, with AI agents for businesses in Luxembourg designed for compliance from the outset.
Want to know what the GDPR means in your specific case? Let us talk through your use case in a meeting: we look together at your data, your legal basis and the simplest architecture.
Frequently asked questions
Is ChatGPT GDPR compliant for my business?
It depends on the use. A consumer tool backed by a US vendor raises two questions: where does the data go and who can access it. On ordinary data with a contractual framework, a controlled use can be considered. On sensitive data (legal, medical, financial), an AI hosted in Europe by a non-US provider is the safest route, because it closes the question of non-EU transfers.
Do I need a DPIA for an AI chatbot?
Not systematically. The DPIA (Article 35 of the GDPR) is mandatory when the processing presents a high risk to individuals. A basic FAQ chatbot on low-sensitivity data does not necessarily trigger one; a chatbot that profiles, processes sensitive data or operates at scale does. The CNPD publishes the list of processing operations for which a DPIA is required in Luxembourg: that is the first reflex to settle the matter.
Who is the controller, me or the AI vendor?
Generally, you are: the company that decides the purposes and means of the processing is the controller. The AI tool vendor is most often a processor within the meaning of the GDPR (Article 28), which requires a processing agreement framing its obligations. Responsibility for compliance cannot be fully delegated to the tool.
Is hosting in Europe enough to be GDPR compliant?
Important, but not enough on its own. First because a provider under US law remains subject to the Cloud Act even with European servers. Second because GDPR compliance covers far more than location: legal basis, information of data subjects, record, retention periods, data subject rights. European hosting by a non-US provider settles the hard point of transfers, not the whole.
In summary
Bringing in an AI means opening a new processing of personal data, and therefore engaging the GDPR. Four obligations kick in: legal basis, information, record, DPIA if there is risk. The most delicate point stays the non-EU transfer, which European hosting by a non-US provider closes at the source. In Luxembourg, the CNPD is the reference authority, and the GDPR remains distinct from the AI Act. Planning ahead before deployment turns compliance into an advantage. Let us talk through your use case.
