Do You Need a DPIA for LLM Inference? A Deployer's Guide

AI This article was created with the help of AI.

Get the Instrument Right: GDPR Article 35 vs. AI Act

Before routing production traffic to an inference endpoint, engineering and product teams face a recurring governance question: does sending prompts to a large language model require a Data Protection Impact Assessment (DPIA)? To answer this accurately, you must first separate the underlying legal frameworks. A DPIA is exclusively a General Data Protection Regulation (GDPR) instrument governed by Article 35. It is triggered by the nature, scope, context, and purposes of personal data processing, not by the mere presence of machine learning in your software stack.

The EU Artificial Intelligence Act does not create a new DPIA obligation. Instead, the AI Act establishes its own distinct governance framework while explicitly cross-referencing existing data protection rules. Under Article 26(9) of Regulation (EU) 2024/1689, deployers of high-risk AI systems must use the information provided under Article 13 to comply with their obligation to carry out a data protection impact assessment under Article 35 of the GDPR, where applicable. The AI Act does not invent a standalone AI DPIA; it provides an upstream information conduit to support the GDPR assessment you already owe.

Understanding the enforcement timeline prevents costly regulatory confusion. While transparency obligations under Article 50 and the European Commission's enforcement powers over general-purpose AI model providers under Article 101 began applying in August 2026, the high-risk deployer obligations in Article 26 do not bind immediately. Under Regulation (EU) 2026/1744, high-risk deployer rules apply from 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for Annex I product-embedded systems. By contrast, the GDPR has applied across the European Union since 25 May 2018, so Article 35 is a live obligation. If your LLM integration processes personal data in a high-risk manner, your DPIA duty is active today.

• GDPR Article 35: Live legal obligation since May 2018, triggered whenever processing personal data is likely to result in high risk to individual rights.
• AI Act Article 26(9): High-risk deployer cross-reference requiring suppliers to supply documentation for DPIAs, applying from December 2027 for Annex III deployments.
• Technological Neutrality: Calling an LLM API does not automatically trigger Article 35; the assessment depends entirely on the data payload, processing purpose, and systemic impact.
• Regime Interplay: Learn how both regulatory frameworks intersect across the complete model lifecycle in our guide on the GDPR and EU AI Act overlap.

The Ten-Minute DPIA Screening Test

To determine whether your specific LLM inference architecture requires a full DPIA, you can execute a straightforward three-tier screening test based on primary statutory criteria and regulatory guidance. You do not need to assume every artificial intelligence feature requires an exhaustive 50-page impact assessment. The threshold is defined by risk to the rights and freedoms of natural persons, evaluated through structured triggers.

First, inspect the mandatory statutory triggers in GDPR Article 35(3). A DPIA is legally mandatory if your processing involves: (a) systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; (b) processing on a large scale of special categories of data (health, biometric, religious, political, or sexual orientation data under Article 9) or criminal conviction data under Article 10; or (c) systematic monitoring of a publicly accessible area on a large scale. If your LLM workflow generates automated credit decisions, triages health records, or profiles job applicants, a DPIA is legally required under Article 35(3)(a) or (b).

Second, check the Article 35(4) mandatory lists (the 'blacklists') published by your relevant national supervisory authority (such as the BfDI in Germany, CNIL in France, or AEPD in Spain). Article 35(4) requires each supervisory authority to establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment, and to communicate those lists to the European Data Protection Board. Third, apply the risk criteria set out in the Article 29 Working Party guidelines WP248 rev.01, which the European Data Protection Board formally endorsed. As a general rule of thumb, processing that meets two or more of those criteria should be treated as likely high risk and assessed.

1. Evaluation or scoring: Profiling employees, behavioral prediction, or automated candidate screening.
2. Automated decision-making with legal or similar significant effect: Exclusion from services or automated contract termination.
3. Systematic monitoring: Tracking user behavior across web applications or monitoring worker telemetry.
4. Sensitive data or data of a highly personal nature: Health records, financial information, or special categories under Article 9.
5. Data processed on a large scale: High volume of data subjects, large geographic scope, or extensive temporal duration.
6. Matching or combining datasets: Merging CRM databases with external conversational scraping.
7. Vulnerable data subjects: Processing data concerning children, patients, or subordinate employees.
8. Innovative use or applying new technological solutions: Deploying generative LLM architectures and novel RAG pipelines.
9. Denial of a right, service, or contract: Processing that directly impedes individuals from accessing a fundamental service.

