Pith. sign in

REVIEW 4 major objections 6 minor 21 references

Towards An Automated AI Act FRIA Tool That Can Reuse GDPR's DPIA

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper treats the GDPR's DPIA and the AI Act's FRIA as structured information processes and shows that a DPIA can be reused as an input to a FRIA, with an automated tool supporting the FRIA as a five-step process.

desk verdict A useful conceptual map for DPIA-to-FRIA reuse and a five-step FRIA tool, but the central reuse claim is asserted at a high level and the needed obligation-by-obligation mapping is explicitly deferred. read the letter →

arxiv 2501.14756 v1 pith:DIBXZZZS submitted 2024-12-23 cs.CY cs.AI

Tytti Rintamaki , Harshvardhan J. Pandit This is my paper · ORCID
classification cs.CYcs.AI
keywords GDPRDPIAAIActFRIAfundamentalrightsimpactassessmentautomatedcompliancetoolriskreuseinformationprocess
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the GDPR's Data Protection Impact Assessment (DPIA), required for high-risk personal-data processing, and the AI Act's Fundamental Rights Impact Assessment (FRIA), required for high-risk AI systems, can be understood as structured information processes. When treated that way, a DPIA can be reused as an ex-ante input to a FRIA or conducted concurrently with it, because the two assessments share much of the same underlying information. The paper identifies the information each assessment requires, aligns them across four shared concerns, and presents the FRIA as a five-step process in which an automated questionnaire tool could assist at each step. The motivation is practical: the AI Act requires the AI Office to build such a tool, and most high-risk AI use cases also trigger a DPIA, so reuse would reduce duplicate compliance work.

What carries the argument

The central machinery is the alignment of two impact assessments as information processes. The paper defines 18 information requirements for the DPIA and six clusters of information for the FRIA, then maps them through four shared categories: systematic description, necessity and proportionality, risks to rights and freedoms, and risk mitigation measures. On top of this mapping sits the five-step FRIA process—determining necessity, reusing the DPIA, gathering information, producing outputs, and notifying authorities—which gives the automated tool a concrete structure, with each step allowing a continuum from manual checklist to full automation.

What would settle it

Run the alignment against a real DPIA for a high-risk AI system and attempt to populate every Article 27(1) FRIA element from the DPIA alone; any element that cannot be filled without new interpretation—such as the description of the deployer's processes or the notification of the market surveillance authority—would mark a boundary where reuse fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that the GDPR's DPIA and the AI Act's FRIA overlap as information processes to the point where DPIA content can be reused in a FRIA, either as an ex-ante input (an existing DPIA starts the FRIA) or as an ex-post complement (both are conducted concurrently). To show this, it aligns the information requirements of the two assessments and identifies commonality in the systematic description of the system, the assessment of necessity and proportionality, the evaluation of risks to rights, and the selection of risk-mitigation measures. It then recasts the FRIA as a five-step process and argues that an automated questionnaire tool can support every step, most directly in reusing DPIA outputs and in structuring the risk and impact information the FRIA requires.

Load-bearing premise

The proposal rests on the assumption that the information categories listed for the DPIA and FRIA cover their respective legal obligations, and that pairing them preserves each obligation's legal meaning; the paper defers the detailed obligation-by-obligation alignment, so a mismatch in any category would break the reuse.

Editorial extensions

If this is right

  • A deployer with a completed DPIA can use it as an ex-ante input to the FRIA, so the FRIA only needs to collect information the DPIA does not already cover, such as training-data provenance and planned system changes.
  • Where a DPIA and FRIA are both required, they can be conducted concurrently as ex-post activities, with a single information-gathering step feeding both assessments.
  • The AI Office's automated FRIA questionnaire can be designed around five stages, each with a different level of automation, from a necessity checklist to automatic notification drafting.
  • Existing DPIA tools and processes can be adapted to support the FRIA, because the shared information categories let DPIA outputs flow into FRIA inputs.
  • The FRIA remains an addition to, not a replacement for, the DPIA: non-personal-data AI harms and system-lifecycle information have no DPIA counterpart.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An implication the paper leaves implicit is that the legal tests for 'risk' differ: GDPR works with material or non-material damage, while the AI Act works with harm to fundamental rights, so a faithful automated mapping would need an explicit translation layer for impact categories, not just a shared set of information fields.
  • A testable extension would be to instantiate the five-step tool on a concrete use case, such as automated passport control, and measure how many FRIA fields a completed DPIA can populate; the residual fields would operationalise the boundary of reuse.
  • The same information-process method could be applied to other overlapping assessments, such as the Digital Services Act's risk assessments or sectoral human-rights due diligence, provided their obligations are re-derived from the relevant legal texts.
  • If the reuse mapping is validated, the EU AI Office's automated tool could share a common information model with GDPR DPIA tools, making 'complemented by' in Article 27(4) a technical interoperability requirement rather than a legal abstraction.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes an information-process interpretation of the GDPR's DPIA and the AI Act's FRIA to support an automated FRIA tool. It enumerates information requirements for DPIA (§3.1) and FRIA (§3.2), discusses ex-ante and ex-post reuse of the DPIA (§3.3), provides a four-category conceptual mapping (§3.4), and describes FRIA as a 5-stage automated-tool process (§4). The central claim is that a DPIA can be reused as an input to, or conducted concurrently with, a FRIA to satisfy parts of Article 27 obligations, and that this reuse can be built into the AI Office's required automated tool.

