Operationalising AI Governance in Public Administration: An Integrated Regulatory and Risk Management Framework

Abstract

Public organisations are increasingly using Artificial Intelligence (AI) and Algorithmic Decision-making Systems (ADSs), but the rules and governance requirements that apply to them remain spread across different legal and risk-management frameworks. This study analyses the European Union (EU) AI Act, the General Data Protection Regulation (GDPR), Directive (EU) 2016/680, the Organisation for Economic Co-operation and Development (OECD) AI Principles, and the National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework (AI RMF 1.0) to identify where they overlap, where they differ, and where practical implementation remains difficult. The findings are brought together into an integrated EU framework built around seven governance pillars and eight lifecycle stages, linking regulatory requirements with organisational responsibilities, human oversight, operational controls, and post-deployment monitoring. The framework is illustrated through two public-sector scenarios: social-benefit eligibility and AI-supported student assessment. The analysis shows that governing AI in EU public administration requires more than compliance with individual rules; it requires a coherent process that helps organisations decide when AI is appropriate, who is responsible, what safeguards are needed, and how systems should be reviewed over time. The framework’s organisational structure may provide a basis for adaptation to other contexts, but its legal mappings are specific to the EU instruments analysed and would require jurisdiction-specific reconstruction and validation.

1. Introduction

Artificial Intelligence (AI) and algorithmic decision-making systems (ADSs) are becoming increasingly relevant to public administration, where they can support complex decisions, process large volumes of information, and contribute to more efficient public services [1,2,3]. Their growing use, however, also changes the way administrative decisions are made and raises questions that extend beyond technical performance. When algorithmic systems influence decisions concerning individuals, issues of accountability, transparency, fairness, privacy, and the protection of fundamental rights become particularly important [4,5].

One of the main concerns is that responsibility can become difficult to locate when a decision involves multiple actors with different legal and organisational roles. Human involvement is therefore often proposed as an important safeguard, but its presence alone does not guarantee meaningful oversight. Research on algorithm-in-the-loop decision-making demonstrates that human involvement has its own limits, while studies of automation bias show that decision-makers may place excessive reliance on automated recommendations [6,7]. Evidence from public-sector decision-making further indicates that officials may both over-rely on algorithmic advice and selectively adhere to recommendations that correspond with pre-existing expectations or stereotypes [8]. Hence, meaningful oversight depends not only on the formal presence of a human decision-maker, but also on that person’s competence, authority, information, and practical ability to question or depart from the algorithmic recommendation.

A related issue is whether AI is appropriate for every type of decision. ADSs necessarily represent problems through available data and formalised criteria, while administrative decisions may also depend on contextual, qualitative, or case-specific information. Research on algorithmic reductionism and procedural justice has shown that removing human bias from a process does not necessarily make the resulting procedure fair, particularly where relevant circumstances cannot easily be reduced to measurable variables [9]. These concerns suggest that governance should begin before an AI system is procured or deployed, with consideration of whether automation is necessary, proportionate, and suitable for the particular administrative context.

Education provides a useful example of this tension. AI-supported assessment and decision-making may offer new ways of analysing learning outcomes and supporting educators, but they also raise questions concerning fairness, accountability, student autonomy, and professional judgement [10,11]. Our previous research on educational ADSs similarly identifies lifecycle responsibility, proportionality, human oversight, and feedback as important responses to these challenges [12].

At the same time, the governance environment for AI has developed considerably. In the EU, the AI Act establishes a risk-based regulatory framework that introduces obligations relating to risk management, human oversight, documentation, fundamental-rights assessment, and post-deployment monitoring. Its application calendar was subsequently amended by Regulation (EU) 2026/1744, which deferred the core high-risk obligations without altering the substantive architecture of the Act [13]. The General Data Protection Regulation (GDPR) continues to regulate personal-data processing and certain forms of automated individual decision-making, while Directive (EU) 2016/680 applies to processing by competent authorities for law-enforcement purposes [14]. These binding EU requirements sit alongside non-binding governance approaches, including the Organisation for Economic Co-operation and Development (OECD) AI Principles and the NIST AI Risk Management Framework (RMF). The OECD AI Principles provide international normative guidance, while the NIST AI RMF offers a voluntary framework for managing AI-related risks. In this study, these non-binding instruments complement, rather than replace or reinterpret, the legal obligations established by the AI Act and GDPR. Public organisations are both users of AI and actors responsible for ensuring that it is used in the public interest [15].

This regulatory fragmentation reflects a broader challenge identified in the scientific literature regarding the proliferation of AI principles. In particular, studies have demonstrated that while there is global convergence around high-level principles such as transparency, justice, and non-maleficence [16,17], organisations consistently struggle to turn these abstract guidelines into actionable governance architectures. The challenge addressed in this study is therefore no longer simply to identify the risks of algorithmic decision-making or to formulate additional ethical principles. Instead, public organisations need to understand how different legal, normative, and risk-management requirements can be brought together and translated into concrete organisational practices across the AI lifecycle. Earlier work on algorithmic accountability has similarly stressed the importance of connecting impact assessment, monitoring, human intervention, and responsibility rather than addressing them as isolated safeguards [4,18].

Recent studies have proposed complementary frameworks addressing public values, socio-technical trust, organisational readiness, institutionalisation, and regulatory integration in public-sector AI [19,20,21,22,23]. In addition, greater attention is being given to social participation in public-sector AI governance [24]. Participation by affected groups and other stakeholders has been associated with transparency, equity, the identification of algorithmic bias, and the legitimacy of AI-supported public decisions, although concrete mechanisms for incorporating such participation into administrative practice remain less developed. However, these approaches address different parts of the governance problem. More recent integrated approaches also connect regulatory and technical requirements, particularly for Generative AI [23].

Empirical research has also examined how public organisations translate AI-governance principles into organisational processes and practices. In particular, the framework proposed in [25], based on evidence from public organisations across multiple jurisdictions, highlights the importance of governance processes, organisational standards, training, and the management of outsourced AI development. At a broader level, systematic AI-governance research has shown that existing approaches can be distinguished according to who governs AI, what is governed, when governance occurs across the lifecycle, and how governance is implemented [26].

A further strand of work assesses AI governance at the level of jurisdictions rather than organisations. The Stanford HAI AI Index tracks responsible-AI practice, policy activity, and incident data across countries and firms [27], while the AI Governance InternationaL Evaluation (AGILE) Index scores national governance across four pillars, namely the AI development level, governance environment, governance instruments, and governance effectiveness [28]. These instruments are complementary rather than competing with this study, as these indices assess governance capacity at the national level, whereas this study addresses how individual public organisations can operationalise legal and governance requirements for specific AI systems. Their indicator-design logic is nevertheless directly relevant, and Section 5.1 explains how it informs the monitoring layer of the proposed framework.

Building on these complementary perspectives, the proposed framework addresses how regulatory and governance requirements can be linked to responsible actors, actions, controls, evidence, and review points throughout the lifecycle of an AI-supported administrative system.

Table 1. Criteria-based comparison with selected recent public-sector AI governance frameworks and related approaches. Criteria C1–C6 were defined before the comparison and applied identically to every entry.

Framework/Study	Core Approach	C1: Instruments Operationalised	C2: Lifecycle	C3: Actors	C4: Evidence	C5: Norm. Status	C6: Auditable Deriv.
Mišić et al. (2025) [20]	Seven public values: responsiveness, effectiveness, procedural justice, resilience, counterbalance, wellbeing, and social justice	None explicitly	No	Partial	No	No	No
Tsarouhas and Grigoriadis (2026) [19]	Transparency, XAI, participatory governance, and digital literacy as determinants of public trust	Referenced, not mapped	Partial	Partial	No	No	No
Babšek et al. (2025) [22]	Organisational readiness: processes, technology, people, services, infrastructure, strategy, citizens, and open government	Compliance treated as a readiness condition	No	Partial	Partial	No	Partial
Kim (2026) [21]	Regulative, normative, and cognitive conditions for institutionalisation, including SOPs, leadership, training, and accountability	None explicitly	No	Partial	No	No	Partial
Riccio (2025) [23]	Strategic governance, risk assessment, cybersecurity, training, and human oversight for Generative AI	AI Act, GDPR, NIST AI RMF, ISO/IEC 42001	Partial	Yes	Partial	No	No
de Almeida and dos Santos Júnior (2025) [25]	Empirically grounded governance processes, organisational standards, training, and management of outsourced development	Not centred on EU regulatory integration	Partial	Yes	Partial	No	Yes
Stanford HAI AI Index [27]	Jurisdiction- and firm-level indicators of responsible-AI practice, policy activity, and incidents	Descriptive; not operationalised	No	No	No	No	Yes
AGILE Index 2025 [28]	National governance scored across four pillars, 17 dimensions, and 43 indicators covering 40 countries	Descriptive; not operationalised	No	No	No	No	Yes
Proposed Framework	Seven governance pillars × eight lifecycle stages linked to actors, controls, evidence, and review points	AI Act, GDPR, Directive (EU) 2016/680, OECD AI Principles, and NIST AI RMF	Yes	Yes	Yes	Yes	Yes

Note: “Yes” indicates explicit and systematic coverage; “Partial” indicates incomplete or implicit coverage; and “No” indicates that the criterion is not addressed. C1 = instruments; C2 = lifecycle; C3 = actors; C4 = implementation evidence; C5 = normative status; C6 = auditable derivation. Stanford HAI and AGILE operate at the jurisdictional rather than system level and are included as complementary approaches.

compares existing frameworks with the proposed one against six predefined criteria, applied identically to every entry: (C1) the regulatory instruments explicitly operationalised; (C2) whether an explicit lifecycle structure with defined stages is provided; (C3) whether governance activities are allocated to identifiable actors; (C4) whether specific implementation evidence is named for each control; (C5) whether the normative status of each control is distinguished; and (C6) whether the derivation of the framework is independently auditable through a published evidence base. These criteria were fixed before the comparison was carried out and correspond to the traceability chain the framework claims to establish.

The five instruments were selected purposively to capture complementary legal, normative, and operational dimensions of public-sector AI governance. Section 3.2 provides the inclusion and exclusion criteria, source versions and dates, and the rationale for excluding other candidate instruments, including ISO/IEC 42001 and the Council of Europe Framework Convention.

The resulting framework is designed specifically for public administration operating within the EU legal context, where AI governance must address not only organisational risk but also public authority, public value, administrative responsibility, fundamental rights, and safeguards for affected individuals. More specifically, the study addresses the following research questions.

RQ1:

Where do the selected regulatory and governance instruments converge, diverge, or leave operational gaps?

RQ2:

How can their requirements be integrated into a lifecycle-based governance framework for public organisations, and can that integration be traced back to its sources?

RQ3:

How does the integrated framework apply to representative public-sector algorithmic decision scenarios?

Given the aforementioned, the contribution of the study is fourfold. First, it brings together binding and non-binding regulatory and governance instruments that are usually considered separately, using a documented and reproducible coding procedure. Second, it translates their requirements into a lifecycle-based framework that identifies not only what should be governed, but also when governance action is needed, who is responsible and must act, which evidence can demonstrate that the required action has occurred, and what normative weight each control carries. Third, it releases the complete evidence matrix and codebook as Appendix A, so that every element of the framework can be traced to an identified provision and every consolidation decision can be inspected and contested. Fourth, the framework is applied through a complete eight-stage worked example of social-benefit eligibility determination, together with a contrasting scenario on AI-supported student assessment, illustrating how the same governance structure yields different priorities across public-sector decision contexts.

The framework is intended to support governance and compliance work. It does not constitute legal advice and does not replace case-specific legal analysis, conformity assessment under the AI Act, a Data Protection Impact Assessment (DPIA), a Fundamental Rights Impact Assessment (FRIA), procurement review, or applicable sector-specific and national administrative-law requirements. Where a control is proposed by the authors rather than derived from a legal obligation, it is identified as such and must not be treated as evidence of compliance.

The remainder of the paper is organised as follows. Section 2 reviews the regulatory and governance instruments considered in the analysis. Section 3 describes the research method and framework-development process. Section 4 presents the comparative findings, the integrated framework, and its illustrative application. Section 5 discusses the implications and limitations of the study, and finally Section 6 concludes the paper.

2. Legislative, Regulatory, and Governance Frameworks

Next, the regulatory and governance instruments that feed into the current analysis and the proposed framework are reviewed.

2.1. The EU Artificial Intelligence Act

Regulation (EU) 2024/1689, the AI Act, establishes a horizontal, risk-tiered regulatory framework under which regulatory obligations vary according to an AI system’s intended purpose, context of use, and potential impact. It presents different levels of risk, ranging from prohibited practices and high-risk systems to systems subject to specific transparency obligations and lower-risk applications. Within this architecture, the classification of high-risk AI systems is particularly important for public administration because it determines whether the more extensive requirements of Chapter III of the Regulation apply [29].

Specifically, Article 6 establishes two principal routes to high-risk classification: (a) when an AI system is intended to be used as a safety component of a product, or constitutes a product itself, covered by the Union harmonisation legislation listed in Annex I, provided that the relevant product is subject to third-party conformity assessment (Article 6(1)); and (b) when an AI system falls within the use cases listed in Annex III of the regulatory framework (Article 6(2)). The latter is particularly relevant to public administration, covering areas such as education, employment, access to essential services and benefits, law enforcement, migration and border management, and the administration of justice and democratic processes [29].

Article 6(3) provides a limited derogation for certain Annex III systems that do not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing decision-making, and satisfy at least one of the conditions specified in the Regulation. The derogation does not apply to systems that perform profiling. Providers relying on it must document their assessment (Article 6(4)), while the applicable registration requirement remains in place under Regulation (EU) 2026/1744 [13]. The derogation therefore does not remove the associated assessment, documentation, and registration duties.

In addition, for high-risk systems, Article 9 requires a continuous and iterative risk-management process throughout the lifecycle, while Article 14 establishes requirements for effective human oversight proportionate to the risks, level of autonomy, and context of use, including measures directed at automation bias. Article 13, by contrast, does not concern notices to affected persons. It obliges providers to design high-risk systems so that their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately, and to accompany the system with instructions for use. The duties owed to individuals affected by a decision arise elsewhere, and conflating the two provisions understates both. This distinction is applied consistently in the crosswalk presented in Section 4.1.

Four further provisions are particularly relevant to public administration. Article 26 sets out deployer obligations concerning appropriate use, human oversight, input data, operational monitoring, incident reporting, logging, and information to workers. Importantly for administrative decision-making, Article 26(11) requires deployers of relevant Annex III high-risk systems that make or assist in making decisions concerning natural persons to inform affected persons that they are subject to the use of such a system.

Article 27 requires specified public-sector and public-service deployers to conduct a Fundamental Rights Impact Assessment (FRIA) before first use. The obligation does not extend to systems under Annex III point 2 (critical infrastructure). The deployer must notify the market surveillance authority of the assessment results (Article 27(3)), while elements already addressed through a GDPR Data Protection Impact Assessment (DPIA) need not be duplicated. Regulation (EU) 2026/1744 further clarified that the two assessments may cross-reference each other [13]. The remaining challenge is therefore primarily one of organisational coordination and sequencing.

Article 49(3) imposes a registration duty that applies specifically to the public sector. Before putting into service or using a high-risk AI system listed in Annex III, with the exception of systems listed in Annex III point 2, deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, must register themselves, select the system, and register its use in the EU database. Public authorities that procure rather than develop AI systems are therefore subject to an affirmative registration obligation independent of the provider’s own registration under Article 49(1).

Articles 85 and 86, on the other hand, establish the remedies available to affected individuals. Article 85 confers a right to lodge a complaint with the relevant market surveillance authority. Article 86 confers a right to explanation of individual decision-making, i.e., any affected person subject to a decision taken by a deployer on the basis of the output of an Annex III high-risk system (other than those listed under point 2) which produces legal effects or similarly significantly affects their health, safety, or fundamental rights has the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision taken. Article 86 is therefore particularly relevant to the framework’s transparency and contestability pillar.

The AI Act establishes a three tier penalty regime, although its application to public authorities and bodies is partly determined by Member State law (Article 99). Union institutions, bodies, offices, and agencies are subject to a separate regime under Article 100, enforced by the European Data Protection Supervisor. Public-sector enforcement exposure therefore depends on the institutional context and applicable national law and cannot be stated as a single figure.

The application timeline for high-risk provisions was amended by Regulation (EU) 2026/1744, which applies Sections 1–3 of Chapter III from 2 December 2027 to systems classified under Article 6(2) and Annex III, and from 2 August 2028 to systems classified under Article 6(1) and Annex I [13]. Obligations already applicable were not deferred, including the Article 5 prohibitions and Article 4 AI literacy duty, which have applied since 2 February 2025, and the Article 50 transparency obligations, applicable from 2 August 2026.

Article 111 also establishes transitional arrangements for legacy systems. Large-scale IT systems covered by Annex X must comply by 31 December 2030 (Article 111(1)), while providers and deployers of high-risk systems intended for use by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)). During the transitional period, applicable obligations under the GDPR, Directive (EU) 2016/680, and national administrative law continue to apply. Legacy systems therefore remain a governance concern even where Chapter III obligations are not yet applicable.

2.2. GDPR and Automated Decision-Making

Regulation of ADSs in the EU predates the AI Act and remains concurrently governed by the GDPR whenever personal data are processed. Article 22 of GDPR provides data subjects with the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects or similarly significantly affects them. Subject to the exceptions provided in Article 22(2), relevant safeguards include the right to obtain human intervention, express one’s point of view, and contest the decision [30,31].

Two judgments of the Court of Justice of the EU materially shape how Article 22 applies to public-sector ADSs and are incorporated into the analysis. In SCHUFA Holding (Case C-634/21, 7 December 2023), the Court held that the automated establishment of a probability value concerning a person’s ability to meet future payment commitments constitutes a “decision” within the meaning of Article 22(1) where a third party draws strongly on that value in deciding whether to establish, implement, or terminate a contractual relationship [32]. The reasoning transfers directly to administrative practice. Where a scoring or triage component is generated by one body and relied upon decisively by another, the safeguards of Article 22 may attach to the upstream scoring operation and not only to the formal administrative act. In CK v Dun and Bradstreet Austria (Case C-203/22, 27 February 2025), the Court held that “meaningful information about the logic involved” under Article 15(1)(h) requires an explanation of the procedure and principles actually applied in the individual case, in a concise, transparent, intelligible, and easily accessible form, and that neither the disclosure of the algorithm nor a description of every step of the process satisfies the requirement; where the controller considers the information to be a trade secret, it must supply it to the competent supervisory authority or court for balancing rather than refuse disclosure outright [33]. The judgment establishes an explanation standard that is functional rather than technical, and it is this standard, not a generic notion of explainability, that the transparency pillar of the framework operationalises.

