Building an AI governance program one owner, one operating system

A program is four things assembled around a person:

• One owner. An AI governance lead - a named individual accountable for the whole, with a seat close to the board. Scattered ownership is the number-one failure; a single owner is the number-one fix.
• An AI system inventory / registry. A living list of every AI system you build or use, each tagged with its risk tier (a2) and your role (a3). You cannot govern what you have not listed.
• Defined roles. Provider or deployer duties assigned per system, so responsibility is never ambiguous.
• The artifacts. A risk method (NIST), a management system (ISO 42001), an EU AI Act compliance mapping, model evaluations as evidence the system works, and incident-and-monitoring to catch problems early.

• You cannot govern an unknown. Most organisations underestimate how many AI systems they run - shadow tools, embedded features, vendor models. The registry surfaces them.
• It carries the tier and the role. Each entry links to session a2 (which risk tier) and a3 (provider or deployer), so the registry is where the whole course lands in one table.
• It drives the cadence. A new system or a new feature is a trigger to review - the registry is what the review works from. No registry, no habit.

• Governance reads from data governance. A model is only as trustworthy as the data feeding it. Provenance, quality, and consent for that data are a data-governance job - and AI governance depends on it. If you took the data-governance course, this is where it plugs in.
• Governance reads from evals. "The model works" is not a claim, it is an evidence question. Model evaluations - accuracy, bias, retrieval quality - produce exactly the proof a regulator or customer asks for. The RAG and evals courses build this muscle.
• Make it a habit. Tie a review cadence to real triggers: a new AI system, a major feature, an incident. Compliance is a habit, not a project - a program that only wakes up for an audit has already failed.

That closes the leader track. You started with a board that thought AI regulation was someone else's problem and you finish with a program you can own, fund, and defend. You know the Act reaches you when your AI's output touches the EU, how your systems sort by risk tier, who carries which duty, what non-compliance costs, which frameworks make it runnable, and how to assemble it all around one owner as a single operating system. That is the leader's job - to see the whole board and decide. The next job is to play the pieces, and that is hands-on work: classifying a system against the Act's criteria, writing the technical documentation, wiring up evaluations, running conformity steps. If you lead the people who do that, or you want to see exactly what your teams are doing, the practitioner track is your next stop - it takes the same running case and builds it, step by step. Whether you go on or hand this to your teams, you now have what you came for: AI governance as something concrete, evidenced, and yours. Thank you for spending these six sessions here.