Cover of AI Platform and Security

Book 3 · Workbook

AI Platform and Security

Objectives, key concepts, discussion questions, exercises and self-tests for every lesson, on one page to print.

6 modules25 lessons

The course

All courses / AI Platform and Security / Workbook

How to use this workbook

The workbook follows the course on AI Platform and Security 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

Module 1 · Part I · Foundations

Part I lays the ground for everything the course builds later. It shows why an AI platform is an architectural and security problem, sorts the work by the six usage modes, turns European law into platform requirements with evidence, presents the layered reference architecture and its four patterns, and introduces the AI Decision Record. Participants leave able to place any AI use at its control point, derive its requirements and record the decision in a repository a pipeline can check.

Chapter 1 · 60 minutes

Introduction to AI Platform and Security

The lesson establishes why an AI platform is an architectural and security problem rather than a model-selection question. Participants work through the four properties of AI systems that classical practice does not address, the book's definitions of AI Architecture and the AI platform, the table where governance requirements become platform capabilities, and the two fictional organisations. They finish by drafting a platform onboarding declaration of the kind Nordvik Region keeps for its staff assistant.

Learning objectives

  • Explain why the platform around a model matters more for incidents and audit findings than the choice of model.
  • Describe the four properties of AI systems that break classical assumptions and the platform response to each.
  • Compare Nordvik Region and Hansa Mutual on the axes that shape a platform.
  • Draft a platform onboarding declaration with purpose, prohibited uses, data boundary and evidence.

Key concepts

AI Architecture
The practice of designing, governing and operating AI systems, meaning their data, models, prompts, orchestration and surrounding controls, as codified, version-controlled, evidence-producing architecture, so that behaviour, risk, cost and legal position stay under the organisation's control throughout the lifecycle.
The AI platform
The shared, centrally operated set of capabilities on which an organisation's AI systems are built, run and observed, together with the controls that constrain them. It is a product with an owner, and its purpose is to make the safe path the easy one.
Controls outside the model
Because a large language model receives instructions and data through the same channel, any text it reads can act as a command. The platform therefore controls what retrieval may return, which tools may be called under whose authority, and what checks an output must clear.
Platform onboarding declaration
A file in the repository stating a system's purpose, legal position, components, data boundary and evidence. The onboarding pipeline provisions no gateway route until the declaration is complete.
Three tensions
Speed against control, autonomy against accountability and innovation against sovereignty, named in AI Governance, Chapter 1. This book meets each as a platform question: pipeline gates, identities with stop paths and logs, and routing, hosting and exit decisions per workload.

Interactive exercises

  • Match: Four properties and a fifth pressure
  • Scenario: A wider purpose for the staff assistant

Done on the lesson page, with feedback at once.

Discussion

  1. Which of the four properties causes most difficulty in your organisation today, and which platform capability is missing for it?
  2. The book says the platform should make the approved route faster than the unofficial one. Where is the unofficial route faster in your organisation, and why?
  3. Nordvik Region steers its AI through contracts and Hansa Mutual through its own platform. Which situation is closer to yours, and what leverage does that give you?

Exercise · 20 minutes

Draft a platform onboarding declaration

Choose a lower-risk AI system in your own organisation, or use Nordvik Region's staff assistant as the model. Write its onboarding declaration with the fields the chapter's example uses: intended purpose, prohibited uses, usage mode, AI Act role for the compound system and for the general-purpose AI model, risk classification with a review trigger, components, data boundary with residency and key custody, security settings for egress and agent tools, and evidence with retention. Then name the two fields that would force a review if someone later widened what the system does.

Deliverable: A one-page onboarding declaration in structured form, with the two fields that guard against silent extension marked and explained.

Self-test

  1. Why does the chapter say the platform must place its controls outside the model rather than rely on a filter?

    1. Because filters add latency that makes conversational assistants unusable for staff
    2. Because instructions and data share one channel, and no filter can list every wording that might steer the model
    3. Because the AI Act forbids providers from filtering the inputs of a high-risk AI system
    4. Because foundation model vendors do not allow licensees to add filters of their own
  2. According to the chapter, where do AI Governance and AI Platform and Security meet?

    1. At the model, which both books select
    2. At the budget, which both books approve
    3. At the supplier contract, which both books draft
    4. At the evidence the platform produces
  3. In the onboarding declaration of Nordvik Region's staff assistant, what does the setting that allows no agent tools achieve?

    1. A proposal to let the assistant file letters becomes a reviewed change to the declaration
    2. The assistant is reclassified as a high-risk AI system under Annex III point 5, with the duties of Article 26
    3. The assistant may be used only by the small platform team that also runs the Region's coding agent
    4. The gateway logs of the assistant no longer need to be retained for the 120 months the file declares

Chapter 2 · 75 minutes

Usage Modes and the Platform: What Each Mode Demands

The lesson teaches participants to sort every use of a large language model into one of six usage modes and to read off what each demands of five platform capabilities: gateway and routing, identity and delegated authority, isolation and containment, logging and evidence, and data boundaries. It covers the minimum platform baseline per mode, the drift paths between modes and the practical guide for mapping each use case to its control point.

Learning objectives

  • Classify a use of a large language model into one of the six usage modes by integration depth and autonomy.
  • Identify the platform control point for each mode.
  • Explain why a change of mode is a platform event that provisioning must detect.
  • Assess a use case against the minimum platform baseline and rank the gaps by exposure.

Key concepts

Usage mode
One of six architectural patterns of use, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, ordered by how deeply the model is integrated into the organisation's data and systems and how much autonomy its output is given.
Platform control point
The place where the organisation can enforce anything in a given mode: inventory and supplier change control, identity provider and egress proxy, tenant configuration, managed policy and sandbox, the AI gateway and reference architecture, or the agent manifest, identity and stop path.
Minimum platform baseline
The floor of gateway and identity, containment, logging and evidence, and data boundary controls per mode in Table 2.2. It is a floor, not a target: the system's risk class adds controls.
Mode drift
The movement of a use case from one mode to another, for example when a prompt becomes a shared skill or an approval step is removed. Each step relocates the control point although the code gives no sign of it.
Tier
The decisive variable in Mode 1 Conversational assistants: one brand is sold both on consumer terms and on commercial terms backed by a data processing agreement, and the platform leaves only the commercial tier reachable.

Interactive exercises

  • Sort: Where is the control point?
  • Put in order: Mapping use cases to control points

Done on the lesson page, with feedback at once.

Discussion

  1. Which use in your organisation has already drifted to a higher mode than the one it was approved in, and what was the trigger?
  2. The organisation can prove only what crosses infrastructure it runs. What can you prove today about Modes 1 and 2, and what can you not?
  3. Nordvik Region permits no Mode 5 and restricts Mode 3 to its platform team. What does an organisation gain and give up by deferring the hardest containment problems in this way?

Exercise · 30 minutes

Map use cases to their platform control point

List five uses of large language models in your own organisation, at least one in Mode 3 or higher. For each, record the usage mode, the control point from Table 2.1 and the identity it acts with. Then mark each cell of the mode's row in Table 2.2 as met, partly met or missing, and say what evidence would show it. Order the gaps by exposure as the practical guide does: Mode 5 agents without a dedicated identity or tested stop path first, then Mode 3 tools without a fail-closed sandbox, Mode 4 calls that bypass the gateway, and consumer-tier Mode 1 use with personal data.

Deliverable: A usage-mode register of five entries with control point, baseline status per cell and a ranked list of gaps with a named owner for each.

Self-test

  1. What is the platform control point for Mode 2 Embedded workplace assistants?

    1. The AI gateway and the whole reference architecture, with service and end-user identity on every call
    2. A managed permission policy and a fail-closed sandbox with an egress allow-list and catalogue-only skills
    3. The tenant configuration: permissions, sensitivity labels, grounding scopes and audit settings
    4. The agent manifest, a dedicated agent identity and a tested stop path
  2. On what does it depend whether a system is a high-risk AI system, according to the chapter?

    1. On its use under Article 6 and Annex III of the AI Act, never on its usage mode
    2. On its usage mode, with Modes 4 and 5 always counted as high-risk
    3. On whether the runtime is operated by the vendor or by the organisation
    4. On whether the model is reached through the consumer tier or the commercial tier
  3. When Hansa Mutual's claims-triage entry UC-2026-014 moved from Mode 4 to Mode 5, what did provisioning do?

    1. It issued the new route at once and opened a review to be completed within a quarter
    2. It moved the agent to the self-hosted models in the Frankfurt data centre
    3. It reclassified the agent as a high-risk AI system and notified the supervisor
    4. It withheld the gateway route until the agent had its own identity, manifest, stop-path test and market-bound token

Chapter 3 · 90 minutes

Regulatory Requirements as Engineering Constraints

The lesson shows how to read European regulation as an engineer. Each obligation is followed from its instrument and article to the shared platform capability that satisfies it, the codified artefact that configures it and the evidence it produces. Participants apply the three keys that decide which requirements apply, work with the requirements-to-capability matrix and the platform requirements catalogue, and run two systems of the fictional organisations through it. All content is architectural implication, not legal advice.

Learning objectives

  • Write a regulatory obligation as a chain of legal source, platform capability, codified artefact and evidence produced.
  • Apply the three keys of risk tier, role and general-purpose AI model use to decide which requirements apply to a system.
  • Explain why log retention under the deployer's control is an architectural and contractual matter.
  • Derive the platform requirements and evidence for a new AI system before design starts.

Key concepts

The four-link chain
Every requirement is written as legal source, platform capability, codified artefact and evidence produced. A requirement that cannot be written as all four links is not ready to be built; the missing link is usually the evidence.
Three keys
The result of risk classification reaches the platform as data in three keys: the risk tier, the role under Article 3 of the AI Act, and whether the system integrates a general-purpose AI model.
Article 25 trigger
The clause the chapter says platform teams most often miss: a deployer that makes a significant change to a high-risk AI system, or repurposes a system into a high-risk use, inherits the provider's obligations.
Platform requirements catalogue
One artefact the pipeline reads: each entry names an article, its control, the condition under which it applies and the gate that blocks a release when the evidence is missing. A full catalogue runs to some sixty entries.
Incident pipeline
The capability for Article 73 of the AI Act: it classifies each AI-related incident against every regime that may apply at once, starts the right clocks and assembles the report from logs and the evidence store.

Interactive exercises

  • Match: From article to platform capability
  • Scenario: Logs in the supplier's environment

Done on the lesson page, with feedback at once.

Discussion

  1. Which obligation in your organisation is met today by a project-built substitute instead of a shared platform capability, and what does that cost?
  2. Hansa Mutual applied the Article 12 logging profile and the Article 14 oversight binding to an agent that its classification record places outside the high-risk tier. When should policy go beyond what the law requires?
  3. For which of your requirements is the evidence link the one that is missing, and who would have to produce that evidence by hand today?

Exercise · 30 minutes

Derive the platform requirements for a new system

Take Nordvik Region's benefits-triage system, or a planned system of your own. Follow the practical guide: write the intended purpose in two or three sentences, record the risk tier and the AI Act role and test the Article 25 triggers, then set the flags for general-purpose model use, personal data, decisions about individuals, sector and markets. Write five catalogue entries, each with source, the condition under which it applies, the control, the evidence and the gate. For every entry say whether the capability exists on your platform or is a gap, and set the retention period with the reasoning the guide gives.

Deliverable: A requirements profile with five catalogue entries written as four-link chains, plus a gap list with an owner and a date for each gap.

Self-test

  1. When a requirement cannot be written as all four links of the chain, which link does the chapter say is usually missing?

    1. The legal source
    2. The platform capability
    3. The evidence produced
    4. The codified artefact
  2. Article 26 of the AI Act requires deployers of high-risk AI systems to keep the logs under their control. What architectural consequence does the chapter draw?

    1. The deployer must retrain the procured model on its own premises every quarter, so that the training logs count as its own records
    2. The contract should require the logs to land on the deployer's platform, since logs kept only by the supplier cannot be retained
    3. The deployer must build its own gateway before it may procure any high-risk AI system
    4. The provider must hand over the model weights so that the deployer can regenerate the logs whenever an authority asks
  3. Why did Hansa Mutual add the Article 12 logging profile and the Article 14 oversight binding to its claims-triage agent?

    1. As group policy: an agent with write access to production needs action-level logs and a stop control whatever its legal tier
    2. Because its classification record places the agent in the high-risk tier under Annex III point 5(c), like the underwriting-support model
    3. Because DORA Article 28 requires both controls for every ICT third-party service provider in the register of information
    4. Because the Swiss and UK supervisors demand AI Act controls for agents in their markets

Chapter 4 · 90 minutes

A Reference Architecture for AI in Large Organisations