In Ligue des droits humains (Case C-817/19, 21 June 2022), the Court emphasised the need for individual, non-automated review before adverse measures are taken following automated processing [34]. This supports the framework’s treatment of human oversight, elaborated in Pillar 5, as substantive rather than merely confirmatory.

The GDPR also contributes a preventive risk-management mechanism through DPIA required under Article 35 where processing is likely to result in a high risk to individuals’ rights and freedoms. For public-sector AI systems, a DPIA may therefore operate alongside the FRIA required by the AI Act. Article 83 permits Member States to determine the extent to which administrative fines apply to public authorities, while Article 38(3) protects the independence of the Data Protection Officer (DPO). This constraint is preserved explicitly in the responsibility model presented in Section 4.2.6.

Accordingly, references to the GDPR and Directive (EU) 2016/680 within the integrated framework do not imply their cumulative application to the same processing operation. The applicable data-protection regime depends on the actor, purpose, and material scope of the processing.

2.3. Directive (EU) 2016/680 and Law-Enforcement Processing

A substantial part of public administration, policing, criminal justice, and elements of migration and border management, falls outside the material scope of the GDPR and within that of Directive (EU) 2016/680, the Law Enforcement Directive (LED), where personal data are processed by competent authorities for the purposes of the prevention, investigation, detection, or prosecution of criminal offences or the execution of criminal penalties [14]. Its omission from many AI-governance frameworks is consequential, because the safeguards differ from those of the GDPR in ways that affect system design.

Article 11 LED prohibits decisions based solely on automated processing (including profiling), which produce an adverse legal effect concerning the data subject or significantly affect them, unless authorised by Union or Member State law providing appropriate safeguards for the rights and freedoms of the data subject, including at least the right to obtain human intervention. Profiling that results in discrimination against natural persons on the basis of special categories of personal data is prohibited outright. Article 27 requires a data protection impact assessment for processing likely to result in a high risk, and Article 25 imposes specific logging obligations for collection, alteration, consultation, disclosure, combination, and erasure in automated processing systems, an obligation that interacts directly with the record-keeping requirements of Article 26(6) of the AI Act. Articles 52–54 establish the corresponding remedies. Because the LED is a directive rather than a regulation, the applicable safeguards are determined by national transposing law, so the framework treats LED-derived controls as conditionally binding and jurisdiction-dependent rather than as uniform EU requirements.

2.4. OECD AI Principles and the Council of Europe Framework Convention

The OECD AI Principles, originally adopted in 2019 and updated thereafter, emphasise inclusive growth, human-centred values and fairness, transparency and explainability, robustness, security and safety, as well as accountability. They also promote lifecycle-based risk management and traceability, making them particularly relevant to the governance of AI systems used by public institutions [35]. They are a recommendation of the OECD Council and are not legally binding on adherents; they operate through political commitment and national implementation.

The Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law (CETS No. 225) was opened for signature on 5 September 2024 and is the first international treaty specifically addressing AI. Its legal status requires careful qualification, and the earlier description of it as generally binding was imprecise. The Convention is binding only on those States and organisations that have consented to be bound and only once it has entered into force in accordance with its own terms, which require a specified number of ratifications, including ratifications by Council of Europe member States. Signature alone creates no substantive obligation beyond the duty not to defeat the object and purpose of the treaty. Moreover, the Convention is a framework instrument in that it sets objectives and requires Parties to adopt or maintain appropriate measures, leaving the choice of means to each Party, and permitting Parties to address private-sector activities differently from public-sector activities. For EU Member States, obligations under the Convention are in any event mediated by Union law, which governs the matters falling within Union competence. Accordingly, the Convention is used in this study as a supplementary human-rights reference for interpretive purposes only. It is not treated as a source of directly applicable obligations, it is not included as a coded instrument in the comparative corpus, and no control in the framework is derived from it alone [36].

2.5. NIST AI Risk Management Framework

The NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0) provides a voluntary, rights-preserving, non-sector-specific, and use-case-agnostic approach for managing risks associated with the design, development, deployment, and use of AI systems. Its purpose is to help organisations incorporate considerations of trustworthiness into AI risk-management practices throughout the system lifecycle [37]. Its core is organised around four functions—Govern, Map, Measure, and Manage—that structure risk identification, assessment, mitigation, and monitoring across the AI lifecycle [37]. For public administration, the AI RMF is particularly useful as an operational complement to binding legal requirements. Because it is voluntary in every jurisdiction, including the United States, every control derived from it is classified as voluntary in the crosswalk, and no NIST-derived control is presented as satisfying a legal obligation.

2.6. Management-System Standards and Index-Based Assessment

Two further categories of instruments were considered and deliberately excluded from the coded corpus.

ISO/IEC 42001:2023 [38] specifies requirements for an AI management system and is closely related to the governance problem addressed here. It was excluded from the coded comparison for three reasons. First, the unit of analysis differs, as ISO/IEC 42001 specifies management-system requirements at the organisational level (policy, objectives, competence, internal audit, management review) and largely presupposes rather than specifies the substantive controls attaching to an individual high-risk system, which is the level at which the present framework operates. Second, the standard is copyright-protected and available only under licence, which prevents the publication of provision-level extracts in an open supplementary evidence matrix and would therefore defeat the auditability the study claims. Third, its structure is deliberately requirement-neutral with respect to jurisdiction, so coding it alongside the AI Act would have required interpretive mapping of a kind the coding rules were designed to exclude. The relationship is nevertheless complementary and is set out in Section 5.1. As such, the Plan–Do–Check–Act cycle of ISO/IEC 42001 corresponds to the governance layer within which the eight lifecycle stages operate, and an organisation certified to ISO/IEC 42001 would already have management-system structures relevant to Pillars 6 and 7.

Index-based assessment instruments were also excluded, but for a different reason. The Stanford HAI AI Index [27] and the AGILE Index [28] measure governance at jurisdictional and, in the former case, firm level. They are descriptive and comparative rather than prescriptive, and they do not generate obligations or controls that could be assigned to a lifecycle stage. They are therefore not sources of requirements. Their methodological contribution to this study is discussed separately in Section 5.1.

3. Materials and Methods

The current section outlines the methodological steps undertaken during framework development, focusing on the various research materials, methods and tools used.

3.1. Research Design

This study combines comparative regulatory analysis with framework development and scenario-based application. The design is qualitative and document-based. It proceeds in four phases, each mapped to a research question: (i) construction of a source corpus and provision-level extraction; (ii) coding of extracted provisions against governance themes, lifecycle stages, actors, controls, and evidence, answering RQ1; (iii) consolidation of themes into pillars and integration with the lifecycle, answering RQ2; and (iv) application of the resulting framework to public-sector scenarios, answering RQ3. Each phase is specified below in sufficient detail to be repeated by an independent analyst, and the complete outputs of phases (i) and (ii) are released as

Table A1. Evidence matrix: complete set of coded regulatory and governance records.

