What Counts as PII Under GDPR
GDPR uses the term personal data rather than PII, and defines it broadly as any information relating to an identified or identifiable natural person. The practical scope is wider than most founders expect. Names, email addresses, phone numbers, and national insurance numbers are obvious examples. So are IP addresses, cookie identifiers, device fingerprints, and advertising IDs - these are routinely collected by analytics tools and are personal data under GDPR. Health information, biometric data, genetic data, data revealing religious beliefs, political opinions, racial or ethnic origin, sexual orientation, and trade union membership are special categories of personal data under Article 9, carrying stricter processing requirements. For AI products, the critical area is inference: if your model can infer a protected characteristic from other data points - inferring likely health conditions from purchase history, for example - you may be processing special category data even if you never explicitly collected it.
Where PII Enters AI Systems
The entry points for PII in AI products are more numerous than in traditional software. User-generated prompts often contain personal information, sometimes deliberately and sometimes incidentally. A user asking your AI to help draft a redundancy letter might paste in employee names, salaries, and performance records. A customer using your AI-powered support tool might include order numbers that link to personal accounts. If those prompts are logged for evaluation or fine-tuning purposes, you now have a PII retention problem. Training and fine-tuning datasets frequently contain personal information scraped from the web or pulled from internal systems. Embeddings generated from documents that contain personal data may preserve identifying information in vector form. Retrieval-Augmented Generation pipelines that index customer data or internal knowledge bases create a vector store that is, in legal terms, a personal data repository requiring GDPR-compliant data retention policies.
Lawful Basis for Processing PII
Under GDPR and UK GDPR, you cannot process personal data without a lawful basis. For AI products, the most common applicable bases are contract performance (you process data because it is necessary to deliver the service the user signed up for), legitimate interests (you process data for a purpose a reasonable person would expect and the interest is not overridden by the individual's rights), and consent (the individual has given clear, specific, and informed agreement). Consent is often the default assumption of founders, but it is also the most demanding to implement correctly: it must be freely given, specific, informed, unambiguous, and withdrawable. For analytics, LLM prompt logging, and model improvement purposes, you will typically need either explicit consent or a carefully documented legitimate interests assessment. Using special category data requires explicit consent or one of the narrower Article 9 exceptions.
PII Minimisation in Practice
The GDPR data minimisation principle requires collecting only what is necessary for the specified purpose. For AI products, this translates into a set of concrete design decisions. Do not log full prompt text if a hash or summary is sufficient for your evaluation purpose. Strip or pseudonymise PII from prompts before they are passed to third-party LLM APIs where possible. Implement prompt pre-processing that detects and redacts obvious PII patterns such as email formats, phone number patterns, and national insurance number formats before the data leaves your infrastructure. Define and enforce retention periods for all personal data, including prompt logs, conversation histories, and user-uploaded documents used in RAG systems. At SpeedMVPs, data minimisation architecture decisions are made during the discovery and scoping phase, not retrofitted after a compliance audit.
Data Subject Rights in AI Systems
GDPR gives individuals rights over their personal data that your AI product must technically support. The right of access means any user can request all personal data you hold about them. The right to erasure means they can ask for their data to be deleted. The right to rectification means incorrect data must be corrected. The right to restriction means processing can be paused while a dispute is resolved. The hard implementation challenge in AI is erasure. Deleting a user from your PostgreSQL database is straightforward. Removing their contributions from a fine-tuned model is not - it may require retraining. Removing documents they uploaded from a vector store is achievable if you have indexed them with user-level metadata. These are engineering problems with engineering solutions, but they must be considered during architecture design, not after a subject access request arrives.
Third-Party LLM APIs and PII Risk
When you send user data to a third-party LLM API such as OpenAI, Anthropic, or Google, you are engaging a data processor under GDPR. You must have a Data Processing Agreement in place with that provider. Most major LLM providers have DPAs available and do not use API-submitted data for training by default, but you should verify this in the current version of their documentation rather than assuming. You must disclose in your privacy notice that personal data may be processed by AI service providers. You must ensure the data transfer is lawful, which for EU personal data sent to a US provider requires Standard Contractual Clauses or equivalent safeguards. UK data transfers have separate adequacy rules under UK GDPR, which currently allow data flows to EEA countries as adequate. The ICO provides guidance on international data transfers that should be the starting point for UK-based teams.