Introduction to AI Governance

AI governance is the system of decisions, controls and evidence through which an organisation keeps its use of artificial intelligence within the intent it has declared. This chapter sets out what that discipline is, why AI breaks the assumptions of classical IT governance, and why European organisations feel the break sharply. It introduces three recurring tensions, the six usage modes of large language models and the two fictional organisations that run through the book, and it places the book within The Transformed Architecture.

The AI governance landscape: series foundations and five changes AI brings feed three governance disciplines, which produce evidence for boards and supervisors; three tensions act on the disciplines

Figure 1.1: AI governance takes the disciplines of the series as its foundation, responds to five changes that AI brings, organises its work in the disciplines of Parts II to IV and produces evidence for boards, supervisors and auditors, while navigating three recurring tensions (the table below).

Five changes AI brings Three recurring tensions
Probabilistic behaviour Speed versus control
Models derived from data Autonomy versus accountability
An opaque model supply chain Innovation versus sovereignty
Dense European law
Adoption that outruns control

Table for Figure 1.1: The five changes AI brings and the three recurring tensions.

What AI governance is, and what it is not

Failed AI governance programmes usually mistake one part of governance for the whole. AI governance is not a committee, because a forum that meets monthly cannot govern systems that change weekly. It is not a policy binder, because a policy that no control enforces is a statement of hope. It is not an ethics statement: the OECD Recommendation on Artificial Intelligence and the Council of Europe Framework Convention give a sound vocabulary for values (22, OECD, 2019), (21, Council of Europe, 2024), but a commitment to fairness says nothing about which system was tested against which threshold, with what result. Nor is it legal compliance alone, since many decisions that matter most, such as which assistant staff may use or how much authority an agent receives, fall outside the AI Act's high-risk categories.

Governance is the connection between those parts: the system that turns intent into decisions, decisions into controls and controls into evidence, and that feeds the evidence back to the people who must answer for the result. ISO/IEC 42001 describes an AI management system in similar terms, as the policies, objectives, processes, roles and controls through which an organisation directs its AI (32, ISO/IEC, 2023). However, the standard is deliberately silent on implementation, which is where most programmes falter.

A working definition

AI governance is the system of decisions, controls and evidence through which an organisation declares what it uses AI for, classifies and accepts the risks of each use, assigns accountability for it, enforces the resulting rules where the systems run, and demonstrates continuously that every AI system remains within its declared intent, its risk appetite and the law.

Of the five verbs, assigning means naming the natural persons who decide, oversee and answer, enforcing means controls that execute where the system runs, and demonstrating means evidence produced as a by-product of operation, so that a supervisor's question is answered by a query rather than a project.

The thesis of this book follows: governance of AI is most effective when it is expressed as code, with declared intent, classifications, policies, approvals, exceptions, decision records and evidence held in version control and executed in pipelines. It is the only arrangement I have seen that keeps pace with the systems it governs.

Why AI breaks the assumptions of classical IT governance

Five properties of AI systems invalidate assumptions on which IT governance has long rested.

From deterministic to probabilistic systems

Classical IT governance assumes that the same input and state yield the same output, so a change can be approved because its effect can be predicted. A classifier, however, returns a probability, and a large language model (LLM), a model trained on very large text corpora to produce language, returns one plausible continuation among many. Article 3(1) of Regulation (EU) 2024/1689, the AI Act, captures this by describing an AI system as one that infers from its input how to generate outputs such as predictions, content, recommendations or decisions (1, European Union, 2024), and ISO/IEC 22989 builds its vocabulary on the same distinction (34, ISO/IEC, 2022). A board therefore cannot approve "the system does X"; it can approve "the system does X with at least this accuracy on this population, and is withdrawn below that threshold". Each characteristic of trustworthy AI in the NIST AI Risk Management Framework has to become a measurable acceptance criterion with an owner, or it remains an aspiration (36, NIST, 2023).

The model as a derived artefact

Code is written; a model is derived from data, a training script, hyperparameters and often a random seed. Sculley et al. (2015) called this entanglement: changing anything changes everything, and data dependencies cost more than code dependencies because they are harder to detect (48, Sculley et al., 2015). Change control must therefore cover data as well as code, and because a model degrades silently as the world shifts, an approval granted once is not an approval for ever. Governance must define when a decision lapses, and monitoring must say when that happens.

A supply chain the organisation cannot inspect

