0.4 How Practice Works

Introduction

Every lesson in this course ends with practice, and the practice is the part of the course that turns reading into ability. This lesson explains how it works: what a practice task produces, how to do it with or without an organization of your own, where to keep the records, how the practice tool works, and how to check your own work.

The short version is that every practice task produces a governance record, the kind of record an organization would actually keep, and the records together make one governance file. The rest of the lesson explains how to get the most from that.

Most course exercises produce an answer that is checked and then forgotten. The practice tasks in this course produce governance records: a definition clause, an inventory entry, a role decision, a risk tier, a Statement of Applicability line, an impact assessment, a law-to-control mapping, an audit test. Each is something a working AI governance program needs and keeps.

Each practice card has a title saying what you will produce, a short list of steps, and an outcome line naming the record you should have at the end. The steps are the method the lesson taught, in the order it is applied. They are short because the lesson has already explained them; the card is a checklist for applying them, not a second explanation.

Work through the steps on one system at a time. Several practice tasks ask for two or three systems, deliberately chosen to differ, because the point of a method is that it produces different answers for different systems and the same answer from different people. Doing it once teaches the steps; doing it on contrasting systems teaches the judgment.

Some cards ask you to decide something, some to write something, and some to check something already written. All of them end in a record you could hand to someone else. If you finish a card and have nothing you could hand over, go back to the outcome line and compare.

The records build on each other. A role decision from Module 1 is used again in Module 4 to decide which controls are yours, and again in Module 8 to decide what to ask a supplier. That is why the course asks you to keep everything in one place: later practice tasks assume you can find what earlier ones produced.

Practice is also where gaps in understanding show. If a step on a card is unclear when you try to apply it, the lesson section behind that step is the one to reread, and doing so with a real system in mind usually resolves it faster than rereading in the abstract.

The course is written for practitioners who can apply it to an organization they work in. Not everyone can: some students are between roles, some work for organizations that would not welcome practice records about their systems, and some are consultants whose clients' systems are not theirs to describe.

Every practice card therefore carries a fallback: a short scenario, printed under the steps, describing an organization and its AI systems in enough detail to do the task. The scenarios change from card to card and rotate across sectors and sizes, from a twelve-person consultancy to a hospital group, so that working through them all gives broad practice rather than deep knowledge of one fictional company.

The two routes produce the same kind of record. A student working on their own organization ends with a governance file they can use at work. A student working on the scenarios ends with a complete worked example: an inventory, decisions, assessments, controls and reports, each built by the method. That example is useful later, as a model to adapt when you do have an organization to govern.

You can mix the routes. Some students use their organization for the tasks where they have the facts and the scenario where they do not, for example using the scenario for a supplier assessment because their organization's contracts are not available to them. Mark which records came from which route, so the file does not mix real systems with invented ones unnoticed.

When working on your own organization, be careful with facts you are not sure of. A record built on a guess about who owns a system, or what data it uses, should say so.

Finding out is part of the practice, and an honest "unknown, asked the IT service owner on this date" is a better record than a confident guess. A record with an unknown in it can be completed later; a confident guess usually survives unchallenged until the day it matters.

The records you produce need a home. The course calls it the governance file: one place where every record can be found by the system it concerns and the date it was made.

The form does not matter. A folder of documents with a spreadsheet for the inventory works, and is what many small and mid-sized organizations use for real. A governance or risk platform works too, if your organization has one and you are allowed to use it for drafts. What matters is that each record names its system, carries a date and an author, and can be found again without searching.

A simple arrangement follows the order of the course. Keep the organization profile and the standards register from this module at the front. Then the inventory, one entry per system, which Module 2 builds properly. Then the decisions taken about each system, the assessments, the controls and the Statement of Applicability, and finally the evidence and reports from Module 10.

Give each record a version. When a later module changes an earlier record, as Module 8 may change a role decision made in Module 1, keep the earlier version, record the change and say why. An auditor looking at a governance program wants to see decisions changing for reasons, and a record that silently changes looks like one that was never decided.

Two habits make the file useful beyond the course. First, write each record for the person who will read it next, usually a reviewer or the system's owner, not for yourself.

Second, link records rather than repeating them: an assessment points to the inventory entry it concerns, and the Statement of Applicability points to the assessments that justify each control. Repeated facts drift apart; linked facts stay consistent. The file is also where a new owner starts when a system changes hands.

Practice records about a real organization describe real systems, data and risks. Some of that is sensitive, and the course asks you to treat it the way your organization treats similar information.

The practical rule is simple. Keep practice records about your organization where your organization would keep governance records of the same kind, under the same access controls.

Do not put details of its systems, data or risks into tools or places it has not approved, including public AI chat tools and personal cloud storage. The practice tool in this course uses its own scenarios and never asks for information about your organization.

If your organization does not yet have an approved place for AI governance records, that is itself a finding worth noting, and the first practical step is to agree one with whoever owns the organization's information management. Until then, keep drafts on the organization's own systems with access limited to the people who would review them.

Where your organization allows it, use the practice records for real. The course is designed so that an inventory entry or a role decision written in practice is fit to become the organization's record after review.

Students who do this finish the course with the start of a working program, and with feedback from colleagues who own the systems, which teaches more than any self-check. It also shows the organization early what the program will ask of system owners, which makes the requests that follow easier to make.

Consultants and auditors have a particular duty here. A client's systems are not yours to describe in your own files unless the engagement allows it. Use the scenarios, or anonymize thoroughly, and keep any record that could identify a client inside that client's engagement records.

The same care applies to sharing your work with other students or online. A good governance record is specific, which is exactly what makes it sensitive. Share the method and your reasoning; keep the facts of a real organization out of it.