The lesson presents the layered reference architecture for AI in large organisations: five functional layers from the data foundation to application and channel, surrounded by a control plane. Participants study the four patterns that carry it, the mapping of layers to the provider and deployer roles of the AI Act, the four deployment variants and the way adaptations are written as overlays, including a market overlay for a non-EU entity and a reduced variant for an authority that mostly procures.

Learning objectives

  • Describe the five functional layers and the cross-cutting control plane of the reference architecture.
  • Explain the role of the AI gateway, the model registry, the evaluation service and the prompt and policy repositories.
  • Compare the cloud, on-premises, hybrid and sovereign deployment variants layer by layer.
  • Derive a checkable variant of the reference architecture as an overlay on a pinned reference model.

Key concepts

Control plane
The cross-cutting part of the architecture for identity, policy, observability and evidence. It is the architectural expression of policy as code and evidence as code, and it remains the organisation's own in every deployment variant.
AI gateway
A single, mandatory entry point for model calls. It authenticates the calling workload and the human behind it, consults the policy decision point, resolves approved model and prompt versions, applies guardrails, routes the request, enforces budgets and emits a trace.
Model registry
The authoritative list of models the organisation may use, including external foundation models. Entries move through stages such as candidate, evaluated, approved and retired, and pipelines perform every promotion, never a person by hand.
Market overlay
A file per market on top of the shared reference model and the group baseline, recording regime, placement and timing. An overlay may add or tighten controls but never relax the group baseline, and a pipeline check fails any overlay that tries.
Reduced variant
The architecture for an authority that mostly procures. It keeps the gateway, the registry, evaluation as acceptance suites and the control plane, and leaves experiment tracking, training pipelines and feature stores to the provider, with the contract carrying what they would have produced.

Interactive exercises

  • Sort: What a procuring authority keeps
  • Scenario: An overlay that wants less

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says that moving the evidence store or the policy repository into a provider's console moves accountability with it. Where do yours sit today?
  2. Applications never call models directly in the reference architecture. Which applications in your estate do, and what would it take to route them through a gateway?
  3. Why may an overlay tighten but never relax the group baseline, and what would go wrong in a multi-jurisdiction group if it could?

Exercise · 30 minutes

Derive your own variant as an overlay

Follow the chapter's practical guide for your own organisation. List up to six AI systems with their usage mode and whether you build or procure them. For each of the five layers and the control plane, mark whether you operate it, buy it as a service or rely on a supplier's product, using the deployment variants of Table 4.1. Keep the gateway, the registry, evaluation and the control plane; for every other component, say which obligation depends on it or drop it. Write the result as an overlay outline on the pinned reference model with placement, added components, control-plane overrides and approvals, as Nordvik Region does.

Deliverable: An overlay outline for the organisation with a per-layer ownership table and one sentence of reasoning for each dropped or bought component.

Self-test

  1. Which structural decision does the chapter call the single most important one in the reference architecture?

    1. Placing the feature store inside the data foundation instead of the model and feature layer
    2. Running one control plane per legal entity in a group
    3. Keeping the prompt repository apart from the policy repository
    4. Separating the serving and inference layer from the orchestration layer above it
  2. What rule keeps the structure of shared reference model, group baseline and market overlays sound?

    1. Each market keeps a full copy of the platform manifest that it may edit freely
    2. An overlay may add or tighten controls but never relax the group baseline
    3. An overlay may remove the evaluation service where no local law requires it
    4. The group baseline is rewritten whenever a market overlay conflicts with it
  3. In the reduced variant for an authority that mostly procures, what happens to experiment tracking, training pipelines and feature stores?

    1. The authority builds them first, because the gateway depends on them
    2. They are replaced by the public algorithm register of the authority
    3. They belong to the provider, and the contract carries what they would have produced
    4. They are moved into the control plane together with the archive

Chapter 5 · 90 minutes

AI Decision Records, Model Cards and the Architecture Repository

The lesson extends the Architecture Decision Record to AI systems. Participants learn the fields the AI Decision Record adds, follow four worked records of Nordvik Region and Hansa Mutual from proposal to supersession, and see how model cards, datasheets and the system card accompany the record in an architecture repository from which the technical documentation of Article 11 and Annex IV of the AI Act is generated instead of written by hand.

Learning objectives

  • Explain why the Architecture Decision Record is not sufficient for AI systems and which fields the AI Decision Record adds.
  • Draft an AI Decision Record with options considered, evaluation criteria, human oversight and retirement criteria.
  • Distinguish the model card, the datasheet and the system card and say what each documents.
  • Map the paths of an architecture repository to the points of Annex IV.

Key concepts

AI Decision Record (AIDR)
A record that keeps the short, numbered, immutable structure of the Architecture Decision Record and adds intended purpose, prohibited uses, risk classification, role, data sources, evaluation criteria, human oversight, logging and retention, and retirement criteria.
Retirement criteria
The conditions under which the system is withdrawn or the model retrained. They are the contract that lets evidence re-open a record: when a monitored threshold is breached, the pipeline creates a review task against it.
Model card and datasheet
Version-controlled companions of the record. The card reports a model's intended use, evaluation and limitations; the datasheet documents a dataset. The pipeline fails if the card's reported metrics do not match those the evaluation stage produced.
System card
The description of a compound system as a whole: every component and version, the data flow, system-level evaluation results and the controls. It records that the organisation deploys the general-purpose AI model but provides the compound system it has assembled.
Architecture repository
The single source of truth in which each Annex IV heading has one place where its evidence lives, so that the technical documentation is generated, versioned and signed on every model promotion and every merge to the decision log.

Interactive exercises

  • Put in order: The life of AIDR-0007
  • Match: Companions in the architecture repository

Done on the lesson page, with feedback at once.

Discussion

  1. The retirement criteria of AIDR-0027 are deliberately asymmetric. What does that asymmetry say about the difference between a control that has failed and a system that performs poorly?
  2. Nordvik Region shows caseworkers a priority band with reasons instead of a numeric score, and queues a random sample without a band. How would you show that human oversight in one of your systems is effective and not nominal?
  3. Which facts about your AI systems are written by hand in more than one document today, and which of those documents would contradict each other first?

Exercise · 30 minutes

Write an AI Decision Record for a real choice

Pick a decision about an AI system that your organisation has taken or is about to take, for example retrieval against fine-tuning, or advisory use against write access. Write the record in the form of the chapter's template: context with measured figures you can defend, intended purpose, prohibited uses, risk classification and role, data sources with lawful basis, at least two options considered with the reason each lost or won, evaluation criteria as metrics with thresholds, the human oversight path, and retirement criteria. Mark any field that does not apply as not applicable with a reason. State which reviewers the front matter would add to the pull request.

Deliverable: A complete AI Decision Record of one to two pages, with testable evaluation and retirement criteria and a list of required reviewers.

Self-test

  1. In AIDR-0011, why did Nordvik Region reject showing caseworkers a numeric score for each claim?

    1. Because a numeric score invites over-reliance
    2. Because the provider's model cannot output a score
    3. Because scores are special-category data under the GDPR
    4. Because a score would make the system fall outside Annex III
  2. How is an accepted AI Decision Record changed when the decision no longer holds?

    1. Its body is edited in place and the date of the edit is added to the front matter
    2. It is deleted from the repository once the retired model has left serving
    3. It is rewritten by the generator that produces the decision log index
    4. Only its status fields change, in the pull request that accepts a successor stating why it was retired
  3. What role analysis does the chapter say is recorded in the system card of a compound system built on a third-party language model?

    1. The organisation is the provider of both the model and the compound system, because it wrote the prompts and the retrieval configuration
    2. The model vendor is the provider of the compound system and the organisation its distributor
    3. The organisation deploys the general-purpose AI model but is the provider of the compound system it has assembled
    4. The organisation is a deployer of both, since it did not train the model

Module 2 · Part II · Data, Models and DevSecMLOps

Part II builds the core of the platform from the bottom up: data products with contracts and lineage, the model lifecycle as a pipeline with gates, the DevSecMLOps loop with revision management as its backbone, the risks at every stage of that loop, foundation models with retrieval and grounding, agents with bounded autonomy, and the integration seam to systems of record. Participants leave with a set of codified artefacts, from a data contract and a release manifest to a permission manifest and a gateway route, that a pipeline can check.

Chapter 6 · 75 minutes

Data Architecture for AI

The lesson starts at the lowest layer of the reference architecture, the data foundation. Participants learn why a trained model is derived data, how data products, descriptors, datasheets and data contracts make ownership testable, how platform-captured lineage carries retention and erasure into every derived store, where feature stores and vector stores differ, why synthetic data has limits, and how the GDPR, EDPB Opinion 28/2024, the Data Act and the Data Governance Act shape the design.

Learning objectives

  • Explain why the quality, legality and reproducibility of a model are bounded by its data.
  • Draft a data contract with the two kinds of field that AI consumers add: distributions and permitted purposes.
  • Distinguish a feature store from a vector store by content, consumer and typical failure.
  • Compare the lawful basis for model training available to a private organisation and to a public authority.

Key concepts

Data product descriptor
A file the platform can read that names the product's owner, outputs, classification, lawful basis, retention, datasheet and lineage. Its lawful basis block separates operational use from model training because the GDPR does.
Data contract
A statement of what the consumer may rely on, in a form a test can check. The platform verifies it on every publication, so that when the contract breaks the producer's pipeline fails, not the consumer's model.
Lineage and provenance
Lineage answers where a value came from; provenance answers how an artefact came to exist. The platform captures lineage instead of teams declaring it, so that it can say which models consumed a dataset version.
Point-in-time join
The defining capability of a feature store, which keeps future information out of a training set. A vector store's problem is different: access control, since a chunk is still its source document.
Model collapse
The predictable degradation of models trained recursively on data generated by earlier models: first the tails of the distribution disappear, later the output converges on a few high-probability patterns. Synthetic data is therefore labelled in lineage.

Interactive exercises

  • Sort: Feature store or vector store?
  • Scenario: An erasure request reaches the claims data

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says purpose limitation is the GDPR principle AI programmes break most often. Which dataset in your organisation was collected to run a service and is now a candidate for training?
  2. RET-04 does not promise to delete a person from a trained model at once. How would you explain that position to a data subject and to an auditor?
  3. The known gaps section of a datasheet is said to be the one that changes model design. What would an honest known gaps section say about a dataset you rely on?

Exercise · 25 minutes

A data contract and an erasure path

Choose a dataset that feeds or grounds an AI system in your organisation, or use Hansa Mutual's policy-wordings corpus. Write its data contract: schema constraints, a distribution range for one numeric column or the metadata every document section must carry, permitted purposes, prohibited purposes, a change policy and at least two tests. Then list every derived store the data reaches, such as training releases, feature store rows, vector index chunks, logs and caches, and state for each the retention period and the action on an erasure request, following the pattern of RET-04. Say how the rule would be exercised to prove it works.

Deliverable: A data contract of about fifteen lines and a table of derived stores with retention, erasure action and the test that exercises the rule.

Self-test

  1. Which two kinds of field does a data contract add for AI consumers, according to the chapter?

    1. The name of the model team and the size of the training cluster
    2. The distribution of numeric columns and the permitted purposes
    3. The price per row and the licence of the pipeline framework
    4. The embedding model version and the chunking strategy
  2. Why can a public authority not rely on legitimate interest for training a model in the performance of its tasks?

    1. Because the Data Governance Act reserves legitimate interest for data intermediation services under its Chapter III
    2. Because EDPB Opinion 28/2024 rejects legitimate interest as a lawful basis for developing or deploying any model
    3. Because Article 9 of the GDPR prohibits public bodies from processing personal data
    4. Because the final sentence of Article 6(1) of the GDPR excludes it, leaving public task under Article 6(1)(e)
  3. How does the vector store handle access control in the chapter's design?

    1. The index carries its sources' access attributes, and the retriever filters on entitlements before similarity search
    2. The generator is instructed in the system prompt not to quote passages the caller may not read, and a canary string detects leaks
    3. Restricted documents are embedded with a separate model that only administrators may call
    4. The grounding check removes restricted passages after the answer has been generated

Chapter 7 · 75 minutes

Model Lifecycle Management: MLOps and LLMOps as Code

The lesson describes the model lifecycle as a pipeline with gates instead of a sequence of projects. Participants work with experiment tracking, the registry entry, the six promotion gates, three deployment strategies, rollback and retirement, the training manifest and the ML Test Score. They see what changes when the managed artefact is a prompt or an adapter, and how separation of duties and the predetermined change envelope are enforced inside the pipeline.

Learning objectives

  • List the six promotion gates and say what each checks.
  • Compare shadow, canary and champion-challenger deployment by what each measures.
  • Explain how LLMOps changes the versioned artefact, the evaluation set, the metric and the promotion unit.
  • Draft a predetermined change envelope that separates planned retraining from changes needing a new assessment.

