AI Governance as Code

Chapter 8 made risk classification executable and kept the risk register in version control. This chapter builds the management system that consumes them, turning AI governance from a sequence of committee meetings into controls that run in pipelines, produce evidence, and can be audited without a workshop. It treats the AI management system of ISO/IEC 42001 as an operating model expressed in a repository, codifies the three policy families that matter most, namely model approval, data use, and deployment, and describes the AI inventory that feeds both the internal register and the public algorithm registers that European authorities increasingly maintain. Architecture as Code introduced Policy as Code (Chapter 10) and Governance as Code (Chapter 11) with the principle of assuring once and complying many times (66, Nordqvist, 2025); this chapter extends that principle to models, prompts, and agents.

Figure 9.1: The governance control loop. Policies in the repository drive pipeline gates; deployed systems emit evidence; the inventory and review functions consume it and feed changes back to the policies and to the exception records.

From committees to controls

Most AI governance programmes begin with a steering group, published principles, and a review board that approves AI use cases. Within a year the board has a backlog, teams have learned to describe their work in terms that avoid the board, and the organisation runs systems nobody has looked at. The board is not at fault; the mechanism is. A committee can decide, but it cannot enforce, observe, or remember at the pace of a delivery organisation that ships weekly.

Governance as code inverts the mechanism. The committee decides the rules, approves the interpretation of regulation, and reviews the evidence the rules produce; the pipeline applies the rules identically to every change, refuses what does not comply, and records what it did. Architecture as Code showed this for infrastructure, with Rego policies, pull-request approvals, and evidence published to an audit portal (66, Nordqvist, 2025). For AI the same structure applies to new objects: model versions, prompt configurations, evaluation results, risk register entries from Chapter 8, and threat models, the structured analyses of how a system could be attacked or misused. The committee still exists, but it meets to look at dashboards generated from evidence rather than at slides written to obtain approval.

ISO/IEC 42001 as a codified operating model

ISO/IEC 42001:2023 specifies requirements for an AI management system, following the harmonised structure shared with ISO/IEC 27001 and arranged as a Plan-Do-Check-Act cycle (32, ISO/IEC, 2023). Its Annex A lists controls covering AI policy, roles, resources, impact assessment, the AI system lifecycle, data, information for interested parties, responsible use, and third-party relationships. Every clause maps to an artefact that can live in a repository, and that mapping is the operating model.

ISO/IEC 42001 element	Repository artefact	Enforcement point
AI policy and objectives	governance/policy.md, versioned and signed	Referenced by every policy as code module
Roles and responsibilities	governance/roles.yaml	Pull-request approval rules, oversight role checks
Risk and impact assessment	Register and assessment records from Chapter 8	Deployment gate
AI system lifecycle	Pipeline definitions with gates	Every promotion
Data for AI systems	Data contracts for each dataset	Training and retrieval ingest
Information for interested parties	Model cards, system cards, register entries	Generated at release
Responsible use	Guardrail policies for inputs and outputs	AI gateway at runtime
Third-party relationships	Vendor assessment records from Chapter 7	Procurement gate
Performance evaluation and improvement	Evidence store, audit reports, metrics	Governance review

An ISO/IEC 42001 audit thus becomes a walk through the repository rather than an interview programme: asked how high-risk systems undergo impact assessment, the organisation shows the gate policy, its test suite, and the evidence log showing it ran for every deployment. The same mapping serves Article 17 of the AI Act, which requires providers of high-risk AI systems to maintain a quality management system covering design procedures, data management, risk management, post-market monitoring, and record keeping (1, European Union, 2024). ISO/IEC 42001 is not yet a harmonised standard carrying a presumption of conformity, which the CEN-CENELEC work in JTC 21 will determine (24, CEN-CENELEC, n.d.), but a codified 42001-aligned system answers much of Article 17 with artefacts that already exist.

Worked example: AI governance policy

Clause 5.2 of ISO/IEC 42001 requires top management to establish an AI policy (32, ISO/IEC, 2023). Here it is governance/policy.md, the one document every policy as code module cites, short enough to read in ten minutes and precise enough that each section maps to a gate, a role, or a record.

