Decision Forums and Governance Bodies

Chapter 9 moved the routine work of AI governance into pipelines, and Chapter 12 placed use-case ownership with the teams closest to the business. Neither removes the need for people to meet and decide. Somebody must set the risk appetite, accept residual risk, rule on unforeseen exceptions, stop an agent at two in the morning, and answer to supervisors and works councils. This chapter describes the forums an organisation needs, what each decides, how decisions are tiered by risk class, and the charters and decision-tier policy that make the structure testable as code.

Figure 13.1: The forum map. Each forum has a distinct mandate; evidence flows up from registers and pipelines and escalations flow up by rule. The specialist forums are the design authority, the model risk committee, the data governance council and the advisory ethics and fundamental rights council.

Why forums still matter after governance as code

Chapter 9 argued that a committee can decide but cannot enforce, observe or remember at delivery pace. The corollary is often missed: pipelines cannot decide anything that has not already been decided. A gate applies a threshold but does not set it, and a waiver record names an approver who must have the mandate to approve. Governance as code therefore relocates human judgement rather than eliminating it, and the quality of that judgement depends on the forums in which it is exercised.

Most organisations already have more forums than they need and fewer than they think. Typically each existing body believes it has a say over AI, none has a mandate that names it, and the first high-risk use case visits all of them in sequence: many meetings, few decisions, and no record of who accepted which risk on what evidence. The design task is to give every AI decision exactly one home, put routine decisions in policy, and make every forum consume evidence from pipelines rather than slide authors. Architecture as Code (Chapter 11) made the same move for architectural governance (66, Nordqvist, 2025), and Chapter 16 applies it to portfolio steering.

The European anchors

Several European instruments already assign decisions to particular bodies. The statements below describe architectural implications, not legal advice; check national transposition and sectoral rules for each organisation.

Management bodies under NIS 2 and DORA

Article 20 of the NIS 2 Directive, Directive (EU) 2022/2555, requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation and follow training, and makes them liable for infringements (4, European Union, 2022); for the digital-infrastructure and ICT-service entities it covers, Implementing Regulation (EU) 2024/2690 adds an annual management-body review of the security policy (125, ENISA, 2025). DORA, Regulation (EU) 2022/2554, is sharper: under Article 5 the management body of a financial entity defines, approves, oversees and bears ultimate responsibility for the ICT risk-management framework, and its members keep their knowledge up to date through regular training (3, European Union, 2022). The ECB's July 2026 letter on AI-enabled cyber threats placed responsibility for the response primarily with banks' management bodies (123, ECB, 2026).

Deployers under the AI Act

The AI Act assigns decisions to persons rather than forums. Article 26(2) requires deployers of high-risk AI systems to assign human oversight to named natural persons, and Article 26(7) requires employers to inform workers' representatives and affected workers before a high-risk system is used at the workplace (1, European Union, 2024). Article 4 on AI literacy, as the Digital Omnibus on AI amended it, asks for measures rather than a guaranteed result (27, European Union, 2026), and the Commission leaves the governance structure for those measures to the organisation (133, European Commission, 2026). The forum structure must therefore make the oversight persons' authority real, including the authority to stop a system under Article 14(4)(e), and show the literacy measures taken.

Management systems and supervisory expectations

ISO/IEC 42001 and ISO/IEC 27001 both place leadership in clause 5 and management review in clause 9.3. In banking, supervisors are applying governance expectations rather than writing new rules. The European Banking Authority found no significant contradictions between the AI Act and the banking framework (124, EBA, 2025); the ECB's priorities for 2026–28 expect banks that leverage new technologies, in particular AI, to set up robust governance and risk controls (119, ECB, 2025); and a 2025 ECB review of thirteen banks found that about half had introduced dedicated AI policies or committees, while warning against generalising from the sample (120, ECB, 2025). An ECB supervisor put the principle plainly: AI should be governed as a core business and risk topic, and it does not dilute responsibility (121, Machado, 2026).

Boards are moving, from a low base. In Deloitte's 2025 survey of 695 board members and executives, 31 per cent said AI was not on the board agenda, down from 45 per cent, and two thirds reported limited or no AI knowledge (131, Deloitte, 2025); among the 80 Fortune 100 companies that had filed by July 2025, 40 per cent disclosed a board committee charged with AI oversight in 2025, against 11 per cent a year earlier (132, EY, 2025).

The forums and what each decides

