AI Compliance Vendors

Data Protection Impact Assessment (GDPR Art. 35)

GDPR-mandated assessment of high-risk personal-data processing operations, including AI systems that process personal data. Distinct from EU AI Act Art. 27 FRIA and Colorado AI Act §6-1-1703 impact assessments.

Required by: GDPR Art. 22

Why this obligation matters

A Data Protection Impact Assessment under GDPR Article 35 is required where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. Most AI deployments that touch personal data meet that bar.

Article 35(3) lists three cases where a DPIA is always required: systematic and extensive evaluation of personal aspects through automated processing (including profiling) that produces legal or similarly significant effects; processing on a large scale of special categories of data under Article 9; and systematic monitoring of publicly accessible areas on a large scale.

For AI specifically, most national DPAs (CNIL, ICO, AEPD) have published guidance that consequential decision-support systems, biometric identification, and large-scale generative-AI deployments all fall within Article 35.

What vendors typically provide

DPIA tooling is mature in the broader privacy-tech category. AI-specific DPIA tooling is newer. Look for vendors that handle both the template/workflow side and the AI-specific risk-mapping side.

Capabilities to look for:

  • DPIA templates aligned to GDPR Article 35 and Article 29 WP248.
  • AI-specific risk taxonomy that maps to the bias, transparency, and accuracy obligations in the AI Act.
  • DPO sign-off workflow with audit trail.
  • Mechanism for consulting data subjects (Article 35(9)) and recording responses.
  • Combined FRIA/DPIA workflow when both regimes apply.
  • Versioning so re-assessment is straightforward after material change.

Compliance checklist

  • [ ] Screen every AI deployment for DPIA triggers under Article 35(3) and DPA guidance.
  • [ ] Describe the processing operations and purposes.
  • [ ] Assess the necessity and proportionality of the processing in relation to the purpose.
  • [ ] Assess the risks to data subjects' rights and freedoms.
  • [ ] Identify mitigation measures and demonstrate compliance with the GDPR.
  • [ ] Consult the DPO and record the consultation outcome.
  • [ ] Where required, seek the views of data subjects.
  • [ ] If the DPIA indicates residual high risk, consult the supervisory authority before processing (Article 36).
  • [ ] Re-assess after material change to the processing.

Common gaps we see

The first gap is conflating a privacy notice with a DPIA. The notice describes processing to data subjects. The DPIA assesses risks to data subjects. Different documents, different purposes.

The second gap is the DPO consultation that does not happen meaningfully. Article 35(2) requires the controller to seek the DPO's advice. Submitting a finished DPIA to the DPO for signature does not satisfy that. The DPO should be consulted while assessing necessity, proportionality, and mitigation.

The third gap is Article 36 prior consultation. When residual high risk remains, the controller must consult the supervisory authority before processing. Most controllers skip this step on the assumption that mitigation closed the risk. Several CNIL and AEPD enforcement actions in 2024-25 specifically cited this failure.

Regulator guidance and primary sources

Vendors that support this obligation

No vendors currently tagged for this obligation.

Related