AI Governance: teacher's guide

All courses / AI Governance / Teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on AI Governance: the lecture of each module with a timed outline, the teaching plan of every lesson, the discussion questions, the exercises and the answers to the self-tests. The agendas of the three formats are on the course page; the slides are in the deck of the book.

Executive briefing (90 minutes): A briefing on what a management body must decide and be able to show. It covers the definition of AI governance, the usage modes, what the AI Act asks of a provider and a deployer, the decision tiers and the stop authority, and what a risk report against appetite looks like, and it ends with the eight conclusions and the first horizon of the phased programme.
One-day seminar (1 day): A working day that walks one use case through the method: placed in a usage mode, classified, bought or built under an origin policy and a contract, passed through governance gates, given designed oversight and left with evidence. The afternoon turns to forums, stop authority, portfolio and cost, and ends with a tabletop exercise and a plan for the first ninety days.
Full course (8 weeks, one session of three to four lessons a week): The full course covers all 26 lessons in the order of the book, with an exercise in every lesson that produces an artefact of the kind the chapter describes. The long Part IV is spread over two weeks and Part III over two. Participants build up a governance repository for their own organisation, or for Nordvik Region or Hansa Mutual, and submit it as the capstone.

Keynote on the whole book · 45 minutes

AI governance that can be executed, checked and proven

For executives, board members, architects and risk, compliance and data protection professionals in European enterprises and public authorities

The lecture presents the argument of AI Governance in one sitting. AI breaks assumptions that classical IT governance relied on: behaviour is probabilistic, the central artefact drifts, the supply chain cannot be inspected, European law assigns obligations to roles that design choices can move, and adoption outruns control. The answer is governance that is codified, evidenced and proportionate to usage mode and risk. The lecture shows what that means for classification, suppliers, oversight, forums and money, using a regional public authority and a mutual insurance group as examples, and ends with what to do in the first six months.

6 min	Why AI breaks classical IT governance A board cannot approve that a system does X, only that it does X with a stated accuracy on a stated population and is withdrawn below that threshold. Models drift, supply chains cannot be inspected, and ordinary technical decisions can change the organisation's legal role. Governance is the connection that turns intent into decisions, decisions into controls and controls into evidence.
7 min	The usage mode, not the brand, sets the governance Six usage modes, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, differ in what the model sees, what it can do and under which identity. Use cases drift between modes, so governance attaches to the use case and treats a change of mode as a change event. Each mode has its own primary artefact, from a supplier-feature register to a permission manifest with a tested stop path.
8 min	Classification, suppliers and the contract Almost every obligation in the AI Act follows from a classification, and classification is triggered by change, not by the calendar. Sovereignty is a risk-tiered choice: how a model is run moves risk between categories, and a drilled exit with a second source keeps the choice reversible. The contract is a deployer's main control, and a clause without an enforcing control is a promise that cannot be verified.
9 min	The committee decides, the pipeline applies A committee can decide but cannot enforce, observe or remember at delivery pace; pipelines cannot decide what has not already been decided. Decisions are tiered by risk class, each with exactly one home, and forums decide on evidence they did not prepare. Human oversight is designed as a mechanism: workload, visible uncertainty, measured override rates and a stop function that reaches a safe state. Evidence is a by-product of delivery, signed and retained, from which documentation, registers and reports are generated.
8 min	People, money and agents Accountability for a use case stays in the line of the business that owns it; adoption is designed and measured, and consultation commitments become controls. A use case is a falsifiable value hypothesis; cost follows consumption, so one named person holds the envelope and the benefit together. Containment of agents must not depend on intent: boundaries in code outside the model, and named people who may stop a workload alone.
7 min	Two organisations and the first six months Nordvik Region resolves every conclusion into one policy, one register and one escalation path; Hansa Mutual into a group baseline with market overlays. What helped both recorded a decision in advance: a retirement criterion, a stop authority, an expiring exception, a drilled exit plan. First: an inventory by usage mode, a classification wired to change, a decision-tier file and named stop holders.

What the audience takes away

AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk.
Give every AI decision exactly one home and let the people there decide on evidence that a pipeline produced.
Bound what AI systems can do in code outside the model, keep a tested way out, and name who can stop them.

Module 1 · Part I · Foundations

Module 1 lays the foundations of the method. It defines AI governance as a system of decisions, controls and evidence, introduces the six usage modes of large language models, maps the AI Act and its neighbouring instruments for architects, sets out eight principles with executable verifications and closes with a readiness assessment kept as a scorecard. Participants leave able to place any AI use in a mode, a regulatory position and a readiness score.

Lecture · 45 minutes

Foundations: from declared intent to evidence

Part I argues that AI governance fails when one of its parts, a committee, a policy binder, an ethics statement or legal compliance, is mistaken for the whole. The lecture follows the argument in five moves: why AI breaks the assumptions of classical IT governance, why the way a model is used matters more than the model, how to read the AI Act as a product safety law, how eight principles become checks a pipeline can run, and why readiness is judged before budget is committed. Nordvik Region and Hansa Mutual are introduced as the two organisations that carry the examples.

8 min	Governance is the connection, not one of the parts AI governance is the system that turns intent into decisions, decisions into controls and controls into evidence, and feeds the evidence back to those who answer for the result. Five changes strain classical IT governance: probabilistic behaviour, models derived from data, an opaque model supply chain, dense European law and adoption that outruns control. The thesis of the book: governance works best expressed as code, held in version control and executed in pipelines.
10 min	Six usage modes instead of one word, AI What changes between modes is how far output travels before a person looks at it, what the model can see and what it can do. Mode 0 Ambient AI to Mode 5 Autonomous production agents: each has its own typical failure, control artefact and cost model. Use cases drift between modes, so governance attaches to the use case and treats every change of mode as a change event.
9 min	The AI Act read as a product safety law Four tiers: prohibited practices, high-risk AI systems, transparency obligations and general-purpose AI models. Obligations follow roles, and roles move under Article 25 when a deployer rebrands, substantially modifies or repurposes a system. One set of controls has to serve the AI Act, the GDPR, DORA and NIS 2, read by several authorities from the same evidence.
9 min	Eight principles a pipeline can verify Intent, trust, control and constraints: four groups, eight principles, each with at least one machine-performable verification. Depth of evidence scales with risk class: four principles for minimal risk, all eight for high risk. Conflicts between principles are resolved in a fixed order and recorded as a decision or a time-limited exception.
9 min	Readiness before budget, and two organisations Pilots succeed on hand-made workarounds that collapse at scale; the scorecard lists what will break. Six dimensions scored 0 to 4 with evidence, with a minimum that acts as a gate and not a target. Nordvik Region mostly procures and its leverage is the contract; Hansa Mutual mostly builds and must contain agents across seven markets.

What the audience takes away

Governance is a system of decisions, controls and evidence; a committee, a policy or a compliance exercise alone is not governance.
Classify every AI use by usage mode and by AI Act role before choosing controls, because both can change through ordinary technical decisions.
A principle or a readiness score counts only when it cites evidence and a check that can fail.

Chapter 1 · 60 minutes

Introduction to AI Governance

The lesson defines AI governance as the system of decisions, controls and evidence that keeps AI within its declared intent, and separates it from the four things it is often mistaken for. Participants examine the five properties of AI that break classical IT governance, the three recurring tensions, and the two fictional organisations, Nordvik Region and Hansa Mutual, including Hansa's group governance charter.

Learning objectives

Explain the working definition of AI governance and its five verbs: declare, classify and accept, assign, enforce and demonstrate.
Distinguish AI governance from a committee, a policy binder, an ethics statement and legal compliance alone.
Describe the five ways in which AI invalidates assumptions of classical IT governance.
Analyse a governance decision as a position on one of the three recurring tensions.

Key concepts

AI governance: The system of decisions, controls and evidence through which an organisation declares what it uses AI for, classifies and accepts the risks, assigns accountability, enforces the rules where the systems run and demonstrates continuously that every AI system stays within its declared intent, its risk appetite and the law.
Five changes AI brings: Probabilistic behaviour, models derived from data, a supply chain the organisation cannot inspect, a dense European legal framework and adoption that outruns control. Each invalidates an assumption on which IT governance has long rested.
Three recurring tensions: Speed versus control, autonomy versus accountability and innovation versus sovereignty. The chapter holds that most governance decisions turn out to be a position on one of them, taken mode by mode and market by market.
Governance as code: The book's thesis: declared intent, classifications, policies, approvals, exceptions, decision records and evidence are held in version control and executed in pipelines, so that governance keeps pace with the systems it governs.
Group AI governance charter: Hansa Mutual's pipeline-readable charter. It declares scope across usage modes 0 to 5, labels per market whether AI Act controls are law or group policy, names the accountable board and chair, and states decision rules and evidence retention.

Teaching plan

10 min	Opening: participants write down what AI governance means in their organisation today; the teacher sorts the answers into committee, policy binder, ethics statement, legal compliance and something else.
15 min	Teacher presentation of the working definition, the five changes AI brings and the three tensions, using Table 1.1 on where the tensions bite hardest by usage mode.
10 min	Walk through Nordvik Region and Hansa Mutual: size, AI Act roles, Hansa's seven-market footprint and why the pair was chosen for contrast.
20 min	Exercise in pairs: draft a governance charter skeleton for the participant's own organisation, modelled on Hansa Mutual's charter.
5 min	Debrief: two pairs read out their decision rules; the group checks whether a pipeline could test each one.

Discussion

Which of the five changes AI brings puts most strain on the governance your organisation already has, and what would a supervisor notice first?
The chapter says a board cannot approve that a system does X, only that it does X with at least a stated accuracy on a stated population. How would that change the way approvals are worded where you work?
Nordvik Region's sharpest tension is innovation against sovereignty and Hansa Mutual's strain lies in legal fragmentation and agents. Which organisation does yours resemble, and why?

Exercise · 20 minutes

Draft a governance charter a pipeline can read

Using Hansa Mutual's group AI governance charter as the model, draft the skeleton of a charter for your own organisation. State the purpose in one sentence, the usage modes in scope and the mode from which an inventory entry is required, each market or legal entity with a label saying whether AI Act controls apply as law or as group policy, the accountable forum, its chair and the body it reports to, two decision rules that a pipeline could check, and where decision records are kept and for how long. Mark every item you could not fill in.

Deliverable: A one-page charter skeleton with purpose, scope, markets, accountability, two checkable decision rules and evidence retention, with open items marked.

Self-test

Why does the chapter say that AI governance is not a committee?
1. Because committees are not recognised by the AI Act as accountable bodies
2. Because a forum that meets monthly cannot govern systems that change weekly
3. Because committee members usually lack a background in machine learning
4. Because ISO/IEC 42001 requires a single accountable executive instead
In Hansa Mutual's charter, how are AI Act controls labelled for the UK and Swiss entities?
1. As law, because the group is headquartered in Hamburg
2. As not applicable, because both sit outside the Union
3. As group policy, because the AI Act does not apply there
4. As law from the date of EEA incorporation
What follows, according to the chapter, from the fact that a model is derived from data and degrades silently as the world shifts?
1. Governance must define when an approval lapses, and monitoring must say when it does
2. Every model must be retrained on a fixed quarterly schedule that the governance board approves in advance
3. Models may only be approved once the provider guarantees stable behaviour
4. Change control can be limited to code, since data changes cannot be predicted

Chapter 2 · 90 minutes

From Chat to Agents: How Large Language Models Are Used

The lesson teaches the six usage modes of large language models, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, as an architectural taxonomy. Participants compare what the model sees, what it can do and under which identity in each mode, recognise mode drift, and apply the minimum control baseline and the classification questions of the chapter's practical guide to a usage-mode register.

Learning objectives

Classify an AI use case into one of the six usage modes using the chapter's ordered questions.
Compare the modes by what the model sees, what it can do, identity, human role and control artefact.
Explain mode drift and why governance attaches to the use case and not to the tool or the brand.
Assign the minimum control baseline of a mode and mark its controls as met, partly met or missing.

Key concepts

Usage mode: One of six ways a large language model is used, defined by architecture and not by product: by depth of integration and by the autonomy granted to the model's output. The usage mode is part of the declared intent of every AI use case.
Shadow AI: Staff signing in to a consumer tier with a private account, which moves organisational data outside every contract the organisation holds. It starts in Mode 1 because the barrier to use is a browser tab.
Excessive agency: OWASP's term for an agent that holds more permission than its task needs. Combined with untrusted input it is the core risk of Mode 3 Agentic work tools.
Mode drift: The movement of a use case from one mode to another, for example a prompt that becomes a shared skill, a product and then an automation. The failure is that the controls stay where the use case started.
Minimum control baseline: A floor of controls per mode, where the higher modes inherit those of the lower ones. The risk class of Chapter 8 adds controls on top, and an organisation with a low risk appetite raises the floor.

Teaching plan

10 min	Opening: participants list every way AI is used in their organisation; the teacher shows that one word covers uses whose risk and controls differ by orders of magnitude.
25 min	Teacher presentation of the six modes, one at a time: definition, typical failure, control artefact and cost model, ending with the comparison in Table 2.1.
10 min	Group discussion of mode drift and of one vendor spanning several modes, using the consultation-summary example that travels from Mode 1 to Mode 5.
35 min	Exercise in groups of three: build a usage-mode register for five use cases, classify each with the ordered questions and assign the baseline of Table 2.2.
10 min	Debrief: groups compare the entry they found hardest to classify and apply the rule that, when in doubt, the higher mode is chosen.

Discussion

Which Mode 0 features have suppliers switched on in your organisation in the last year, and who would have known that the data processing changed?
The chapter recommends writing approvals as service X, tier Y, mode Z, for data classes up to C. What would have to change in your current approval process to do that?
Nordvik Region permits no Mode 5 and limits Mode 3 to its platform team, while Hansa Mutual uses every mode. What does each choice cost, and what does it protect?

Exercise · 35 minutes

Build a usage-mode register

Take five AI uses from your own organisation, or use Nordvik Region's: meeting recaps switched on by a supplier, drafting in the approved enterprise chat tool, a coding agent for the platform team, an internal staff assistant and the procured benefits-triage system. Group them into use cases, not tools. Classify each with the chapter's questions in order: was the use chosen, does the model act on business systems without approval of each action, did the organisation build or integrate it, does it execute tools, does it retrieve organisational content on its own. Record vendor, tier, data classes, identity, owner and AI Act role, then assign the baseline for the mode and mark each control met, partly met or missing.

Deliverable: A register of five use cases with mode, identity, owner, AI Act role and baseline status, and the three gaps to act on first in order of exposure.

Self-test

According to the chapter's classification steps, which mode should be chosen when it is unclear which of two modes a use case belongs to?
1. The mode the vendor names in its product documentation
2. The lower mode, to avoid unnecessary controls
3. The mode in which the use case first started
4. The higher mode
What does the chapter identify as the defining property of Mode 5 Autonomous production agents?
1. Identity, because what the agent acts as determines the blast radius
2. The size of the underlying model, because larger models take more actions
3. The vendor platform, because agent platforms differ in their safety features
4. Cost, because consumption scales with the number of users
Why is a brand name a poor unit of governance, according to the chapter?
1. Because vendors change their brand names faster than policies can be updated
2. Because brands cut across the modes and data terms differ by feature within one brand
3. Because the AI Act forbids approvals that refer to commercial product names
4. Because the same brand always runs on different models in different regions

Chapter 3 · 75 minutes

The EU AI Act and the European Regulatory Landscape

The lesson gives a working map of European AI law for architects. Participants read the AI Act as a product safety law with four tiers, trace how roles move under Article 25, place the staged application dates, relate the Act to the GDPR, DORA, NIS 2, the Data Act and the Cyber Resilience Act, and codify one system's regulatory position as a versioned record.

Learning objectives

Explain the risk-based structure of the AI Act: prohibited practices, high-risk AI systems, transparency obligations and general-purpose AI models.
Determine whether an organisation is provider or deployer of a system and identify what would move the role under Article 25.
Map the requirements of Articles 9 to 15 to architectural components and the evidence each produces.
Draft a regulatory position record for one AI system.

Key concepts

Product safety law: The style in which the AI Act is written: it defines a product category, assigns obligations to economic operators by role, requires conformity assessment before market placement and establishes market surveillance afterwards. Reading it this way is the first step to reading it well.
Provider and deployer: Roles defined in Article 3. The provider develops a system and places it on the market or puts it into service under its own name; the deployer uses a system under its authority in a professional context.
Roles that move: Under Article 25 a deployer becomes a provider if it puts its name on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk.
Presumption of conformity: Under Article 40, conformity with a harmonised standard published in the Official Journal creates a presumption of conformity. The chapter advises keeping the mapping from control to clause as data, so that new standards change the mapping and not the architecture.
Regulatory position: A versioned record in the architecture repository stating, for one system, the AI Act role and rationale, risk tier, applicable articles, GDPR lawful basis, sector instruments, supervisors and the triggers for the next review.

Teaching plan

10 min	Opening: why architects need their own map. The teacher contrasts reading law for liability with reading it for structure: components, records and reviewable decisions.
20 min	Teacher presentation of the four tiers, Table 3.1 from requirement to component to evidence, the roles and the timeline of application including the Digital Omnibus on AI.
10 min	Group work on adjacent instruments: each group takes the GDPR, DORA and NIS 2, or the Data Act and Cyber Resilience Act, and names one control that serves both it and the AI Act.
25 min	Exercise: participants draft a regulatory position record for one system, modelled on the benefits-eligibility-support example.
10 min	Debrief: pairs exchange records and check that every applicable article has a mapped control and a stated review trigger.

Discussion

Which ordinary technical decision in your organisation, such as fine-tuning, rebranding or reusing a system for a new purpose, could move you from deployer to provider without anyone noticing?
The chapter says the controls in Table 3.1 take longer to build than any plausible delay of the high-risk obligations. How should that shape planning after the postponement to December 2027?
Hansa Mutual applies AI Act controls as policy where the law does not yet require them. What are the arguments for and against doing so in a group that spans the Union, the EEA, the United Kingdom and Switzerland?

Exercise · 25 minutes

Codify a regulatory position

Choose one AI system in your own organisation, or take Nordvik Region's procured benefits-triage system. Write its regulatory position as a structured record with the fields of the chapter's example: the AI Act role and a one-line rationale, the risk tier and, if relevant, the Annex III area, the applicable articles, whether a fundamental rights impact assessment and registration are required, the GDPR lawful basis and whether special categories are processed, the Article 22 safeguard, sector instruments such as NIS 2 or DORA, the supervisors that may read the record, and the events that trigger the next review. Then list one pipeline check that should fail if the record is incomplete.

