Using AI with personal data requires the same disciplined questions as other data processing: what is the purpose, what is the lawful basis, who receives the data and how are people’s rights protected? AI adds practical complications, including uncertain outputs, data sent to external services and the reuse of information across a model’s lifecycle.
The GDPR was adopted in 2016 and has applied since 2018. This article explains issues to assess when planning an AI workflow. It is not a determination that a particular product or deployment complies with the law. Use the GDPR text and involve the organisation’s data protection lead or legal adviser where needed.
Start with the purpose and the data
Describe the task before choosing a model. Drafting a public marketing text, summarising employee records and deciding whether to offer a loan create different risks and obligations.
Inventory the information used in prompts, uploaded files, retrieved documents, outputs and logs. Personal data can appear in any of these. Removing names may not anonymise a record if its contents still allow a person to be identified.
Pseudonymised data remain personal data when they can be linked back to a person. Effective anonymisation requires a separate assessment of identification risk. Voice or video recordings are not automatically special-category biometric data; the purpose and method of processing, including use for unique identification, matter.
Limit data to what the task needs. If a question can be answered using a policy excerpt, sending an entire personnel file creates avoidable exposure.
Identify the lawful basis and responsibilities
Processing needs an appropriate basis under Article 6. Where special-category data are involved, an applicable Article 9 condition is also needed. Consent is one possible basis or condition, rather than a universal solution.
In employment settings, an imbalance of power can make freely given consent difficult. Legitimate interests also require assessment; they are not an automatic substitute. The purpose, data, consequences and available alternatives determine the analysis.
Clarify which organisations act as controllers or processors for each activity. A provider may have different roles for different processing purposes. Where a processor relationship applies, an Article 28 agreement is part of the required arrangements. Read the actual service terms and instructions rather than relying on a product’s marketing label.
Assess the provider and deployment
A provider cannot be evaluated from its brand name alone. Consumer, business and API services may have different terms, configurations and data flows, and those can change.
Review:
- Whether submitted data may be used for model training or other purposes.
- Retention periods for prompts, files, outputs and operational logs.
- Access by the provider, subprocessors and support staff.
- Hosting locations and any international transfers.
- Available deletion, access control and audit features.
- Incident procedures and the evidence needed for your own accountability.
The GDPR does not impose a general EU-only hosting rule. Transfers outside the EEA require assessment under the applicable transfer framework and circumstances. A provider’s US ownership does not, on its own, resolve every question about a particular data flow.
Running an application on your own server also does not prove that data stay there. External model APIs, telemetry, email services and backups may still receive information. Map the complete architecture.
Handle automated decisions and human review
Article 22 addresses decisions based solely on automated processing that produce legal or similarly significant effects, subject to its conditions and exceptions. This is different from saying that every AI recommendation is prohibited or that adding an approval button resolves the issue.
Human review must be meaningful: the reviewer needs relevant information, authority and time to challenge the output. A rubber-stamp process may not provide the safeguard its name suggests.
For recruitment, credit or other consequential uses, assess the intended purpose and effect on people before deploying the system. Record who remains responsible, how errors can be challenged and how the workflow is monitored.
Decide whether a DPIA is needed
A data protection impact assessment is required where the processing is likely to result in a high risk to people’s rights and freedoms, with specific cases identified in the GDPR and relevant supervisory guidance.
Assess scale, sensitivity, systematic evaluation, vulnerable people and the consequences of errors. Neither “it uses AI” nor “a human reviews it” is a sufficient conclusion. If a DPIA is needed, complete it before the relevant processing begins and use it to change the design where risks require it.
Design access, retention and incident handling
Apply access restrictions to retrieved documents as well as to the chat interface. A retrieval system that ignores source permissions can expose information even when its answers sound plausible. See RAG for business for the data and evaluation questions involved.
Set retention periods by purpose and applicable obligations. There is no universal period that makes every AI chat log appropriate to keep. Avoid storing secrets or sensitive personal details in debugging logs by default.
Prepare a process for investigating security incidents. Where notification to the supervisory authority is required, the GDPR sets a 72-hour timeframe from awareness where feasible. Not every technical incident or personal data breach triggers the same notification duties: risk, circumstances and the rules for notifying affected people must be assessed.
Consider the AI Act separately
The EU AI Act entered into force in August 2024, with obligations applying in phases. GDPR compliance does not settle AI Act obligations, and the reverse is also true.
Classification depends on the system’s intended purpose, use and the organisation’s role. Human review does not automatically remove a system from a high-risk category. Transparency requirements also need assessment for the actual use, including certain interactions with AI and generated content.
Avoid treating a vendor’s brand or a general claim of “human oversight” as a legal classification. Check the current rules that apply to the particular system and its lifecycle.
Put the assessment into the project
Before implementation, agree the allowed data, provider configuration, permissions, acceptance tests and responsibilities for ongoing operation. Include privacy requirements in the design rather than leaving them to a final document review.
Q-Journey can assess an organisation’s processes and continue into individual software delivery. Q-Dev can implement an agreed technical scope. Privacy and legal decisions remain part of the organisation’s governance, supported by its responsible advisers. Discuss the workflow with QA10.
FAQ
Is an AI service GDPR-compliant because it has a business plan?
A plan name does not establish compliance for a particular use. Review the processing purpose, roles, contract, configuration, retention, access and transfers, then assess how the service fits the organisation’s obligations.
Do personal data have to stay in the EU?
The GDPR does not require EU-only hosting in every case. International transfers require assessment under the applicable transfer rules and circumstances. Hosting location is one part of that assessment.
Does anonymising names remove GDPR obligations?
Not necessarily. Other details may still identify a person, and pseudonymised data remain personal data when they can be linked back to someone. Effective anonymisation requires an assessment of the remaining identification risk.
Does human review make an AI system low-risk?
No. Meaningful review can be an important safeguard, but it does not automatically remove GDPR obligations or an AI Act high-risk classification. The intended use, impact and applicable legal criteria still matter.
Must every AI-related incident be reported within 72 hours?
No. Investigate whether a personal data breach occurred and whether notification is required under the applicable risk criteria. Where supervisory-authority notification is required, the GDPR provides a 72-hour timeframe from awareness where feasible.