Illustrative example. The policy below belongs to Nordvik Region and is abridged. The tiers are those assigned by the classification policy in Chapter 8; the forums are defined, with their terms of reference, in Chapter 13.

# Nordvik Region AI governance policy

Version 2.1 | Approved by the Regional Director, 2026-03-18 | Review by 2027-03-31
Owner: Chief Digital Officer | Repository: governance/policy.md

## 1. Scope
Every AI system as defined in Article 3(1) of the AI Act that the Region builds,
buys, configures or uses, including AI features in purchased software, general-
purpose AI tools used by staff, and agents. Out of scope: rule-based automation.

## 2. Principles
2.1 We never use AI for practices prohibited by Article 5 of the AI Act.
2.2 A natural person is accountable for every AI system and every decision
    that affects a resident.
2.3 Residents are told when AI is involved in decisions about them.
2.4 Rules are enforced by pipeline gates; evidence is kept for every gate.

## 3. Risk tiers and approval path
| Tier       | Approval before use                                        | Review          |
|------------|------------------------------------------------------------|-----------------|
| Prohibited | Not permitted. No waiver possible                          | n/a             |
| High       | System owner, DPO and Governance Forum; FRIA and DPIA      | Every 6 months  |
|            | complete; Regional Director signs go-live                  | and on triggers |
| Limited    | System owner and DPO; disclosure tested                    | Every 12 months |
| Minimal    | System owner; registered in inventory                      | Every 24 months |
A system whose tier is unknown is treated as high until classified.

## 4. Inventory
Every AI system has a descriptor before production use. A deployed system without
a descriptor is handled as an incident. High-risk systems are registered in the
EU database (Article 49(3)) and the regional algorithm register before go-live.

## 5. Exceptions
Waivers are records in governance/waivers/, scoped to one rule and one system,
with compensating controls and an expiry of at most 90 days.
No waiver may suspend a prohibition, a FRIA, or human oversight.

Three choices are deliberate. The AI system owner is a named head of unit rather than the IT department, because accountability for purpose and harm sits with the business. An unknown tier defaults to high, which removes the incentive to delay classification. And the exceptions section lists what no waiver can touch, so the exception path cannot dismantle the controls the AI Act itself requires.

Policy as code for approval, data use, and deployment

Three policy families carry most of the governance weight, each a module evaluated by the same Open Policy Agent engine Architecture as Code uses (40, Open Policy Agent, n.d.). Model approval governs promotion in the model registry: a model version is approved only if its model card is complete, its evaluation meets the thresholds for its risk tier, its licence is allowed, its provenance attestation verifies, and its register entry is within appetite. Data use governs what may train, fine-tune, or ground a model: a data contract must exist, state a lawful basis for personal data, and declare a purpose compatible with the AI Decision Record. Deployment governs release to users: the gateway must reference an approved model, guardrails and logging must be on, a human oversight role must be assigned where the tier requires it, and an incident runbook must exist.

The approval policy below reads the model card, the evaluation report, and the register entry, and returns the decision with its reasons.

package ai.governance.model_approval

import rego.v1

default allow := false

thresholds := {
    "high": {"accuracy": 0.90, "max_subgroup_gap": 0.03},
    "limited": {"accuracy": 0.85, "max_subgroup_gap": 0.05},
    "minimal": {"accuracy": 0.80, "max_subgroup_gap": 0.10},
}

card_complete if {
    every field in {"intended_purpose", "training_data", "evaluation", "limitations", "owner", "risk_tier"} {
        input.model_card[field]
    }
}

meets_thresholds if {
    t := thresholds[input.model_card.risk_tier]
    input.evaluation.accuracy >= t.accuracy
    input.evaluation.subgroup_gap <= t.max_subgroup_gap
}

provenance_verified if input.attestation.slsa_level >= 2

register_in_appetite if input.register.status == "accepted_within_appetite"

allow if {
    card_complete
    meets_thresholds
    input.model_card.licence in data.allowed_licences
    provenance_verified
    register_in_appetite
}

deny contains "Model card incomplete" if not card_complete
deny contains "Evaluation below tier thresholds" if not meets_thresholds
deny contains "Provenance attestation missing or weak" if not provenance_verified
deny contains "Risk register entry not within appetite" if not register_in_appetite