ID	Source	Provision	Duty/Principle (Close Paraphrase)	Normative Status	Governance Objective	Preliminary Theme	Integrated Pillar(s)	Lifecycle Stage(s)	Primary Responsible Actor	Proposed Operational Control	Expected Implementation Evidence	Rationale for Mapping
AIA-001	AI Act	Art. 4	Providers and deployers take measures to ensure a sufficient level of AI literacy among staff dealing with operation and use.	B	Organisatio-nal competence to operate AI responsibly	Organisatio-nal capacity and competence	P6	3, 6	Leadership; AI governance function	Role-based AI literacy programme covering system limitations and override authority	Training curriculum; attendance and competence records by role	Applicable since 2 February 2025 and not deferred by Reg. 2026/1744; addressed to deployers, hence organisational rather than technical.
AIA-002	AI Act	Art. 5	Prohibition of specified AI practices, including social scoring by or on behalf of public authorities.	B	Boundary of legitimate automation	Legal authority and enforceability	P1	1, 2	Legal function	Prohibited-practice screening completed before any development or procurement decision	Screening record with reasoned conclusion	Applies irrespective of classification; screening must precede Stage 2 because a prohibited use cannot be remediated by later controls.
AIA-003	AI Act	Art. 6(1)	High-risk classification where the system is a safety component of, or is itself, a product covered by Annex I harmonisation legislation subject to third-party conformity assessment.	C	Determination of applicable regime	Risk classification and lifecycle management	P2	2	Legal function	Classification determination recorded with reasons	Classification record	Conditional on product scope; obligations apply from 2 August 2028 per Reg. 2026/1744.
AIA-004	AI Act	Art. 6(2)	High-risk classification for systems falling within the Annex III use cases.	C	Determination of applicable regime	Risk classification and lifecycle management	P2	2	Legal function	Annex III mapping recorded against the specific point and sub-point	Classification record identifying the Annex III point relied upon	Principal route for public administration; obligations apply from 2 December 2027.
AIA-005	AI Act	Art. 6(3)	Derogation where the system poses no significant risk of harm, including by not materially influencing the outcome, and meets one of four conditions; never available where the system performs profiling of natural persons.	C	Proportionate scoping of the high-risk regime	Risk classification and lifecycle management	P2	2	Legal function	Derogation assessment addressing each of the four conditions and the profiling carve-out separately	Reasoned derogation assessment	Coded separately from Art. 6(2) because the conditions and the absolute carve-out generate a distinct assessment duty.
AIA-006	AI Act	Art. 6(4)	Provider relying on Art. 6(3) documents its assessment before placing on the market or putting into service; registration obligations are retained.	C	Auditability of a claimed exemption	Risk classification and lifecycle management	P2	2	Provider; authority where it acts as provider	Retention of the provider’s Art. 6(4) documentation as a procurement deliverable	Provider assessment document; EU database registration confirmation	Reg. 2026/1744 deleted only Annex VIII Section B points 7 and 9 and expressly retained registration after an Art. 6(3) assessment.
AIA-007	AI Act	Art. 9	Establishment, implementation, documentation and maintenance of a continuous, iterative risk-management system across the lifecycle.	C	Continuous risk management	Risk classification and lifecycle management	P2	2–8	AI governance function	Risk register maintained across the lifecycle with defined review triggers	Risk register; review records	Iterative by its terms, hence mapped to all stages from classification onward rather than to a single stage.
AIA-008	AI Act	Art. 10	Training, validation and testing data subject to data-governance and management practices appropriate to the intended purpose.	C	Quality of the evidential basis	Data governance and privacy	P3	4	Technical team; provider	Data documentation covering provenance, preparation, assumptions, and examination for bias	Data documentation; bias examination record	Addressed primarily to providers; the deployer’s corresponding duty is Art. 26(4), coded separately.
AIA-009	AI Act	Art. 11 and Annex IV	Technical documentation drawn up before placing on the market and kept up to date.	C	Auditability of the system	Risk classification and lifecycle management	P2, P6	3, 6	Provider; procurement	Contractual requirement to supply and maintain Annex IV documentation	Documentation package; version history	Coded to procurement because for a deploying authority the duty is discharged through contract.
AIA-010	AI Act	Art. 12	Automatic recording of events (logs) over the lifetime of the system.	C	Traceability of operation	Monitoring and assurance	P3, P7	6, 8	Provider; technical team	Logging specification validated at acceptance testing	Log schema; acceptance test evidence	Distinguished from Art. 26(6), which places the retention duty on the deployer.
AIA-011	AI Act	Art. 13	Providers design high-risk systems so that operation is sufficiently transparent to enable deployers to interpret and use the output appropriately, accompanied by instructions for use.	C	Provider-to-deployer transparency	Transparency and explainability	P4, P6	3, 6	Provider; procurement	Procurement condition requiring instructions for use and interpretability sufficient for the intended oversight role	Instructions for use; acceptance record confirming sufficiency	CORRECTION: Art. 13 concerns information to deployers, not notices to affected persons. Duties owed to individuals are coded at Arts. 26(11), 50, 85 and 86.
AIA-012	AI Act	Art. 14	High-risk systems designed and developed so that they can be effectively overseen by natural persons, including measures addressing automation bias.	C	Design for effective oversight	Human oversight	P5	3, 6	Provider; technical team	Oversight requirements specified at procurement and verified at acceptance testing	Oversight design specification; acceptance test evidence	Design-side duty; the organisational counterpart is Art. 26(2).
AIA-013	AI Act	Art. 15	Appropriate levels of accuracy, robustness and cybersecurity, consistent throughout the lifecycle.	C	Technical reliability	Robustness and security	P3	6, 8	Technical team; information security	Acceptance thresholds for accuracy and robustness; security testing before approval	Test reports; penetration test results	Mapped to Stage 6 for verification and Stage 8 for maintenance over time.
AIA-014	AI Act	Art. 25	Distributors, importers, deployers or third parties are considered providers where they put a system into service under their own name or make a substantial modification.	C	Correct attribution of statutory role	Accountability and organisational roles	P1, P5	2, 3, 8	Legal function	Role reassessment triggered by any model modification or rebranding	Classification record entry; change-control record	Critical for public authorities that fine-tune or rebrand procured systems; coded to Stage 8 because the trigger recurs.
AIA-015	AI Act	Art. 26(1)	Deployers take appropriate technical and organisational measures to ensure use in accordance with the instructions for use.	C	Use within the validated envelope	Accountability and organisational roles	P5, P6	6, 7	Operational owner	Operating procedure aligned to the instructions for use; deviation escalation route	Operating procedure; deviation log	Primary deployer duty; anchors the operational procedures of Stage 7.
AIA-016	AI Act	Art. 26(2)	Deployers assign human oversight to natural persons with the necessary competence, training and authority, and provide the necessary support.	C	Meaningful human control	Human oversight; accountability and organisational roles	P5, P6	6, 7	Leadership; operational owner	Named designation of oversight personnel with recorded training and delegated authority to override	Designation record; training record; delegation of authority	Converts oversight from a system property into an organisational allocation; principal justification for consolidating oversight with accountability into P5.
AIA-017	AI Act	Art. 26(4)	Deployers ensure input data are relevant and sufficiently representative in view of the intended purpose, to the extent they exercise control over input data.	C	Quality of inputs under deployer control	Data governance and privacy	P3	4, 8	Data owner; technical team	Input-data quality and representativeness checks on the data the authority controls	Input-data control record; representativeness assessment	Distinguished from Art. 10, which addresses the provider’s training data.
AIA-018	AI Act	Art. 26(5)	Deployers monitor operation, inform the provider and relevant authorities where a risk is identified, and report serious incidents.	C	Post-deployment risk detection	Monitoring and assurance	P7	8	AI governance function; operational owner	Monitoring plan with defined escalation and notification routes and timescales	Monitoring reports; incident register; notification records	Directly supports the closure of the monitoring-to-action loop identified as an operational gap.
AIA-019	AI Act	Art. 26(6)	Deployers keep automatically generated logs for a period appropriate to the intended purpose and of at least six months, subject to applicable law.	C	Evidential retention	Monitoring and assurance	P7	8	Operational owner; information security	Log retention schedule reconciled with data-protection retention limits	Retention schedule; retention audit	Coded separately from Art. 12 because the duty holder and the action differ.
AIA-020	AI Act	Art. 26(7)	Before putting a high-risk system into service at the workplace, deployers who are employers inform workers’ representatives and affected workers.	C	Workforce information	Transparency and explainability; organisational capacity and competence	P4, P6	6	Leadership; HR function	Consultation and information step included in the deployment authorisation checklist	Consultation record	Relevant where officials themselves are the affected workers; frequently omitted from public-sector frameworks.
AIA-021	AI Act	Art. 26(9)	Deployers use the information provided under Art. 13 to comply with their obligation to carry out a DPIA where applicable.	C	Coordination of assessments	Risk classification and lifecycle management	P2	5	DPO (advisory); AI governance function	DPIA drawing expressly on the provider documentation supplied under Art. 13	DPIA referencing the provider documentation	Establishes the statutory link between provider documentation and the deployer’s DPIA.
AIA-022	AI Act	Art. 26(11)	Deployers of Annex III high-risk systems that make or assist in making decisions concerning natural persons inform those persons that they are subject to the use of such a system.	C	Notice to affected persons	Transparency and explainability	P4	7	Operational owner; public officials	Standard notice issued at the point of application and repeated with the decision	Notice text and version; issuance record	This, not Art. 13, is the deployer’s notice duty towards individuals.
AIA-023	AI Act	Art. 27(1)–(2)	Deployers that are bodies governed by public law, or private entities providing public services, carry out a FRIA before first use, covering processes, period and frequency of use, categories of persons affected, specific risks of harm, human-oversight measures, and measures where risks materialise.	C	Ex ante fundamental-rights assessment	Risk classification and lifecycle management	P2	5	AI governance function	FRIA conducted to the Art. 27(1) element list, cross-referencing the DPIA where elements are already met	FRIA record	Scope excludes Annex III point 2; Reg. 2026/1744 expressly permits cross-reference to the DPIA.
AIA-024	AI Act	Art. 27(3)	Deployers notify the market surveillance authority of the results of the FRIA, submitting the completed template.	C	External accountability for the assessment	Risk classification and lifecycle management; monitoring and assurance	P2, P7	5	AI governance function; Legal	Notification step included in the Stage 5 exit criteria	Notification record and acknowledgement	Frequently omitted; makes the FRIA an externally facing instrument rather than an internal document.
AIA-025	AI Act	Art. 49(1)–(2)	Provider registration in the EU database, including registration following an Art. 6(3) assessment.	C	Public transparency of deployed systems	Legal authority and enforceability	P1, P2	2, 6	Provider; procurement	Verification of provider registration as a procurement acceptance condition	Registration confirmation from the provider	Retained by Reg. 2026/1744.
AIA-026	AI Act	Art. 49(3)	Deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, register themselves, select the system, and register its use in the EU database before putting into service or using an Annex III high-risk system, except a system listed in Annex III point 2.	C	Public transparency of public-sector use	Legal authority and enforceability	P1, P2	2, 6	AI governance function; Legal	Registration of use completed before deployment authorisation is granted	EU database registration confirmation	Public-sector specific and independent of provider registration; omitted from most existing crosswalks.
AIA-027	AI Act	Art. 50	Transparency obligations for specified system types, including interaction disclosure and marking of synthetic content.	C	System-type transparency	Transparency and explainability	P4	6, 7	Operational owner	Disclosure and content-marking configuration verified at acceptance	Configuration record; sample outputs	Applies irrespective of high-risk status; applicable from 2 August 2026 subject to the Art. 111(4) transitional for Art. 50(2).
AIA-028	AI Act	Art. 72	Providers establish and document a post-market monitoring system proportionate to the nature of the technologies and risks.	C	Post-market surveillance	Monitoring and assurance	P7	8	Provider; AI governance function	Contractual right to receive post-market monitoring outputs relevant to the deployment	Provider monitoring reports	Provider duty; coded because the deployer must contract for access to its outputs.
AIA-029	AI Act	Art. 85	Any natural or legal person may lodge a complaint with the relevant market surveillance authority.	B	External remedy	Contestability and feedback	P4	7, 8	Legal function	Complaint route stated in the notice and in the decision	Notice text; complaint register	Applies generally rather than conditionally on classification.
AIA-030	AI Act	Art. 86	Affected persons subject to a decision taken on the basis of the output of an Annex III high-risk system (other than point 2) producing legal effects or similarly significantly affecting health, safety or fundamental rights have the right to obtain from the deployer clear and meaningful explanations of the role of the system in the decision procedure and the main elements of the decision.	C	Individual explanation	Transparency and explainability; contestability and feedback	P4	7	Public officials; operational owner	Reason template stating the role of the system and the factors operating in the individual case	Reasoned decision; explanation issued on request with response time	Principal legal anchor for P4; absent from the earlier crosswalk. Consolidates transparency with contestability because the explanation exists to enable challenge.
AIA-031	AI Act	Art. 99(1), (3)–(5)	Three-tier administrative fines: up to EUR 35M or 7% (Art. 5 breaches); EUR 15M or 3% (other obligations); EUR 7.5M or 1% (incorrect information). Member States determine the extent to which fines apply to public authorities.	B	Enforcement exposure	Legal authority and enforceability	P1	2	Legal function	Enforcement exposure recorded in the classification record by reference to national law	Classification record entry	CORRECTION: the regime is three-tier, not single-tier, and its application to public bodies is set nationally under Art. 99(1).
AIA-032	AI Act	Art. 100	Fines on Union institutions, bodies, offices and agencies imposed by the EDPS, up to EUR 1.5M and EUR 750,000.	B	Enforcement exposure (Union bodies)	Legal authority and enforceability	P1	2	Legal function	Applicable only where the deployer is a Union body	Classification record entry	Coded for completeness; not applicable to national or municipal authorities.
AIA-033	AI Act	Art. 111(1)	AI systems that are components of the Annex X large-scale IT systems placed on the market or put into service before 2 August 2027 are brought into compliance by 31 December 2030.	B	Transitional governance of legacy systems	Risk classification and lifecycle management	P2	2, 8	Legal function; AI governance function	Legacy inventory identifying Annex X components and their compliance path	Legacy system inventory; compliance plan	Directly relevant to migration, asylum and border authorities; omitted from the earlier analysis.
AIA-034	AI Act	Art. 111(2)	The Regulation applies to operators of other pre-existing high-risk systems only on significant change in design; providers and deployers of high-risk systems intended for use by public authorities must comply by 2 August 2030.	B	Transitional governance of legacy systems	Risk classification and lifecycle management	P2	2, 8	AI governance function	Monitored position on significant change, with interim safeguards under P4 and P5 maintained throughout	Legacy classification record; change-control log	Public-sector specific longstop retained by Reg. 2026/1744, which replaced the fixed cut-off with one tied to Art. 113.
AIA-035	AI Act	Art. 113 (as amended)	Application dates: Sections 1–3 of Chapter III apply from 2 December 2027 (Art. 6(2)/Annex III) and 2 August 2028 (Art. 6(1)/Annex I).	B	Temporal scope of obligations	Legal authority and enforceability	P1, P2	2	Legal function	Applicable-date statement recorded for every conditionally binding control	Classification record entry	Basis for the C classification of Chapter III controls throughout the matrix.
GDPR-036	GDPR	Art. 5	Principles relating to processing: lawfulness, fairness and transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity and confidentiality, accountability.	B	Lawful and fair processing	Ethical foundations; data governance and privacy	P1, P3	1, 4	Controller; DPO (advisory)	Processing design tested against each principle and documented	Processing record; DPIA section	Accountability under Art. 5(2) underpins the evidence orientation of the whole framework.
GDPR-037	GDPR	Art. 6	Lawfulness of processing; for public authorities typically Art. 6(1)(e) with a basis in Union or Member State law.	B	Legal basis	Legal authority and enforceability	P1	2, 4	Legal function; controller	Legal basis identified and recorded, with the national provision cited	Classification record; processing record	Coded to Stage 2 for determination and Stage 4 for implementation.
GDPR-038	GDPR	Art. 9	Prohibition on processing special categories of personal data subject to specified conditions.	C	Heightened protection	Data governance and privacy	P3	2, 4	DPO (advisory); Legal	Condition identified where special-category data are processed; additional safeguards recorded	DPIA section; safeguards record	Conditional on the data actually processed; frequently engaged in benefit and health-adjacent use cases.
GDPR-039	GDPR	Arts. 13–14	Information to be provided to data subjects, including the existence of automated decision-making and meaningful information about the logic involved.	B	Ex ante transparency	Transparency and explainability	P4	7	Controller; operational owner	Privacy notice covering the AI element, issued at collection	Notice text and version	Distinguished from Art. 26(11) AI Act, which is a separate and cumulative duty.
GDPR-040	GDPR	Art. 15(1)(h)	Right of access to information on the existence of automated decision-making, including profiling, referred to in Art. 22(1) and (4), including meaningful information about the logic involved and the significance and envisaged consequences of such processing.	C	Individual explanation	Transparency and explainability	P4	7	Controller; public officials	Where Art. 22(1) or (4) is engaged, provide meaningful information concerning the procedure and principles applied in the automated processing in an intelligible form.	Explanation issued; response time	Conditionally applicable in the context of automated decision-making referred to in Art. 22(1) and (4). Dun & Bradstreet (C-203/22) clarifies that meaningful information must enable the data subject to understand and challenge the automated decision, without requiring disclosure of the algorithm itself.
GDPR-041	GDPR	Art. 22	Right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects, subject to exceptions and safeguards including human intervention, expression of view, and contestation.	C	Safeguards for automated decisions	Human oversight; contestability and feedback	P4, P5	2, 7	Controller; public officials	Design ensuring substantive human involvement, with the assumption monitored rather than assumed	Override log; reconsideration records	Conditional on the decision being solely automated. SCHUFA (C-634/21) extends Art. 22(1) to upstream scoring drawn on strongly by a third party.
GDPR-042	GDPR	Art. 24 and Art. 32	Controller implements appropriate technical and organisational measures, including security of processing.	B	Organisational and technical assurance	Data governance and privacy	P3, P6	4, 6	Information security; controller	Security control set mapped to the system and tested before approval	Security assessment; test evidence	Provides the GDPR-side anchor for the security element of P3.
GDPR-043	GDPR	Art. 25	Data protection by design and by default.	B	Preventive design	Data governance and privacy	P3	3, 4	Technical team; DPO (advisory)	Design requirements derived from the DPIA and embedded in the procurement specification	Requirements specification; design record	Coded to Stage 3 because for a procuring authority the design lever is contractual.
GDPR-044	GDPR	Art. 30	Records of processing activities.	B	Auditability of processing	Monitoring and assurance	P7	4, 8	Controller; DPO (advisory)	Processing record maintained and reconciled with the AI system inventory	Record of processing activities	Reconciliation with the AI inventory is author-proposed; the record itself is binding.
GDPR-045	GDPR	Art. 35	DPIA where processing is likely to result in a high risk, in particular for systematic and extensive automated evaluation producing legal or similarly significant effects.	C	Ex ante risk assessment	Risk classification and lifecycle management	P2	5	Controller; DPO (advisory)	DPIA performed before processing, sequenced ahead of the FRIA	DPIA record	Conditional on the risk threshold. Distinct from the FRIA in object and in risk addressed; see the coordination table in the manuscript.
GDPR-046	GDPR	Art. 36	Prior consultation of the supervisory authority where the DPIA indicates high residual risk.	C	External check on residual risk	Risk classification and lifecycle management	P2	5	DPO (advisory); Legal	Consultation trigger defined in the residual-risk acceptance procedure	Consultation record	Coded because residual-risk acceptance at Stage 6 must test this trigger.
GDPR-047	GDPR	Art. 38(3)	The DPO receives no instructions regarding the exercise of tasks, is not dismissed or penalised for performing them, and reports to the highest management level.	B	Independence of the monitoring function	Accountability and organisational roles	P5, P6	Cross-cutting	Leadership	DPO recorded as Consulted and never Accountable in the RACI; dissent recorded and retained	RACI; dissent record	CORRECTION: the DPO must not be merged with general legal or compliance responsibility. Constrains the responsibility model throughout.
GDPR-048	GDPR	Art. 39(1)(c)	The DPO provides advice on the DPIA and monitors its performance.	B	Advisory role in impact assessment	Risk classification and lifecycle management; accountability and organisational roles	P2, P5	5	DPO	DPO advises on but does not own the DPIA; ownership rests with the controller function	DPIA record showing DPO advice and any dissent	Clarifies that DPO involvement does not transfer accountability.
GDPR-049	GDPR	Art. 77	Right to lodge a complaint with a supervisory authority.	B	External remedy	Contestability and feedback	P4	7, 8	Legal function	Supervisory authority route stated in the notice and decision	Notice text; complaint register	Cumulative with Art. 85 AI Act; both routes must be stated.
GDPR-050	GDPR	Art. 83(4) –(5), (7)	Two-tier administrative fines up to EUR 10M/2% and EUR 20M/4%; Member States may determine whether and to what extent fines apply to public authorities.	B	Enforcement exposure	Legal authority and enforceability	P1	2	Legal function	Exposure recorded by reference to national law	Classification record entry	CORRECTION: two tiers, not one, and application to public bodies is set nationally.
LED-051	Dir. (EU) 2016/680	Art. 4	Principles relating to processing for law-enforcement purposes.	C	Lawful processing in the law-enforcement context	Ethical foundations; data governance and privacy	P1, P3	2, 4	Competent authority; DPO	Confirmation of which regime applies before design decisions are fixed	Regime determination in the classification record	Conditionally binding because content is set by national transposing law.
LED-052	Dir. (EU) 2016/680	Art. 11(1)	Decisions based solely on automated processing producing an adverse legal effect or significantly affecting the data subject are prohibited unless authorised by law providing appropriate safeguards including at least the right to obtain human intervention.	C	Safeguards for automated decisions	Human oversight; contestability and feedback	P4, P5	2, 7	Competent authority; Legal	Verification of a national legal authorisation and of the safeguards it requires, before deployment	Legal basis analysis; oversight procedure	Stricter default than Art. 22 GDPR: prohibition unless authorised, rather than a right subject to exceptions.
LED-053	Dir. (EU) 2016/680	Art. 11(3)	Profiling that results in discrimination against natural persons on the basis of special categories of personal data is prohibited.	C	Non-discrimination	Ethical foundations	P1, P3	4, 5, 8	Competent authority; DPO	Disparity testing against special-category proxies at acceptance and in monitoring	Disparity test results	An outright prohibition rather than a balancing test; drives the disparity indicator in P1/P3.
LED-054	Dir. (EU) 2016/680	Art. 25	Logging of collection, alteration, consultation, disclosure, combination and erasure in automated processing systems.	C	Traceability of operation	Monitoring and assurance	P3, P7	4, 8	Information security; operational owner	Logging specification meeting both Art. 25 LED and Art. 26(6) AI Act	Log schema; retention schedule	Interacts directly with AI Act log retention; a single reconciled schedule is required.
LED-055	Dir. (EU) 2016/680	Art. 27	Data protection impact assessment where processing is likely to result in a high risk.	C	Ex ante risk assessment	Risk classification and lifecycle management	P2	5	Competent authority; DPO	LED impact assessment sequenced with the FRIA in the same way as a GDPR DPIA	Impact assessment record	Functionally parallel to Art. 35 GDPR but under a distinct legal basis.
LED-056	Dir. (EU) 2016/680	Arts. 52–54	Right to lodge a complaint with a supervisory authority and to an effective judicial remedy.	C	External remedy	Contestability and feedback	P4	7, 8	Legal function	Remedy routes stated in the decision, subject to any lawful restriction	Decision template; complaint register	Restrictions under Art. 15 LED may lawfully limit information; must be recorded and justified, not applied by default.
OECD-057	OECD AI Principles	1.1 Inclusive growth, sustainable development and well-being	AI actors proactively pursue beneficial outcomes for people and planet.	V	Public value orientation	Ethical foundations	P1	1	Leadership	Expected public value stated and revisited at reassessment	Statement of expected public value	Voluntary; supports but does not establish the necessity justification.
OECD-058	OECD AI Principles	1.2 Human rights and democratic values, including fairness and privacy	AI actors respect the rule of law, human rights and democratic values throughout the lifecycle.	V	Rights orientation	Ethical foundations	P1	1, 5	AI governance function	Rights considerations carried into the FRIA element list	FRIA record	Voluntary; the binding counterpart is Art. 27 AI Act.
OECD-059	OECD AI Principles	1.3 Transparency and explainability	AI actors commit to transparency and responsible disclosure, providing meaningful information appropriate to the context.	V	Transparency	Transparency and explainability	P4	6, 7	Operational owner	Context-appropriate disclosure design tested with affected users at pilot	Notice and reason templates; pilot feedback	Voluntary; corresponding binding or conditionally binding transparency and explanation requirements may arise under Art. 86 AI Act and Art. 15(1)(h) GDPR, subject to their respective conditions of application.
OECD-060	OECD AI Principles	1.4 Robustness, security and safety	AI systems are robust, secure and safe throughout their lifecycle, with traceability of datasets, processes and decisions.	V	Technical reliability and traceability	Data governance and privacy	P3	4, 6, 8	Technical team; information security	Traceability of datasets, processes and decisions maintained as a governance record	Data lineage documentation; decision log	Voluntary; overlaps Arts. 12 and 15 AI Act.
OECD-061	OECD AI Principles	1.5 Accountability	AI actors are accountable for the proper functioning of AI systems and for respect of the principles, based on their roles and context.	V	Accountability	Accountability and organisational roles	P5	Cross-cutting	Leadership	Named accountability for each governance activity	RACI; decision-rights allocation	Voluntary; the framework’s decision-rights table is author-proposed and goes beyond it.
NIST-062	NIST AI RMF 1.0	GOVERN 1	Policies, processes, procedures and practices across the organisation related to the mapping, measuring and managing of AI risks are in place, transparent and implemented effectively.	V	Governance structure	Organisational capacity and competence	P6	Cross-cutting	Leadership; AI governance function	Documented AI governance policy and standing governance function	Policy document; terms of reference	Voluntary; corresponds to the management-system layer also addressed by ISO/IEC 42001.
NIST-063	NIST AI RMF 1.0	GOVERN 2	Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible and trained.	V	Accountability and competence	Accountability and organisational roles; organisational capacity and competence	P5, P6	3, 6	Leadership	Role definitions with training and delegated authority	Designation and training records	Voluntary counterpart to the binding Art. 26(2) AI Act duty.
NIST-064	NIST AI RMF 1.0	GOVERN 6	Policies and procedures address AI risks associated with third-party software and data.	V	Supplier governance	Organisational capacity and competence	P6	3, 8	Procurement; operational owner	Supplier governance clauses and periodic supplier performance review	Contract clause register; supplier review records	Voluntary; directly supports the procurement controls of Stage 3.
NIST-065	NIST AI RMF 1.0	MAP 1	Context is established and understood, including intended purpose, setting, and expectations.	V	Context establishment	Risk classification and lifecycle management	P1, P2	1	AI governance function	Context statement forming part of the suitability assessment	Suitability assessment record	Voluntary; aligns with Stage 1.
NIST-066	NIST AI RMF 1.0	MAP 3	AI capabilities, targeted usage, goals and expected benefits and costs are understood.	V	Benefit and cost articulation	Ethical foundations; risk classification and lifecycle management	P1, P2	1	Leadership	Benefit and cost articulation, including consideration of non-AI alternatives	Necessity and proportionality record	Voluntary; the non-AI alternative comparison is author-proposed.
NIST-067	NIST AI RMF 1.0	MAP 5	Impacts to individuals, groups, communities, organisations and society are characterised.	V	Impact characterisation	Risk classification and lifecycle management	P2	5	AI governance function	Affected-group analysis feeding the FRIA	FRIA record; stakeholder input record	Voluntary; complements the binding element list of Art. 27(1).
NIST-068	NIST AI RMF 1.0	MEASURE 2	AI systems are evaluated for trustworthy characteristics, including validity, reliability, safety, security, privacy, fairness and explainability.	V	Evaluation	Monitoring and assurance	P3, P7	6, 8	Technical team	Acceptance test battery covering each trustworthiness characteristic	Test reports	Voluntary; provides the operational structure for the Stage 6 acceptance criteria.
NIST-069	NIST AI RMF 1.0	MEASURE 3	Mechanisms for tracking identified AI risks over time are in place.	V	Risk tracking	Monitoring and assurance	P7	8	AI governance function	Indicator set linked to the risk register, with defined review triggers	Monitoring reports; risk register updates	Voluntary; the review-trigger design is author-proposed.
NIST-070	NIST AI RMF 1.0	MEASURE 4	Feedback about efficacy of measurement is gathered and assessed.	V	Measurement validity	Monitoring and feedback	P7	8	AI governance function; internal audit	Periodic review of whether the indicators detect the risks they were chosen for	Indicator review record	Voluntary; addresses the risk that monitoring measures the wrong thing.
NIST-071	NIST AI RMF 1.0	MANAGE 2	Strategies to maximise AI benefits and minimise negative impacts are planned, prepared, implemented, documented and informed by input from relevant AI actors.	V	Risk treatment	Risk classification and lifecycle management; monitoring and assurance	P2, P7	5, 8	AI governance function	Documented treatment plan linked to each register entry	Risk register; treatment records	Voluntary; overlaps the Art. 9 AI Act risk-management system.
NIST-072	NIST AI RMF 1.0	MANAGE 4	Post-deployment monitoring plans are implemented, including mechanisms for appeal and override, decommissioning, incident response, recovery and change management.	V	Post-deployment management	Monitoring and assurance; contestability and feedback	P7	8	Operational owner; AI governance function	Monitoring plan incorporating appeal, override, decommissioning and change management	Monitoring plan; decommissioning triggers	Voluntary; the most directly operational of the coded NIST subcategories and the closest analogue to Stage 8.
AUTH-073	Authors	–	Documented comparison of non-AI and less-automated alternatives, with reasons for the option chosen.	A	Necessity and proportionality	Ethical foundations	P1	1	Leadership	Necessity and proportionality record	Necessity record with alternatives considered	Not derived from any coded provision. Supports but does not evidence compliance with any legal duty.
AUTH-074	Authors	–	Definition of decision types reserved for human judgement without system input.	A	Preservation of contextual judgement	Human oversight	P5	1, 3, 7	Operational owner; practitioners	Reserved-decision list embedded as a functional requirement	Reserved-decision list; system configuration record	Author-proposed. Responds to evidence on automation bias and selective adherence rather than to a legal requirement.
AUTH-075	Authors	–	Explicit allocation of decision rights: residual-risk acceptance, deployment authorisation, suspension, and verification of corrective action.	A	Decision authority	Accountability and organisational roles	P5	5, 6, 7, 8	Leadership; internal audit	Decision-rights table adopted as organisational policy	Decision-rights allocation; acceptance and approval records	Author-proposed. No coded instrument assigns these rights; separating suspension from approval is a design choice.
AUTH-076	Authors	–	Monitoring indicators paired with review triggers rather than performance targets.	A	Detection of governance failure	Monitoring and assurance	P7	8	AI governance function	Indicator and trigger set instantiated per system against a pre-deployment baseline	Monitoring plan; baseline record	Author-proposed. Design adopted from the instrument-versus-effectiveness separation used in index-based governance assessment.
AUTH-077	Authors	–	Override-rate floor as a suspension trigger for the assumption that human review remains substantive.	A	Prevention of formal-only oversight	Human oversight	P5	8	AI governance function; operational owner	Override floor set against pilot baseline, with suspension on sustained breach	Override log; quarterly oversight review	Author-proposed. Converts a legal question (whether Art. 22 GDPR is engaged) into a monitored governance assumption; it is not a legal opinion.
AUTH-078	Authors	–	Contract clause register mapping each clause to the provision it gives effect to.	A	Procurement traceability	Organisational capacity and competence	P6	3	Procurement; Legal	Clause-to-provision mapping maintained through the contract lifecycle	Contract clause register	Author-proposed. Makes it verifiable that procurement actually secured the conditions the deployer needs.

