0.1 What AI Governance Decides

Introduction

AI governance is the set of decisions an organization takes about the AI systems it builds, buys and uses, together with the records that show each decision was taken, by whom and on what grounds. This lesson sets out what those decisions are, who asks to see them, and why this course teaches them from international standards rather than from any one country's law.

It also says what the course is not. Governance decides whether and how a system is used and who answers for it; it does not build models, give legal advice, or replace the people who run the systems day to day.

Most definitions of AI governance list activities: setting policy, assessing risk, monitoring, reporting. The list is accurate and hard to act on. A more useful way to see the subject is as a series of decisions about each system, every one of which someone takes and someone else can later check.

A system arrives because somebody built it, bought it, or switched on a feature in software the organization already pays for. Someone decides whether it is an AI system the organization governs, and if so it is recorded in an inventory.

Someone decides how risky it is, which sets how much assessment it needs. Someone chooses the controls that bring the risk within what the organization accepts. Someone approves its release. Then it runs, and it is decided on again when it changes or when its review date arrives.

Each of those steps can be done well or badly, but the commonest failure is that a step is not taken at all. A system is in use before anyone decided it was in scope.

Controls exist but nobody chose them for this system. A release was never approved because the tool was already licensed. Governance in this course means that every one of those decisions has an owner and a record.

That framing matters because it is what every reviewer looks for. An auditor testing an AI management system against ISO/IEC 42001 wants evidence that decisions were made as the organization's own rules require. A board member asking whether AI is under control wants to know who decided what. Neither is satisfied by a policy alone, however good, if nothing shows the policy was followed for the systems actually in use.

The return arrow is the part most programs leave out. A system approved last year may have a new model behind it, a new use, or a new group of people affected by it, and the original decision no longer covers it. Governance that decides once and never again has governed a moment, not a system.

The decisions in the previous section reduce to five questions. They are asked of every AI system, whether it is a model a data science team trained, a product the organization bought, or a feature that appeared in an existing tool after an update.

Is it in scope? The first decision is whether the system is an AI system under the definition the organization has adopted, and whether it is recorded. Everything else depends on it, because a system outside the inventory receives none of the controls that follow. Module 1 teaches the definition and Module 2 the inventory.

What role does the organization hold? An organization that builds a model holds different responsibilities from one that offers it to others or one that only uses it. The role decides which controls and documents are the organization's to provide and which it should ask a supplier for. Module 1 teaches the role decision.

How much risk does it carry? A tier sorts systems so that the assessment effort goes where the potential harm is. A spell checker and a system that screens job applicants are both AI and do not deserve the same scrutiny. Modules 2, 3 and 5 teach tiering and assessment.

Which controls apply? The controls are chosen from a reference set, mostly ISO/IEC 42001 Annex A, with a reason recorded for each one included or excluded. Modules 4 and 6 to 8 cover the controls for the management system, the lifecycle, generative AI and suppliers.

Who answers for it? Every system needs a named owner who decides about it and a record of the decisions taken. Modules 1 and 10 cover accountability and the evidence that shows it working.

The questions are deliberately plain. They are what a board member, a regulator or a customer will ask in their own words, and an organization that can answer all five for each of its systems, with records, is governing its AI whatever framework it uses.

AI governance has several audiences, and each asks a different question. It is worth knowing them from the start, because they decide what the records have to show.

The governing body asks whether the organization's use of AI is within the risk it is prepared to accept, and whether the people running it are accountable. Customers, especially business customers, increasingly ask suppliers which AI systems touch their data and how those systems are controlled; the question arrives in security questionnaires and contract negotiations.

Regulators ask which obligations apply and whether they are met. Auditors, internal or external, ask to see evidence that the organization follows its own rules. Insurers have started to ask how AI risk is controlled before they price a policy. Staff ask which tools they may use, for what, and with what data.

Each audience wants something slightly different from the same material. The board wants a summary against the appetite, the auditor wants the underlying records, the customer wants an answer specific to their data, and staff want a short rule they can follow.

None of them is served by a document written for its own sake. All of them are served by an inventory of systems, with decisions, owners and evidence attached to each entry.