Three properties make this a governance control rather than a script: the thresholds are data keyed by risk tier, changed through a reviewed commit; the policy has a test suite with fixtures for each tier and failure reason, so a change to it is itself governed; and every evaluation leaves a record of the input, decision, reasons, policy version, and commit, which is the evidence Chapter 11 assembles for auditors.

Worked example: deployment policy evaluated in CI

Illustrative example. Nordvik Region's deployment policy runs on every release. It reads the gateway configuration and the deployment request, together with approved models and trained oversight roles published by the registry and the training system.

package ai.governance.deployment

import rego.v1

default allow := false

approved_models := {m.id | some m in data.registry.models; m.stage == "approved"}

models_approved if {
    count(input.gateway.models) > 0
    every m in input.gateway.models { m in approved_models }
}

# Article 19 and Article 26(6): at least six months of logs.
logging_compliant if {
    input.gateway.logging.enabled == true
    input.gateway.logging.retention_days >= 183
}

oversight_assigned if input.system.risk_tier != "high"

oversight_assigned if {
    input.system.risk_tier == "high"
    data.roles[input.deployment.oversight_role].trained_members >= 2
}

guardrails_enabled if {
    input.gateway.guardrails.input_screening == true
    input.gateway.guardrails.output_screening == true
}

allow if {
    models_approved
    guardrails_enabled
    logging_compliant
    oversight_assigned
}

deny contains "Gateway references a model that is not approved" if not models_approved
deny contains "Input or output screening disabled" if not guardrails_enabled
deny contains "Logging disabled or retention below 183 days" if not logging_compliant
deny contains "High-risk system lacks a trained oversight role" if not oversight_assigned

The CI job runs the policy's own tests first, then evaluates the release, writes the decision to the evidence store, and only then enforces it. Recording before enforcing is the important ordering: a blocked release leaves the same evidence as an approved one, which shows an auditor that the gate actually refuses things. The minimum of two trained overseers is a Nordvik default so that holidays and sickness do not leave a high-risk system without one; adapt it to the size of the team.

For data use, Nordvik Region's standard STD-AI-002 sets what each data class may be used for with generative AI: public data in any approved tool, internal data only in the Region's tenant, confidential case data only in the staff assistant with pseudonymised logs kept for six months, and sensitive data only in a system specifically approved for it. The gateway reads the same matrix as data, so the table staff read and the rule the platform enforces cannot diverge, and a pull request that changes one without the other fails review.

data_handling_standard:
  id: STD-AI-002
  version: "1.3"
  classes:
    public: {allowed_systems: ["*"]}
    internal: {allowed_systems: [ai-system/staff-assistant, ai-system/office-assistant], tenant: nordvik-eu}
    confidential: {allowed_systems: [ai-system/staff-assistant], log_content: pseudonymised, max_content_retention_days: 183}
    sensitive: {allowed_systems: [], requires: [dpia, system_specific_approval]}
  supplier_terms: {training_on_customer_data: prohibited, processing_region: eu_eea}
  on_violation: block_and_alert

The AI inventory and the register

You cannot govern what you cannot enumerate, and the most common finding in AI governance assessments is that the organisation does not know how many AI systems it operates. The inventory should therefore be derived: every AI system, model, prompt set, and agent is declared in the repository as a descriptor, and the inventory is generated from those descriptors together with the deployment state the pipelines observe. A deployed system without a descriptor is a finding; a descriptor with no deployment is a candidate for retirement.

The inventory serves several masters. Internally it answers the governance forum's questions about tiers, owners, and review dates. Under Article 49 of the AI Act, providers of Annex III high-risk systems, and deployers that are public authorities, must register the system or its use in the EU database before the system is placed on the market, put into service or used, with the systems in point 2 of Annex III excepted (1, European Union, 2024). And a growing number of administrations publish algorithm registers; the Dutch government's Algorithm Register, which describes purpose, legal basis, data, human oversight, and risks in plain language, is the most developed European example (23, Dutch Ministry of the Interior, n.d.). Chapter 17 discusses the register as a public-sector obligation; here the point is that the public entry should be generated from the internal inventory, so that the two cannot diverge. A JSON Schema validates every descriptor and includes a publication block that controls which fields reach a public register.