and

Table A2. Codebook: extraction rules, field definitions, verification procedure, consolidation rules, normative-status rules, and rejected consolidations.

Element	Rule/Definition	Notes
A2.1 Extraction rules
Unit of analysis	The governance-relevant provision: the smallest self-contained textual element imposing or recommending an identifiable obligation, safeguard, principle or control addressed to an organisational actor.	AI Act/GDPR/LED: article paragraph, or sub-point where a paragraph enumerates distinct duties. OECD: principle or sub-principle. NIST: subcategory within a core function.
E1 Thematic relevance	Extract where the provision addresses at least one of the eleven comparison themes.	Themes: risk classification; accountability; human oversight; transparency and explainability; impact assessment; data governance; fairness and fundamental rights; robustness and security; contestability; monitoring; organisational capacity.
E2 Addressee	Extract only where addressed to a provider, deployer, controller, processor, competent authority or equivalent organisational actor.	Provisions addressed solely to Member States, the Commission, notified bodies, standardisation bodies or supervisory authorities are excluded unless they generate a corresponding organisational duty, in which case that duty is recorded instead.
E3 Machinery	Exclude provisions establishing procedural, institutional or enforcement machinery without an organisational compliance duty.	Enforcement provisions are coded only where they determine the exposure an authority must record (Arts. 99, 100 AI Act; Art. 83 GDPR).
E4 One duty per record	Where one article contains duties belonging to different themes, extract each duty as a separate record.	Ensures the mapping is one-to-one at record level; e.g., Art. 26 AI Act yields separate records for paragraphs 1, 2, 4, 5, 6, 7, 9 and 11.
Recitals	Not coded; used only to interpret the corresponding operative provision.
Case law	Not coded as independent provisions; recorded as interpretive sources against the provision they construe.	C-634/21 SCHUFA (Art. 22 GDPR); C-203/22 Dun & Bradstreet (Art. 15(1)(h) GDPR); C-817/19 Ligue des droits humains (automated processing by public authorities).
A2.2 Field definitions
Source	Instrument from which the record derives.	Six values: AI Act; GDPR; Dir. (EU) 2016/680; OECD AI Principles; NIST AI RMF 1.0; Authors.
Provision	Article, paragraph, principle or subcategory identifier.	‘–’ where the record is author-proposed.
Duty/principle	Close paraphrase of the duty, not a verbatim quotation.	Paraphrase used throughout to avoid reproducing protected text; the identifier permits verification against the source.
Normative status	B/C/V/A, per the rules in A2.5 of Table A2.	Assigned before pillar and stage, so that status does not depend on placement.
Governance objective	The substantive end the provision serves, stated independently of its wording.	The field on which cross-instrument comparison is made, since terminology differs.
Preliminary theme	One or more of the ten controlled theme labels produced by the first analytical step: ethical foundations; legal authority and enforceability; transparency and explainability; human oversight; accountability and organisational roles; data governance and privacy; risk classification and lifecycle management; monitoring and assurance; contestability and feedback; organisational capacity and competence.	Where a record maps to more than one preliminary theme, each assigned theme retains its exact controlled label and multiple assignments are separated by semicolons.
Integrated pillar	P1–P7 after consolidation.	Multiple pillars recorded where the duty genuinely operates across them; multi-pillar assignment rate is one of the sensitivity measures in Table A4.
Lifecycle stage(s)	Stage or stages at which the duty becomes operationally relevant.	‘Cross-cutting’ where the duty applies continuously rather than at identifiable points.
Responsible actor	Internal organisational function that performs or coordinates the resulting activity.	Statutory role is recorded separately in the manuscript role-mapping table; this field is organisational.
Proposed control	The organisational action through which the duty is discharged.	Where the control goes beyond what the provision requires, that increment is recorded as a separate author-proposed record.
Expected evidence	Artefact by which performance of the control can be demonstrated and reviewed.	Must be an artefact that would exist independently of the audit, not a statement produced for it.
Rationale	Reason for the mapping, including any correction to an earlier reading.	Corrections are flagged with ‘CORRECTION:’ so that changes between versions are traceable.
A2.3 Verification procedure and outcome
Initial coding	Performed by the first and second authors across the complete set of 78 records (72 instrument-derived records and six author-proposed controls).	Extraction and coding applied rules E1–E4 and the field definitions in A2.2 of Table A2.
Verification subset	26 records (33% of the corpus), stratified to include records from every instrument, author-proposed controls, and every preliminary theme. The subset is listed in Table A3	Verification record. Reviewed by the third and fourth authors against the codebook.
Fields assessed	Preliminary theme and principal lifecycle stage, being the two fields most exposed to interpretive discretion.
Form of verification	Consensus review, not blind parallel coding. The third and fourth authors reviewed the first and second authors’ assignments against the codebook and the source provisions, rather than coding the subset independently without sight of those assignments.	This is a limitation of the procedure and is stated as such in Section 3.4 and Section 5.3 of the manuscript.
Agreement statistic	Not computed. Because verification took the form of consensus review rather than blind parallel coding, the data required for a percentage-agreement or Cohen’s kappa calculation were not generated.	No statistic is reported. A larger blind independently coded sample would allow one to be computed; this is identified as future work.
Disagreements and resolutions	None. The joint review session confirmed the assignment for all 26 records in the verification subset; no record required reassignment on either field.	Recorded per record in Table A3. Because verification took the form of consensus review, reviewers saw the initial assignment; a nil result is therefore weaker evidence of reliability than it would be under blind parallel coding.
Rule amendments	None required. No disagreement arose that would have prompted a change to a coding rule, so no re-checking of the full corpus against an amended rule was necessary.	Stated explicitly rather than left blank, so that the absence of amendments is legible as a result.
A2.4 Consolidation rules
R1 Shared governance objective	The themes serve the same substantive objective, such that a control implementing one would ordinarily be evaluated against the other.	Necessary condition.
R2 Lifecycle co-location	The themes become operationally relevant at substantially the same stages.	Necessary condition; prevents consolidation from concealing a difference in timing.
R3 Shared responsibility and evidence	The themes involve substantially overlapping responsible actors and produce overlapping evidence.	Necessary condition; prevents consolidation that would generate duplicate records rather than distinct action.
R4 Legal non-equivalence	Consolidation groups themes organisationally and never implies that the underlying legal requirements are equivalent, interchangeable, or discharged by a single act.	Constraint on every consolidation, not a condition for it.
Decision rule	Consolidate only where R1, R2 and R3 are all satisfied. Failure of any one is sufficient to retain the themes separately.
A2.5 Normative status assignment rules
B Binding	Gives effect to a legal obligation applying directly to the actor, subject only to its own conditions of application.	Example: Art. 5 AI Act prohibition of specified AI practices.
C Conditionally binding	Application depends on a classification decision, risk threshold, national transposition choice, or an application date not yet reached.	All LED-derived controls are C because content is set by national transposing law. All Chapter III AI Act controls are C pending 2 December 2027/2 August 2028.
V Voluntary	Derives from a non-binding instrument; creates no legal obligation.	All OECD and NIST records.
A Author-proposed	Not derived from any coded provision. May support compliance but does not constitute evidence of it.	Recorded with source ‘Authors’ and provision ‘–’ so that author-proposed content is separable by filter.
A2.6 Consolidations considered and rejected
Risk classification + monitoring	Rejected.	R1 satisfied (both concern risk over time) but R2 fails: classification is fixed at Stage 2 and revisited on change, whereas monitoring is continuous from Stage 8. Consolidating would have concealed the distinction between a determination and an ongoing activity.
Data governance + risk classification	Rejected.	R3 fails: the responsible actors differ (data owner and technical team versus legal function) and the evidence does not overlap (data documentation versus classification record).
Organisational capacity + accountability	Rejected.	R1 fails: capacity concerns whether the organisation is able to act, accountability concerns who answers for the action. Merging would have placed accountability in a pillar concerned with capability rather than authority; tested as Alternative B in Table A4.
Transparency + human oversight	Rejected.	R3 fails: oversight is evidenced by intervention and override records, transparency by notices and reasons. Both are discharged by the same official but through different artefacts.
Contestability + monitoring/feedback	Rejected.	R2 partially satisfied but R1 fails: contestability is a right of the individual exercised at the point of decision, whereas feedback is an organisational learning mechanism. Retained as a link between P4 and P7 rather than as a consolidation.

of Appendix A.

3.2. Source Corpus, Versions, and Selection Criteria

The corpus was assembled purposively rather than exhaustively. Instruments were included where they satisfied all four of the following criteria: (CR1) they impose or recommend requirements addressed to organisations that develop, procure, or use AI systems; (CR2) they are applicable to, or usable by, public authorities operating in the EU; (CR3) their authoritative text is publicly available in full, without licence restriction, so that provision-level extracts can be published in an open evidence matrix; and (CR4) they contribute a perspective, AI-specific regulation, data protection, law-enforcement processing, international normative guidance, or operational risk management, not already represented in the corpus. Instruments were excluded where they were sector-specific (for example, medical-device regulation), addressed exclusively to a non-EU jurisdiction without transferable operational content, restricted by copyright licensing (ISO/IEC 42001:2023, ISO/IEC 23894:2023), descriptive rather than prescriptive (index-based assessment instruments), or not yet in force as a source of directly applicable obligation (the Council of Europe Framework Convention).

Table 2. Source corpus: identifiers, versions, legal status, and consultation dates.

Source	Identifier	Version Used	Normative Status for EU Public Authorities	Consulted
EU AI Act	Regulation (EU) 2024/1689; CELEX 32024R1689	Consolidated text as amended by Regulation (EU) 2026/1744	Binding; phased application (Arts. 113, 111)	20 August 2026
Digital Omnibus on AI	Regulation (EU) 2026/1744; CELEX 32026R1744	OJ, 24 July 2026; in force 27 July 2026	Binding amending regulation	20 August 2026
GDPR	Regulation (EU) 2016/679; CELEX 32016R0679	Consolidated text	Binding	20 August 2026
Law Enforcement Directive	Directive (EU) 2016/680; CELEX 32016L0680	Consolidated text	Binding on Member States; effect via national transposition	20 August 2026
OECD AI Principles	OECD/LEGAL/0449	As revised, 2024	Non-binding Council Recommendation	20 August 2026
NIST AI RMF	NIST AI 100-1	Version 1.0, January 2023	Voluntary; no legal effect in the EU	20 August 2026
EDPB guidance	Guidance on automated decision-making and profiling; DPIA guidance	–	Interpretive guidance only; not coded as a source of obligation	20 August 2026
CJEU case law	C-634/21 SCHUFA; C-203/22 Dun & Bradstreet; C-817/19 Ligue des droits humains	–	Interpretive source only; not coded as a source of obligation	20 August 2026
CoE Framework Convention	CETS No. 225	–	Excluded from the coded corpus; supplementary human-rights reference	20 August 2026

identifies the version or identifier, legal status, and consultation date of each source. All primary legal texts were consulted in the consolidated English-language versions published on EUR-Lex, identified by their CELEX numbers. Where interpretive guidance was used, it is identified as guidance and is not coded as a source of obligation; guidance documents informed the interpretation of coded provisions but did not themselves generate entries in the evidence matrix. The legal position is stated as of 20 August 2026.

3.3. Unit of Analysis and Extraction Rules

The unit of analysis is the governance-relevant provision: the smallest self-contained textual element of a source that imposes or recommends an identifiable obligation, safeguard, principle, or control addressed to an organisational actor. In the AI Act, the GDPR, and Directive (EU) 2016/680, this is the article paragraph, or the sub-point where a paragraph enumerates distinct duties; recitals were not coded but were used to interpret the corresponding operative provisions. In the OECD AI Principles, the unit of analysis is the individual principle or sub-principle. In the NIST AI RMF, it is the subcategory within a Govern, Map, Measure, or Manage category.

The following extraction rules were applied.

• Extraction rule E1: A provision was extracted where it addressed at least one of the eleven governance themes used for the comparison (risk classification, accountability, human oversight, transparency and explainability, impact assessment, data governance, fairness and fundamental rights, robustness and security, contestability, monitoring, and organisational capacity). These eleven dimensions served as the extraction-relevance screen rather than as the final coding categories. During the subsequent coding step, overlapping dimensions were refined into the ten preliminary themes defined in Section 3.6.
• Extraction rule E2: A provision was extracted only where it was addressed to a provider, deployer, controller, processor, competent authority, or equivalent organisational actor; provisions addressed exclusively to Member States, the Commission, notified bodies, standardisation bodies, or supervisory authorities were excluded unless they generated a corresponding organisational duty, in which case that duty rather than the institutional provision was recorded.
• Extraction rule E3: Provisions establishing procedural, institutional, or enforcement machinery without an organisational compliance duty were excluded.
• Extraction rule E4: Where a single article contains duties belonging to different themes, each duty was extracted as a separate record, so that the mapping is one-to-one rather than one-to-many at the level of the record.

Application of these rules produced 72 instrument-derived records across the five coded instruments, together with six author-proposed controls recorded separately, yielding 78 records in total; the complete set is published as Table A1 in Appendix A.

3.4. Coding Procedure and Verification

Each extracted record was coded on eleven fields, including: source; provision identifier; verbatim or close-paraphrase statement of the duty; normative status; governance objective; preliminary theme; integrated pillar; principal lifecycle stage or stages; responsible actor; proposed operational control; and expected implementation evidence. The coding frame for the preliminary themes was derived from the eleven extraction-relevance dimensions defined in Section 3.3 and refined during the first analytical pass over the AI Act and the GDPR, following established procedures for directed qualitative content analysis [39,40]. This refinement, as stated, produced the ten preliminary themes reported in detail in Section 3.6 and used consistently in the codebook and evidence matrix.

Coding was carried out by the first and second authors, who performed the initial extraction and coding of all records. A verification subset comprising 26 records (one third, or 33%, of the corpus), stratified to include records from every instrument, author-proposed controls, and every preliminary theme, was reviewed by the third and fourth authors against the codebook and the source provisions, with particular attention to the two fields most exposed to interpretive discretion, preliminary theme and principal lifecycle stage.

Verification took the form of consensus review rather than blind parallel coding, and no formal inter-coder agreement statistic was therefore computed; this is a limitation of the procedure and is noted as such. The verification subset and the outcome of verification for each record are reported in

Table A3. Verification record for the stratified subset of coded records.