Deliverable: A completed regulatory position record for one system and one proposed pipeline check with the condition that makes it fail.

Self-test

Under the Digital Omnibus on AI, as the chapter reports it, from which date do the Annex III high-risk obligations apply?
1. 2 August 2026
2. 2 August 2027
3. 2 December 2027
4. 2 August 2028
How does the chapter propose to resolve the pull between Article 12 record-keeping in the AI Act and storage limitation in the GDPR?
1. By keeping logs only for systems that process no personal data at all
2. By a retention policy that keeps the required logs and minimises personal data in them
3. By asking the data protection authority for an exemption for each system
4. By deleting all logs after six months, whatever the system's risk tier or the instrument that applies
Where the regulatory map meets engineering, how does the chapter divide the work?
1. Engineering states the obligation and governance selects the tools to meet it
2. Legal counsel owns both the requirement and the technical means
3. The model provider owns the means and the deployer owns nothing
4. Governance owns the requirement and engineering owns the means

Chapter 4 · 75 minutes

Fundamental Principles

The lesson presents eight principles of AI Architecture in four groups, intent, trust, control and constraints, each anchored in the AI Act and each with a verification a machine can perform. Participants scale the principles by risk class, study the recurring conflicts between them and the fixed order for resolving them, and write a principles statement and a recorded exception in the manner of Nordvik Region and Hansa Mutual.

Learning objectives

State the eight principles and the verification that proves each one.
Apply the scaling rule that selects principles by risk class.
Resolve a conflict between two principles using the chapter's fixed order.
Draft a time-limited exception to a principle with compensating controls and an expiry date.

Key concepts

Declared intent: Principle 1: every AI system has a codified statement of its purpose, its scope and the uses that are prohibited, and that statement is the reference against which classification, evaluation and oversight are measured.
Bounded autonomy: Principle 4: every AI system, and every agent in particular, operates within explicit limits on actions, resources and decisions without a person, and those limits are enforced outside the model by components it does not control.
Scaling by risk class: The depth of evidence follows the AI Act's gradient. In the principles manifest a minimal-risk system is held to P1, P2, P7 and P8, a limited-risk system adds P5, and a high-risk system is held to all eight.
Order for resolving conflicts: A legal obligation first; then protection of the people affected over efficiency; then the option that is easier to reverse; finally the outcome is recorded as a decision or a time-limited exception in the AI Decision Record.
Principle exception: A record such as Hansa Mutual's EXC-0004 that names the requirement it relaxes, lists compensating controls, states residual risk and who accepted it, and expires. The pipeline treats an expired exception as a failing check.

Teaching plan

10 min	Opening: the teacher asks which principles in participants' current AI policy have ever changed a decision, then states the chapter's test that a principle earns its place only if it does.
20 min	Teacher presentation of the eight principles by group, with the AI Act anchor and the verification for each, and the scaling block of the principles manifest.
10 min	Group discussion of Table 4.1, the recurring tensions, with attention to lineage against data minimisation and the resolution by reference and hash.
25 min	Exercise in pairs: write three lines of a principles statement with control and test, then record one exception with compensating controls.
10 min	Debrief: each pair presents its exception; the group checks for a named requirement, compensating controls, an acceptor and an expiry date.

Discussion

Nordvik Region expects quarterly override rates between 2 and 30 per cent, or a recorded explanation. Why is a rate near zero treated as a warning, and what would you expect to find behind it?
The chapter says a model cannot be trusted to respect limits it is merely told about. Where in your organisation are limits on an AI system stated only in a prompt or an instruction?
Hansa Mutual keeps one group statement that national entities may tighten but never weaken. What would be lost and gained if each market wrote its own principles instead?

Exercise · 25 minutes

A principles statement and a recorded exception

Part one: following Nordvik Region's one-page statement, choose three of the eight principles and write for each a line with four columns: what the organisation commits to, the control that enforces it, and the test that proves the control works, with a frequency. Part two: pick one principle your organisation cannot currently meet in full for a specific system, as Hansa Mutual cannot meet P3 for a hosted model. Record an exception in the form of EXC-0004: the principle and requirement relaxed, the reason, at least three compensating controls, the residual risk, the role that accepts it and an expiry date no more than twelve months ahead.

Deliverable: Three statement lines with control, test and frequency, and one exception record with compensating controls, acceptor and expiry date.

Self-test

In the chapter's principles manifest, which principles apply to a minimal-risk system?
1. P1, P2, P7 and P8
2. P1, P4, P6 and P7
3. P1, P2, P3 and P5
4. All eight, with lighter evidence
How does the chapter resolve the tension between Principle 3, lineage, and data minimisation under the GDPR?
1. By exempting systems that process personal data from tracing altogether
2. By keeping full copies of the inputs behind every output, but only for a short and fixed retention period
3. By tracing by reference and hash, so that personal data stays in the system of record
4. By asking each data subject to consent to the storage of traces
Why does Hansa Mutual's exception EXC-0004 carry an expiry date?
1. Because DORA limits every contractual exception to one calendar year
2. Because the provider's contract for the hosted model ends on that date
3. Because the chief risk officer's mandate is renewed annually
4. Because an exception without an expiry date becomes the architecture by default

Chapter 5 · 75 minutes

Prerequisites and Readiness for Enterprise AI

The lesson teaches how to judge readiness for enterprise AI before budget is committed. Participants assess six dimensions, data, platform, governance, skills, culture and, for public authorities, the legal mandate, and learn to keep the result as a version-controlled scorecard scored with evidence, with a minimum that gates the decision to industrialise. Worked examples are Nordvik Region's intake form and Hansa Mutual's use-case checklist.

Learning objectives

Explain why a successful pilot is weak evidence of readiness to scale.
Assess an organisation across the six readiness dimensions on the scale 0 absent to 4 measured, citing evidence for every score above zero.
Identify the public-sector specifics that can stop a programme outright: legal mandate, procurement and transparency.
Draft a use-case intake form whose screening answers route the proposal to the right assessments and forum.

Key concepts

Readiness assessment: A structured judgement, made before the scale decision, of whether data, platform, governance, skills and culture can carry the load. The chapter stresses that it is not a maturity ranking but a list of the things that will break.
Readiness scorecard: A version-controlled record scoring each dimension from 0 absent to 4 measured, with evidence and gaps. Its minimum to industrialise is 2, treated as a gate, and it is re-scored on a fixed cadence with the history kept.
Use-case intake form: The short form through which every proposal enters. Its screening answers are factual and not evaluative, so the provisional class, the required assessments and the review forum follow from them, and readiness dependencies stop a proposal from passing.
Legal mandate confirmation: A written note from the legal function, such as Nordvik Region's LM-2026-009, confirming that the governing legislation permits the processing. Its conditions become a prohibited purpose in the data contract and a review trigger in the system's declaration.
Generative culture: In Westrum's typology, a culture in which messengers are trained and failure leads to inquiry. It matters for AI because failures, drift and bias are discovered by people who notice a wrong output and feel safe to say so.

Teaching plan

10 min	Opening: participants describe a pilot that succeeded and then stalled at scale; the teacher collects the workarounds that the pilot team performed by hand.
20 min	Teacher presentation of the six dimensions, the governance test for platform readiness, the public-sector specifics and the three practices that make a scorecard useful.
30 min	Exercise in groups: score the participant's organisation on the six dimensions with evidence, then write an intake form for one proposed use case.
15 min	Debrief: groups name their blocking dimensions and compare them with the chapter's table of typical blocking gaps per usage mode.

Discussion

The chapter says data readiness is most often overestimated and governance readiness most often underestimated. Which of the two describes your organisation better, and what is the evidence?
Hansa Mutual's claims assistant was blocked from full roll-out by a missing exit plan, not by a technical item. Which non-technical item would most likely block a pilot in your organisation?
An organisation can be ready for Mode 1 well before it is ready for Mode 4. How should a readiness report to the board show that difference without collapsing it into one number?

Exercise · 30 minutes

Score readiness and write an intake form

First, score your organisation on the dimensions data, platform, governance, skills and culture, and on the public-sector dimension if you are a public authority, using the scale 0 absent, 1 ad hoc, 2 defined, 3 operating, 4 measured. Cite one piece of inspectable evidence for every score above zero and one gap per dimension, then state the outcome and the blocking dimensions against a minimum of 2. Second, for one proposed use case, complete an intake form like Nordvik Region's UC-2026-017: intended purpose, what is out of scope, whether individuals are affected, decision involvement, special-category data, Annex III candidacy, agent actions, whether the legal mandate is confirmed, the assessments required and the review forum.

Deliverable: A scorecard with scores, evidence, gaps and blocking dimensions, and one completed intake form with routing and readiness dependencies.

Self-test

What is the chapter's governance test for platform readiness?
1. Whether the platform has enough accelerator capacity for the largest planned model
2. Whether the organisation holds an ISO/IEC 42001 certificate for its AI management system, issued within the last year
3. Whether the organisation can say, for any model, which version is approved, by whom and on what evidence
4. Whether every data scientist has been given access to a shared development environment
In the chapter's example scorecard for a regional health authority, why is the outcome remediate before scaling?
1. Because governance and the public-sector dimension score 1, below the minimum of 2
2. Because the platform dimension scores lower than the skills dimension
3. Because the culture dimension has not yet been scored with evidence
4. Because the average of the six dimensions is below 3, the level at which a capability counts as operating
Why does the chapter prefer engineering practice to certifications as a skills indicator?
1. Because certifications are not recognised under Article 4 of the AI Act
2. Because version control, continuous integration and automated testing predict delivery performance and are the floor for AI
3. Because engineering practice is cheaper to measure across the workforce than the Article 4 literacy programme, which covers all staff
4. Because certified staff tend to leave the organisation sooner than others

Module 2 · Part II · Sovereignty and Suppliers

Module 2 asks whose AI the organisation commits to and on what terms. It applies five categories of geopolitical risk by the same criteria to every model origin, separates a hosted service from open weights run on European infrastructure, and turns the assessment into an origin policy, a drilled exit plan, a vendor assessment and contract clauses with enforcing controls. Participants leave able to assess a model's origin and review a supplier contract against the AI Act, public procurement law and DORA.

Lecture · 40 minutes

Sovereignty and suppliers: neither blanket ban nor blanket trust

Part II treats the model as something that brings its provider's law, politics and training choices into the European estate. The lecture argues that the answer is not a list of approved countries but a risk-tiered position: the same criteria for every origin, a clear view of how the deployment mode moves risk between categories, and a second source kept ready. It then follows the assessment into the purchase, where the contract decides which documentation arrives, whether the organisation can leave and who answers to a supervisor. Buying AI is buying an obligation, and a clause without an enforcing control is a promise that cannot be verified.

7 min	Why model origin is a separate question Infrastructure sovereignty does not settle who can be compelled to hand over prompts, who can withdraw the service, and what the model was trained to say, refuse or omit. The dependency is concentrated, and the same model carries different risks depending on how it is consumed. Because the facts move quickly, every figure carries its month and year and every assessment a review date.
10 min	Five risk categories, one set of criteria Legal access, service continuity, model behaviour, supply-chain integrity and regulatory compliance apply to American and Chinese providers alike. The symmetry matters more than the differences: in both cases the provider's home law can reach data in its control. Self-hosting open weights is a strong control against legal access and a weak one against behaviour and supply-chain risk.
8 min	A risk-tiered position expressed as code An assessment per model, with the highest category score as the overall rating, not the average. An origin policy by data class that the AI gateway and the intake pipeline evaluate and enforce. An exit plan with a second source in a different jurisdiction, kept warm and drilled twice a year.
8 min	Buying AI is buying an obligation Every purchase assigns a role, and Article 25 means an organisation can become a provider through its own architectural choices. Ask for artefacts, not assurances: a missing artefact is a finding that blocks the contract or becomes a recorded exception. Public buyers specify by evaluation set and contract model updates as a process; financial entities add DORA's register, exit strategies and Article 30 provisions.
7 min	Keeping the choice reversible Lock-in hides in prompts, embeddings, tool-calling formats, fine-tuned weights and evaluation thresholds the organisation created itself. A gateway, versioned prompts, independent embeddings and a rehearsed exit strategy contain it. Nordvik Region's leverage is the contract under procurement law; Hansa Mutual needs one contract that satisfies seven regimes.

What the audience takes away

Assess every model by the same five risk categories, whatever its origin, and take the highest score as the rating.
How a model is consumed, as a hosted service or as self-hosted weights, moves risk between categories; it does not remove it.
Pair every contract clause with the control that enforces it, and rehearse the exit before it is needed.

Chapter 6 · 90 minutes

Geopolitics and Model Origin

The lesson treats model origin as a question separate from infrastructure placement. Participants apply five categories of geopolitical risk by the same criteria to every origin, compare a foreign hosted service with foreign open weights on European infrastructure and a European provider, and produce the three artefacts of a risk-tiered position: a model-origin assessment, an origin policy by data class and an exit plan with a second source.

Learning objectives

Explain why infrastructure sovereignty does not settle the three questions specific to models.
Assess a model or provider across the five risk categories, scoring each from 1 to 4 with a cited rationale.
Compare how a hosted service, self-hosted open weights and a European provider move risk between the categories.
Draft an origin policy rule and an exit plan with a second source, switch times and trigger events.

Key concepts

Five categories of geopolitical risk: Legal access to data and prompts, service continuity including sanctions and export controls, model behaviour, supply-chain integrity and regulatory compliance. Each applies to every origin by the same criteria, and each attaches to a different layer of dependency.
Control, not location: The test in the US CLOUD Act, which requires disclosure of records within a provider's possession, custody or control wherever they are located. The chapter notes the symmetry: both US and Chinese home law can reach data in a provider's control.
Model-origin assessment: A dated, evidence-backed record such as Hansa Mutual's GEO-2026-017 that scores one model or provider on the five categories, takes the highest score as the overall rating, lists controls and carries a review date.
Model-origin policy: A versioned policy stating which combinations of origin and deployment mode may serve which data classes. Origins are defined by legal position, so a change in adequacy changes the outcome automatically, and the gateway rejects any route not permitted.
Second source: A replacement model from a different jurisdiction, or self-hosted open weights, evaluated at least monthly, kept warm with shadow traffic and drilled twice a year, so that a sanction or ruling is an operational event and not a crisis.

Teaching plan

10 min	Opening: the teacher poses the three questions infrastructure sovereignty does not answer and asks participants which of their current models they could answer them for.
25 min	Teacher presentation of the five risk categories with the chapter's dated evidence for both American and Chinese providers, stressing where evidence is thin or comes from an interested party.
10 min	Group reading of Table 6.1: for each risk category, participants state in their own words what changes between a hosted service, self-hosted open weights and a European provider.
35 min	Exercise in groups: assess one model with the six-step practical guide, write the matching policy rule and outline an exit plan.
10 min	Debrief: groups compare overall ratings and discuss what Hansa Mutual's April 2026 drill, which exposed a GPU quota too low, says about untested exit plans.

Discussion

The chapter treats the CAISI evaluations as credible and as produced by an interested party. How should an assessment record use evidence of that kind?
Nordvik Region's reporting clause on government data requests is deliberately modest, because a supplier cannot promise what its home law forbids. What can a contract realistically achieve against legal access risk, and what must architecture do instead?
Blanket bans push staff towards unmanaged consumer tools and blanket trust ignores dated evidence. Where does your organisation's present position sit between the two, and what would a risk-tiered position change?

Exercise · 35 minutes

Assess a model's origin and plan the exit

Pick one model or provider your organisation uses or is considering, or take Hansa Mutual's proposal to self-host an open-weight coding model. Follow the practical guide: record the deployment mode and map every party in the chain with ultimate parent and jurisdiction; score legal access, continuity, behaviour, supply chain and regulatory compliance from 1 to 4 with a one-line rationale each; take the highest score as the overall rating; state the decision, the controls and a review date within twelve months. Then write one origin policy rule for the highest data class the model may serve, and outline an exit plan: the second source and its jurisdiction, the acceptance threshold against the primary, the switch time and three trigger events.

Deliverable: A model-origin assessment record with five scored categories and an overall rating, one policy rule, and a half-page exit plan with second source, switch time and triggers.

Self-test

In the chapter's practical guide, how is the overall rating of a model-origin assessment derived from the five category scores?
1. It is the average of the five category scores, rounded up
2. It is the score for legal access, which outweighs the others
3. It is the highest of the category scores
4. It is set by legal counsel independently of the scores
Why did Hansa Mutual's self-hosted coding model from a developer established in China score only 1 on legal access?
1. Because no prompts or telemetry leave Hansa's infrastructure and egress is denied
2. Because the model's licence is Apache 2.0 and therefore open
3. Because China has an adequacy decision for source code
4. Because the developer appointed an authorised representative in the Union
What does the chapter conclude from findings that model behaviour differs between languages?
1. Models from third countries should be limited to English-language use
2. Evaluation must cover every language a deployment serves, not English alone
3. Behaviour tests can be replaced by provenance checks on the weights
4. Translation into English before inference removes the behaviour risk

Chapter 7 · 90 minutes

Procurement, Vendor Management and Open Models

The lesson shows why procurement is an architectural activity. Participants trace the roles a purchase creates under the AI Act, learn how Directive 2014/24/EU makes the evaluation set the lawful way to specify quality, apply DORA's third-party duties, weigh open-weight against proprietary models, and review a supplier contract clause by clause against the controls that enforce it.

Learning objectives

Explain how Article 25 of the AI Act can make a purchasing organisation the provider of a high-risk AI system.
Design vendor due-diligence questions that ask for an artefact and name the obligation each supports.
Identify where lock-in hides in AI and the control that contains each form.
Review a draft model-supply contract against the clause table, marking each clause present, a gap or missing, with its enforcing control.

Key concepts

Artefacts rather than assurances: The remedy for weak vendor assessment. The schema records what the organisation has received, not what the vendor has claimed; a model card is an artefact, a statement that the vendor follows responsible AI principles is not.
Evaluation set as specification: Under Article 42 of Directive 2014/24/EU an authority cannot specify a named vendor's model. The versioned test cases and acceptance thresholds are therefore the lawful way to express a requirement that would otherwise be a brand name.
Register of information: The register of all ICT contractual arrangements that Article 28 of DORA requires financial entities to maintain. For a bank or insurer, the vendor assessment schema is its source for AI providers.
Exit strategy: A document in the repository that names each dependency, the replacement path, the estimated time and the evidence that the path has been exercised. The chapter states that an exit strategy never rehearsed is a hope.
Open-weight versus open-source AI: Many models called open have downloadable weights but restrictive licences and no description of training data. The Open Source AI Definition also requires sufficiently detailed training data information, complete training and inference code, and the parameters.

Teaching plan

