GDPR AI DPIA: When Article 35 Requires an Assessment

A GDPR AI DPIA starts with a processing operation: a defined purpose, categories of personal data, affected people, recipients, retention periods, and technical flow. The presence of an LLM alone settles none of those questions. Under GDPR Article 35, the controller must assess processing before it begins when its nature, scope, context, and purposes make a high risk to natural persons' rights and freedoms likely.

That threshold depends on the processing context. A public chatbot answering questions from a product manual presents a different case than a recruitment assistant ranking applicants, even if both call the same model endpoint. I think blanket claims that every enterprise LLM needs a DPIA make privacy work weaker. They replace the statutory test with a label and leave the actual data flow unexamined.

This guide applies Article 35, the Article 29 Working Party's WP248 rev.01 DPIA guidelines, and the European Data Protection Board's Opinion 28/2024 on AI models. It also separates the person sending an AI request from the person described inside it, a distinction that becomes visible as soon as a support agent pastes a customer's account history into a prompt.

Article 35 sets a likely-high-risk threshold

Article 35(1) makes the controller responsible for the threshold decision. The assessment concerns a type of processing, particularly one using new technologies, that is likely to result in high risk after considering its nature, scope, context, and purposes. Similar processing operations with similar high risks may share one DPIA, but the document still needs enough specificity to describe the operations it covers.

Article 35(3) identifies three situations that require a DPIA:

• systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal effects or similarly significant effects;
• large-scale processing of Article 9 special-category data or Article 10 data about criminal convictions and offences; and
• systematic monitoring of a publicly accessible area on a large scale.

An AI hiring system that ranks candidates for rejection may meet the first case. A clinical summarization service operating across a hospital group may raise the second. A computer-vision system monitoring a railway station may raise the third. Each conclusion depends on the processing design rather than the marketing category attached to the software.

Article 35(4) also requires each supervisory authority to publish a list of processing operations subject to a DPIA. Those lists vary by jurisdiction. The Irish Data Protection Commission's DPIA page, for example, directs controllers to its national list and stresses that the controller remains responsible for assessing risk. A team operating in several EU Member States should identify the competent authority and inspect the relevant list instead of copying a use-case list from a vendor slide.

If the controller concludes that a DPIA is unnecessary, WP248 recommends documenting the reasons. Put the dated decision, processing description, criteria considered, DPO advice, and review trigger in the governance record. A one-line spreadsheet entry reading “low risk” will look painfully thin six months later.

WP248 rev.01 provides nine screening criteria

WP248 rev.01 gives nine criteria for identifying processing likely to result in high risk. The guidelines say that, in most cases, a processing operation meeting two criteria should trigger a DPIA. That is a rule of thumb. One criterion may be enough in a particular case, and a controller may conclude that an operation meeting two criteria is unlikely to create high risk if it can justify that conclusion.

The nine criteria translate into concrete AI questions:

• Evaluation or scoring. Does the system infer, predict, score, rank, or categorize a person's work performance, health, preferences, reliability, behaviour, location, or movements?
• Automated decisions with legal or similarly significant effects. Does an output determine or materially shape access to employment, credit, insurance, housing, education, healthcare, or another consequential service? The related automated-decision rules deserve a separate GDPR Article 22 analysis.
• Systematic monitoring. Does the deployment observe, track, or control people in a way they may struggle to avoid or understand?
• Sensitive or highly personal data. Will prompts, retrieved context, outputs, or logs contain Article 9 data, Article 10 data, financial information, private communications, or similarly intimate material?
• Large-scale processing. Consider the number and proportion of data subjects, the volume and range of data, processing duration, and geographical extent. GDPR provides no universal customer-count cutoff.
• Matching or combining datasets. Does retrieval or enrichment join records collected for different purposes or by different controllers in a way people would not reasonably expect?
• Data concerning vulnerable people. Are children, employees, patients, asylum seekers, older people, or others affected by a power imbalance or reduced ability to object?
• Innovative use or application of technological or organisational solutions. Does technical novelty create uncertain consequences, such as inferring new personal attributes through an AI model?
• Preventing exercise of a right or access to a service or contract. Can the operation exclude a person, block a benefit, or determine access to a contract?

Picture the assessment workshop with a single architecture diagram on the wall. The recruitment team has drawn the applicant tracking system, retrieval store, model API, reviewer screen, and rejection email. That drawing often resolves the threshold faster than a forty-question template because it exposes dataset matching, significant effects, retention, and human review in one view.

The DPIA record follows Article 35(7)

Article 35(7) gives the minimum content. A DPIA must describe the envisaged processing operations and purposes, including any legitimate interest pursued by the controller. It must assess necessity and proportionality, evaluate risks to data subjects' rights and freedoms, and identify measures planned to address those risks and demonstrate compliance.

For an AI deployment, the processing description should identify the application, model and provider, input sources, retrieval stores, output recipients, human-review points, storage locations, retention rules, and downstream actions. It should also record the legal basis, the purpose attached to each data flow, and any international transfer mechanism. The broader governance context belongs in the organization's GDPR and AI control model.

Necessity asks how the processing contributes to the stated purpose and which less intrusive designs were considered. Proportionality tests data minimisation, accuracy, transparency, retention, access controls, rights handling, and safeguards around automated decisions. A faster workflow may be a business benefit; the DPIA still needs a defensible account of the personal data required for that workflow.

