Source-linked AI summary

From Legal Text to AI-specific Risk Sources: A Systematic Analysis of the EU AI Act's High-Risk Requirements

Ronald Schnitzer, Mike Auer, Rumpa Choudhury, Andreas Hapfelmeier, Maximilian Hoeving, Isabelle Painter, Josiane Xavier Parreira, Sonja Zillner

arXiv:2609.13535v1cs.AI

TL;DR

The AI Act’s high-risk requirements do not explicitly enumerate their AI-specific risk sources, leaving no systematic mapping to established taxonomies. This paper classifies those requirements and derives a consolidated risk-source list. It finds that only a minority directly address such sources, with the resulting list comprising 40 distinct sources.

  • Problem

    The AI Act’s HRRs implicitly address AI-specific risk sources without enumerating them, and no systematic extraction has provided a structured basis for assessing what risk-management practices cover.

    Source: §1 · pp. 2–3
  • Method

    The authors classify extracted HRRs as AI risk-related, process compliance, or documentation compliance requirements, then derive risk sources from the AI risk-related requirements.

    Source: §1 · p. 3, §3.1 · p. 6, §3.2 · p. 6
  • Results

    31.03% of the 87 extracted requirements directly address AI-specific risk sources, from which the authors derive 40 distinct sources.

    Source: §6 · p. 16
  • Takeaways & Limitations

    The EU AI Act Risk Source List provides a structured inventory for comparing the risk sources addressed by the Act with established AI risk taxonomies.

    Source: §5.1 · p. 14, §6 · p. 16

    The four raters shared professional backgrounds and institutional affiliation; AIR had the lowest agreement (Fleiss’ κ = 0.61), so their consistency does not establish interpretive validity.

    Source: Inter-rater Reliability · p. 10, §5.4 · p. 15

Abstract

from arXiv · show

The EU AI Act introduces mandatory requirements for high-risk AI systems with the explicit goal of ensuring the development and operation of trustworthy AI. At the same time, AI risk management practices rely on structured risk taxonomies to systematically identify and treat AI-specific risk sources. As both the AI Act and established risk taxonomies aim to address AI-induced risks, a natural question is whether they align in the risk sources they cover. However, no clear mapping exists between the risks implicitly addressed by the Act's high-risk requirements and established taxonomies, leaving practitioners without a structured basis for aligning regulatory obligations with AI risk management practice. This paper presents a systematic classification of the requirements extracted from the EU AI Act Section 2 (Requirements for high-risk AI systems), revealing that only a minority directly address AI-specific risk sources, while the majority impose organizational process and documentation obligations. From the AI risk-related requirements, a consolidated list of distinct AI-specific risk sources is derived. The resulting EU AI Act Risk Source List takes an important step towards bridging the gap between legal obligation and AI risk management practice, providing a structured reference for explicit comparison between existing AI risk taxonomies and the risk sources implicitly addressed by the EU AI Act. Important Note: This is the authors' preprint. The paper was presented at the 4th International Conference on Frontiers of Artificial Intelligence, Ethics, and Multidisciplinary Applications. A link to the conference's official proceedings will be provided upon publication.

1 Introduction

The EU AI Act’s High-Risk Requirements (HRRs) aim to mitigate risks and ensure trustworthiness, but do not explicitly enumerate the AI-specific risk sources they address. This study classifies the HRRs and derives a risk-source list to provide a structured basis for relating legal obligations to AI risk-management practice.

1 Introduction

  • The Act classifies systems into four risk levels, with comprehensive obligations for high-risk systems in Articles 8–15.Those obligations are intended to mitigate risks and ensure a high level of trustworthiness; application dates differ by high-risk system category.Source: §1 · p. 2
  • The HRRs combine obligations directly tied to AI-specific risks with process and documentation duties, leaving their motivating risk sources implicit.For example, requiring provider identity and contact details in instructions for use has no relation to an AI-specific risk source.Source: §1 · p. 2
  • The study asks what proportion of HRRs directly relate to AI-specific risk sources and which sources they implicitly address.Source: §1 · p. 3
  • The authors classify extracted HRRs into AI risk-related, process compliance, and documentation compliance requirements, then derive a list of risk sources from the AI risk-related requirements.Source: §1 · p. 3
  • The resulting EU AI Act Risk Source List provides a structured reference for AI risk identification and assessment and for comparing coverage with established taxonomies.Source: §1 · p. 3

2 Related Work

