Governing Generative AI, end to end.

Module 00 — Orientation

The 360° View of GRC for GenAI

GRC — Governance, Risk, and Compliance — is the discipline of steering an organization toward its objectives (governance), understanding what could go wrong (risk), and proving you meet your obligations (compliance). It has existed for decades in finance, security, and privacy. Generative AI does not replace this discipline; it stress-tests it.

A “360° view” means refusing to look at AI governance through a single lens. The same AI system is simultaneously a governance question (who is accountable?), a risk question (what is the likelihood and impact of harm?), a compliance question (which laws bind us?), a control question (what mechanisms reduce the risk?), a lifecycle question (does this hold from design through decommissioning?), and an assurance question (can we prove any of it to an auditor?). This course walks all six faces of that cube.

Here is Aurelia's posture in numbers — pulled directly from the database you'll query in Module 14:

The six faces of the cube

Governance — the “G”

Who is accountable, and by what authority?

• Distinguish governance from management, and policy from control.
• Read Aurelia's policy hierarchy and locate the single AI Governance Policy.
• Design an AI accountability model: board, owners, and the “three lines.”

Governance is the setting of intent

Governance answers three questions: What are we trying to achieve? Who decides? Who is answerable when it goes wrong? In GRC, governance is expressed primarily through policies — board-sanctioned statements of intent — which are then operationalized by controls (Module 08) and measured by risk (Module 02).

The distinction that trips people up: governance is not management. Management runs the AI system; governance constrains how management is allowed to run it, and holds them accountable. An AI Ethics Board that also builds the models has no independence and provides no governance.

Aurelia's policy hierarchy

Aurelia maintains 12 policies. Eleven are conventional and mostly Active. Exactly one governs AI — and its status is the first red flag in the whole dossier:

The AI accountability model

A defensible model assigns three kinds of role. Aurelia's data shows all three already exist as control owners — AI Ethics Board, ML Engineering, Data Governance Team — they are simply not yet empowered by an active policy.

The “three lines” model, applied to AI

• First line — the builders (ML Engineering) own and operate controls at the point of risk.
• Second line — risk & compliance (AI Ethics Board, Privacy) set policy, challenge, and monitor.
• Third line — independent internal audit provides assurance the other two lines actually work (Module 10).

Risk — the “R”

What could go wrong, how badly, and how likely?

• Score risk with a 5×5 likelihood–impact matrix and read a risk register.
• Name the AI-native risk categories traditional registers miss.
• Choose a treatment strategy: mitigate, accept, transfer, or avoid.

The anatomy of a risk

A risk is a potential future event with an uncertain outcome. We make it tractable by scoring two dimensions on a 1–5 scale and multiplying them:

Risk Score = Likelihood (1–5) × Impact (1–5)

The product (1–25) buckets into levels. Aurelia uses the conventional bands: Low 1–4 Medium 5–9 High 10–16 Critical 17–25. Scoring forces disagreement into the open: two people who both call a risk “bad” may be a full band apart on impact.

AI-native risk categories

A traditional register carries buckets like Cybersecurity, Financial, Operations, Third-Party. Aurelia's register adds three the pre-AI world didn't need — and they now dominate the top of the heatmap:

Notice these are outcome categories. Module 11 goes one level deeper into the mechanisms — hallucination, prompt injection, drift — that generate them.

Treatment: the four T's

• Treat / Mitigate — reduce likelihood or impact with a control. Aurelia mitigates all 28 tracked risk items this way; every AI mitigation is still Planned or In Progress.
• Tolerate / Accept — consciously bear it (see R8, “Regulatory Change,” status Accepted). Acceptance is a governance decision and must be signed by the risk owner.
• Transfer — shift it via insurance or contract. Note: you cannot contractually transfer regulatory liability for an AI system away from yourself.
• Terminate / Avoid — don't do the thing. The only valid response to an Unacceptable-risk AI system under the AI Act (Module 04).

Compliance — the “C”

Which obligations bind us, and can we prove it?