That is why this course keeps returning to the record. A well-kept record of what was decided about each system can be summarized for a board, sampled by an auditor, filtered for a customer and turned into an acceptable-use rule for staff. A program that produces reports without records has to produce each report from scratch, and the reports will disagree with each other.

The audiences also explain why governance cannot stay inside one team. Answering customers needs the sales and legal teams; answering staff needs IT and human resources; answering the board needs the executives who own the systems. A governance lead coordinates, but the decisions belong to the people who own each system, which Module 1 sets out as the chain of accountability.

There are two ways to build an AI governance program. One starts from a law, works out what it requires, and builds controls to meet it. The other starts from an international standard, builds a control set that covers the risks AI systems carry, and then maps each law onto that control set. This course takes the second way.

The reason is how quickly the laws are moving. In 2026 alone, the European Union's Digital Omnibus deferred the dates on which the AI Act's obligations for high-risk systems apply, and the state of Colorado repealed its AI Act before it took effect and replaced it with a narrower law on automated decision-making.

A program built around either law as it stood at the start of the year would have needed rebuilding by the summer. A program built on a standards-based control set needed its mappings updated.

The standards move more slowly and apply everywhere. ISO/IEC 42001, published in December 2023, specifies an AI management system any organization in any country can implement and have certified.

The NIST AI Risk Management Framework, published in January 2023, gives a risk method organized in four functions that any organization can adopt. Neither depends on where the organization operates, and both were written to be used alongside the laws rather than instead of them.

Laws still matter, and Module 9 teaches how to read one, turn its articles into obligations, map them onto the control set and find the gaps. It uses the EU AI Act and US state law as worked examples, dated, with the warning that both will have moved by the time a student reads them.

What the course will not do is make any one law the frame of a lesson, because the student's organization may be subject to a different law, to several, or to one not yet written.

For a student this has a practical consequence. The work done in Modules 1 to 8 does not need redoing when a new law arrives. The inventory, the tiers, the assessments and the controls stay; a new mapping is added beside them.

AI governance borders several other disciplines, and confusing them with it is the quickest way to build a program that looks busy and decides little.

Governance is not building or running models. Data scientists and engineers train, tune, test and deploy models; governance decides whether they may, on what terms, and checks that the agreed controls were applied. Module 6 governs those activities without teaching them, and the course assumes no programming or machine learning knowledge.

It is not legal advice. Lawyers decide what a law requires of a particular organization in a particular situation. Governance builds the control set and the records that let the organization meet whatever the lawyers conclude, and Module 9 teaches how to structure that work, not how to interpret any one statute.

It is not privacy compliance, though the two meet often. Where an AI system processes personal data, the data protection impact assessment required by privacy law sits beside the AI impact assessment, and the course says where the two connect. It does not teach privacy law.

It is not attacking AI systems. Module 7 covers prompt injection, data leakage and excessive agency as risks with controls, which is what a governance practitioner needs. The techniques for exploiting them belong to a different discipline and a different course.

And it is not a set of values. Principles have a place, as a short opening section of a charter, but only when each is tied to a decision someone owns. A program that publishes principles and stops has done the easiest part of the work and none of the rest.

Drawing these edges does not mean governance works alone. Every one of these neighbors has a part in the decisions, and the governance lead's job is largely to make sure the right one is asked at the right point.

Most organizations do not begin governing AI before they use it. They begin when someone notices how much they already use: a board question, a customer questionnaire, an incident, a new law. By then AI has arrived through several doors at once.

A sales team at a 300-person distributor switches on the AI meeting summary
feature in its collaboration suite. The feature is in the license the company
already pays for. IT turned it on for the sales group after the sales director
asked. Nobody else was told. Summaries of customer calls go into the CRM.

None of them has been answered in a way anyone could check. The feature is an
AI system in use (scope), the company is its deployer (role), it handles customer
conversations (risk), no control was chosen, and the only person who decided was
the sales director, with no record. Use came first and governance has not started.

The commonest door is software the organization already has. Office suites, collaboration platforms, customer relationship systems, service desk tools and development environments now include AI features, often switched on by an update or by an administrator with no wider decision.