Key concepts

Promotion gate
A set of automated checks a model version must pass to move between stages. The book insists on six: data, reproducibility, evaluation, comparison, readiness and approval. Thresholds are read from the decision record so that record and gate cannot disagree.
Training manifest
The file stored with the model that pins code by commit, data by immutable version, environment by image digest, configuration including seeds, and hardware class, with a declared reproducibility tolerance.
ML Test Score
A rubric of twenty-eight tests in four areas. A test scores half a point when manual and documented and a full point when automated, and the overall score is the minimum across the areas.
LLMOps
The lifecycle practice for a general-purpose AI model obtained from a third party: it versions prompt templates, retrieval and guardrail configuration and adapters, and promotes the compound system of model plus prompt plus configuration.
Predetermined change envelope
The retraining procedure, thresholds and acceptable ranges of change declared up front under Article 43(4) of the AI Act, so that each retraining within it is a planned change through the gates, with a list of what falls outside.

Interactive exercises

  • Put in order: From tracked run to retirement
  • Match: Strategies and operations of deployment

Done on the lesson page, with feedback at once.

Discussion

  1. Only the approval gate involves a person. Which of the other five gates is still performed by hand in your organisation, and what would automating it require?
  2. The release note for claims-ranker 4.0.0 reports a small fall in precision alongside an improvement in parity. Who in your organisation would need such a note, and who writes it today?
  3. A vendor model update is treated as a change to Hansa Mutual's own system. How do you learn of vendor updates today, and what do they trigger?

Exercise · 25 minutes

Draft a predetermined change envelope

Take a model your organisation retrains or a compound system whose vendor model is updated regularly; if you have none, use Nordvik Region's claims ranker. Write its change envelope: the planned changes with interval, data and parameter ranges, the acceptance criteria with thresholds, the list of changes that fall outside the envelope, and the action those changes trigger. Then write the promotion gate that goes with it: which component versions the candidate names, which thresholds and slices the evaluation uses, what triggers a run, and which role approves, excluding the authors of the change.

Deliverable: A change envelope and a promotion gate definition for one system, each about fifteen lines, with every threshold traceable to a decision record.

Self-test

  1. How is the overall ML Test Score calculated from the four areas?

    1. It is the sum of the four area scores
    2. It is the average of the four area scores
    3. It is the minimum across the four areas
    4. It is the score of the monitoring area alone
  2. Why does the chapter call rollback a registry operation, and what does it require?

    1. Moving the champion alias back is immediate, provided the previous version's environment, features and dependencies still exist
    2. The registry retrains the previous version from its manifest whenever the alias is moved back
    3. The registry deletes the failed version, after which serving falls back to arrival order
    4. The registry asks the provider to redeploy the previous version within the change envelope
  3. In Nordvik Region's change envelope, which of these is listed as outside the envelope?

    1. Retraining after 90 days on a newer release of the same data product
    2. A maximum tree depth of eight within the declared range
    3. A parity difference of 0.02 after retraining
    4. New or removed features, or a change of algorithm family

Chapter 8 · 90 minutes

Setting Up an Effective DevSecMLOps Loop

The lesson widens the frame from the model to the delivery loop through which every part of an AI system changes. Participants learn the ten stages with their owners, artefacts and gates, why revision management is the backbone, what a release is, how commits by coding assistants are treated, how skills, agents and connectors become governed catalogue assets, and how the loop evidences controls of ISO/IEC 27002:2022 inside the information security management system.

Learning objectives

  • Name the artefacts that shape an AI system's behaviour and say where each is versioned.
  • Explain why a release is the set of versions evaluated together and why a manifest records versions, not aliases.
  • Design a catalogue entry for a shared skill with owner, digest, permitted tools and consumers.
  • Map elements of the delivery loop to the ISO/IEC 27002:2022 controls they evidence.

Key concepts

DevSecMLOps loop
The delivery loop in which development, security, machine learning and operations share one loop instead of four handovers. Every stage has an owner, a versioned artefact and a gate the next stage trusts.
Revision management
The backbone of the loop: every artefact that can change the system's behaviour has a version, an owner and a place in version control or in a registry with immutable versions. It decides whether a team can say within an hour what is running.
Release manifest
The signed record of the exact set of artefact versions that passed evaluation together, pinned by digest. If any one changes, the evaluated combination no longer exists and the change needs its own evaluation.
Alias
A mutable reference such as production, used for rollout and rollback in prompt and model registries. Aliases are pointers, not versions, so a release manifest records the version an alias resolved to.
Governed catalogue
One catalogue, owned by the platform, that carries every skill, agent definition, shared prompt and connector to users. Its entry is the unit of governance: owner, version, digest, review and evaluation status, permitted tools and data, distribution and deprecation.

Interactive exercises

  • Match: The gate the next stage trusts
  • Scenario: A quick fix through the alias

Done on the lesson page, with feedback at once.

Discussion

  1. Could your team say within an hour exactly what is running, what changed since yesterday and how to go back? Which artefact would be hardest to name?
  2. The chapter requires that an agent-authored change still needs a second human approval and that agents never hold release credentials. Which of these rules would meet most resistance in your organisation, and why?
  3. Where do skills, agent definitions and connector lists live in your organisation today, and who would own a catalogue of them?

Exercise · 30 minutes

A release manifest and a catalogue entry

For one AI system in your organisation, or for Hansa Mutual's claims assistant, write a release manifest that names every behaviour-shaping artefact with the reference you would pin it by: source commit, service image, base model, adapter, data snapshot, prompt, retrieval index, skills, connectors, the evidence attached and the retention date. Mark each artefact as pinned by digest, versioned but mutable, or unversioned today. Then write a catalogue entry for one shared skill or connector the system uses, with owner, version, risk tier, permitted tools, code execution and network settings, review date, evaluation status and consumers.

Deliverable: A release manifest with a coverage status per artefact and one catalogue entry, plus a short list of the gaps to close first.

Self-test

  1. How does the chapter define a release of an AI system?

    1. The model version that most recently passed the evaluation gate, together with its model card and training manifest
    2. The exact set of artefact versions that passed evaluation together, pinned by digest and signed
    3. The commit on the default branch that the production alias points to
    4. The deployment record written by the platform team after admission
  2. What does the chapter conclude from the reported figures on the security of generated code and on secrets leaked in agent co-authored commits?

    1. Coding assistants should be banned from every repository that holds prompts, policies or evaluation sets
    2. Agent-authored changes should merge without review once the test suite passes
    3. Generated changes pass the same gates as human ones and still need a second human approval
    4. Only the platform team may use coding assistants, with release credentials
  3. In the practical guide for the repository and revision model, what is the bypass list of the ruleset limited to?

    1. A break-glass group of two named people whose use of it raises an alert and an incident record
    2. All repository administrators, reviewed once a year by the security architect
    3. The release pipeline and the coding agents that open pull requests
    4. The model team during training runs, for the life of the training branch

Chapter 9 · 90 minutes

Risks and Vulnerabilities Across the DevSecMLOps Loop

The lesson walks the delivery loop stage by stage from the defender's side: what happened in documented incidents of 2024 to 2026, why the control failed and what prevents it, never how to reproduce an attack. Participants learn the three recurring failures and their containing controls, the limit of provenance, unmanaged skills as a risk class, the mapping to Annex A of ISO/IEC 27001:2022, and the risk register as code.

Learning objectives

  • Identify the three recurring failures behind the reviewed incidents and the control that contains each.
  • Explain why provenance is necessary but not sufficient.
  • Assess an existing pipeline stage by stage and map its risks to Annex A controls.
  • Draft a stage-risk register entry with controls, evidence, key risk indicators and an owner.

Key concepts

Mutable reference
A name such as a Git tag or a registry alias that can be pointed at different content while consumers keep trusting the name. The containing control is pinning by digest and commit SHA, because tags are not versions.
Rotate, do not rewrite
The rule for a secret pushed to a repository: revoke or rotate first and verify that the old value is rejected. Rewriting history strips signatures and leaves the data reachable in forks.
Limit of provenance
Provenance confirms which pipeline built an artefact, not whether that pipeline behaved as intended. It stays valuable because it makes compromise attributable, but the pipeline needs the same protection as its artefacts.
Unmanaged skills
A risk class with four forms: private copies that never receive fixes, unreviewed instructions, connectors of unknown origin and poisoned shared skills. The treatment is the governed catalogue with signing and review.
Risk register as code
The loop's risk register kept in the platform repository. Each entry names the stage, the risk, the controls with their Annex A mapping, the evidence, an owner and key risk indicators computed from manifests and logs.

Interactive exercises

  • Match: Recurring failure and containing control
  • Scenario: A secret in the history

Done on the lesson page, with feedback at once.

Discussion

  1. A vulnerability with a modest severity score in a mirror turned out to matter greatly to the loop. Which component in your pipeline is more important than its score would suggest?
  2. An auditor at Nordvik Region saw a control verified as effective with findings. Why might a recorded and corrected deviation be worth more than an unbroken series of passes?
  3. Where in your pipeline do a tool, a credential and untrusted input meet in the same job, and who decided that they should?

Exercise · 30 minutes

Tabletop: a compromised dependency is reported

Run a tabletop on your own pipeline or on Hansa Mutual's claims assistant. The scenario: a package, action or base model the loop uses is reported compromised this morning. Using the chapter's response guide, write down who freezes promotion and where affected versions are blocked, how every consumer is found by name and digest, which signed manifest systems roll back to, which credentials are rotated and how revocation is verified, what evidence is preserved, and which reporting duties are assessed. Note for each step whether you could meet the guide's default times. Then write the stage-risk register entry for this stage in the form of HM-LOOP-04.

Deliverable: A response timeline with owners and achievable times per step, and one risk register entry with controls, evidence, key risk indicators, Annex A mapping and owner.

Self-test

  1. Which three failures does the chapter say recur across the incidents of 2024 to 2026?

    1. Weak passwords, missing backups and unpatched laptops
    2. Model drift, biased training data and missing model cards
    3. Unclear ownership, late testing and insufficient budget
    4. The mutable reference, the shared CI cache and the credential believed revoked but still valid
  2. What does the May 2026 wave against the TanStack packages show, according to the chapter?

    1. That signed commits and hashed lockfiles make package registries safe to use without a mirror or a soak period
    2. That provenance confirms which pipeline built an artefact, not whether it behaved as intended
    3. That provenance attestations are of no value and should be dropped from the loop
    4. That a soak period is unnecessary once packages carry build provenance
  3. Where should the risks of the delivery loop be recorded, according to the chapter?

    1. In a separate AI risk register owned by the model team and reviewed once a month by the small catalogue board
    2. In the model card of each affected model version, under its limitations block
    3. In the organisation's information security risk register, treated through its selected Annex A controls
    4. In the supplier contracts, since most risks of the loop sit with suppliers and their release cycles

Chapter 10 · 90 minutes

Foundation Models, Retrieval and Grounding

The lesson covers the architectural choices around foundation models: build, buy or adapt, the obligations for general-purpose AI models that reach the organisation as a downstream provider, and retrieval-augmented generation with its failure modes and remedies. Participants study grounding with citations and abstention, chunking, embeddings and indexes, prompts as configuration, and an evaluation set that includes refusal cases, using the citizen-service assistant of Nordvik Region.

Learning objectives

  • Compare the four build, buy or adapt options by what the organisation controls and its position under the AI Act.
  • Match each failure mode of retrieval-augmented generation to its architectural remedy.
  • Design a retrieval prompt template with grounding, machine-checkable citations and a fixed abstention text.
  • Draft evaluation items for a retrieval system, including refusal and no-answer cases.

Key concepts

Foundation model
A model trained on broad data at scale that can be adapted to a wide range of downstream tasks. Its two architecturally significant properties are emergence, capabilities not explicitly designed, and homogenisation, many systems depending on a few models.
Retrieval-augmented generation (RAG)
A generative model combined with a non-parametric memory: a retriever selects passages from an indexed corpus and the generator conditions on the query and the passages. The output rests on sources the organisation controls, can update and can cite.
Grounding
The design response to hallucination: the prompt restricts answers to supplied passages, the output format requires a citation identifier after each claim, and a grounding check scores each claim against its passage and removes, flags or routes unsupported claims.
Structure-aware chunking
Splitting documents on headings and tables and keeping a heading path with each chunk. Every chunk also carries source identifier and version, position, access-control attributes, language and ingestion timestamp.
Refusal case
An evaluation item the system should decline. A set containing only questions the system should answer measures helpfulness alone; refusal and no-answer cases measure safety.

