AI DPIA: How the GDPR Article 35 Assessment Changes When the Processing Runs Through an LLM

GDPR Article 35 has required a Data Protection Impact Assessment for high-risk personal-data processing since May 25, 2018. The EU AI Act adds the Fundamental Rights Impact Assessment under Article 27 for high-risk AI deployers, effective in waves through August 2, 2026 and beyond. An organization that runs an HR-screening AI on EU residents needs both. The assessment that survives is the one that ties the two into a single artifact with the per-decision audit log as the operational evidence.

I want to walk through where the two assessments overlap, where they diverge, and how the audit pipeline becomes the evidence that the assessment commits to.

What the GDPR DPIA covers

Article 35's DPIA covers a description of the processing, the necessity and proportionality, the risks to the rights and freedoms of data subjects, and the measures envisaged to address the risks. The Article 35(7) text lists four elements:

The DPIA is signed by the controller. The DPO advises. The supervisory authority can be consulted under Article 36 when the residual risk is high.

What the EU AI Act FRIA adds

Article 27 of the EU AI Act requires a Fundamental Rights Impact Assessment for deployers of certain high-risk AI systems, particularly those used by public authorities or in essential private services. The FRIA covers the processes the system will be used in, the categories of natural persons affected, the specific risks of harm, the human oversight measures, and the measures for redress when harm occurs.

The FRIA is a separate artifact but shares ground with the DPIA where personal data is processed.

The overlap section: the personal-data part of the AI system

A single artifact can cover the overlap by treating the personal-data part of the AI system once and referencing it from both the DPIA and the FRIA. The overlap section answers:

The first question: what personal data flows into the AI system, in what categories, and from which lawful basis. The answer lists the input categories (customer name, email, employment history, performance review) and the lawful basis (Article 6(1)(b) for contract performance, Article 6(1)(f) for legitimate interest, etc.).

The second question: how the data is retained, where it is processed, and who has access. The answer ties to the provider region map, the retention policy, and the role table.

The third question: how data subjects exercise their Article 15-22 rights. The answer covers access, rectification, erasure, and objection. The audit log is the artifact that supports access and rectification.

The AI-specific section: model and decision evidence

The AI-specific section is new ground for most DPIAs. The questions the regulator now expects to see answered:

Model provenance and training

The model used, the provider, the version, and whether the provider trained on customer data. The artifact is the model catalog and the provider DPA.

Decision logic in human-readable form

A description of how the model contributes to the decision. The description includes the inputs, the model output, the human review step, and the final decision. The description avoids the trap of describing a probabilistic system in deterministic terms.

Accuracy, bias, and false-positive analysis

The vendor's or internal evaluation of the model's accuracy on the use case, the bias analysis across protected categories, and the false-positive and false-negative rates. The artifact is the evaluation report.

Human oversight measures

Article 14 of the EU AI Act requires meaningful human oversight. The DPIA documents what oversight looks like in practice: who reviews the model's output, how often, with what authority to override, and how the override is recorded.

Per-decision audit and traceability

The audit log fields, the retention, and the navigation path from a decision to the inputs that produced it. The artifact is the audit-record schema.

The convergence section: risk treatment

Both the DPIA and the FRIA close with a risk-treatment section. The section lists each identified risk, the measure that addresses it, and the residual risk after the measure.

The measures are concrete and the audit log is the operational evidence each measure produces. A DPIA whose measures are aspirational does not survive the Article 36 consultation.

The audit log as DPIA evidence

The per-decision audit log carries the fields the DPIA commits to.

The data_subject_rights_marker is what tells the downstream tooling to attach Article 22 safeguards (the right to human review, the right to express a point of view, the right to contest the decision). The marker travels with the row.

How this maps to Colorado SB 26-189 and US state AI laws

Colorado's revised AI Act, signed May 14, 2026, imposes assessment obligations on deployers of consequential decisions, including in healthcare. The HIPAA covered-entity exemption was removed in the May revision. The same per-decision audit log that supports the EU DPIA supports the Colorado deployer obligation; the assessment artifact differs in scope but the underlying evidence is the same.

The Texas Responsible AI Governance Act, effective January 1, 2026, similarly imposes deployer obligations with civil penalties. The same audit log supports the Texas assessment.

DeepInspect

DeepInspect produces the per-decision audit the DPIA depends on. The identity, the classification, the policy version, the model used, the human-review marker, and the data-subject-rights marker live on each row. The audit pipeline writes to tamper-evident storage with the retention the DPIA commits to.

The gateway runs in-line with sub-50ms p95 enforcement overhead from internal DeepInspect testing. The DPIA's traceability obligation resolves against the audit pipeline; the FRIA's monitoring obligation resolves against the same source. Book a DPIA-mapping session at deepinspect.ai to walk through the overlap and convergence sections against your current AI deployments.