The second door is tools staff choose for themselves, from a free chatbot to a browser extension, often with no purchase involved. The third is the formal one: a project that builds or buys a system deliberately, with a business case and a budget.

Governance that only watches the third door misses most of what is in use. That is why the first practical step in almost every program is finding what exists, which Module 2 teaches, before writing policies about what should exist. An inventory of fifteen systems with an owner for each is a better starting position than a policy that covers systems nobody has listed.

Starting from what is in use also changes the tone of the work. Teams that switched on a feature without asking were usually not hiding anything; nobody had told them a decision was needed. A program that begins by finding systems, recording them and assigning owners gets cooperation. One that begins by declaring past use non-compliant teaches teams to stop mentioning what they use.

The predict block above is typical. The feature was paid for, was switched on by the right administrator, and is useful. What is missing is the five decisions, and the fix is to take them now: record the system, decide the role and tier, check the controls that matter for customer conversations, and name the owner.

Every lesson in this course ends with a practice task that produces a governance record, and the records accumulate into one file. By the end of Module 10 the file holds everything an auditor, a board or a regulator would ask to see.

Modules 1 and 2 produce the foundation: a definition of what counts as an AI system, a role decision for each system, an inventory entry and a risk tier. Module 3 adds a working profile against the NIST AI RMF, and Module 4 the scope of an AI management system and a Statement of Applicability against ISO/IEC 42001 Annex A, the document that records which controls apply and why.

Modules 5 to 8 apply the method across the lifecycle. Module 5 produces a risk assessment and an impact assessment. Module 6 adds controls for data, models, change and monitoring. Module 7 builds a control set for generative AI and agents, including an acceptable-use policy staff can follow. Module 8 produces an assessment of an AI supplier.

Module 9 adds a law-to-control mapping, and Module 10 an audit test and a report to a governing body. Together these are the records that show governance working, and they are the material Module 10 uses to show certification readiness.

If you work in an organization, every one of these is for your own systems, and the file is something you can use at work. If you do not, each practice task gives a short scenario to work instead, and the file you build is a complete example you can adapt later. Lesson 0.4 explains how practice works in detail.

The file is cumulative on purpose. A role decision made in Module 1 is used in Module 4 to decide which controls are the organization's to apply, and again in Module 8 to decide what to ask a supplier. Keeping the records together means each module builds on decisions already made rather than repeating them.

A common reaction to AI governance is that it is for large organizations: banks with model risk teams, hospitals with ethics committees, software vendors with compliance departments. The five questions say otherwise. They apply to a twelve-person firm using one AI writing assistant exactly as they apply to a multinational, and what changes with size is how much paperwork the answers need.

At a small firm the inventory is a list, the role decision is a word, the risk tier is a judgment the managing partner makes in a minute, the control is a rule everyone can remember, and the owner is a named person. All five answers fit in one row. That row is governance: it can be checked, it says who decided, and it gives a date to look again.

At a large organization the same answers need more. The inventory holds hundreds of entries, the risk tier follows written criteria so that different reviewers reach the same tier, the controls are chosen from a reference set with a justification for each, and decisions above a threshold go to a committee. The questions have not changed; the organization needs more structure to answer them consistently across many people.

The course teaches both versions side by side, because a student may work at either end or move between them. Where a lesson shows a full control, it also shows the smallest version that still answers the question, and says what must not be dropped at any size: a named owner and a record of each decision.

Proportion cuts both ways. A small organization that copies a bank's framework produces documents nobody reads. A large one that governs with a spreadsheet and goodwill cannot show a regulator or an auditor that decisions are consistent.

The right amount is the least that answers the five questions reliably for the systems the organization actually has. That amount grows as the organization's use of AI grows, and the program should grow with it.

AI governance is the set of decisions an organization takes about each AI system, and the records that show them: whether it is in scope, what role the organization holds, how much risk it carries, which controls apply and who answers for it.

The course teaches those decisions from ISO/IEC 42001 and the NIST AI RMF, treats laws as overlays mapped onto that control set, and builds one governance file across ten modules. The next lesson introduces the standards themselves.

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