Bommasani et al. (2021) coined the term foundation model for a model trained on broad data and adaptable to many tasks, and identified emergence, where capabilities appear that nobody designed, and homogenisation, where a defect in one upstream model propagates to many downstream systems (49, Bommasani et al., 2021). The organisation cannot inspect or reproduce a licensed foundation model, so it relies on the provider's documentation; for that reason Article 53 of the AI Act obliges providers of general-purpose AI models to maintain technical documentation, inform downstream providers and publish a summary of training content (1, European Union, 2024). Because state-of-the-art results increasingly come from compound systems of several models, retrievers and tools (52, Zaharia et al., 2024), supplier management becomes a first-order risk discipline, and it is the subject of Part II.

In Europe the regulatory position of an AI system is defined by overlapping instruments: the AI Act, the General Data Protection Regulation, DORA, NIS 2, sector law, public law and procurement law (1, European Union, 2024), (2, European Union, 2016), (3, European Union, 2022), (4, European Union, 2022). Obligations attach to roles, and ordinary technical decisions can change the roles, so the legal position has to be assessed when design choices are made rather than in a review at the end of a project.

Adoption that outruns control

AI reaches staff before it reaches the governance board. Classical IT governance assumed that systems arrived through a project, a procurement or a change request, yet much AI arrives through none of these doors. Governance must therefore start with discovery and offer approved alternatives fast enough that staff have no reason to look elsewhere.

The European context

Europe is a design constraint rather than a backdrop, and Chapter 3 treats the law in depth. The AI Act is risk-based: Article 5 prohibits a short list of practices, Article 6 and Annex III define high-risk AI systems in areas such as employment, credit, life and health insurance and access to essential services, Article 50 imposes transparency obligations, and Chapter V regulates general-purpose AI models (1, European Union, 2024). A provider places a system on the market under its own name; a deployer uses it under its own authority. Under Article 25, a deployer that rebrands or substantially modifies a high-risk system, or repurposes a system so that it becomes high-risk, takes on the provider's obligations, so fine-tuning a licensed model for a high-risk use is a change of legal position that governance must catch. The obligations apply in stages under Article 113, and the Digital Omnibus on AI of July 2026 postponed the high-risk obligations to December 2027 and, for systems in regulated products, to August 2028 (27, European Union, 2026). The GDPR applies in full alongside, so AI processing of personal data still needs a lawful basis under Article 6 and, where high risk is likely, an impact assessment under Article 35 (2, European Union, 2016).

Europe is also not a single legal space. Supervision under the AI Act is mostly national, as are the rules on penalties; EEA states such as Norway apply EU law only once it is incorporated into the EEA Agreement (187, EFTA, n.d.); the United Kingdom has a sector-led approach without a horizontal act (188, DSIT, 2023); and Switzerland relies on its revised Federal Act on Data Protection (190, Swiss Confederation, 2020). A group operating across these borders must label honestly which controls are law and which are group policy. Public authorities carry additional duties: a public-body deployer must complete a fundamental rights impact assessment (FRIA) under Article 27 and register its use under Article 49 (1, European Union, 2024). Because a citizen cannot take their business elsewhere, Chapter 17 is devoted to these readers.

Six usage modes in brief

"Using AI" covers implementations whose risk, controls, legal position and cost differ by orders of magnitude, so Chapter 2 defines six usage modes. Mode 0, ambient AI, is AI people meet without choosing it. Mode 1, conversational assistants, covers chat services into which a person pastes context. Mode 2, embedded workplace assistants, act on mail, documents and calendars with the user's permissions. Mode 3, agentic work tools, edit files and execute commands. Mode 4, built AI applications, are systems the organisation integrates into its own services, possibly becoming a provider under the AI Act. Mode 5, autonomous production agents, act on business systems without a person approving each step. An agent, in this book, is a system in which a model directs a sequence of tool calls towards a goal within limits set by its configuration.

Modes 0 to 3 are governed mainly through procurement, configuration, acceptable-use policy and AI literacy, because the organisation does not build the system; Modes 4 and 5 are governed through the full lifecycle. Chapter 2 compares the modes in its usage-mode matrix.

Three recurring tensions

Most governance decisions turn out to be a position on one of three tensions that recur in every AI programme I have worked on.

Speed versus control

Prohibition produces shadow AI, and permissiveness produces incidents. The resolution Architecture as Code proposed applies with particular force, because controls expressed as code execute at the speed of the pipeline (66, Nordqvist, 2025). Chapters 8, 9 and 11 make classification, approval and evidence executable.

