At a glance
If competency I.A is why AI needs governance, I.B is who does it and how the organization is told about it. This competency is about the people and structure of an AI governance program: (1) defining roles and responsibilities, (2) building cross-functional collaboration, (3) delivering training and awareness, (4) right-sizing the program to the organization, and (5) distinguishing the developer / provider / deployer / user roles from a governance perspective.
A useful framing: governance is not a document, it is a set of accountable people working across functions. The exam tests the most widely accepted elements of how organizations set this up — anchored in the NIST AI RMF Govern function and ISO/IEC 42001’s management-system requirements (leadership, roles, competence, awareness) — and it tests them at the apply/analyze level, so expect short org scenarios.
I.B.1 — Define roles and responsibilities for AI governance stakeholders
Effective AI governance assigns clear, documented responsibilities so that for any AI system someone is accountable for its risks and outcomes. The NIST AI RMF Govern function and ISO/IEC 42001 both make “assign roles, responsibilities and authorities” a foundational requirement.
Common roles (titles vary; functions are what matter):
| Role | Governance responsibility |
|---|---|
| Board / senior leadership | Set tone at the top, approve the AI strategy and risk appetite, hold ultimate accountability. |
| Executive sponsor (e.g., Chief AI Officer) | Owns the AI governance program; secures resources; reports to the board. |
| AI governance committee / council | Cross-functional body that sets policy, reviews high-risk use cases, arbitrates trade-offs. |
| Legal, privacy & compliance | Map legal obligations (EU AI Act, GDPR), advise on lawfulness, manage regulatory risk. |
| Risk & security | Threat modelling, security testing, risk acceptance. |
| Data science / ML engineering | Build, test, document models within policy. |
| Product / business owners | Own the use case, its value and its first-line risk. |
| HR, procurement, ethics | Workforce impact, third-party/vendor risk, ethical review. |
| Internal audit | Independent assurance that controls work (third line). |
A RACI matrix is the most widely recommended tool to remove ambiguity: for each governance task, name who is Responsible, Accountable, Consulted and Informed. The rule the exam leans on: exactly one party is Accountable for a given task, and accountability cannot be delegated away even when the work is.
Many organizations layer this onto the three lines model: business owners (first line) own the risk, risk/compliance/legal (second line) set policy and oversee, and internal audit (third line) gives independent assurance.
I.B.2 — Establish cross-functional collaboration
AI risk is multi-dimensional — legal, ethical, technical, security, privacy, reputational, commercial — so no single function can govern it alone. The BOK justifies cross-functional collaboration explicitly for efficacy and diversity of expertise and perspective. A model that looks fine to a data scientist may be unlawful to a privacy lawyer, biased to an ethicist, and a security liability to the CISO; only together do they see the whole picture.
This is why the AI governance committee is cross-functional by design. Practical mechanisms:
- A standing committee with members drawn from legal/privacy, security, data science, product, HR, compliance, ethics and the affected business units.
- Diverse and inclusive membership — diversity of background and perspective is itself a control against bias and blind spots, not just a staffing nicety.
- Defined escalation paths and decision gates (e.g., high-risk use cases must clear the committee before deployment).
- Stakeholder engagement that reaches beyond the building — affected users, domain experts, and sometimes the public.
I.B.3 — Create and deliver a training and awareness program
Governance only works if people across the organization understand it. ISO/IEC 42001 makes competence and awareness explicit management-system requirements, and the NIST Govern function calls for a workforce that understands AI risks. The BOK requires training to all stakeholders on AI terminology, strategy and governance.
What good training programs share:
- Role-based, tiered content — general AI-literacy and acceptable-use awareness for everyone; deeper training for builders, reviewers, and the governance committee; board-level briefings for leadership.
- Covers terminology, strategy and governance — a shared vocabulary (so “model,” “bias,” “deployer” mean the same thing to all), the organization’s AI strategy and risk appetite, and the actual policies/procedures people must follow.
- Ongoing, not one-off — refreshed as technology, regulation and the program evolve; reinforced through awareness campaigns.
- Measured — completion and comprehension tracked, with records kept (an ISO 42001 expectation).
Note that AI literacy is becoming a legal obligation, not just best practice — the EU AI Act (Art. 4) requires providers and deployers to ensure a sufficient level of AI literacy among staff operating AI systems.
I.B.4 — Differentiate approaches based on company context
There is no one-size-fits-all AI governance program. The BOK requires differentiating approaches by company size, maturity, industry, products and services, objectives and risk tolerance. A program is right-sized, not copied.
| Factor | How it shapes governance |
|---|---|
| Size | A startup may run governance through a few people wearing several hats; a multinational needs formal committees, dedicated officers and tooling. |
| Maturity | Early programs focus on inventory, policy and quick wins; mature ones run continuous monitoring, audits and metrics. |
| Industry / sector | Regulated sectors (health, finance, employment) face stricter legal duties and need heavier controls. |
| Products & services | Higher-stakes or customer-facing AI (e.g., medical, lending) warrants more rigor than low-risk internal tools. |
| Objectives | Strategy and business goals set what AI is for and how aggressively it is adopted. |
| Risk tolerance | A risk-averse organization sets stricter gates, lower thresholds and more human oversight; a risk-tolerant one accepts more in pursuit of speed/innovation. |
Governance operating models — the structural choice scenario questions ask you to name:
- Centralized — one governance function (committee/office) reviews and decides for the whole organization. Strong consistency and control; can bottleneck. High-risk decisions escalate to the centre.
- Decentralized (federated) — each business unit or region governs its own AI within broad principles. Fast and context-aware; risks inconsistency and gaps.
- Hybrid — the common answer in practice: central policy, standards and escalation for high-risk decisions, with local/business-unit execution and first-line ownership. A multinational that manages risk locally but escalates high-risk cases to headquarters is running a hybrid model.
The constant across all of them is the principle: oversight, accountability and risk management scale proportionate to risk. Higher risk and higher regulatory exposure justify more formal, resource-intensive governance; lower risk justifies lighter touch. This proportionality idea echoes the EU AI Act’s risk-tiering and NIST’s risk-based approach.
I.B.5 — Developers, providers, deployers and users
Different actors in the AI value chain have different responsibilities, opportunities and needs. The exam aligns this with how the EU AI Act uses the roles, and the distinction drives who must do what.
| Actor | Who they are | Core governance responsibility |
|---|---|---|
| Developer | Designs, codes and trains the model/system. | How the system is built: data quality, training, documentation, intended purpose, built-in safeguards. |
| Provider | Develops a system (or has it developed) and places it on the market / puts it into service under its own name or trademark (EU AI Act). | The heaviest obligations: risk management, technical documentation, conformity assessment, transparency, registration, post-market monitoring. |
| Deployer | Uses an AI system under its own authority in a professional capacity (not as a consumer). | Use it as intended, ensure human oversight, monitor operation, inform affected people, keep logs — responsibility in context of use. |
| User | The end user / affected individual interacting with or subject to the system. | Mainly a recipient of protections: transparency/notice, ability to contest, redress. |
Key nuances the exam likes:
- Provider ≠ deployer. The provider builds and markets; the deployer puts it to use. The provider carries the bulk of pre-market obligations; the deployer carries in-use obligations.
- Roles can shift. A deployer can become a provider (and inherit provider obligations) if it substantially modifies a high-risk system or puts its own name on it, or repurposes a system to a high-risk use. Building your own model makes you both developer and provider — more control, but more obligation and liability.
- “Developer” vs. “provider” overlap but are not identical: developer is the technical builder; provider is the legal role of placing on the market under your name. The EU AI Act regulates providers and deployers by name.
How this shows up later
- The roles/RACI and committee structures here are the governance backbone for the lifecycle policies in I.C and the build/deploy controls in Domains III–IV.
- The provider vs. deployer distinction is tested again directly under the EU AI Act (II.C) and shapes who bears which obligation when deploying proprietary vs. third-party models (IV.A–IV.C).
- Proportionate, context-driven governance (I.B.4) underpins risk classification and impact assessments throughout the rest of the exam.
- Training/AI-literacy reappears as a legal requirement (EU AI Act Art. 4) and as a deployment control (IV.C user training).