Equally important is identifying when a DPIA is not required. If an engineering team deploys an internal coding assistant or a documentation drafting tool where no personal data enters the prompt and no automated decisions affecting individuals emerge from the completion, an Article 35 DPIA is not required. Similarly, using an LLM to summarise publicly available technical documentation, run synthetic data generation, or perform automated SQL syntax linting involves zero processing of personal data. Treating every trivial API invocation as high-risk governance waste dilutes engineering focus away from genuine high-risk systems.

Separating the DPIA from the AI Act FRIA

A frequent point of confusion among deployers is the relationship between the GDPR DPIA and the Fundamental Rights Impact Assessment (FRIA) established in Article 27 of the AI Act. These are distinct regulatory instruments with different scopes, triggers, and enforcement schedules. A FRIA evaluates broad fundamental rights impacts (including human dignity, freedom of expression, non-discrimination, and environmental sustainability), whereas a DPIA focuses specifically on the fundamental right to data protection and privacy.

The FRIA obligation applies only to a strictly defined, narrow subset of deployers of high-risk AI systems listed in Annex III of Regulation (EU) 2024/1689. Article 27(1) binds deployers that are bodies governed by public law, deployers that are private entities providing public services, and deployers of the high-risk systems referred to in points 5(b) and (c) of Annex III, namely creditworthiness assessment and risk assessment and pricing in life and health insurance. If your organisation is a standard commercial software company deploying an LLM for customer support automation, enterprise document analysis, or internal code generation, you fall outside the scope of Article 27.

Furthermore, the AI Act explicitly coordinates the two assessments. Under Article 27(4), where any obligation under the FRIA is already fulfilled through the execution of a GDPR Article 35 DPIA, the FRIA complements the DPIA rather than duplicating it. You run the DPIA first as the foundational data protection baseline, and add the broader fundamental rights layers only if you fall within the narrow Article 27 deployer criteria. Crucially, because Article 27 sits within the deferred high-risk deployer package, it does not bite until 2 December 2027. No deployer owes a FRIA instead of a DPIA, and the overwhelming majority of commercial LLM deployers will never owe a FRIA at all.

Understanding these boundary conditions ensures that your team prepares the necessary documentation without inventing nonexistent compliance obligations. For organizations that do operate high-risk systems, technical preparation begins with understanding the infrastructure layer for conformity assessments well ahead of the 2027 enforcement milestones.

Mapping the Inference Layer to Your DPIA

When a DPIA is required for an LLM-enabled application, the inference provider forms a critical section of your assessment, but never the entirety of it. GDPR Article 35(7) says the assessment shall contain at least: a systematic description of the envisaged processing operations and the purposes of the processing; an assessment of the necessity and proportionality of the processing operations in relation to the purposes; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the Regulation.

The deployer (acting as the data controller) owns the arguments for necessity and proportionality. An inference provider cannot determine whether using an 80-billion-parameter language model is proportionate for your internal customer intake workflow. However, the inference provider must furnish the technical evidence needed to populate the systematic description, risk assessment, and technical safeguards. This evidence must be recorded accurately in your DPIA evidence register, clearly separating audited technical controls from vendor assertions.

At Lyceum, we operate serverless inference with a clear, self-asserted policy of zero data retention: customer prompts and model completions reside in volatile GPU memory only for the duration of the request execution and are never written to persistent disk storage or used for model retraining. However, in your DPIA risk register, this must be classified factually as a vendor self-assertion rather than an independently audited SOC 2 Type II or ISO 42001 certification. GDPR compliance is a legal status rather than an issued certificate, and treating self-asserted technical controls with proper transparency is essential for audit integrity.

The Challenge of Recipients, Access, and Transfers

Two specific rows in your Article 35 DPIA demand meticulous verification when integrating third-party inference APIs: the identification of data recipients and the analysis of international data transfers under GDPR Chapter V. Deployers frequently rely on broad marketing claims regarding European hosting, only to encounter fatal deficiencies during supervisory audits.

First, you must establish the exact legal entity acting as the data processor under Article 28, and verify from which jurisdictions administrative and technical support access can occur. If an inference vendor hosts physical servers in Frankfurt or Stockholm but routes diagnostic logging, administrative access, or customer support through personnel based in the United States, an international data transfer takes place under EU data protection law. You must obtain written confirmation of the contracting entity and the geographic boundaries of support personnel.