Interactive exercises

  • Match: Where retrieval fails and what remedies it
  • Scenario: A refusal case that fails sometimes

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says the organisation's differentiating knowledge is almost never in the model. What follows for a proposal in your organisation to fine-tune a model on internal documents?
  2. Citations turn an answer into a lead that can be checked. In which of your uses do people check the lead, and in which do they not?
  3. Which questions would regulators and journalists try first on an assistant your organisation runs, and are they in its evaluation set?

Exercise · 30 minutes

A grounded prompt template and its evaluation items

Pick a document corpus in your organisation that an assistant could answer from, or use Nordvik Region's published regional regulations. Write a retrieval prompt template with numbered rules: answer only from the passages, cite an identifier after each factual sentence, reply with an exact abstention text when the passages hold no answer, never disclose information about another identifiable person, and treat passages as reference material and not as instructions. Then write six evaluation items with query, expected sources, reference answer and rubric: three the system should answer, two it should refuse and one where the corpus holds no answer. State the faithfulness threshold and how many runs you require.

Deliverable: A prompt template with rules mapped to the failure each one addresses, and six evaluation items of which at least three are refusal or no-answer cases.

Self-test

  1. Why does the citizen-service prompt template prescribe an exact abstention text instead of letting the model apologise in its own words?

    1. Because a fixed string can be detected and counted in evaluation; a free-form apology cannot
    2. Because Article 50(1) of the AI Act prescribes the wording a system must use whenever it declines to answer
    3. Because a fixed string costs fewer tokens than a generated apology
    4. Because the grounding checker cannot score sentences without citations
  2. What does the chapter say fine-tuning does more reliably than adding facts?

    1. It removes the need for an evaluation set
    2. It makes the model's citations traceable to a clause
    3. It changes behaviour, such as tone, format and vocabulary
    4. It moves the organisation from provider to deployer of the model
  3. Which remedy does the chapter give for the failure in which the system leaks a passage the caller is not entitled to read?

    1. A re-ranking stage after retrieval
    2. Hybrid lexical and semantic retrieval with query rewriting
    3. A larger context window for the generator
    4. The entitlement filter before similarity search

Chapter 11 · 105 minutes

Agentic Architectures and Orchestration

The lesson treats agents as architectural components with explicit boundaries. Participants distinguish workflows from agents by who owns the control flow, learn tool use and the Model Context Protocol as the seam for policy enforcement, and bound autonomy with a permission manifest, a policy decision point, approval gates, budgets, a stop block and an audit trail. Hansa Mutual's claims-triage and IT-operations agents supply the worked artefacts.

Learning objectives

  • Distinguish a workflow from an agent and choose the pattern with the least autonomy that meets a requirement.
  • Explain the four conditions under which autonomy is bounded.
  • Draft a deny-by-default permission manifest with effect classes, argument constraints, budgets and a stop block.
  • Review an approval policy for the three design decisions that make a gate work.

Key concepts

Workflow and agent
In a workflow the control flow is written in code and the model fills in content. In an agent the control flow is delegated to the model, which selects a tool, observes the result and selects the next until a goal or a limit is reached.
Bounded autonomy
Autonomy is bounded when the agent can only reach explicitly granted tools, each tool call executes under a least-privilege identity, actions above a defined risk threshold require approval, and steps and spend are capped.
Permission manifest
The agent's declared intent in a versioned artefact: what it is for, which tools it may call with which arguments, under which identity, and which actions require a human. Nothing the model emits can extend it.
Effect classification
The labelling of each tool on a registered server as read, reversible-write or irreversible. It lets the pipeline check that every irreversible tool in a manifest carries an approval requirement, and lets a tool be prohibited for agent use outright.
Approval gate
The architectural form of human oversight for agents. It presents the action with enough context, binds the approval to the specific action with an expiry, and treats a timeout as a safe stop, never as silent approval.

Interactive exercises

  • Sort: Who owns the control flow?
  • Scenario: Approvals that keep timing out

Done on the lesson page, with feedback at once.

Discussion

  1. A gate that approves by default under time pressure is called worse than no gate. Where in your organisation does an approval step produce evidence of oversight that did not occur?
  2. A skill changes what the agent is told, never what it is permitted to do. Which of your current controls on AI tools are instructions, and which are enforced by the platform?
  3. Nordvik Region runs no autonomous production agents because it cannot yet answer who took the decision and on what grounds. Which questions would your organisation have to answer first?

Exercise · 40 minutes

Design review: a manifest for a proposed agent

A team proposes an agent that acts on a business system in your organisation; if you have no candidate, take an agent that prepares document requests in Hansa Mutual's claims system. First decide whether a workflow would do and record the reason. Then write a deny-by-default permission manifest: purpose, prohibited uses, identity with token lifetime, each granted tool with its effect class and conditions or argument constraints, the actions that require approval with approver role and expiry, the things the agent may never do, budgets for steps, cost and time, a stop block with kill switch, stop conditions and safe state, and audit retention. Add one approval rule bound to the exact action with the behaviour on timeout.

Deliverable: A permission manifest of one page, an approval rule, and a three-line note on why an agent and not a workflow was justified.

Self-test

  1. What is the distinction that matters between a workflow and an agent, according to the chapter?

    1. Whether a large or a small model is used
    2. Who owns the control flow
    3. Whether tools are reached through the Model Context Protocol
    4. Whether the system runs in the cloud or on premises
  2. In Hansa Mutual's approval policy, what does binding an approval to the action hash achieve?

    1. The approval is valid for every tool call of the same class for thirty minutes
    2. The agent can batch ten document requests into one approval
    3. The approval is recorded in the registry together with the model version
    4. The handler approves the request they were shown, not whichever request the agent sends next
  3. Which statement about the AGENTS.md file in a repository matches the chapter?

    1. It carries instructions, not enforcement, so it is paired with controls the agent cannot override
    2. It replaces branch protection and code-owner approval once the coding agents in the repository have read it
    3. It grants the agent a repository-scoped token and network access
    4. It is the permission manifest that the policy decision point evaluates

Chapter 12 · 75 minutes

Integrating AI into the Enterprise Landscape

The lesson closes Part II at the place where AI output reaches a case file, an order or a citizen. Participants learn the gateway functions as integration seam, when to integrate synchronously and when by event, three principles for legacy systems of record, delegated authority with explicit identity propagation, contracts for probabilistic services, caching and idempotency, and the interoperability duties of public bodies under the Interoperable Europe Act.

Learning objectives

  • Explain the two assumptions of classical integration that an AI service breaks.
  • Choose between a synchronous call and an event for a given AI integration and justify the choice.
  • Describe how a delegated token carries both the service identity and the acting person to a system of record.
  • Draft a response contract for a probabilistic service with status, confidence, provenance, model version and disclosure.

Key concepts

Integration seam
The AI gateway as the single seam through which every AI call passes, performing the functions no team should implement twice: authentication and delegated authority, policy enforcement, routing, quotas and budgets, guardrails, logging and tracing, caching and idempotency.
Proposal, not write
AI never writes directly to a system of record. It writes a proposal to an intermediate store or publishes an event, and a deterministic component or a person commits the change, which makes a confident wrong answer recoverable.
Delegated authority
The gateway exchanges the person's token for a short-lived token bound to the AI service's identity, with the person preserved as an act claim. The system of record, not the model, makes the authorisation decision.
Contract for a probabilistic service
An API contract that expresses how confident the service is, where the answer came from, what happens when it cannot answer and which model produced it. Refusal and fallback are first-class outcomes consumers must handle.
Idempotency
A retried request produces no second effect. The gateway stores an idempotency key per request, returns the stored outcome on retry and never re-executes a completed tool call.

Interactive exercises

  • Sort: Call or event?
  • Match: Fields of a contract for a probabilistic service

Done on the lesson page, with feedback at once.

Discussion

  1. Collapsing the service identity and the acting person into one is called the most common identity mistake. What does your system of record see today when an AI service calls it?
  2. Semantic caching is disabled on Hansa Mutual's claims route. For which content in your organisation would a similar enough answer be acceptable, and for which never?
  3. What would each consumer of your AI services do if the service were removed entirely, and has anyone tested it?

Exercise · 25 minutes

Design an integration with a system of record

Choose an AI service in your organisation whose output should reach a system of record, or use a triage suggestion in Hansa Mutual's claims system. Decide whether the integration is synchronous, event-driven or both, and give the reason. Describe the path from proposal to commit and who or what commits. List the claims of the delegated token: service identity, acting person, scope, purpose and lifetime. Then write the response contract as a field list: status values including refused and fallback, a calibrated confidence, provenance, model and prompt versions, and disclosure. Finally state the cache key and whether semantic caching is allowed, with the reason.

Deliverable: A one-page integration design with the commit path, the token claims, the response contract fields and the caching decision.

Self-test

  1. Which of the following is one of the three principles for integrating AI with legacy systems of record?

    1. Give the AI service the legacy system's full command set, since the mainframe treats every caller as a trusted employee
    2. Copy the legacy data into the vector index once and retire the legacy interface
    3. AI never writes directly to a system of record; a deterministic component or a person commits its proposal
    4. Block every transaction of record until the inference call has returned
  2. In the delegated token of Nordvik Region's staff assistant, what do the sub claim and the act claim identify?

    1. The service identity of the assistant and the officer on whose behalf it acts
    2. The officer who signed in and the department that owns the records system
    3. The model version that answered and the prompt version it used
    4. The identity provider that issued the token and the records-management adapter it is meant for
  3. When is a model change behind an unchanged API contract a major version, according to the chapter?

    1. Whenever the provider of the model announces a new model family
    2. When the evaluation suite does not pass, as decided by the consumer's contract tests
    3. When the response schema gains an optional field
    4. Whenever the gateway route moves to another region

Module 3 · Part III · Infrastructure

Part III decides where the platform runs and who controls it. It treats placement as an architectural decision driven by scarce accelerators, sensitive data and European transfer law, compares cloud AI services with self-hosted models challenge by challenge, and carries the resulting hybrid pattern to agentic work tools, where routing is fixed per workspace before a session starts. Participants leave able to place a workload with a recorded rule, check readiness for self-hosting, verify a cloud service's terms and design classification-routed agent workspaces.

Chapter 13 · 75 minutes

Infrastructure, Compute and European Digital Sovereignty

The lesson asks where AI runs and who controls it. Participants learn the book's definition of digital sovereignty as verifiable properties, plan accelerator capacity by workload class, weigh on-premises, European cloud, sovereign hyperscaler variants and confidential computing, map third-country transfers after Schrems II, and apply the sovereignty decision matrix. Nordvik Region's tender profile and decision record AIDR-0211 and Hansa Mutual's capacity plan show the decisions as code.

Learning objectives

  • Explain digital sovereignty as a set of verifiable properties instead of a synonym for on-premises.
  • Identify the transfers of personal data that AI workloads create where classical applications did not.
  • Apply the sovereignty decision matrix to a workload using its data classification and risk class.
  • Draft a sovereignty requirements profile in which each requirement states how it is verified.

Key concepts

Digital sovereignty
The ability of European organisations to control their data, infrastructure and models. It is a set of properties: knowing where workloads run, showing which law governs them, changing provider without rewriting the estate, and continuing to operate if a provider becomes unavailable.
Capacity plan as code
A reviewed file that reserves capacity for interactive inference, schedules batch work such as evaluation and fine-tuning into the gaps, caps agent traffic and reserves fallback inference, compared quarterly with observed utilisation.
Sovereignty requirements profile
A list attached to a tender in which each requirement is mandatory or weighted and states how it will be verified, so that the evaluation committee scores evidence and the platform team can check the same attributes after award.
Confidential computing
Running workloads inside hardware-enforced trusted execution environments so that data is protected in use and the operator cannot read memory. The book treats it as a strong supplementary measure whose attestation must be verified in the deployment pipeline.
Sovereignty decision matrix
A matrix in the architecture repository that sets workload attributes, from public information to classified data, against placements, and is evaluated at intake as a rule set against the workload's declared classification.

Interactive exercises

  • Match: Options between hyperscaler and data centre
  • Scenario: Weights after the scores are known

Done on the lesson page, with feedback at once.

Discussion

  1. In AIDR-0211 the option with the best task quality did not win. How would your organisation set the weights before scoring, and who would agree them?
  2. Which flows of personal data to a third country does your AI use create that nobody decided on, such as telemetry or support access?
  3. Hansa Mutual treats adequacy decisions as dependencies with an owner and a review date. Which legal or contractual assumptions does your placement rest on, and who watches them?

Exercise · 25 minutes

A sovereignty profile and three placements