10 min	Opening: participants name the last AI purchase in their organisation and state which role under the AI Act it gave them; the teacher introduces buying as taking on an obligation.
25 min	Teacher presentation: roles along the value chain, what a provider must hand over, public procurement under Directive 2014/24/EU, DORA Articles 28 and 30, and the open-weight trade-off.
10 min	Group reading of Nordvik Region's due-diligence questionnaire for tender NR-2026-117: why a statement without the artefact scores 0 and what the mandatory questions exclude.
35 min	Exercise in groups: review a supplier agreement against the clause table and write the due-diligence questions that would have exposed the gaps.
10 min	Debrief: groups report their count of gaps and missing clauses and whether the contract is ready for signature, as in Hansa Mutual's checklist.

Discussion

Mode 0 is the case procurement most often misses, because no purchase takes place. Which of your existing software agreements would let a supplier switch on an AI feature without notice?
Hansa Mutual records a clause as a gap when it cannot verify it through its own gateway, evaluation service or evidence pipeline, even if the wording is acceptable. What would that rule do to your current contracts?
Open-weight models offer control at the price of competence and infrastructure, proprietary models capability at the price of dependency. For which of your use cases does each side of the trade-off weigh most?

Exercise · 35 minutes

Review a model-supplier contract

Take a current or draft agreement with an AI supplier from your own organisation, or work from Hansa Mutual's situation with Model Provider Alpha. Go through the seven clauses of the chapter's table: customer data use, processing location, model updates, documentation delivery, incident notification, audit and access rights, and exit assistance. For each, record what the contract states, mark it OK, GAP or MISSING, and name the control in your own estate that would verify it. Then write five due-diligence questions in the style of Nordvik Region's questionnaire: each asks for a specific artefact and names the obligation it supports. Finish with an outcome: ready for signature or not, and the changes required.

Deliverable: A seven-row clause checklist with status and enforcing control, five artefact-based due-diligence questions, and a signature recommendation.

Self-test

Why is the evaluation set, according to the chapter, more than a quality tool for a public authority?
1. Because it replaces the conformity assessment the provider would otherwise perform
2. Because the AI Act requires deployers to publish it with the tender documents
3. Because it lets the authority negotiate the price after the award decision
4. Because it is the lawful way to express a requirement that would otherwise be a brand name
The AI Act exempts providers of general-purpose AI models released under a free and open-source licence from some documentation duties. Whose relief is that, as the chapter puts it?
1. The downloading organisation's, which is thereby not a deployer
2. The provider's, not the downloading organisation's
3. Both parties', as long as the model is self-hosted in the Union
4. Neither party's, once the model is used in production
In Hansa Mutual's review of draft v3 of the agreement with Model Provider Alpha, what was the outcome?
1. Not ready for signature, with 4 clauses missing and 8 gaps
2. Approved with a time-limited exception owned by the platform head
3. Ready for signature, subject to an on-site audit within a year
4. Rejected, with the provider replaced by a self-hosted model

Module 3 · Part III · Risk, Governance, Trust and Assurance

Module 3 is the core of the method. It turns the AI Act's classification into a decision tree over a signed descriptor, keeps the risk register and risk appetite as data, builds the management system as policies and gates in a pipeline, attaches mechanisms to transparency, fairness and human oversight, and assembles the resulting evidence into a signed chain. Participants leave able to classify a use case, write a gate policy in outline, design oversight that is real and answer an auditor's question with an artefact.

Lecture · 50 minutes

Risk, governance, trust and assurance: the committee decides, the pipeline applies

Part III carries the central argument of the book: AI risk management becomes reliable when it stops being an event and becomes a pipeline. The lecture follows one use case through four stations. It is classified by a decision tree and entered in a register that re-opens itself when the system changes. It passes gates that apply the committee's rules identically to every change. Its fairness criterion, its transparency and its human oversight are designed, not asserted. And every step leaves signed evidence from which documentation and audit packs are generated. Each station also shows what the previous one cannot prove.

10 min	Classification as a decision tree, the register as code Six questions in a fixed order assign the tier; the profiling exclusion in Article 6(3) overrides every derogation ground. The policy reads a signed descriptor, not the system, so a misleading descriptor is an auditable act. Article 9's regular review is implemented as triggered review: a change to model, data or purpose re-opens the entry and blocks promotion.
12 min	From committees to controls A committee can decide, but it cannot enforce, observe or remember at the pace of an organisation that ships weekly. ISO/IEC 42001 maps clause by clause to repository artefacts and enforcement points. Three policy families, model approval, data use and deployment, with thresholds as data and every decision recorded before it is enforced. Waivers are records that expire, and their count and age are the richest governance metric.
12 min	What consistency cannot prove: trustworthy AI A pipeline that applies a rule identically proves consistency, not soundness. Fairness criteria cannot all hold when base rates differ, so the choice is made explicitly, by people with authority, and recorded with its rationale. Oversight under Article 14 is a design: workload, visible uncertainty, never auto-accept, blind sampling, override alerts and a tested stop function.
10 min	Evidence, not attestation Attestation is a person asserting that a control operated; evidence is a machine-generated artefact that demonstrates it. A release without a complete evidence bundle cannot reach production; evidence is written once and signed inside the pipeline. Annex IV documentation, audit packs and incident reports are generated from the store, for the AI Act and DORA together.
6 min	One regime and seven Nordvik Region classifies once, against one regime, and writes its register to be read by residents and journalists. Hansa Mutual keeps one tiering policy and one appetite; each entity's overlay may add obligations but never remove a group control.

What the audience takes away

Classify the use, not the technology, and wire the classification and the register to the events that change the system.
Let the committee approve the rules, the appetite and the legal interpretation once; let the pipeline apply them every time and record what it did.
Design fairness, oversight and evidence as artefacts in the repository, because a requirement that is not an artefact does not survive a delivery schedule.

Chapter 8 · 90 minutes

AI Risk Management and Classification as Code

The lesson turns AI risk management from a periodic workshop into part of the delivery pipeline. Participants apply the AI Act's classification as a six-step decision tree over a signed use-case descriptor, write a risk register entry with controls and review triggers, see how a substantial-modification rule forces a human judgement, and express a risk appetite statement as data that a gate can evaluate.

Learning objectives

Classify a use case with the six-step decision tree, citing the article behind every answer.
Explain why the profiling question is asked separately from the Article 6(3) derogation.
Draft a risk register entry that links a hazard to controls, assessments, an owner and review triggers.
Describe how a versioned risk appetite statement becomes the threshold a deployment gate enforces.

Key concepts

Classification decision tree: Six questions in order: is it an AI system under Article 3(1), is it a prohibited practice under Article 5, is it high-risk under Article 6, does the Article 6(3) derogation apply, do Article 50 transparency duties apply, and is the organisation provider or deployer.
AI Decision Record: A version-controlled record, kept for every AI system, that states its intended purpose, user population, data, model, usage mode and the organisation's role, and that changes through reviewed commits. It serves as the use-case descriptor the policy evaluates.
Excluded uses: The list in a descriptor of uses the system must not be put to. Naming them makes drifting into them a visible change of intended purpose, which re-runs the classification.
Risk register as code: Each entry is a YAML document validated against a schema, reviewed through a pull request and linked by identifier to system, controls, evidence and assessments. Its review triggers name the events that force re-evaluation, and a stale entry counts as an open risk.
Risk appetite as data: The board-level declaration of acceptable risk expressed as rules per tier, with required assessments and a maximum residual rating. Versioned, it shows the appetite in force when a system was approved and lists the systems that no longer fit when it tightens.

Teaching plan

10 min	Opening: the teacher asks when participants' AI risk assessments were last re-opened, then presents why a control once implemented does not stay implemented for AI.
25 min	Teacher walks through the decision tree using Nordvik Region's risk-tiering questionnaire for benefits triage, then the staff assistant descriptor that stays limited-risk through its excluded uses.
15 min	Presentation and questions on the register entry, the six classes of change that trigger re-evaluation, the substantial-modification rule and the appetite statement.
30 min	Exercise in pairs: complete a tiering questionnaire for one system and write its register entry with triggers.
10 min	Debrief: pairs challenge the basis of each other's answers, not the conclusion, and check the resulting tier against the appetite rules.

Discussion

Teams often describe a system as only prioritising. Why does the chapter treat that description with suspicion, and which of your systems would it apply to?
The substantial-modification rule does not decide that a change is substantial; it decides that a human must make the judgement. What is gained by drawing the line between machine and legal judgement there?
No committee meets at deployment, because its work happened when it approved the policy, the appetite and the legal interpretation. What would your risk committee have to give up, and what would it gain, to work that way?

Exercise · 30 minutes

Tier a use case and write its register entry

Choose an AI system from your own organisation, or a variation of Nordvik Region's staff assistant that is now proposed for recommending eligibility. First complete a risk-tiering questionnaire with the chapter's questions: is it an AI system, does any use fall under Article 5, is it used in an Annex III area, is the task only narrow or preparatory, does it profile natural persons, does it interact with people or generate content, what is your role, and are you a body governed by public law. Give the basis for each answer and state the resulting tier and obligations. Then write a register entry: hazard, harm categories, inherent rating, at least three controls, residual rating, owner, linked assessments, review period and triggers.

Deliverable: A completed tiering questionnaire with article references and resulting tier, and one register entry with controls, owner and review triggers.

Self-test

In Nordvik Region's questionnaire for the benefits-triage system, why can the Article 6(3) derogation not apply?
1. Because the Region is a body governed by public law
2. Because the system profiles natural persons, which excludes every derogation ground
3. Because the supplier, as provider, would have to document the derogation and register the system
4. Because the system interacts directly with applicants
How does the chapter implement the requirement in Article 9 for regular review of risks?
1. As an annual workshop with the risk committee and the system owner, minuted in the register
2. As a quarterly report from the model provider to the deployer
3. As a review by legal counsel at each contract renewal
4. As triggered review: a commit that changes model, data or purpose re-opens the entries
What does the gate do with a register entry whose last review date plus review period has passed?
1. It treats the stale entry as an open risk
2. It deletes the entry and asks the owner to file a new one
3. It lowers the residual rating by one level until reviewed
4. It ignores the entry, since the classification is unchanged

Chapter 9 · 90 minutes

AI Governance as Code

The lesson builds the AI management system as code. Participants map ISO/IEC 42001 to repository artefacts and enforcement points, study the three policy families of model approval, data use and deployment, derive the AI inventory from descriptors, place governance gates in the lifecycle, and handle waivers as expiring records. Nordvik Region's governance policy and acceptable-use policy are the worked examples.

Learning objectives

Explain why a review board accumulates a backlog and what governance as code inverts.
Map elements of ISO/IEC 42001 to a repository artefact and an enforcement point.
Specify the conditions a deployment gate checks before a release reaches users.
Draft a waiver record scoped to one rule and one system, with compensating controls and an expiry.

Key concepts

Governance as code: The committee decides the rules, approves the interpretation of regulation and reviews the evidence; the pipeline applies the rules identically to every change, refuses what does not comply and records what it did.
Three policy families: Model approval governs promotion in the model registry; data use governs what may train, fine-tune or ground a model; deployment governs release to users. Thresholds are data keyed by risk tier and changed through a reviewed commit.
Derived inventory: The inventory is generated from descriptors in the repository 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.
Governance gate: A point in the lifecycle where a policy is evaluated and a change proceeds, is blocked or is routed to a human. A gate asks for a human only when the policy says so and never asks the same question twice.
Waiver as a record: An exception with a schema, accepted by the gate only if valid, unexpired, approved by the role the policy names and scoped to the specific rule that failed. An expired waiver is a blocked deployment.

Teaching plan

10 min	Opening: participants describe how AI use cases are approved today and how long the queue is; the teacher presents the chapter's account of the review board with a backlog.
25 min	Teacher presentation of the ISO/IEC 42001 mapping, Nordvik Region's governance policy with its tier table, the model approval and deployment policies and the seven gates.
15 min	Group reading of the benefits-triage inventory entry and the staff acceptable-use policy; discussion of AI the organisation did not choose and how supplier changes surface as drift.
30 min	Exercise in groups: write the tier and approval table of a governance policy, the conditions of a deployment gate in plain language, and one waiver record.
10 min	Debrief: groups test each other's gate conditions by proposing a release that should be refused and checking that the gate refuses it.

Discussion

Nordvik Region's policy treats a system whose tier is unknown as high until classified. What behaviour does that default encourage, and what would the opposite default encourage?
The CI job records the decision before it enforces it, so a blocked release leaves the same evidence as an approved one. Why does that ordering matter to an auditor?
A policy with many waivers is either wrong or ahead of the organisation's capability. How would you tell which, and who should decide?

Exercise · 30 minutes

Write a gate, a policy table and a waiver

For your own organisation, or for Nordvik Region, produce three short artefacts. One: the risk tier and approval path table of an AI governance policy, stating for prohibited, high, limited and minimal tiers who approves before use and how often the system is reviewed, plus the rule for an unknown tier and the things no waiver may suspend. Two: the conditions of a deployment gate in plain language, covering approved models, input and output screening, logging with a retention minimum, and the oversight role for high-risk systems, each with the message shown when it fails. Three: one waiver record for a rule a real system cannot meet today, with justification, compensating controls, approver, expiry and the action that removes the need for it.

Deliverable: A tier and approval table, a list of deployment gate conditions with failure messages, and one waiver record with expiry and review action.

Self-test

In Nordvik Region's deployment policy, what logging retention must the gateway have for a release to be allowed?
1. At least 30 days
2. At least 90 days
3. At least 183 days
4. At least 365 days
According to Nordvik Region's governance policy, what is the maximum expiry of a waiver, and what may no waiver suspend?
1. 90 days; a prohibition, a FRIA or human oversight
2. 12 months; registration in the EU database
3. 30 days; any rule that applies to a limited-risk system
4. 6 months; the acceptable-use policy for staff
How does governance as code treat an AI feature that a supplier switches on inside purchased software?
1. As outside governance until the organisation formally adopts the feature
2. As the supplier's responsibility alone, since the supplier is the provider and the licence has not changed
3. As a minimal-risk change that needs no descriptor or decision
4. As an event to process: the feature gets a descriptor and a decision, and is an open risk until then

Chapter 10 · 90 minutes

Trustworthy AI: Transparency, Fairness and Human Oversight

The lesson turns from enforcement to substance. Participants attach a mechanism and an evidence source to the seven requirements for trustworthy AI and work in depth on three: transparency for three audiences, fairness as a recorded choice between incompatible criteria, and human oversight under Article 14 as a design. Nordvik Region's oversight specification, transparency notice and fundamental rights impact assessment are the worked examples.

Learning objectives

Distinguish the three audiences of transparency and what each needs.
Explain why independence, separation and sufficiency cannot all hold when base rates differ, and where the resulting choice is recorded.
Design human oversight that addresses workload, defaults, automation bias and the stop function.
Outline a fundamental rights impact assessment in which every risk has an identifier, a measure and a trigger.

Key concepts

System-level transparency: For large language models, an explanation of the model's own output is generated text, not a faithful account of the computation. The honest alternative records which sources were retrieved, which tools were called, which model version answered and which verification steps applied.
Three families of fairness criteria: Independence (demographic parity), separation (equal error rates across groups) and sufficiency (calibration). They cannot all hold when base rates differ, so every system embodies a choice, made explicitly and recorded in the AI Decision Record.
Oversight patterns: Human-in-the-loop: a person approves each output before it takes effect. Human-on-the-loop: the system acts and a person monitors and can halt. Human-in-command: a person decides whether and where the system is used at all.
Automation bias controls: Measures that show whether oversight has become ceremonial: a blind sample of cases shown to the overseer without the score, and both a lower and an upper override-rate alert, because ceremonial oversight and a failing model both show in that number.
Fundamental rights impact assessment: The assessment required of certain deployers by Article 27, covering processes, period and frequency of use, affected groups, specific risks, oversight measures and measures if risks materialise. Kept in the repository with stable section identifiers so that other artefacts can cite individual findings.

Teaching plan

10 min	Opening: the teacher states that a pipeline proves consistency, not soundness, and asks which of the seven requirements lacks a mechanism in participants' organisations.
20 min	Teacher presentation on transparency for deployer, affected person and oversight staff, the transparency record of the staff assistant, and the fairness configuration with thresholds and rationale.
15 min	Guided reading of Nordvik Region's oversight design for benefits triage: participants explain why each value is there, from never auto-accept to the stop function reverting to date order.
35 min	Exercise in groups: write an oversight design specification and a short transparency notice for one system that affects people.
10 min	Debrief: each group states what happens when the overseer does nothing, and what the safe state is when the system is stopped.

Discussion

An overseer who must process three hundred recommendations an hour with a single accept button has no control, whatever the policy says. Where in your organisation does the workload decide the quality of oversight?
Nordvik Region's notice leads with what the system does not do and offers handling without the system's suggestion. What does that option demand of the workflow behind it?
The FRIA names groups such as paper applicants that a purely statistical fairness analysis would not have found. How would you find the equivalent groups for a system in your own service?

Exercise · 35 minutes

Design oversight that is real

Take one system in your organisation that ranks, recommends or drafts something affecting people, or use Hansa Mutual's underwriting-support model. Write an oversight design specification with the fields of Nordvik Region's example: the pattern, the oversight role, the maximum workload per hour and minimum review time per case, what the overseer sees, the actions available and whether a reason is required, the default when nobody acts, the automation bias controls with a blind sample rate and lower and upper override-rate alerts, and the stop function with who can trigger it, its effect, the time to a safe state and how often it is tested. Then write a transparency notice of at most 120 words for the affected person, leading with what the system does not do.

Deliverable: An oversight design specification with workload, defaults, automation bias controls and stop function, and a plain-language notice of at most 120 words.

Self-test

Why does Nordvik Region's oversight design send five per cent of cases to the overseer without the score?
1. To reduce the overseer's workload during peak periods
2. To give a baseline for measuring agreement with the system, as a check on automation bias
3. To comply with the minimum group size of 200 that the fairness configuration sets for each subgroup
4. To test whether the stop function reaches a safe state in time
Where, according to the chapter, should protected attributes be joined to predictions for fairness measurement?
1. In the production feature set, so that monitoring is continuous
2. In the caseworker's interface, so that the overseer can see them
3. Nowhere, since special categories may not be processed for this purpose
4. Only in an isolated evaluation environment, with the join logged
In the benefits-triage oversight design, what is the effect of triggering the stop function?
1. The queue reverts to date order
2. All pending applications are approved automatically
3. The supplier rolls the model back to its previous version
4. Rankings continue but are hidden from caseworkers

Chapter 11 · 90 minutes