Autonomy versus accountability

The more an AI system may do without a person in the loop, the harder it becomes to say who answers for what it did. Article 14 of the AI Act requires that high-risk systems be designed for effective human oversight, including the ability to intervene and interrupt, and Article 26 requires deployers to assign that oversight to natural persons with the competence, training and authority to exercise it (1, European Union, 2024). Accountability is therefore a matter of mandates, decision rights, approval gates and logs that attribute an agent's actions to a named owner, treated in Chapters 2, 9, 10 and 13.

Innovation versus sovereignty

The most capable foundation models and accelerator capacity are mostly supplied from outside Europe. Using them transfers data, dependency and control to jurisdictions, among them the United States, whose legal protections the Court of Justice of the European Union has twice found inadequate (20, CJEU, 2020). The AI Continent Action Plan sets out the Commission's response (16, European Commission, 2025). The governance task is to record a decision on model origin, hosting and exit for each use case, as Chapters 6 and 7 describe.

Across the usage modes

Mode Speed versus control Autonomy versus accountability Innovation versus sovereignty
Mode 0 – Ambient AI Suppliers switch features on faster than anyone reviews them People rely on output they never chose to use Data flows to a supplier's model without a decision
Mode 1 – Conversational assistants Shadow use grows where no approved tool exists Low: a person copies every output Prompts leave the organisation unless an enterprise tier is contracted
Mode 2 – Embedded workplace assistants The suite vendor sets the pace of change The assistant acts with the user's full permissions Tenant data is processed by the vendor's models
Mode 3 – Agentic work tools Developers adopt tools faster than policy follows Commands and file edits run on workstations and repositories Code and secrets are reachable by an external service
Mode 4 – Built AI applications The organisation sets the pace Oversight, logging and approval are designed in Model choice and hosting are the organisation's own
Mode 5 – Autonomous production agents Gates must run at pipeline speed Highest: actions on business systems without a person at each step Core operations depend on the model provider

Table 1.1: Where the three tensions bite hardest, by usage mode.

Purpose, readers and scope of this book

The book gives large European organisations, with public authorities as first-class readers, a working method for governing AI: deciding what AI is used for, managing its risks, meeting the AI Act and its neighbouring instruments, contracting suppliers, organising decision-makers and producing the evidence that all of this is true. It is written for people who must answer for AI without necessarily building it, and assumes familiarity with IT governance but no background in machine learning. Its baseline is the European Union acquis, with the United Kingdom and Switzerland treated where the examples require it. The book says what a model card must record and what an evaluation gate must prove, but it does not design the platform or engineer the defences. Nothing in it is legal advice: legal statements are attributed to the instrument and article and framed as governance implications.

How this book fits The Transformed Architecture

Architecture as Code, Book 1 of the series, argued that architecture becomes trustworthy when it is expressed as executable, version-controlled artefacts (66, Nordqvist, 2025). It developed policy as code (Architecture as Code (Chapter 10)), governance as code (Architecture as Code (Chapter 11)), compliance as an executable concern (Architecture as Code (Chapter 12)), risk as code (Architecture as Code (Chapter 9C)), evidence as code (Architecture as Code (Chapter 15A)) and management as code (Architecture as Code (Chapter 19)). This book applies those disciplines where they are hardest to apply, to systems whose behaviour is probabilistic, whose central artefact drifts and whose supply chain cannot be inspected.

The series' method also applies to how the books themselves are made. Most of the prose in this volume was drafted by specialist AI agents working under briefs, rules and automated checks that the author wrote, and every change reached the manuscript only after the author had reviewed and approved it. The judgements are the author's, and so is the responsibility. About the Author describes the arrangement and what it means for the reader.

Two organisations that run through this book

The worked examples follow two fictional organisations, so that the artefacts connect from chapter to chapter. Real legal instruments are named only to show which obligations apply.

Nordvik Region

Nordvik Region is a regional public authority in a Nordic member state of the European Union, with about 6,000 employees serving about 450,000 residents. It coordinates health and social care, public transport and needs-based financial assistance for its municipalities. Under the AI Act it is a deployer of a high-risk system: its procured benefits-triage system ranks applications for financial assistance by urgency, which falls within Annex III point 5(a), and so brings the duties of Article 26, the fundamental rights impact assessment of Article 27 and registration under Article 49 (1, European Union, 2024). Caseworkers decide every case. Its usual legal basis for processing personal data is the public task in Article 6(1)(e) of the GDPR, with special-category data under Article 9 in health and social care (2, European Union, 2016), and procurement follows Directive 2014/24/EU as transposed (9, European Union, 2014). It runs staff and citizen-service assistants and AI features in licensed software, but no autonomous production agents.

