EU AI Act and GDPR: the questions to answer before you deploy an LLM feature

Regulation (EU) 2024/1689, the AI Act, entered into force on 1 August 2024 and applies in phases. Prohibited practices and AI literacy obligations applied from 2 February 2025; obligations for general-purpose AI models from 2 August 2025; the bulk of the high-risk regime follows later. GDPR applies throughout, unchanged, and for most organisations it is the more immediately demanding of the two.

Question 1: are you a provider or a deployer?

This determines almost everything that follows. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity.

Most European businesses building a feature on top of a third-party model are deployers, which carries a substantially lighter obligation set. But the roles can shift: if you substantially modify a high-risk system, or put your own name on a system placed on the market, you can become a provider with the full obligation set attached. If you are building something customer-facing on a foundation model, get this classified in writing early.

Question 2: which risk tier does the use case fall into?

Question 3: is personal data involved, and on what basis?

This is where most projects actually run into trouble, and it is GDPR rather than the AI Act doing the work. Four sub-questions, in order.

1. What is the lawful basis for this processing? If it is legitimate interests, the balancing assessment has to be documented, and it has to account for the fact that the data is being sent to a third-party model provider.
2. Is the model provider a processor, and is there an Article 28 agreement in place covering this use? Consumer-tier terms typically do not provide one.
3. Where is the processing performed, and if outside the EEA, what transfer mechanism applies? Model API endpoints frequently default to a non-EU region, and this is a configuration decision that is often made by whoever set up the integration.
4. Does the processing require a data protection impact assessment? Systematic evaluation of personal aspects, large-scale processing of special category data, and innovative use of new technology are all DPIA triggers, and a novel LLM feature processing customer data commonly hits more than one.

Question 4: can you satisfy data subject rights?

This is the question that most often has no good answer, and it is better discovered at design time.

• Erasure. If a person requests deletion, can you remove their data from prompt logs, from any vector store or embedding index, and from anything the provider retains? Embeddings derived from personal data are generally still personal data.
• Access. Can you tell a person what data about them was processed by the system and produce it?
• Rectification. If the system stored an inference about someone that is wrong, is there a route to correct it?
• Automated decision-making. Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects. If a model output drives such a decision without meaningful human involvement, you need an applicable exception plus safeguards including a right to human intervention.

Article 22 is worth reading carefully if any model output feeds a decision about a person. A human who rubber-stamps model output without the authority or information to overturn it does not constitute meaningful human involvement, and regulators have been clear on this point in analogous contexts.

Question 5: what are you logging, and does the log create a new problem?

AI Act high-risk systems require automatic recording of events. Security practice wants prompt and response logs for investigation. Both are legitimate, and both create a data store containing exactly the sensitive material that made the project risky in the first place.

Design this deliberately rather than by default. Options include logging metadata only, logging pseudonymised prompt content with the mapping held separately under tighter control, or logging full content with a short retention period and strict access control. Any of these can be defensible. What is not defensible is discovering that a debug logger has been writing full prompts to a general-purpose log platform accessible to forty engineers.

A pre-build checklist

1. Classify the role: provider or deployer, in writing.
2. Classify the risk tier against the AI Act annexes, and check specifically for the employment and worker management category.
3. Establish the lawful basis and confirm an Article 28 processor agreement with the model provider covering this use.
4. Confirm the processing region and the transfer mechanism, and configure the endpoint accordingly rather than accepting the default.
5. Run a DPIA if any trigger applies. Novel LLM features processing customer data usually trigger at least one.
6. Design the data subject rights path before launch, especially erasure across logs and embedding stores.
7. Decide the logging model explicitly, including retention and access.
8. Apply AI Act transparency measures where relevant: tell people they are interacting with an AI system, and mark synthetic content.

Eight items, and most take under a day each with the right people in the room. The cost of doing them after launch is an order of magnitude higher, because the answer is sometimes that the feature has to change.