• Understand the compliance mapping — the join between a control and a legal requirement.
• Read Aurelia's compliance posture and see why AI frameworks score red.
• Grasp why evidence location is the difference between compliant and “trust me.”

Compliance is a join table

Compliance, mechanically, is a many-to-many relationship: one control can satisfy several legal requirements, and one requirement usually needs several controls. Aurelia stores 48 compliance mappings, each recording four things: the control, the framework, the specific requirement reference (e.g. Art. 14), and the evidence location — the pointer to the artifact that proves it.

That evidence pointer is the whole game. A control that is “Implemented” but whose mapping has evidence_location = null is, to an auditor, not compliant — it is an unsupported assertion.

The three-state compliance model

The EU AI Act

The world's first horizontal AI law

• Classify any AI system into the Act's four risk tiers.
• Enumerate the provider obligations for high-risk systems, by article.
• Place your organization on the enforcement timeline and penalty scale.

Regulation (EU) 2024/1689 — the AI Act — entered into force on 1 August 2024 and applies extraterritorially: it binds any provider or deployer whose AI output is used in the EU, regardless of where they sit. It is risk-based: obligations scale with the potential for harm, sorted into four tiers.

The four risk tiers

A separate track governs General-Purpose AI (GPAI) models — the foundation models behind most GenAI. Providers face transparency and copyright-summary duties (Art. 53); models posing systemic risk face additional evaluation and incident-reporting duties (Art. 55).

High-risk provider obligations — the checklist

This is the heart of the Act, and every row maps to a control in Aurelia's library. Cross-reference the “Aurelia status” column against Module 08 to see the remediation gap.

Timeline & penalties

Penalties (Art. 99) scale with the breach: up to €35M or 7% of global turnover for prohibited-practice violations; up to €15M or 3% for breaching most obligations (the tier Aurelia's high-risk gaps fall into); up to €7.5M or 1% for supplying incorrect information to authorities.

AICM — AI Compliance Management

Compliance as a lifecycle, not an event

• See how AICM operationalizes the AI Act's demands into a continuous management system.
• Map AICM's six requirement domains to Aurelia's controls.

Where the AI Act says what you must achieve, AICM (AI Compliance Management) is the framework for how you keep achieving it over time. Think of it as the ISO-style management-system layer for AI: it turns point-in-time obligations (pass a conformity assessment once) into standing processes (re-assess on every material change, monitor continuously, track the whole lifecycle).

Aurelia maps six AICM requirement domains — and every one is currently Non-compliant or Partial:

AIEU — Trustworthy AI in the EU

The ethics layer: from legal to legitimate

• Distinguish the ethical principles of trustworthy AI from the legal minimum.
• Connect AIEU principles to concrete controls and impact assessments.

The AI Act sets the legal floor. AIEU (AI Ethics in the EU), rooted in the EU's Ethics Guidelines for Trustworthy AI, raises the bar to what is legitimate — the practices that keep public trust even where the law is silent. Its requirements overlap the Act but are framed as principles rather than checkboxes.

How the Laws Interlock

AI never arrives alone

• See how GDPR, the AI Act, and sectoral law stack on a single AI system.
• Avoid the trap of governing AI in a silo.

A GenAI system rarely triggers one law. Aurelia's credit-scoring model simultaneously engages: the AI Act (it's high-risk Annex III), GDPR (it processes personal data and makes automated decisions — Art. 22 gives the applicant a right to human review), AIEU (fairness, explainability), and sector rules on consumer credit. These are not alternatives; they are layers, and they can conflict.

Controls

The mechanisms that make policy real

• Classify controls by function (preventive / detective / corrective) and measure effectiveness.
• Read the maturity gap between Aurelia's traditional and AI controls.
• Build the AI control set the AI Act actually requires.

Three control functions

A mature program balances all three. A control is only worth its evidence, so each also carries an effectiveness rating — Effective, Partially Effective, or Not Assessed — set by testing, not by opinion.

The maturity gap, in one chart