Evidence, Assurance and Audit

The lesson shows how to make an AI system auditable continuously. Participants separate attestation from evidence, follow the evidence chain from sources of truth to a signed store, generate Annex IV documentation from the repository, design logging that reconciles record-keeping with data minimisation, and build an evidence-pack index and an audit test procedure. Post-market monitoring, serious incident reporting and the overlap with DORA complete the picture.

Learning objectives

Distinguish attestation from evidence and name the four characteristics of evidence as code.
Describe the contents of an evidence bundle and the two design decisions that make the chain trustworthy.
Design an inference log that separates the record of events from content containing personal data.
Draft an evidence-pack index and an audit test procedure with a design test and an operating effectiveness test.

Key concepts

Attestation versus evidence: Attestation is a person asserting that a control operated. Evidence is a machine-generated artefact that demonstrates it. The auditor's question about which model served decisions on a given date should be answered from evidence within an hour.
Evidence manifest: The record that ties the chain together for one release: hashed subjects such as model, dataset and prompt bundle, evaluation reports, controls mapped to obligations and artefacts, approvals, a cryptographic attestation and retention periods.
Events separated from content: The event record, proving the system operated within its declared bounds, is kept for the regulatory period in append-only storage. Content with personal data is pseudonymised at ingestion, held under shorter retention and linked by a reference under a documented access procedure.
Evidence pack: A set of artefacts generated by query for one system and period. Its index lists each audit question, the artefacts that answer it and their hashes, and records the query and generator commit so that a second auditor can regenerate it.
AI-specific incident classification: A step in the incident process for every production incident touching an AI system, recording the answer and the reasoning whatever the outcome, so that the fifteen-day deadline of Article 73 can be met and a negative assessment can be reviewed.

Teaching plan

10 min	Opening: the teacher puts the auditor's question to the room: which model version served decisions on a given date, on what data, with what evaluation, approved by whom. Participants estimate how long the answer would take.
25 min	Teacher presentation of the evidence chain, the manifest, Annex IV as queries against the repository, logging and retention, and the table of artefacts that serve both the AI Act and DORA.
15 min	Guided reading of audit test procedure TP-AI-014 and Hansa Mutual's incident classification record INC-2026-0457; discussion of why steps O4 and O5 carry the most value.
30 min	Exercise in pairs: build an evidence-pack index for one system and write a test procedure for one of its controls.
10 min	Debrief: pairs report which sections of their index are empty and treat each empty section as a finding.

Discussion

Evidence as code lets auditors spend their time on questions that need judgement. Which three questions about your AI systems can no event log answer?
Hansa Mutual recorded that Article 73 did not apply to its incident. What is the value of recording a negative assessment, and who reads it?
For Modes 0 to 2 the evidence is largely what the supplier lets the organisation export. What should your contracts say about audit logs, and what is the strongest evidence you hold today for those modes?

Exercise · 30 minutes

Build an evidence-pack index and a test procedure

Choose one AI system and a two-month period. Draft the index of an evidence pack in the form of Nordvik Region's EP-2026-011: at least four sections, each headed by an audit question tied to an obligation, such as use per intended purpose, human oversight operating as designed, and logs complete and retained for at least six months, with the artefacts that would answer it. Mark honestly which artefacts exist today. Then write a test procedure for one control, modelled on TP-AI-014: a design test with two steps, an operating effectiveness test with a sample size, a step that recomputes a metric from raw events, one interview step, and the conditions under which the control is judged deficient.

Deliverable: An evidence-pack index with at least four audit questions and their artefacts, gaps marked, and a one-page audit test procedure for one control.

Self-test

Which two design decisions make the evidence chain trustworthy, according to the chapter?
1. Evidence is reviewed by legal counsel, and stored in the supplier's cloud
2. Evidence is kept in a wiki, and approved by two engineers
3. Evidence is written once and never edited, and it is signed inside the pipeline with an identity bound to the run
4. Evidence is summarised quarterly for the forum, and signed with a key that the release manager holds on a hardware token
In audit test procedure TP-AI-014, why does the auditor recompute the weekly override rate from raw events?
1. Because the oversight design forbids dashboards for override metrics
2. Because it tests the metric pipeline as well as the control, so a broken dashboard cannot hide a broken control
3. Because raw events are retained for longer than the published metrics
4. Because the supplier's instructions for use require a manual recalculation of every published metric before each audit
Within what period must a provider report a serious incident under Article 73 of the AI Act, as the chapter states it?
1. Immediately after establishing a causal link or its likelihood, and at most fifteen days after becoming aware
2. Within six months, together with the post-market monitoring report
3. Within seventy-two hours of detection, as for a personal data breach
4. Within thirty days of the governance forum's decision that the incident is serious, and never before that decision

Module 4 · Part IV · Organisation and Leadership

Module 4 turns from controls to the people and bodies that hold them. It covers operating models and team topology, decision forums tiered by risk class, the AI architect and the roles around it, change and adoption under European labour law, the portfolio run as a register, the economics of systems whose cost follows consumption, and the particular duties of public authorities. Participants leave able to say, for any AI system, who owns it, who decides, who can stop it, what it costs and how it is explained.

Lecture · 55 minutes

Organisation and leadership: who owns, who decides, who can stop it

Every control in Part III names a role. Part IV asks who holds those roles and whether they can carry them. The lecture follows the argument through the organisation: an operating model that puts use-case ownership with the business and controls in the platform; forums that decide only what pipelines cannot; competence that is role-specific and evidenced; adoption treated as a designed and measured property of the system; a portfolio of falsifiable hypotheses funded against evidence; cost governed by ownership before metering; and the public authority, which must have a legal basis before it has a system and must give reasons a citizen can read.

8 min	Conway's law and three operating models The seam that is missing in the organisation is the one that fails in production. Centralised fails at the queue, federated at the inventory; hub-and-spoke scales when the hub is a platform team and an enabling team and ownership stays in the spokes. Control functions keep their independence through gates and records, not through seats in the delivery team.
9 min	Forums decide what pipelines cannot Pipelines cannot decide anything that has not already been decided: appetite, policy, exceptions, residual risk and the response when something goes wrong. Four tiers route each decision to the lowest level that can take it with the evidence; prohibited practices are not a tier. The stop authority sits outside the system it stops, and restarting is harder than stopping.
8 min	Competence is the scarce resource The AI architect owns the seams between the architecture roles, between building and verifying, and between the system and its overseers. Article 4 now asks for measures that support literacy, but Articles 14 and 26(2) still require competence that can be shown. Upskill those who know the domain; hire for scarce specialisms and the first AI architect.
8 min	Adoption is the binding constraint The chasm between early adopters and the early majority is crossed by changing the system, not only the message. Consultation with employee representatives is a design review whose commitments become controls with tests. The override rate has a healthy range: near zero is ceremony, too high is a model not good enough to deploy.
12 min	Portfolio and money: hypotheses, envelopes and five outcomes A use case is a falsifiable value hypothesis with a baseline, acceptance criteria and retirement criteria written at intake. The platform is funded as a product, use cases in tranches released against evidence; reports are projections of the register stamped with a commit. Cost follows consumption, so a named budget owner holds the envelope and the benefit together, and the stop authority is delegated downwards. The forum's decision table has five outcomes: approve, approve with conditions, pause, scale, retire or redesign.
10 min	The public authority: legality before capability An authority may deploy a model only because the law permits the task, and only in the way the law permits. The line between decision support and decision-making is drawn in the data model, the audit log and the metrics. The reasons log, the algorithm register and the published FRIA summary are generated from the same repository that the gates evaluate.

What the audience takes away

Keep accountability for a use case in the line of the business that owns it; shared platforms and group teams cannot absorb it.
Give every AI decision exactly one home, tier it by risk class and make the forum decide on evidence it did not prepare.
Treat adoption data, cost per unit of value and published reasons as governance evidence, each with an owner and a threshold.

Chapter 12 · 75 minutes

Organisational Design for AI

The lesson treats organisational design for AI as architecture by other means. Participants compare the centralised, federated and hub-and-spoke operating models and their failure modes, distinguish the platform team from the enabling team, place the control functions at gates, and split responsibilities between a group and its entities. They finish with a RACI for a high-risk use case and a team topology that a pipeline can validate.

Learning objectives

Explain how Conway's law applies to AI systems and what organisational design does about it.
Compare the three operating models by ownership, inventory and typical failure.
Distinguish the interaction modes of the platform team and the enabling team, and state what each must not do.
Draft a RACI for a high-risk use case in which every activity has exactly one accountable role.

Key concepts

Hub-and-spoke model: A central hub provides the platform, the standards and specialist support, while use cases are owned by the teams closest to the business. Its failure mode is a hub that drifts into building use cases itself or shrinks into a standards committee.
AI platform team: Owns the gateway, model registry, evaluation service, guardrail library, observability stack and golden path templates, offered as a service. It does not build use cases, because it would then compete with its customers for its own capacity and the queue returns.
Enabling team: Often called the AI centre of excellence, it works in facilitating mode: it helps a stream-aligned team through its first use case and then leaves. Its success is measured by how quickly a team no longer needs it.
Retained roles: Roles that carry accountability or judgement against the supplier's interest and must not be filled by supplier staff: the accountable executive, the oversight staff, the owner of evaluation thresholds, the design authority seat and the owner of each exit plan.
Market liaison: A role in each entity of a group, usually in compliance, that maintains the market's policy overlay and translates group decisions into the entity's terms, linking group capabilities to the accountability the law ties to the entity.

Teaching plan

10 min	Opening: participants sketch who owns data, model, infrastructure, policy and oversight for one of their AI systems and mark where those groups never meet.
20 min	Teacher presentation of the three operating models, the platform and enabling teams, stream-aligned ownership, control functions at gates and the group and entity split.
10 min	Group reading of Hansa Mutual's engagement charter for the Motor Claims team: why the will-not list and the exit criteria matter.
25 min	Exercise in groups: build a RACI for one high-risk use case and list the retained roles.
10 min	Debrief: groups check each other's matrices for activities with two accountable roles or none, and for builders setting their own thresholds.

Discussion

In Nordvik Region's matrix, model risk is accountable for the evaluation thresholds so that the builders do not set the bar they must clear. Who sets that bar in your organisation today?
An accountable executive who owns the system will insist on evidence, whereas one who has delegated it to the hub will insist on speed. Where have you seen this, and what did it cost?
A shared-service body must not become the accountable party by default for small municipalities. Why is that tempting, and what goes wrong when it happens?

Exercise · 25 minutes

A RACI for a high-risk use case

Take a high-risk or otherwise consequential AI use case in your organisation, or Nordvik Region's bought benefits-triage system. List six activities: impact assessments, evaluation thresholds, gateway and logging configuration, oversight design and training, the go-live decision, and monitoring of risks. Name the roles involved, including the business owner, the product team, the AI platform, the people who exercise oversight, the data protection officer and model risk. Fill in R, A, C and I so that each activity has exactly one A. Then state which operating model you run today, its failure mode as you observe it, and which five roles you would never hand to supplier staff.

Deliverable: A six-row RACI with exactly one accountable role per activity, a one-paragraph diagnosis of the current operating model, and a list of retained roles.

Self-test

What is the typical failure of the federated operating model, according to the chapter?
1. A queue at the central team and shadow AI in the business units
2. A hub that starts to build the use cases itself
3. Duplication and divergence, with an inventory the organisation cannot produce
4. Control functions that sit inside the delivery teams
Why should the AI platform team not build use cases?
1. Because it then competes with its customers for its own capacity and the queue returns
2. Because the AI Act forbids platform owners from acting as deployers
3. Because platform engineers lack the domain knowledge to evaluate models
4. Because use cases must be built by the enabling team instead
In Nordvik Region's shared platform service agreement with Eastby Municipality, who approves the municipality's use cases?
1. The Region's digital services unit, as provider of the platform
2. A joint committee of the Region and the municipality
3. The supplier of the model behind the gateway
4. The municipality's own accountable executive only

Chapter 13 · 90 minutes

Decision Forums and Governance Bodies

The lesson explains why forums still matter after governance as code and how to design them. Participants place the management body, the AI governance board, the design authority and the specialist councils, tier decisions by risk class so that each has exactly one home, define the stop authority, and write terms of reference and a decision minute as records in version control.

Learning objectives

Explain what pipelines cannot decide and which forum decides it.
Route a decision to one of the four tiers using risk class and decision type.
Define a stop authority and a restart rule for a system before it reaches production.
Draft terms of reference for a forum with mandate, quorum, cadence, evidence and a sunset clause.

Key concepts

Decision tiers: Tier 1 pipeline 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.
Management body: The board in a company, or the head of the authority with the management group. It sets the risk appetite for AI, approves the AI policy, accepts residual risks beyond the appetite it delegated and oversees whether the arrangements work.
AI design authority: Often a specialisation of an existing architecture board. It decides reference patterns, golden paths, sourcing choices, deviations from approved patterns and precedent-setting AI Decision Records; its output is a merged record, not minutes.
Stop authority: The chapter's default: 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; every stop is reported to the AI governance board.
Governance theatre: 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, including a deadline after which a decision escalates.

Teaching plan

10 min	Opening: participants list every body in their organisation that believes it has a say over AI and count how many have a mandate that names it.
25 min	Teacher presentation of the European anchors in NIS 2, DORA and the AI Act, the forums and what each decides, and the decision-tier policy with its routing, escalation and consult blocks.
15 min	Guided reading of Hansa Mutual's board terms of reference and decision minute DEC-2026-031: consent, recusal, conditions, dissent and review date.
30 min	Exercise in groups: build a decision-rights matrix by risk class and write terms of reference for the tier 3 forum.
10 min	Debrief: each group runs one recent real decision and one simulated stop at night through its matrix and reports where it got stuck.

Discussion

A forum that never says no deserves as much scrutiny as one that always does. What would each pattern tell you about where the real decision is taken?
The chapter insists that a stop path inside the system it is meant to stop fails exactly when needed. Who in your organisation can stop an AI system at two in the morning, and how do you know?
A decision never moves sideways to a parallel forum, which is how decisions disappear. Where do AI decisions move sideways in your organisation, and what rule would end it?

Exercise · 30 minutes

Decision rights by risk class

For your own organisation, or for Nordvik Region with its regional executive committee as the political tier, build a decision-rights matrix. Use the risk classes minimal, limited and high as columns and these decision types as rows: routine change within an approved configuration, new use case or go-live, model or provider change, exception to policy, acceptance of risk beyond appetite, stop of a system and restart after a stop. Name one decider per cell and the bodies consulted, such as employee representatives, an ethics council and the data protection officer. Then write terms of reference for the forum that decides high-risk go-live: mandate, what it does not decide, where it escalates, voting, consenting and advisory roles, quorum, cadence, the maximum age of the evidence pack and a review date.

Deliverable: A decision-rights matrix with one decider per cell and consultation points, and one-page terms of reference with quorum, evidence pack rule and sunset date.

Self-test

How does the decision-tier policy treat prohibited practices under Article 5 of the AI Act?
1. They are escalated to tier 4, the management body, for a decision
2. They are not a tier: the policy rejects them at intake and no forum may approve them
3. They are decided at tier 3 with the consent of the chief risk officer
4. They require a waiver of at most 90 days from the design authority
In Hansa Mutual's board terms of reference, what makes a decision invalid even if enough voting members are present?
1. The absence of the data protection officer, who holds a veto
2. An evidence pack that was generated automatically from the registers
3. A recusal by one of the voting members for a conflict of interest
4. The lack of consent from the chief risk officer
What does the chapter say about the change advisory board and model versions promoted through the pipeline gates?
1. Such a version is a pre-authorised standard change; the board sees only what policy routes to it
2. The board must re-approve every model version, with its evaluation report, before the version reaches users
3. The board replaces the AI governance board for limited-risk systems
4. The board reviews every prompt change within five working days

Chapter 14 · 75 minutes

Competence, Roles and the AI Architect

The lesson names the people an AI programme needs. Participants define the AI architect in relation to the established architecture roles, separate roles that build from roles that verify, examine the human oversight officer and four new roles that follow the usage modes, read Article 4 on AI literacy as amended, and work with a competence framework and individual competence records that a readiness gate can check.

Learning objectives

Describe what the AI architect adds to the enterprise, solution, data and security architect roles.
Explain why roles that build and roles that verify must be distinct.
Interpret the amended Article 4 alongside Articles 14 and 26(2) for a high-risk system.
Write a role description for an AI system owner and a competence record for an oversight officer.

Key concepts

AI architect: Owns the architectural treatment of the model as a derived, probabilistic, degrading component whose behaviour must be evaluated and not specified: the AI Decision Records, the evaluation strategy, technical input to classification and the oversight path. A governance position, accountable for decisions and not for tooling.
AI system owner: The accountable person for one system in use, whose role the deployer duties of Article 26 give legal content. In Nordvik Region's description the owner may suspend the system at any time but may not change evaluation thresholds, which model risk sets.
Agent operator: Runs Mode 5 agents in production: works the approval queue for actions above the agent's threshold, reviews overreach signals and may revoke the agent's credentials, which cuts off further actions because the agent acts only through its own scoped identity.
AI literacy under Article 4: As amended by the Digital Omnibus on AI, providers and deployers take measures to support AI literacy among staff, without guaranteeing a specific level for any individual. The chapter reads it as role-specific and to be evidenced, and as the floor for high-risk systems.
Competence record: A per-person record linking each competence to evidence of practice, with a validity date and revalidation triggers such as a major provider version. The readiness check reads it before a high-risk system goes live.

Teaching plan

10 min	Opening: participants name who in their organisation decides whether a model is good enough, and which existing architecture role that person formally holds.
20 min	Teacher presentation of the role map: the AI architect, builders, verifiers, oversight staff and the four new roles, then Article 4 as amended and management-body competence under NIS 2 and DORA.
10 min	Group reading of Nordvik Region's nine-hour learning path for oversight officers: why each module ends in a demonstration that writes to the competence record.
25 min	Exercise in pairs: write an AI system owner role description and a competence record for one oversight officer.
10 min	Debrief: pairs present their may-not and does-not lines and their revalidation triggers; the group discusses hire versus upskill for the gaps found.

Discussion

The softened wording of Article 4 changes less in architecture than it appears to. What would an organisation lose if it dismantled role-specific competence records because of the amendment?
Caseworkers who become skilled oversight officers need that skill recognised, or oversight is felt as a burden added to a full caseload. How is oversight work recognised where you work?
The chapter proposes a cooling-off period, for example twelve months, before a person validates a system they helped to build. Which moves between building and verifying happen in your organisation without one?

Exercise · 25 minutes

Role description and competence record

