A one-day, operationally-focused program for management-level "Directors" who need to build and run an AI governance program — not pass a certification exam. Condensed from the IAPP AIGP Body of Knowledge v2.1 (58 lessons, 4 domains) into what leaders actually need to act on: accountability, the regulatory landscape, lifecycle controls, and vendor/deployment oversight.
The source material is written for an individual studying to pass a certification exam — dense, recall-oriented, organized around what gets tested. A room of senior managers needs the opposite: a small number of decisions and questions they can act on Monday morning. This program keeps the four-domain structure (it's a sound map of the discipline) but re-weights every session from "know this for a test" to "here's what to build, and what to ask your team."
A standard 9:00–17:00 day: 6.5 hours of programming, a working lunch, and two short breaks. Every block below can compress or stretch by ±10 minutes without breaking the flow — see Facilitator Notes for how to adapt it to a half-day or a two-day format.
The shortest module in scope but the one everything else depends on. Get accountability right here and the rest of the day is implementation detail; get it wrong and no framework in Module 2 will save you.
Objective: agree on the vocabulary and the risk rationale before assigning any accountability.
An AI system is a machine-based system that infers from the inputs it receives how to generate outputs — predictions, content, recommendations or decisions. What makes it a distinct governance problem, versus ordinary software, is a specific combination of traits: complexity (hard to fully audit), opacity (decision logic isn't always inspectable), autonomy (can act with less human review), and speed and scale (one flawed model can affect millions of decisions before anyone notices). Every control in this document exists to answer one of those four traits.
The same eight principles recur across every framework covered today (OECD, NIST, the EU AI Act, most corporate charters). The table is the point: a principle only governs once it becomes a requirement with an owner.
| Principle | What it means | What it looks like in practice |
|---|---|---|
| Ethics | Respect human rights and societal values — the umbrella over the rest | Ethics review; clear red lines for unacceptable uses |
| Fairness | Avoid unjust bias; comparable treatment | A chosen fairness metric, a threshold, a disparate-impact test |
| Safety & reliability | Performs as intended within safe limits | Robustness testing, guardrails, fail-safes |
| Privacy | Lawful, minimal use of personal data | Data minimization, DPIAs, retention limits |
| Security | Protected from attack and manipulation | Threat modeling, access control, poisoning defenses |
| Transparency & explainability | People know it's AI and can understand outputs | Disclosure, model cards, audience-appropriate explanations |
| Accountability | Named people answer for outcomes | A single accountable owner; an audit trail |
| Human-centricity | Respects human autonomy and wellbeing | Human-in-the-loop, opt-outs, meaningful redress |
These principles routinely pull against each other — more transparency can expose personal data or invite gaming; tighter fairness constraints can cost raw accuracy; heavy human oversight can slow throughput. Governing well means naming the trade-off explicitly and recording who signed off on the balance, not pretending it doesn't exist.
Objective: leave with a concrete accountability structure, not just a principle that "everyone owns AI."
Effective AI governance is distributed but accountable. The goal is to avoid both failure modes: a single overwhelmed owner, and diffuse responsibility where "everyone" owns AI and therefore no one does. Two tools do the work:
| Stage | Who leads | What they own |
|---|---|---|
| Planning & design | Exec sponsor, product owner, governance/ethics lead | Set acceptable-use limits, screen ethical risk, fund the build |
| Data collection & prep | Data engineering, legal, privacy/compliance | Confirm lawful data rights, check representativeness & bias, apply privacy controls |
| Model development & training | Data scientists, ML engineers, risk partners | Train and validate, record design assumptions, measure bias & performance |
| Validation & testing | QA, domain experts, compliance | Run robustness & security tests, confirm accuracy & reliability |
| Verification & release | Governance board, accountable executive | Review pre-deployment evidence, decide go/no-go, accept or remediate residual risk |
| Deployment & integration | AI/ML ops, IT, business owner | Stand up monitoring & alerts, hold to service levels, control the rollout |
| Operation & monitoring | Risk owners, end users, compliance | Watch for drift, gather feedback, run incident response, keep documentation current |
| Decommissioning / retirement | Legal, IT, governance committee | Retire models safely, preserve logs & records, update the inventory |
A policy only governs if it is an enforceable gate — explicit entry/exit criteria a system must clear to advance, with evidence to prove it. "No approved use-case assessment, no data work; no test sign-off, no release."
| Lifecycle stage | Policy gate | What it requires to pass |
|---|---|---|
| Use-case assessment | Intake approval | Defined purpose and value, plus an initial risk screen |
| Risk & impact | Impact-assessment sign-off | Documented impacts and mitigations |
| Data acquisition & use | Data-use approval | Lawful rights, quality and representativeness checks |
| Development & training | Build review | Design assumptions and risk controls recorded |
| Testing & validation | Test sign-off | Validation, robustness, security and bias results met |
| Deployment | Release gate | Conformity, oversight, rollback and a monitoring plan |
| Monitoring | Periodic re-review | Drift, performance and incidents reviewed on a cadence |
| Incident management | Response readiness | Detection, escalation and disclosure paths defined |
It's a loop, not a line: monitoring, incidents and drift feed back into earlier stages, triggering re-assessment or even redesign. Live systems get re-reviewed on a cadence, not approved once and forgotten.
The goal here is not legal fluency — it's pattern recognition. By the end of this module, attendees should be able to tell which of the four "kinds" of framework they're looking at, and flag when a system likely needs legal review.
The single most useful mental model for the regulatory landscape: these frameworks are not competing versions of the same thing. They sit at different altitudes and do different jobs.
| Framework | What it is | Binding? |
|---|---|---|
| OECD AI Principles | The values — the first intergovernmental AI standard (2019, updated 2024) | Soft law — non-binding, no penalties |
| NIST AI RMF | The process — a voluntary US risk-management operating model | Voluntary — no penalties, but widely adopted |
| ISO/IEC 42001 | The certificate — an AI management system standard you can be audited against | Voluntary but certifiable |
| EU AI Act | The law — a binding, risk-tiered regulation with fines | Binding — fines up to €35M / 7% of global turnover |
The OECD's technology-neutral definition of an AI system — a system that infers from inputs how to generate outputs — is the definition the EU AI Act itself builds on. Know that lineage and the rest of this section falls into place.
Objective: correctly sort a described system into one of four risk tiers, and know what obligation follows.
The world's first comprehensive, horizontal AI law. It is risk-based (obligations scale with risk tier), extraterritorial (applies to non-EU providers/deployers when the system's output is used in the EU, much like the GDPR), role-based, and technology-neutral.
A system is high-risk if it's a safety component of a regulated product, or falls in an Annex III use area: biometrics, critical infrastructure, education & vocational training (admissions, scoring, proctoring), employment (recruitment, screening, promotion, termination), essential services including credit scoring and insurance pricing, law enforcement/migration, and administration of justice. Education, employment and credit are the classic blind spots — they sound routine but carry full high-risk obligations.
| Role | Core duties |
|---|---|
| Provider | The heaviest duties: risk management, data governance, documentation, conformity assessment, CE marking, registration, post-market monitoring |
| Deployer | Use per instructions, ensure human oversight, monitor, keep logs, inform affected people, run a FRIA for certain high-risk uses |
| Importer | Verify the provider's conformity assessment, documentation and CE marking before placing on the EU market |
| Distributor | Check that marking and documentation are present before making a system available |
Watch this one: a deployer who substantially modifies or rebrands a system becomes a provider — and inherits the heavier duties.
All GPAI providers must maintain technical documentation, publish a summary of training data used, and put in place a copyright policy. GPAI with systemic risk — presumed above a 10²⁵ FLOP training-compute threshold — carries extra duties: model evaluation, adversarial testing, systemic-risk assessment, serious-incident reporting and cybersecurity.
| Breach | Maximum fine |
|---|---|
| Prohibited-practice breaches | €35M or 7% of global annual turnover, whichever is higher |
| Most other obligation breaches (high-risk, GPAI, transparency) | €15M or 3% |
| Supplying incorrect/misleading information to authorities | €7.5M or 1.5% |
| Date | What applies |
|---|---|
| Aug 2024 | Entry into force of the Regulation |
| Feb 2025 | Prohibited practices and AI-literacy obligations apply |
| Aug 2025 | GPAI obligations, governance bodies and penalties apply |
| Aug 2026 | Most high-risk (Annex III) obligations apply |
| Aug 2027 | High-risk systems that are safety components of regulated products apply |
The framework to reach for wherever no AI-specific law yet applies — voluntary, sector-agnostic, and paired with a companion Playbook of suggested actions.
| Function | What it does |
|---|---|
| Govern (cross-cutting) | Cultivate a culture of risk management — policies, accountability, roles and oversight that make the other three functions work |
| Map | Establish context and frame the risks of the system and its use case |
| Measure | Analyze, assess and benchmark the identified risks (bias, robustness, security) |
| Manage | Prioritize, respond to and monitor the risks, allocating resources to the greatest |
Pair each function with the seven trustworthy-AI characteristics it's meant to produce: valid & reliable, safe, secure & resilient, accountable & transparent, explainable & interpretable, privacy-enhanced, and fair (harmful bias managed).
There is no single US federal AI law. Instead: a growing state patchwork, plus existing federal regulators applying old authority to new technology.
| Law / regulator | What it does |
|---|---|
| Colorado AI Act | First comprehensive US state AI law — duty of care against algorithmic discrimination in consequential decisions |
| NYC Local Law 144 | Requires an independent bias audit before using an automated hiring/promotion tool, plus candidate notice |
| Illinois BIPA | Strict consent rules for biometric identifiers (face, fingerprint, voice) — with a private right to sue |
| California AB 2013 / SB 942 / SB 1001 | Training-data transparency / AI-content provenance & labeling / "a bot must say it's a bot" |
| FTC / EEOC | Apply existing authority to AI — overstated "AI-washing" claims and AI hiring tools that produce discriminatory outcomes |
Globally: the EU AI Act (binding law), South Korea's AI Basic Act (2nd comprehensive national law, effective Jan 2026), the Council of Europe Framework Convention (the first binding AI treaty), China's vertical rules and algorithm registry, and softer-touch principles in the UK, Singapore and Japan. Takeaway for management: if a system touches hiring, credit, biometrics, or EU users, get legal involved early — this is not a landscape to navigate on instinct.
This is the build half of the lifecycle. The goal is to leave with the vocabulary to ask sharp questions of a technical team — not to become the technical team.
Governance is not a one-time gate — it follows the system from first idea to retirement, and it's a loop, not a line: monitoring, incidents and drift feed back into earlier stages. Four things run continuously across every stage: governance & accountability, risk management, documentation, and human oversight.
Build half (this module): use case → impact assessment → data governance → train → test (TEVV) → release readiness. Deploy half (Module 4): select model → deploy → monitor → maintain/retrain → deactivate.
An AI impact assessment systematically evaluates potential harms to individuals, groups and society, the proportionality of the system, and the mitigations — ideally starting before development and iterating as the design firms up. Several overlapping assessments exist:
| Assessment | Covers |
|---|---|
| DPIA | Privacy / data-protection risk |
| FRIA | Fundamental-rights impact (required of certain EU AI Act deployers) |
| AIA | The whole AI risk picture — harms, proportionality, mitigations |
| ISO/IEC 42005 | A recognized method for structuring an AI impact assessment |
Four testing activities get blurred together in practice. Knowing which question each answers is enough to read any technical test report critically.
| Component | The question it answers | Measured against |
|---|---|---|
| Test | Does this specific function work under known conditions? | Predefined inputs & expected outputs |
| Evaluate | How good is the whole system, overall? | Metrics across the battery — accuracy, robustness, fairness |
| Verify | Did we build it right? | Design specifications & requirements |
| Validate | Did we build the right thing? | Real-world need & intended use |
The most useful distinction for a manager: Verify asks "did we meet the spec," Validate asks "does this actually solve the real problem." A system can pass verification and still fail validation.
Each type of bias enters the system at a different point. Knowing which point helps you ask the right follow-up question when a team reports a fairness issue instead of accepting "it's biased" as a full explanation.
| Bias | Enters at… | What's actually wrong |
|---|---|---|
| Historical | Real-world inequity, accurately recorded | The data is correct, but the world it records was unfair |
| Representation | Sampling — who is in the data | Some groups are under-represented vs. the deployment population |
| Measurement | Features & labels (proxies) | The proxy is flawed, or measured differently across groups |
| Aggregation | Model design | One model is forced onto distinct subgroups that behave differently |
| Evaluation | The test set / benchmark | The benchmark is unrepresentative, so headline metrics mislead |
| Deployment | Context of use | Used outside the context it was built or validated for |
| Automation | Human behavior (over-trust) | People over-rely on outputs and stop applying judgment |
| Confirmation | Human cognition (belief) | People favor outputs that confirm what they already expected |
The classic mix-up: historical vs. representation vs. measurement all look like "biased data" in a post-mortem — the difference is why. And two of the eight (automation, confirmation) aren't data problems at all — they're human behavior, and the fix is oversight design and training, not re-sampling a dataset.
Most organizations are deployers of someone else's model far more often than they are builders of their own. This module is deliberately weighted toward that reality.
Three questions to settle before committing to a system: the context of the use case (who's affected, how consequential), the model type (classic predictive vs. generative vs. agentic carry different risk profiles), and the deployment option (build in-house, license, or embed a third-party API — each shifts where obligations and liability sit).
Objective: leave able to hand this table to procurement or legal before the next AI vendor contract is signed.
When you're buying rather than building, the contract is your governance control. Default vendor terms are written to protect the vendor.
| Term | What to check |
|---|---|
| Data use | Will your inputs train the vendor's model? |
| IP & ownership | Who owns the outputs? |
| Performance / SLA | Committed accuracy, uptime and support |
| Liability & indemnity | Who bears IP-infringement and harm risk? |
| Transparency & audit | Rights to documentation, bias evidence, audit |
| Security & sub-processors | Controls, and the vendor's own downstream suppliers |
| Model-change notice | Notification when the model materially changes |
| Exit & portability | Get your data/config out; avoid lock-in |
The vendor's benchmarks do not capture your data and your population — only ongoing monitoring in your own production environment does.
| Watch for | Why |
|---|---|
| Drift | Your data/population diverges from the lab's |
| Performance | Accuracy can decay in your specific context |
| Bias | Fairness must hold for your population, not the vendor's test set |
| Outages | Operational health and availability |
| Vendor updates | Validate changes before you adopt them, don't inherit them blind |
Deployers keep records too — an incident log, an issue/risk register, and a post-market monitoring plan, feeding the provider and regulators where required. Reporting runs both ways: you often must notify the provider, who has their own downstream duties.
| Record | Purpose |
|---|---|
| Incident log | Evidence, learning and reporting |
| Issue / risk register | Track open items with named owners |
| Post-market monitoring plan | Track real-world performance over time |
| Provider / regulator reports | Meet two-way notification duties |
And finally: every system needs a designed way to be turned off. Be able to deactivate, localize, or retire a system safely — with a fallback process and a plan for the data it leaves behind.
16:00–16:45. Attendees pick one real AI system from their own organization and work through this checklist live, in small groups. The goal is a filled-in page, not a perfect one — gaps found today are cheaper than gaps found in an incident review.
| If someone says… | They probably mean… |
|---|---|
| "the values-based principles" | OECD AI Principles (soft law, 2019/2024) |
| "the risk-management process" | NIST AI RMF — Govern · Map · Measure · Manage (voluntary, US) |
| "the certification / audit standard" | ISO/IEC 42001 (certifiable AI management system) |
| "the law with the fines" | EU AI Act (binding, up to €35M / 7% turnover) |
| By day… | Do this |
|---|---|
| 30 | Inventory every AI system in use (including "shadow AI" tools teams adopted on their own) and assign one accountable owner to each |
| 60 | Run the risk-tier and vendor-contract checklists above against your three highest-exposure systems; escalate gaps to legal/compliance |
| 90 | Charter the AI governance committee, publish the lifecycle RACI, and schedule the first periodic re-review cadence |
The ~25 terms used most often across today's session. For the complete 281-term glossary behind this program, see the full course extract referenced in Facilitator Notes.
This program condenses and re-levels content from a self-study course built on the IAPP AIGP Body of Knowledge v2.1 (effective Feb 2026) — a professional-certification syllabus, not an official IAPP training product. It has been substantially rewritten here: exam-recall framing removed, self-test Q&A converted to management discussion prompts, and content re-weighted toward operational, cross-industry, management-level application rather than certification recall. Verify current thresholds, fine amounts and effective dates against the primary sources below before publishing this externally or relying on it for compliance decisions — regulatory details (especially EU AI Act phase-in dates and US state law) move quickly.