The AI control set — what “good” looks like

These twelve controls (all children of the AI Governance Policy) are the operational answer to Module 04's obligation checklist. This is the target-state library Aurelia must build:

The AI-GRC Lifecycle

Governance that travels with the model

• Walk an AI system through seven governance gates from intake to retirement.
• See which control fires at each gate and what evidence it produces.

The single biggest failure mode in AI governance is treating it as a launch checkpoint. Real governance is a relay — control ownership passes from gate to gate, each producing evidence the next depends on. This is the operating spine that ties every prior module together.

Audit & Assurance

Independent proof it actually works

• Understand the audit finding as the atomic unit of assurance.
• Track severity, status, ownership, and remediation deadlines.
• Read Aurelia's AI findings as a prioritized worklist.

Assurance is the third line's answer to a simple question: “You say the control works — prove it.” The output is a set of audit findings, each a discrete gap with a severity, an owner, and a remediation deadline. Findings convert vague worry into a tracked, dated backlog.

Aurelia carries 18 findings; the eight AI-related ones are the most severe and every one is still Open:

Read as a worklist, the pattern is unmistakable: the Critical findings all block deployment legality (conformity, registration, human override), while the High findings concern fairness and transparency. A risk-based remediation plan clears the Criticals first — they carry both the legal exposure and the earliest deadlines.

GenAI-Specific Risks

The failure modes traditional GRC never had to name

• Name the mechanisms that generate AI harm — the layer beneath the risk register.
• Match each to a control and a regulatory hook.

Modules 02–10 governed AI risk as outcomes (bias, non-compliance). This module goes underneath, to the mechanisms unique to generative and agentic systems. These are what your control set must actually defend against — and most are absent from a pre-AI register.

Cross-Cutting GenAI Risk Domains

The risks the regulations alone won't catch — and how to mitigate them

• Work through the six risk domains that apply to every generative-AI system, whatever its AI-Act tier.
• For each, learn the specific harm, how it shows up in GenAI, and the concrete controls that reduce it.
• See why a “are we AI-Act compliant?” checklist is necessary but never sufficient.

Part II covered the laws. But several of the most important GenAI risks are not really about a specific statute — they are baked into how generative AI works, and they cut across every system regardless of its risk tier. A program that only asks “does this pass the AI Act?” will sail straight past them. This module walks the six domains a practitioner must actively manage, and — crucially — pairs each with mitigations you can actually build, not just risks to worry about.

Domain 1Mitigating data-privacy concerns & protecting PII

The risk that personal data flows into — or leaks out of — a GenAI system.

Domain 2Alleviating biases

The risk that outputs systematically disadvantage some groups of people.

Generative models learn from vast amounts of human text and imagery, which carry society's historical prejudices. Left unchecked, the model reproduces — and can amplify — those patterns: stereotyped language, worse performance for some dialects or demographics, or subtly harsher treatment of certain groups in a decision-support setting.

Domain 3Managing open-source & model-supply-chain risks

The risk you inherit from the models and components you didn't build.

Almost no one trains a foundation model from scratch. You download an open-source model, or call a vendor's hosted one — and with it you inherit everything you can't see inside: how it was trained, on whose data, and whether it's safe.

Domain 4Contending with hallucinations

The risk of confident, fluent, and completely false output.

Domain 5Observing copyright & IP laws

The risk that AI ingests, reproduces, or leaks protected work — including your own.

Copyright touches GenAI from both directions: the model may have been trained on protected work, and it may generate output that reproduces someone's protected content. And there's a third, often-missed angle: your employees pasting your own trade secrets into a public model.

Domain 6Responsible use & societal impact

The risk that a system is legal but still harmful — to individuals, or to society.

The final domain is the widest: beyond any single law, does this system do right by the people it touches and the society it operates in? This is where governance becomes about legitimacy, not just compliance.

Two Case Studies, Start to Finish

Governing two real AI systems, step by step