The risk section should follow the effect on people. Plausible harms include an applicant losing an opportunity because of an inaccurate inference, a patient record reaching an unintended provider endpoint, an employee being unable to contest a score, or a customer having sensitive details retained beyond the stated period. Probability and severity need evidence, assumptions, and an owner. A coloured cell with no rationale hides the decision instead of recording it.

Measures should map back to those risks. Examples include excluding fields before an HTTP request leaves the application, restricting approved model routes by role and purpose, requiring human review before a consequential action, setting provider retention controls, testing output accuracy for the intended population, and creating a rights-request workflow around stable data-subject references. AI data governance supplies the ownership and data-handling layer around those controls.

Article 35 also includes process duties that thin templates miss. The controller must seek the DPO's advice where a DPO is designated. Article 35(9) calls for the views of data subjects or their representatives where appropriate, while allowing the controller to account for commercial interests, public interests, or processing security. The assessment must happen before processing, while design choices can still change.

AI model status requires case-specific evidence

EDPB Opinion 28/2024 addresses three questions about AI models: when a model may be considered anonymous, the use of legitimate interests in development or deployment, and the consequences when a model was developed using unlawfully processed personal data. It provides an AI-specific evidence source, but it is not a standalone DPIA methodology.

The opinion rejects an automatic assumption that a model trained with personal data is anonymous. Supervisory authorities should assess the likelihood of extracting personal data directly or indirectly, including through queries, and the likelihood of obtaining personal data from the model. The assessment is case-specific and should consider the controller's measures.

For a DPIA, that means recording evidence behind claims about the model. Relevant material can include dataset provenance, selection and filtering methods, attacks considered, testing results, model access restrictions, output filters, provider terms, DPO input, and a DPIA or reasoned no-DPIA decision. A procurement questionnaire stating “training data removed” gives the review team a claim. It gives them no test result.

Role allocation needs the same discipline. The application operator may act as controller for one operation and processor for another. A model provider may process solely on documented instructions, or it may determine an independent purpose for some data use. The contract and the real processing both matter. Under GDPR Article 28, a processor must assist the controller with Articles 35 and 36 obligations where applicable, taking account of the nature of processing and information available to the processor.

Article 27 FRIA coordination has a narrower scope

The EU AI Act's Article 27 Fundamental Rights Impact Assessment applies to specified deployers before they use certain high-risk AI systems. Its scope includes bodies governed by public law, private entities providing public services, and deployers of particular Annex III systems used for creditworthiness assessment or credit scoring and risk assessment or pricing in life and health insurance. The creditworthiness branch excludes systems used to detect financial fraud.

That scope is narrower than “every private company deploying high-risk AI.” It also differs from Article 35 because the GDPR test starts with personal-data processing likely to create high risk. A team should assess each trigger independently.

Article 27(4) says the FRIA shall complement a DPIA where the deployer already meets some Article 27 obligations through that DPIA. This supports coordinated work and reuse of evidence. It stops short of requiring one combined document. Article 27 asks for elements including the deployer's processes, period and frequency of use, affected categories of people, specific risks of harm, human-oversight measures, and measures for materialized risks. The DPIA can cover overlapping material while the FRIA record addresses the remaining AI Act elements.

Keep three identities separate in that work. The requester authenticates to the AI application or gateway. The data subject is the natural person whose personal data appears in the processing. An affected person under the AI Act may experience an impact even when the request contains someone else's data. In a claims workflow, an employee may send the request, a policyholder may be the data subject, and a dependent may also be affected by the output.

Article 35 review depends on operational change

Article 35(11) requires the controller to review the DPIA where necessary, at least when the risk represented by processing operations changes. A model replacement, new retrieval source, additional user population, changed purpose, longer retention period, provider-region change, bypass route, or incident can all justify review. The trigger is the changed risk, so a fixed annual review alone may miss the event that matters.

The operating record should connect approved design to observed processing. Useful evidence can include model-route inventories, configuration histories, access reviews, sampled requests, policy decisions, incident records, rights-request outcomes, provider notices, and test results. Tamper-evident AI audit logs can strengthen the integrity of runtime evidence, provided the deployment implements that storage property.

Runtime logs remain one evidence source. They cannot establish training-data lawfulness, prove that provider-side retention matches the contract, cover offline processing, or show what happened on traffic that bypassed the collection point. A DPIA review should reconcile those gaps explicitly.

DeepInspect

DeepInspect sits on routed HTTP traffic between authenticated users or agents and LLM endpoints. At that boundary, it can apply identity-aware policy to an outbound AI request and create a decision record for traffic that actually crosses the gateway. Those records can support DPIA monitoring by showing the authenticated requester, model route, request time, applicable policy decision, and other configured event fields.

The requester field should never be treated as a data-subject index by default. A lawyer asking an LLM to summarize a complaint is the requester; the complainant and witnesses described in the text are data subjects. Rights retrieval needs a stable reference to those people plus search, export, rectification, restriction, and erasure procedures outside the gateway. Article 17 erasure also remains subject to its statutory conditions and exceptions.

DeepInspect covers a bounded enforcement point. Provider training practices, controller and processor allocation, offline datasets, local model calls, direct routes around the proxy, necessity analysis, data-subject consultation, and the complete DPIA or FRIA remain with the organization's legal, privacy, security, and engineering controls. I would rather draw that boundary in thick black ink than sell a compliance claim the evidence cannot carry.

If your team needs request-level evidence for the routed, authenticated HTTP portion of an AI DPIA, let's talk today.