0.3 Reading the Course for Your Organization

Introduction

This course has no case company. It teaches AI governance as a subject, with short examples that change from lesson to lesson, so that what you learn holds for whatever organization you work in. That puts one job on you: reading each lesson for your own organization.

This lesson shows how. It sets out the four things that change the right answer in AI governance (whether you build or buy, your size and maturity, your sector, and where you operate), shows what an organization usually has already, and suggests which modules to lean on for the work you do.

Many courses teach through one fictional organization, followed from the first lesson to the last. It makes for a tidy story and a weaker course, because every lesson then teaches that organization's choices: its size, its sector, its suppliers and its laws. A student from a different kind of organization has to work out which parts still apply.

This course takes the other approach. Each lesson's examples are short and self-contained, and they rotate across organization types: a bank in one lesson, a hospital in the next, a software company, a retailer, a local government body, a small consultancy. No example depends on another lesson's, and none recurs often enough to become the course's default.

The rotation is deliberate in another way. Where the right answer depends on the organization, a lesson says what it depends on and shows how the answer changes, rather than giving one answer and leaving the reader to adapt it. Modules 2 to 10 each close with a section on what changes when the organization differs, organized around the same four variables this lesson introduces.

What stays constant is the method. Every example applies the same five questions from lesson 0.1, produces the same kinds of record, and uses the same standards. A student who has seen the method applied to a bank's credit model and a council's case routing tool can apply it to their own systems, which is the point.

It also means you should not look for your organization in the examples. You will rarely find it exactly. Look instead for the variable that matches your situation, whether you build or buy, how large you are, which sector rules apply and which laws, and read the lesson's answer for that variable.

Where two variables apply at once, such as a small firm in a regulated sector, read both answers: they usually combine rather than conflict, the sector rule deciding what a control must achieve and the size deciding how much structure it needs.

The single biggest difference between organizations is whether they build AI systems, offer them to others, or only use systems other people built. Most organizations do some of each, for different systems.

A model maker trains a general model, often a large language model, and makes it available to others. A provider builds a system on that model, or on its own, and offers it to customers.

Your organization may do either, or it may use systems others provide, and it may change position for one system by fine-tuning a model, putting its own name on a product or offering a tool it built for itself to other companies in its group. Module 1 taught how to decide the role for each system.

The role decides which controls are yours. An organization that trains a model holds the controls for training data, testing and documentation. One that buys a system holds the controls for choosing the supplier well, using the system for its intended purpose, monitoring it in use and obtaining the documentation the supplier holds. Both are governing; they hold different parts of the same control set.

This is why the course keeps returning to the role decision. In Module 4 it decides which Annex A controls are applied by the organization and which are obtained from a supplier. In Module 6 it decides whether lifecycle controls are run or evidenced. In Module 8 it decides what to ask a supplier and what to put in the contract.

Read every lesson with the question: for this system, do we build, offer or use? A lesson about bias testing, for example, asks a builder to run the tests and a buyer to obtain and judge the supplier's results.

The judgment is the same; who does the testing changes. Keep a note of the systems where your organization holds more than one role, because those are where controls are most often left to the other party by both sides.

Size changes how much structure a program needs. A large organization with hundreds of AI systems needs written criteria so that different reviewers reach the same decision, committees for the decisions above a threshold, and tooling to keep the inventory current. A small one can do the same work in a spreadsheet, with one person deciding and a second checking once a year.

Maturity is a separate question from size. A large organization can be at the first stage, with AI in use everywhere and nothing listed; a small one can be at the fourth, with a short inventory, an owner for each entry and a risk tier for each.

The stages run in the same order whatever the size, because each depends on the one before: nothing can be owned until it is listed, and nothing can be assessed until somebody owns it.

The course teaches the full version of each control beside the smallest version that still works, and it says what must not be dropped at any size. In almost every case that is a named owner for each decision and a record that it was taken. A program that keeps those two, however lightly, can grow into the full version; one that drops them has nothing to grow from.

Finding your stage tells you where to put effort first. An organization at the first stage gets the most from Modules 1 and 2, because until systems are listed and owned, risk assessment and controls have nothing to attach to. An organization at the fourth stage gets the most from Modules 4 and 10, because its next step is a management system that can be audited.