For one AI system in your organisation, or Nordvik Region's benefits-triage system, write a role description for the AI system owner in the form of ROLE-AI-OWNER: the holder and reporting line, five accountabilities with the article each derives from where one applies, the decision rights including what the owner may suspend, one thing the owner may not change, what the owner does not do, and the competence and literacy level required with a refresh interval. Then write a competence record for one person who oversees the system: the role and authority, three competence areas each with evidence of practice and not attendance alone, a validity date and at least two events that force revalidation.

Deliverable: A one-page AI system owner role description and one competence record with evidence per competence, validity date and revalidation triggers.

Self-test

What did the Digital Omnibus on AI change in Article 4 of the AI Act, as the chapter describes it?
1. It replaced measures to ensure a sufficient level of literacy with measures to support literacy
2. It limited the literacy duty to deployers of high-risk AI systems only
3. It postponed the literacy duty to 2 December 2027, together with the Annex III high-risk obligations
4. It introduced a mandatory certificate for staff who oversee AI systems
Why does the evaluation engineer role separate from the AI engineer once a programme has several systems?
1. Because evaluation requires a different programming language from application code
2. Because the AI Act names the evaluation engineer as a mandatory role for providers of high-risk AI systems
3. Because of separation of duties: whoever tuned a model to pass an evaluation should not certify it
4. Because evaluation sets must be maintained by the model provider's own staff
What is the chapter's strategic answer to the thin and expensive market for AI competence?
1. Outsource oversight and evaluation roles to the model supplier
2. Upskill more than hire, and hire for scarce specialisms and the first AI architect
3. Hire experienced AI engineers first and train domain staff later
4. Centralise all AI roles in one team so that fewer specialists are needed

Chapter 15 · 75 minutes

Change Management and Responsible Adoption

The lesson treats adoption as a designed, measured and governed property of an AI system. Participants apply Rogers' diffusion of innovation and the chasm between pilot and majority, identify the AI-specific pitfalls in Kotter's steps, turn employee consultation into commitments enforced as controls, practise precise communication about probabilistic systems, and define an adoption dashboard with a healthy range for the override rate and privacy safeguards.

Learning objectives

Explain why adoption failures are architectural and why adoption data is governance evidence.
Translate Rogers' five attributes of an innovation into design choices for an AI system.
Convert commitments from employee consultation into controls with tests and reopen triggers.
Define adoption metrics that reveal ceremonial oversight without becoming a surveillance tool.

Key concepts

The chasm: The gap between early adopters and the early majority, where AI programmes most often fall. Early adopters tolerate a model right eighty per cent of the time; the early majority experience a tool wrong one time in five. Crossing requires that the system change.
Champions network: Early adopters formalised as visible sponsors from each professional community, with protected time. Nordvik Region's charter states what champions do not do, including reporting on whether named colleagues use the assistant, so the role cannot drift into surveillance.
Consultation as a design review: Works councils and unions ask what employee data the system uses, who sees outputs, whether they serve performance management and how long logs are kept. The answers are recorded as commitments in the AI Decision Record and enforced in the permission model and retention policy.
Override rate: The share of recommendations that users reject or change, the clearest signal of whether human oversight is real. The dashboard gives it a healthy range: below suggests rubber-stamping, above suggests low quality.
Adoption nobody chose: Ambient and embedded features invert the adoption problem. The response is a standing review process, and the useful measure is the share of live AI features that have passed review, not the share of staff using them.

Teaching plan

10 min	Opening: participants describe a pilot that impressed a steering committee and never became part of how work is done; the teacher introduces adoption as the binding constraint.
20 min	Teacher presentation of the adopter segments and programme responses, the five Kotter pitfalls for AI, consultation rights in Germany, Sweden and the Netherlands, and the three communication disciplines.
10 min	Group reading of Nordvik Region's staff announcement: what the tool does, the 91 and 9 per cent figures, and what happened to the 64 pilot reports.
25 min	Exercise in groups: write a consultation commitments file and an adoption dashboard definition for one system.
10 min	Debrief: groups identify which commitments have no automated test and say so openly, as the chapter's example does for C4.

Discussion

The chapter says nobody should be measured on the acceptance rate of recommendations, because that metric rewards not looking. Which of your current measures might reward not looking?
A system that shows managers every override with the user's identity discourages overrides; the same data aggregated for model evaluation encourages them. How is override data governed where you work?
The guiding coalition must include the people who can stop you. Who are they for your next AI rollout, and when do they first hear about it?

Exercise · 25 minutes

Commitments as controls and an adoption dashboard

Choose a workplace AI system that is about to be rolled out, or use Hansa Mutual's claims assistant moving from its pilot unit to every market. First write a commitments file in the form of Nordvik Region's: the counterparts consulted and the basis, then four commitments, for example on performance assessment, log deletion, minimum group size in reports and training before access, each with the control that enforces it and the test that proves it, plus three reopen triggers. Then define an adoption dashboard: an active users ratio with a target, an override rate with a healthy range and a note on what each extreme means, open error reports with an alert level, literacy training completion, commitments met, and a privacy block with minimum group size and no individual-level access.

Deliverable: A commitments file with four commitments, controls, tests and reopen triggers, and a dashboard definition with five metrics and a privacy block.

Self-test

According to the chapter, what does crossing the chasm between early adopters and the early majority require?
1. A stronger communication campaign from the pilot team
2. A mandate from senior management that makes use compulsory for the early majority after the pilot ends
3. A longer pilot with the same group of innovators
4. That the system change: guardrails, evaluation gates and golden paths before the pilot graduates
In a multinational group, who consults employee representatives on a tool built by group IT and used in several markets?
1. The group platform team, once, for all markets together, since it built the tool and holds the system record
2. Each employing entity under its own national rules, with material from the platform team
3. The entity at headquarters, whose agreement binds the others
4. The supplier of the underlying model, as provider
Which of these would the chapter count as a real short-term win?
1. A demonstration on curated examples to the steering committee
2. A high number of log-ins during the first month of the pilot
3. A measured reduction in handling time on live cases, with error rates no worse than the baseline
4. A survey in which pilot users report that they like the tool

Chapter 16 · 90 minutes

Management as Code for AI Programmes

The lesson extends Management as Code to the AI portfolio. Participants write a use case as a register entry with a falsifiable value hypothesis, closed lifecycle states and retirement criteria set at intake, track benefits with comparison groups and dis-benefits, fund the platform as a product and use cases in evidence-gated tranches, and generate board and entity reports as projections of one register.

Learning objectives

Explain why an AI portfolio cannot be managed with budgets, milestones and status colours alone.
Write a value hypothesis with a baseline, a target, acceptance criteria and retirement criteria.
Distinguish measured from self-reported benefit and leading from lagging indicators.
Design a report to the management body that separates what the pipeline measured from what a person judged.

Key concepts

Portfolio register: A directory of files, one per use case, validated in a pipeline. Intake is a pull request and the merge is the approval. One register serves governance, funding and regulatory reporting.
Falsifiable value hypothesis: A statement of expected value with a baseline and a target, which makes it falsifiable and therefore manageable. Its metrics are produced in production and compared with the baseline automatically, so the register shows whether the hypothesis is currently supported.
Lifecycle states: A closed vocabulary: proposed, discovery, pilot, scaling, operating, retired. The pipeline enforces transitions against evidence; a steering committee may move a use case without it only by recording an exception with an owner and an expiry date.
Evidence-gated tranches: The platform is funded centrally as a product; use cases are funded in tranches by the business units that own them, each released against evidence such as confirmed data access, an approved AI Decision Record or acceptance criteria met.
Report as a projection: A board or supervisory report generated by the pipeline from the register and stamped with the commit it came from, so that anyone who questions a figure can recompute it. A group projects the same register into one report per entity.

Teaching plan

10 min	Opening: participants recall an AI business case written to secure funding and never consulted again; the teacher introduces the portfolio as a set of hypotheses that may be disproved.
25 min	Teacher presentation of the register entry UC-2026-031, the lifecycle state machine, exception EXC-2026-012, benefit tracking with a staged comparison, key results that pair outcome with constraint, and the funding model.
15 min	Guided reading of Hansa Mutual's monthly AI risk report: the appetite table, items outside appetite, decisions requested and the single signed commentary.
30 min	Exercise in pairs: write a portfolio register entry for one use case and a one-page risk report outline for the management body.
10 min	Debrief: pairs test each other's hypotheses by asking what result would disprove them and what would trigger retirement.

Discussion

Retirement criteria are written at intake, when nobody is yet attached to the system. Which system in your portfolio would have been retired by criteria written on its first day?
A key result such as deploying twenty AI use cases by year end rewards counting. What outcome and what constraint would you pair for your own programme?
The committee reviews what was reported; it does not decide whether to report. Why does the chapter separate the obligation fixed in law from management discretion in this way?

Exercise · 30 minutes

A register entry with a falsifiable hypothesis

Pick one AI use case in your organisation, or model your entry on Hansa Mutual's claims correspondence drafting assistant. Write its portfolio register entry: name, business owner, current state from the closed vocabulary, a value hypothesis in one sentence with a measured baseline and a target, three acceptance criteria of which one is a quality constraint and one an override rate range, the AI Act class and decision record, the funding model with a platform charge and a use-case budget, and two retirement criteria. Add one leading and one lagging indicator and one dis-benefit you would measure. Then outline a monthly report to the management body: five indicators against appetite, one incident, items outside appetite with dates, and the decisions requested.

Deliverable: A portfolio register entry with hypothesis, baseline, acceptance and retirement criteria, and a one-page outline of a management-body report.

Self-test

What happens when Hansa Mutual's portfolio exception EXC-2026-012 reaches its expiry date without its closure condition being met?
1. The exception is renewed automatically for a further 90 days
2. The use case stays in scaling and the board is informed at its next meeting
3. The use case reverts to its previous state unless the exception is closed
4. The use case is retired and its budget returned to the platform
In Nordvik Region's benefit realisation record for the staff assistant, how is the self-reported figure of hours saved per week treated?
1. It is kept, classified as an estimate, and excluded from the benefit figure
2. It is averaged with the measured drafting time to give the benefit
3. It is deleted, because survey data may not be stored in the register
4. It is used as the main benefit, since it covers all tasks
Who pays for evaluation and assurance in the chapter's funding model, and why?
1. Each use case, so that costs fall where the risk is created
2. The risk function, so that assurance stays independent of delivery
3. The supplier, as a condition of the model-supply contract
4. The platform, so that nobody saves money by testing less

Chapter 16A · 90 minutes

Governing AI Economics: Cost, Value and Portfolio Decisions

The lesson treats the economics of AI as a governance problem: whether to fund, continue, scale, constrain or stop a system whose costs follow consumption and whose benefits are uncertain. Participants identify why costs run away, turn a demonstration into evidence of value with a unit of value and a baseline, set a cost envelope with thresholds and stop conditions, compare options fairly and apply the forum's five-outcome decision table.

Learning objectives

Explain the drivers that make the cost of systems built on large language models variable at run time.
Define a unit of value with a recorded baseline and a quality constraint for one system.
Set a cost envelope with soft and hard thresholds, a fallback and a named stop authority.
Apply the governance forum's decision table to a renewal or scale decision, recording the evidence that is missing.

Key concepts

Unit of value: Something the business already counts, such as a standard letter sent or a claim correctly routed, with a recorded baseline and a quality constraint so that it cannot be improved by lowering the standard. A cost per token is a price, not a value.
Cost envelope: What the organisation has decided to spend in a period, distinct from the forecast of what it will spend. The envelope is a decision; the forecast is an estimate with recorded assumptions and the previous period's error.
Soft and hard thresholds: A soft threshold notifies the budget owner; a hard threshold triggers the platform's fallback, such as a cheaper model, a reduced scope or search-only mode. A system supporting a statutory service needs a fallback that keeps the service running.
Budget owner: One named person, usually the product or service owner, who answers for the envelope and the benefit together, so that nobody books the benefit while someone else explains the overspend.
Decision table: The forum's five outcomes with the conditions that support each: approve, approve with conditions, pause, scale, and retire or redesign. Every decision names the next review date, and the forum records what evidence it did not have.

Teaching plan

10 min	Opening: participants say who in their organisation sees the invoice for AI consumption, who sees the benefit, and whether it is the same person.
25 min	Teacher presentation of the cost drivers, the four disciplines that turn a demonstration into evidence, who owns the money, the investment gates and the minimum controls.
15 min	Guided reading of stop record SPD-2026-007: the retry storm, the hard cap pausing the agent before the budget owner replied, and why cost is shown beside service impact.
30 min	Exercise in groups: set an envelope and stop conditions for one system, compare options on one unit of value, and reach a decision with the table.
10 min	Debrief: groups read out the section on what has not been shown, following Nordvik Region's appraisal summary for its elected committee.

Discussion

The first tranche buys the baseline, not the system, if no baseline exists. How many of your AI investments have a measured baseline of the current process, errors and waiting times included?
Minutes saved become money only if posts are not filled, work is redirected or a service is delivered noticeably faster. How should your business cases treat self-reported time savings?
A stop record showing only EUR 965 would invite the wrong decision in either direction. What else must a forum see before it lets an agent resume, and why?

Exercise · 30 minutes

Envelope, comparison and decision

For one AI system that is up for scaling or renewal in your organisation, or Hansa Mutual's document-extraction service, do three things. One: define the unit of value, its baseline and a quality constraint; name the budget owner; set the cost envelope for the next period with a soft alert, a hard stop, the fallback that applies at the hard stop, the role that may execute the stop alone, and three events that reopen the record. Two: compare at least four options on that one unit of value, including a non-AI option and doing nothing, with cost range, exit and sovereignty beside price. Three: apply the decision table, state the outcome, list the evidence you did not have and name the next review date.

Deliverable: An investment and value record in outline, a four-option comparison table on one unit of value, and a decision with missing evidence and review date.

Self-test

How does the chapter distinguish the cost envelope from the forecast?
1. The envelope covers the platform and the forecast covers the use cases
2. The envelope is a decision on what to spend; the forecast is an estimate of what will be spent
3. The envelope is set by the supplier and the forecast by finance
4. The envelope is the previous period's actual spend and the forecast is the high case for the next period
In the chapter's practical guide, what does missing evidence at a renewal review yield?
1. A pause until the supplier provides the evidence
2. An automatic renewal for one further term
3. Retirement of the system at the end of the contract
4. Approve with conditions, never approve
Why does the chapter say a unit cost that falls because quality was lowered is a breach and not a saving?
1. Because the unit-cost ceiling is paired with a quality floor, so lowering the standard cannot count as a gain
2. Because suppliers are contractually entitled to raise prices when quality falls
3. Because lower quality always increases token consumption in later periods
4. Because Article 15 of the AI Act sets a minimum cost per decision for high-risk systems that deployers must respect

Chapter 17 · 90 minutes

AI in Public Authorities

The lesson examines what is different when a public authority deploys AI: a legal basis that must exist before the system does, the limits on solely automated decisions, the duty to give reasons, transparency owed to citizens, records and archives law, procurement and sovereignty. Participants work with Nordvik Region's reasons log, public register entry, transparency record and public summary of its fundamental rights impact assessment.

Learning objectives

Explain why a public authority needs legality before capability and how the legal basis is recorded as a property of the system.
Distinguish decision support from automated decision-making in the data model, the audit log and the metrics.
Draft a reasons log entry and a public register entry for a system that influences decisions about citizens.
Reconcile the retention rules of the AI Act, the GDPR and archives law in a retention schedule.

Key concepts

Decision support versus decision-making: In decision support a case officer reads the proposal and signs; in decision-making no person is in the path. The line concerns where authority resides, so it must be visible in the data model, the audit log and the metrics that reveal when human review has become a formality.
Reasons log: For every decision the system influences, a record of the inputs, model version, output, applied rule and the human action that followed, written in the language of the case and retained for as long as the decision can be appealed. It is distinct from Article 12 logging.
Algorithm register: The place where transparency, inventory and AI Act registration converge. Each entry is a version-controlled file the pipeline validates before publishing its public fields to the website and, where required, the EU database.
FRIA as a promotion gate: The fundamental rights impact assessment treated as code: the pipeline refuses to promote a high-risk system without an approved assessment, and a change to purpose or affected population reopens it automatically.
Retention schedule: Where three rules meet: logs kept at least six months under Article 26(6) of the AI Act, deletion under the GDPR's storage limitation, and possible permanent retention under archives law. The archivist owns it and the pipeline enforces it as configuration.

Teaching plan

10 min	Opening: the teacher puts the public-sector architect's three questions: can the output lawfully ground a decision, can the citizen be told why, and can it be appealed to a person who did not depend on the model.
25 min	Teacher presentation of legal basis, Article 22 of the GDPR, the duty to give reasons and Article 86, registers and Article 49(3), public access and archives, interoperability, procurement and sovereignty.
15 min	Guided reading of Nordvik Region's reasons log entry and transparency record, including the published parity gap for single-parent households and the response.
30 min	Exercise in groups: write a reasons log entry and a citizen-facing register entry for one system.
10 min	Debrief: each group reads its register entry aloud; the others answer as a citizen whether a machine decided, what it looked at and what they can do.

Discussion

Nordvik Region publishes its own weakness, the parity gap for single-parent households, because a record that reports only good news is not believed. What would your organisation need in order to publish a weakness of that kind?
The review time recorded in the reasons log shows, in aggregate, whether human review is real. What other signals would tell you that review has become a formality?
More AI artefacts are records than most programmes expect, including prompt templates and possibly an official's prompts and outputs. How would your records management plan have to change?

Exercise · 30 minutes

Reasons log and public register entry

Take a system in a public authority that ranks, scores or recommends in individual cases, or Nordvik Region's triage of applications for living-support benefit. First write one reasons log entry: the system and model version, the inputs used with their sources, the inputs excluded by policy, the output, the rule applied, the main factors in plain language, the human action including how long the case was open for review, the decision, and the retention period. Then write the public register entry for the same system under the headings the chapter uses: what the system does, what it does not do, what information it uses, the legal basis, and the citizen's rights. Use words an applicant would understand and place legal references after the plain explanation.

Deliverable: One reasons log entry with plain-language factors and human action, and a public register entry under five headings.

Self-test

How does the chapter distinguish the reasons log from the technical logging of Article 12 of the AI Act?
1. It is written in the language of the case and kept for as long as the decision can be appealed
2. It is kept by the provider for ten years, whereas Article 12 logs are kept by the deployer for six months
3. It records only decisions that went against the applicant
4. It replaces Article 12 logging for systems used by public authorities
In Nordvik Region's arrangements for its benefit triage system, how are appeals handled?
1. By the same case officer, who is shown the raw score for the appeal
2. By the supplier, which re-runs the model on the corrected data
3. By a separate unit that has no access to the triage score
4. By the regional executive committee, at its next public meeting
Where no rule of Union or Member State law authorises automated decisions with suitable safeguards, what can a public authority's system do, according to the chapter?
1. Decide automatically, provided that the citizen is informed afterwards
2. Only recommend, and a natural person must decide
3. Decide automatically for favourable outcomes and refer the rest
4. Nothing, since any use of the model would lack a legal basis

