PECB ISO/IEC 42001 Foundation

Governance Roles, Risk, and AI Controls

Effective AI governance makes decisions visible. It clarifies who does work, who approves it, who receives information, what risks matter, and what evidence shows that controls operate. This is a learner-created review module, not an official PECB curriculum. Use the official source at the end for current offering details and policies.

Roles create accountable decisions

Roles are not just job titles. A role explains authority, responsibility, competence, and interfaces. An executive may set direction and provide resources. A process owner may define the intended use and accept operational risk. A technical team may configure and monitor a system. Legal, privacy, security, procurement, and assurance functions may provide specialist challenge. A human reviewer may make the final decision in a high-impact process. The exact arrangement varies, but unmanaged overlap and unmanaged gaps are both risks.

Scenario: A recruitment assistant ranks applicants. The vendor says it provides bias testing, the data team maintains inputs, and HR uses the results. When an applicant asks how a decision was made, everyone points elsewhere. The governance lesson is to map the decision chain. Who defines intended use? Who validates input quality? Who monitors outcomes? Who handles complaints? Who can pause the tool? A strong answer assigns and connects these responsibilities.

Risk thinking for AI activity

Risk thinking asks what could affect intended outcomes. With AI, risks may arise from purpose, data, model behavior, deployment context, human use, supplier dependency, security, documentation, or changes over time. Do not treat risk as a list of alarming words. Describe a cause, event, consequence, existing response, owner, and next decision. Opportunity can also be considered, but opportunity does not justify ignoring harm or uncertainty.

Misconception: “A high accuracy figure proves risk is controlled.” Accuracy may be important, but it does not by itself address suitability, fairness, privacy, security, explainability, human oversight, or behavior in a changed environment. Ask which population, task, threshold, limitation, and monitoring method apply. Good governance is specific about what a measurement can and cannot prove.

Controls must connect to a purpose

A control is an action, process, rule, technical measure, review, or safeguard used to modify risk. The word control should prompt four questions: what risk is addressed, who operates it, what evidence exists, and how is effectiveness evaluated? A policy that nobody can apply is weak. A dashboard that nobody reviews is weak. A vendor questionnaire that is never updated after a major change is weak. Controls gain value from a deliberate operating rhythm.

Take a simple example. A customer-service tool drafts replies. A possible control set might include approved use cases, access restrictions, human review for sensitive topics, logging, a process for reporting unsafe output, and periodic review of incidents. Do not copy this as a universal checklist. Instead, show how each measure relates to the actual context and risk. The best answer is usually the one that creates a credible link between purpose, risk, action, and evidence.

Tool selection and supplier relationships

Tool selection is a governance decision, not only a feature comparison. Before selecting or expanding an AI tool, define the intended purpose, affected parties, data categories, integration points, constraints, accountable owner, and exit considerations. Ask vendors questions that lead to usable evidence. What documentation is available? How are material changes communicated? What access, retention, security, and support arrangements apply? What can the organization monitor independently?

A supplier can support governance without replacing it. The organization still decides whether the tool is appropriate for its purpose and whether its control environment is sufficient. Practice distinguishing a vendor claim from verified evidence. A claim says a feature exists. Evidence shows how it applies to the use case, who checked it, when it was checked, and what limitations remain.

Practice method and checkpoints

For each scenario, draw a compact chain: intended use, stakeholders, risk, control, owner, evidence, review. Then change one element. What happens if the data source changes? What happens if a supplier changes a component? What happens if users treat a recommendation as a final decision? This exposes missing controls and helps you reason through unfamiliar questions.

Checkpoint: explain why assigning a role is not enough, why a metric is not enough, and why a supplier statement is not enough. In each case, name the connection to an operating control and review activity. If you can do that, you are studying management-system reasoning rather than isolated terminology.

Official Scope and Verification

Contract verified 2026-07-13; source rechecked 2026-07-31. Official source: https://pecb.com/en/education-and-certification-for-individuals/iso-iec-42001/iso-iec-42001-foundation. Consult the official source for current authoritative offering information. This module intentionally does not state fees, exam counts, weights, timing, languages, eligibility, retakes, or certification rules.