GDPR does not specifically govern artificial intelligence, because it doesn't need to. If an AI tool touches personal data (a name, an email address, a CV, a support ticket, a photo of a person), the same rules apply as for any other software: you need a reason to process the data, you should use as little of it as possible, you must know where it is processed, and Luxembourgish businesses must be able to explain their choices if the CNPD (Commission nationale pour la protection des données) asks.
Where small teams get into trouble is not obvious: it is the plumbing around their AI use: a SaaS chatbot that trains on what your staff paste into it, a US-hosted tool with no data agreement, or a document assistant that indexes files nobody was supposed to keep. These are both architecture and human control problems, and both have clear best practices you can apply.
The best answer to "where does my data go" is an AI setup where the answer is "it stays here": EU-hosted infrastructure, or your own servers, with a contract that forbids training on your inputs. That is the architecture we can build for you, and it is why data protection is not an add-on for us. It is the default.
The CNPD publishes its own thematic dossier on AI and data protection. Simplified, it comes down to five questions you should be able to answer for any AI tool you use.
Every use of personal data needs a lawful basis under Article 6: consent, a contract, a legal obligation, or a legitimate interest you have weighed against the person's rights. The CNPD's guidance is explicit that this applies "for each data processing envisaged". An AI tool does not get its own exemption, not even for testing purposes. Need data for testing? We can provide fake data for checking workflows, new AI features, or integrations.
Data minimization (Article 5) means "adequate, relevant and limited to what is necessary". The CNPD notes that this is exactly where AI systems integrated with large corporate databases struggle. Small teams have the opposite advantage: with less data, you can decide precisely what an AI assistant sees and what it never touches.
Any provider that handles personal data for you is a processor and needs a written contract under Article 28. If the data leaves the EU, Chapter V on international transfers applies, and you need a recognized mechanism (an adequacy decision or standard contractual clauses with a transfer assessment). This is the GDPR question most consumer AI tools fail for use by businesses.
The CNPD expects organizations to "be transparent about the use of AI" and to explain how personal data is collected and used. If an AI system makes a decision about someone on its own, with a legal or similarly significant effect, Article 22 gives them the right not to be subject to it, with narrow exceptions. Keeping a human in the loop is the simplest way to stay clear of that.
Accountability (Article 5(2)) means being able to document the choices above. For a small team that is a record of processing under Article 30, a retention rule (the CNPD is clear that data "cannot be kept indefinitely"), and, where AI use is likely to be high-risk for people, a data protection impact assessment under Article 35. Not a binder of bureaucratese gathering dust in a drawer; a few pages you actually reference for staff enablement, and keep current.
None of this is specific to Luxembourg; GDPR is the same regulation across all businesses that serve EU customers. What is specific is the authority. The CNPD supervises GDPR here, and under the bill currently before Parliament it is also set to become the national authority for the AI Act, so the same body will be looking at both sides of any AI question you get asked about.
This is the real risk for compliance and EU sovereignty. There are three broad ways to run an AI model, and they sit at very different distances from GDPR.
Consumer and US-hosted SaaS tools. The free or B2C-subscription ChatGPT, Gemini, or Copilot tier that most people first use. Your prompts are processed outside the EU, may be used to improve the model unless you find and change a setting, and there is no data processing agreement between you and the provider. The EDPB's ChatGPT taskforce report puts the responsibility for GDPR compliance on the provider, not on the person typing, but that does not help you: as the organization, you are the controller of your customers' data, and you have just handed it to a party you have no contract with. Business tiers fix the contract and the training question, and some now offer EU data residency. They do not change who ultimately operates the service or which laws can compel access to it (such as the US CLOUD Act).
EU-hosted managed models. Open-weight models such as Mistral or Qwen, served by an EU provider on EU infrastructure, under a DPA that forbids training on your data. Nothing leaves the EU, the transfer chapter of GDPR does not apply, and the provider is a contracted processor. For most small teams this is the proportionate choice: it costs a fraction of a per-seat subscription and the risk assessment is short.
Self-hosted open-source models. The model runs on hardware you control, in Luxembourg or in an EU data centre you rent. There is no processor, no transfer, and no third party who can be compelled to hand anything over. The EDPB's opinion on AI models accepts that a model can be treated as anonymous, assessed case by case, where personal data cannot be extracted from it, which means the model file is not the problem; only what you feed it is. This is the cleanest data residency answer that exists, and for organizations handling sensitive data it is often the only one whose impact assessment comes out clean.
Our position, which we apply to our own work: use whatever model is best for building and for tasks that involve no personal data or truly unique intellectual property, and route anything that does involve personal data through the second or third option. For NGOs handling case files, that usually means self-hosting. For SMEs, EU-hosted is usually enough. The model is a tool; the architecture around it is where compliance lives.
Six points. If you can tick all of them, you are ahead of most organizations your size.
Read the training clause and the storage location. If either is wrong, the tier is wrong, or the company is not suitable to provide EU services as a data processor.
This one decision removes the international transfer question entirely, which is the most difficult part of the assessment to get right.
Names, addresses, health details, anything about an identifiable person. Redact it or use the contracted tool. This is the rule most often broken, and the easiest to fix with behaviour or guardrails.
Which tools are approved, what may go into them, who to ask. It doubles as evidence of accountability and as part of the AI literacy the AI Act has required since February 2025.
Chat logs, indexed documents, uploaded files. Decide how long they live and make the deletion automatic.
Drafts are fine to automate. Decisions about hiring, pricing, credit, or eligibility at a minimum need a person who can overrule the output, both for Article 22 and because the output is sometimes wrong. We would recommend not using those tools for those types of decisions.
A customer-facing chatbot is the AI use that many small organizations start with. It's also an ideal candidate for landing in GDPR hot water. Compliance comes down to three factors.
Where the conversation goes. Every message a visitor types is personal data the moment it contains anything identifying, and people type their names, order numbers, and problems into chat windows without thinking. If the chatbot is a wrapper around a US-hosted model, each conversation is an international transfer. An EU-hosted or self-hosted model behind the same chat window has no such problem, and the visitor cannot tell the difference.
What you tell people. Your privacy notice has to cover the chatbot: that it exists, what it collects, on what basis, and for how long. Separately, the AI Act's transparency rule, in force since 2 August 2026, requires that people are told they are talking to an AI unless it is obvious. One sentence at the top of every chat covers both.
What you keep. Chat logs are useful for improving the bot and dangerous to keep indefinitely. Set a retention period, strip identifiers from anything you keep for analysis, and never feed raw conversations back into a model's training data without a basis (and consent) for doing so.
Consent is rarely the right basis for a support chatbot: the person came to you with a question, and answering it is a legitimate interest or part of the contract. Where consent does matter is anything beyond the conversation itself, such as using it for marketing or profiling. Keep the chatbot doing the one job it was built for and the legal picture stays simpler.
GDPR is about personal data: why you have it, where it goes, and what people can ask of you. The AI Act is about AI systems as products: whether a given use is prohibited, high-risk, or simply needs to be disclosed. The two overlap wherever an AI system processes personal data, which is most of the time, but they ask different questions and are answered by different work.
This page covers the data side. The product side, including the transparency obligations that have applied since August 2026 and what "high-risk" actually means for a small team, is on our AI Act readiness page. For the wider picture of how small organizations here are adopting AI, see AI in Luxembourg.
We are not a law firm, and this page is practical guidance rather than legal advice. What we do is the part that makes the legal picture simple: choosing and setting up AI tools so that the answer to "where does the data go" is one you are happy to give. EU-hosted infrastructure, open-weight models where they do the job, self-hosting where the data warrants it, and a contract that forbids training on your inputs.
For a small team that usually means a short conversation about what data you actually hold, a decision about which of the three hosting routes fits, and a setup that keeps compliance as the default rather than a project you have to remember to do. If a question genuinely needs a lawyer, we will say so and work alongside yours.
Book a pre-discovery callYes, for work that involves no personal data, and with care for everything else. The free and consumer versions are the problem: prompts can be used to train the model and the data leaves the EU. Business tiers with a signed data processing agreement and no-training terms are a different conversation.
The question to ask is not "is ChatGPT allowed" but "what am I putting into it". Drafting a generic email or summarizing a public report involves no personal data and raises no GDPR question at all. Pasting a client's name, a candidate's CV, or an employee's performance notes into a consumer chatbot is a transfer of personal data to a processor you have no contract with, hosted outside the EU. That is the part the CNPD would ask you to explain. If your team uses these tools, the practical fix is a short internal rule about what may and may not go in, and a business tier with a data processing agreement for anything that touches real people.
No. Self-hosting solves the transfer and processor questions, which are the hardest ones, but GDPR still applies to what you do with the data: lawful basis, minimization, retention, and people's rights are all still yours to answer.
Self-hosting is the cleanest answer to "where does my data go", because the answer becomes "nowhere". It does not answer "why are you processing this at all", "how long do you keep it", or "can someone ask what you hold about them". A self-hosted document assistant that indexes every old email including ones you should have deleted years ago has a minimization and retention problem, however sovereign the server. The architecture removes a category of risk; the internal note and the retention rule handle the rest.
If the provider handles personal data on your behalf, yes: Article 28 GDPR requires a contract with specific terms. Most business or enterprise AI tiers offer one. Consumer tiers generally do not, which is the strongest reason to keep personal data out of them.
A data processing agreement (DPA) is the contract that makes a provider your processor rather than an unknown third party. It sets out what they may do with the data, that they act on your instructions, that they keep it secure, and what happens when you stop using them. Under Article 28 the agreement has to exist before the processing starts. For AI tools, check two things in it: whether your inputs can be used to train or improve the provider's models, and where the data is stored and processed. A DPA that permits training on your data is a DPA you probably do not want.
Only into a tool you have a lawful basis to use for that purpose, a processor agreement with, and that keeps the data where you can account for it. For most small teams that means an EU-hosted or self-hosted tool, not a consumer chatbot.
Customer data is personal data, so every GDPR principle applies. The purpose you collected it for has to cover what the AI does with it, or you need a new basis. The tool has to be a contracted processor. The data has to stay somewhere you can document, and it should be the minimum needed for the task: a support assistant that answers questions about an order needs the order, not the customer's entire history. If the tool makes decisions about people on its own (pricing, eligibility, screening), Article 22 adds further conditions, and a human in the loop is usually the simplest way to stay on the right side of them.
EU-hosted is enough for most small teams: an EU provider under a proper DPA keeps the data inside the GDPR's reach and avoids the transfer question entirely. Self-hosting is for organizations where even a contracted provider is a risk too far: sensitive case files, vulnerable people, hostile jurisdictions.
The distinction is about who else can see the data. With an EU-hosted managed model, the provider can in principle access it and is bound by contract and EU law not to misuse it. With a self-hosted open-weight model on your own infrastructure, nobody outside your organization can. For a marketing agency or an accounting firm, the EU-hosted route is proportionate and far cheaper to run. For a human rights organization handling testimony, or a clinic handling health data, self-hosting is often the only architecture whose risk assessment comes out clean. We build both, and we will tell you which one your situation actually warrants.
GDPR governs personal data; the AI Act governs AI systems as products, by risk level. Most small teams meet the AI Act through transparency duties (say when a chatbot is a chatbot, label AI-generated media) and meet GDPR through where the data goes and why. You need both, and they rarely conflict.
The two regulations overlap at exactly one point: an AI system that processes personal data is subject to both. The AI Act asks whether the system is prohibited, high-risk, or subject to transparency rules. GDPR asks whether the personal data flowing through it is processed lawfully. In Luxembourg both are expected to land with the same authority, the CNPD, which is one reason to treat them as one compliance conversation rather than two. Our AI Act readiness page covers the product side; this page covers the data side.
The regulatory statements on this page come from the following primary sources:
Regulatory content last reviewed 29 September 2026. This page is practical guidance, not legal advice. Guidance from the CNPD and the EDPB evolves: check the linked sources for the current position before relying on any statement here.
That is the normal starting point. A free 20-minute call to map what your team already uses, where the personal data is, and which hosting route makes the question go away.
Book a pre-discovery call