Hansa Mutual

Hansa Mutual is a mutual insurance group headquartered in Hamburg, with about 9,500 employees, writing property and casualty and motor insurance and, in some markets, life and supplementary health insurance. Its subsidiaries use a shared AI platform at headquarters under group policy.

Country Entity and role What changes for AI
Germany Headquarters, group IT and the shared AI platform Lead jurisdiction; co-determination with works councils
Netherlands Insurance subsidiary National supervisory expectations and works-council rights
Sweden Insurance subsidiary Language and consumer-information requirements; union consultation
Poland Claims and operations service centre Cross-border data flows for several markets
Norway Insurance subsidiary (EEA, not EU) EU law applies once incorporated into the EEA Agreement
United Kingdom Insurance subsidiary (outside the EU) No AI Act; UK data protection law and a sector-led approach
Switzerland Insurance subsidiary (outside the EU and EEA) No AI Act; Swiss data protection law and supervision

Table 1.2: Hansa Mutual's footprint (illustrative).

The AI Act, the GDPR and DORA apply directly in the EU entities, with national supervision, whereas the UK and Swiss entities sit outside the AI Act and DORA and Norway follows with a lag (1, European Union, 2024), (3, European Union, 2022). Hansa is a provider as well as a deployer, because it builds on vendor models, and its underwriting-support model for life and health products is high-risk under Annex III point 5(c). Its systems include a claims assistant built with retrieval-augmented generation, a claims-triage agent and an IT-operations agent with write access to production. A group AI governance board chaired by the chief risk officer reports to the executive board, the management body for DORA purposes.

The pair was chosen for contrast: Nordvik mostly procures, so its leverage is the contract, whereas Hansa mostly builds and must contain agentic work tools and autonomous production agents.

Worked example: a group AI governance charter

Illustrative example. The smallest artefact that shows the thesis of this book is a governance charter that a pipeline can read. Hansa Mutual's charter declares scope, where controls are law and where group policy, who decides and what evidence must exist; the forum's terms of reference follow in Chapter 13.

# governance/charter.yaml - Hansa Mutual group AI governance charter (illustrative)
apiVersion: governance.hansa.example/v1
kind: AIGovernanceCharter
metadata:
  version: 1.3.0
  approvedBy: executive-board
  approvedOn: 2026-06-18
spec:
  purpose: >
    Keep every AI system used by the group within its declared intent,
    the group risk appetite and the law of each market it serves.
  scope:
    usageModes: [0, 1, 2, 3, 4, 5]
    inventoryRequiredFrom: mode-0
  markets:
    - {code: DE, aiAct: law, dora: law}
    - {code: NL, aiAct: law, dora: law}
    - {code: SE, aiAct: law, dora: law}
    - {code: PL, aiAct: law, dora: law}
    - {code: NO, aiAct: group-policy-until-eea-incorporation, dora: group-policy-until-eea-incorporation}
    - {code: UK, aiAct: group-policy, localRegime: [uk-gdpr, pra-fca-expectations]}
    - {code: CH, aiAct: group-policy, localRegime: [revised-fadp, finma-expectations]}
  accountability:
    board: ai-governance-board
    chair: chief-risk-officer
    reportsTo: executive-board
  decisionRules:
    - classification precedes build, purchase or enablement
    - a change of purpose or substantial modification reopens classification
  evidence:
    decisionRecords: decisions/AIDR-*.md
    retentionMonths: 120

The markets block labels honestly that, for the Norwegian, UK and Swiss entities, AI Act controls are group policy rather than law. The decision rules give the pipeline something to check, so a system with a changed purpose and an unchanged classification fails before production (Chapters 8 and 9); the retention period follows AIDR-0022.

How to read this book

