Rule of thumb 👍: Accountability is (a person | people); governance is a system.

• Accountability = answerability for outcomes & impacts. A named owner makes decisions, documents rationale, fixes issues, and provides redress.
• Governance = structures, policies, and oversight that steer the AI lifecycle (who decides, how we decide, and how we verify we did it right).

Situation: The team finds gender skew in a hiring-support model during pilot.

• Accountability: Model Owner pauses deployment; documents decision; updates AIIA; approves mitigation (data rebalancing + threshold change); records rollback plan; communicates to stakeholders.
• Governance: Model Risk Committee reviews evidence; confirms policy fit (fairness metrics, human-in-the-loop); ensures additional testing; logs decision in register; sets re-evaluation date; Internal Audit adds the control to its next review.

Takeaway: Accountability is the who and action now; governance is the how and assurance always.

By the end of this module, you should be able to:

• Distinguish accountability vs governance and map roles with a RACI.
• Apply controls from ISO/IEC 42001, NIST AI RMF 1.0 + GenAI Profile, and the EU AI Act.
• Evidence accountability with artifacts (model/system cards, datasheets, risk registers, AIIA, eval plans, logs, incident reports).
• Design an assurance pathway (ISO 42001 certification (if available); EU AI Act conformity).

• EU AI Act:
  • entered into force 1 Aug 2024;
  • staggered application through 2025–2027.
• Maturing Standards:
  • ISO/IEC 42001 (AIMS), NIST AI RMF 1.0 and GenAI Profile (AI 600‑1).
• Public sector pull:
  • US OMB M‑24‑10 governance + M‑25‑22 acquisition; state/healthcare primers.

• 2 Feb 2025: Prohibitions & AI literacy start
• 2 Aug 2025: GPAI transparency/governance duties begin
• 2 Aug 2026: Most remaining provisions applicable
• 2 Aug 2027: Certain embedded high‑risk products

1. NIST AI RMF:
   • The core: 1) Govern, 2) Map, 3) Measure, 4) Manage
2. ISO/IEC 42001:
   • AIMS (Plan‑Do‑Check‑Act) + documentation & improvement
     
3. EU AI Act:
   • Risk‑based duties, transparency, post‑market monitoring, conformity assessment

• Voluntary, outcomes-based framework to manage AI risks across the lifecycle.
• Two parts:
  1. Foundations (risk & trustworthiness)
  2. Core (GOVERN, MAP, MEASURE, MANAGE)
• Trustworthiness characteristics:
  • valid & reliable; safe; secure & resilient; accountable & transparent; explainable & interpretable; privacy-enhanced; fair (harmful bias managed).

From 🔗 §3

• Policy & controls reflect law/regulatory duties; trustworthiness traits embedded.
  • (GOVERN 1.1–1.4)
• Roles & training: clear accountability lines; execs own risk decisions.
  • (GOVERN 2.1–2.3)
• Diverse teams & oversight: human-AI role clarity; safety-first mindset.
  • (GOVERN 3.1–4.1)
• Documentation & testing practices; incident information-sharing.
  • (GOVERN 4.2–4.3)
• External engagement & feedback loops; third-party/supply chain risk handling.
  • (GOVERN 5–6)

From 🔗 Table 1

• Document purpose, settings, norms, laws, stakeholders, risk tolerances.
  • (MAP 1.1–1.6)
• Categorize tasks/methods; describe knowledge limits & human oversight.
  • (MAP 2.1–2.2; 3.5)
• Build in scientific integrity & TEVV plans; define proficiency standards.
  • (MAP 2.3; 3.4)
• Analyze benefits, costs, and constraints; scope realistic use.
  • (MAP 3.1–3.3)
• Map third-party & IP risks and impacts (positive/negative) to people & society; engage actors.
  • (MAP 4.1–5.2)

From 🔗 §5.2, Table 2

• Choose metrics/approaches for top MAP risks; document gaps/limits.
  • (MEASURE 1.1–1.3)
• Evaluate trustworthiness in conditions like deployment; document generalization limits.
  • (MEASURE 2.1–2.5)
• Assess safety, security/resilience, transparency/accountability, explainability/interpretability, privacy, fairness/bias, and environmental impact; review TEVV efficacy.
  • (MEASURE 2.6–2.13)
• Track risks over time; enable feedback from users/communities.
  • (MEASURE 3.1–3.3; 4.1–4.3) From 🔗 §5.3, Table 3

• Make go/no-go calls; prioritize treatment by impact × likelihood × resources.
  • (MANAGE 1.1–1.4)
• Plan and implement mitigations; sustain value; recover from emergent risks.
  • (MANAGE 2.1–2.4)
• Manage third-party and pre-trained model risks.
  • (MANAGE 3.1–3.2)
• Run post-deployment monitoring, incident response, change management, and communications—continually.
  • (MANAGE 4.1–4.3)