Significance. If the alignment were demonstrated at the obligation level, it would be a practical contribution for deployers, authorities, and tool builders, bridging two major EU instruments. The paper is legally specific, builds on the authors' prior enumeration of 94 DPIA conditions, offers a structured 5-step process with graduated automation, and explicitly identifies several open issues. Its main value is as a preliminary framework; the central reuse claim is not yet demonstrated because the obligation-to-information trace is deliberately deferred. The paper's honesty about this limitation is a strength, but it means the current version supports a research agenda rather than an implementable compliance solution.

major comments (4)
  1. [§3.4] The reuse claim depends on the obligation-level trace that the paper explicitly defers: §3.4 states that 'a detailed exploration of such an alignment between the obligations and information across both regulations requires further work and is beyond the scope of this current article.' The four broad categories (systematic description, proportionality/necessity, risks, mitigation) are mapped at a conceptual level, but the paper never identifies which Art.27(1)(a)–(f) obligations are already met by which DPIA elements. In particular, Art.27(1)(e) human oversight and Art.27(1)(f) governance/complaint mechanisms are not shown to be covered by the DPIA information list in §3.1, which contains generic technical/organisational measures. §3.4 even acknowledges that the DPIA's mitigation measures are 'limited as compared to the AI Act.' Without an obligation-by-obligation mapping, the conclusion that a DPIA can be reused to satisfy parts of a FRIA is legally unsubstantiated; at most the paper shows that some background information is shared.
  2. [§3.1–3.2] The information categories enumerated in §3.1 and §3.2 are asserted as 'the relevant information' but there is no systematic method for their derivation or a completeness argument. The lists draw on selected articles (Art.10, 11, 13, etc.) without a traceability matrix tying each information item to a specific FRIA obligation. This matters because the tool design in §4.3–4.4 assumes these categories are sufficient to cover both DPIA and FRIA; any omitted category (e.g., FRIA-specific human oversight measures, or non-personal-data harms) would break the reuse claim. The authors should provide an explicit mapping from each Art.27(1) obligation to the information items that satisfy it, or explicitly downgrade the enumeration to illustrative and soften the reuse claim.
  3. [§4.2] Stage 1 (determining FRIA necessity) is a prerequisite for every use of the tool, but the paper states that it will not provide the detailed information required for this stage, deferring it to 'a lengthy analysis of the AI Act as a whole.' This is a significant gap for RQ2 ('Where can automation assist with FRIA obligations?'), because the binary necessity output is the entry point to all later stages. At minimum, the paper should specify the input information categories (e.g., role of entity, Annex III classification, exemptions) and how they can be obtained, even if the full legal analysis is future work. As written, the 5-step process is incompletely specified.
  4. [§3.3] The ex-post use-case rests on a nontrivial interpretation of Art.27(4): the paper reads 'the FRIA shall complement that DPIA' as allowing simultaneous conduct, but the statutory phrase 'is already met through the DPIA' suggests the DPIA must exist before the FRIA can complement it. The paper calls the simultaneous interpretation 'novel but necessary' but does not engage with counterarguments or provide legal analysis supporting it. If this interpretation is wrong, the ex-post reuse scenario is unsupported. The authors should justify this reading or present it as a proposed policy interpretation rather than an established one.
minor comments (6)
  1. [Abstract] The abstract says the AI Act 'requires the EU Commission to create of an automated tool,' but the Introduction correctly quotes Art.27(5) as assigning this task to the AI Office; please align the abstract.
  2. [Introduction] The Introduction attributes the DPIA-complement clause to Art.27-5, whereas §3.3 cites the same clause as Art.27-4; only the latter is correct.
  3. [§3.3 and §3.4] The text repeatedly uses 'compliment' where 'complement' is meant; please correct these typographical errors.
  4. [§4.1] The sentence 'Based on the prior establish reuse of privacy engineering techniques...' is ungrammatical and should be rewritten.
  5. [§3.2] The coined term 'AI subject' (item 2c) is not an established legal term; consider using 'persons subject to the AI system' or 'affected persons' to avoid confusion with GDPR's 'data subject'.
  6. [References] Reference [4] lists '????' as the year and reference [8] lacks a URL or access date; please complete the bibliographic details.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the DPIA-to-FRIA reuse proposal is an interpretive mapping grounded in statutory text, not a self-referential derivation.

