AI Impact Assessment vs DPIA: Key Differences

Two Assessments, Two Legal Bases

A Data Protection Impact Assessment exists under GDPR Article 35(1) and applies where processing of personal data is likely to result in high risk to individuals' rights and freedoms, particularly when new technologies are involved. Its scope is the processing operation itself: what data is collected, why, and what happens to it.

The EU AI Act creates a separate obligation set built around the AI system rather than the data flow. Article 9 requires providers of high-risk AI systems to maintain a risk management system across the system lifecycle, and Article 27 requires specified deployers of high-risk systems, including public-law bodies and certain private entities in sectors such as banking, insurance, and public services, to complete a Fundamental Rights Impact Assessment before deployment.

These are frequently referred to together as an AI Impact Assessment, though the Act itself uses the FRIA term for the deployer-facing obligation. A separate reference model, NIST's AI Risk Management Framework, organizes AI risk assessment around trustworthiness characteristics such as validity, safety, security, fairness, and transparency, which differs from GDPR's data-subject-rights framing and is useful context for organizations operating outside the EU.

When Each Assessment Is Required

DPIA triggers are defined by data processing characteristics. Article 35(3) mandates a DPIA for systematic or extensive profiling with legal or similarly significant effects, large-scale processing of special category data, and large-scale systematic monitoring of public areas. The Article 29 Working Party's WP248 rev.01 guidance, endorsed by the EDPB, adds nine supplementary criteria, including evaluation or scoring and automated decision-making with significant effect, that also indicate a DPIA is required even where Article 35(3) does not directly apply.

FRIA triggers, by contrast, depend on whether the AI system falls within the high-risk categories defined in Article 6 and Annex III of the AI Act, such as biometrics, employment, education, essential services, and law enforcement, and whether the organization qualifies as a deployer subject to Article 27.

Because these trigger sets are independent, an AI system can require a DPIA, a FRIA, both, or neither. A high-risk hiring tool that also processes special category data would likely trigger both assessments; an internal analytics tool that does not meet Annex III criteria and processes only non-sensitive aggregate data may trigger neither.

Differences in Methodology and Documentation

DPIA methodology under Article 35(7) requires a description of the processing operations, an assessment of necessity and proportionality, an assessment of risk to the rights and freedoms of data subjects, and the measures taken to address that risk. The output is a documented record tied to the processing activity, typically owned by privacy or data protection teams.

AI Act risk management under Article 9 and the FRIA under Article 27 extend the analysis beyond personal data to the broader design and deployment context of the system, including risks that do not involve personal data processing at all, such as safety or discriminatory outcomes arising from model behavior. This documentation is often owned by AI governance or product teams rather than privacy teams, since it addresses system-level risk management rather than a single processing activity.

Organizations using NIST's AI RMF as a reference model will find its structure oriented around trustworthiness characteristics rather than data subject rights, which can complement but not substitute for either EU obligation.

Integrating the Two Without Duplicating Effort

Article 27(4) of the AI Act provides an explicit basis for integration: where a DPIA has already been performed for the same processing, the FRIA obligation should be fulfilled in conjunction with and to complement that DPIA rather than as a separate exercise. This makes integration a legitimate governance design choice, not a compliance shortcut, provided the FRIA addresses the additional fundamental rights and safety considerations that a DPIA does not cover.

In practice, this requires mapping each AI use case against both trigger sets separately, since ownership, timing, and regulator relationships differ even when the underlying assessment content overlaps. A single risk register or control mapping that cross-references DPIA and AI Act documentation for the same system can reduce duplicated evidence collection during audits, but it depends on continuing to track the system after deployment.

Ongoing monitoring of how a high-risk AI system behaves in production, who accesses it, and what actions it takes is what turns a point-in-time assessment into current evidence rather than a stale document. This is the operational layer where runtime governance and audit logging controls support both DPIA and AI Act documentation over the system's lifecycle, rather than replacing the assessments themselves.