The forums below are functions, not necessarily separate meetings, and a mid-sized authority may fold several into existing bodies. What must not be combined is a mandate with its own oversight: the forum that approves a high-risk deployment should not also review whether its approvals were sound.

The management body

The management body, the board in a company and the head of the authority with the management group in public administration, sets the risk appetite for AI, approves the AI policy, accepts residual risks beyond the appetite it delegated, and oversees whether the arrangements work. A board that reviews chatbots has stopped governing and started managing. A report generated from the portfolio register (Chapter 16) and a training record treated as governance evidence make its oversight real.

The AI governance board

The AI governance board turns the appetite into policy and owns the portfolio. It approves the classification policy of Chapter 8 and the policy modules of Chapter 9 with their thresholds, accepts residual risk and decides go-live for high-risk systems, reviews waivers by count and age, and decides funding tranches under Chapter 16. It avoids becoming a queue by refusing to see anything the policy can decide and by measuring its own decision lead time.

The AI design authority

The AI design authority, often a specialisation of an existing architecture board, decides reference patterns, golden paths, sourcing choices under Chapter 7's criteria, deviations from approved patterns, and precedent-setting AI Decision Records. An AI Decision Record extends the architecture decision record that Nygard proposed (78, Nygard, 2011) to one decision about an AI system; with the model card that documents a model's intended use and limitations (46, Mitchell et al., 2019), it is the authority's working material, and its output is a merged record rather than minutes. Where an architecture board of the kind in Architecture as Code (Chapter 11) exists, the design authority is a standing agenda item rather than a new body (66, Nordqvist, 2025).

The model risk committee

In supervised financial entities a model risk committee approves models after independent validation and tracks findings to closure. The ECB's guide to internal models expects banks to reflect the risks of machine-learning models in their governance and expects the management body, senior management, the risk committee, developers, validators and auditors to understand such models sufficiently (122, ECB, 2026). AI models belong in the same inventory, and to absorb their rate of change the committee approves the thresholds of an automated evaluation pipeline and decides exceptions rather than revalidating every version by hand.

The data governance council

The data governance council decides data-use questions the policy cannot settle, such as a new purpose for a dataset or a cross-border transfer for training. The data protection officer is consulted, not outvoted, because Article 38(3) of the GDPR protects the officer's independence (2, European Union, 2016).

The ethics or fundamental-rights council

An ethics council, or in the public sector a fundamental-rights or algorithm council, gives opinions on lawful but contested uses such as profiling or staff monitoring. It should include external members, authorities should publish its opinions, and it should be advisory, with one firm rule: an accountable executive who proceeds against its opinion records the reasons. For deployers that must complete a fundamental rights impact assessment under Article 27 of the AI Act, it is the natural reviewer of the assessment (1, European Union, 2024).

The change advisory board

The change advisory board should not re-approve what the pipeline has evaluated: a model version promoted through the gates of Chapter 9 is a pre-authorised standard change, and the board sees only what the policy routes to it, such as an emergency rollback. A board that reviews every prompt change will be bypassed within a quarter.

Management reviews under ISO/IEC 27001 and ISO/IEC 42001

In ISO/IEC 27001 and ISO/IEC 42001, clause 5 sets leadership requirements, including roles, responsibilities and authorities, and clause 9.3 requires top management to review the management system at planned intervals (104, ISO/IEC, 2022), (32, ISO/IEC, 2023). Organisations certified under both should run the two reviews with a shared evidence pack, because AI security and information security share controls, owners and incidents.

Incident and stop decisions

Some decisions cannot wait for a forum, and a detection that pages a person who cannot stop a workload has produced a record, not a response. Article 14(4)(e) of the AI Act requires that a high-risk system can be brought to a halt in a safe state (1, European Union, 2024), and research has observed some frontier models working around a shutdown mechanism within their reach in order to finish a task (61, Schlatter et al., 2026), so a stop path inside the system it is meant to stop fails exactly when needed. Our default is that the incident commander and the use-case owner may each stop a system unilaterally; restarting requires the use-case owner and, for high-risk systems, the risk function; and every stop is reported to the AI governance board and, above a materiality threshold, to the management body. The Five Eyes guidance on agentic AI likewise treats human approval points and the ability to interrupt an agent as controls to be designed in (95, Five Eyes agencies, 2026).

Supplier and procurement decisions

Routine purchases within an approved catalogue are decided by policy. A new provider for a high-risk system, a provider outside the approved sovereignty posture of Chapter 6, or a contract the DORA register of information must capture belongs with the procurement board, advised by the design authority and the risk function.