Worked example: AI system inventory entry

Illustrative example. The descriptor below is for Nordvik Region's benefits-triage system, whose classification Chapter 8 walked through.

id: ai-system/benefits-triage
name: Benefits application triage
owner: head-of-social-services
role: deployer
risk_tier: high
annex_iii_area: "5(a) eligibility for essential public assistance benefits"
status: deployed
intended_purpose: >-
  Rank incoming applications for financial assistance by urgency so that
  caseworkers handle the most urgent first. The system does not decide
  eligibility; a caseworker decides every application.
legal_basis: >-
  National social assistance legislation; GDPR Article 6(1)(e) and
  Article 9(2)(g) for declared health information
models: [model/triage-gbm@3.2.1]
data_contracts: [DC-BEN-001, DC-BEN-004]
human_oversight: >-
  Senior caseworkers review the ranking daily and can re-order any case with a
  recorded reason; the queue reverts to date order if the service is stopped.
assessments: {dpia: DPIA-2026-007, fria: FRIA-2026-002}
eu_database_id: "EUDB-DEP-2026-004213"
publication:
  public_register: true
  public_fields: [name, intended_purpose, legal_basis, human_oversight, risk_tier, assessments.fria]
review_due: 2027-05-12

The intended_purpose states what the system does not do as well as what it does, because the negative statement is what an auditor and a resident most often need. The public_fields list is the only place that decides what reaches the public register, so an internal field cannot leak by accident. And the deployment gate rejects status deployed for a high-risk entry without an eu_database_id, which makes registration under Article 49(3) a precondition of go-live rather than a follow-up task.

Across the usage modes

Most AI in a large organisation is not designed by the organisation, and each usage mode is governed by a different primary artefact; matching artefact to mode keeps governance proportionate.

Mode	Primary governance artefact	Enforced at
Mode 0 Ambient AI	Scope clause of the AI policy; supplier-feature register	Procurement, contract renewal, tenant defaults
Mode 1 Conversational assistants	Acceptable-use policy and approved-tools list	Identity provider, network egress
Mode 2 Embedded workplace assistants	Tenant configuration, sensitivity labels, data-handling standard	Tenant settings held as code
Mode 3 Agentic work tools	Agent permission configuration; skills and connector catalogue	Catalogue promotion pipeline
Mode 4 Built AI applications	AI Decision Record and the full lifecycle gates	Every gate in this chapter
Mode 5 Autonomous production agents	Agent definitions, permission manifests, stop paths	Policy decision point on every tool call

The full gate set belongs to Modes 4 and 5; applying it to every Mode 1 request recreates the committee backlog this chapter opened with. Mode 0, at the other end, has no descriptor for the generator to read, which the section on AI the organisation did not choose addresses below.

Governance gates in the pipeline

A gate is a point in the lifecycle where a policy is evaluated and a change proceeds, is blocked, or is routed to a human. The gates below form the minimum set we recommend for an organisation operating high-risk systems; smaller programmes can collapse several into one.

Gate	Trigger	Policies evaluated	Human involvement
Intake	New AI Decision Record proposed	Classification, prohibited practices, appetite	Owner signs the descriptor
Design	Architecture and data design merged	Data use, oversight design, assessment presence	Risk and data protection review for high tier
Data	Training or retrieval dataset published	Data contract, lawful basis, provenance	Data owner approval
Promotion	Model version proposed for approval	Model approval, security scan, licence	Four-eyes approval for high tier
Deployment	Release to users requested	Deployment, guardrails, logging, oversight role	Accountable executive for high tier
Operation	Scheduled and event-driven	Register freshness, drift, incident status	Governance forum reviews exceptions
Retirement	System decommissioned	Record retention, model deletion, register update	Owner confirms

Two rules keep gates from becoming the committee in another form. A gate asks for a human only when the policy says so, never by default. And a gate never asks the same question twice: an assessment accepted at the design gate is an identifier the deployment gate checks for presence and freshness, not a document it re-reads.

Roles and accountabilities