ID	Source	Provision	Duty/Principle (Close Paraphrase)	Preliminary Theme as Verified	Principal Lifecycle Stage as Verified	Outcome of Verification
AIA-014	AI Act	Art. 25	Distributors, importers, deployers or third parties are considered providers where they put a system into service under their own name or make a substantial modification.	Accountability and organisational roles	2	Confirmed—no change
AIA-029	AI Act	Art. 85	Any natural or legal person may lodge a complaint with the relevant market surveillance authority.	Contestability and feedback	7	Confirmed—no change
AIA-008	AI Act	Art. 10	Training, validation and testing data subject to data-governance and management practices appropriate to the intended purpose.	Data governance and privacy	4	Confirmed—no change
AIA-012	AI Act	Art. 14	High-risk systems designed and developed so that they can be effectively overseen by natural persons, including measures addressing automation bias.	Human oversight	3	Confirmed—no change
AIA-002	AI Act	Art. 5	Prohibition of specified AI practices, including social scoring by or on behalf of public authorities.	Legal authority and enforceability	1	Confirmed—no change
AIA-010	AI Act	Art. 12	Automatic recording of events (logs) over the lifetime of the system.	Monitoring and assurance	6	Confirmed—no change
AIA-001	AI Act	Art. 4	Providers and deployers take measures to ensure a sufficient level of AI literacy among staff dealing with operation and use.	Organisational capacity and competence	3	Confirmed—no change
AIA-021	AI Act	Art. 26(9)	Deployers use the information provided under Art. 13 to comply with their obligation to carry out a DPIA where applicable.	Risk classification and lifecycle management	5	Confirmed—no change
AIA-003	AI Act	Art. 6(1)	High-risk classification where the system is a safety component of, or is itself, a product covered by Annex I harmonisation legislation subject to third-party conformity assessment	Risk classification and lifecycle management	2	Confirmed—no change
AIA-013	AI Act	Art. 15	Appropriate levels of accuracy, robustness and cybersecurity, consistent throughout the lifecycle.	Data governance and privacy	6	Confirmed—no change
AIA-020	AI Act	Art. 26(7)	Before putting a high-risk system into service at the workplace, deployers who are employers inform workers’ representatives and affected workers.	Transparency and explainability; organisational capacity and competence	6	Confirmed—no change
AIA-011	AI Act	Art. 13	Providers design high-risk systems so that operation is sufficiently transparent to enable deployers to interpret and use the output appropriately, accompanied by instructions for	Transparency and explainability	3	Confirmed—no change
AUTH-075	Authors	–	Explicit allocation of decision rights: residual-risk acceptance, deployment authorisation, suspension, and verification of corrective action.	Accountability and organisational roles	5	Confirmed—no change
AUTH-073	Authors	–	Documented comparison of non-AI and less-automated alternatives, with reasons for the option chosen.	Ethical foundations	1	Confirmed—no change
AUTH-074	Authors	–	Definition of decision types reserved for human judgement without system input.	Human oversight	1	Confirmed—no change
AUTH-076	Authors	–	Monitoring indicators paired with review triggers rather than performance targets.	Monitoring and assurance	8	Confirmed—no change
AUTH-078	Authors	–	Contract clause register mapping each clause to the provision it gives effect to.	Organisational capacity and competence	3	Confirmed—no change
LED-056	Dir. (EU) 2016/680	Arts. 52–54	Right to lodge a complaint with a supervisory authority and to an effective judicial remedy.	Contestability and feedback	7	Confirmed—no change
LED-051	Dir. (EU) 2016/680	Art. 4	Principles relating to processing for law-enforcement purposes.	Ethical foundations; data governance and privacy	2	Confirmed—no change
LED-053	Dir. (EU) 2016/680	Art. 11(3)	Profiling that results in discrimination against natural persons on the basis of special categories of personal data is prohibited.	Ethical foundations	4	Confirmed—no change
LED-052	Dir. (EU) 2016/680	Art. 11(1)	Decisions based solely on automated processing producing an adverse legal effect or significantly affecting the data subject are prohibited unless authorised by law providing appro	Human oversight; contestability and feedback	2	Confirmed—no change
LED-054	Dir. (EU) 2016/680	Art. 25	Logging of collection, alteration, consultation, disclosure, combination and erasure in automated processing systems.	Monitoring and assurance	4	Confirmed—no change
LED-055	Dir. (EU) 2016/680	Art. 27	Data protection impact assessment where processing is likely to result in a high risk.	Risk classification and lifecycle management	5	Confirmed—no change
GDPR-047	GDPR	Art. 38(3)	The DPO receives no instructions regarding the exercise of tasks, is not dismissed or penalised for performing them, and reports to the highest management level.	Accountability and organisational roles	Cross-cutting	Confirmed—no change
OECD-059	OECD AI Principles	1.3 Transparency and explainability	AI actors commit to transparency and responsible disclosure, providing meaningful information appropriate to the context.	Transparency and explainability	6	Confirmed—no change
NIST-062	NIST AI RMF 1.0	GOVERN 1	Policies, processes, procedures and practices across the organisation related to the mapping, measuring and managing of AI risks are in place, transparent and implemented effectively.	Organisational capacity and competence	Cross-cutting	Confirmed—no change

(Appendix A); no record required reassignment and no coding rule was amended.

3.5. Normative Status Classification

Every record and control carries an explicit normative status, reproduced in the operational tables.

• Binding: The control gives effect to a legal obligation that applies directly to the actor concerned, subject only to its own operative terms. Example: the prohibition of specified AI practices under Article 5 AI Act.
• Conditionally binding: The control gives effect to a legal obligation whose application depends on a classification decision, risk threshold, national transposition, or future application date. This includes the FRIA under Article 27 where its conditions apply. All Directive (EU) 2016/680 controls are classified as conditionally binding because their content is determined by national transposing law.
• Voluntary: The control derives from a non-binding instrument and creates no legal obligation. All OECD- and NIST-derived controls are classified as voluntary.
• Author-proposed: The control is proposed by the authors as good practice and is not derived from a coded provision. Such controls may support compliance but do not themselves constitute evidence of legal compliance.

This classification is the mechanism by which the framework avoids the failure mode in which a public authority treats a NIST recommendation or an author-proposed control as a legal requirement, or treats implementation of a proposed control as proof of compliance. Where a lifecycle stage combines controls of different status, the statuses are listed separately rather than aggregated.

3.6. Framework Development and Consolidation Rules

The framework was developed through a structured thematic synthesis in two steps [39,40]. The governance dimensions identified during the comparative analysis were used as initial analytical categories, while source requirements were grouped and refined according to their governance objective, responsible actor, lifecycle relevance, and expected implementation evidence. This first step produced ten preliminary themes: ethical foundations; legal authority and enforceability; transparency and explainability; human oversight; accountability and organisational roles; data governance and privacy; risk classification and lifecycle management; monitoring and assurance; contestability and feedback; and organisational capacity and competence.

In a second step, preliminary themes were consolidated according to three jointly necessary consolidation rules and one constraint:

• Rule R1 (shared governance objective): The themes serve the same substantive governance objective.
• Rule R2 (lifecycle co-location): The themes become operationally relevant at substantially the same lifecycle stages.
• Rule R3 (shared responsibility and evidence): The themes involve substantially overlapping responsible actors and implementation evidence.
• Rule R4 (legal non-equivalence): Consolidation is organisational only and does not imply that underlying legal requirements are equivalent, interchangeable, or discharged by a single act.

Themes were consolidated only where R1–R3 were all satisfied, subject to R4. The application of these rules, including consolidations that were considered but rejected, is documented in Table A2 of Appendix A.

This process reduced the ten initial themes to seven pillars. Two potentially contestable consolidations warrant explicit justification. Transparency and explainability were combined with contestability (Pillar 4) because explanation enables the exercise of contestation rights, the functions become operationally relevant at the same decision stage, and they involve overlapping actors and evidence. This relationship is supported by Dun & Bradstreet and Article 86 of the AI Act. Human oversight was combined with accountability and organisational roles (Pillar 5) because Article 26(2) AI Act links effective oversight to the competence, authority, and assignment of natural persons; the functions also share lifecycle stages and intervention and override records as evidence.

The stability of the seven-pillar structure was tested against two alternative groupings applied to the full record set. Alternative A separated transparency, contestability, human oversight, and accountability, producing nine pillars; Alternative B used a different seven-pillar grouping by separating data governance from security and robustness, merging accountability with organisational capacity, and combining human oversight with transparency and contestability. Alternative A produced virtually unchanged multi-pillar assignment (33.3% versus 32.1%) and identical cross-pillar evidence sharing (11.5%), while increasing the mean number of pillars activated per lifecycle stage from 5.38 to 6.12. Alternative B reduced multi-pillar assignment to 25.6% but increased cross-pillar evidence sharing to 14.1%. Neither alternative changed requirement coverage, lifecycle placement, or responsible actors. The adopted seven-pillar structure is therefore treated as a defensible organisational compromise rather than a unique taxonomy. Full results are reported in

Table A4. Sensitivity analysis of the adopted seven-pillar structure against alternative groupings.

Measure	Seven-Pillar Structure (Adopted)	Alternative A (Nine Pillars)	Alternative B (Seven Pillars, Different Content)	Interpretation
Structure	P1 Legal/ethical/public value; P2 Risk and lifecycle; P3 Data/privacy/security/robustness; P4 Transparency/reasoning/contestability; P5 Human oversight/accountability; P6 Capacity/procurement/ competence; P7 Monitoring/assurance/improvement	As adopted, but transparency, contestability, human oversight and accountability separated into four distinct pillars	As adopted, but data governance separated from security and robustness; accountability merged into organisational capacity and human oversight placed with transparency and contestability
M1 Records requiring assignment to more than one pillar	32.1%	33.3%	25.6%	Alternative A leaves overlap essentially unchanged (one additional record) despite adding two pillars. Alternative B lowers it, but does so by merging distinctions rather than by resolving overlap.
M2 Mean distinct pillars activated per lifecycle stage	5.38	6.12	5.25	Alternative A activates more pillars at each stage without extending coverage, diluting the stage-to-pillar mapping. Alternative B is close to the adopted structure.
M3 Controls sharing implementation evidence across a pillar boundary	11.5%	11.5%	14.1%	Alternative B raises evidence fragmentation: separating lawful basis from data-quality controls places duties evidenced by the same documentation in different pillars.
Coverage: requirements captured	All 78 records mapped	All 78 records mapped	All 78 records mapped	INVARIANT. No grouping changes which requirements the framework covers.
Coverage: lifecycle stage attribution	Unchanged	Unchanged	Unchanged	INVARIANT. Stage attribution derives from the provision trigger point, not the pillar partition.
Coverage: responsible actor	Unchanged	Unchanged	Unchanged	INVARIANT. Actor attribution derives from the addressee of the duty.
Qualitative assessment	Adopted. Neither alternative dominates on all three measures; the adopted structure is retained because it holds M1 and M2 close to their minimum while keeping evidence fragmentation (M3) lowest and preserving the legal distinction between oversight and accountability.	Rejected. Adds two pillars for no measurable reduction in overlap and raises the number of pillars activated per stage.	Rejected. Improves M1 but raises M3, and places accountability in a pillar concerned with capability rather than authority.
Computation note	M1, M2 and M3 were computed from the 78 records in Table A1 (Appendix A). The adopted structure uses the recorded Integrated pillar assignment; the alternatives are transformations of that assignment, with the side of each split determined by the record’s preliminary theme. M1 counts records whose pillar set has more than one member. M2 averages, over lifecycle stages 1–8, the number of distinct pillars activated by at least one record attributed to that stage. M3 counts records sharing at least one expected-evidence item with a record whose pillar set is disjoint from its own.

of Appendix A.

Consolidation does not imply legal equivalence. For example, the GDPR DPIA and AI Act FRIA are grouped within the same broader risk and impact-assessment pillar because both contribute to ex ante risk governance, while retaining their distinct legal purposes, triggers, and scopes.

The seven pillars describe what needs to be governed, while a separate lifecycle mapping identifies when governance action is required. Requirements were ordered by the point at which they become operationally relevant, from problem definition and assessment of the suitability of AI through legal and risk classification, procurement or development, data preparation, impact assessment, testing and approval, operational decision-making, and monitoring and decommissioning. Eight stages were retained because each marks the point at which at least one coded provision first becomes operationally relevant and produces a distinct governance output.

The lifecycle also allows earlier decisions to be revisited when new issues arise through monitoring, complaints, audits, incidents, or changes to the system. Previous research on algorithmic decision-making helped inform practical aspects of the framework, particularly human oversight, contextual judgement, the suitability of automation, stakeholder involvement, lifecycle responsibility, and feedback. This literature was used for supporting purposes and was not included in the coded corpus.

3.7. Scenario-Based Application

The framework is applied to two illustrative public-sector scenarios: (i) social-benefit eligibility and (ii) AI-supported student assessment. Both can have significant consequences for individuals, but they differ in the types of data involved, the role of professional judgement, and the form of human oversight required.

The first scenario is developed as a complete worked example using a four-part protocol. P1 defines the system, including its purpose, level of automation, data categories, provider–deployer relationship, affected population, and legal effects. P2 applies the framework across all eight lifecycle stages and identifies the relevant pillars and the normative status of each control. P3 identifies the governance artefacts produced throughout the lifecycle. These include the classification record, risk register, DPIA–FRIA coordination, human-oversight procedure, explanation and appeal process, acceptance criteria, monitoring indicators, and decommissioning triggers. P4 records the points where the framework does not provide a predetermined answer and organisational judgement is required. The second scenario is presented more briefly and shows how the same framework leads to different priorities in a different decision context.

The scenarios are constructed rather than empirical. Their purpose is to examine whether the framework can be applied coherently to a realistic case and produce identifiable responsibilities, controls, evidence, and review points. They do not validate its effectiveness or demonstrate practitioner usability, organisational feasibility, compliance effectiveness, or improvements in decision quality. These aspects require expert evaluation and field implementation and are identified as future work in Section 5.3.

4. Results

The results are organised by research question. Section 4.1 reports the comparative mapping and the convergences, divergences, and operational gaps it reveals (RQ1). Section 4.2 presents the integrated framework, its derivation, and its traceability to the coded sources (RQ2). Section 4.3 reports the end-to-end application of the framework to a public-sector decision scenario (RQ3).

4.1. RQ1: Comparative Regulatory and Governance Mapping

The comparison shows that the five instruments address many of the same governance concerns, but from different perspectives and with different levels of legal force (

Table 3. Comparison of the five coded instruments across operational governance dimensions.

Dimension	EU AI Act	GDPR	Dir. (EU) 2016/680	OECD AI Principles	NIST AI RMF 1.0
Legal Status & Enforceability	Binding EU Regulation; public-sector penalties depend partly on Member State law (Art. 99)	Binding EU Regulation; fines for public authorities depend on Member State law (Art. 83(7))	Binding on Member States; effect through national transposition	Non-binding OECD Council Recommendation	Voluntary framework; no legal effect in the EU
Defined Roles	Provider, deployer, importer, distributor, authorised representative	Controller, processor, DPO	Competent authority as controller, processor, DPO	AI actors	Organisational and lifecycle roles
Risk Conceptualisation	Risk differentiated by system and intended use	Risk to rights and freedoms from personal-data processing	Risk to rights and freedoms in law-enforcement processing	Societal, ethical, and human-rights impacts	Continuous socio-technical risk and trustworthiness
Assessment Triggers	High-risk classification (Art. 6); FRIA where applicable (Art. 27)	High-risk processing; DPIA (Art. 35)	DPIA (Art. 27); prior consultation (Art. 28)	Voluntary adoption and policy endorsement	Map and Measure functions
Human Oversight	Design for effective oversight (Art. 14); competent assigned person (Art. 26(2))	Human intervention under Art. 22(3)	Safeguards including human intervention (Art. 11)	Human-centred values, agency, and oversight	Human roles across the core functions
Information to Deployers	Transparency and instructions for use (Art. 13); technical documentation	Processor arrangements and records	Processor arrangements and records	Openness and traceability	Documentation and transparency practices
Information and Explanation to Affected Persons	Notice (Art. 26(11)); explanation (Art. 86); system-specific transparency (Art. 50)	Information about logic (Arts. 13–15); contestation safeguards (Art. 22)	Information rights (Arts. 12–15); Art. 11 safeguards	Explainability and understandable information	Explainability as a trustworthiness characteristic
Registration and Record-Keeping	Registration (Art. 49); logging (Arts. 12, 26(6))	Records of processing (Art. 30)	Records and logging (Arts. 24–25)	Traceability of data, processes, and decisions	Govern and Manage documentation practices
Application to Legacy Public-Sector Systems	Transitional arrangements under Art. 111	Applies without transitional relief	Applies through applicable national law	Not applicable	Not applicable

Note: Application dates for Sections 1–3 of Chapter III of the AI Act are 2 December 2027 for systems classified under Article 6(2) and Annex III, and 2 August 2028 for systems classified under Article 6(1) and Annex I, as amended by Regulation (EU) 2026/1744. Articles 4 and 5 have applied since 2 February 2025 and Article 50 since 2 August 2026.

). The EU AI Act and the GDPR establish binding legal requirements, while Directive (EU) 2016/680 establishes requirements that operate through national transposition. The OECD AI Principles provide broader normative guidance, and the NIST AI RMF offers a voluntary approach to AI risk management.

The instruments also conceptualise risk differently. The AI Act links risk to the characteristics and intended use of the system through its classification framework. The GDPR focuses on risks to the rights and freedoms of individuals arising from personal-data processing, while Directive (EU) 2016/680 addresses similar concerns in the law-enforcement context. The OECD AI Principles take a broader societal and ethical perspective, whereas the NIST AI RMF treats risk as evolving throughout the lifecycle of a socio-technical system. These differences are reflected in their assessment mechanisms, ranging from AI Act classification and FRIA requirements to DPIAs under the GDPR and Directive (EU) 2016/680 and the iterative Map and Measure functions of the NIST AI RMF.

Areas of convergence are also evident. Human oversight appears across the five instruments, although its form and legal effect differ. Transparency follows a similar pattern. Under the AI Act, Article 13 concerns information provided by the provider to the deployer, whereas duties towards affected persons arise under provisions including Articles 26(11) and 86. Article 50 adds transparency requirements for specific types of AI systems. The framework preserves these distinctions because the duties involve different actors, lifecycle stages, and forms of evidence.

Despite differences in legal status and terminology, the instruments converge around accountability, transparency, human-centred governance, risk management, and continuing oversight [41]. Governance does not end when a system is approved. Risk assessment, documentation, monitoring, and corrective action recur throughout the lifecycle.

The main divergences concern enforceability, the conception of risk, and the allocation of roles. The AI Act distinguishes providers, deployers, importers, and distributors; the GDPR and Directive (EU) 2016/680 distinguish controllers and processors; and NIST uses broader organisational and lifecycle roles. A public authority may occupy several of these roles simultaneously, particularly where AI systems are externally procured or components are supplied by another organisation.

The comparison also reveals operational gaps where requirements exist but the instruments do not specify how they should be combined or implemented within a public organisation.

Table 4. Operational gaps identified by the comparison and the corresponding framework elements.