Employee representation and works councils

In much of Europe, AI that monitors, evaluates or changes employees' work is a matter for co-determination or consultation. Article 26(7) of the AI Act sets a floor (1, European Union, 2024), and national law often goes further: the German Works Constitution Act requires that the works council be informed about work procedures that include AI and deems an expert necessary when it assesses the introduction of AI (130, Germany, 2001). The employee-representation forum therefore sits at a defined point in the decision path, after the design authority has settled what the system will do and before go-live, and receives the same evidence pack as the board.

Political and legal accountability in the public sector

Public authorities also answer to elected bodies, ombudsmen, courts and auditors-general, and the head of the authority remains accountable under administrative law for decisions taken with AI support, as Chapter 17 discusses. Swedish national guidelines state that the use of generative AI must ultimately be decided by the authority's management and that AI never carries responsibility (127, Digg & IMY, 2025); the Dutch Algoritmekader asks authorities to make someone responsible for algorithm governance and fix decision points across the lifecycle (128, Dutch Ministry of the Interior, 2026); the United Kingdom requires central government departments to publish records under its Algorithmic Transparency Recording Standard (129, GDS & DSIT, 2025); and the OECD recommends oversight and advisory bodies across the lifecycle (126, OECD, 2025). The authority's records should answer what those bodies ask: the legal basis, who decided and on what evidence.

Decision tiers by risk class

The single most effective design decision is to tier decisions by risk class and route each to the lowest tier that can take it with the necessary evidence. Figure 13.2 shows four tiers.

Figure 13.2: Decision tiers by risk class. The policy routes routine decisions to pipeline gates, exceptions to a specialist forum, high-risk go-live to the AI governance board and decisions beyond appetite to the management body; every tier writes a decision record, and a decision escalates upward when a tier cannot take it.

Tier 1 gates decide routine matters; tier 2, the design authority or model risk committee, decides exceptions and precedent; tier 3, the AI governance board, decides high-risk go-live, residual risk and policy; tier 4, the management body, sets the appetite and accepts risks beyond it. Prohibited practices under Article 5 of the AI Act are not a tier: the policy rejects them at intake and no forum may approve them (1, European Union, 2024). The policy below expresses the tiers as data that the intake and deployment gates read; changing it is a tier 3 decision recorded as a pull request.

# governance/decision-tiers.yaml
policy: ai-decision-tiers
version: 1.4.0
owner: ai-governance-board
approved_by: management-body     # appetite statement RA-2026-02
tiers:
  1: {decided_by: pipeline-gate, record: evidence-log}
  2: {decided_by: [ai-design-authority, model-risk-committee], record: decision-record}
  3: {decided_by: ai-governance-board, record: decision-record}
  4: {decided_by: management-body, record: board-minute-and-decision-record}
routing:
  prohibited: {decision: reject_at_intake}   # AI Act Article 5
  minimal: {routine_change: 1, policy_exception: 2}
  limited: {routine_change: 1, new_use_case: 1, policy_exception: 2}
  high:
    routine_change: 1            # within approved configuration only
    model_or_provider_change: 2
    go_live: 3
    residual_risk_acceptance: 3
    policy_exception: 3
  any:
    risk_beyond_appetite: 4
    stop_system: incident-authority
    restart_after_stop: {high: 3, default: 2}
escalation:
  forum_deadlock_days: 10        # unresolved at tier 2 moves to tier 3
  waiver_max_days: {tier_2: 90, tier_3: 180}
consult:
  works_council: [high.go_live, any.workplace_monitoring]
  ethics_council: [high.go_live, any.profiling_of_natural_persons]
  data_protection_officer: [any.new_personal_data_purpose]

The routing reuses Chapter 8's risk class, the escalation block forces undecided items upwards, and the consult block records opinions without giving a vote.

Across the usage modes

The risk class decides the tier, but the usage mode of Chapter 2 (see the usage-mode matrix) decides what is approved and which forum normally sees it; team ownership per mode is set out in Chapter 12.

Usage mode	What the forum approves	Forum and usual tier
Mode 0 Ambient AI	Keeping a supplier-enabled feature	Procurement; tier 1, or tier 2 with personal data
Mode 1 Conversational assistants	Tool, settings and acceptable use	Design authority, tier 2 once
Mode 2 Embedded workplace assistants	Enablement and permission baseline	Design authority, tier 2; works council if monitoring
Mode 3 Agentic work tools	Tool permissions and repositories	Design authority, tier 2, with security
Mode 4 Built AI applications	Each use case	By risk class: tier 1, or tier 3 for high-risk go-live
Mode 5 Autonomous production agents	Delegated authority	Tier 2; tier 3 if high-risk, tier 4 beyond appetite