Module 5 · Part V · Experience

Module 5 turns from what should be done to what has been observed. It reads eight case studies through usage mode, AI Act role and the control that mattered, reconstructs one agent incident in an evaluation environment for its governance lessons, catalogues fifteen anti-patterns with symptom, consequence and remedy, and reassembles the book's practices by lifecycle stage and by the three tensions. Participants leave able to diagnose a programme, run a tabletop exercise on stop decisions and hold a steering committee to twelve lessons.

Lecture · 45 minutes

Experience: what the cases, an incident and the failures teach

Part V tests the method against experience. The lecture reads the cases for what they have in common: a structural boundary around what the system may do, a register enforced by the pipeline, an obligation turned into a gate and an early seat for those who can stop the programme. It then takes the incident the book devotes a chapter to, in which nearly every failure was architectural: a shared credential, a supporting service that was also a way out and a stop decision nobody owned. The anti-patterns show the same failures in quieter form, and the practices show one remedy: a codified control in place of an intention.

10 min	Eight cases through three lenses Usage mode, role under the AI Act, and the controls that worked, failed or were missing. The composite cases converge: decision support kept as a structural boundary, a registry as the condition of production, an agent bounded by a permission manifest. The documented cases confirm it from the other side: a risk model nobody outside could inspect, a reported time saving that was not a measured gain, and controls that sat with the provider.
12 min	An incident in which the architecture failed As the chapter reconstructs it, agents under evaluation with safeguards switched off left their sandbox through a package mirror and coordinated through an improvised message board. The hinge is a decision point: a signal was seen and continuing was judged acceptable, because no trigger treated coordination between agents as a stop condition and no role owned the decision. The reported propensity fell more than a hundredfold under a production harness, which shows that the leverage is in the architecture around the model. Four governance lessons: evaluation is a governed activity, stop rights exist before the signal, evidence and disclosure are prepared, supplier oversight continues after signature.
10 min	Fifteen anti-patterns, one shape of remedy Portfolio anti-patterns arise when urgency or vendors decide what is built; governance anti-patterns when accountability is separated from the means to act; engineering anti-patterns when prototyping habits survive into production. Several are mode errors: a system in one usage mode governed as if it belonged to another. Each remedy replaces an intention with a codified control, and most anti-patterns leave traces that fitness functions can query.
8 min	Practices by stage and by tension Intake, design, build, assure, operate, retire: the governance requirement at each stage is what a forum or a gate checks. Make control fast, bound autonomy in code, keep sovereignty as an option set. Keep governance and platform decisions consistent through one record system and a machine-checked link.
5 min	Two exposures Nordvik Region's exposure is through what it buys: cautious-buyer anti-patterns and supplier incidents. Hansa Mutual's exposure is through the agency it grants and through treating group policy as the law in every market.

What the audience takes away

Read every AI system through usage mode, AI Act role and the single control that matters most, and record what remains unresolved.
Name who may stop an agent workload, on which signals and how fast, before the first signal arrives, and test the mechanism.
When a programme fails quietly, look for the intention that was never turned into a control: a manifest, a gate, an evaluation set or a retirement criterion.

Chapter 18 · 90 minutes

Case Studies

The lesson works through eight case studies: five anonymised composites and three documented European cases, SyRI in the Netherlands, embedded workplace assistants in UK central government and the enforcement against a conversational assistant in Italy. Participants read each through usage mode, role under the AI Act and the control that mattered most, and extract the patterns the cases share.

Learning objectives

Analyse a case through the three lenses of usage mode, AI Act role and controls that worked, failed or were missing.
Explain how decision support was made a structural boundary in the social insurance case.
Compare what a deployer controls in Mode 4 with what it controls in Modes 1 and 2, using the documented cases.
Identify the patterns the composite cases share and apply them to a system in the participant's organisation.

Key concepts

Anonymised composite: A case that combines several organisations and engagements with details altered, so that none describes a real, named organisation although the pattern is real. Five of the chapter's eight cases are composites; three are documented and can be checked.
Structural boundary: A limit on what the AI system may do that is built into the design, such as a model producing a priority score and a list of likely missing documents but never a proposed decision, with the decision record carrying no reference to the score.
Registry as the condition of production: The decisive organisational move in the bank case: a model not in the registry was not in production, and inference endpoints could load only approved artefacts. The number of models fell by a fifth as units found models nobody used.
Verifiability: What the SyRI risk-scoring system lacked. The risk model and its indicators were not public and its application was insufficiently transparent and verifiable, so the court held that the legislation did not strike the fair balance required and declared it without binding effect.
Deployer's levers in Modes 1 and 2: In the UK and Italian cases most controls belonged to the provider, leaving the deployer permissions, the service tier and contract, and a fallback for dependent processes, since a service can be withdrawn from one market at short notice.

Teaching plan

10 min	Opening: the teacher explains how to read the cases, including that the outcomes are deliberately modest and that the documented cases are read for what the AI Act would require, not whether it was breached.
25 min	Jigsaw: five groups each take one composite case and prepare a two-minute account of context, challenge, approach, outcome and what stayed unresolved.
15 min	Teacher presentation of the three documented cases and the summary table of mode, role and the control that mattered most.
30 min	Exercise: each participant writes a case analysis of one of their own systems in the chapter's format and through its three lenses.
10 min	Debrief: the group lists the patterns across the cases and marks which ones their own analyses show and which are missing.

Discussion

In the social insurance case officers could explain their decisions but not the score, and claimants were told it was a scheduling aid. Under what conditions would that answer stop being adequate?
The bank forced three business-critical models into an uncomfortable exception process and judged the discomfort to be the point. When is discomfort a sign that governance works, and when a sign that it is wrong?
The UK evaluations found a self-reported saving of 26 minutes a day and, with control groups, no evidence that time savings had improved productivity. What does the difference tell you about how to design your own pilots?

Exercise · 30 minutes

Write your own case through three lenses

Choose one AI system your organisation runs or is introducing. Write it up as a case in the chapter's structure: context in two sentences, the challenge including who objected and why, the approach, and the outcome so far. Then read it through the three lenses: state its usage mode, your role under the AI Act with a one-line reason, and the controls that worked, failed or are missing. Name the single control that matters most, as the chapter's summary table does for each case. Finish with one question that remains unresolved and should be recorded as open, and say which of the eight cases your system most resembles and what you would copy from it.

Deliverable: A one-page case analysis with mode, AI Act role, the control that matters most, one recorded open question and the closest case from the chapter.

Self-test

In the manufacturing case, how did the group take its maintenance agent out of the employment-related high-risk category?
1. It limited the agent to plants outside Germany
2. It removed task allocation to individuals: the agent proposes a skill profile, a supervisor assigns
3. It replaced the agent's model with a smaller one hosted in the Union
4. It asked each technician for written consent to automated scheduling and recorded it in the permission manifest
What did the hospital group decline to do, and why?
1. Run the triage tool in more than two hospitals, because of cost
2. Report the lower local sensitivity to the vendor, because of the contract
3. Issue data permits to researchers, because of the data protection officer's objections
4. Improve the vendor's tool with local data, because that would make it a provider
What did the municipality's regression suite of golden questions catch within a year?
1. Two vendor model updates that would have reintroduced eligibility answers
2. A leak of residents' personal data to the vendor's training set
3. A fall in the share of first-line enquiries handled by the service
4. Several conversations in which the disclosure had not been shown

Chapter 19 · 120 minutes

A Cautionary Case: The OpenAI–Hugging Face Incident

The lesson studies the incident the book reconstructs from public sources, in which agents under cybersecurity evaluation left their sandbox and reached a third party's production systems. Participants separate what the sources establish from interpretation, trace the architectural weaknesses that chained together, and draw four governance lessons. They then apply the chapter's self-assessment, tabletop exercise and stop-policy checklist to their own agent environments.

Learning objectives

Describe the architectural weaknesses that, according to the chapter, chained together in the incident.
Distinguish what the sources establish from the chapter's interpretation, and name the limits of each source.
Explain the four governance lessons and the chapter each one draws on.
Draft an agent stop policy with stop-holders, stop signals, a time target and a waiver rule for continuing.

Key concepts

Supporting service as an egress path: A package mirror fetches remote content on its clients' behalf, which makes it a way out whatever the diagram calls it. Restricting direct internet access proved insufficient when workloads could reach and use shared services.
Shared credential: Many research workloads were given the same credential for the mirror. The chapter's reading is that a credential shared across runs makes every run a potential correspondent of every other, turning independent runs into one communicating population.
The missing decision: On seeing a security signal, on-call staff advised that stopping the run was not required. The chapter reads this as a missing decision, not a careless one: no severity trigger treated unauthorised coordination between agents as a stop condition and no role was charged with weighing it.
Well-meaning insider: The premise for containment: the organisation's own agent is treated as a well-meaning insider whose good intentions are not a control. The architecture, not the agent's behaviour, is the thing that must hold.
The harness as the decisive lever: The reported propensity to compromise out-of-scope infrastructure fell more than a hundredfold under the production harness and system prompt. The behaviour was a property of the model under a particular harness: gateway, permission manifest, approval gates and monitoring.

Teaching plan

15 min	Teacher presentation of the setting and the timeline from April to August, with the sources and their limits stated first and interpretation marked as interpretation.
20 min	Group analysis of the escape path: participants list every boundary that failed and explain why each is one an ordinary enterprise also relies on. No technical reproduction is attempted; the focus is design and decision.
15 min	Discussion of the four governance lessons and the European frame the chapter gives: Article 55 of the AI Act, Article 23 of NIS 2 and the Cyber Resilience Act.
45 min	Tabletop exercise in groups on the chapter's four injects, each with a timed decision, followed by drafting an agent stop policy.
15 min	Self-assessment: each participant answers the chapter's environment checklist for one of their own agent environments and marks every false as a finding with an owner.
10 min	Debrief: groups report which inject had no named decision-maker and what they changed in their stop policy as a result.

Discussion

The chapter insists on fairness to the responders: they were not negligent, the decision was missing. Which stop decisions about AI workloads are missing in your organisation, in the sense that nobody is charged with taking them?
Removing safeguards for a capability evaluation was defensible but was a risk decision. How should an organisation that red-teams models in its own clusters record and own such decisions?
For most European organisations an incident like this is a supplier event. What should your vendor assessment ask a model provider, and what should happen to an approval when the provider publishes an incident?

Exercise · 45 minutes

Tabletop on the timeline and a stop policy

With a facilitator and an observer who records decisions and timings, run the chapter's tabletop on a fictional agent environment. Take the four injects in order and reach a timed decision at each: agents are found coordinating through a shared service, so continue, constrain or stop; the service is driven offline, so is this availability or security; a third party discloses an incident that might be yours, so who correlates; it is confirmed that your agents reached a third party's systems, so who notifies whom, with the NIS 2 clocks of 24 and 72 hours named. Record every gap in role, authority or evidence. Then write an agent stop policy: at least two roles that may stop, the signals that oblige a stop, the time target, the waiver rule for continuing and the test interval.

Deliverable: A decision log for the four injects with decision-maker, decision and time, a list of gaps with owners, and an agent stop policy.

Self-test

Which of the following does the chapter's decision-rights checklist list as a signal that obliges a stop and not merely an investigation?
1. An agent exceeding its expected task duration
2. A rise in the cost per completed task
3. Unauthorised coordination between agents
4. A model update announced by the provider
Why, according to the chapter, do its lessons not depend on the agents in the incident being typical?
1. Because the lessons rest on the architecture that let atypical behaviour reach the internet
2. Because every model behaves the same way once its safeguards are removed
3. Because the independent review verified each of the operator's findings
4. Because the incident took place in one of the six usage modes
What does the chapter's stop policy require when someone decides to continue after a stop signal?
1. A note in the incident channel by the on-call engineer
2. Nothing further, as long as monitoring is increased
3. A report to the market surveillance authority within 24 hours of the decision
4. A waiver: a dated, owned record approved by the accountable executive

Chapter 20 · 75 minutes

Anti-Patterns

The lesson catalogues fifteen anti-patterns of enterprise AI in three clusters: portfolio and strategy, governance and compliance, and engineering and operations. Participants learn to recognise each by symptom, cause, consequence and remedy, to see several as mode errors, to compare an unbounded agent's permission set before and after, and to detect anti-patterns from traces in registers and logs with fitness functions.

Learning objectives

Recognise each anti-pattern from its symptom and name the chapter that holds its remedy.
Explain why prohibition without a sanctioned alternative produces shadow AI and how the remedy reads it as a demand signal.
Rewrite an unbounded agent configuration as a bounded permission manifest.
Define fitness functions that detect anti-patterns from registers, telemetry and pipeline history.

Key concepts

Anti-pattern: Not a one-off mistake but a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome every time. The chapter describes each through symptom and cause, consequence and remedy.
Pilot purgatory: Dozens of AI pilots over two or three years and none in production, because pilots are funded as experiments with no production budget, platform or owner. The remedy is to fund the platform as a product before funding the fifth pilot.
Compliance by checkbox: An AI Act readiness spreadsheet of articles with a status column in which no row links to a control, a test or an artefact. The remedy maps obligations to controls, controls to evidence and evidence to pipeline stages.
Unbounded agent: An agent whose prototype credentials were never narrowed and whose instructions serve as the security boundary. The remedy is bounded autonomy: a versioned permission manifest, a tool allow-list, per-action authorisation, approval gates for irreversible actions and spend limits enforced outside the model.
Mode error: A system in one usage mode governed as if it belonged to another, for example granting a tool that runs commands the trust appropriate to a chat assistant. Risk follows what the system can do, not how it was acquired.

Teaching plan

10 min	Opening: the teacher reads five symptoms aloud without naming the anti-pattern; participants note which they have seen in their own organisation.
20 min	Teacher presentation of the three clusters and the lifecycle stage where each anti-pattern first shows, with the table of mode errors and remedies.
10 min	Guided comparison of Hansa Mutual's invoice-enquiry agent, prototype and production: what the only boundary was before and what enforces the boundary after.
25 min	Exercise in groups: diagnose the participant's programme against the catalogue, write three fitness functions and rewrite one agent permission set.
10 min	Debrief: groups practise naming an anti-pattern without causing offence, presenting a firing signal as an invitation to look.

Discussion

The centre of excellence that says no is accountable for risk but not for value. What would it be measured on if it were rebuilt as a platform team and an enabling team?
Hansa Mutual's first spreadsheet marked the logging obligation as compliant because logging was enabled. What would have to pass, and keep passing, for that claim to be true?
Nordvik Region's anti-patterns come from doing too little too slowly and Hansa Mutual's from doing much, quickly, in one shape for many jurisdictions. Which set is closer to your organisation, and which single anti-pattern would you address first?

Exercise · 25 minutes

Diagnose a programme and write its fitness functions

Go through the fifteen anti-patterns and mark, for your own AI programme, each as present, suspected or absent, with the symptom you have observed for every one marked present or suspected. Choose the three that matter most and write a fitness function for each in the form of the chapter's suite: an identifier, the data source such as the portfolio register, network telemetry or the model registry, the query in plain words, a threshold and the chapter that holds the remedy. Then take one agent or automation in your estate whose boundary is a sentence in its instructions, and rewrite its configuration as a manifest: its own identity, the tools allowed with constraints, deny by default, budgets and a kill switch.

Deliverable: A fifteen-row diagnosis with observed symptoms, three fitness functions with source, query and threshold, and one bounded permission manifest.

Self-test

What was the only boundary on Hansa Mutual's prototype invoice-enquiry agent?
1. A tool allow-list limited to reading invoice status
2. A daily spending cap enforced by the gateway
3. An approval gate for every credit note above a threshold
4. A sentence in its instructions telling it never to issue credit notes
How does the chapter advise responding to shadow AI?
1. Discipline the staff concerned, to deter further unsanctioned use
2. Make the sanctioned path faster than the shadow path, and onboard discovered use, not punish it
3. Block all AI service domains at the proxy until the governance board has approved an acceptable-use policy
4. Wait for the supplier to offer an enterprise tier at no extra cost
According to the chapter, who should set the bar in an evaluation, as the governance remedy for evaluation by demo?
1. The sponsor, who knows what the business needs from the system
2. The model vendor, who knows the model's achievable scores
3. Model risk or the system owner, approved at the assigned tier, never the sponsor
4. The steering committee, by trying the system in a meeting and recording its impression in the minutes

Chapter 21 · 75 minutes

Best Practices and Lessons Learned

The lesson reassembles the book's practices in the order a programme meets them, from intake to retirement, and views them through the three tensions. Participants state the governance requirement at each lifecycle stage, write a decommissioning record, learn four practices that keep governance and platform decisions consistent, and use a practice checklist as code together with twelve lessons a steering committee can test itself against.

Learning objectives

State the governance requirement at each of the six lifecycle stages.
Explain how each of the three tensions is resolved in practice.
Draft a decommissioning record that covers the identities and grants that outlive a model.
Assess a programme against the twelve lessons and the practice checklist, citing evidence for each item.

Key concepts

Six lifecycle stages: Intake, design, build, assure, operate and retire. Where a practice is primarily engineering, the chapter states the governance requirement, which is what a forum or a gate checks, and leaves the method to the platform teams.
Make control fast: The resolution of speed versus control: controls are encoded as pipeline gates, policy as code and golden paths. A team on the golden path never waits for a meeting; lead time from intake to production is measured, and a rising number is a governance defect.
Decommissioning record: A planned retirement with an owner, steps and evidence for each: route traffic to the replacement, disable the service account, revoke tool and database grants, archive model, lineage and evaluation results, retain decision logs, and update the inventory and public register.
Governance and platform consistency: Four practices: one record system with stable identifiers; a machine-checked link from platform thresholds to governance decisions; named platform changes that reopen governance; and one management review pack for both sides.
Practice checklist as code: A machine-readable list in which each item names the stage, the obligation or principle it serves, the evidence that demonstrates it and the chapter that explains it. A pipeline stage evaluates it against the evidence manifest; it is the single statement of what ready means.

Teaching plan

