AI Governance: workbook

How to use this workbook

The workbook follows the course on AI Governance lesson by lesson. Read the chapter (or its whitepaper) before each lesson, bring the workbook to the session and keep what you produce in the exercises: they add up to the final assignment.

After the course you can

Classify every use of AI in an organisation by usage mode, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, and assign its minimum control baseline
Determine the organisation's role under the AI Act for a system, its risk tier and the events that reopen the classification
Assess a model's origin across five risk categories and review a supplier contract clause by clause against enforcing controls
Express risk classification, risk appetite, approval policies, waivers and the AI inventory as version-controlled artefacts evaluated at pipeline gates
Design human oversight, fairness evaluation and transparency as mechanisms with thresholds, and assemble the evidence they produce into a chain an auditor can follow
Design the operating model, decision tiers, stop authority and roles that hold accountability for AI, including consultation with employee representatives
Manage an AI portfolio with falsifiable value hypotheses, cost envelopes and a decision table, and report to a management body from generated evidence
Draft a governance roadmap and a first-90-days plan that separate what is observable, expected and speculation

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.

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.

Interactive exercises

Match: Five changes and what each demands of governance
Scenario: AI reaches staff before it reaches the board

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: The classification questions in order
Sort: Which usage mode is it?

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: From requirement to architectural component
Scenario: A fine-tuned model and a role that moves

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: Eight principles in four groups
Put in order: The order for resolving conflicts between principles

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Scenario: A green pilot and a blocking dimension
Match: Typical blocking gap per usage mode

Done on the lesson page, with feedback at once.

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.

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.

Interactive exercises

Sort: How the deployment option moves the risk
Scenario: A route the origin policy does not permit

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: Each clause and the control that enforces it
Sort: Buy, adapt or build

Done on the lesson page, with feedback at once.

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.

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.

Interactive exercises

Put in order: The classification decision tree
Sort: Which tier does the policy return?

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: Gates and their triggers
Scenario: A blocked release and a request for a waiver

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: Three patterns of human oversight
Match: A mechanism for each requirement

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: The five stages of the evidence chain
Scenario: An incident that is probably not serious

Done on the lesson page, with feedback at once.

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.

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.

Interactive exercises

Sort: Three operating models
Scenario: The enabling team is asked to stay

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: Route each decision to its tier
Match: The forums and what each decides

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: Roles around the AI architect
Scenario: A major provider update and a competence record

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: Adopter segments along the curve
Scenario: A manager asks who is not using the assistant

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: Lifecycle states of a use case
Match: What is reported for each usage mode

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: The forum's decision table
Scenario: What to tell the elected committee

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: Public-sector constraints and architectural responses
Scenario: A new use for the triage score

Done on the lesson page, with feedback at once.

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.

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.

Interactive exercises

Match: The control that mattered most in each case
Scenario: Planning a pilot after the UK evaluations

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: The timeline as the chapter reconstructs it
Sort: The self-assessment checklist

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: Three clusters of anti-patterns
Match: Anti-pattern and remedy

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Put in order: Six lifecycle stages
Scenario: A request for something like a chatbot

Done on the lesson page, with feedback at once.

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.

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.

Interactive exercises

Sort: Observable, expected or speculation
Put in order: Monitoring the signals

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Sort: Nordvik Region or Hansa Mutual?
Scenario: A proposal for the Region's first autonomous agent

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: The comfortable act and what it replaces
Sort: Cited observation or the author's projection

Done on the lesson page, with feedback at once.

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.

Interactive exercises

Match: Each conclusion in the two organisations
Scenario: An overreach signal and a proposed instruction

Done on the lesson page, with feedback at once.

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