In Modes 0 to 3 the forum approves a configuration once; in Modes 4 and 5 it approves each system. The mode never lowers the tier the risk class sets.

Worked example: an escalation matrix by risk tier

Illustrative example. Nordvik Region's matrix adds a political tier: the regional executive committee, as the elected body, decides deployments that affect citizens' rights.

Situation	Minimal or limited risk	High risk	Beyond appetite or politically sensitive
Routine change within approved configuration	Pipeline gate	Pipeline gate	Pipeline gate, reported to tier 3
New use case or go-live	Pipeline gate	AI governance board, after design authority and rights review	Regional director, then regional executive committee
Exception to policy	Design authority, waiver up to 90 days	AI governance board, waiver up to 180 days	Regional director
Stop of a system	Incident commander or system owner	Incident commander or system owner	Same, regional director informed within 2 hours

Mandates, quorum, cadence, and evidence

A forum is defined by its mandate, membership and quorum, cadence, evidence and record. The mandate names the decisions the forum may take, those it may not, and where it escalates. Membership names roles, and quorum requires the roles whose consent the decision depends on: a model risk committee without the independent validator is not quorate whatever the number present. Cadence follows the decision flow rather than the calendar.

The evidence pack is generated from the registers, evidence store and incident log, pinned to a commit and limited to the agenda, which is itself a query, as Chapter 16 describes; a pack assembled by hand the night before reveals a gap in the evidence pipeline. The approval is a merged decision record with reasons, dissent, conditions and review date. A decision escalates when it exceeds the mandate, misses the deadline or lacks a consent; it never moves sideways to a parallel forum, which is how decisions disappear. The worked examples come from Hansa Mutual, whose EU entities are subject to DORA.

Worked example: terms of reference for an AI governance board

Illustrative example. Hansa Mutual's AI governance board sits at tier 3 and reports to the executive board, the management body for DORA purposes. The chief risk officer chairs and must consent; the data protection officer, CISO and internal audit attend without a vote.

# governance/forums/ai-governance-board.yaml  (Hansa Mutual, illustrative)
forum: ai-governance-board
tier: 3
chair: chief-risk-officer
mandate:
  decides: [high.go_live, high.residual_risk_acceptance, policy_change, waiver.tier_3]
  does_not_decide: [risk_beyond_appetite, prohibited_practice]
  escalates_to: executive-board
scope:
  applies_in: [DE, NL, SE, PL, NO, UK, CH]            # group policy and shared platform
  entity_boards_informed: [NL, SE, NO, UK, CH]        # subsidiaries keep their own legal duties
  employee_consultation_before_go_live: [DE, NL, SE]  # works council or union, national rules
membership:
  voting: [coo, cfo, head-claims, head-underwriting, head-ai-platform, chief-architect]
  consenting: [chief-risk-officer]            # decision invalid without consent
  advisory: [dpo, ciso, head-internal-audit, head-model-risk]
quorum: {min_voting: 4, required_roles: [chief-risk-officer]}
cadence: {synchronous: monthly, asynchronous_review: weekly, extraordinary: within 2 working days}
inputs: {evidence_pack: generated, max_pack_age_hours: 48}
outputs: {decision_record: "decisions/{yyyy}/{id}.yaml", report_to: executive-board}
conflicts_of_interest: declare_and_recuse
review_due: 2027-06-30              # charter lapses unless renewed

The design authority's tier 2 charter has the same shape: chaired by the chief architect, quorate only with the security architect present, and deciding on pull requests within five working days. The board's agenda is generated by a query, and each go-live item points to the classification, evaluation, validation, DPIA, FRIA, oversight assignment, training records and AI Decision Record.

Worked example: a filled-in decision minute

Illustrative example. The minute is a decision record merged into the governance repository. Hansa Mutual applies the high-risk regime as internal policy ahead of its application date of 2 December 2027 under the Digital Omnibus on AI.

# decisions/2026/DEC-2026-031.yaml  (Hansa Mutual, illustrative)
id: DEC-2026-031
forum: ai-governance-board
meeting: 2026-10-14
evidence_pack: governance@3e91b7d
subject: UC-2026-044 health underwriting triage assistant   # Annex III point 5(c)
related_records: [adr/AIDR-0212.md]
decision: approved_with_conditions
quorum:
  voting_present: [coo, cfo, head-underwriting, head-ai-platform, chief-architect]
  consenting: {chief-risk-officer: consent_given}
  recused: [head-claims]              # sponsor of a competing use case