full rationale

The paper's central move—aligning DPIA and FRIA information categories (Sections 3.1–3.4) and proposing a five-stage automated FRIA tool (Section 4)—is an interpretive legal-engineering exercise, not a quantitative derivation. There are no fitted parameters or equations whose outputs equal their inputs. The FRIA information requirements in Section 3.2 are anchored in AI Act Articles 3, 10, 11, 12, 13, 27 and Annex IV (e.g., intended purpose, involved entities/data, deployment information, provenance, operational information), even though the authors say they 'reuse' their DPIA-based descriptive understanding. The reuse claim is not forced by construction because Section 3.4 explicitly identifies non-overlapping items (legal bases under GDPR, non-personal data under the AI Act, training/validation data, provenance, planned changes) and concedes that the DPIA's mitigation measures are 'limited as compared to the AI Act.' The paper also flags its own limitation: 'A detailed exploration of such an alignment between the obligations and information across both regulations requires further work and is beyond the scope of this current article' (Section 3.4). That is a scoping caveat, not a circular step—it weakens legal certainty while preserving the paper's stated contribution as a foundation. Self-citations to prior work ([3], [9], [17]) are external published analyses used for background (94 DPIA conditions, AI Cards, DPIA-as-information-process); none is invoked as the sole proof of the central reuse claim, and the claim does not reduce to them. Overall, no load-bearing premise is defined in terms of the conclusion, so no circularity is present.

Assumptions & free parameters 0 free parameters · 5 assumptions · 1 invented entities

The central claim rests on several interpretive assumptions about EU legal terms and about the completeness of enumerated information categories. No free parameters are fitted. The only invented conceptual term is 'AI subject'.

assumptions (5)
  • domain assumption GDPR's 'rights and freedoms' in Art.35 are all-encompassing fundamental rights, supporting alignment with FRIA's fundamental rights focus.
    Section 3.1 interprets the scope of DPIA rights to include all EU fundamental rights, which underpins the mapping in Section 3.4.
  • domain assumption The AI Act's 'affected' in Art.27-1c is interpreted as limited to negative effects.
    Section 3.2 states that 'affected' can be interpreted to be limited to negative effects, narrowing the FRIA risk scope.
  • domain assumption Art.27-4's 'complement that DPIA' is interpreted as allowing both ex-ante reuse and concurrent (ex-post) conduct of DPIA and FRIA.
    Section 3.3 introduces the ex-ante and ex-post use-cases as the core of the reuse argument, but this is one possible reading of the legal text.
  • domain assumption The FRIA process can be modeled as five stages, each addressable by an automated tool.
    Section 4.1 constructs the five-stage process as an interpretation of Art.27-5, but the AI Act does not prescribe such a structure.
  • domain assumption The 'automated tool' in Art.27-5 is interpreted as a questionnaire plus support tool for deployers, not a fully automated decision-maker.
    Section 4.1 infers this from Recital 96 and the term 'template', which shapes all subsequent stage descriptions.
invented entities (1)
  • AI subject
    purpose: To name natural persons subjected to an AI system, analogous to 'data subject' under GDPR.
    Introduced in Section 3.2, item 2c, as a conceptual label; no independently verified referent beyond the proposed usage.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards An Automated AI Act FRIA Tool That Can Reuse GDPR's DPIA." pith.science (2026). https://pith.science/paper/DIBXZZZS