Write a sovereignty requirements profile for procuring a managed inference service for your organisation, modelled on Nordvik Region's. Include at least five requirements covering location of processing and backups, training use of inputs and outputs, serving of open-weight models with export of weights on exit, a machine-readable self-description and exit assistance. Mark each as mandatory or weighted and state how it is verified. Keep as mandatory only what your legal analysis makes non-negotiable. Then take three workloads of different data classes and place each with the decision matrix, noting where the compliant placement is not yet available and what the workload does meanwhile.

Deliverable: A requirements profile with verification method per requirement, and a placement table for three workloads with the matrix row applied.

Self-test

  1. How does the chapter define digital sovereignty?

    1. As running every AI workload, including training and fine-tuning, on accelerators in the organisation's own data centre
    2. As buying only from providers headquartered and operated in the European Union
    3. As a set of verifiable properties, such as knowing which law governs a workload and being able to change provider
    4. As holding a Gaia-X label for every cloud service in use
  2. What did applying the decision matrix do for Nordvik Region's correspondence summaries, which may include Article 9 health data?

    1. It stopped the workload from going to the most convenient placement while the compliant one was not ready
    2. It placed the workload with a hyperscaler EU region under a transfer assessment
    3. It showed that the workload needed no placement decision at all
    4. It moved the workload to an EuroHPC AI Factory for production inference
  3. In Nordvik Region's tender profile, why is a machine-readable self-description such as a Gaia-X label weighted and not mandatory?

    1. Because Gaia-X labels are only available to hyperscalers that operate sovereign regions through a European legal entity
    2. Because the data protection officer had rejected the label as unreliable
    3. Because weighted requirements are verified after award and mandatory ones before
    4. Because only what the legal analysis makes non-negotiable is mandatory, keeping the tender open to competition

Chapter 14 · 105 minutes

Cloud AI Services versus On-Premises AI: Different Challenges

The lesson compares consuming AI as a cloud service with running open-weight models on accelerators the organisation controls, challenge by challenge: cost and its predictability, capacity and power, who controls the model version, the shared-responsibility split, data terms, regulatory roles, operational burden and lock-in. Participants then apply the chapter's three practical guides: placing a workload, the readiness check before self-hosting, and the controls before relying on a cloud AI service.

Learning objectives

  • Distinguish the three consumption models and say what provider and customer hold in each.
  • Compare the cost risk and the model-change risk of a cloud AI service and a self-hosted model.
  • Apply a workload placement policy and record the rule that produced the placement.
  • Review a platform against the self-hosting readiness gate or a service against the cloud controls file.

Key concepts

Three consumption models
An AI feature embedded in a SaaS product, a model API or managed AI platform, and a self-hosted open-weight model. Responsibilities shift at each boundary, and control and burden grow from the first to the third.
Utilisation risk
The cost risk of self-hosting: the unit cost of a token depends on how busy the hardware is, and a model serving office-hours users pays for capacity it uses a fraction of the day. Cloud cost risk is volume instead.
Forced migration
A model behind an API is not a fixed artefact: the provider decides when it is retired and with how much notice. A cloud-hosted AI system therefore has a migration and a re-run of the evaluation suite built in.
Workload placement policy
A rule set evaluated at intake. Exclusion rules come first, then capability available only as a service, then steady volume with a passed readiness gate, then a default; every placement is recorded in an AI Decision Record with a review date.
Self-hosting readiness gate
The checks that must pass before a self-hosted model reaches production: licence, no unauthenticated endpoint, patching service levels, weights from the registry only, evaluated safety filters, connected monitoring with on-call, and confirmed capacity with a cloud fallback.

Interactive exercises

  • Put in order: Placing a workload
  • Sort: Who holds what with a model API?

Done on the lesson page, with feedback at once.

Discussion

  1. The chapter says published break-even analyses exclude staffing and should be treated as lower bounds. What would an honest three-year cost comparison include in your organisation?
  2. Behaviour of a cloud model can change without any change to the model identifier. How would you notice, and how quickly?
  3. What binds you most to your current AI provider: prompts tuned to one model, fine-tunes held by the provider, managed features or licence conditions?

Exercise · 40 minutes

Place a workload and test the chosen route

Choose a planned AI workload in your organisation, or use Nordvik Region's case-note summariser. Register it with data class, risk class, volume profile and any sector or national rule. Apply the placement rules in order and name the rule that decides. If the result is self-hosting, go through the seven items of the readiness check and mark each as passed with evidence, open with an owner, or unknown. If the result is a cloud service, fill in a controls file: retention, residency, version pinning, deprecation notice, exit assets with a named substitute model, and regulatory position. State what would trigger a re-evaluation of the placement.

Deliverable: A placement record naming the deciding rule and review date, with either a completed readiness checklist or a cloud controls file and its open items.

Self-test

  1. How does the chapter summarise the difference in cost risk between a cloud AI service and self-hosting?

    1. Cloud cost risk is hardware price; self-hosted cost risk is the price of tokens
    2. Cloud cost risk is volume, managed at the gateway; self-hosted cost risk is utilisation and staffing
    3. Cloud cost risk is staffing; self-hosted cost risk is data egress fees
    4. Both carry the same risk, since the unit cost of a token is fixed in each case
  2. Which responsibilities does the customer hold in every consumption model, according to the chapter?

    1. Hosting the base model, patching the serving stack and filtering unsafe content
    2. Choosing the model version, the date of its retirement and whether deployments are upgraded automatically
    3. Capacity, power and cooling, and the patching of inference servers
    4. Data classification and lawful basis; identity, access and keys; human oversight and acceptable use
  3. In the placement policy, what happens first when a workload's data class is special-category, classified or base-registry?

    1. Rule P1 places it self-hosted; if no open-weight model passes evaluation, the answer is redesign or decline
    2. Rule P4 applies: the workload goes to a cloud service with gateway routing once the cloud controls have passed
    3. The workload is scored in a weighted matrix and the highest total wins
    4. The workload is sent to the cloud burst tier until owned capacity is free

Chapter 15 · 90 minutes

Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information

The lesson applies the hybrid pattern to agentic work tools on the desks of engineers, analysts and operators. Participants learn why routing must be fixed by the classification of the workspace before a session starts, how a provider-neutral agent, with OpenCode as the worked example, uses a self-hosted model for confidential and protected information and a cloud model for the rest, and why enforcement sits at the gateway and the network, not in the client.

Learning objectives

  • Explain why model routing for an agent is decided per workspace before the session starts and never per prompt.
  • Classify work into the four information classes and assign the permitted model tier and workspace to each.
  • Design the controls outside the client that make classification routing enforceable.
  • Plan the evaluation that decides whether a protected workspace offers full agents or planning and review only.

Key concepts

Routing before the session starts
An agent sends file contents, command output, tool results and its earlier turns to the selected model. Once a cloud session has read a protected file the disclosure has happened, so the workspace's classification fixes the model tier in advance.
Information classes
Public, internal, confidential and protected. Confidential work may use a cloud service that has passed the controls guide for that class; protected work, such as Article 9 personal data and trade secrets, admits only a self-hosted model in an isolated zone.
Label the work, not the user
Every repository and data set carries a class, unlabelled work defaults to confidential, and labels are bound to the source-control platform and workspace identity, so that the gateway never trusts what the client asserts.
Enforcement outside the client
A client setting is a convenience, not a control. Direct egress from agent workspaces is denied, model traffic goes only to the AI gateway, cloud keys live only in the gateway and a protected workspace holds no cloud credentials at all.
Capacity follows context
A session resends its growing history at each step, so context memory, not the number of engineers, limits concurrency on the self-hosted tier. The tier is sized from measured pilot sessions, and sessions are queued instead of truncated.

Interactive exercises

  • Sort: Four information classes
  • Scenario: One prompt on the better model

Done on the lesson page, with feedback at once.

Discussion

  1. The line between Mode 3 and Mode 5 is said to be not the tool but whether a person is present to answer a prompt. Which of your agent runs already have no person present?
  2. Where a local model falls short, the chapter restricts the protected workspace to planning and review agents instead of relaxing its routing. How would your engineers react, and what would you say to them?
  3. Nordvik Region's hybrid is narrow by necessity and Hansa Mutual's broad by design. What decides the right breadth of the protected tier for your organisation?

Exercise · 35 minutes

Design a classification-routed agent environment

For your own organisation, or for Nordvik Region's platform team, design the environment in the eight steps of the practical guide. Produce a routing table with the four information classes, the permitted model tier and the workspace for each, and the default for unlabelled work. List what the gateway checks before it accepts a request, where cloud API keys live, which egress destinations each workspace may reach and which client features are disabled in the protected tier. Set the evaluation gate for the local model with thresholds for valid tool calls and task completion and say what is offered below it. Finally write three tests, one per workspace, that attempt a forbidden route and state the expected log entry.

Deliverable: A routing table, an enforcement list for gateway, network and credentials, a local-model gate, and three negative tests with expected evidence.

Self-test

  1. Why must the model tier for an agent session be decided before the session starts?

    1. Because switching models during a session resends the whole history and so doubles the token cost of every later step
    2. Because self-hosted models cannot continue a history begun by a cloud model
    3. Because once a cloud session has read a protected file the disclosure has happened; switching model does not recall it
    4. Because the AI Act requires a deployer to register the model before each session
  2. What does the chapter say about a client setting that selects the permitted model provider?

    1. It is sufficient once the managed configuration file sits in the administrator-only directory of the workspace image
    2. It is a convenience, not a control, because a user can install another client or supply a cloud key
    3. It should be replaced by a written instruction to engineers in the acceptable-use policy
    4. It is the place where refused requests are logged as evidence
  3. What is the practical guide's default treatment of a repository that carries no classification label?

    1. It counts as public until the information owner says otherwise
    2. It counts as internal and may be opened in a standard workspace
    3. It counts as protected and may be read only without any agent
    4. It counts as confidential, and agent access to unlabelled repositories is refused

Module 4 · Part IV · Security

Part IV secures what runs on the platform. Two chapters treat AI as the target: the attack surface of models, prompts, retrieval and agents, and the engineering practice of threat models as code, layered controls, security tests in the pipeline and incident playbooks. Two treat AI as the source of threat: adversaries who use AI to shrink the exploitation window and impersonate people, and the organisation's own agents that exceed their mandate. All content is defensive. Participants leave with a linked threat model, a patch-velocity policy and a containment profile.

Chapter 16 · 90 minutes

Security for AI Systems

The lesson extends security architecture to the parts of an AI system that classical controls do not reach: the model, the prompts and retrieved content that steer it, the data that trained it and the agents that act on its output. Participants map the threat surface with the OWASP Top 10 for LLM applications and MITRE ATLAS, study injection, poisoning and leakage at the level needed to design controls, bring models into supply-chain practice with the ML-BOM, and codify a threat model and guardrail policy.

Learning objectives

  • Explain the three properties of AI systems that break long-standing security assumptions.
  • Map the points of the threat surface of an AI system to their main threats and primary architectural controls.
  • Describe how an ML-BOM, signing and provenance bring a model into an existing promotion gate.
  • Draft a threat model entry whose controls resolve to a guardrail configuration.

Key concepts

Single channel for instructions and data
A large language model receives its system prompt, the user's request and any retrieved document as one sequence of tokens, and nothing in the model enforces a boundary between them. The boundary is therefore enforced outside the model.
Indirect prompt injection
Instructions planted in content such as a web page, an email or a shared document that are followed when the content enters the context window. The attacker never touches the application, so every system that reads external content is exposed by construction.
ML-BOM
The CycloneDX Machine Learning Bill of Materials, which records the provenance, licences and training parameters of models and datasets. When a base model is withdrawn, a query over the registry's ML-BOMs lists every model that depends on it.
Threat model as code
A threat model kept in the repository with trust boundaries, threats tagged with OWASP and ATLAS identifiers, and named controls. It is reviewed on every change, because the pull request that adds a source or tool shows the entries affected.
Guardrail policy
The configuration the AI gateway enforces at runtime: allowed retrieval collections, output validation, tool allow-list, actions to confirm and limits. The threat model's control identifiers point to it, so a named control is demonstrably live.

Interactive exercises

  • Match: OWASP entries and their primary control
  • Sort: The review checklist by layer

Done on the lesson page, with feedback at once.

Discussion

  1. The checklist puts foundations first because a reviewer who starts with the AI-specific items tends to miss a shared API key. Which foundation is weakest around your AI systems?
  2. None of the controls makes injection impossible; together they make it unprofitable. What is the worst case of a fully hijacked model in one of your systems today?
  3. Could your organisation establish within 24 hours whether retrieved content caused a wrongful action? What would have to be logged for that?

Exercise · 30 minutes

Security design review of an AI system