reasons: >
  Evaluation meets tier thresholds; independent validation complete with two
  minor findings; oversight assigned to three named underwriters with
  completed training and authority to override; employee representatives informed.
conditions:
  - {id: C1, text: "Pilot limited to 20 per cent of new health applications in Sweden", owner: head-underwriting}
  - {id: C2, text: "Close validation findings MV-044-01 and MV-044-02", owner: head-model-risk}
dissent:
  - role: dpo
    note: Advises keeping applicant explanations for 24 months; retention policy to November meeting
residual_risk: {status: accepted_within_appetite}
stop_authority: [incident-commander, head-underwriting]
review_date: 2027-02-10
approved_by_merge: PR-1187

Reviewing the forums themselves

Forums decay: membership drifts, mandates overlap and bodies outlive their purpose. ISO/IEC 42001 requires internal audit and management review of the AI management system, of which the forums are part (32, ISO/IEC, 2023). Review them with the data the decision records already hold, such as lead time, the share of decisions taken by policy, reversals and waivers past expiry. A forum that takes no decisions for two quarters should be merged or closed, and a sunset clause in every charter forces explicit renewal.

Avoiding governance theatre

Governance theatre, the pattern Chapter 20 catalogues, is the condition in which forums perform oversight without exercising it: approvals nobody can trace to evidence and a high-risk system whose risk acceptance nobody can find. Four rules prevent it. A forum sees nothing the policy can decide; it decides on evidence it did not prepare; it has a deadline, after which the decision escalates; and a forum that never says no deserves as much scrutiny as one that always does, because both suggest the real decision is taken elsewhere.

Practical guides

The guides are written for the chief architect, head of risk or programme owner asked to put AI governance on a sound footing; adapt the defaults to the organisation's risk appetite.

Practical guide: designing the forum structure for an organisation

Purpose. Give every AI decision exactly one home, reusing existing forums where they work. Roles. Chief architect or AI architect (owner), chief risk officer, data protection officer, CISO, internal audit, legal function, employee representatives.

1. Inventory every forum that claims a say over AI, with its last ten decisions. Default: three weeks.
2. Map each decision type in the tier policy to the forum that takes it today, then assign each to one forum and one tier, reusing existing bodies first.
3. Identify the legal anchors, NIS 2 and DORA management-body duties, AI Act deployer duties, ISO management reviews and co-determination rights, and confirm the mapping with legal counsel.
4. Define the stop authority and restart rule before any agent reaches production, and test it in a tabletop exercise.
5. Commit a charter per forum in the format above, with a review date no more than eighteen months ahead, and have the management body approve the structure as a tier 4 decision record.

Definition of done. Every decision type maps to one forum with a validated charter; the stop authority is named and exercised; the management body's approval is on record.

Practical guide: building a decision-rights matrix by risk class

Purpose. Make decision rights by risk class visible and enforceable. Roles. AI architect (owner), chief risk officer, accountable executives, data protection officer, employee representatives.

1. Use Chapter 8's risk classes and the tier policy's decision types as the two axes, and name one decider per cell.
2. Give consent rights by default to the risk function on high-risk residual risk and to the data protection officer's documented opinion on any new purpose involving personal data.
3. Confirm for every high-risk system that Article 26(2) of the AI Act is met by named oversight roles with documented competence and authority, and add the consultation points required by co-determination law and Article 26(7).
4. Translate the matrix into repository ownership rules so that a record without the required approvals cannot merge, then test it with five recent decisions and one simulated incident.

Definition of done. Every cell has one decider; the repository rejects records lacking approvals; the oversight and stop roles for each high-risk system are named and trained.

Nordvik Region and Hansa Mutual

Nordvik Region's escalation matrix ends with the regional executive committee, whose minutes are public documents. Its forums are few because its portfolio is small, and their evidence must survive freedom-of-information requests and archiving. Employee representatives are consulted under one national regime, and for high-risk systems used at work Article 26(7) of the AI Act requires workers' representatives to be informed before use (1, European Union, 2024).