@misc{pith2026250114756,
  author       = {Pith},
  title        = {Pith review of: Towards An Automated AI Act FRIA Tool That Can Reuse GDPR's DPIA},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DIBXZZZS}},
  note         = {Machine review of arXiv:2501.14756}
}
read the original abstract

The AI Act introduces the obligation to conduct a Fundamental Rights Impact Assessment (FRIA), with the possibility to reuse a Data Protection Impact Assessment (DPIA), and requires the EU Commission to create of an automated tool to support the FRIA process. In this article, we provide our novel exploration of the DPIA and FRIA as information processes to enable the creation of automated tools. We first investigate the information involved in DPIA and FRIA, and then use this to align the two to state where a DPIA can be reused in a FRIA. We then present the FRIA as a 5-step process and discuss the role of an automated tool for each step. Our work provides the necessary foundation for creating and managing information for FRIA and supporting it through an automated tool as required by the AI Act.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 16 canonical work pages

  1. [1]

    Regulation 2024/1689 Of The European Parliament And Of The Council of 13 June 2024 laying down harmonised rules on Artificial Intelligence (Artificial Intelligence Act), 2024

    work page 2024

  2. [2]

    Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), Official Journal of the European Union L119 (2016)

    work page 2016

  3. [3]

    Rintamäki, D

    T. Rintamäki, D. Golpayegani, E. Celeste, D. Lewis, H. J. Pandit, High-Risk Categorisations in GDPR vs AI Act: Overlaps and Implications, 2024. doi:10.31219/osf.io/6qhzj

    work page doi:10.31219/osf.io/6qhzj 2024

  4. [4]

    The open source PIA software helps to carry out data protection impact assess- ment, https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact- assessment, ????

    work page

  5. [5]

    A. Mantelero, The Fundamental Rights Impact Assessment (FRIA) in the AI Act: Roots, legal obligations and key elements for a model template, Computer Law & Security Review 54 (2024) 106020. doi:10.1016/j.clsr.2024.106020

    arXiv 2024

  6. [6]

    Calvi, D

    A. Calvi, D. Kotzinos, Enhancing AI fairness through impact assessment in the European Union: A legal and computer science perspective, in: 2023 ACM Conference on Fairness, Accountability, and Transparency, ACM, Chicago IL USA, 2023, pp. 1229–1245. doi:10.1145/3593013.3594076

    arXiv 2023

  7. [7]

    Malgieri, C

    G. Malgieri, C. Santos, Assessing the (Severity of) Impacts on Fundamental Rights, 2024. doi:10. 2139/ssrn.4875937. arXiv:4875937

    work page 2024

  8. [8]

    Fundamental Rights Impact Assessment (FRIA) | aligner, ????

    work page

Show all 21 references
  1. [9]

    Golpayegani, I

    D. Golpayegani, I. Hupont, C. Panigutti, H. J. Pandit, S. Schade, D. O’Sullivan, D. Lewis, AI Cards: Towards an Applied Framework for Machine-Readable AI and Risk Documentation Inspired by the EU AI Act, in: Privacy Technologies and Policy, volume 14831, Springer Nature Switze...

    2024 doi

  2. [10]

    Janssen, M

    H. Janssen, M. Seng Ah Lee, J. Singh, Practical fundamental rights impact assessments, International Journal of Law and Information Technology 30 (2022) 200–232. doi:10.1093/ijlit/eaac018

    2022 doi

  3. [11]

    Inverardi, S

    N. Inverardi, S. Bertaina, I. Biganzoli, A. Cosentini, R. Desiante, D. Fontanella, I. G. Penco, Fun- damental Rights and AI Impact Assessment: A proposal for a new quantitative approach, in: 2024 International Joint Conference on Neural Networks (IJCNN), 2024, pp. 1–8. doi:10....

    2024

  4. [12]

    Georgiadis, G

    G. Georgiadis, G. Poels, Towards a privacy impact assessment methodology to support the requirements of the general data protection regulation in a big data analytics context: A systematic literature review, Computer Law & Security Review 44 (2022) 105640. doi: 10.1016/j.clsr....

    2022

  5. [13]

    The Danish Institute for Human Rights, Human Rights Impact Assessment Guidance and Toolbox, Technical Report, 2020

    2020

  6. [14]

    Gerards, M

    J. Gerards, M. T. Schaefer, A. Vankan, I. Muis, Fundamental Rights and Algorithms Impact Assess- ment, 2022

    2022

  7. [15]

    H. L. Janssen, An approach for a fundamental rights impact assessment to automated decision- making, International Data Privacy Law 10 (2020) 76–106. doi: 10.1093/idpl/ipz028

    2020 doi

  8. [16]

    Cobbe, J

    J. Cobbe, J. Singh, Artificial intelligence as a service: Legal responsibilities, liabilities, and policy challenges, Computer Law & Security Review 42 (2021) 105573. doi: 10/gmq8jm

    2021

  9. [17]

    H. J. Pandit, A Semantic Specification for Data Protection Impact Assessments (DPIA), Towards a Knowledge-Aware AI (2022) 36–50. doi:10.3233/SSW220007

    2022 doi

  10. [18]

    Necessity Toolkit | European Data Protection Supervisor, https://www.edps.europa.eu/data- protection/our-work/publications/papers/necessity-toolkit_en, 2024

    2024

  11. [19]

    EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data | European Data Protection Su- pervisor, https://www.edps.europa.eu/data-protection/our-work/publications/guidelines/edps- guideline...

    2024

  12. [20]

    Novelli, G

    C. Novelli, G. Governatori, A. Rotolo, Automating Business Process Compliance for the EU AI Act, in: Legal Knowledge and Information Systems, IOS Press, 2023, pp. 125–130. doi: 10.3233/ FAIA230955

    2023

  13. [21]

    H. J. Pandit, B. Esteves, G. P. Krog, P. Ryan, D. Golpayegani, J. Flake, Data Privacy Vocabulary (DPV) – Version 2, 2024. arXiv:2404.13426

    2024 arXiv

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.