Prior work separately analyzes the AI Act, inventories AI risks, or models regulatory concepts, but does not provide a systematic, up-to-date linkage between HRRs and AI-specific risk sources. This study positions its requirements-engineering approach and Risk Source List as a bridge between those strands.

2 Related Work

  • Legal analyses clarify the scope and intent of HRRs, while prior work formalizes high-risk classification concepts and obligations.Almada examines product safety and fundamental-rights protections; Golpayegani et al. formalize conditions for high-risk classification.Source: §2 · pp. 3–4
  • AI-risk repositories and taxonomies offer candidate hazards and organizing principles across technical, ethical, and application domains.Examples include the MIT Risk Repository and Bagehorn et al.’s taxonomy and tooling [2].Source: §2 · p. 4
  • Existing knowledge representations model obligations or risk concepts, but leave open a systematic, up-to-date classification explicitly relating HRRs to AI-specific sources.TAIR uses an outdated Act version, while AIRO provides a schema without a comprehensive, systematically populated risk list.Source: §2 · p. 4
  • The study addresses a gap between legal analyses of the Act and AI-risk taxonomies: neither, on its own, systematically links HRRs to AI-specific risk sources.Source: §2 · p. 4

3 Methodology

The methodology decomposes the Act’s legal prose into HRRs, classifies those obligations, and synthesizes AI-specific risk sources from the requirements classified as risk-related. It uses rule-based extraction, a three-category codebook, independent ratings, and researcher reconciliation.

3.1 HRR Extraction

  • The authors decomposed legal prose using ISO/IEC/IEEE 29148:2018 and treated enumerated points as inheriting shared components from parent statements.They split units containing separate obligations, including blocks with multiple modal verbs; the smallest addressable legal units formed the starting point for decomposition.Source: §3.1 · p. 5
  • The extraction procedure reduced 111 candidate requirements to 87 HRRs by applying four sequential exclusion criteria.Candidates were excluded if they came from Article 8, used permissive “may,” concerned non-provider actors, or merely scoped later obligations.Source: §3.1 · p. 6

3.2 HRR Classification

  • Four raters used a codebook to classify HRRs as AI risk-related, process compliance, or documentation compliance requirements; categories were not mutually exclusive.Four AI engineering and research raters coded a pilot and then the full set; confidence-weighted majority voting determined final labels, with ties returned for consensus.Source: §3.2 · pp. 6–7
  • The classification distinguishes direct AI-specific risk obligations from duties to establish or execute governance processes and duties to produce, maintain, or disclose artifacts.Source: §3.2 · pp. 6–7

3.3 AI Risk Source Extraction

  • For each requirement labeled AI risk-related, four raters supplied free-text risk-source labels that two researchers independently synthesized and reconciled.Semantically equivalent labels were merged, only labels traceable to the requirement text were retained, and multiple sources could be kept for one requirement.Source: §3.3 · p. 8

4 Results

The classification results show that most high-risk requirements concern process or documentation, while agreement was substantial overall but weakest for identifying AI-specific risks. The analysis also yields a 40-source list and shows how requirement categories vary across Articles 9–15.

Inter-rater Reliability

  • Overall Fleiss’ κ was 0.69; per-category values were 0.61 for AIR, 0.66 for PCR, and 0.73 for DCR, with AIR agreement lowest.The authors caution that agreement among raters with a shared professional profile measures consistency, not interpretive validity.Source: Inter-rater Reliability · pp. 9–10, Table 1 · p. 9

Distribution of Categories

  • Of 87 requirements, 27 (31.03%) were AIR, 40 (45.98%) PCR, and 20 (22.99%) DCR.Table 2 reports the category distribution across Articles 9–15.Source: Distribution of Categories · p. 10, Table 2 · p. 10
  • Article 9’s 18 requirements were all PCR, while Article 10 had the most AIR requirements, with 11 of its 19 requirements classified as AIR.Article 9’s process classification reflects the obligation type, although it requires identifying and mitigating health, safety, and fundamental-rights risks; Article 10’s remaining requirements comprised 7 PCR and 1 DCR.Source: Distribution of Categories · p. 10
  • Article 11’s six requirements were split evenly between DCR and PCR, and Article 12’s eight requirements were almost entirely PCR despite its indirect traceability link to risk.Article 12.2 requires logging capabilities that can identify situations potentially resulting in risk.Source: Distribution of Categories · pp. 10–11
  • Articles 13, 14, and 15 had 2, 8, and 6 AIR requirements, respectively, addressing human-AI interaction and data or system risks.Article 13’s AIR requirements concern disclosure of foreseeable risks and system limitations; Article 14 addresses automation bias and insufficient intervention, while Article 15 includes robustness, data poisoning, and self-reinforcing bias through feedback loops.Source: Distribution of Categories · p. 11