Codified governance still needs people, and it needs them named. The roles file is the authority for who may approve what, and pull-request rules enforce it: an accountable executive owns each system and signs its risk acceptance, model and data owners approve model cards and data contracts, the risk function owns the appetite, the platform team owns the gates, and internal audit reviews the evidence rather than the systems.

Raji et al. describe an internal algorithmic audit framework, applied throughout the development lifecycle, in which each stage yields documents that together form the audit report (57, Raji et al., 2020); governance as code produces those artefacts as a by-product of delivery. The AI Act adds competence: Article 4 requires AI literacy among staff dealing with AI systems, and Article 26(2) requires deployers to assign human oversight to persons with the necessary competence, training, and authority (1, European Union, 2024). Encode the oversight role in the roles file, require evidence of training against it, and let the deployment gate check that it is filled.

Worked example: AI acceptable-use policy for staff

Most staff never see a gate or a register; what they see is the acceptable-use policy, which is also the first evidence of AI literacy under Article 4 that a supervisor will ask for. It must be readable in five minutes and consistent with the data-handling standard.

Illustrative example. The policy below is Nordvik Region's, abridged.

# Using AI at Nordvik Region: acceptable-use policy for staff

Version 1.4 | Owner: Chief Digital Officer | Applies to all staff and contractors

## Approved tools
| Tool                   | What it is for                              | Highest data class |
|------------------------|---------------------------------------------|--------------------|
| Staff assistant        | Internal guidance questions; drafting letters | Confidential     |
| Office suite assistant | Summarising and drafting internal documents | Internal           |
| Public AI chat services| Not approved for work use                   | None               |
Any other AI tool, including browser extensions, needs approval first.
If you are not sure of a data class, treat it as the higher class.

## Do
- Check every output before you use it. You are responsible for what you send.
- Tell residents when a letter was drafted with AI support, using the template sentence.
- Use the "report a problem" button when an output is wrong, biased or strange.

## Do not
- Do not let an AI tool decide anything about a resident. A person decides.
- Do not paste Confidential or Sensitive information into a tool not approved for it.
- Do not use AI to assess a colleague's performance or behaviour.
- Do not connect AI tools to mailboxes, case systems or files yourself.

## If something goes wrong
Report straight away through the service desk, category "AI incident".
Reporting quickly is expected and is not a disciplinary matter in itself.

## Training
Complete the 45-minute AI literacy course before access, and a refresher yearly.

The policy names tools, because staff act on names; it says who decides in the first "do not"; and it makes reporting safe, because an organisation that punishes the report of a mistaken paste learns about leaks from the press rather than from its staff.

Exceptions and waivers as records

Every governance system needs an exception path, and its quality shows in how exceptions are handled. In committee-based governance they are granted verbally and forgotten; in governance as code, a waiver is a record with a schema, and the gate accepts it only if it is valid, unexpired, approved by the role the policy names, and scoped to the specific rule that failed.

waiver:
  id: WAIVER-2026-007
  system: ai-system/claims-triage
  policy_rule: ai.governance.model_approval.provenance_verified
  justification: "Vendor model delivered without SLSA attestation; hash verified manually against vendor statement"
  compensating_controls: [CTRL-SEC-030, CTRL-MON-002]
  approved_by: head-of-model-risk
  approved_on: 2026-08-20
  expires_on: 2026-11-20
  review_action: "Require attestation in renewed vendor contract"

Waivers are also the richest governance metric: a policy with many waivers is either wrong or ahead of the organisation's capability, so the governance forum should see their count, age, and distribution at every meeting. An expired waiver is a blocked deployment, which concentrates minds on renewing or removing it.

Governing AI the organisation did not choose

The policy families above assume that someone proposed the system and that the proposal passed a gate. A growing share of AI never does: a records-management supplier adds automatic summarisation in a quarterly release, an office suite switches on a drafting assistant by default, or a human resources platform begins to rank candidates with a licensed model. No AI Decision Record exists, yet the organisation is now using an AI system under its authority, which makes it a deployer under Article 3(4) of the AI Act, and its processing of personal data may require a new assessment under Article 35 of the GDPR (1, European Union, 2024), (2, European Union, 2016). If the feature ranks job applicants, the use falls under Annex III whatever the organisation intended when it signed the licence.