• Follow two complete assessments — a RAG assistant and an autonomous agentic system — from the first description to a costed action plan.
• See how the same method produces a Limited-risk verdict for one and a High-risk one for the other, and understand exactly why.
• Learn the full path a governance assessor walks every time: understand → question → approach → frameworks → policies → controls → risks → assessment → compliance → gaps → action plan.

Everything so far has been the vocabulary and the rules. This module puts them to work. We take two AI systems a real company might actually try to build, and we assess each one the way a governance advisor would — slowly, out loud, explaining every judgment. If you have never done a risk-and-compliance assessment before, this is the module where it clicks: you will see that it is not magic or law-school knowledge, it is a disciplined sequence of sensible questions.

Case Study ① — A “RAG” assistant for insurance customer support

Part 1Understanding the use-case in full

A mid-sized insurance company based in the European Union wants to make its customer-support team faster and more consistent. Every day, support agents answer hundreds of questions — “Does my policy cover water damage?”, “Why was my claim only partly paid?”, “How do I add my new car?” Answering well means digging through dense policy documents and the customer's own file. It is slow, and different agents give different answers. The company wants an AI assistant to help.

Concretely, here is what the proposed system does, in order:

• A support agent is on a case. The customer's question comes in by phone or email.
• The assistant retrieves. It searches three sources: the company's product documentation, the exact policy wordings, and that specific customer's own policy record and claims history.
• The assistant drafts. Using only what it retrieved, it writes a suggested reply for the agent.
• A human reviews and edits. The support agent reads the draft, corrects it, and only then sends it. The AI never speaks to the customer directly.

Two facts shape the entire assessment. First, the retrieval step pulls in the customer's personal and financial data (their name, policy number, claims history). Second, the assistant is built on a third-party hosted LLM (large language model) API — meaning the text it works with, including that customer data, is sent out over the internet to an outside vendor's servers to be processed. The company wants this live in four months, serving EU customers only.

Part 2The questions to think through — and why each one matters

Before reaching for any regulation, a good assessor interrogates the design. Each question below narrows down what the system really is; the answer changes what rules apply and how much work is required. This questioning is the assessment starting — everything downstream flows from it.

• Does the system make a decision about a person, or only suggest text to a human who decides?

  Only suggests. A human agent reads, edits, and sends every reply; the AI has no authority of its own.
  Why it matters: This is the single most important question in the whole assessment. The law treats “an AI that decides your fate” very differently from “an AI that helps a person do their job faster.” The answer here is what keeps this system out of the strict, expensive “high-risk” category.
• Could a draft ever contain a number or recommendation that affects the customer's entitlement — a claim amount, a coverage decision, a price?

  No. It only explains and drafts; it never computes what someone is owed.
  Why it matters: This is the trap-door. Insurance pricing and claims decisions are explicitly high-risk under EU law. If a future version started suggesting payout figures, the system would silently fall through into the high-risk category and need a completely heavier compliance regime. Naming this now prevents an accidental, illegal upgrade later.
• Whose personal data touches the system, and does it leave the company's control?

  Customers' personal and financial data enters the retrieval context, and yes — it is sent to an external LLM vendor to be processed.
  Why it matters: The moment personal data leaves your walls, data-protection law (GDPR) becomes the dominant concern — often bigger than the AI-specific rules. This one answer relocates the centre of gravity of the whole assessment from “AI” to “privacy.”
• What is our lawful basis to use each customer's data this way, and do we actually have it for everyone?

  We rely on consent / legitimate interest — but roughly 12% of customer accounts are missing valid consent records.
  Why it matters: Under GDPR you may only process personal data if you have a lawful reason. Data for those 12% of customers cannot legally be fed into the assistant until that is fixed. A gap you can name is a gap you can close; a gap you ignore becomes a fine.
• Is the “human in the loop” genuine, or will it become a rubber stamp?

  It must be actively enforced. Agents under time pressure tend to skim and accept.
  Why it matters: The system's safety depends entirely on the human actually reviewing. This tendency to trust the machine is called automation bias, and it quietly turns a “safe” design into an unsafe one. If we can't prove the human really reviews, the whole “it only suggests” argument collapses.
