Alethexis
All features

Assess risk and impact

Data protection impact assessment (DPIA) for AI systems

Decide, system by system, whether processing with AI needs a DPIA and, when it does, document it with the DPO’s opinion.

14-day free trialSee the demo

What it is for

If an AI system processes personal data with a likely high risk to the rights and freedoms of individuals, Article 35 GDPR calls for an impact assessment before the processing. It does not depend on the AI Act classifying the system as high-risk: they are two different thresholds, and one does not determine the other.

Section HRA-2 of the M3 High-Risk Ready module starts with that question, through a screening recorded for each system that processes personal data. Then, for those that require it, a block-by-block assistant collects the minimum content set by Article 35(7) GDPR.

Assessment under Art. 35 GDPR, with PDF. The DPIA is an instrument independent of the FRIA, never a substitute for it.

How it works

Article 35 screening, system by system

For each system that processes personal data you record whether it requires an impact assessment and on what basis: a case under Article 35(3), the list published by the supervisory authority or the controller’s reasoned judgement. Where you conclude it is not required, or decide by reasoned judgement, a rationale is mandatory and is recorded with its author and date. The Owner, the AI Officer and the DPO can record it.

A view that sorts your systems

HRA-2 groups systems as pending screening, requiring an assessment, not requiring one, voluntary assessments and out of scope, where they process no personal data. The section completes itself once no system is left to screen and every system that requires one has its DPIA with a recorded approval.

The DPIA, block by block

Preliminary assessment, description of the processing, purpose and legal basis, necessity and proportionality, risks with their likelihood and impact, measures to mitigate them and a block for the information the provider supplies under Article 13 of the AI Act. In the risks block you see those the risk register already holds for that system, and the assistant flags when special categories of data are involved.

DPO opinion and recorded approval

The DPO gives an opinion — favourable, conditional or unfavourable —, with conditions or reasons where it is not favourable, and the Owner records the approval. If nobody holds the DPO role, the Owner acts in their place and the screen says so. It also records whether a prior consultation of the supervisory authority has been started or completed. Statuses: draft, opinion, approval recorded and archived.

The AEPD list, as guidance

In Spain, the AEPD publishes an indicative, non-exhaustive list of processing that requires an impact assessment: according to that list, one will be needed in most cases where the processing meets two or more of its criteria, unless it is on the list of processing that does not require one (Article 35(5) GDPR). It is the authority’s guidance, a good practice: the obligation is the one in Article 35 GDPR.

DPIA screen (HRA-2) in the dental clinic demo, with the systems that require one and their status, with fictitious data
Demo account · fictitious data

What you get

  • DPIA PDF with a hash

    The PDF is generated when the approval is recorded, with the system and processing assessed, the version and date, the content of each block, the DPO’s opinion and the recorded approvals. The platform records the file’s SHA-256 integrity hash and shows it next to the download button. Any later change requires a new version. The PDF is generated in Spanish.

  • Evidence and history

    The PDF is filed as evidence for the system and, if the system is high-risk, goes into its dossier. Earlier versions are kept as history.

Basis

The controls in the Alethexis catalogue that this feature helps to document, with their legal basis where they have one, and their nature.

  • LMLegal obligation with an explicit mandate
  • LCLegal obligation with a confirmed future date
LMLegal obligation with an explicit mandateM3-HRA-021

Determining whether a DPIA is required (Article 35 GDPR)

For each processing of personal data associated with an AI system, assess whether it is likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1) GDPR). Article 35(3) lists, in particular, three cases in which the assessment is required (a systematic and extensive evaluation of personal aspects based on automated processing, on which decisions are based that produce legal effects or similarly significantly affect natural persons; large-scale processing of special categories of data or of personal data relating to criminal convictions and offences; systematic monitoring of a publicly accessible area on a large scale), and the AEPD publishes the list under Article 35(4). The decision, positive or negative, is documented.

Legal basis

Regulation (EU) 2016/679 (GDPR), Article 35(1):

Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.
LMLegal obligation with an explicit mandateM3-HRA-024

Necessity and proportionality assessment (Article 35(7)(b) GDPR)

Justify the necessity of the processing in relation to its purposes and the proportionality between the data processed and that purpose. Document why less intrusive alternatives are not workable. Proportionality is what separates real diligence from paperwork.

LCLegal obligation with a confirmed future dateM3-HRA-028

Integrating Article 13 AI Act information into the DPIA

Where the system is P5, the deployer feeds the DPIA with the information received from the provider under Article 13 (instructions for use, capabilities, limitations, intended purpose). Article 26(9) provides that, where applicable, the deployer uses that information to comply with its obligation to carry out a data protection impact assessment. Article 26 applies from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I ones; it does not reach the products in Annex I, Section B (Article 113, third paragraph, point (c), and Article 2(2), as amended by Regulation (EU) 2026/1744).

Data from the controls catalogue. The labels show the regulatory nature of each control; they are not a statement of compliance.

Available in

  • M3High-Risk Ready

Modules build on each other: M2 includes everything in M1, and M3 includes M1 and M2.

Related

FAQ

Do I need a DPIA if my AI system is not high-risk?
You may. High risk under the AI Act and high risk under Article 35 GDPR are different thresholds: a system classified as minimal risk can process data in a way that requires an impact assessment. That is why screening covers every system that processes personal data, not only the high-risk ones.
Is the DPIA part of the FRIA?
No. They are independent instruments, each with its own legal basis, record and PDF. If a system needs both, the FRIA can refer to the relevant sections of the DPIA or incorporate them, but neither replaces the other.
What if our organisation has no DPO?
If your organisation declares that it has no DPO, the person who takes on that role in Alethexis is shown as “privacy lead”, not as DPO. If nobody holds the role, the Owner acts in their place and the screen says so, recommending that it be assigned. Whether you must have a DPO depends on the GDPR and on your activity.
Does Alethexis submit the DPIA to the AEPD?
No. Alethexis structures and keeps your DPIA, and lets you record whether you have started or completed a prior consultation of the supervisory authority. You carry out the consultation with the authority, and the assessment of the risk is for your organisation, as controller, with the advice of the DPO.

Try it with your own systems

14-day free trialSee the demo