Governance as code therefore treats the supplier's change as an event the organisation's pipeline must process. The contract obliges the supplier to announce AI features before enabling them, as Chapter 7 sets out. Tenant settings are exported on a schedule and compared with a recorded baseline, so that a feature switched on without notice appears as drift. And each discovered feature receives a descriptor and a decision, to keep, restrict or disable it, taken by the contract owner, with classification and data protection review triggered by the same rules as for a built system. Until the decision is recorded, the feature is an open risk on the register, not a tolerated default.

A group adds a further layer, because the decision to keep a feature in a shared tenant is taken once but its lawfulness is assessed per entity. At Hansa Mutual a drafting assistant switched on in the group tenant falls under the AI Act in the four EU entities and requires works-council consultation in Germany, the Netherlands and Sweden before any capability that can monitor employees is used there. The supplier-feature descriptor therefore carries the same applies_in list as a built system, so the deployment policy can disable the feature for one entity while consultation runs rather than leaving it enabled everywhere by default.

A public-sector consideration

For a public authority, governance as code has an additional audience: citizens and their representatives. Generating the EU database entry and the public register entry from the descriptor that the deployment gate evaluates means that what the authority tells the public is, by construction, what it has deployed. Few things damage trust faster than a public register that describes a system retired a year ago, or omits one still running.

Nordvik Region and Hansa Mutual

Nordvik Region's governance policy, deployment policy, data-handling standard and acceptable-use policy show governance as code under one legal regime. A single policy bundle encodes national administrative law and public-access duties alongside the AI Act, and the regional executive committee, as the elected body, can read the same policy files the pipeline enforces. Because the Region is mostly a deployer, much of its policy is enforced at the procurement and configuration boundary rather than in model code.

Hansa Mutual cannot write one policy and stop. The group policy set in Hamburg binds every entity, and each entity adds a national overlay as data: a Dutch works-council right, a German co-determination duty under the Works Constitution Act (130, Germany, 2001), or, for the United Kingdom and Swiss entities, the national rules that replace the AI Act and DORA. The deployment policy evaluates the group rules first and then every overlay in the system's applies_in list, so a release lawful in Germany but not yet assessed for Norway fails for Norway alone. As in Chapter 8, an overlay may add a control, never remove a group one. Where Nordvik's challenge is keeping its policy readable to elected members, Hansa's is keeping seven jurisdictions consistent without seven copies of the policy.

Summary

AI governance succeeds when the committee decides the rules and the pipeline applies them. Mapping ISO/IEC 42001 to repository artefacts and enforcement points makes the management system something the organisation runs rather than documents, and answers much of Article 17 of the AI Act with artefacts that already exist.

The policy families of model approval, data use, and deployment carry most of the weight, with thresholds as data and every decision recorded; the derived inventory feeds the forum, the EU database, and public registers; and waivers as records give an honest exception path and the most informative metric.

Governance as code establishes that the rules are applied, not that they are the right ones, that the system treats people fairly, or that the humans in the oversight role can actually intervene. Chapter 10 turns to those questions, translating the requirements for trustworthy AI, from transparency and fairness to human oversight under Article 14, into design decisions and codified evaluations.

Sources

1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
2. European Parliament and Council of the European Union (2016). 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. (2, European Union, 2016)
3. Ministry of the Interior and Kingdom Relations, Netherlands (2025). The Algorithm Register of the Dutch government. Government of the Netherlands. (23, Dutch Ministry of the Interior, n.d.)
4. CEN-CENELEC (2025). Joint Technical Committee 21 – Artificial Intelligence. CEN-CENELEC. (24, CEN-CENELEC, n.d.)
5. International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. ISO. (32, ISO/IEC, 2023)
6. Open Policy Agent Contributors (2025). Open Policy Agent Documentation. Cloud Native Computing Foundation. (40, Open Policy Agent, n.d.)
7. Raji, I. D., Smart, A., White, R. N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. & Barnes, P. (2020). Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing. Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency. (57, Raji et al., 2020)
8. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
9. 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)