Operational Gap	Unresolved Issue	Framework Element
Sequencing of DPIA and FRIA	Neither instrument specifies sequencing, reconciliation of residual-risk decisions, or responsibility for resolving divergence.	Stage 5; DPIA–FRIA coordination table (Section 4.3.1)
Translating Oversight into Intervention	The AI Act requires effective oversight but does not specify intervention thresholds, override procedures, or supporting records.	Pillar 5; Stage 7; oversight procedure and override log
Allocation between Authority and Provider	Regulatory roles do not determine internal responsibilities or which activities may be contractually delegated.	Statutory–organisational role mapping and RACI tables (Section 4.2.6)
Operationalising the Explanation Standard	The applicable provisions define the function of explanation but not its form, timing, or integration into the administrative decision [42].	Pillar 4; explanation and appeal workflow (Section 4.3.1)
Closing the Monitoring Loop	Monitoring and incident reporting are required, but corrective-action triggers and verification are not fully specified.	Pillar 7; monitoring indicators and review triggers (Section 4.2.5)
Governing Legacy Systems	The transitional regime does not specify interim governance, while other applicable legal obligations continue.	Stage 2 classification record; Stage 8 reassessment triggers
Determining Decision Authority	The instruments do not specify who internally accepts residual risk, authorises or suspends deployment, or verifies corrective action.	Decision-rights allocation (Section 4.2.6)

links these gaps directly to the elements of the proposed framework. For example, Regulation (EU) 2026/1744 permits cross-referencing between a FRIA and a DPIA, but questions of organisational sequencing and coordination remain.

4.2. RQ2: Integrated Public-Sector AI Governance Framework

The comparative analysis was synthesised into an integrated governance framework linking regulatory requirements and normative principles to organisational responsibilities and operational controls. As described in Section 3.6, ten preliminary governance themes were consolidated into seven pillars using Rules R1–R3, subject to Constraint R4.

Table 5. From preliminary governance themes to integrated governance pillars.

Preliminary Governance Theme(s)	Integrated Governance Pillar	Basis for Consolidation	Rule(s)
Ethical foundations + legal authority and enforceability	1. Legal, Ethical, and Public-Value Foundations	Shared focus on the legitimacy, legality, proportionality, fairness, fundamental rights, and public value of AI use.	R1, R2, R3
Risk classification and lifecycle management	2. Risk Classification, Impact Assessment, and Lifecycle Governance	Covers classification, ex ante assessment, risk treatment, and lifecycle reassessment; retained as a single theme.	—
Data governance and privacy	3. Data Governance, Privacy, Security, and Robustness	Shared requirements for data quality, lawful processing, privacy, security, and reliability, supported by overlapping evidence.	—
Transparency and explainability + contestability and feedback	4. Transparency, Explainability, Administrative Reasoning, and Contestability	Explanation supports the ability of affected individuals to understand and challenge consequential decisions.	R1, R2, R3
Human oversight + accountability and organisational roles	5. Human Oversight, Accountability, and Responsibility	Effective oversight depends on clearly assigned competence, authority, and responsibility.	R1, R2, R3
Organisational capacity and competence	6. Organisational Capacity, Procurement, and AI Competence	Covers organisational capability, AI literacy, coordination, and governance of externally supplied systems; retained as a single theme.	—
Monitoring and assurance	7. Monitoring, Assurance, Incident Management, and Continuous Improvement	Monitoring findings support corrective action, learning, and reassessment throughout the lifecycle.	—

Note: R1 = shared governance objective; R2 = lifecycle co-location; R3 = shared responsibility and evidence. Constraint R4 preserves legal non-equivalence across all consolidations. Detailed consolidation decisions, including alternatives considered and rejected, are reported in Table A2 of Appendix A.

summarises this consolidation.

The resulting framework is shown in Figure 1. It combines seven governance pillars, defining what needs to be governed, with an eight-stage lifecycle identifying when governance action is required. Different pillars are activated at each stage according to the decisions and requirements involved. Monitoring, assurance, and feedback operate across the lifecycle, and findings, incidents, or complaints may lead to corrective action or the reassessment of earlier decisions. The framework is therefore iterative rather than strictly linear.

4.2.1. The Seven Governance Pillars

The first pillar, “Legal, Ethical, and Public-Value Foundations”, sets the boundaries for legitimate AI use in public administration. It covers legality, proportionality, fairness, purpose limitation, fundamental rights, and public value. Each use case should therefore have a clear legal basis and purpose, together with a documented justification of why AI is necessary and proportionate and whether any prohibited or unacceptable use is involved.

The second pillar, “Risk Classification, Impact Assessment, and Lifecycle Governance”, addresses how risks are identified and managed over time. It covers classification under Article 6 of the AI Act, including the conditions and documentation associated with Article 6(3)–(4), as well as the FRIA and DPIA where applicable. It also extends to testing, periodic reassessment, changes in risk, and eventual decommissioning. Risk management is therefore treated as an ongoing process rather than a one-off assessment.

The third pillar, “Data Governance, Privacy, Security, and Robustness”, concerns the data and technical foundations of AI-supported decisions. It covers lawful processing, data minimisation, purpose limitation, data lineage, data quality, representativeness, bias, privacy safeguards, cybersecurity, and technical robustness. For public authorities acting as deployers, Article 26(4) is particularly relevant because it requires them, where they control the input data, to ensure that these data are relevant and sufficiently representative.

The fourth pillar, “Transparency, Explainability, Administrative Reasoning, and Contestability”, concerns the position of individuals affected by AI-supported decisions. Under the AI Act, Article 26(11) provides for information about the use of relevant high-risk systems, Article 86 addresses explanation, and Article 85 provides a right to complain to the market surveillance authority. These safeguards operate alongside GDPR information and contestation rights and the applicable national-law duty to give reasons for administrative decisions [43]. The pillar therefore links explanation with practical routes for individuals to seek clarification, review, or challenge.

The fifth pillar, “Human Oversight, Accountability, and Responsibility”, addresses who remains in control of the system and who is responsible for its use. Article 26(2) requires oversight to be assigned to persons with the necessary competence, training, authority, and support. Effective oversight also requires meaningful opportunities to intervene, override, or stop the system and to consider contextual information that the system may not capture. The presence of a human decision-maker alone does not guarantee effective oversight, particularly where algorithmic advice may encourage excessive reliance or selective adherence [8]. Responsibilities must therefore be clearly allocated throughout the lifecycle, including where systems are supplied by external providers.

The sixth pillar, “Organisational Capacity, Procurement, and AI Competence”, concerns the organisation’s ability to put governance requirements into practice. It includes AI literacy under Article 4, appropriate governance structures, coordination between legal, technical, security, and data-protection functions, and effective management of external suppliers. Leadership commitment, adequate resources, training, and organisational readiness are also important for embedding AI governance into routine administrative practice [21,22].

The seventh pillar, “Monitoring, Assurance, Incident Management, and Continuous Improvement”, extends governance beyond deployment. It covers ongoing monitoring, logging, incident reporting, audits, and corrective action, including the relevant requirements of Articles 12 and 26(5)–(6) of the AI Act and Article 25 of Directive (EU) 2016/680. Monitoring findings may lead to reassessment, modification, suspension, or decommissioning where necessary.

4.2.2. The Eight-Stage Governance Lifecycle

The seven pillars describe what needs to be governed, but they do not show when different governance activities should take place. To address this, the framework is further organised around an eight-stage lifecycle:

• Problem Definition, Necessity and Suitability Assessment;
• Legal and Risk Classification;
• Procurement or Development;
• Data Governance and Preparation;
• Impact Assessment;
• Testing, Pilot Deployment, and Approval;
• Decision Operation, Administrative Reasoning, and Citizen Safeguards;
• Monitoring, Incident Response, and Decommissioning.

4.2.3. Pillar–Lifecycle Integration

The two dimensions of the framework are integrated by linking each lifecycle stage to the governance pillars requiring action at that point. The pillars are not applied with equal intensity throughout the lifecycle. Instead, each stage activates a combination of governance requirements and produces evidence that can subsequently be reviewed or audited.

At Stage 1 (Problem Definition, Necessity and Suitability Assessment), the organisation considers whether AI is an appropriate response to the administrative problem. This includes defining the intended purpose, expected public value, affected groups, and potential consequences, and considering whether the same objective could reasonably be achieved through a less automated or non-AI approach. This is particularly important where decisions depend on contextual or case-specific information that may not be fully captured through data [12]. For consequential uses, stakeholder participation may also help identify context-specific risks and assess the suitability of automation. Where such participation takes place, its influence on the decision should be documented.

At Stage 2 (Legal and Risk Classification), the organisation determines the applicable legal and governance requirements. This includes classification under Article 6 of the AI Act, any reliance on Article 6(3), the applicability of the GDPR or Directive (EU) 2016/680, DPIA and FRIA requirements, registration obligations, transitional provisions, and the regulatory roles of the public authority and external providers. The main output is a classification record identifying the applicable legal basis, risk category, responsible actors, and required assessments.

At Stage 3 (Procurement or Development), governance requirements are translated into system specifications or contractual conditions. For externally procured systems, these should address technical documentation, instructions for use, audit access, security, incident reporting, system updates, and support for human oversight and explanation. Responsibilities between the provider and the public authority should be explicit, while relevant practitioners should contribute to operational requirements where professional or administrative judgement is involved.

At Stage 4 (Data Governance and Preparation), the organisation establishes the lawful basis for processing, documents data provenance and lineage, assesses data quality, representativeness, and potential bias, and applies appropriate privacy and security safeguards. This stage also includes the deployer’s responsibility under Article 26(4) for input data within its control.

At Stage 5 (Impact Assessment), applicable assessments are coordinated without treating them as interchangeable. A DPIA addresses risks arising from personal-data processing, while a FRIA addresses broader fundamental-rights impacts where Article 27 applies. As Regulation (EU) 2026/1744 permits cross-referencing between the two, the framework emphasises coordinated assessment and a reconciled residual-risk position. Beyond documentation, these assessments support interdisciplinary consideration of system purpose, affected rights, risks, mitigation measures, and consequential governance choices [44,45]. The resulting evidence should link identified impacts to mitigation measures, responsible actors, residual-risk decisions, and monitoring requirements.

At Stage 6 (Testing, Pilot Deployment, and Approval), governance requirements are translated into acceptance criteria. Before full deployment, relevant aspects of accuracy, robustness, security, bias, explainability, logging, and human oversight should be tested, and staff should receive appropriate training. Pilot deployment may also provide feedback from operators and, where appropriate, affected users [24]. Approval should follow only after material deficiencies have been addressed and the responsible authority has accepted the remaining risks in accordance with the decision-rights allocation discussed in Section 4.2.6.

At Stage 7 (Decision Operation, Administrative Reasoning, and Citizen Safeguards), governance becomes part of day-to-day administrative practice. Public officials should exercise meaningful human oversight and remain able to question, review, or override system outputs where appropriate. Affected individuals should receive relevant information about the use of AI, understandable explanations where applicable, and access to appropriate routes for review, complaint, or appeal. Significant human interventions and contested decisions should also be documented.

Finally, Stage 8 (Monitoring, Incident Response, and Decommissioning) extends governance throughout operational use. Technical performance, data or concept drift, security incidents, complaints, and human-intervention patterns should be monitored over time. Material changes to the model, data, purpose, operating environment, or patterns of use should trigger reassessment where appropriate. Monitoring may also incorporate stakeholder feedback, particularly where recurring complaints or disparities reveal concerns that technical indicators alone may not capture [24].

4.2.4. From Regulatory Requirements to Operational Controls

The framework is intended to move beyond high-level governance principles by linking requirements to responsible actors, operational actions, and evidence.

Table 6. Consolidation of the preliminary themes into seven governance pillars.

Preliminary Theme(s)	Integrated Pillar	Basis for Consolidation	Rules
Ethical foundations + legal authority and enforceability	1. Legal, Ethical, and Public-Value Foundations	Genuine consolidation; shared legitimacy, rights, and public-value objectives.	R1–R3
Risk classification and lifecycle management	2. Risk Classification, Impact Assessment, and Lifecycle Governance	Expanded operational scope of the retained theme; determines applicable assessments and controls across the system lifecycle.	—
Data governance and privacy	3. Data Governance, Privacy, Security, and Robustness	Expanded operational scope of the retained theme; data governance requires data quality, privacy, security, reliability requirements and robustness safeguards.	—
Transparency and explainability + contestability and feedback	4. Transparency, Explainability, Administrative Reasoning, and Contestability	Genuine consolidation; explanation supports understanding and contestation.	R1–R3
Human oversight + accountability and organisational roles	5. Human Oversight, Accountability, and Responsibility	Genuine consolidation; oversight requires assigned authority and responsibility.	R1–R3
Organisational capacity and competence	6. Organisational Capacity, Procurement, and AI Competence	Expanded operational scope of the retained theme; organisational capability requires competent personnel, adequate resources, and effective provider management on AI procurement and competence.	—
Monitoring and assurance	7. Monitoring, Assurance, Incident Management, and Continuous Improvement	Expanded operational scope of the retained theme; monitoring supports incident detection, corrective action, reassessment, and organisational learning for continuous improvement.	—

Note: R1 = shared governance objective; R2 = lifecycle co-location; R3 = shared responsibility and evidence. Constraint R4 preserves legal non-equivalence across all consolidations. Detailed decisions and rejected alternatives are reported in Table A2 of Appendix A.

maps each lifecycle stage to its primary governance pillars, operational controls, the normative status of each control, responsible and accountable actors, and the implementation evidence through which governance action can be demonstrated and reviewed. The normative-status column is the safeguard against the framework being read as a compliance checklist. To this end, controls marked (author-proposed) are proposed here and satisfy no legal duty, while controls marked (conditionally binding) apply only where the stated condition, classification, or application date is met.

Table 7. Traceability of key regulatory and governance requirements to the proposed framework (extract; the complete matrix is provided in supplementary Table A1 of Appendix A).

Source	Provision	Governance Issue	Norm. Status	Preliminary Theme(s)	Pillar(s)	Stage(s)
AI Act	Art. 5	Prohibited practices	(binding)	Legal authority and enforceability	P1	1–2
AI Act	Art. 4	AI literacy of staff	(binding)	Organisational capacity and competence	P6	3, 6
AI Act	Art. 6(1)–(2)	High-risk classification	(conditionally binding)	Risk classification and lifecycle management	P2	2
AI Act	Art. 6(3)–(4)	Derogation conditions, profiling carve-out, documentation	(conditionally binding)	Risk classification and lifecycle management	P2	2
AI Act	Art. 9	Risk-management system	(conditionally binding)	Risk classification and lifecycle management	P2	2–8
AI Act	Art. 13	Provider-to-deployer transparency; instructions for use	(conditionally binding)	Transparency and explainability	P4, P6	3, 6
AI Act	Art. 14	Human oversight by design	(conditionally binding)	Human oversight	P5	3, 6
AI Act	Art. 26(2)	Assignment of oversight to a competent, trained, authorised person	(conditionally binding)	Human oversight; accountability and organisational roles	P5, P6	6–7
AI Act	Art. 26(5)–(6)	Operational monitoring; incident notification; log retention	(conditionally binding)	Monitoring and assurance	P7	8
AI Act	Art. 26(11)	Notice to persons subject to a high-risk system	(conditionally binding)	Transparency and explainability	P4	7
AI Act	Art. 27	FRIA	(conditionally binding)	Risk classification and lifecycle management	P2	5
AI Act	Art. 27(3)	Notification of FRIA results to market surveillance authority	(conditionally binding)	Risk classification and lifecycle management; monitoring and assurance	P2, P7	5
AI Act	Art. 49(3)	Registration of use by public-authority deployers	(conditionally binding)	Legal authority and enforceability	P1, P2	2, 6
AI Act	Art. 85	Right to lodge a complaint with a market surveillance authority	(binding)	Contestability and feedback	P4	7–8
AI Act	Art. 86	Right to explanation of individual decision-making	(conditionally binding)	Transparency and explainability; contestability and feedback	P4	7
AI Act	Art. 111(2)	Transitional compliance deadline for public-authority systems	(binding)	Risk classification and lifecycle management	P2	2, 8
GDPR	Art. 22	Safeguards for solely automated decisions	(conditionally binding)	Human oversight; contestability and feedback	P4, P5	7
GDPR	Art. 15(1)(h)	Meaningful information about the logic involved	(conditionally binding)	Transparency and explainability	P4	7
GDPR	Art. 35	DPIA	(conditionally binding)	Risk classification and lifecycle management	P2	5
GDPR	Art. 38(3)	Independence of the DPO	(binding)	Accountability and organisational roles	P5, P6	Cross-cutting
Dir. 2016/680	Art. 11	Solely automated adverse decisions; discriminatory profiling prohibition	(conditionally binding)	Human oversight; contestability and feedback; ethical foundations	P1, P5	2, 7
Dir. 2016/680	Art. 25	Logging in automated processing systems	(conditionally binding)	Monitoring and assurance	P3, P7	4, 8
Dir. 2016/680	Art. 27	Data protection impact assessment	(conditionally binding)	Risk classification and lifecycle management	P2	5
OECD	Transparency & explainability	Transparency	(voluntary)	Transparency and explainability	P4	Several
NIST	Govern	Roles/accountability	(voluntary)	Accountability and organisational roles; organisational capacity and competence	P5, P6	Cross-cutting
NIST	Map	Context and affected stakeholders	(voluntary)	Risk classification and lifecycle management	P1, P2	1–2
NIST	Measure/Manage	Monitoring and risk treatment	(voluntary)	Monitoring and assurance	P7	6–8
Authors	—	Necessity and non-AI alternative justification record	(author-proposed)	Ethical foundations	P1	1
Authors	—	Indicator review triggers and decommissioning thresholds	(author-proposed)	Monitoring and assurance	P7	8

Note: (binding) = binding; (conditionally binding) = conditionally binding; (voluntary) = voluntary; (authorproposed) = author-proposed. Ligue des droits humains, SCHUFA, and Dun & Bradstreet inform the interpretation of Articles 11 Dir. 2016/680, 22 GDPR, and 15(1)(h) GDPR respectively and are recorded in Table A1 (Appendix A) as interpretive sources rather than as independent provisions.

illustrates the traceability chain from source provision to framework element. It is an extract; the complete matrix of coded records, including the close-paraphrase duty statement, governance objective, and rationale for each mapping, is published as Table A1 in Appendix A.

4.2.5. Cross-Cutting Monitoring–Assurance–Feedback Loop

Governance continues after deployment. Monitoring, assurance, and feedback operate across the lifecycle, allowing governance arrangements to adapt as new risks, incidents, and operational experience emerge.