Be honest about the stage. An inventory last updated a year ago, or one that lists projects but not the AI features switched on inside existing software, is closer to the first stage than the second. Module 2 shows how to find what an inventory is missing.

Regulated sectors add rules for some AI systems, and they are often detailed. They do not change what governance is. A bank, a hospital and a council still need an inventory, a risk method, a control set and evidence; the sector adds requirements on top for particular systems.

In banking, supervisors have long expected banks to manage model risk: to validate models independently, document them and monitor their performance. Many AI systems in a bank fall under those expectations, and the bank's model risk function is often the natural home for the lifecycle controls in Module 6.

Where AI software meets the definition of a medical device, device regulation brings requirements for clinical evaluation, quality management and post-market monitoring. Public bodies carry duties of transparency and equality that shape how they assess and explain AI used in decisions about people.

The course does not teach any sector's rules. It teaches where they attach. A sector rule is treated like a law in Module 9: read it, turn it into obligations, map each obligation onto the control set, and close the gaps. Usually the result is that a few controls become stricter for the systems the rule covers, and the rest of the program is unchanged.

Two cautions apply. First, a sector function that already governs models, such as a bank's model risk team, should not be duplicated. The AI governance program should use its work and fill the gaps around it, typically the AI systems it does not cover, such as bought tools and generative AI.

Second, sector rules rarely cover everything. A hospital's device rules apply to clinical software, not to the AI in its scheduling system or its office suite, which still need governing.

The sector function and the AI governance program should agree, in writing, which systems each covers, so that nothing falls between them and nothing is assessed twice under different rules. That agreement is a short document, and the inventory can carry a field saying which function governs each entry.

An organization operating in several countries, or selling into them, may be subject to several AI laws at once, and they will not agree with each other. The course handles all of them the same way.

The method has five steps. Identify which laws apply and record why, because applicability often turns on facts such as where the system's output is used. Read the articles themselves rather than summaries, because the exceptions and definitions are in the text.

Turn each article into obligations, one testable duty at a time. Map each obligation onto the control set the organization already has. Where an obligation maps to nothing, add or change a control.

The method's value shows with the second law. An organization subject to the EU AI Act and to a US state law on automated decisions will find that many obligations map onto the same controls: an inventory, a risk assessment, an impact assessment, human oversight, records. The second mapping is mostly a matter of pointing to controls the first one already justified, plus a handful of additions.

Laws appear in the course only through this method. Module 9 uses the EU AI Act and US state law as dated worked examples, and lessons elsewhere mention a law only where it uses a term differently from the standards, as Module 1 did with the EU AI Act's deployer.

When reading the course, keep a short list of the laws your organization is subject to and the systems each touches.

You will not need it until Module 9, but noticing as you go which controls a law is likely to strengthen makes the mapping faster when you get there. It also shows early whether a law affects many systems or only a few, which decides whether it deserves a full mapping exercise or a short note against the handful of systems it touches.

Most organizations find that one or two laws drive most of the work, and the rest add little beyond what the first mapping already covers.

Very few organizations start AI governance from nothing. Most have a management system, a risk process, privacy assessments and supplier reviews, and each of them already does part of the work.

An organization certified to ISO/IEC 27001 has a scope, a document control procedure, internal audit, management review and corrective action. ISO/IEC 42001 uses the same high-level structure, so these can be extended to cover AI rather than built twice. Many organizations run the two as one integrated system with a shared audit program.

A risk register and its method can take AI risks, with the additions ISO/IEC 23894 and the AI RMF describe for risks that come from probabilistic output, drift and opacity. The organization's risk appetite can be extended with statements about AI uses, as Module 1 showed.

Privacy assessments already ask what personal data a system uses and how individuals could be affected. The AI impact assessment asks a wider question, covering people affected whether or not their personal data is involved, and the two can share fields and reviewers. Supplier reviews already ask security questions; Module 8 adds AI questions to the same process rather than starting a new one.

What is genuinely new is smaller than it first appears: an AI inventory, because no existing register lists AI systems with the facts governance needs; an AI impact assessment; and the controls specific to AI, such as data quality for training, model documentation, human oversight and limits on what agents may do.