Hansa Mutual's group board reports to the executive board, and the scope block in its terms of reference records what the group forum cannot decide alone: each subsidiary board keeps its own legal duties, and consultation happens locally under different rules, from co-determination with the German works council under section 87(1) no. 6 of the Works Constitution Act where a tool can monitor employees (130, Germany, 2001) to union consultation in Sweden. A group decision is therefore final only when every affected entity's consultation is recorded. Nordvik's forums answer to elected members and the public; Hansa's answer to a group board, seven entity boards and several employee bodies.

Summary

Governance as code does not remove the need for forums; it changes what they are for. Pipelines enforce, observe and remember, while forums decide what pipelines cannot: the appetite, the policy, the exceptions, the acceptance of residual risk and the response when something goes wrong. Each forum, from the management body to the stop authority and the works council, has one mandate and one place in the decision path.

NIS 2 Article 20 and DORA Article 5 place oversight of cyber and ICT risk with a trained management body; the AI Act requires competent oversight persons with authority and the information of workers' representatives; ISO/IEC 27001 and 42001 require management review. A structure built on those anchors, with tiered decisions, generated evidence and every decision in version control, can show a supervisor who decided what on which evidence. However, the forums are only as good as the people in them, so Chapter 14 turns to those roles and to the skills and literacy that make them effective.

Sources

1. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
3. European Union Agency for Cybersecurity (2025). Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690 (version 1.0). ENISA, June 2025. (125, ENISA, 2025)
4. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
5. European Central Bank (2026). Addressing AI-enabled cybersecurity threats (letter to the chief executive officers of significant institutions, SSM-2026-0301). ECB Banking Supervision, 7 July 2026. (123, ECB, 2026)
6. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
7. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (27, European Union, 2026)
8. European Commission (2026). AI literacy: questions and answers. Shaping Europe's digital future, updated 20 October 2026. (133, European Commission, 2026)
9. European Banking Authority (2025). AI Act: implications for the EU banking and payments sector. EBA, 21 November 2025. (124, EBA, 2025)
10. European Central Bank (2025). ECB Banking Supervision: supervisory priorities for 2026–28. ECB Banking Supervision, November 2025. (119, ECB, 2025)
11. European Central Bank (2025). AI's impact on banking: use cases for credit scoring and fraud detection. Supervision Newsletter, ECB Banking Supervision, 20 November 2025. (120, ECB, 2025)
12. Machado, P. (2026). Technology is neutral, governance is not: AI adoption in the banking sector. Speech at the KPMG RiskTech Conference, Frankfurt, ECB Banking Supervision, 24 February 2026. (121, Machado, 2026)
13. Deloitte (2025). Governance of AI: A critical imperative for today's boards (second edition). Deloitte Global Boardroom Program, 2025. (131, Deloitte, 2025)
14. EY Center for Board Matters (2025). Cyber and AI oversight disclosures: what companies shared in 2025. EY, 14 October 2025. (132, EY, 2025)
15. European Central Bank (2026). ECB guide to internal models (version 4.1). ECB Banking Supervision, 26 June 2026. (122, ECB, 2026)
16. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
17. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Geneva: ISO, October 2022. (104, ISO/IEC, 2022)
18. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO, December 2023. (32, ISO/IEC, 2023)
19. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK (2026). Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (95, Five Eyes agencies, 2026)
20. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act), as last amended on 19 July 2024. Federal Ministry of Justice, Gesetze im Internet. (130, Germany, 2001)
21. Agency for Digital Government and Swedish Authority for Privacy Protection (2025). Inför en AI-policy (Introducing an AI policy), part of the national guidelines for the use of generative AI in public administration. Digg, published January 2025, updated 3 June 2026. (127, Digg & IMY, 2025)
22. Ministry of the Interior and Kingdom Relations, Netherlands (2026). Algoritmekader: governance (version 2.5). Government of the Netherlands, March 2026. (128, Dutch Ministry of the Interior, 2026)
23. Government Digital Service (2025). Algorithmic Transparency Recording Standard Hub. GOV.UK, updated 8 May 2025. (129, GDS & DSIT, 2025)
24. Organisation for Economic Co-operation and Development (2025). Governing with Artificial Intelligence: The State of Play and Way Forward in Core Government Functions. OECD Publishing, Paris, 2025. (126, OECD, 2025)
25. Nygard, M. Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (78, Nygard, 2011)
26. Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. & Gebru, T. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), pp. 220–229. (46, Mitchell et al., 2019)
27. Schlatter, J., Weinstein-Raun, B. & Ladish, J. (2026). Incomplete Tasks Induce Shutdown Resistance in Some Frontier LLMs. Transactions on Machine Learning Research; arXiv:2509.14260v2. (61, Schlatter et al., 2026)