From 🔗 §5.4, Table 4

• ISO/IEC 42001:2023 is the first AI Management System (AIMS) standard.
  • Requirements to establish, implement, maintain, and continually improve how your org governs AI.
  • It’s certifiable, similar in spirit to ISO 27001.
• Applies organization‑wide (not just a single model or project).
• Works for any org that develops, deploys, or uses AI systems.

From 🔗 here

An 🔗 overview

• It’s a management system that embeds AI governance into everyday work — not a one‑off checklist.
• Aligns with adjacent AI standards you can plug in:
  • ISO/IEC 23894 — AI risk management (methods & treatment).
  • ISO/IEC 5338 — AI system lifecycle processes (from concept to retirement).
  • ISO/IEC 42005:2025 — AI Impact Assessment (AIIA) structure and practice.
• Plays nicely with NIST AI RMF and public‑sector governance (e.g., OMB).

• Plan: define scope, context, roles, policy, and risk criteria (use 23894 for AI‑specific risk).
• Do: operate controls across the AI lifecycle (use 5338 as the lifecycle spine).
• Check: monitor & measure; run internal audits.
• Act: corrective actions and continual improvement.

1. Scope & inventory — define AIMS scope; list AI systems in scope.
2. Policy & roles — publish an AI policy; name accountable owners; train staff.
3. Risk process — adopt ISO/IEC 23894 for risk identification/treatment; set risk criteria.
4. Lifecycle & controls — map your build/ship cycle to ISO/IEC 5338; embed procedures (data governance, evaluation, logging, change mgmt).
5. Impact assessment — run ISO/IEC 42005 AIIA where impacts are higher.
6. Assurance — monitor, run internal audits, fix findings; consider certification.

• Scope & context • risk criteria • documented procedures • competence/awareness
  
• Evidence artifacts: inventories • AIIA • evaluation plans • logging • incident records

• EU regulation establishing a common legal framework for AI use in the EU.
• Entered into force: 1 Aug 2024; applies gradually over the next 6–36 months.
• A product‑regulation approach: obligations primarily on providers and professional deployers.
• Scope: most AI systems; notable exemptions for military, national security, and pure research; non‑professional use generally out of scope.

See 🔗 here

• Five buckets:
  • Unacceptable risk → banned (e.g., social scoring; certain real‑time remote biometric ID in public; manipulative systems — with narrow exemptions).
  • High risk → conformity assessment + obligations (quality, security, transparency, human oversight, lifecycle monitoring).
  • Limited risk → transparency duties (e.g., disclosure for AI interactions, deepfakes).
  • Minimal risk → unregulated (e.g., spam filters, games); voluntary codes encouraged.
  • General‑purpose AI (GPAI) → transparency requirements; reduced duties for open‑source models.

• What’s special?
  • GPAI addresses generative/foundation models.
  • Transparency: training‑data summary & copyright policy; reduced requirements for open‑source.
  • Systemic‑risk GPAI: additional evaluations where capability may cross computational/capability thresholds.

• EU‑level & national bodies:
  • AI Office (European Commission): coordinates implementation; oversees GPAI providers.
  • European Artificial Intelligence Board: Member State reps for consistent application.
  • Advisory Forum & Scientific Panel support technical/sector input.
• Conformity assessment under the New Legislative Framework; standards via CEN/CENELEC JTC 21; self‑assessment or notified bodies depending on use case.

• Exemptions: AI for military, national security, and pure research is out of scope.
• Extraterritorial reach: applies to providers outside the EU offering systems in the EU.
• Maximum harmonization: Member States can’t add extra rules for minimal‑risk systems.

1. Classify your AI systems by risk tier (incl. GPAI vs. application‑specific uses).
2. For high‑risk: assemble technical documentation, plan conformity assessment, set human oversight & monitoring.
3. For GPAI: prepare transparency artifacts (training‑data summary, copyright policy); check systemic‑risk triggers.
4. Map obligations to existing governance (e.g., ISO 42001 AIMS, NIST AI RMF) and set a timeline aligned to 6/9/12/24/36‑month milestones.
5. Track EU‑level guidance (AI Office/Board) and evolving standards for detailed requirements.

• AI Act Implementation Tool (Algorithm Audit): open‑source dynamic questionnaires to decide, e.g., risk category; can run locally.
• Trail ML — EU AI Act Compliance Checker: free self‑assessment that outputs likely role(s) and duties (incl. GPAI branches).
• Holistic AI — Risk Calculator: quick triage of risk category for portfolio screening.
• Securiti — Applicability Assessment & Compliance Checker: vendor tool to screen scope/roles and high‑risk/GPAI flags.
• appliedAI Institute — Risk Classification Database: searchable examples of high‑risk vs non‑high‑risk use‑cases (helpful for benchmarking).

