DPIA Implementation Guide

A Data Protection Impact Assessment is required under GDPR Article 35 before deploying any AI system likely to result in high risk to individuals. For AI systems, DPIAs are not optional — and supervisory authorities have been clear that a DPIA must address the system’s evidence architecture, not just its data flows. This guide explains how AIEP’s verifiable records satisfy the structural requirements of Article 35.


When a DPIA is required

Under Article 35, a DPIA is mandatory for processing that involves:

  • Systematic and extensive automated evaluation of natural persons, including profiling, to make decisions with legal or significant effects
  • Large-scale processing of special categories of data
  • Systematic monitoring of publicly accessible areas on a large scale

Virtually all high-risk AI deployments — hiring, credit, health, legal, benefits, insurance — will meet at least the first criterion. A DPIA must be conducted before processing begins.


What GDPR Article 35 requires the DPIA to cover

Article 35 requirementAIEP response
A systematic description of the processingEvidence artefact schema provides a machine-readable, version-bound description of every inference
An assessment of necessity and proportionalityNegative Proofs record when evidence was insufficient — demonstrating proportionate inference
An assessment of risks to rights and freedomsTamper-evident chain makes bias, hallucination, or drift detectable in audit
Measures to address risksComplianceCertificates and hash-bound outputs are the technical measures

Structuring your DPIA

Step 1 — Describe the AI processing

Document: what data the AI system uses as input; what evidence sources it retrieves; what outputs it produces; and what decisions those outputs inform. AIEP’s evidence ledger provides the technical specification for the first three automatically.

Step 2 — Identify risks

For AI systems, the relevant risks include: hallucinated outputs treated as factual; contradictory evidence not surfaced; reasoning drift over time; retroactive modification of records. AIEP’s architecture eliminates each of these structurally:

  • Outputs are hash-committed at production time — retroactive modification is detectable
  • Dissent/negative proof records are mandatory when evidence is absent or contradictory
  • GENOME SDK locks the kernel version — drift between deployments is explicit, not silent

Step 3 — Document technical measures

In the DPIA’s technical measures section, reference: the AIEP canonical schema version in force; the GENOME_LOCKFILE.json hash; the Evidence Ledger configuration; and the deployment’s ComplianceCertificate generation policy.

Step 4 — Consult the DPO

Where a DPIA indicates high residual risk, GDPR requires prior consultation with the supervisory authority (Article 36). AIEP’s artefact architecture makes that consultation significantly more tractable — you can present the DPA with machine-verifiable evidence of your system’s behaviour, not just a narrative description.


Ongoing monitoring

A DPIA is not a one-time document. Article 35(11) requires that the assessment be reviewed when there is a change in the risk. AIEP’s version-binding (GENOME_LOCKFILE, schema version, kernel hash) makes version changes explicit and auditable — your DPIA review process can be triggered automatically on a new lockfile commit.


Template DPIA section: AI system evidence architecture

Technical measure: Verifiable evidence architecture
The AI system operates under AIEP v[X.Y.Z]. Every output is hash-bound to its source evidence chain at time of production. Outputs cannot be retroactively modified without detection. Where evidence is insufficient, a Negative Proof record is generated rather than a silently uncertain output. The system’s kernel is version-locked via GENOME_LOCKFILE.json (hash: [value]). ComplianceCertificates are generated for all inference operations. These records are available for supervisory audit on request.


GDPR & AI Compliance · EU AI Act Compliance · Data Sovereignty · Compliance