A model register that records only the model name, supplier and intended use will not answer the first question a regulator, auditor or DPO is likely to ask: what personal data is processed, at which stage, and under whose instructions? That is the practical answer to does GDPR cover AI models. The GDPR does not regulate AI models as a standalone technology category. It regulates the processing of personal data. Where an AI model is trained on, fine-tuned with, prompted using or produces information relating to identifiable individuals, GDPR obligations may apply.
For compliance teams, this distinction matters. Treating every model as automatically subject to every GDPR obligation creates unnecessary work. Treating the model itself as outside GDPR because it is “only an algorithm” creates a more serious exposure. The correct assessment is lifecycle-based, evidence-led and specific to the use case.
Does GDPR cover AI models directly?
Not directly in the way the EU AI Act regulates defined AI systems and assigns obligations to providers, deployers, importers and distributors. GDPR applies to a controller or processor that processes personal data. An AI model may be part of that processing operation, but it is not automatically the legal object of regulation.
The real question is whether personal data is present or can be derived at any material point in the lifecycle. That includes data collection, training, validation, testing, fine-tuning, retrieval-augmented generation, user prompting, inference, monitoring, incident investigation and model retirement.
A model trained exclusively on properly anonymised data may fall outside GDPR, provided re-identification is not reasonably likely. That threshold is high. Pseudonymised data remains personal data. Removing direct identifiers is not enough where records can be linked back to people through other data, attributes or available means.
The position is equally not resolved by calling information “public”. Personal data collected from public websites, professional profiles, forums or social media remains personal data. Public availability may affect the practical balance of interests under a legitimate interests assessment, but it does not remove the need for a lawful basis, transparency and compliance with the data protection principles.
Where GDPR risk arises across the AI lifecycle
Training and fine-tuning data
Training data is the most obvious point of exposure. If an organisation collects, licences or receives personal data to train or fine-tune a model, it must identify a lawful basis under Article 6. Where special category data is involved, an Article 9 condition is also required. Criminal offence data brings further restrictions under Article 10.
Purpose limitation and data minimisation are often the difficult tests. A dataset collected for customer service, recruitment or fraud prevention cannot simply be repurposed for broad model development because the data is useful. The organisation needs a documented compatibility assessment or a separate lawful basis and transparency route. It must also show why the proposed dataset, fields and retention period are proportionate.
Where data is obtained indirectly, Articles 13 and 14 require particular attention. Providing a privacy notice after data has entered a large training corpus may be operationally difficult, but difficulty is not an exemption. Any reliance on an Article 14 exception needs a defensible assessment, not a generic statement that notification would be inconvenient.
Prompts, context and retrieval
Many organisations focus on foundation-model training while overlooking the data sent at inference. An employee entering a customer complaint into a generative AI tool, or a retrieval system indexing personnel files, is processing personal data even if the underlying model was trained by someone else.
This is where supplier terms alone are insufficient. The organisation needs to establish whether the provider acts as processor, independent controller or joint controller for each relevant activity. It must understand whether prompts are retained, used for service improvement, transferred outside the UK or EEA, or made available to sub-processors. A data processing agreement is valuable only when it reflects the actual operating model.
Outputs and automated decisions
Outputs can themselves be personal data. A model may generate a profile, risk score, recommendation, summary or inferred attribute about an individual. It may also reproduce personal data from its training or retrieval sources. Both situations require governance.
Article 22 becomes relevant where solely automated processing produces a decision with legal or similarly significant effects, such as decisions about recruitment, credit, insurance, benefits or access to services. Human review must be meaningful, not a nominal click-through. The reviewer needs authority, competence, sufficient context and a real ability to challenge the recommendation.
Even where Article 22 does not apply, fairness, accuracy, transparency and accountability still do. A low-confidence output used to prioritise a customer service queue presents a different risk from a model that rejects job candidates, but neither should be deployed without defined controls and ownership.
The model weights question: not a safe harbour
Whether trained model parameters or weights constitute personal data depends on the facts. If a person can be identified from the model or if the model can be used, with reasonably available means, to reveal information relating to an identifiable person, GDPR risk remains. Memorisation, model inversion and membership-inference attacks make this more than a theoretical issue for some models.
There is no reliable compliance shortcut in saying that personal data has been transformed into weights. Organisations should assess the nature of the training data, the model architecture, the likelihood of memorisation, the capacity to extract training examples, intended access arrangements and available attack techniques. The assessment should be proportionate to the model and deployment context, but it should exist.
This also affects data subject rights. Access, rectification and erasure requests do not always require rebuilding a model. Equally, an organisation cannot reject a request by asserting that deletion is technically difficult without examining whether the data can be removed from source systems, retrieval stores, fine-tuning datasets, logs or future training cycles. It needs a documented, technically informed response process.
GDPR duties that need operational evidence
For most AI deployments involving personal data, the core GDPR obligations are familiar. The failure is usually evidential: obligations sit in privacy documentation, model documentation, vendor folders and security tickets with no usable connection between them.
A defensible governance record should connect the AI use case to its controller and business owner, purpose, affected data subjects, data categories, lawful basis, special category assessment, recipients, retention rules, international transfers, security measures and data subject rights process. It should also identify the model, version, provider, training or fine-tuning status, deployment environment and downstream systems.
Article 25 requires data protection by design and by default. In AI terms, that means choosing data-minimising architectures, restricting prompts, applying role-based access, filtering sensitive inputs where appropriate, setting retention limits for logs, testing for data leakage and preventing unauthorised secondary use. These decisions should be made before deployment, not reconstructed after an incident.
Article 30 records of processing must be kept current. Article 32 requires security appropriate to risk. If processing is likely to result in high risk to individuals, Article 35 requires a data protection impact assessment. AI use cases involving vulnerable people, large-scale profiling, sensitive data, systematic monitoring or consequential decisions will frequently meet that threshold.
A DPIA should not be a one-off approval document. Material changes in model provider, data source, intended purpose, decision logic, scale, geography or affected population should trigger review. The same change discipline is needed for AI Act classification and ISO/IEC 42001 controls, although the frameworks answer different questions.
GDPR and the EU AI Act are complementary, not interchangeable
The EU AI Act does not displace GDPR. A system can meet parts of the AI Act’s documentation or risk-management requirements and still lack a lawful basis for its training data. It can also have a well-developed DPIA while failing AI Act obligations on risk classification, technical documentation, logging, human oversight or provider and deployer duties.
For organisations operating in the UK and EU, separate frameworks should be managed through one controlled evidence base. Maintain distinct legal assessments, but avoid duplicating the inventory, ownership, change history and control evidence. A single AI system record should show both its data protection position and its AI governance status, with clear links to the relevant assessments, approvals and monitoring results.
This is the practical value of a system of record such as Endaxi AIG: it replaces fragmented spreadsheets and static policy folders with traceable ownership, lifecycle controls and audit-ready evidence across GDPR-sensitive processing, the EU AI Act and ISO/IEC 42001.
A proportionate decision process for each model
Start by registering the use case rather than the technology in isolation. A general-purpose model may be used for harmless drafting in one workflow and for customer profiling in another. Those are different processing contexts and should not share a single blanket approval.
Then establish the data flow: what enters the model, what supporting data is retrieved, what is retained, who receives the output and where processing occurs. Assess the controller-processor roles, lawful basis, special category data, international transfers and whether a DPIA is required. Finally, define controls for testing, human oversight, output use, security, monitoring and change management.
The objective is not to prove that AI is risk-free. It is to show that the organisation understands where personal data is processed, has made proportionate decisions before deployment, and can produce evidence when challenged. Start with the AI systems already handling customer, employee or prospect data. They are the records most likely to expose the gap between an AI policy and operational control.