Alongside the practice cards, each module includes a practice tool scenario: a set of short case files, each describing one system in a different organization, with a decision to take on each. The tool used most in this course is the Role and Scope Desk, and the scenario below is a short one built on the five questions from lesson 0.1.

For each case you make a decision and cite the facts it turns on. A decision with no fact cited cannot be checked, so the tool asks for at least one. When you check your answers, it shows the model decision, the facts it turns on and the reason, and a note on each option explaining why it is right or wrong for that case.

Citing facts is the point, not a formality. Full marks need a fact the decision actually turns on, not just any true fact about the system.

That trains the habit every governance record needs: the reason a decision was taken should rest on something specific about the system, which another reviewer could check. "It uses AI" is not a fact a decision can turn on; "it was trained on ten years of the university's admissions essays" is.

The scenarios are designed so that the same decision has different right answers in different cases, because a decision that always comes out the same way teaches nothing about telling cases apart. They also include the cases people get wrong in practice, such as a system that is well documented in every respect except the one that matters.

Use the tool after the lesson it accompanies, not instead of the practice card. The tool trains the judgment quickly across several organizations; the practice card applies it to your own systems and produces a record. Together they cover what the course asks of you: deciding well, and recording the decision so that it can be checked.

Nobody grades the practice records in this course, so you need a way to check them yourself. The test the course uses throughout is the reviewer test: could someone who was not there reach the same decision from the record alone?

A record that passes the test states the decision plainly, lists the facts it turned on, gives a reason that connects those facts to the decision, names who owns it, and says when it will be looked at again. Each part has a purpose. Without the facts, a reviewer cannot check the decision.

Without the reason, a reviewer can see the facts but not why they led where they did, and may reach a different decision from the same facts. Without an owner, nobody answers for it. Without a review date or trigger, it stays in force long after the system has changed.

The commonest failure is the reason. "Low risk" is a decision; "low risk, because it drafts internal text only, no customer or personal data goes in, and staff review every output before use" is a decision with a reason.

The second can be checked, challenged and revisited when one of its facts stops being true. The first can only be believed or not. Reasons are also what let a decision be revisited: when a fact changes, the reason shows whether the decision still holds.

A useful way to apply the test is to give a record to a colleague, or reread it a week later, and ask what decision you would reach from it. If you would reach a different one, the record is missing a fact or a reason. If you cannot tell who owns it or when it will be reviewed, it is missing those.

The test also helps when two records disagree. If an inventory entry says one thing about a system and an assessment says another, the reviewer test will usually show which record is missing a fact, and fixing that record usually resolves the disagreement.

The modules are written to be taken in order, because each builds on records the previous ones produced. You can read ahead, but do the practice in order, or later practice tasks will ask for records you have not made.

Take each module's practice before starting the next. The practice tasks are short when the lesson is fresh and much longer when it is not, because the method has to be relearned.

A week between a lesson and its practice is usually enough to lose the detail that made a step easy, and the record suffers for it. Doing them in order also means that when a later module changes an earlier record, the earlier record exists to change.

Expect to revisit records. Module 1's role decisions are refined in Module 4, when the controls that depend on them are chosen, and again in Module 8, when a supplier's answers show more about how a system was built.

Module 2's risk tiers are tested against the full assessments in Module 5. Revising a record is a sign the program is working; record each change and its reason so the history stays visible.

If you are applying the course to your organization as you go, pace yourself to the organization as well as the course. Some practice tasks need information from other people, such as a system's owner, a supplier or the legal team.

Ask early and carry on with the next lesson while you wait, coming back to finish the record when the answer arrives. Keep a short list of questions waiting on other people, with the date asked, so none of them is forgotten while you move on through the modules. Some answers take weeks.

Finally, the course closes with an exam drawn from all ten modules. The best preparation is the governance file itself: a student who has built each record by the method, and checked it with the reviewer test, will recognize what the exam asks.

Some practice tasks will not have a clean answer, and neither will real systems.

A system may sit on the boundary of the definition, a role may depend on a contract clause nobody has read, or a risk tier may turn on how a system is actually used rather than how it was intended to be used. The course does not hide these cases; it asks you to record them properly.

Start by recording what is known, with its source. Then name the open question precisely: not "role unclear" but "whether our fine-tuning counts as a substantial modification, which decides whether we are the provider". A precise question can be answered; a vague one sits in the file forever.

Take an interim decision, usually the more cautious of the options, and say it is interim. Treating a borderline system as in scope until the question is settled costs a little effort; treating it as out of scope and being wrong means it ran ungoverned. Then name who will settle the question, often a lawyer, the system's supplier or its owner, and when.

When the answer arrives, record it beside the interim decision, with the reason, and change anything that depended on it. The history is useful: it shows a reviewer that the organization saw the doubt, handled it sensibly and closed it, which is exactly what a mature program looks like from outside.

The lessons model this. Where the standards or the laws leave a question open, the lesson says so and shows how to record it, rather than presenting one reading as settled. Expect the same of your own records, and treat an honest open question as a sign of a careful reviewer rather than an unfinished task.

A file with no open questions at all, after ten modules of real systems, usually means doubts were resolved silently rather than recorded, and that is harder to defend to an auditor than the doubts themselves would have been.

Every practice task in the course produces a governance record, built by the method the lesson taught, for your own organization or for the scenario on the card. The records go into one governance file, findable by system and date, kept where your organization keeps similar records.

The practice tool trains decisions that cite the facts they turn on, and the reviewer test checks any record: decision, facts, reason, owner, review. The next lesson writes the first entry in the file.