If your AI product processes personal data about people in the EU, GDPR is not a slide you add near the end of a build, it is a requirement that shapes the architecture from the start. This is a plain-language walk through what GDPR actually requires, why it exists, and specifically what changes when the thing processing personal data is an AI agent or an LLM-based product rather than a traditional application.
What GDPR actually is
GDPR is the General Data Protection Regulation, the EU-wide law governing how personal data can be collected, used, and shared. It applies across every EU member state and is enforced by each country's own national Data Protection Authority (DPA), with the European Data Protection Board (EDPB) working to keep enforcement and guidance consistent across all of them.
A few concepts sit at the center of GDPR and matter for every AI product:
- Data controller. The organization that decides why and how personal data is processed. If you run an AI product that collects user data, you are typically the controller.
- Data processor. A person or company that processes personal data on the controller's behalf, following the controller's instructions rather than deciding independently. This is exactly the role an AI vendor or LLM API provider plays the moment EU personal data passes through their systems.
- Lawful basis for processing. Every use of personal data needs a legal justification: consent, contract necessity, legitimate interest, legal obligation, or one of a few others. There is no default "we're allowed because we're a business" basis.
- Data minimization and purpose limitation. Collect only what is needed for a stated purpose, and do not quietly reuse it for something else.
- Individual rights. GDPR gives people the right to access what is held about them, correct it, request erasure (the "right to be forgotten"), receive a portable copy of their data, and object to certain kinds of processing.
- Data protection by design and by default. Privacy has to be built into a system from the start, not bolted on afterward as a policy document that the system itself does not actually enforce.
Why GDPR exists
Before GDPR, data protection rules across Europe were fragmented, and individuals had limited, inconsistent power over what companies did with their personal information. Data could be collected, combined, sold, and repurposed with little transparency and no reliable way for a person to find out or object. GDPR exists to address that specific harm: personal data, once out of a person's control, can be used to profile, discriminate against, or otherwise disadvantage them in ways they cannot see or contest. The rights it grants (access, correction, erasure, objection) exist to put some of that control back.
Why a company follows it
National DPAs can investigate complaints and take enforcement action, so there is real legal exposure to mishandling personal data. GDPR fines can be significant, though the exact amount depends heavily on the specifics of a case, so this piece will not cite a number without verifying it against a specific enforcement action. Beyond legal exposure, the more immediate concern for most companies is trust: an EU buyer, especially in a regulated sector, will ask directly how personal data flows through an AI feature, whether a data processing agreement exists with every vendor that touches that data, and what happens when a user asks to see or delete their information. A weak answer to that question is often the end of the sales conversation.
What specifically needs attention when building AI products under GDPR
The data processing agreement with your AI vendor: GDPR's version of a BAA
If you have read our HIPAA explainer, this concept will feel familiar. HIPAA requires a business associate agreement (a BAA) before protected health information reaches a vendor acting as a business associate. GDPR has a direct parallel: a Data Processing Agreement (DPA), a contract required between a controller and any processor before personal data is shared with that processor. An AI vendor or LLM API provider that receives EU personal data as part of your product is, in GDPR terms, acting as a processor (or a sub-processor of one), and a DPA needs to be in place with that provider before personal data reaches its systems, not after. Not every model API provider offers a DPA on every plan tier, and this has to be checked directly and confirmed in writing, the same discipline HIPAA requires for a BAA.
Personal data inside a prompt sent to a third-party model
The moment a prompt to an LLM API includes a person's name, email, order history, or any other identifying detail, that prompt is personal data under GDPR, whether or not it is stored anywhere afterward. Consider a small SaaS company building an AI support agent: if that agent's prompt to the model includes a customer's full account history to give better answers, that data transfer has to be covered by a lawful basis and, if the model provider is a separate processor, by a DPA, the same as any other data flow in the product.
Training data and fine-tuning data
If personal data ends up in a dataset used to fine-tune a model, or if a third-party model provider's terms allow using submitted data to improve their own models, that is a separate processing activity that needs its own lawful basis and its own disclosure to the people whose data it is. This is one of the areas most likely to be overlooked, because it happens once during setup rather than on every request, but it is still processing personal data and still falls under GDPR.
Retention and logging of conversations that contain personal data
Application logs, LLM request and response logs, and any analytics or debugging tool that captures user input are all places personal data quietly accumulates if nobody designs against it. GDPR's storage limitation principle means these logs need a defined retention period, not indefinite storage by default, and a plan for what happens to them when a user exercises their right to erasure.
Data protection by design applied to how an agent is architected
For an AI agent specifically, data protection by design is not primarily about a privacy policy, it is about what the agent is actually allowed to retrieve, log, and retain. An agent that answers a customer's billing question should be scoped to retrieve only that customer's relevant billing data, not given standing access to the full customer database on the assumption that the prompt will keep it well-behaved. Building this scoping into the system's access controls, rather than relying on instructions in the prompt, is what makes data protection by design a real architectural property instead of an aspiration.
What GreyScript AI does, and does not, do here
GreyScript AI builds AI systems designed to align with GDPR: scoping what an agent can retrieve and log, keeping personal data out of logging paths that were not built for it, and structuring the system so a Data Processing Agreement with the relevant vendors is a real, checkable thing rather than an assumption. We do not certify compliance, and we do not give a legal opinion. Where a formal compliance determination or a Data Processing Agreement needs to be signed, that stays yours to commission, typically through counsel and the vendors in question directly. See our AI governance and security service for how this fits into a build.
If your product is also built for the United Kingdom, our UK GDPR explainer covers how that closely related but separately enforced regulation differs, including a significant 2026 change to its automated decision-making rules. If the system in question also falls under the EU's separate AI-specific regulation, our EU AI Act explainer covers that framework and how it applies alongside GDPR.