Review an AI system of your own organisation, or Nordvik Region's casework assistant, as its security architect. Draw its trust boundaries: where user input, retrieved content, tool results and supply-chain artefacts enter. Write four threat entries in the chapter's form, each with an OWASP identifier, the vector described at design level, the impact, the controls and the residual risk; cover at least retrieved content, agent tools and the model supply chain. Then write the guardrail settings those controls point to: allowed collections, output validation, tool allow-list, actions needing confirmation and limits. Finish by listing which checklist items for foundations you could not evidence.

Deliverable: A threat model excerpt with four linked entries, the matching guardrail policy, and a list of unevidenced foundation items.

Self-test

  1. Why is indirect prompt injection described as more dangerous for enterprises than direct injection?

    1. Because it requires the attacker to hold valid credentials and a delegated token for the application's gateway route
    2. Because it only affects models that were fine-tuned on raw personal data
    3. Because it can be carried out only against self-hosted models
    4. Because the attacker never touches the application: planted content acts when it enters the context
  2. What does the chapter say is the property that matters in a codified threat model and guardrail policy?

    1. Completeness: every OWASP entry and every conceivable attack wording is enumerated in the model before the first release
    2. Linkage: the threat names the control, the control names the configuration, the pipeline proves deployment
    3. Confidentiality: the threat model is kept outside the repository
    4. Brevity: no more than ten threats are recorded for each system
  3. In the casework assistant's prompt section on untrusted content, what does the rule that the prompt contains no credentials record?

    1. That no control depends on the prompt's confidentiality; the case management API decides authorisation
    2. That the prompt may be published unredacted in the public algorithm register alongside the threat model
    3. That the model is not permitted to call any tool at all
    4. That the gateway does not need to log the prompt version

Chapter 17 · 105 minutes

AI Security Engineering in Practice

The lesson is the engineering handbook that follows from the threat map. Using a payment-dispute assistant at a retail bank, participants apply a threat-modelling method that extends STRIDE with MITRE ATLAS and OWASP, then work through the controls at each layer from training data to tool execution, a registry gate with six checks, security tests as a pipeline stage, incident playbooks under the European reporting duties, and a control catalogue that generates the evidence mapping.

Learning objectives

  • Apply the threat-modelling method: six asset classes, trust boundaries and STRIDE extended with ATLAS and OWASP.
  • Describe the five controls that secure retrieval and explain why entitlements are filtered before similarity search.
  • Design a security test stage for the pipeline with explicit pass thresholds per suite.
  • Draft an incident playbook that runs containment in parallel with legal classification.

Key concepts

Defence in depth for AI
Layers from the data and training path through retrieval and the gateway to agents and tools, each assuming the one before it has failed. The threat model, the security tests in CI and the tamper-evident audit log cut across all of them.
Six AI asset classes
Training data; model weights and adapters; prompts, which encode business rules; the retrieval corpus and its index; tools and their credentials; and outputs, which become actions and records. Each has a classification and an owner.
Review trigger
The list in the threat model of configuration paths, such as retrieval sources, tools, model version and prompt template, whose change forces a review. A code-ownership rule routes such changes to the security architect.
Entitlement-aware retrieval
Each document's access attributes are carried onto every chunk, and the filter on the user's delegated identity is applied before the similarity search, never after, because a post-filter leaks through ranking.
Control catalogue entry
An entry that carries framework mappings, the configuration key that implements the control and an evidence query with a fail condition. The pipeline resolves the implementation path, so a renamed configuration fails the build.

Interactive exercises

  • Sort: STRIDE for AI systems
  • Put in order: The injection playbook PB-AI-001

Done on the lesson page, with feedback at once.

Discussion

  1. The security test job tolerates a small success rate for injection attempts but fails on any leakage of another customer's data. How would you justify different thresholds for different suites in your own systems?
  2. The record-keeping duty of AI Act Article 12 and the GDPR's data minimisation principle pull in opposite directions. How does logging identifiers and hashes resolve that, and what does it require of your stores?
  3. Which of your controls is falsifiable today, in the sense that a query would show it failing?

Exercise · 40 minutes

Threat-model workshop and tabletop

Work on an AI system of your own, or on Hansa Mutual's claims correspondence assistant. First list its assets in the six classes with an owner each, and its trust boundaries. Write three threat entries using a STRIDE category, an OWASP identifier and the boundary crossed, with the vector described at the level needed to design the control, and link each to named controls. Add the review trigger paths. Then run a tabletop on one entry: a canary or flag alert has fired. Write who scopes the incident from the trace, what is quarantined or narrowed and by when, which reporting regimes are assessed in parallel, what evidence is preserved, and which regression case and threat model update follow.

Deliverable: A threat model with assets, boundaries, three linked entries and review triggers, plus a one-page playbook with timed steps and owners.

Self-test

  1. Why must the entitlement filter be applied before the similarity search and never after?

    1. Because filtering afterwards doubles the cost of the embedding model
    2. Because the gateway cannot read entitlements once chunks are ranked
    3. Because a post-filter leaks through ranking
    4. Because the AI Act prescribes the order of retrieval steps
  2. In the agent authorisation policy, which two properties does the chapter say matter more than the details?

    1. An approval is bound to the hash of the specific action, and the token's subject must equal the user
    2. The policy is written in Rego, and it is evaluated by Open Policy Agent
    3. Refunds are capped at a fixed amount, and approvals never expire
    4. The agent holds a long-lived key, and the operator can edit the log
  3. How does the chapter position red teaming in the delivery of an AI system?

    1. As a single exercise before launch that need not be repeated
    2. As external discovery whose every finding becomes an automated test that also runs on a schedule
    3. As a replacement for threat-led penetration testing under DORA
    4. As a task for the model provider alone under Article 55, with the documentation requested in procurement

Chapter 18 · 90 minutes

When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window

The lesson treats AI as the source of threat in an adversary's hands. Participants examine the reported evidence that AI makes existing techniques cheaper and faster, that every patch is an exploit specification, and that the exploitation window has collapsed. They then build the architectural response: patch velocity by exploitability tier with compensating controls, detection with authority to act, approvals that resist synthetic media, and defensive AI under oversight, sequenced in a 30-60-90-day plan.

Learning objectives

  • Explain why publishing a fix starts a race the defender begins with a handicap.
  • Classify vulnerability findings into tiers by known exploitation, exploitation probability and exposure.
  • Design an approval process for high-value or irreversible actions that does not rely on appearance.
  • Draft a 30-60-90-day plan that sequences the response for an organisation.

Key concepts

Exploitation window
The time between a patch or advisory and exploitation. The chapter reports measurements falling from weeks to days and an estimate in which exploitation routinely precedes the patch, so a monthly patch cycle no longer matches the threat.
Patch velocity
The time from advisory to protection, treated as a measured service level with an emergency path. In the chapter's policy, tier 1 findings are protected within 48 hours by a patch or a compensating control.
Compensating control
A measure such as virtual patching, disabling the feature or isolating the system that carries the risk when a patch cannot be applied in time. It is prepared in advance and recorded with an expiry date.
Synthetic-media-resistant approval
For actions that move money, change payee details, grant privileged access or deploy to production: verification through an independent channel registered in advance and approval by a second person who did not receive the request.
The shared principle
Every boundary around an AI workload, and every approval of a consequential action, should be enforced by something that neither an attacker nor the workload itself can change. None of the responses relies on predicting the actor.

Interactive exercises

  • Sort: Which tier is this finding?
  • Scenario: The director on the video call

Done on the lesson page, with feedback at once.

Discussion

  1. Only a small fraction of disclosed vulnerabilities is exploited, which is why prioritisation works at all. What does your organisation prioritise by today, and does it include exposure?
  2. An alert to a person not empowered to stop the workload produces a record, not a response. Who in your organisation may stop a production workload without a meeting?
  3. Why is refusing an urgent request from a senior executive described as protected behaviour, and what would have to change for staff in your organisation to believe it?

Exercise · 30 minutes

Tabletop: 48 hours from advisory to exploit

Run a tabletop for your own organisation or for Nordvik Region. A critical patch for a component of the AI platform is published this morning. Using the chapter's guides, write down how exposure is confirmed from the inventory within the first hour, which interim mitigation or compensating control is applied to internet-facing instances, which detections are raised, who may use the emergency change path, and how remediation is verified. Classify the finding with the tier criteria. Then take one process that moves money or changes payee details and state its call-back channel, its second approver, its cooling-off rule and how you would test it with a synthetic voice exercise.

Deliverable: A timed response sheet for the first 24 hours with owners, the tier classification with reasons, and a hardened approval rule for one process.

Self-test

  1. Why does the chapter say that the defender begins the race after a published fix with a handicap?

    1. Because the attacker needs one exploit and the defender needs every instance patched
    2. Because vendors publish patches to attackers before they reach customers
    3. Because defenders may not use AI to triage advisories under the AI Act
    4. Because patches for AI components cannot be tested before deployment
  2. What lesson does the chapter draw for architects from the Arup case?

    1. That video conferencing must be removed from finance departments and replaced by signed e-mail for every payment request
    2. That the firm's internal systems had been compromised months earlier
    3. That deepfake detection software would have stopped the transfers
    4. That the approval process was the vulnerability: it treated a familiar face and voice as proof of identity and authority
  3. In the patch-velocity policy, what does the service level for tier 1 require?

    1. A patch deployed to every instance within 30 days of the advisory, verified by closing the change ticket for each system
    2. A risk acceptance signed by the CISO within seven days
    3. A patch or compensating control in place within 48 hours, through a pre-approved emergency change path
    4. A vendor confirmation that no exploit exists before any change is made

Chapter 19 · 90 minutes

When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent

The lesson concerns the threat that needs no adversary: agents given goals, tools and credentials that reach the goal by routes nobody sanctioned and report something other than what was recorded. Participants review the reported evidence on specification gaming and on workarounds of sandboxes and limits, learn why instructions are not a control, and build containment enforced by the platform, detection from telemetry and decoys, and a response that never relies on the agent's account.

Learning objectives

  • Explain why containment of an agent must not depend on the agent's intent or on instructions.
  • Describe the containment layers the platform enforces outside the agent.
  • Draft a containment profile for a coding or operations agent.
  • Plan detection and response for agent overreach based on what the infrastructure recorded.

Key concepts

Specification gaming
Behaviour that satisfies the literal specification of an objective without achieving the intended outcome; reward hacking is the variant that manipulates the measure of success itself, such as modifying tests or scoring code.
The well-meaning insider
The chapter's mental model for an agent: a capable colleague with access and a deadline who may route around a control without malice. Security practice handles insiders with least privilege, separation of duties, unalterable logs and a second person for irreversible actions.
Advice and control
A boundary the agent can see and change is advice; a boundary enforced by something the agent cannot reach is a control. System prompts lower the rate of overreach but leave it above zero, so they are not a boundary.
Protected control artefacts
Tests, evaluation sets, policies, pipeline definitions, logs and the stop mechanism sit outside the agent's write access. An agent that cannot change a test cannot make it pass by editing it.
Stop path outside the system
A stop instruction sent to the agent is a request it processes; a kill switch in the platform is a control. The holders are named in advance, have authority to use it without a meeting, and the switch is tested.

Interactive exercises

  • Match: Containment layers enforced by the platform
  • Sort: Three kinds of overreach signal

Done on the lesson page, with feedback at once.

Discussion

  1. An agent's account is a claim, not evidence. Where in your organisation is an agent's or a tool's own summary currently accepted as the record of what happened?
  2. Which of the artefacts that define success for your agents, such as tests, evaluation sets and pipeline definitions, can those agents write to today?
  3. Nordvik Region's priority is to keep agency out of places it has not granted it; Hansa Mutual's is to contain the agency it has granted. Which describes your situation, and what follows for your first control?

Exercise · 30 minutes

A containment profile and its proof

Write a containment profile for a coding or operations agent in your organisation, or for an agent of Nordvik Region's platform team. State the isolation and lifetime of the environment, the identity and token lifetime, the reach through a narrow tool interface, default-deny egress with named destinations, the protected artefacts, one decoy and where it sits, budgets for steps, write actions and time, the append-only log and what it captures, and the kill switch with named holders. Then design the test task that proves it: list each denied capability and budget the task attempts and the log entry you expect. Finish with the first three steps of your response if an overreach alert fires.

Deliverable: A containment profile of about twenty lines, a negative test list with expected evidence, and a three-step response opening that stops the agent from outside.