• What happens if the assistant is confidently wrong?

  A hallucinated policy detail could be sent to a customer as fact, leading to a wrong decision, a complaint, or a regulatory problem under insurance conduct rules.
  Why it matters: RAG reduces made-up answers but does not remove them. Beginners often assume “it looked it up, so it must be right.” Planning for the wrong-but-confident case is what separates a toy from a governed system.
• Can we trust the vendor with our data — will they train their models on it, and where do they store it?

  Unknown until we have a contract. By default, some providers may retain or learn from submitted data.
  Why it matters: You inherit your vendor's risks. If the provider trains on your data or suffers a breach, your customers are exposed and you are accountable. This is why a specific data contract (below) is non-negotiable.
• Who owns this system and is answerable for its risks?

  To be assigned — the organization has an AI oversight function on paper but it is not yet empowered.
  Why it matters: Every risk needs a named owner or nothing gets fixed. “The company” is not an owner; a person is. Without clear ownership, a four-month project has no one to stop it launching unsafe.

Part 3How to approach it — the assessor's method

An assessment is not a form; it is a mindset followed by a sequence. The mindset for a beginner to absorb: govern the system by what it can actually do, not by what it is called. “RAG” and “AI” are labels; the rules attach to behaviour — does it decide, does it act, whose data does it touch. With that in mind, the method is eight steps, and the rest of this case study simply walks them:

Notice the shape: you move from understanding to obligations to a plan. A beginner who follows these eight steps in order will produce a defensible assessment of almost any AI system.

Part 4Which frameworks apply — and why this one is “Limited risk”

The EU AI Act sorts every AI system into four tiers by how much harm it could do: unacceptable (banned), high (heavy rules), limited (light rules), and minimal (none). To classify, you walk a short decision path. Is it a banned practice? No. Is it one of the “high-risk” uses the law lists (called Annex III) — things like credit scoring, hiring, or insurance pricing and claims decisions? This is the key test.

Here is the full set of frameworks that actually apply, explained plainly:

Part 5What policies to create — the rules the company sets for itself

A policy is an internal rule the organization writes for itself, usually to satisfy a law or prevent a risk. It states what must be true; the controls in Part 6 make it true. For this system, most policies already exist for the traditional business and simply need extending to AI — except the foundational one, which was never finalized.

Part 6How those policies become controls — the mechanisms that enforce them

A policy on its own is a promise. A control is the concrete mechanism that keeps the promise — the thing you can point at, switch on, and test. Each policy above turns into one or more controls. Read this as “the rule, and the machine that enforces it”:

Part 7What the risks are

A risk is a bad thing that could happen. Here are the ten this system carries, in plain language — notice they cluster around data and accuracy, not the AI Act:

Part 8How to do the risk assessment — turning worry into a number

To compare risks fairly you score them. The standard way: rate Likelihood (how probable, 1–5) and Impact (how bad if it happens, 1–5) and multiply. The result (1–25) sorts into Low, Medium, High, Critical. Scoring isn't about mathematical precision — it's a forcing function that makes a team say out loud how worried they really are, so the scary-but-boring risks get funded alongside the flashy ones. Two worked examples:

Part 9Compliance — proving it, not just doing it

Here is the hardest truth in the whole discipline: compliance is not what you do — it's what you can prove. For every legal requirement you need three things lined up: the requirement, a control that satisfies it, and evidence — the document you could hand an inspector. A perfect safeguard with no evidence counts as non-compliant. Think of evidence as the receipt.

Part 10Review — finding the gaps

A gap is simply a required control that is missing or ineffective. You find gaps by laying the “what we need” list next to the “what we have” list and circling the differences. Here, sorting them by urgency, three tiers appear:

Part 11The action plan — closing the gaps in the right order

Finally, turn the gaps into a sequenced plan. The rule of sequencing: do the launch-blocking items first — finishing a “nice to have” before a “must have” is wasted effort. We sort into three buckets:

Case Study ② — An autonomous “agentic” system for payment disputes

Part 1Understanding the use-case in full

A financial-technology (“fintech”) company in the EU processes payments for online shoppers. When a customer disputes a charge — “I never received this order,” “I was double-billed,” “this looks fraudulent” — a human analyst currently investigates and, if the complaint is valid, issues a refund. It's slow and expensive, and the volume is growing. The company wants an AI to handle the whole process by itself.

Here is exactly what the proposed system does:

• It reads the incoming dispute (an email or web form from the customer).
• It investigates on its own — querying the company's transaction and account systems to gather evidence.
• It decides whether to approve or reject the refund.
• For refunds up to €500, it executes the refund itself — it calls the payment system's software interface (its “API”) and moves the money, with no human review.
• Only above €500, or on unusual patterns, does it escalate to a human analyst.

The defining trait: this system does not advise — it acts, and it moves real money. It handles customers' personal and financial data, serves EU customers, and the company wants it live in six months.

Part 2The questions to think through — and why each one matters

• Does it make a consequential decision about a person, on its own?

  Yes. It approves or denies refunds and, below €500, carries them out with no human involved.
  Why it matters: An automated decision that affects someone's money is exactly what the strictest rules exist for. This answer alone signals we are likely in “high-risk” territory — the opposite of Case ①.
• Does it act on the real world, or only advise?

  It acts. It calls live payment systems to move money.
  Why it matters: This is the heart of “agentic,” and it changes everything. An AI that only writes text can, at worst, be wrong. An AI that can move money can, at worst, cause immediate, irreversible financial loss — including if someone tricks it. Every other risk in this case is amplified by this one fact.
• Does it profile people — analyze their behaviour to judge them?

  Yes — it weighs a customer's payment history and dispute patterns.
  Why it matters: Profiling is treated with special caution in EU law, and it automatically removes the “this is just a simple helper task” exemption that saved Case ①. Once you profile, the easy exits close.
• Where, exactly, is the human oversight?

  Only above €500. Below that threshold there is none at all.
  Why it matters: This is the central defect the entire assessment will circle back to. High-risk AI law requires that a human can always understand, override, and stop the system. A design that deliberately removes the human for a whole class of decisions is, by construction, breaking that rule.
• What is the blast radius if the system is manipulated or malfunctions?

  Because it can move money, a single successful manipulation could drain funds or wrongly deny thousands of legitimate customers.
  Why it matters: You must size the worst case before you build. Here the worst case is direct financial and legal catastrophe — which justifies heavy, expensive safeguards that would be overkill for a drafting tool.
• Which other laws govern automated money decisions?

  Data-protection law's rule on automated decisions (GDPR Art. 22), and payment-services law (PSD2/PSD3) covering refund rights, deadlines, and the right to a clear reason for a refusal.

  Why it matters: Just like Case ①, the AI Act is not the only law in the room — but here the extra laws have real teeth about refusing people's money. The AI could satisfy the AI Act and still break payment law by wrongly denying a valid refund.
• Can the system explain its decisions to a customer and a regulator?

  Not as designed — there's no logging or explanation capability yet.
  Why it matters: When you deny someone money, they have a right to know why, and you must be able to reconstruct what happened. “The AI decided” is not an acceptable answer to a regulator. Without records, you cannot defend a single decision.

Part 3How to approach it — same method, far higher stakes

The eight-step method is identical to Case ① — understand, question, classify, map the law, set policies and controls, find and score risks, check the proof, review and plan. What changes is the weight of every step, because the answer to “what can it actually do?” is now “decide and move money by itself.” When a system acts autonomously on something valuable, the assessor's default flips from “how do we enable this?” to “what must be true before we dare let it act unsupervised?”

Part 4Which frameworks apply — and why this one is “High risk”

We walk the same classification path — but this time it lands in the strict tier. The EU AI Act names certain uses as automatically high-risk (its Annex III list). This system hits two of them at once.