4.2 Derivation of the AI-Specific Risk Source List

  • The synthesis produced a list of 40 distinct AI-specific risk sources from labels collected across 44 requirements, mapped to their source articles.The list presents the minimum set of risks implicitly addressed by Articles 9–15 and groups them into three clusters.Source: Table 3 · p. 12, §4.2 · p. 13

5 Discussion

The discussion finds that most high-risk requirements impose process and documentation obligations, while a smaller share directly address AI-specific risks. It interprets the derived risk-source list as a useful starting point, not an exhaustive inventory or a formal comparison with existing taxonomies.

5.1 Interpretation of Classification Results and AI-Specific Risk Sources

  • Nearly a third of requirements are AI risk-related, while most are process or documentation obligations; Article 9 requires providers to address all known and foreseeable risks.The authors say Article 9 delegates identification of specific risk sources to providers, so the AIR requirements are only a minimum set and the full scope may be broader.Source: §5.1 · p. 13
  • The 27 AIR requirements cluster around data quality, human-AI interaction, and technical risks, with 11 in Article 10, 10 across Articles 13–14, and 6 in Article 15.Examples include data bias, automation bias, misuse, data poisoning, and feedback-loop bias; Article 15 treats accuracy and robustness more abstractly than some cybersecurity risks.Source: §5.1 · pp. 13–14
  • The 40-source Risk Source List makes explicit requirements traceable, but explainability, distribution shift, and emergent behavior are not explicitly addressed in AIR requirements.The authors describe the list as their answer to RQ2 and note those risks are typically covered by existing AI risk taxonomies.Source: §5.1 · p. 14

5.2 Implications for Research

  • The AIR/PCR/DCR classification and analysis procedure could transfer to other regulations, but AIR would need redefining for other domains.The authors identify cross-jurisdictional analysis and the Cyber Resilience Act as possible applications.Source: §5.2 · pp. 14–15
  • A formal comparison with existing AI risk taxonomies is left to future work; the list establishes a provision-traceable basis for that comparison.Without that reference point, the choice of taxonomy and matching granularity would remain arbitrary.Source: §5.2 · p. 15

5.3 Implications for Practice

  • Practitioners can use the list as a first reference for identifying AIA-mandated risks, but it is a starting point rather than a compliance checklist.Article 9 still requires providers to address known and foreseeable risks beyond those explicitly named, including risks tied to their system context and deployment environment.Source: §5.3 · p. 15

5.4 Limitations

  • The four raters’ shared professional backgrounds and institutional affiliation limit what their agreement establishes, especially for AIR, where agreement was lowest.AIR agreement was Fleiss’ κ = 0.61, with a pairwise minimum of 0.46; the authors call for studies with more varied expertise and institutional settings.Source: §5.4 · p. 15
  • The study covers Articles 9–15, does not encode relationships among risk sources of different granularity, and reflects a static reading that may change with later instruments.Other AIA provisions, including Article 5, general-purpose AI model provisions, and recitals, were excluded; the authors also say the list should be updated as standards and guidance develop.Source: §5.4 · pp. 15–16

6 Conclusion

The classification finds that most high-risk requirements emphasize governance and documentation, while 31.03% directly address AI-specific risk sources. The resulting 40-source list is a minimum inventory, version 0, that may evolve as standards and implementing acts develop.

6 Conclusion

  • 31.03% of the 87 extracted requirements directly address AI-specific risk sources, concentrated in Articles 10, 13, 14, and 15.The other requirements primarily rely on organizational governance and documentation rather than direct technical controls.Source: §6 · p. 16
  • The analysis derives 40 distinct AI-specific risk sources, grouped into data quality and management, human-AI interaction, and AI system technical risks.The EU AI Act Risk Source List is presented as a structured inventory for Articles 9–15 and a minimum set for AI risk management.Source: §6 · p. 16
  • The authors characterize the list as version 0, subject to refinement as implementing acts and harmonized standards evolve.The work reflects the status of relevant instruments as of May 2026.Source: §6 · pp. 16–17
  • Future work should extend the analysis to the full Act, validate category assignments with diverse raters, examine other regulations, and formally compare taxonomies and ontologies.The proposed comparisons include the AI Hazard List, MIT Risk Repository, AI Risk Atlas, TAIR, and AIRO.Source: §6 · p. 17
Loading 2609.13535v1…