Second, understand the fundamental technical reality of LLM inference: encryption in transit and local storage do not cure an unlawful international transfer. To generate tokens, an inference engine must decrypt the input prompt and hold the model weights, KV cache, and intermediate activations in volatile GPU memory (VRAM) as plaintext. The European Data Protection Board's Recommendations 01/2020 on measures that supplement transfer tools, adopted in final form on 18 June 2021, set out why this matters: an exporter must assess, case by case, whether the law and practice of the third country undermine the safeguards it relies on, and technical measures cannot fill that gap where the importer needs access to the data in the clear to perform the service.

• Plaintext execution: LLM computation requires unencrypted prompt processing in GPU memory, making remote foreign access an active Chapter V transfer event.
• Residency vs Sovereignty: Hosting in an EU data centre eliminates cross-border transfers for local compute, but does not automatically resolve access-by-foreign-parent legal risks under the US CLOUD Act. Review our technical guide on data residency for deep architectural trade-offs.
• Model-by-model verification: Serverless inference platforms may route different model weights across different hardware clusters. You must obtain written confirmation of the physical data centre region for every specific model string your application invokes.
• Statutory limits: Regional hosting solves data localisation questions, but leaves all controller duties under Articles 5, 6, 12 to 22, 28, and 32 fully active.

Handling the Sub-Processor List Gap

Under GDPR Article 28(2) and 28(3)(d), a data processor may not engage sub-processors without prior specific or general written authorisation of the controller, and must maintain an up-to-date list of all engaged sub-processors. When compiling a DPIA, compliance officers and legal counsel routinely request this named sub-processor list to evaluate supply chain vulnerability, data egress paths, and secondary transfers.

In the AI infrastructure market, obtaining an exhaustive, real-time list of hardware vendors, colocation facilities, and routing providers can prove challenging. For instance, while Lyceum executes compute in European data centres across Paris and Finland, and provides a Data Processing Agreement on request, a publicly downloadable named sub-processor registry is not currently published on the website. Deployers should confront this reality directly rather than attempting to obscure it in their documentation.

1. Request the sub-processor list in writing: Formally contact your inference provider's compliance or engineering team to request the current schedule of sub-processors and facility operators.
2. Record the status accurately: If a named list cannot be fully supplied, document the entry in your DPIA evidence log as 'Vendor sub-processor schedule available on request / not published on domain'.
3. Evaluate DPA change-notification mechanisms: Ensure your Article 28 Data Processing Agreement contains explicit commitments requiring the provider to notify you of intended sub-processor additions or replacements, granting you the right to object or terminate.
4. Implement compensating architectural controls: Where supply-chain visibility is incomplete, apply prompt redaction, pseudonymisation, or payload tokenisation before sending strings to external endpoints.

A DPIA that honestly identifies gaps and documents contractual mitigating measures is legally robust and defensible. Conversely, an assessment that assumes unverified compliance claims or fabricates audited supply chain verifications will fail supervisory inspection.

Ownership, Limits, and Prior Consultation

A DPIA is an accountability instrument that belongs entirely to the data controller. It cannot be delegated to, outsourced to, or certified by an infrastructure provider. While your inference provider supplies technical parameters, the controller must conduct the assessment, evaluate residual risks, and seek the advice of the data protection officer, where designated, as GDPR Article 35(2) requires.

No hosting choice, European cloud provider, or technical parameter automatically confers GDPR compliance on an application. Compliance is an inherent property of the entire end-to-end processing pipeline, encompassing data collection legal bases under Article 6, data subject rights workflows under Articles 12 to 22, role-based access control, and prompt sanitisation. If your DPIA indicates that the processing would result in a high risk in the absence of measures taken to mitigate that risk (for example, if automated model outputs could cause severe irreversible harm to individuals without human intervention), GDPR Article 36 requires you to consult your supervisory authority before the processing begins.

• The Article 28 Data Processing Agreement: Request the formal contract governing processing instructions and liability limits.
• The precise retention policy: Document the technical mechanism guaranteeing zero data retention or defining the exact ephemeral caching window in GPU memory.
• The specific processing location: Secure written confirmation of the European data centre facility handling the specific model strings used in your application.
• The sub-processor schedule: Obtain the available sub-processor disclosures and ensure contractual notification rights for infrastructure changes.

Before deploying your next LLM feature to production, contact your inference provider in writing to secure these four foundational inputs. Document the responses, verify the evidence boundaries with your Data Protection Officer and legal counsel, and integrate the verified parameters into your Article 35 impact assessment.