Being high-risk triggers the AI Act's full obligation set — the “complete package.” In plain terms:

Part 5What policies to create

Because this system can act, its policies are heavier and one of them is the crux of the whole project.

Part 6How those policies become controls

Part 7What the risks are

Ten risks, and the top ones flow directly from the fact that the system acts on money by itself:

Part 8How to do the risk assessment

Same Likelihood × Impact scoring — but watch how “the harm is designed in” drives likelihood to the maximum:

Part 9Compliance — proving it

The same requirement → control → evidence discipline, for the heavy high-risk obligations:

Part 10Review — finding the gaps

Part 11The action plan

Side-by-side — why one is Limited and the other High

Two systems, one method, opposite verdicts. Reading the differences across is the fastest way to internalize what actually drives an AI's risk level:

Practice It Yourself

Five exercises to make the method stick

• Practice each step of the assessment method on fresh, bite-sized examples.
• Build the reflexes: classify a system, ask the right questions, turn a policy into controls, score a risk, and sequence a fix.
• Check yourself against a worked answer after every exercise.

Reading about a method is not the same as being able to do it. These are pen-and-paper exercises — you need nothing but this page and a few minutes of thinking. Each one isolates a single skill from the two case studies, gives you a task, and then lets you check your reasoning against a worked answer. Try each one before you open the answer; the struggle is where the learning happens.

Lab AClassify it yourself

For each system below, walk the tier decision from Module 13: is it banned? one of the high-risk uses (credit, hiring, insurance pricing/claims, essential services, biometrics)? a limited-risk case (it talks to people or generates content)? or minimal? Assign a tier and, more importantly, say why.

1. An AI that filters spam out of employees' email inboxes.
2. A chatbot on a shopping website that answers product questions and tells users it's an AI.
3. An AI that screens job applications for an EU employer and auto-rejects anyone below a score.
4. An AI that recommends films to stream based on what you've watched.
5. An AI that drafts reply suggestions for bank support agents, who edit and send them.

Lab BAsk the right questions

Scenario: A hospital wants an AI that reads a patient's history and suggests to the doctor which of three treatment options to consider. The doctor makes every final decision.

Write down five questions you would ask before assessing this system — and for each, one sentence on why it matters.

Lab CTurn a policy into controls

A company writes this policy: “No customer personal data may be sent to an external AI provider without protecting it.” That's the rule. Now list the controls — the concrete mechanisms — that would actually make it true.

Lab DScore the risks

For the hiring-screening AI from Lab A (#3), score these three risks using Likelihood × Impact (1–5 each). Justify each number, then place it in a band (Low 1–5, Medium 6–11, High 12–19, Critical 20–25).

1. The AI systematically rejects more women than men because of biased training data.
2. A hacker steals the candidate database.
3. A typo in the rejection email template.

Lab EFind the gaps and sequence the fix

Scenario: A company is two months from launching the hiring-screening AI. Today it has: a job-applicant privacy notice ✅, encrypted storage ✅. It does not have: any bias testing, a human review of rejections, a record of why each candidate was rejected, or an approved AI policy.

Turn the missing items into a plan: which are must-have before launch, which are should-have soon after, and why in that order?

CapstoneRun the whole method

Put it all together on a fresh system: “An AI for an EU lender that automatically approves or declines small top-up loans up to €2,000 for existing customers, and issues the approved funds itself. Larger requests go to a human.”

Walk all eight steps: understand → question → classify → map the law → policies & controls → risks → compliance → gaps & plan. Write a short assessment, then compare.

Reference & Glossary

Keep this open while you work

The 10 frameworks in the dossier

Glossary

The 360 in one sentence per face

• Governance — ratify the policy so someone can say no.
• Risk — score it so the danger is legible.
• Compliance — map obligation to control to evidence.
• Controls — prevent, detect, correct; then test.
• Lifecycle — gate it from intake to retirement.
• Assurance — prove it independently, on a dated backlog.