{"id":"88671b9d-56bc-4d3e-96ae-32db98bb06e6","arxiv_id":"2501.14756","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"The authors propose an information-process alignment between GDPR DPIAs and AI Act FRIAs, and a five-step automated tool workflow that reuses DPIA data.","lead":"This paper maps the information required for a GDPR Data Protection Impact Assessment (DPIA) onto the EU AI Act's Fundamental Rights Impact Assessment (FRIA), and proposes a five-step process for an automated FRIA tool. It aims to help regulators and deployers reuse existing DPIA work when building the AI Act's required automated support tool.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The reuse claim rests on an unmade obligation-level argument: DPIA information categories do not obviously satisfy FRIA-specific obligations such as Art. 27(1)(e) human oversight and (f) incident/complaint mechanisms.","rationale":"The reader's weakest_assumption identified the sufficiency of the information categories and the preservation of legal meaning in the mapping. My concern is more specific: the paper itself defers the obligation-level mapping, and the FRIA contains obligations (human oversight, incident/complaint mechanisms) that a DPIA is not designed to document. This makes the central reuse claim contingent on an argument the paper does not provide. This does not warrant rejection: the paper is an explicit early-stage conceptual framework, the deferred analysis is acknowledged, and the proposed 5-step process remains useful as a scaffold. The conditional verdict stands, with the condition being that the traceability matrix must be produced before the reuse claim is treated as established. I agree with the reader's identification of the weakest assumption; my concern sharpens it by pointing to specific obligations that are likely uncovered.","tokens_in":15035,"tokens_out":4027,"duration_ms":38540,"concrete_test":"Build a traceability matrix crossing each obligation in AI Act Art. 27(1)(a)–(f) with the DPIA elements enumerated in Section 3.1 and the mandatory content of GDPR Art. 35(7). For each cell, note whether a DPIA conducted in accordance with the GDPR would necessarily contain the required information, would contain it only if the use-case involved personal data, or would not contain it. Then apply the matrix to a concrete high-risk use case (e.g., the paper’s automated passport control example) using a standard DPIA template such as the CNIL PIA software. If Art. 27(1)(e) and (f) are not covered by the DPIA, the paper's central reuse claim should be weakened to 'DPIA supplies inputs, not satisfied obligations', and Stage 2 of the tool should be redesigned accordingly.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The reuse claim in Sections 3.3–3.4 and the tool design in Stage 2 (Section 4.3) presuppose that a GDPR DPIA supplies information that satisfies FRIA obligations. This is exactly what Art. 27(4) requires, but the paper never demonstrates it. It groups FRIA information into four broad categories and maps them to DPIA elements at a high level, then 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' (Section 3.4). That is the load-bearing step. In particular, Art. 27(1)(e) requires a description of how human oversight measures are implemented, and Art. 27(1)(f) requires measures for incidents and governance/complaint mechanisms. The DPIA information list in Section 3.1 contains generic technical and organisational measures but does not require either of these FRIA-specific elements. Section 3.4 acknowledges the DPIA’s mitigation measures are 'limited as compared to the AI Act' but does not identify which Art. 27(1) obligations, if any, are 'already met' by a DPIA. Without that trace, the claim that a DPIA can be reused to satisfy parts of a FRIA is legally unsubstantiated; at most, a DPIA can supply background data that the deployer then uses to complete FRIA-specific obligations.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":15320,"tokens_out":6517,"duration_ms":56242,"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":[{"comment":"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.","section":"§3.4"},{"comment":"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.","section":"§3.1–3.2"},{"comment":"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.","section":"§4.2"},{"comment":"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.","section":"§3.3"}],"minor_comments":[{"comment":"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.","section":"Abstract"},{"comment":"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.","section":"Introduction"},{"comment":"The text repeatedly uses 'compliment' where 'complement' is meant; please correct these typographical errors.","section":"§3.3 and §3.4"},{"comment":"The sentence 'Based on the prior establish reuse of privacy engineering techniques...' is ungrammatical and should be rewritten.","section":"§4.1"},{"comment":"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'.","section":"§3.2"},{"comment":"Reference [4] lists '????' as the year and reference [8] lacks a URL or access date; please complete the bibliographic details.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a workshop-length position paper. The main gap is the deferred obligation mapping, which is also the main substantive weakness. A revision that adds even a partial traceability matrix, or that reframes the paper as a framework proposal with an explicit non-committal reuse hypothesis, would make the contribution fit for publication. The paper's reliance on prior work by the same authors is transparent and not problematic."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing to know: this is a solid workshop paper, not a finished legal analysis. It gives a clear information-systems framing of DPIA and FRIA, and a plausible five-step FRIA process. But the key reuse claim—that a DPIA can actually satisfy parts of a FRIA—is asserted at a conceptual level and explicitly deferred to future work. The stress-test note is right: they never trace Art. 27(1)(e) human oversight or (f) incident/complaint mechanisms to any DPIA element, and Section 3.4 itself admits the DPIA’s mitigation measures are more limited than the AI Act’s. So what the paper really establishes is that the two assessments share a lot of information, not that a DPIA legally meets FRIA obligations.\n\nWhat is genuinely new: the ex-ante/ex-post distinction is useful and not something I’ve seen framed that way in the prior work they cite. The five-stage workflow—necessity, reuse, information gathering, outputs, notification—is a sensible decomposition and a practical contribution for anyone building compliance tooling. The information requirement lists in Sections 3.1 and 3.2 are carefully compiled from the relevant articles and annexes, and the mapping in 3.4, while high-level, is a reasonable starting point. The citation pattern is fine: the self-citations to prior work on the 94 DPIA conditions and the DPV are legitimate relevant external results, not padding.\n\nThe soft spots are real but proportionate. The central legal claim is under-supported; the paper would be stronger if it either did the obligation-level mapping for at least the four Art. 27(1) points, or explicitly reframed the contribution as information-interoperability groundwork rather than “reuse.” As written, a deployer might walk away thinking a DPIA covers human oversight when it doesn’t. There are also minor internal issues: RQ3 is mentioned but never defined, and there’s a Commission/AI Office slip. Stage 1 (FRIA necessity) is a placeholder, which the authors acknowledge. These are fixable.\n\nBottom line: this deserves a serious referee, but with the expectation that the reuse claim gets tightened or visibly bounded. It’s a useful foundation for people working on AI Act compliance tooling, and the ex-ante/ex-post framing alone is worth discussing. Don’t desk-reject; send it out with a request to either supply the missing legal trace or soften the claim.","headline":"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.","tokens_in":15851,"tokens_out":2701,"would_cite":true,"duration_ms":27064,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["GDPR","DPIA","AI Act","FRIA","fundamental rights impact assessment","automated compliance tool","risk assessment reuse","information process"],"falsifier":"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.","tokens_in":14849,"feed_emoji":"⚖️","tokens_out":7900,"duration_ms":66777,"temperature":0.7,"pith_summary":"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.","feed_headline":"Map your GDPR DPIA onto the AI Act's FRIA—reuse is feasible","feed_subtitle":"The paper aligns both impact assessments as information flows and outlines a five-step automated tool for Article 27.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Prior analysis showing that 22 of 25 AI Act Annex III high-risk clauses also require a DPIA, establishing the overlap that motivates reuse.","marker":"[3]"},{"why":"Expresses the DPIA as a multi-stage information process, the basis for treating both assessments as information flows.","marker":"[17]"},{"why":"Provides a machine-readable framework for representing AI Act information and a heuristic for purpose compatibility used in the tool's information gathering.","marker":"[9]"},{"why":"Supplies a structured FRIA template that maps inputs to risk levels, used in the output stage.","marker":"[8]"},{"why":"Gives the legal analysis of FRIA that informs the information-requirements section.","marker":"[5]"},{"why":"Presents FRIA as a four-step process that the paper extends to five steps.","marker":"[10]"},{"why":"Reviews DPIA methodologies and tools, supporting treatment of DPIA as an established process.","marker":"[12]"},{"why":"Provides the vocabulary planned for machine-readable DPIA and FRIA information, enabling interoperable tools.","marker":"[21]"}],"fun_headline_variants":["Reuse your GDPR DPIA for the AI Act FRIA","DPIA reuse makes FRIA automation feasible","Five-step blueprint for an automated FRIA via DPIA","Align DPIA and FRIA to automate impact assessments","DPIA reuse: a practical path to FRIA automation"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Reuse your GDPR DPIA for the AI Act FRIA","DPIA reuse makes FRIA automation feasible","Five-step blueprint for an automated FRIA via DPIA","Align DPIA and FRIA to automate impact assessments","DPIA reuse: a practical path to FRIA automation"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00069,"raw_usage":{"total_tokens":3072,"prompt_tokens":842,"completion_tokens":2230,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":458,"completion_tokens_details":{"reasoning_tokens":2152}},"tokens_in":458,"tokens_out":2230,"duration_ms":15231,"temperature":1.0,"reasoning_tokens":2152,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T05:26:00.714757+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Rintamäki, D","cited_arxiv_id":null,"evidence_quote":"Prior analysis showing that 22 of 25 AI Act Annex III high-risk clauses also require a DPIA, establishing the overlap that motivates reuse."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Expresses the DPIA as a multi-stage information process, the basis for treating both assessments as information flows."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies a structured FRIA template that maps inputs to risk levels, used in the output stage."},{"cited_title":"Janssen, M","cited_arxiv_id":null,"evidence_quote":"Presents FRIA as a four-step process that the paper extends to five steps."},{"cited_title":"Georgiadis, G","cited_arxiv_id":null,"evidence_quote":"Reviews DPIA methodologies and tools, supporting treatment of DPIA as an established process."}],"review_version":1}