Starting from existing assets also helps adoption.

People who already run the risk register or the supplier reviews are more likely to support AI governance that extends their process than one that duplicates it. It also saves money: a second certification audit run alongside an existing one usually costs far less than a separate program, and an auditor who already knows the organization's document control and corrective action process spends the time on what is new.

Ask the owners of each existing process early, before designing anything, what they would need to change to cover AI.

The course is written for several kinds of practitioner, and each will find some modules closer to their daily work. The whole course applies to all of them, but it helps to know where to slow down.

A GRC or risk practitioner usually owns the program and needs every module, with the most weight on the inventory, the frameworks and the assessments. Modules 2 to 5 are where most of a working week goes once a program is running.

A security manager or architect brings controls that already exist for software and suppliers. The new material is in what changes for AI: prompt injection and excessive agency in Module 7, the AI questions for suppliers in Module 8, and the monitoring and change control of models in Module 6.

A privacy or data protection specialist will find the impact assessment closest to existing work, and the data governance in Module 6 a natural extension of it. The course marks where the AI impact assessment and the data protection assessment meet and where they differ.

An internal auditor needs to know what a management system must contain and how to test it, which Modules 4 and 10 cover, and who should be accountable, which Module 1 set out. A consultant needs the proportionate versions throughout, since clients range from a five-person firm to a multinational.

None of this is a reason to skip modules. Governance is one chain of decisions, and the parts nearest your own work make most sense once the parts around them are understood. A security manager who reads only Module 7 will choose sound controls for prompt injection and then find nobody owns the systems they apply to, because the inventory and the role decisions were someone else's module.

An auditor who reads only Module 10 will test controls without knowing why they were chosen. Read the whole course once in order; come back to the modules nearest your work when you need them, with the rest of the chain already in view.

Before Module 1, it helps to write down the four facts that decide how each lesson applies to you. They take a few minutes, and you will use them in every practice task.

A 40-person architecture practice builds no AI. It uses an office suite with an
AI assistant, a drawing tool that generates design options, and a chatbot some
staff pay for themselves. Its owner asks which modules she can skip.

None can be skipped, but three get lighter. Module 6 is mostly about asking
suppliers for lifecycle evidence rather than producing it. Module 9 may need one
or two law mappings. Module 10 needs a short report, not a certification audit.
Modules 2, 7 and 8 get heavier: inventory, generative AI and suppliers.

Build or buy. List the main ways AI reaches your organization: systems built in house, products bought, features inside existing software, tools staff use on their own, and any systems you offer to customers or other group companies. Note which is most common.

Size and stage. Note roughly how many people work in the organization, how many AI systems you think are in use, and which of the five stages in section 3 you are at. A rough number is fine, and the gap between the number you guess and the number Module 2 finds is itself useful.

Sector. Note any sector rules that might apply to some of your AI systems, and any function, such as model risk or clinical safety, that already governs some of them.

Where you operate. List the countries you operate in or sell into, and any AI laws you already know apply. Do not research the laws yet; Module 9 does that.

Add one more line: which management systems, risk processes, privacy assessments and supplier reviews already exist, and who runs them. That tells you what the program can extend.

The profile is a working note, not a governance record, and it will change as you go. Its job is to let you read each lesson's "what changes" section and know immediately which line applies to you. Keep it with the governance file you begin in the next lesson's practice.

Revisit it at the end of Module 2, when the inventory has replaced the guessed count with a real one, and again before Module 9, when the list of laws matters. Each time, note what changed and why, because the changes show how the organization's use of AI is moving, which is information a governing body will want.

The course teaches AI governance without a case company, so you read each lesson for your own organization. Four variables change the answer: whether you build or buy, your size and maturity, your sector, and where you operate.

Most organizations already have a management system, a risk process, privacy assessments and supplier reviews to extend, and the genuinely new parts are the inventory, the impact assessment and the AI-specific controls. The next lesson explains how practice works.

Versions this lesson relies on: ISO/IEC 42001:2023; NIST AI 100-1, AI RMF 1.0 (January 2023); ISO/IEC 23894:2023; EU AI Act, Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744 (status as of 5 November 2026).