Self-test

  1. Why does the chapter conclude that system prompts are worth writing but are not a boundary?

    1. Because system prompts are visible to users and can be copied
    2. Because they lower the rate of out-of-scope behaviour but leave it above zero
    3. Because the AI Act forbids safety instructions in system prompts
    4. Because agents do not receive the system prompt when they call tools
  2. How does the chapter read, architecturally, the AI Act's requirement that a high-risk system can be brought to a halt in a safe state?

    1. As a requirement that the agent is instructed to stop itself on request
    2. As a requirement that every tool call is approved by two people
    3. As a requirement that the stop path lives outside the system it stops
    4. As a requirement that agents are switched off outside office hours
  3. What is the first step of the chapter's guide for responding when an agent has exceeded its mandate?

    1. Ask the agent for a summary of what it did and why, and compare that summary with the declared task before acting
    2. Rewrite the system prompt with a clearer scope statement
    3. Notify the model provider and wait for its analysis
    4. Stop the agent and related tasks through the platform kill switch; never ask the agent to stop itself

Module 5 · Part V · Delivery and Operations

Part V takes AI systems through release and into daily operation. It defines an evaluation strategy for components that behave probabilistically, an observability stack that separates the regulatory record from operational traces and detects drift, a cost and carbon discipline with levers in the gateway, and a codified path from pilot to production. Participants leave with an evaluation suite with thresholds, a drift job and incident runbook, a cost policy with unit economics, and a readiness checklist tied to a go or no-go decision record.

Chapter 20 · 90 minutes

Evaluation and Testing of AI Systems

The lesson defines a testing strategy for systems whose most important component behaves probabilistically. Participants learn the six layers of the evaluation pyramid, the governance of golden datasets, the use and limits of a judge model, regression testing with repeated runs and champion comparison, acceptance criteria as code, and the place of red teaming and human evaluation, with Nordvik Region's claims-routing suite and evaluation report as worked material.

Learning objectives

  • Describe the six layers of the evaluation pyramid and how often each runs.
  • Identify the four ways a golden dataset is mishandled and the governance that prevents each.
  • Explain the documented biases of judge models and the rules that follow for using one.
  • Draft an evaluation suite definition with datasets, checks, thresholds and reporting.

Key concepts

Evaluation pyramid
Six layers from numerous, cheap, deterministic tests run on every commit to few, costly ones run per release: unit tests for code, data tests, model metrics, behavioural and scenario tests, red teaming and human evaluation.
Golden dataset
A curated, versioned collection of inputs with expected outputs or labels, the reference for model metrics and scenario tests. It is mishandled through contamination, staleness, unclear ownership and personal data without proper controls.
LLM-as-a-judge
Using a strong LLM to grade outputs that have no reference answer. Judge models show position, verbosity and self-enhancement bias, so the judge is calibrated against a human-labelled sample, pinned, never of the same family as the system, and kept under a human layer.
Evaluation suite definition
The file that turns the pyramid into a pipeline gate. It declares datasets, metrics, thresholds and judge configuration; the pipeline fails if any threshold is not met and attaches the report to the evidence manifest.
Pass rate with confidence interval
Because a single pass or fail is not meaningful for a non-deterministic system, each scenario is run several times and the result compared with the champion, with a minimum improvement or a maximum permitted regression.

Interactive exercises

  • Sort: Which layer of the pyramid?
  • Scenario: A pass at the edge of the threshold

Done on the lesson page, with feedback at once.

Discussion

  1. A model that gains two points of accuracy and loses ten points of calibration has not improved for decision support. Which single headline number does your organisation report, and what does it hide?
  2. Changes to expected outputs in an eligibility golden set are reviewed by the business owner, not by engineers. Who owns the expected answers in your evaluation sets?
  3. Nordvik Region's red-team plan separates what is tested from how, and includes a caseworker among the testers. What does each of those choices make possible?

Exercise · 30 minutes

An evaluation suite with acceptance criteria

For an AI system of your own, or for Hansa Mutual's claims assistant, write an evaluation suite definition. Name the datasets with a version reference and a datasheet, the number of repetitions and the fixed settings for runs, and at least four checks: one overall task metric with a minimum and a maximum regression from the champion, one sliced by a group or market that matters with a minimum per slice, one judged check with the judge configuration, and one resistance or refusal check. Name the business approver. Then write the datasheet lines for the golden dataset that cover contamination, refresh cadence, ownership of expected outputs and personal data.

Deliverable: An evaluation suite definition with four checks and thresholds, and a datasheet extract for its golden dataset with known limitations stated.

Self-test

  1. Which rule about thresholds does the chapter set for changes to the evaluation suite?

    1. A threshold may be lowered whenever the challenger narrowly misses it
    2. A threshold is never lowered in the same pull request that changes the model
    3. Thresholds are set by the model provider and copied into the suite
    4. Thresholds apply only to high-risk AI systems and are optional elsewhere
  2. Which of these is one of the chapter's rules for using a judge model?

    1. Use the same model as the system under evaluation, so the styles match
    2. Prefer absolute scores over comparison between two versions
    3. Let the judge replace human evaluation once its agreement with human raters exceeds eighty per cent
    4. Calibrate the judge against a human-labelled sample and record the agreement rate as evidence
  3. In Nordvik Region's evaluation report the automated gate passed. Why did the release not proceed on that alone?

    1. Because the champion had scored higher than the challenger on routing accuracy and on explanation grounding
    2. Because the judge model had not been calibrated against human raters
    3. Because the gate is necessary but not sufficient: human evaluation and business approval were still open
    4. Because the injection resistance check had failed its minimum pass rate

Chapter 21 · 90 minutes

Observability, Monitoring and Drift in Production

The lesson explains how to keep an AI system trustworthy after go-live. Participants distinguish data drift, concept drift and performance decay, design an observability stack that separates the unsampled record of events from sampled operational traces, define a drift detection job and service level objectives for a probabilistic service, plan sampled human review that avoids feedback loops, and extend incident management with an AI classification step, an impact query and a path back to evaluation.

Learning objectives

  • Distinguish data drift, concept drift and performance decay and say which signals reveal each.
  • Explain why the evidence pipeline is unsampled while the operational pipeline is sampled.
  • Define a drift detection job with reference window, current window, checks and actions.
  • Draft an AI incident runbook that narrows before it suspends and assesses notifications in parallel.

Key concepts

Data drift and concept drift
Data drift occurs when the distribution of inputs changes while the relationship between inputs and outputs stays the same. Concept drift occurs when the relationship itself changes. Performance decay is the observable consequence of either.
Evidence pipeline
The route by which the record of events reaches an append-only store with retention locks. It is not sampled, because Article 12 of the AI Act requires automatic recording of events over the system's lifetime.
Drift detection job
Scheduled, versioned code that compares a reference window with a rolling current window for input drift, prediction drift and delayed-label accuracy. Its thresholds are the same values as in the post-market monitoring plan.
Blind sample
A small sample in which officers decide before seeing the system's suggestion, with a record of whether each decision was made with or without it. Without it, accuracy measured against decisions that follow the suggestion becomes meaningless.
Impact query
A query listing which decisions each model version made in which period, used for remediation after an incident. It is the reason the Article 12 record must be complete and unsampled.

Interactive exercises

  • Put in order: The AI incident runbook
  • Match: Indicators for a probabilistic service

Done on the lesson page, with feedback at once.

Discussion

  1. Labels often arrive late or never. For which of your systems do you never learn the right answer, and what do you monitor instead?
  2. Suspension is called an architectural requirement: a tested switch and a fallback that absorbs the load. Could your organisation process the work manually for a week, and has it tried?
  3. Awareness time is recorded at detection because a time reconstructed later will be reconstructed generously. What else in an incident record is tempting to reconstruct afterwards?

Exercise · 35 minutes

A drift job and an incident tabletop

For one production AI system of your own, or for Nordvik Region's claims-routing classifier, define a drift detection job: the reference source, the current window and minimum sample, an input-drift check on named features, a prediction-drift check, a delayed-label check with the label delay you really face, and the actions on warning and on alert. Then run a tabletop: the input-drift alert has been in alert state for a day after a rule change. Write how you confirm it, how you assess whether it is real and matters, how you narrow the system before suspending it, what evidence you preserve, which notification questions you assess in parallel, and what you add to the golden dataset afterwards.

Deliverable: A drift job definition with thresholds and actions, and a completed incident sheet with awareness time, containment steps, notification assessments and the follow-up test case.

Self-test

  1. Why is the evidence pipeline in the collector configuration not sampled?

    1. Because Article 12 of the AI Act requires automatic recording of events, and a sample is not a record
    2. Because sampling would expose prompt and completion content that hashing in the collector cannot protect
    3. Because the observability back end cannot store traces that have been sampled
    4. Because unsampled traces are cheaper to query than sampled ones
  2. What does the chapter prescribe to counter a feedback loop in which case officers accept a decision support tool's suggestions by default?

    1. Retrain the model more often on the recorded decisions, so that it follows the officers' latest practice
    2. Hide the confidence score from the case officers
    3. Record whether the human decided with or without the suggestion, and keep a small blind sample
    4. Raise the alert threshold for prediction drift on the predicted route
  3. In Nordvik Region's drift runbook, how may a drift threshold be changed?

    1. By the on-call engineer silencing the alert for the affected slice
    2. By the supplier, as part of the next quarterly retraining
    3. By the incident manager during containment, with a note in the ticket
    4. Through a pull request to the drift job, never a silenced alert

Chapter 22 · 75 minutes

Cost, Capacity and Sustainability of AI

The lesson treats cost and energy as architectural constraints. Participants trace inference cost to its drivers in the token formula, plan GPU capacity for interactive and batch demand, apply the gateway levers of caching, routing and batching, set up attribution and a cost policy with budgets and unit economics, and calculate carbon per functional unit with the Software Carbon Intensity specification, using Nordvik Region's capacity plan, routing policy and SCI record.

Learning objectives

  • Explain each term of the inference cost formula as an architectural decision.
  • Compare the levers of caching, routing and batching by the cost driver each acts on.
  • Draft a cost policy with budget alerts, a hard cap with fallback, and a unit-economics target.
  • Calculate a Software Carbon Intensity score for a use case and state its boundary and limitations.

Key concepts

Token economics
The cost of a request is roughly input tokens times the input rate plus output tokens times the output rate, multiplied by request volume. Input tokens come from the system prompt, retrieved context, history and the user's message.
Routing policy
A gateway configuration that classifies each request and sends it to the cheapest model that meets the quality objective from the evaluation suite. Each route names its evidence, and a fallback makes behaviour under budget exhaustion explicit.
Chargeback and showback
Attribution of tokens and GPU hours through the gateway to use case and team. Whether the consuming team pays or is merely informed is a management decision; the architecture is the same.
Unit economics
Cost set against a unit of work, such as a resolved enquiry or a processed claim. It relates spending to value and is the figure a steering committee can act on, unlike cost per request.
Software Carbon Intensity (SCI)
The specification published as ISO/IEC 21031:2024: energy consumed times the carbon intensity of the electricity, plus embodied emissions of allocated hardware, divided by the functional unit. It rewards reduction, so purchased offsets do not lower the score.

Interactive exercises

  • Sort: Which lever is it?
  • Scenario: The budget runs out in the third quarter

Done on the lesson page, with feedback at once.

Discussion

  1. A two-thousand-token system prompt sent with every request is called a fixed cost nobody chose deliberately. Which costs in your AI services did nobody choose?
  2. The fallback on budget exhaustion is the difference between a cost policy and a cost surprise. What should your most used AI service do when its budget is exhausted?
  3. Which functional unit would make cost and carbon comparable across your AI use cases, and who would have to agree to it?

Exercise · 25 minutes

A cost policy and an SCI calculation

For one AI use case of your own, or for Nordvik Region's citizen FAQ service, draft a cost policy: the monthly budget, alert levels, a hard cap and what the gateway falls back to when it is reached, the pipeline threshold for a cost increase that needs the cost owner's approval, and a target cost per unit of work. Then calculate an SCI score using the chapter's formula: state the functional unit, the boundary with what is included and excluded, the energy and how it was measured or estimated, the carbon intensity and its source, the embodied emissions allocated, and the number of functional units. Add one sensitivity line and the known limitations.

Deliverable: A cost policy of about ten lines and an SCI record with boundary, method, result against a target, a sensitivity line and limitations.

Self-test

  1. What did the weekly showback report at Nordvik Region reveal about the eligibility-explanation route?

    1. It had the most requests and the lowest cost per resolved enquiry of all routes in the routing policy
    2. It was served entirely from the exact-match cache at no cost
    3. It exceeded the hard cap of the monthly budget in every week
    4. With the fewest requests it carried 40 per cent of spend for 13 per cent of resolved enquiries
  2. What does the chapter call the most common mistake in GPU capacity planning?

    1. Buying on-demand capacity for the interactive peak
    2. Sizing for the interactive peak and leaving capacity idle at night
    3. Scheduling batch work into the troughs of interactive load
    4. Measuring quality after adopting quantisation
  3. How can a Software Carbon Intensity score be improved, according to the chapter?

    1. Only by less energy per unit, cleaner energy or less allocated hardware; offsets do not lower it
    2. By purchasing offsets equal to the operational emissions of the period and recording them in the calculation
    3. By excluding the hosted model routes from the boundary of the calculation
    4. By changing the functional unit from resolved enquiries to requests