1. Triage with the FLI checker; if ambiguous, run the Algorithm Audit questionnaires.
2. Validate “high‑risk” logic against the legal text:
   Article 6 (classification rules) → Annex III (listed high‑risk use‑cases).
3. Benchmark similar use‑cases in the appliedAI database; record reasoning.
4. Track official guidance and timeline on the Commission’s AI Act page; update your internal procedure as guidance/standards evolve.

• Practical, testable controls (accountability, testing, content provenance)
  
• “Crosswalks” to ISO 42001 and NIST AI RMF available via AI Verify
• Use AI Verify artifacts for testing & transparency
• Useful in RFPs and internal assurance

See 🔗here

• Treasury Board of Canada Secretariat (TBS): Directive on Automated Decision‑Making (DADM) + Algorithmic Impact Assessment (AIA) for administrative decisions.
• Generative AI (federal): GC Guide on the use of Generative AI (principles, safeguards, practices).
• Proposed federal law: Artificial Intelligence and Data Act (AIDA) (Bill C‑27) — not in force; companion docs published.
• Provinces (e.g.): Ontario Responsible Use of AI Directive and Bill 194 Developments; other commissioners issue guidance.

• Board / Execs: approve policy, set risk appetite, receive assurance.
• Chief AI / Risk Owner: accountable for the AIMS; resolves escalations.
• AI Steering / Model Risk Committee: cross‑functional gate for material changes.
• Model Owner (per system): end‑to‑end accountability; maintains evidence.
• Data Steward / Privacy / Security: domain controls; sign‑offs aligned to risk.
• MLOps/SRE: deployment controls, monitoring, rollback.

1. Scope check: Confirm your system is an automated decision system within DADM scope (incl. partial automation & human‑in‑the‑loop).
   
2. Run an AIA: Complete the Algorithmic Impact Assessment → get Impact Level (1–4).
   
3. Peer review: For Impact Level ≥ 2, arrange expert peer review and publish the review (or a plain‑language summary) before production.
   
4. Notice & explanation: Provide plain‑language notice and explanation appropriate to the impact level; keep documentation current.
   
5. Monitoring & incidents: Establish post‑deployment monitoring, incident response, and change‑management; re‑assess AIA on material changes.
   
6. Generative AI guardrails: Apply GC GenAI guide (copyright, data handling, safeguards, human oversight) when relevant.

• AI policy; prohibited uses; approvals; third‑party procurement and model intake.
• Risk appetite statements tied to use‑case criticality.
• Documentation & disclosure expectations (e.g., user‑facing notices).

• AI Impact Assessment (AIIA) proportional to risk; sign‑offs before launch.
• Human‑in‑the‑loop plans; escalation paths; change management.
• Incident response & post‑market monitoring procedures.
• Red‑teaming / safety evaluations pre‑deployment on risky features.

• Evaluation plan covering robustness, safety, security, privacy, fairness, misuse.
• Guardrails / policies; event logging and traceability; content provenance where applicable.
• Staged rollout; model/service SLOs and kill‑switch/rollback.

ISO 42001 ↔︎ NIST RMF ↔︎ EU AI Act

• Model/System Cards, Datasheets, evaluation reports.
• Deployment change logs; versioning; rollback plans.
• User disclosures and help content; accessibility notes.
• Monitoring dashboards; incident reports.

• Purpose & scope; intended/out‑of‑scope uses.
• Data sources & preprocessing; links to Datasheets.
• Evals across groups/contexts; limitations & failure modes.
• Safety measures & guardrails; human oversight & escalation.
• Monitoring signals & thresholds; incident playbook; contacts.

• 1st line (teams): Own the risk and the artifacts. They maintain the AI inventory, RACI, eval plans, logs, rollback plans, and incident records.
  • What I look for: current system card, recent eval report, and evidence of change control (who approved the last version and why).
• 2nd line (risk/compliance): Set the policy and challenge decisions. They define the AIIA template, thresholds, and sign-off criteria; they monitor KRIs.
  • What I ask: “Show me the risk appetite for this use case and where the latest metrics sit vs thresholds. When did you last re-assess after a material change?”
• 3rd line (internal audit): Independent testing and assurance to the audit committee. Scope includes inventory completeness, control design/effectiveness, and evidence integrity.
  • Typical tests: can we reproduce the evaluation? do logs prove who changed what and when? was the rollback drill executed in the last 6 months?

• E.g., Hiring support model flagged group disparity. 1st line paused rollout and updated AIIA; 2nd line challenged thresholds and approved mitigations; 3rd line verified logs, sign-offs, and that monitoring caught the issue.
• If you remember one thing: first line owns, second line challenges, third line verifies—and all three leave evidence.

• ISO/IEC 42001 certification (scope‑bound) to evidence an AIMS.
• EU AI Act conformity assessment where applicable (high‑risk); notified bodies.
• Use recognized evaluation methods (e.g., GenAI Profile tasking) to support claims.