Monitoring involves the continuing collection of information about technical performance and governance in practice. Depending on the use case, relevant indicators may include error rates, drift, security incidents, complaints, processing incidents, and patterns of human intervention. Monitoring should also consider how officials interact with the system. Acceptance and override rates, reasons for intervention, disagreement with system recommendations, and successful complaints or appeals may help identify situations in which human oversight has become largely formal rather than substantive. Two design choices in the monitoring layer were adopted from the methodology of index-based governance assessment, as discussed in Section 5.1; that is, indicators separate the existence of a governance instrument from evidence of its effect, and each indicator is paired with an explicit review trigger rather than a target value, so that a threshold initiates investigation rather than being managed towards.

Table 8. Illustrative monitoring indicators and review triggers by governance pillar.

Pillar	Monitoring Indicator	Review Trigger	Governance Implication
P1 Legal, ethical and public-value foundations	Systems with a current necessity and proportionality justification	Missing or outdated justification; change of purpose	Use extending beyond the authorised purpose
P2 Risk classification, impact assessment and lifecycle	Time since classification and impact-assessment review	Material change or expiry of the review interval	Risk assumptions no longer valid
P3 Data governance, privacy, security and robustness	Data quality, drift, representativeness, and security incidents	Material drift, data breach, or representativeness gap	Reduced reliability of the basis for decisions
P4 Transparency, explainability, administrative reasoning and contestability	Explanation, reconsideration, complaint, and appeal patterns	Sustained increase in clarification requests or upheld challenges	Explanations or review routes may be ineffective
P5 Human oversight, accountability and responsibility	Acceptance and override rates; recorded justifications	Near-zero overrides or unexplained variation across officials or cases	Possible automation bias or ineffective oversight
P6 Organisational capacity, procurement and AI competence	Current staff training and provider response times	Expired training or provider response beyond the contractual period	Insufficient capacity to exercise effective oversight
P7 Monitoring, assurance, incident management and continuous improvement	Time to corrective action and proportion of findings closed	Overdue corrective action or recurrence of a closed finding	Monitoring not leading to effective corrective action

Note: Indicators and triggers are illustrative and author-proposed unless they evidence a binding or conditionally binding duty. They are signals for review rather than universal compliance thresholds; numerical thresholds should be defined by the organisation according to the system and its operating context.

provides illustrative indicators for each governance pillar, the review trigger associated with each, and the governance concern that a material deviation may signal.

Assurance provides an additional layer of review through internal or external audit, compliance assessment, or other independent examination. Its purpose is to determine not only whether the system performs as expected, but also whether governance procedures and responsibilities are being followed in practice.

Feedback ensures that monitoring and assurance findings lead to a documented response. This may involve changing procedures, retraining staff, modifying the system, revisiting an impact assessment, strengthening contractual requirements, or suspending or decommissioning the system.

4.2.6. Governance Roles and Responsibility Allocation

A governance framework is only useful if it is clear who is expected to act at each point in the AI lifecycle. This is especially important in public administration, where responsibility is often shared between managers, legal and data-protection staff, technical teams, public officials, and external technology providers. Without a clear allocation of roles, responsibility can easily become fragmented, particularly when decision-making is partly automated. Earlier work on algorithmic decision-making has already highlighted this risk, showing how reliance on automated recommendations may weaken individual perceptions of responsibility and make system outputs less likely to be questioned.

The framework distinguishes two layers of role, and the earlier version of this analysis conflated them. The first layer consists of statutory roles, which are assigned by law according to the objective circumstances of the processing or the system, and which cannot be reallocated by internal decision or by contract: provider, deployer, importer, and distributor under the AI Act; controller, joint controller, and processor under the GDPR; and competent authority acting as controller under Directive (EU) 2016/680. The second layer consists of internal organisational roles, which the authority allocates in order to discharge its statutory duties: leadership, an AI governance function, legal and data-protection functions, procurement, information security, technical teams, operational owners, public officials, and internal audit.

Table 9. Mapping of statutory roles to internal organisational roles.

Statutory Role	Source	Internal Functions That Typically Discharge It	Constraint on Internal Reallocation
Deployer	AI Act Arts. 3(4), 26, 27, 49(3), 86	Leadership (accountable); operational owner; public officials (oversight under Art. 26(2)); AI governance function (coordination)	Determined by use under own authority; cannot be transferred to the provider by contract.
Provider	AI Act Arts. 3(3), 16, Chapter III	Technical team; AI governance function; Legal	May be assumed involuntarily under Art. 25 where the authority puts a system into service under its own name or substantially modifies it.
Controller	GDPR Arts. 4(7), 24, 35	Leadership (accountable); data owner; DPO (advisory only)	Determined by who decides purposes and means; the DPO cannot be the controller.
Processor/joint controller	GDPR Arts. 26, 28	Procurement; Legal; Information security	Arrangement must reflect the factual allocation, not the label used in the contract.
Competent authority	Dir. (EU) 2016/680 Arts. 3(7), 11, 25, 27	Operational owner; DPO; Legal	Applies by virtue of law-enforcement purpose; safeguards set by national transposing law.
Data Protection Officer	GDPR Arts. 37–39, esp. Art. 38(3)	DPO, as an independent advisory and monitoring function	Must not receive instructions on the exercise of tasks, must not be dismissed or penalised for performing them, reports to the highest management level, and must not hold a role that determines purposes and means; the DPO advises on the DPIA but does not own it.
External provider/ supplier	Contract; AI Act Arts. 16, 25	Managed by procurement and the operational owner; performance monitored by internal audit	Outsourcing technical activity does not transfer responsibility for the administrative use of the system.

maps the two layers and states, for each statutory role, the internal functions that typically discharge it and the constraint that limits internal reallocation. A public authority frequently occupies several statutory roles simultaneously, and the framework treats this as the normal case rather than an exception. An authority that procures a system and uses it to make decisions is a deployer under the AI Act and a controller under the GDPR. An authority that configures, fine-tunes, or substantially modifies a procured system, or that places its own system into service under its own name, may additionally become a provider and thereby assume the Chapter III provider obligations. An authority that supplies a scoring or triage output relied upon decisively by another body may be a controller in respect of that operation notwithstanding that the formal decision is taken elsewhere, following SCHUFA. An authority processing for law-enforcement purposes acts as a competent authority under Directive (EU) 2016/680 rather than as a GDPR controller, with correspondingly different safeguards. Stage 2 of the lifecycle therefore requires the classification record to state, expressly, every statutory role the authority occupies in relation to the system, and the internal function accountable for each.

The independence of the DPO requires particular protection within this structure. Article 38(3) GDPR requires that the DPO receive no instructions regarding the exercise of their tasks, not be dismissed or penalised for performing them, and report to the highest management level. The DPO therefore advises on and monitors compliance, including the DPIA process under Article 39(1)(c), but does not own the DPIA, does not accept residual risk, and cannot be made accountable for a governance decision without compromising the independence the Regulation requires. In the RACI matrix that follows, the DPO is accordingly recorded as Consulted, never as Accountable, and a separate legal and compliance function carries the advisory role in respect of AI Act classification, procurement conditions, and FRIA requirements.

A governance framework must also state who decides.

Table 10. Allocation of decision rights not determined by the coded instruments.

Decision	Holder	Conditions and Evidence	Stage
Acceptance of residual risk	Senior responsible owner in leadership; cannot be delegated to the technical team or the provider	Written acceptance identifying each residual risk, its mitigation, the reason for acceptance, and the monitoring indicator attached to it; DPO and Legal consulted, neither accountable.	5–6
Authorisation of deployment	Leadership, on the recommendation of the AI governance function	Approval record confirming that acceptance criteria are met, oversight personnel are trained and authorised under Art. 26(2), registration under Art. 49(3) is complete, and residual risks are accepted.	6
Suspension of an operating system	Operational owner and, independently, the AI governance function or DPO acting on a data-protection or fundamental-rights concern	Documented suspension decision with reasons; either holder may act alone; reversal requires the deployment-authorisation route.	7–8
Verification of corrective action	Internal audit, or an assurance function independent of the function that implemented the action	Closure record evidencing that the action was implemented and that the indicator that triggered it has returned within range.	8

Note: This allocation is author-proposed. It is a coordination mechanism and does not alter statutory responsibility: the deployer remains the deployer, and the controller the controller, irrespective of the internal holder recorded here.

allocates the four decision rights that no coded instrument assigns, namely acceptance of residual risk, authorisation of deployment, suspension of an operating system, and verification that corrective action has been completed. Separating the authority to suspend from the authority to approve is deliberate: where the same function holds both, suspension competes with the decision it would reverse.

Political and administrative leadership has a central role at the outset. The decision to introduce an AI system should not be treated simply as a technical or procurement choice: leadership should be able to explain why AI is needed, what public value it is expected to provide, whether its use is proportionate, and whether the organisation has the resources and expertise to govern it. An AI governance function or committee then provides coordination across the organisation, maintaining an inventory of AI systems, coordinating legal and risk classification, following up impact assessments and mitigation measures, and checking that required reviews have taken place before deployment.

Public officials and system operators become central once the system influences real administrative decisions. Article 26(2) requires that oversight be assigned to natural persons who have the necessary competence, training, authority, and support, so officials need enough information, competence, and authority to question a recommendation, consider circumstances not captured by the system, and override or reject an output where appropriate. Training therefore becomes part of accountability rather than a separate organisational issue, and staff cannot be expected to challenge a system they do not understand [12].

Technical and development teams translate governance requirements into system-level controls through documentation, testing, security, robustness, logging, explainability mechanisms, and version or drift management. Responsibility for the technical functioning of a system should not, however, be confused with responsibility for the administrative decision. Procurement and information security are governance actors in their own right rather than support services: procurement determines whether the contractual conditions necessary to discharge Articles 13, 26, and 86 are actually secured, and information security owns the robustness and cybersecurity controls of Pillar 3 and the incident channel of Pillar 7. The same distinction applies to external vendors: outsourcing development, maintenance, or documentation does not remove the authority’s responsibility for the way AI is used in exercising public functions. Internal and external audit functions provide an additional layer of assurance, examining not only technical performance but whether governance procedures are followed, whether responsibilities are exercised in practice, and whether findings result in corrective action. Citizens and data subjects also have an active place in this structure: by requesting explanations, challenging decisions, submitting complaints, or providing information that changes the understanding of an individual case, they may identify problems not visible through technical monitoring alone. Affected individuals and stakeholder representatives form a consultative actor group; they carry no legal or organisational accountability but may provide contextual knowledge and identify potential harms, particularly at suitability assessment, impact assessment, pilot evaluation, and post-deployment monitoring.

Table 11. Illustrative organisational RACI matrix for the proposed eight-stage public-sector AI governance framework.

Lifecycle Stage	Leadership	AI Gov. Func.	Legal	DPO	Procurement	Info. Sec.	Tech. Team	Oper. Owner	Int. Audit	Ext. Provider
1. Problem Definition & Suitability	A/R	C	C	C	I	I	I	C	I	–
2. Legal & Risk Classification	A	C	R	C	I	I	I	C	I	I
3. Procurement/Development	A	C	C	C	R	C	R	C	I	R
4. Data Governance & Preparation	A	I	C	C	I	C	R	R	I	C
5. Impact Assessment (DPIA/FRIA)	A	R	C	C	I	C	C	C	I	C
6. Testing, Pilot & Approval	A	C	C	C	I	C	R	R	C	C
7. Decision Operation & Safeguards	A	I	C	I	I	I	C	A/R	I	I
8. Monitoring & Decommissioning	A	R	C	C	C	C	C	R	C	C

Note: R: Responsible (performs or coordinates the organisational activity); A: Accountable (holds final organisational ownership or approval authority); C: Consulted; I: Informed. The DPO is recorded as Consulted throughout and never as Accountable or Responsible, in order to preserve the independent advisory and monitoring function required by Article 38(3) GDPR. Affected individuals and stakeholder representatives are consulted at Stages 1, 5, 6, and 8 and are not shown as a column because they hold no organisational accountability; their involvement is recorded in the corresponding stage evidence. Decision rights not captured by RACI, residual-risk acceptance, deployment authorisation, suspension, and verification of corrective action, are allocated in Table 10.

translates this role structure into an illustrative RACI matrix across the eight-stage lifecycle. “Responsible” identifies the actor that performs or coordinates an activity; “Accountable” identifies the actor holding final organisational ownership or approval authority. These designations do not redefine statutory responsibilities: responsibilities assigned to controllers and processors under the GDPR, to competent authorities under Directive (EU) 2016/680, or to providers and deployers under the AI Act remain determined by law, irrespective of the internal allocation represented here.

4.3. RQ3: End-to-End Application to Public-Sector Decision Scenarios

This section applies the framework to an end-to-end application scenario in full, following the protocol set out in Section 3. The scenario is constructed rather than observed; it is used to test whether the framework yields a determinate set of responsibilities, controls, evidence, and review points, and not to validate its effectiveness. A second illustrative contrasting scenario is then developed at a summary level and used comparatively.

4.3.1. Scenario 1: Social-Benefit Eligibility

The first scenario considers a municipal social-welfare authority procuring an AI system to support eligibility decisions for a means-tested housing allowance.

System Specification (Protocol Step P1)

The system combines application data with administrative records and produces an eligibility recommendation together with a flag for documentary verification. A caseworker reviews every recommendation and remains responsible for the administrative decision.

The authority acts as deployer under the AI Act and controller under the GDPR, while the external vendor acts as provider and processor. The system processes identity, household, income, benefit, and tenancy data, as well as health data where a disability supplement is claimed. It affects approximately 40,000 applicant households annually and may contribute to decisions producing legal effects.

The system falls within Annex III, point 5(a), and is classified as high-risk under Article 6(2). The Article 6(3) derogation is unavailable because the system performs profiling and materially influences decision-making. Chapter III obligations therefore apply from 2 December 2027, while applicable GDPR, administrative-law, Article 4, and Article 5 requirements continue to govern the preceding period.

Stage-by-Stage Traversal and Governance Artefacts (Protocol Steps P2–P3)

Stage 1 (P1, P5, P6): The authority defines the administrative problem, assesses whether AI is necessary and proportionate, and considers less automated alternatives. Applications involving disability supplements, homelessness, and domestic-violence circumstances are reserved for human judgement without system input. Structured input from practitioners and a tenants’ advocacy organisation is documented, including changes made to the proposed design. Artefacts include a necessity and proportionality record, Article 5 screening, and a stakeholder-input record.

Stage 2 (P1, P2): The authority produces a classification record identifying the applicable legal basis, statutory roles, AI Act classification, transitional position, required assessments, and registration duties. The principal output is summarised in

Table 12. Worked example: classification record produced at Stage 2.

Field	Entry
Intended purpose	Decision support for means-tested housing-allowance eligibility; recommendation plus verification flag.
Statutory roles	Authority: deployer and controller. Vendor: provider and processor.
AI Act classification	Annex III, point 5(a); high-risk under Article 6(2).
Article 6(3) derogation	Unavailable because the system performs profiling and materially influences decision-making.
Transitional position	Chapter III Sections 1–3 apply from 2 December 2027; Articles 4 and 5 already apply.
GDPR position	Public-interest processing under Article 6(1)(e), with the relevant national legal basis under Article 6(3); Article 22 is not engaged as designed because every recommendation undergoes substantive human review and the final decision is not based solely on automated processing. Consequently, Article 15(1)(h) is not relied upon as an applicable explanation right in this scenario.
Directive (EU) 2016/680	Not applicable because the processing is not for law-enforcement purposes.
Assessments required	DPIA under Article 35 GDPR and FRIA under Article 27 AI Act, with notification under Article 27(3).
Registration	Provider registration under Article 49(1); authority registration of use under Article 49(3), since the system falls under Annex III point 5(a) and not the point 2 exception.
Accountable internal role	Director of Social Services as senior responsible owner; Legal function prepares the record.

.

Stage 3 (P6, with P2–P5 as design conditions): Governance requirements become procurement conditions. These include access to relevant technical documentation and instructions for use, support for explanation and human oversight, logging, incident notification, audit access, change control, and exit provisions. Responsibilities between the provider and the authority are made explicit, and practitioners contribute to operational requirements where professional judgement is involved.

Stage 4 (P3): The authority confirms the lawful basis, documents data provenance and lineage, and assesses data quality, representativeness, and potential bias. Two data-quality issues are recorded in the risk register rather than resolved silently: lagged income records for some self-employed applicants and incomplete tenancy data for informal sublets. Artefacts include data documentation, quality and representativeness assessment, safeguards, and an Article 26(4) input-data control record.

Stage 5 (P2, with P1 and P3–P5): The DPIA and FRIA are coordinated (

Table 13. Worked example: DPIA–FRIA coordination at Stage 5.

Element	DPIA	FRIA
Focus	Risks arising from personal-data processing	Fundamental-rights impacts of deploying the high-risk system
Sequence	Performed first to establish data flows and processing risks	Cross-references the DPIA and addresses additional fundamental-rights impacts
External step	Prior consultation where Article 36 GDPR applies	Notification under Article 27(3) AI Act
Residual risk		Differences are documented and resolved by the senior responsible owner without compromising DPO independence
Review		Reassessment follows material changes or relevant monitoring triggers

), and a risk register is produced. The worked example identifies risks including stale income data, ineffective human oversight, representativeness gaps, inadequate explanations, and unnotified model updates. Each risk is linked to mitigation, a residual-risk decision, and a monitoring indicator. The full risk register is reported in

Table A5. Risk register for the worked example of Scenario 1 (Section 4.3.1).