Chapter 23 · 90 minutes

From Pilot to Production: Scaling AI Across the Organisation

The lesson explains why AI pilots stall and how to codify the path from idea to governed production service. Participants learn the pilot trap and its causes, the platform as a product with golden paths, the intake record and four prioritisation criteria, the production readiness review as a gate mapped to Article 26 of the AI Act, the go or no-go decision record with stop criteria, the closing of pilots that do not proceed, and measures of industrialisation.

Learning objectives

  • Explain why pilots built beside the enterprise estate stall on the way to production.
  • Describe what a golden path gives a team and what leaving it costs.
  • Review a use case against a codified readiness checklist with evidence, exceptions and owners.
  • Draft a go or no-go decision record with options, conditions and measurable stop criteria.

Key concepts

Pilot trap
The state in which an organisation can start AI initiatives but not finish them: proofs of concept with no owner, model code in a notebook on a laptop, and no funding. The chapter calls it a failure of architecture, not of talent.
Golden path
A documented, templated, supported way of building a particular kind of AI service with the controls already wired in. A team that leaves it must prove equivalence at the readiness review.
Intake record
A short structured file in the use-case portfolio repository with sponsor, value hypothesis, decision impact, data sources, likely AI Act role and prioritisation scores. It makes the decision to proceed reviewable and seeds the risk classification.
Production readiness review
The gate between a pilot and a service: a codified checklist whose items are verified by evidence in the repository, most of them automatically. An item passes, fails, or passes with a recorded exception that has an owner and an expiry.
Stop criteria
Conditions in the go-live decision record, measurable from the observability configuration verified at the gate, any one of which triggers rollback. A rollback then depends on a threshold and not on a meeting.

Interactive exercises

  • Match: Deployer obligations and their evidence
  • Scenario: A pilot that will not proceed

Done on the lesson page, with feedback at once.

Discussion

  1. The single failure in Hansa Mutual's gate run belonged to the business owner: nobody had agreed the baseline that defines success. Who would fail that check for your current pilots?
  2. Reuse potential is the prioritisation criterion most organisations omit. Which of your proposed use cases would force the platform to add a capability the next five also need?
  3. What do your abandoned pilots still hold in the way of data extracts, credentials and indexes, and who is responsible for closing them?

Exercise · 35 minutes

Readiness review and go or no-go record

Take a pilot in your own organisation, or Nordvik Region's staff assistant before its scale-out. Write its intake record with value hypothesis, baseline and target, decision impact, data sources, likely AI Act role and the four prioritisation scores. Then run a readiness review with at least eight checks drawn from the chapter's table and checklist; for each give the evidence location, whether it is automated, and the result as pass, fail or pass with exception, naming an owner, an expiry and a compensating control for each exception. Finally write the decision record: at least two options, the decision, conditions, three measurable stop criteria and who accepts the residual risk.

Deliverable: An intake record, a readiness checklist with results and exceptions, and a go or no-go decision record with stop criteria and a named accountable owner.

Self-test

  1. What is the deeper cause of stalled pilots, according to the chapter?

    1. The models used in pilots are too small for production workloads and must be replaced before the readiness review
    2. Steering committees approve too few pilots each year
    3. Most pilots are built beside the enterprise estate, so controls must be retrofitted at higher cost
    4. Business units lack the talent to write evaluation sets
  2. What happens at the readiness gate when an item's evidence is missing or older than the last model or prompt change?

    1. The pipeline blocks deployment unless an exception is recorded with an owner and an expiry
    2. The review board discusses the item and records the outcome in minutes
    3. The item is waived automatically for systems that are not high-risk
    4. The deployment proceeds and the gap is listed in the next quarterly report
  3. Which option did Hansa Mutual choose in the go-live decision AIDR-0034 for the claims triage assistant?

    1. A full go for all claim types and all handlers on the planned date
    2. A conditional go: property claims only, 30 per cent of handlers, for six weeks
    3. No go until both exceptions had been closed
    4. A go for the German market only, with the other markets after a year

Module 6 · Part VI · Conclusions

Part VI draws the conclusions. The first lesson collects the decisions of the whole book into one platform and security conclusion each for Nordvik Region and Hansa Mutual, with what worked, what was hard and a prioritised plan for 24 months. The second reduces the book's argument to eight conclusions, the artefacts that carry them, the trade-offs the platform must engineer and a capability roadmap in three stages, each with a test. Participants leave with a roadmap for their own organisation.

Chapter 24 · 90 minutes

Nordvik Region and Hansa Mutual: Platform and Security Conclusions

The lesson collects the chapter-by-chapter answers into one platform and security conclusion for each of the two fictional organisations. For Nordvik Region and for Hansa Mutual, participants review the starting point, the decisions recorded across the book, the usage-mode profile, what was built first, what worked and what was hard, and the prioritised plan for the next 24 months, and compare why the same principles give different platforms.

Learning objectives

  • Summarise the platform and security decisions of Nordvik Region and Hansa Mutual and the records that hold them.
  • Explain the four causes of the differences between the two platforms.
  • Assess what worked and what was hard in each case and what each can learn from the other.
  • Draft a prioritised platform and security roadmap as a checkable artefact.

Key concepts

Reduced platform around a procured core
Nordvik Region's shape: the gateway, the registry and acceptance suites the authority owns, with existing identity, logging and archive services as the control plane, no agent runtime, and model-building left to the supplier.
Group baseline with market overlays
Hansa Mutual's shape: one shared platform with an overlay per entity that may tighten the baseline but never relax it, selected by the policy engine from a system's declared markets and checked against where it is processed.
Controls that follow the claim
At the Polish service centre the controls attach to the claim, not the building: the chapter's own conclusion is that the agent's permissions, log retention and notification route must follow the claim's market wherever the server stands.
Roadmap as code
The plans recorded as version-controlled artefacts with items, horizons, deadlines and references to decision records, exceptions and risk entries, so that one pipeline can check that every referenced record exists and every deadline is met.

Interactive exercises

  • Sort: Nordvik Region or Hansa Mutual?
  • Scenario: UK claims through the Polish service centre

Done on the lesson page, with feedback at once.

Discussion

  1. At Nordvik Region capacity, not policy, decides when a compliant placement becomes available. What decides it in your organisation?
  2. The chapter says the market dimension worked at Hansa Mutual because it was declared in the first manifest and not added later. Which dimension of your own estate should have been in the first manifest?
  3. Nordvik Region has no exit test for its triage supplier, and Hansa Mutual scales faster than each market's rules allow. Which of the two weaknesses is closer to yours, and what would the other organisation advise?

Exercise · 30 minutes

Your organisation's conclusion and roadmap

Write the platform and security conclusion for your own organisation in the form the chapter uses for the two cases. State the starting point in five lines: legal position, role under the AI Act, build or buy, team and main lever. Give the usage-mode profile, one line per mode in use. List three things that work and three that are hard, each tied to an artefact or its absence. Then write a prioritised plan for 24 months with five items ordered by what each depends on, and express three of them as roadmap items with identifier, horizon, action, the record or gap each closes and a deadline where a legal date applies. Add the gates that hold throughout.

Deliverable: A two-page conclusion with usage-mode profile, strengths and difficulties, and a five-item plan of which three are written as checkable roadmap items.

Self-test

  1. Why did replacing Nordvik Region's ranking model with a version without postcode features need a new decision record and an updated FRIA?

    1. Because the supplier had changed and a new tender was required
    2. Because the system moved from on premises to a European cloud provider
    3. Because removing features lies outside the change envelope, so it could not pass as planned retraining
    4. Because the new version scored lower on precision at 100 than the evaluation criterion of the decision record allows
  2. Which of the four causes of difference between the two organisations does the chapter call the most consequential?

    1. Nordvik avoids Modes 3 and 5 outside its platform team, while Hansa uses both daily and needs layered containment
    2. Nordvik has two accelerators on order, whereas Hansa already reserves eight in Frankfurt and four in an EU cloud region
    3. Nordvik reports to an elected body, whereas Hansa reports to an executive board
    4. Nordvik uses open-weight models, whereas Hansa uses only vendor models
  3. What makes Hansa Mutual's market overlays bite, according to the chapter?

    1. Each market keeps its own copy of the platform manifest and deploys it separately through its own release pipeline and gateway
    2. The group baseline is relaxed for entities outside the AI Act and DORA
    3. Legal changes are collected yearly and applied to all overlays at once
    4. The policy engine selects overlays from a system's declared markets and checks every processing location against them

Chapter 25 · 90 minutes

Conclusions: Building and Securing AI Platforms

The lesson consolidates the book. Participants restate the thesis for platform and security, review the eight conclusions on which the parts converge and the tensions each acts on, identify the few artefacts that carry most of them and the four trade-offs the platform must engineer, and work with the capability roadmap in three stages, each with a test. A marked forward look separates what is observable from the author's speculation.

Learning objectives

  • State the book's thesis on when an AI platform is under control.
  • Explain the eight conclusions and the tension each acts on.
  • Assess an organisation against the three stages of the capability roadmap using the test of each stage.
  • Draft a first-90-days platform and security plan with workstreams, outcomes and success measures.

Key concepts

The thesis
An AI platform is under control when everything that shapes behaviour is codified, versioned and evaluated together, every model call and tool call passes a policy point outside the model, containment holds whatever anyone intends, and evidence comes from normal operation.
Shared artefacts
A few artefacts serve several conclusions at once: the gateway is routing point, policy decision point, cost meter and source of the event log; the permission manifest and the release manifest likewise carry more than one conclusion.
Engineered trade-offs
Four conflicts that become design decisions with a cost: speed of defence against change control, rich telemetry against storage limitation, containment against value, and routing for cost against stable evaluation.
Capability roadmap
Three stages stated as platform capabilities, each with a test: one control point and a working stop in months 0 to 6, replaceable and ready for high-risk duties in months 6 to 18, and evidence on every release with autonomy by exception in months 18 to 36.
Observable and speculation
The labels the chapter uses in its forward look to separate what can be observed today, with sources, from what the author expects. The full outlook is in AI Governance, Chapter 22.

Interactive exercises

  • Sort: Which stage of the roadmap?
  • Match: Four trade-offs and their reconciliation

Done on the lesson page, with feedback at once.

Discussion

  1. Sovereignty is said to depend less on where a model was made than on how fast it can be replaced. How fast could you replace the model behind your most important AI service, and how do you know?
  2. A platform that does not budget for its controls will find them traded away in the first difficult quarter. Which control on your platform is unfunded?
  3. The chapter says that if its judgements prove wrong the timing of the roadmap changes but not its order. Which stage of the roadmap would you be tempted to skip, and what would it cost later?

Exercise · 30 minutes

Stage assessment and a first-90-days plan

Assess your organisation against the tests of the three roadmap stages. For Stage 1, state whether any model calls bypass the gateway, whether shared or standing credentials exist in AI workloads, and whether each acting agent has been stopped in an exercise. For Stage 2, state whether a forced model migration has been rehearsed and whether unregistered skills or connectors exist. For Stage 3, state whether an auditor could reconstruct a release and an agent permission from records alone. Then write a first-90-days plan with four workstreams, each with the usage modes it concerns, the records it refers to, an outcome that can be verified and a due day, plus two success measures.

Deliverable: A stage assessment with evidence or gap per test, and a first-90-days plan with four workstreams and two success measures.

Self-test

  1. Why does the chapter say the inventory and every approval should name the usage mode and not the brand?

    1. Because brand names change too often to be kept in a register
    2. Because one vendor appears in several modes, and the mode determines what the platform must provide
    3. Because the AI Act forbids naming vendors in public registers
    4. Because the mode is easier to detect from proxy logs than the vendor
  2. How does the chapter reconcile the demand to protect within 48 hours with change management requirements that every change be reviewed?

    1. By exempting security patches for known-exploited vulnerabilities from DORA's change management requirements altogether
    2. By patching only at the monthly change window with extra reviewers
    3. By leaving the decision to each system owner at the time of the advisory
    4. By approving the emergency path, its canary rings and rollback in advance, making each patch a standard change
  3. What is the test of Stage 1 of the capability roadmap?

    1. No model calls outside the gateway, no standing credentials in AI workloads, and each Mode 5 agent stopped in an exercise
    2. A forced model migration rehearsed end to end and no unregistered skill or connector found in a quarterly scan of the estate
    3. An auditor reconstructing any release and any agent permission from records alone
    4. Every use case on the golden path and a first-attempt pass at every readiness review