Part I, Foundations (Chapters 1 to 5), covers this introduction, the usage modes, the European legal map, eight principles and a readiness assessment. Part II, Sovereignty and Suppliers (Chapters 6 and 7), treats model origin and procurement. Part III, Risk, Governance, Trust and Assurance (Chapters 8 to 11), is the core of the method: risk classification, governance as code, transparency and oversight, and evidence and audit. Part IV, Organisation and Leadership (Chapters 12 to 17, with the companion Chapter 16A on AI economics), covers organisational design, forums, competence, change, Management as Code and public authorities. Part V, Experience (Chapters 18 to 21), presents case studies, the OpenAI–Hugging Face incident, anti-patterns and best practices, and Part VI (Chapters 22 to 25) looks ahead and draws conclusions. The appendices hold the glossary, an AI Act obligation mapping (Appendix A), a maturity model (Appendix B) and templates (Appendix C).

After Chapters 1 to 3, readers can take a shorter route.

Reader Start with Then
Chief risk officer Chapters 8, 11 and 16 Chapters 13 and 20
Compliance and internal audit Chapters 9 and 11, Appendix A Chapters 8 and 19
Data protection officer Chapters 3, 10 and 7 Chapters 8 and 17
Chief information officer Chapters 5, 12 and 16 Chapters 6, 7 and 21
Enterprise or chief architect Chapters 4, 9 and 14 Chapters 2 and 11
Governance board member Chapters 13, 8 and 16 Chapters 20 and 23
Senior public official Chapters 17, 10 and 15 Chapters 7 and 18

Table 1.3: Suggested reading routes by role.

Nordvik Region and Hansa Mutual

For Nordvik Region the main strain is adoption outrunning control, so its first moves are an inventory that reaches Mode 0, an approved staff assistant recorded in AIDR-0211, and an acceptable-use policy the platform enforces. Its benefits-triage system brings the full weight of Articles 26, 27 and 49, and FRIA-2026-002 recurs throughout the book. Its sharpest tension is innovation against sovereignty, because residents' data and public trust are at stake and it can influence suppliers only through contracts.

Hansa Mutual, by contrast, feels the strain in legal fragmentation and agents: one platform serves seven markets, its agents hold real authority in claims and IT operations, and sovereignty becomes a question of where each market's data may travel. Chapter 23 draws these trade-offs together.

Summary

AI governance is the system of decisions, controls and evidence that keeps AI within its declared intent. It is not a committee, a policy binder, an ethics statement or legal compliance alone, although it needs all four. AI strains classical IT governance in five ways: probabilistic behaviour demands measured thresholds; drifting models demand decisions that lapse; uninspectable supply chains shift trust to supplier governance; European law assigns obligations to roles that design choices can change; and adoption outruns control, so governance begins with discovery.

The book therefore expresses governance as code, so that the three tensions become explicit trade-offs made mode by mode and market by market. Chapter 2 now sets out the six usage modes, from ambient AI to autonomous production agents, and shows why their risks, controls and legal positions differ so widely.

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. 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)
  4. European Parliament and Council of the European Union (2022). 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. (4, European Union, 2022)
  5. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. Official Journal of the European Union. (9, European Union, 2014)
  6. European Commission (2025). AI Continent Action Plan. COM(2025) 165 final. (16, European Commission, 2025)
  7. Court of Justice of the European Union (2020). Judgment in Case C-311/18, Data Protection Commissioner v Facebook Ireland Limited and Maximillian Schrems (Schrems II). 16 July 2020. (20, CJEU, 2020)
  8. Council of Europe (2024). Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law (CETS No. 225). (21, Council of Europe, 2024)
  9. Organisation for Economic Co-operation and Development (2024). Recommendation of the Council on Artificial Intelligence (OECD/LEGAL/0449). (22, OECD, 2019)
  10. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union. (27, European Union, 2026)
  11. International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. ISO. (32, ISO/IEC, 2023)
  12. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 22989:2022 Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. ISO. (34, ISO/IEC, 2022)
  13. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. (36, NIST, 2023)
  14. Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28. (48, Sculley et al., 2015)
  15. Bommasani, R. et al. (2021). On the Opportunities and Risks of Foundation Models. Stanford Center for Research on Foundation Models. (49, Bommasani et al., 2021)
  16. Zaharia, M. et al. (2024). The Shift from Models to Compound AI Systems. Berkeley Artificial Intelligence Research blog. (52, Zaharia et al., 2024)
  17. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. Published at aac.geon.se. (66, Nordqvist, 2025)
  18. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (187, EFTA, n.d.)
  19. Department for Science, Innovation and Technology and Office for Artificial Intelligence (2023). A pro-innovation approach to AI regulation (CP 815). UK Government, 29 March 2023. (188, DSIT, 2023)
  20. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (190, Swiss Confederation, 2020)