ID	Risk	Pillar	Lifecycle Stage Identified	Mitigation	Owner	Residual Position	Residual Accepted by	Monitoring Indicator	Review Trigger
R1	Stale income data for self-employed applicants produces systematically low eligibility recommendations	P3	4	Suppress recommendation where the income record is older than two quarters; route to manual verification	Data owner	Accepted; residual processing delay in a subset of cases	Senior responsible owner	Suppression rate; verification queue length	Suppression rate above the level assumed at acceptance, or queue length exceeding the statutory determination period
R2	Caseworker review degenerates into confirmation, converting the decision into one based solely on automated processing and engaging Art. 22 GDPR	P5	5	Reserved case types excluded from recommendation; mandatory override justification; confidence indicator hidden for reserved types; quarterly review of override patterns	Operational owner	Accepted subject to indicator; suspension trigger defined	Senior responsible owner	Override rate; variation across officials and case types	Override rate below the defined floor for two consecutive quarters without an accepted explanation
R3	Under-representation of informal tenancy arrangements produces disparate refusal rates	P1, P3	4	Representativeness assessment by tenure type; disparity testing at acceptance and quarterly thereafter	Technical team	NOT accepted at acceptance stage; deployment conditional on disparity within the FRIA band	Deployment blocked until met	Refusal-rate disparity by tenure and nationality	Disparity outside the FRIA band in any quarter
R4	Explanations describe the model rather than the individual decision, failing the Dun & Bradstreet standard	P4	5	Reason template stating the factors that operated in the individual case and the caseworker’s own reasoning; template tested with the advocacy organisation at pilot	Legal function	Accepted after pilot revision	Senior responsible owner	Requests for clarification; proportion of appeals citing unclear reasons	Sustained rise in clarification requests or in appeals citing unclear reasons relative to pilot baseline
R5	Vendor model update alters system behaviour without notice	P6, P7	3	Contractual change-control notice; re-testing before any update enters production; version log	Procurement	Accepted	Senior responsible owner	Unnotified version changes detected; drift measures after update	Any unnotified version change; drift beyond the range validated at acceptance
R6	Health data processed for the disability supplement without a confirmed Art. 9 condition	P1, P3	2	Art. 9 condition identified and recorded before processing; additional access restriction on the supplement pathway	DPO (advisory); Legal	Accepted with additional safeguards	Senior responsible owner	Access-log review for supplement pathway	Any access outside the authorised role set
R7	Authority becomes a provider under Art. 25 through fine-tuning or rebranding without recognising the change of statutory role	P1, P5	3	No-fine-tuning condition recorded in the specification; role reassessment triggered by any model modification	Legal function	Accepted	Senior responsible owner	Change-control log entries involving model modification	Any model modification, rebranding, or substantial change in intended purpose
R8	FRIA results not notified to the market surveillance authority under Art. 27(3)	P2, P7	5	Notification made an exit criterion for Stage 5; acknowledgement retained	AI governance function	Not accepted; mandatory	n/a – mandatory	Stage 5 exit checklist completion	Stage 6 authorisation cannot proceed without the notification record
R9	Log retention schedule under Art. 26(6) conflicts with the data-protection retention limit	P3, P7	4	Single reconciled retention schedule agreed between DPO and information security before deployment	Information security	Accepted	Senior responsible owner	Retention audit	Any retention audit exception
R10	Oversight personnel exercise review without current training or recorded authority under Art. 26(2)	P5, P6	6	Named designation with recorded training and delegated authority; access contingent on current training	Leadership	Not accepted; mandatory precondition to deployment	n/a – mandatory	Proportion of active oversight personnel with current training	Any official exercising oversight without current training

of Appendix A.

Stage 6 (P2–P6): Acceptance criteria and decommissioning triggers (

Table 14. Worked example: acceptance criteria and decommissioning triggers at Stage 6.

Category	Criterion or Trigger
Performance and disparity	Agreement with parallel manual determination must meet the pilot baseline, and refusal-rate disparities must remain within the band defined in the FRIA.
Explanation	The reason template must identify the factors that operated in the individual case and be validated during the pilot.
Oversight and logging	Designated caseworkers must be trained and authorised; override functionality and justification fields must operate correctly; relevant logs must be retained.
Decommissioning	Suspension or withdrawal is triggered by persistent oversight failure, unresolved disparity, loss of legal basis, an unvalidated model update, or a finding that the system no longer serves the public value identified at Stage 1.

) are fixed before deployment. Designated caseworkers are trained and formally authorised under Article 26(2), and a three-month pilot is conducted using parallel manual determination. Deployment is authorised only after material deficiencies have been addressed and the remaining risks have been accepted in writing by the senior responsible owner.

Stage 7 (P4, P5): Operation is governed by a documented oversight procedure and an explanation and appeal workflow. Caseworkers remain responsible for the administrative act, may request manual verification, and must record significant departures from or reliance on the system recommendation. The resulting workflow is summarised in

Table 15. Worked example: explanation and appeal workflow at Stage 7.

Step	Action	Evidence
1	Notice of AI-supported assessment under Article 26(11) AI Act and Articles 13–14 GDPR	Notice text and version
2	Reasoned administrative decision stating the relevant factors, the role of the system, and the caseworker’s own reasoning	Reasoned decision in the case file
3	Request for explanation under Article 86 AI Act	Explanation issued and response time
4	Internal reconsideration by a different caseworker, with the opportunity to submit further information	Reconsideration record and outcome
5	Administrative appeal under applicable national law	Appeal record and outcome
6	Regulatory complaint under Article 85 AI Act or Article 77 GDPR	Complaint register and regulator correspondence
7	Feedback from upheld challenges and clarification requests into governance review	Periodic contestability report

.

Stage 8 (P7, with P2–P6): Monitoring applies the indicators and triggers in Table 8 to the deployed system. Relevant indicators include suppression and verification-queue measures, override patterns, refusal-rate disparities, clarification and appeal volumes, and model-version changes. Logs are retained under Article 26(6), serious incidents are notified under Article 26(5), and internal audit verifies closure of corrective actions. Material change triggers reassessment of the relevant earlier stages.

Where the Framework Did Not Determine an Answer (Protocol Step P4)

The worked example also identifies four points at which the framework structures, but does not determine, the decision. First, numerical thresholds such as accuracy levels, disparity bands, and override floors remain organisational judgements that must be justified against a baseline. Second, the trade-off between suppressing recommendations based on stale income data and delaying decisions is a substantive policy choice. Third, whether human review is sufficiently substantive to keep the process outside Article 22 GDPR depends on operational reality and must therefore be monitored rather than assumed at design time. Fourth, the framework does not determine whether the authority should adopt the system at all; instead, it makes the necessity and proportionality judgement explicit, attributable, and reviewable.

4.3.2. Scenario 2: AI-Supported Student Assessment

The second scenario considers a public educational institution using an AI system to support decisions concerning student assessment or academic progression. The system may analyse academic performance and other relevant information and provide a recommendation to academic staff.

Governance again begins by asking whether AI is appropriate for the decision concerned. This is particularly important in education because student performance and progression may depend on circumstances that are not fully captured through quantitative indicators. Previous research has highlighted the risks of reducing complex educational situations to algorithmic inputs and the importance of retaining contextual and professional judgement [12]. Annex III, point 3, covers education and vocational training, including systems used to evaluate learning outcomes and to monitor prohibited behaviour during tests. Whether the particular system falls within a listed sub-point, and whether the Article 6(3) derogation is available, must thus be determined for the specific configuration rather than assumed from the sector.

Human oversight should go beyond approving or rejecting the recommendation. As such, academic staff should remain able to consider contextual and case-specific information the system may not capture [12]. Article 26(2) again converts this into an allocation decision, rather than a property of the interface, that specifies which staff are designated, trained, and authorized. Relevant practitioners can also contribute earlier in the lifecycle, defining operational requirements during procurement and identifying exceptional cases that should remain subject to human judgement. Pilot deployment can examine whether recommendations are understandable and useful to those expected to act on them, and student representatives may provide feedback on whether the system’s use, explanations, and review procedures are perceived as fair. Students should receive appropriate information where AI contributes to decisions affecting them (Article 26(11)) and should have access to established procedures for clarification, reconsideration, or appeal (Article 86; the institution’s academic-regulations appeal route).

4.3.3. Comparative Analysis of the Application Scenarios

The comparison of the two previous scenarios is set out in

Table 16. Comparative application of the governance framework across two public-sector scenarios.

Governance Dimension	Scenario 1: Social-Benefit Eligibility	Scenario 2: AI-Supported Student Assessment
AI Act classification	Annex III point 5(a); high-risk under Art. 6(2). Art. 6(3) unavailable: profiling carve-out and material influence on the outcome.	Annex III point 3; high-risk status depends on the specific sub-point and configuration, and the availability of Art. 6(3) must be assessed rather than assumed.
Applicable dates	Chapter III from 2 December 2027; Arts. 4 and 5 already applicable.	Chapter III from 2 December 2027; Arts. 4 and 5 already applicable.
Impact assessments	DPIA where the Art. 35 threshold is met; FRIA under Art. 27 with notification under Art. 27(3).	DPIA where the Art. 35 threshold is met; FRIA under Art. 27 where the institution is a body governed by public law or provides a public service.
Human oversight focus	Ability to question or override the recommendation and consider applicant-provided or contextual information.	Preservation of professional academic judgement and consideration of contextual student circumstances.
Contestability and safeguards	Notice (Art. 26(11)); explanation (Art. 86); reconsideration; administrative appeal; complaint under Art. 85.	Notice (Art. 26(11)); explanation (Art. 86); academic review, complaint, or grievance procedures under institutional regulations.
Participation/ feedback	Input from social-service practitioners and affected groups during suitability and impact assessment; stakeholder review where recurring concerns arise.	Input from academic staff and, where appropriate, affected students during pilot evaluation; structured feedback after deployment.
Binding governance constraint	Legal effect on access to a statutory entitlement; drives disparity testing, reason quality, and appeal accessibility.	Preservation of professional judgement; drives reserved-decision definition and oversight design.
Monitoring indicators	Recurring errors, human interventions, complaints and appeals, disparities in outcomes across groups, continued suitability.	Staff acceptance and override patterns, student complaints and appeals, disparities in outcomes, structured student feedback, continued support for the educational purpose.

Note: Inclusion of a use case in Annex III does not by itself determine high-risk status without the classification assessment required under Article 6, including the conditions set out in Article 6(3). The relevant high-risk requirements apply according to the dates fixed by Regulation (EU) 2026/1744.

. As observed, the same framework produces materially different governance priorities. In the benefit scenario, the binding constraint is the legal effect on access to a statutory entitlement, which drives the contestability and disparity controls. Conversely, in the education scenario, it is the preservation of professional academic judgement, which drives the reserved-decision and oversight-design controls.

5. Discussion

The results suggest that the main challenge for public organisations is not the absence of governance requirements but the lack of a structure connecting them. The instruments examined address common concerns such as risk, accountability, transparency, human oversight, and monitoring, but differ in legal force, terminology, and allocation of responsibilities. The seven operational gaps identified in Table 4 reflect this fragmentation.

Integration does not imply legal equivalence. The AI Act, GDPR, and Directive (EU) 2016/680 provide the binding legal baseline, while the OECD AI Principles and NIST AI RMF offer complementary normative and operational guidance. The normative-status classification in Section 3.5 preserves these distinctions by identifying controls as binding, conditionally binding, voluntary, or author-proposed.

The framework’s contribution lies primarily in establishing traceability between source requirements, governance functions, lifecycle decisions, responsible actors, operational controls, and implementation evidence. The legal audit also has practical implications. Duties towards affected individuals arise from Articles 26(11), 85, and 86 of the AI Act, together with the relevant GDPR safeguards, rather than Article 13, which concerns information provided to deployers. Moreover, Dun & Bradstreet establishes a functional approach to explanation, requiring intelligible information about the procedure and principles applied in the individual case. Pillar 4 therefore treats explanation as part of administrative reasoning and contestability rather than simply as a question of technical interpretability.

The transitional regime is also important for public authorities. Article 111 permits certain legacy systems to remain outside the relevant Chapter III requirements during the transitional period, but applicable GDPR, Directive (EU) 2016/680, and national administrative-law obligations continue to apply. The framework therefore treats legacy systems as requiring continuing governance rather than as temporarily exempt from it.

5.1. Relationship to Management-System Standards and Index-Based Assessment

The framework operates at the level of an individual AI system within an organisation, whereas management-system standards and governance indices operate at different levels.

ISO/IEC 42001:2023 [38] establishes an organisational AI management system based on a “Plan–Do–Check–Act” structure. The relationship is complementary. ISO/IEC 42001 provides organisational arrangements for policy, competence, internal audit, and management review, while the proposed framework specifies governance actions and evidence for an individual system. An organisation applying ISO/IEC 42001 would therefore already have structures relevant to Pillars 6 and 7. The standard was excluded from the coded corpus because its licensing conditions prevent provision-level reproduction in an open evidence matrix, not because it lacks relevance.

The Stanford HAI AI Index [27] and AGILE Index [28] operate at jurisdictional rather than system level and therefore were not coded as sources. Their methodological contribution is nevertheless relevant. In particular, the distinction between the existence of governance mechanisms and evidence of their effectiveness informs the monitoring indicators in Table 8. The framework similarly distinguishes the presence of controls from evidence that oversight, corrective action, and other governance processes actually operate.

These comparisons also clarify the limits of the proposed framework. It specifies what should be governed, when, by whom, and with what evidence, but does not demonstrate that practitioners would reach the same decisions, that the arrangements are proportionate to organisational capacity, or that they improve administrative outcomes. These remain empirical questions.

5.2. Implications

A first implication concerns human oversight. Formal human involvement is insufficient if officials lack the competence, authority, or practical ability to question an algorithmic recommendation. Article 26(2) makes oversight an organisational allocation of competence, training, and authority, while Ligue des droits humains reinforces the importance of individual, non-automated review in consequential contexts. The framework therefore treats meaningful oversight as a monitored governance condition rather than assuming that the presence of a human decision-maker is sufficient.

A second implication concerns the decision to use AI at all. Technical feasibility does not establish suitability for an administrative task. Public authorities should consider non-AI alternatives and assess legality, necessity, proportionality, expected public value, fundamental rights, and procedural safeguards before procurement or development. Responsibility for the administrative decision remains with the authority even where technology is supplied externally.

The framework also makes governance trade-offs explicit. Transparency may conflict with privacy, security, or legitimate confidentiality; extensive human review may affect administrative efficiency; and stakeholder participation may increase organisational burden. The framework does not resolve these tensions automatically. Instead, it identifies them, assigns responsibility, and requires the resulting decisions to be justified and reviewed. Scenario 1 illustrates this boundary by identifying decisions that the framework structures but does not determine.

Finally, the framework complements rather than replaces existing public-sector AI governance research. Value-based, socio-technical, readiness, and institutional approaches identify concerns such as public value, trust, participation, competence, and organisational learning. The proposed framework provides an operational layer through which these concerns can be incorporated into lifecycle governance. Stakeholder participation can therefore take different forms across the lifecycle, from consultation during problem definition to structured feedback after deployment [24].

5.3. Limitations and Future Work

Several limitations define the scope of the findings.

First, the selection of the EU AI Act, GDPR, Directive (EU) 2016/680, OECD AI Principles, and NIST AI RMF was purposive rather than exhaustive. Other standards, sector-specific rules, national administrative-law requirements, and governance frameworks may introduce additional controls or responsibilities.

Second, the synthesis involves interpretive judgement. The coding and consolidation rules, verification procedure, and sensitivity analysis improve transparency and reproducibility but do not establish the seven-pillar structure as the only possible taxonomy. Coding was performed by the authors with verification of a stratified subset; independent coding of a larger sample would provide stronger evidence of reliability.

Third, the framework is designed primarily for European public administration. Although its lifecycle structure, actor–control–evidence relationships, and normative-status discipline may be transferable, the legal content of the pillars cannot be transferred unchanged to other jurisdictions. Portability outside the EU has not been evaluated.

Fourth, the scenarios are constructed rather than empirical. Scenario 1 demonstrates that the framework can generate an internally consistent set of responsibilities, controls, evidence, and review points and can identify where organisational judgement remains necessary. It does not demonstrate practitioner usability, organisational feasibility, compliance effectiveness, resource proportionality, or improvements in decision quality. Independent expert evaluation and public-sector implementation are therefore necessary next steps.

Fifth, the regulatory landscape continues to evolve. The analysis reflects the legal position as of 20 August 2026 and incorporates Regulation (EU) 2026/1744. Subsequent legislation, guidance, and harmonised standards may require revisions to the crosswalk and operational controls [41].

Finally, the framework identifies governance activities and evidence but does not provide validated measures of their effectiveness or a weighting mechanism for resolving trade-offs. The monitoring indicators are author-proposed, and their thresholds remain organisational judgements. Future work should therefore evaluate the framework through expert assessment, public-sector case studies, and pilot implementation, and develop validated measures of human oversight, contestability, organisational capacity, stakeholder participation, and post-deployment monitoring.

6. Conclusions

This study examined how the EU AI Act, GDPR, Directive (EU) 2016/680, OECD AI Principles, and NIST AI RMF can be brought together into a more coherent governance approach for public-sector AI operating within the EU legal context. Although these instruments share concerns around risk, accountability, transparency, human oversight, and monitoring, they approach them from different legal and organisational perspectives. The challenge for public organisations is therefore not simply to comply with individual requirements, but to translate them into a governance process that can be applied throughout the lifecycle of an AI system.

To address this, the study proposed an integrated framework built around seven governance pillars and eight lifecycle stages, linking legal and ethical requirements with organisational responsibilities, operational controls, and post-deployment review. Three features distinguish it from a checklist of principles. Every element is traceable to an identified provision through a published evidence matrix and codebook, so the derivation can be audited and contested. Every control carries an explicit normative status, so guidance and author-proposed practice cannot be mistaken for legal obligation. Additionally, the statutory roles assigned by law are kept distinct from the internal organisational roles through which an authority discharges them, with the decision rights that no instrument assigns, including residual-risk acceptance, deployment authorisation, suspension, and verification of corrective action, allocated explicitly.

The framework was applied in an end-to-end social-benefit eligibility scenario, producing a classification record, a risk register, a coordinated DPIA and FRIA, an oversight procedure, an explanation and appeal workflow, acceptance criteria, monitoring indicators with review triggers, and defined decommissioning triggers, together with records of the points at which organisational judgement was required to determine the outcome. A contrasting scenario regarding education showed that the same structure yielded different priorities in a different decision context. These applications demonstrate analytical completeness; they do not demonstrate usability, feasibility, or effectiveness, which require empirical evaluation and deployment within active public agencies to measure the actual burden of compliance.

The framework’s value lies less in adding another set of principles than in showing how existing requirements can be organised, assigned, implemented, evidenced, and reviewed over time. Further work should include the submission of the framework to independent expert assessment and to pilot implementation in public authorities, in order to develop validated measures of whether the governance arrangements it specifies function as actually intended, by genuinely improving administrative fairness and preserving the core democratic values, transparency, and accountability that underpin public service.