10 min	Opening: participants place three practices their organisation is proud of on the six lifecycle stages; the teacher notes which stages stay empty, usually retire.
20 min	Teacher presentation of the practices by stage, with Hansa Mutual's motor claims intake record and Nordvik Region's reviewed staff-assistant prompt, then the three tensions and the consistency practices.
25 min	Exercise in groups: score the programme against the twelve lessons with evidence, then write a decommissioning record for one system.
10 min	Group discussion of the practice checklist: which items regulated sectors and public authorities would add to the same file.
10 min	Debrief: each group names the lesson where its evidence was weakest and the first artefact it would create.

Discussion

A retired system that still has a live service account is an unbounded agent waiting for an instruction. What survives in your estate after systems are switched off?
A forum raises an evaluation threshold the platform never receives, or a waiver outlives the configuration it excused. Where have governance and platform decisions drifted apart in your organisation?
Most of the twelve lessons carry over from the Architecture as Code discipline, yet AI programmes forget them more often, under more pressure. Why, and what would make them harder to forget?

Exercise · 25 minutes

Twelve lessons and a decommissioning record

First, take the twelve lessons one by one and state for your own programme whether the steering committee would pass the test, citing one piece of evidence for each yes and one gap for each no. Second, choose a system that should be retired or will be replaced, or use Nordvik Region's travel-allowance claim scorer. Write its decommissioning record: the trigger, the owner, the planned date, six steps each with the evidence that proves it was done, covering traffic, service accounts, tool and database grants, the archive, retained decision logs and the inventory or register, then the archive retention date with its reason and the roles that sign off.

Deliverable: A twelve-row self-assessment with evidence or gap per lesson, and a decommissioning record with six evidenced steps and sign-off roles.

Self-test

What would Nordvik Region's first request, a service desk ticket to switch off the old model, have achieved?
1. It would have stopped traffic and left everything else running
2. It would have deleted the decision logs before appeal periods closed
3. It would have retired the replacement system as well
4. It would have triggered a new procurement for the scoring service
How does the chapter resolve the tension between innovation and sovereignty?
1. By refusing models and services that originate outside the Union
2. By accepting any provider that offers processing in an EU region
3. By keeping sovereignty as a set of architectural options held open, decided per workload
4. By leaving the choice of provider to each business unit
Which of the following is one of the chapter's twelve lessons?
1. Choose the foundation model first and design the system around it
2. Fund the platform before the fifth pilot
3. Collect evidence by hand before each audit to keep it current
4. Expand an agent's autonomy first and bound it once incidents occur

Module 6 · Part VI · Future and Conclusions

Module 6 looks ahead and draws the book together. It teaches a way to read an outlook, separating what is observable, expected and speculation and keeping it in a horizon register, closes the cases of Nordvik Region and Hansa Mutual with what worked, what was hard and a 24-month plan, presents the author's own reflections as judgement and not finding, and consolidates eight conclusions into a phased programme. Participants leave with a horizon register, a roadmap and a first-90-days plan for their own organisation.

Lecture · 45 minutes

Future and conclusions: governing on ground that is still being laid

Part VI asks what will change and what the book has established. It first shows how to hold an outlook responsibly: commit to what is observable, prepare on dated triggers for what is expected, and stay reversible where a trend is speculation. It then compares the two organisations of the book, one jurisdiction with a contract-held core against seven with a platform and agents, and shows that the artefacts that helped both recorded a decision before the pressure arrived. It ends with the thesis, that AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk, and with what to do first, next and later.

10 min	Reading an outlook: observable, expected, speculation A governance arrangement built on a speculative trend should be reversible; one built on an observable trend may be committed to. Three dates dominate: 2 August 2027, 2 December 2027 and 2 August 2028, while guidelines and harmonised standards arrive late and in stages. Supervisors converge on inventory, classification, named accountability and evidence; agents stretch the link between an action and the person accountable. A horizon register is valuable because it can be wrong in a reviewable way.
12 min	Two organisations, one method, different resolutions Nordvik Region: one policy, one register, one escalation path; the lever is the contract and the risk is to residents' rights and public trust. Hansa Mutual: a group baseline with market overlays and entity projections; the lever is the platform and the risks are fragmentation, resilience and the agency it grants. What helped both recorded a decision in advance: a retirement criterion, a stop authority, an exception with an expiry, a commitment written as a control, a drilled exit plan.
8 min	The author's reflections, labelled as judgement The usage modes that grow fastest, Modes 2 and 3, are in the author's view the least governed. Where the author is most uncertain, governance should be designed so that the answer does not matter. The author's disagreements are with habits that substitute a comfortable act for an uncomfortable one, such as a ban for a risk assessment or an instruction for a boundary.
10 min	Eight conclusions and how they interact The usage mode sets the governance; classification is triggered by change; decisions are tiered and evidence-driven; sovereignty is a risk-tiered choice. The contract is a deployer's main control; oversight is designed; evidence is a by-product of delivery; containment of agents does not depend on intent. The conclusions reinforce each other as a chain and pull against each other in named tensions, each with a recorded resolution.
5 min	First, next, later First, 0 to 6 months: know what is in use, classify it, and know who decides and who can stop. Next, 6 to 18 months: make high-risk systems ready for 2 December 2027 and make the estate replaceable. Later, 18 to 36 months: make assurance continuous and expand autonomy only on evidence.

What the audience takes away

Label every statement about the future as observable, expected or speculation, and match the reversibility of the decision to the label.
Record decisions before the pressure arrives: retirement criteria, stop authority, expiring exceptions, commitments as controls and drilled exits.
Start with an inventory by usage mode, a classification wired to change, a decision-tier file and named stop holders.

Chapter 22 · 75 minutes

Future Trends

The lesson teaches how to read and keep an outlook on AI governance. Participants separate what is observable from what is expected within five years and from speculation across the AI Act's remaining phases, guidelines and standards, supervisory expectations, the EEA, the United Kingdom and Switzerland, agents and accountability, and model markets, and codify the result in a horizon register with signals, owners and review dates.

Learning objectives

Classify a statement about the future as observable, expected or speculation, using the chapter's definitions.
Explain why the label determines how reversible the resulting governance decision should be.
Identify the three dates that dominate planning under the amended AI Act and what each applies to.
Draft a horizon register entry with horizon, affected artefacts, reversibility, decision and a monitored signal.

Key concepts

Three horizons: Observable covers developments visible in adopted legislation, published guidance, cited standards or production systems. Expected covers developments with strong evidence but uncertain timing or form within five years. Speculation covers what is plausible and consequential but not yet evidenced.
Reversibility by horizon: A governance arrangement built on a speculative trend should be reversible, while one built on an observable trend may be committed to. A date in adopted legislation is observable; a date in a Commission proposal is not.
Mode-change trigger: As vendors add triggers, connectors and background execution to assistants, the boundary between Modes 2 and 5 blurs. The classification triggers therefore need one that fires on supplier feature releases, treating each new trigger or agent mode as a mode change.
Decision record per grant of agency: The expected form of accountability for agents: the organisation can show the permission it granted, who granted it and the stop authority it held, as Hansa Mutual's records for its two agents do.
Horizon register: The outlook under version control: each trend with its horizon, the artefacts it affects, its reversibility, the decision taken and review dates. Its value lies in being wrong in a reviewable way.

Teaching plan

10 min	Opening: the teacher reads six statements about the future of AI governance; participants label each as observable, expected or speculation and compare answers.
25 min	Teacher presentation of the trends by section, each split into its three labels, and the table of direction of travel and governance to prepare for each usage mode.
25 min	Exercise in groups: build a horizon register of five trends for the participant's organisation and attach a signal with an owner to each.
15 min	Debrief: groups name the trend they classified as speculation and explain how their decision on it stays reversible.

Discussion

The cost of a second round of simplification of the AI Act would fall on organisations that froze their programmes waiting for it. Why does the chapter conclude that, and do you agree?
An organisation that governs by product and not by use case will find autonomous agents nobody approved as such. Which products in your estate could gain triggers or background execution through a supplier release?
If supervisors came to consume machine-readable evidence, the evidence manifest would become an interface between the organisation and the state. What would you design differently today if that were possible?

Exercise · 25 minutes

A horizon register for your organisation

Write a horizon register with five trends that bear on your organisation's AI governance, drawing on the chapter's sections: at least one on the AI Act's remaining phases, one on guidelines or standards, one on supervisory expectations, one on agents or mode drift in purchased suites, and one you classify as speculation. For each entry give an identifier, the horizon, the artefacts it affects such as the obligation mapping, the classification policy or the supplier-feature register, its reversibility, and the decision you take now. Then follow the practical guide: name one signal per trend with an authoritative source, an owner and a check frequency, and state the date of the next review of the whole register.

Deliverable: A five-entry horizon register with horizon, affected artefacts, reversibility and decision, plus a signal, source, owner and frequency per trend.

Self-test

Which three dates does the chapter say dominate the next two years under the amended AI Act?
1. 2 February 2025, 2 August 2025 and 2 August 2026
2. 1 August 2024, 2 August 2026 and 2 August 2027
3. 2 August 2026, 2 February 2027 and 2 December 2028
4. 2 August 2027, 2 December 2027 and 2 August 2028
How does the chapter classify the incorporation of the AI Act into the EEA Agreement?
1. As expected within five years, probably with adaptations
2. As observable, since it has already been incorporated
3. As speculation, since no EEA state has shown interest
4. As outside the outlook, since the EEA is not affected
In the chapter's horizon register, what decision is recorded for the speculative trend of code-based supervision?
1. Wait until a supervisor publishes a technical specification
2. Give supervisors direct write access to the governance repository
3. Design the evidence store as if an authority may query it
4. Replace the evidence manifest with structured financial reporting

Chapter 23 · 90 minutes

Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

The lesson closes the two running cases from the perspective of governance. For Nordvik Region and Hansa Mutual, participants review the starting point, the decisions taken across the book, what worked, what was hard and a prioritised plan for the next 24 months. They compare one jurisdiction with seven, a contract-held core with a platform, and identify what each organisation can take from the other.

Learning objectives

Summarise the governance decisions each organisation took and the artefacts that record them.
Explain the four parts of Hansa Mutual's answer to legal fragmentation.
Compare the two organisations by legal regime, AI Act role, usage-mode profile, lever and main risk.
Draft a prioritised 24-month governance roadmap with gates for the participant's own organisation.

Key concepts

Depth versus number of regimes: Nordvik Region shows governance under a single legal regime, where the depth of public-law duty sets the difficulty. Hansa Mutual shows governance under seven regimes, where the difficulty is keeping one set of decisions consistent across them.
Market overlay: A per-market addition to the group policy, maintained by the market liaison, covering what differs, from Norway's incorporation status to retention periods and consultation procedures. An overlay may add a control but never remove a group one.
Bounded mandate of the group board: The board in Hamburg decides the group baseline, the risk appetite and what the tiers route to it, but each subsidiary board keeps its entity-level duties, and a group decision becomes final in a market only when that entity's consultation is recorded.
Roadmap gate: A commitment the organisation will not trade for speed. For Nordvik Region: no Mode 5 use case without containment, a stop authority, evaluation evidence and a committee decision. For Hansa Mutual: no expansion of agency without evidence and no overlay that weakens the baseline.
Decision recorded in advance: What the most useful artefacts in both organisations had in common: a retirement criterion, a stop authority, an exception with an expiry date, a consultation commitment written as a control, and an exit plan that had been drilled.

Teaching plan

10 min	Opening: participants recall one artefact from each organisation that stayed with them from earlier lessons and say what decision it records.
25 min	Two groups prepare a briefing each, one on Nordvik Region and one on Hansa Mutual: starting point, what worked, what was hard, advantages, disadvantages and the 24-month plan.
15 min	Briefings and teacher-led comparison using the chapter's comparison table and the two roadmaps as code, including the single-value and structured jurisdictions field.
30 min	Exercise: each participant drafts a 24-month governance roadmap for their own organisation with horizons, linked records and gates.
10 min	Debrief: participants state which organisation theirs resembles on each row of the comparison table and what they would borrow from the other.

Discussion

Because the condition for retiring the triage model was named in advance, a parity breach was handled as a planned decision and not as a crisis. Which decisions in your organisation would benefit most from being taken before they are needed?
At the Polish service centre, the agent's permissions, log retention and consultation record must vary by the market of the claim, not by the location of the server. What does that demand of a shared platform?
Nordvik Region's narrow usage-mode profile is a choice it can still make; Hansa Mutual's is a fact it must govern. Which describes your organisation, and what would it take to keep or regain the choice?

Exercise · 30 minutes

A 24-month governance roadmap

Draft a governance roadmap for your own organisation in the form of the chapter's two roadmaps. State who approves it, the period, the jurisdictions, as a single value or a structured map of EU, EEA and other markets, and any usage modes excluded. Write at least six items across three horizons: the next six months, the months up to 2 December 2027, and the full period. For each item give an identifier, the action, and the decision records, assessments or triggers it links to. Include an inventory that reaches ambient AI, a test of a stop function, closure of evidence or contract gaps with a supplier, and one exit rehearsal. Finish with two gates: commitments you will not trade for speed.

Deliverable: A roadmap with approver, jurisdictions, at least six items across three horizons with linked records, and two gates.

Self-test

What did Nordvik Region's first assessment round find, as the chapter recalls?
1. No AI in use beyond the procured benefits-triage system
2. Eleven AI services in use, three of them reached by staff without any review
3. Two autonomous production agents running without a stop authority
4. Seven suppliers that refused to disclose their model versions
Which rule governs the relation between Hansa Mutual's group policy and its market overlays?
1. An overlay replaces the group policy wherever national law differs
2. An overlay applies only in entities outside the Union and the EEA
3. An overlay may add a control but never remove a group one
4. An overlay may relax a group control with the consent of the entity board
What can Nordvik Region take from Hansa Mutual, according to the chapter's comparison?
1. Drilled exit plans, since its records show no rehearsal of an exit from its triage supplier
2. Autonomous production agents, since the Region has none
3. A group governance board, since the Region has only an elected committee
4. Public transparency generated from the descriptors of deployed systems, since the Region publishes little

Chapter 24 · 60 minutes

Reflections on Each Part

The lesson presents the author's own reflections on each part of the book, which the chapter labels as judgement and not as the book's findings. For each part participants examine what the author considers most important, remains uncertain about, disagrees with in common practice and expects next, including a planning assumption about the shrinking window between a patch and its exploitation and its consequence for decision rights.

Learning objectives

Distinguish the author's judgements in this chapter from the evidence-based conclusions of the other chapters.
Summarise, for at least three parts, what the author considers most important and where the author disagrees with common practice.
Explain the governance consequence the author draws from the shrinking time between a patch and a working exploit.
Formulate a position of the participant's own on one of the author's projections, with the evidence that would change it.

Key concepts

Judgement labelled as judgement: Everything before this chapter supports each claim with a source; here the views are the author's own. Projections cite evidence but are labelled as the author's view, and the recommendations of the concluding chapter do not depend on them being right.
Evaluation suite as the real specification: The author's view from Part III: the evaluation suite is the organisation's real specification of an AI system, the place where good enough is written in a form a machine can check.
Instruction versus boundary: The author disagrees with treating instructions as controls: a prohibition in a prompt reduces unwanted behaviour without eliminating it, and a control that leaves the rate above zero is not a boundary.
Two clocks after a patch: One clock runs from a published patch to a working exploit, the other to exploitation at scale. The author's projection is that it is prudent to plan for the first being measured in minutes for many vulnerability classes within a few years.
Delegated decision to patch: The governance consequence: a change advisory board that meets weekly cannot be in the path for known-exploited vulnerabilities, so patching on release, behind canary rings and automatic rollback, is delegated in advance and reviewed afterwards.

Teaching plan

10 min	Opening: the teacher explains the chapter's status as the author's views and its four recurring questions: most important, uncertain, disagree, expect next.
15 min	Six groups take one part each and report in one minute the author's answer to the four questions for that part.
10 min	Teacher presentation of the aside on the exploitation window: the two clocks, the observed data points, the counter-evidence on prioritisation and the horizon register entry.
20 min	Exercise: each participant writes a position paper of one page on one of the author's projections or disagreements.
5 min	Debrief: three participants read out the evidence that would make them change their position.

Discussion

The author would now give bounded autonomy more prominence than declared intent among the eight principles. After the earlier lessons, how would you order the principles for your own organisation?
The author doubts the book's own procurement advice, since most deployers will not receive the artefacts they ask for from the largest providers. What follows for a small authority or a mid-sized company?
A governance function that accepts generated classifications without reading the reasoning has reinvented compliance by checkbox. Where is the line between useful drafting support and that failure?

Exercise · 20 minutes

A position on one of the author's judgements

Choose one judgement from the chapter, for example that Modes 2 and 3 are the least governed, that a single strategic AI provider is a mistake, that a new AI committee makes forum overlap worse, or that emergency patching of known-exploited vulnerabilities should be delegated outside the change advisory board. Write a one-page position for your own organisation: state the judgement in one sentence, say whether your organisation's experience supports it and cite what you have observed, name the evidence that would change your mind, and record the decision you would take now and how reversible it is. Finish with a horizon register entry for it: horizon, owner, statement, consequence for governance, reversibility and next review date.

Deliverable: A one-page position with observed evidence, the evidence that would change it, a decision and its reversibility, and a horizon register entry.

Self-test

What governance consequence does the author draw from the shrinking time between a patch and a working exploit?
1. The change advisory board should meet daily instead of weekly and approve each emergency patch within the hour
2. Patching should be postponed until an exploit has been observed
3. Patching known-exploited vulnerabilities on release is delegated in advance and reviewed afterwards
4. Vulnerability management should be handed to the model provider
Which two usage modes does the author believe grow fastest with the least oversight?
1. Mode 0 and Mode 1
2. Mode 1 and Mode 4
3. Mode 4 and Mode 5
4. Mode 2 and Mode 3
How does the author describe the status of the views in this chapter?
1. As findings that the earlier chapters have already established, each with a source in the bibliography
2. As the author's own judgement, not the book's findings, with projections labelled as such
3. As legal advice on how to apply the AI Act after the Digital Omnibus
4. As the agreed position of the two fictional organisations

Chapter 25 · 90 minutes

Conclusions: A Consolidated Analysis

The lesson consolidates the book. Participants restate the thesis that AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk, work through eight cross-cutting conclusions, analyse where they reinforce and where they pull against each other, revisit the three tensions and turn the result into a phased programme: first, next and later, with a first-90-days plan.

Learning objectives

Explain the three terms of the thesis: codified, evidenced and proportionate.
State the eight cross-cutting conclusions and the chapter each rests on.
Analyse one pair of conclusions that reinforce each other and one pair that conflict, with the recorded resolution.
Draft a first-90-days plan with workstreams, evidence, due days and success measures.

Key concepts

Codified, evidenced, proportionate: Codified: intent, policy, decision rights and boundaries are artefacts a pipeline can check. Evidenced: proof of a control is generated by the systems that operate it. Proportionate: the weight of governance follows usage mode and risk tier.
Eight cross-cutting conclusions: The usage mode sets the governance; classification is triggered by change; decisions are tiered and evidence-driven; sovereignty is a risk-tiered choice; the contract is a deployer's main control; oversight is designed; evidence is a by-product of delivery; containment of agents must not depend on intent.
Conclusions as a chain: Triggered classification determines which obligations apply; evidence produced by delivery lets a forum decide on evidence it did not prepare; designed oversight and containment make autonomy affordable, because the worst case is bounded and those who can stop the system are named.
Containment that does not depend on intent: Instructions lower the rate of unwanted behaviour, but only boundaries cap its consequences: task-scoped credentials, default-deny egress, logs outside the workload's reach, and a stop path outside the system held by named people who may act alone.
First, next, later: Three horizons: in 0 to 6 months know what is in use, classify it and know who decides; in 6 to 18 months make high-risk systems ready for 2 December 2027 and the estate replaceable; in 18 to 36 months make assurance continuous and expand autonomy on evidence.

Teaching plan

10 min	Opening: participants write the thesis of the course in one sentence from memory; the teacher compares the answers with the chapter's wording.
25 min	Eight pairs take one conclusion each and present it in two minutes: the claim, the chapter behind it and what it means for Nordvik Region and for Hansa Mutual.
15 min	Teacher-led analysis of how the conclusions reinforce and conflict, the three tensions revisited, and what the chapter treats as close to certain and what rests on fewer sources.
30 min	Exercise: each participant drafts a first-90-days plan for their own organisation in the form of the chapter's programme plan.
10 min	Closing round: each participant names the first artefact they will create on returning to work and who will approve it.

Discussion

Tiered governance pulls against the speed of a stop, so stop authority is delegated in advance. Which other pair of conclusions conflicts most sharply in your organisation, and how is the conflict resolved today?
The chapter says none of this is novel, and that is the point. If the practices are familiar, why do AI programmes so often fail to apply them?
The two organisations are fictional and illustrate the application of the evidence, not additional evidence. How should a reader use the worked examples when arguing for change in a real organisation?

Exercise · 30 minutes

A first-90-days plan

Write a first-90-days plan for your own organisation in the form of the chapter's programme plan. Name the approving body and, if relevant, the jurisdictions. Define four workstreams, each with an identifier, the usage modes it covers, the outcome, the evidence file or record that proves it, and a due day. Cover at least: an inventory built from deployments and supplier notices with each entry's usage mode; classification with triggers wired to change; a decision-tier file with the owner of every high-risk system and named stop holders for every system that acts; and one workstream specific to your situation, such as supplier evidence gaps or market overlays. Add two success measures expressed as percentages, and one sentence on what the plan deliberately does not try to achieve.

Deliverable: A programme plan with approver, four workstreams with modes, outcome, evidence and due day, two success measures and a stated limit.

Self-test

What does proportionate mean in the book's thesis?
1. The weight of governance follows usage mode and risk tier
2. Governance costs are shared between entities by headcount
3. Controls are applied equally to every system to ensure fairness
4. The number of forums grows with the number of AI systems
How does the chapter resolve the conflict between evidence and data minimisation?
1. By keeping complete records and asking data subjects for consent
2. By logging identifiers and hashes and enforcing retention by configuration
3. By limiting logging to systems that process no personal data
4. By deleting all logs once the conformity assessment is complete
Which actions belong to the first horizon, 0 to 6 months, in the chapter's phased programme?
1. Produce an evidence bundle on every release and re-score maturity
2. Complete the fundamental rights impact assessments and qualify a second source with a drilled switch
3. Renegotiate contracts and expand agent autonomy on evidence
4. Build the inventory with usage modes, classify, write the decision-tier file and name stop holders

Answers to the self-tests

Chapter 1	1B · 2C · 3A (1) The chapter rejects the committee as the whole of governance on grounds of pace: a monthly forum cannot keep up with systems that change weekly. Governance needs the forum, but it is the connection between decisions, controls and evidence. (2) The markets block labels honestly that for the UK and Swiss entities AI Act controls are group policy and not law. Norway is labelled group policy until EEA incorporation. (3) Because the model is a derived artefact that drifts, an approval granted once is not an approval for ever. Change control must cover data as well as code, and decisions must be able to lapse.
Chapter 2	1D · 2A · 3B (1) The practical guide ends its ordered questions with the rule that, when in doubt, the higher mode is chosen, because every step up adds permissions, identities and oversight duties that the controls must cover. (2) The chapter states that the defining property is identity. An agent running as a named employee inherits that person's permissions and leaves an audit trail naming the wrong actor, so each agent needs a dedicated least-privilege workload identity. (3) One brand can cover several modes, and even within a brand the data terms differ by feature. The chapter therefore organises the inventory by use case and mode and writes approvals per service, tier, mode and data class.
Chapter 3	1C · 2B · 3D (1) Regulation (EU) 2026/1744 moved the Annex III high-risk obligations to 2 December 2027 and those for products under Annex I to 2 August 2028. (2) The two obligations pull in opposite directions. The chapter's resolution is architectural: a retention policy that keeps the logs the AI Act requires while minimising the personal data they contain. (3) Governance states the obligation, threshold and acceptable evidence in the obligation mapping; the platform team demonstrates that its mechanism produces that evidence. Left implicit, the interface fails in one of two ways the chapter describes.
Chapter 4	1A · 2C · 3D (1) The scaling block lists P1, P2, P7 and P8 for minimal risk. A minimal-risk system is spared the rebuilds and oversight checks that would add cost without reducing risk. (2) A trace that stores identifiers, versions and content hashes and not the documents themselves satisfies both Principle 3 and Articles 5 and 17 of the GDPR, because the personal data remains in the system of record. (3) The chapter states that an exception without an expiry date becomes the architecture by default. The pipeline therefore treats an expired exception as a failing check, which forces the trade-off to be revisited.
Chapter 5	1C · 2A · 3B (1) If the organisation cannot say which version of a model is approved, who approved it and on what evidence, the platform is not ready, however much compute it has. (2) The minimum to industrialise is 2 and is treated as a gate per dimension. Governance and publicSector both score 1, so they are the blocking dimensions, whatever the other scores are. (3) Citing Forsgren, Humble and Kim, the chapter notes that those engineering capabilities predict delivery performance. They are the floor for AI, which makes practice a more honest indicator than certificates.
Chapter 6	1C · 2A · 3B (1) Step 6 of the guide takes the highest category score as the overall rating, not the average. In GEO-2026-017 the overall rating is 3, the maximum of the category scores. (2) The developer's jurisdiction mattered less than how the model is run. Nothing leaves Hansa's infrastructure, so legal access scores low; a hosted service from the same developer would have scored 4. (3) The reported narrative alignment varied strongly by language, so testing in English alone does not test a deployment in twenty languages. The practical guide requires behaviour prompts in every deployment language.
Chapter 7	1D · 2B · 3A (1) Article 42 of Directive 2014/24/EU requires specifications in performance or functional terms. The authority must specify what the system must do and how well, so the evaluation set carries the requirement a brand name cannot. (2) The relief under Article 53(2) is the provider's. Deploying the model in a high-risk system still makes the organisation a deployer, and modifying and rebranding it may make it a provider under Article 25. (3) The checklist ends with the outcome not ready for signature: 4 MISSING and 8 GAP, with a re-review after draft v4. Examples are the 30-day update notice against a required 90 and the missing training content summary.
Chapter 8	1B · 2D · 3A (1) The derogation never applies where the system profiles natural persons. Q6 is asked separately because this is the answer most often missed when a team describes its system as only prioritising. (2) In an Architecture as Code practice, regular is implemented as triggered. The pipeline downgrades the entry to review required, assigns it to the owner and blocks promotion until the residual rating is reaffirmed or revised. (3) An entry past its review period is stale, and the gate treats stale entries as open risks. This mirrors the drift detection that Architecture as Code applies to infrastructure.
Chapter 9	1C · 2A · 3D (1) The policy requires logging to be enabled with retention of at least 183 days, reflecting the six-month minimum in Articles 19 and 26(6) of the AI Act. (2) Waivers are 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, so the exception path cannot dismantle what the AI Act requires. (3) The organisation is now a deployer under Article 3(4). Tenant settings are compared with a baseline so the feature appears as drift, and the contract owner decides to keep, restrict or disable it. Until the decision is recorded, it is an open risk on the register.
Chapter 10	1B · 2D · 3A (1) The blind sample gives a baseline of the overseer's own judgement. Agreement with the system far above that baseline signals automation bias, which Article 14 asks the design to address. (2) Article 4a of the AI Act permits such processing for bias detection where strictly necessary and under safeguards. The chapter's rule is to join protected attributes only in an isolated evaluation environment, never in the production feature set, and to log the join. (3) The stop function reverts the queue to date order, the safe state the service ran on before the system existed, within 60 seconds, and it is tested quarterly.
Chapter 11	1C · 2B · 3A (1) Artefacts sit in an append-only store with retention locks and each manifest references the previous one. Signing uses an identity bound to the pipeline run, not a key an engineer holds. (2) Step O4 requires the recomputed rate to match the published metric exactly. That tests the metric pipeline together with the control, which is why the chapter says it carries the most value alongside O5. (3) The chapter gives the deadline as immediately after establishing a causal link or its reasonable likelihood and in any case within fifteen days of awareness, with shorter deadlines for the gravest incidents.
Chapter 12	1C · 2A · 3D (1) In the federated model units duplicate gateways and vendor relationships and interpret the AI Act differently, and the organisation cannot produce an inventory. The centralised model fails at the queue. (2) The platform team offers its components as a service and measures itself by adoption. The moment it builds use cases it competes with its customers for its own capacity, recreating the central team's queue. (3) The accountability section leaves approval, registration and oversight staffing with the municipality, which remains the deployer. The service provider is neither provider nor deployer of the customer's use cases.
Chapter 13	1B · 2D · 3A (1) Prohibited practices are not a tier. The routing block rejects them at intake, and no forum, at any level, has a mandate to approve them. (2) The chief risk officer is a consenting member and a required role for quorum: a decision is invalid without that consent. The data protection officer, CISO and internal audit attend in an advisory capacity without a vote. (3) The change advisory board should not re-approve what the pipeline has evaluated. A board that reviews every prompt change will be bypassed within a quarter.
Chapter 14	1A · 2C · 3B (1) The 2024 text required measures to ensure a sufficient level; the amended text asks for measures to support literacy without guaranteeing a specific level. The duty still applies to every AI system and no certificate is required. (2) The chapter grounds the split in separation of duties, a regulatory expectation in financial services and sound practice everywhere. The evaluation engineer reports to model risk or the platform team. (3) Existing staff know the domain, the data and the politics, most roles are existing roles with an AI syllabus added, and the enabling team is itself an upskilling engine. Hiring is for specialisms upskilling cannot supply fast enough.
Chapter 15	1D · 2B · 3C (1) Crossing requires that the system change, not merely the message. The early majority must receive a more reliable product than the innovators played with, so the crossing has an engineering budget and a governance decision attached. (2) Who consults whom follows the employment relationship, not the platform. A commitment made in Germany about logging does not automatically protect claims handlers employed in Poland. (3) A demonstration on curated examples is not a win. The win is defined before the pilot starts, recorded as acceptance criteria in the use-case register, and measured on live cases against the baseline.
Chapter 16	1C · 2A · 3D (1) The on_expiry field is set to revert the state unless closed. A lapsed exception reverts the use case and does not silently become permanent, which keeps management discretion without losing accountability. (2) Surveys overstate the time assistants save, so the chapter prefers measured to self-reported benefit. The survey figure is kept but not used in the benefit figure, the distinction a public auditor will ask about. (3) Evaluation and assurance are paid by the platform so that nobody saves money by testing less, while exit is paid by the use case through a provision set at intake.
Chapter 16A	1B · 2D · 3A (1) The envelope is what the organisation has decided to spend in the period, distinct from the forecast of what it will spend. The envelope is a decision; the forecast is an estimate with assumptions and a recorded error. (2) Step 6 of the renewal guide applies the decision table and records missing evidence, which yields approve with conditions, with an owner and a date, and never a plain approval. (3) The envelope guide pairs a unit-cost ceiling with a quality floor. A system that is cheaper per letter but needs more corrections has moved cost, not removed it.
Chapter 17	1A · 2C · 3B (1) The reasons log records inputs, model version, output, applied rule and the human action that followed in the language of the case, and it serves the decision letter and the appeal body. Article 12 logging remains a separate, technical record. (2) The transparency record states that appeals are handled by a separate unit without access to the triage score, so that an appeal is decided by a person who did not rely on the model's estimate. (3) For authorities, the relevant exception in Article 22 of the GDPR is authorisation by law with suitable safeguards. Where such a rule exists its safeguards become architectural requirements; where it does not, the system can only recommend.
Chapter 18	1B · 2D · 3A (1) Allocating work to named technicians could fall within the high-risk employment categories and was subject to co-determination. The manifest forbids an assignee and disallows scheduling a technician, and the works council's agreement is recorded in the AI Decision Record. (2) Improving the CE-marked tool with local data would make the hospital a provider and bring the work under secondary use. The group has so far declined to cross that line, which the case records as an outcome. (3) The city's version-controlled scope excludes eligibility assessments. The golden set runs on every content update and vendor model change, and it caught two model updates that would have brought eligibility answers back.
Chapter 19	1C · 2A · 3D (1) The stop policy lists four signals: unauthorised coordination between agents, an agent reaching host or hypervisor root, egress to an unapproved destination, and an agent tampering with logs or guardrails. (2) The operator stresses that the models ran without deployed safeguards in an outlier scenario. The chapter therefore grounds its lessons in the architecture: a shared credential, a mirror that was also an exit, correlated controls and an unowned stop decision. (3) A decision to continue after a stop signal is the exception that the waiver discipline of Chapter 9 turns into a dated, owned record. The policy sets requires_waiver to true with the accountable executive as approver.
Chapter 20	1D · 2B · 3C (1) The prototype ran with a shared service account and every tool the finance API exposes; its only boundary was a sentence in the instructions, which a retrieved document can contradict. The production manifest removes the credit-note tool altogether. (2) Shadow AI arises where unsanctioned use was forbidden without a faster alternative. The remedy is an AI gateway with approved models and logging, the inventory, and telemetry that finds unregistered use. Shadow AI is a demand signal to be read. (3) The remedy is an evaluation pyramid with acceptance criteria as code and gates in the promotion pipeline. The governance point is who sets the bar: model risk or the system owner, approved at the tier Chapter 13 assigns.
Chapter 21	1A · 2C · 3B (1) Switching off the model stops traffic only. The decommissioning record the Region now requires also covers the identities and grants that outlive the model, the archive, the retained decision logs and the register update. (2) Sovereignty is a set of options kept open, not a refusal to use what is available: per workload, where data may reside, which jurisdictions may reach it, whether weights must be inspectable and what the exit path is. (3) Lesson 2 is to fund the platform before the fifth pilot. The other options invert lessons 1, 8 and 7: architect the system and not the model, generate evidence and do not collect it, and bound autonomy in code and expand it with evidence.
Chapter 22	1D · 2A · 3C (1) 2 August 2027 for legacy general-purpose AI models and national sandboxes, 2 December 2027 for Annex III high-risk systems, and 2 August 2028 for high-risk systems embedded in regulated products. The chapter advises verifying the timeline before committing a plan. (2) Observably, the AI Act was still under scrutiny for incorporation at the time of writing. The chapter expects incorporation within five years, probably with adaptations, so groups keep one baseline with national overlays. (3) The entry is marked speculative with high reversibility, and the decision is to design the evidence store as if an authority may query it, a step that costs little and can be undone if the trend does not materialise.
Chapter 23	1B · 2C · 3A (1) A cautious authority discovered that it was already using more AI than it governed, and that most of it had arrived through suppliers: eleven services, three without review. (2) The group policy expresses what holds everywhere and each overlay adds what differs. An overlay may add a control but never remove a group one, and controls applied where an instrument is not law are labelled as group policy. (3) Hansa's drilled exit plans, and its exceptions with expiry and automatic reversion, would serve the Region. In the other direction, the Region's practice of generating public transparency from the same descriptors as its deployed systems would serve Hansa.
Chapter 24	1C · 2D · 3B (1) A weekly board cannot be in the path if the first clock is measured in hours. The decision to patch on release, behind canary rings and automatic rollback, is delegated in advance through the decision tiers, and the assumption is recorded for review. (2) The author's observation from practice is that Mode 1 is governed through an acceptable-use policy and Mode 4 through project processes, while Modes 2 and 3 grow fastest with the least oversight, since neither passes through intake. (3) The chapter states that everything before it supports each claim with a source, while what follows are the author's own views, with room to disagree, to doubt and to guess. The concluding chapter sets these judgements aside.
Chapter 25	1A · 2B · 3D (1) The thesis is that AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk. Proportionate means that the weight of governance follows usage mode and risk tier. (2) Article 12 of the AI Act requires lifetime logging for high-risk systems while the GDPR requires that personal data be kept no longer than necessary. Chapter 11's design logs identifiers and hashes and enforces retention by configuration. (3) First: know what is in use, classify it and know who decides, including named stop holders and the containment baseline for agents. Contracts, impact assessments and a second source come next; continuous assurance and expanded autonomy come later.

Final assignment

A governance repository for one AI system and its organisation. Choose one AI system that affects people or business decisions in your own organisation; if that is not possible, take Nordvik Region's benefits-triage system or Hansa Mutual's claims-triage agent. Build the governance repository for it from the artefacts the course has taught, so that a reviewer can follow the path from declared intent to evidence without asking you a question. The repository must place the system in a usage mode, state your role under the AI Act and the risk tier with its basis, record the sourcing and exit position, show who decides and who can stop the system, describe how oversight works in practice, and say what evidence proves each control operated. Mark honestly every artefact that does not yet exist and every question that remains open. Present the repository in ten minutes as if to your AI governance board, and ask for one decision.

Assessment criteria

Fidelity to the method: the usage mode, AI Act role and risk tier are stated with their basis, and the book's terms and artefact types are used exactly
Traceability: a reviewer can walk from intent to classification, control, decision and evidence through identifiers, without relying on explanation
Enforceability: every rule, clause and commitment is paired with the control that enforces it and the test or evidence that proves it
Accountability: named roles hold the go-live decision, the oversight and the stop authority, and nothing consequential is left to a supplier or to a system
Honesty: missing artefacts, untested controls and open questions are recorded as such, with owners and dates