Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 15

AI Governance, Legal, Privacy & Compliance

Last updated · 12 min read

15.1 NIST AI Risk Management Framework & Generative AI Profile

Priority: Must Understand

Executive Definition: The NIST AI Risk Management Framework (AI RMF 1.0, released January 2023) is a voluntary, non-regulatory framework organized around four functions (Govern, Map, Measure, Manage) for identifying and managing risks across an AI system's lifecycle. The Generative AI Profile (NIST AI 600-1, published July 2024) extends it with risks specific to generative AI (confabulation, data leakage, harmful content, over-reliance) and suggested actions mapped to the same four functions. Neither is a law or a certification; both are reference vocabulary and structure that regulators, auditors, and vendors increasingly assume you already use.

Why It Matters: NIST AI RMF has become the de facto common language for AI governance in US enterprises, referenced by insurers, auditors, and enterprise customers doing vendor risk assessments even though compliance is voluntary. The Generative AI Profile gives you a checklist of GenAI-specific failure modes (hallucination, IP infringement, data leakage) your own AI programs are unlikely to have already scoped. It is also the framework most cleanly mapped to ISO/IEC 42001 and to several state AI laws, so adopting its vocabulary reduces translation cost across obligations.

What I Need to Understand:

  • The four functions (Govern, Map, Measure, Manage) are lifecycle stages, not a maturity ladder: Govern is the cross-cutting function that has to exist before the others are meaningful.
  • The RMF is voluntary and non-prescriptive; the companion Playbook gives suggested (not mandatory) actions per subcategory and is explicitly "neither a checklist nor a set of steps to be followed in its entirety."
  • The Generative AI Profile adds ~12 GenAI-specific risk categories (e.g., confabulation, dangerous/violent content, data privacy, IP, value chain/component integration) layered onto the core functions: it does not replace the base RMF.
  • This is a framework, not a certification: there is no "NIST AI RMF certified" status; certification-seeking vendors claiming this should be questioned.
  • The framework is under active revision tied to US federal AI policy shifts (the 2025 AI Action Plan); expect updates, not a frozen document.

Questions I Should Be Able to Ask My Team:

  1. Which of our AI systems have gone through a documented Map/Measure/Manage cycle, and who owns Govern-level accountability across them?
  2. For our generative AI deployments specifically, which of the GenAI Profile's risk categories (confabulation, data leakage, IP, over-reliance) have we actually assessed versus just referenced in a slide?
  3. When a vendor claims "NIST AI RMF compliant," what artifact are they pointing to, and does it map to a specific Govern/Map/Measure/Manage subcategory or is it marketing language?

Technologies / Standards / Companies to Know: NIST AI RMF 1.0, NIST AI 600-1 (Generative AI Profile), NIST AI RMF Playbook, NIST AI Safety Institute (now the Center for AI Standards and Innovation)

Recommended Learning:

Time Investment: 2-3 hours

15.2 ISO/IEC 42001 (AI Management Systems)

Priority: Should Understand

Executive Definition: ISO/IEC 42001:2023, published December 2023, is the first international standard for an "AI Management System" (AIMS): an organizational governance structure for how you develop, provide, or use AI systems responsibly. Unlike NIST's AI RMF, it is a certifiable management-system standard, structured like ISO 27001 (information security) or ISO 9001 (quality) around Plan-Do-Check-Act, requiring documented policies, an AI risk process, and continual improvement. An organization can be audited and certified against it by an accredited body.

Why It Matters: ISO/IEC 42001 certification is emerging as the artifact enterprise procurement and vendor-risk teams ask for from AI vendors and from internal AI functions, the same way ISO 27001 became a baseline ask for security. Because it is certifiable, it creates external accountability (third-party audits) that NIST's framework does not. It also gives you a structural scaffold (policy, roles, risk register, internal audit, management review) that most internal "AI governance" efforts are missing even when they have written principles.

Why It Matters: (kept single per format above)

What I Need to Understand:

  • ISO/IEC 42001 is a management system standard (like ISO 27001/9001), not a technical or content standard: it governs how you manage AI risk and lifecycle, not what your models must do.
  • It is certifiable: accredited bodies audit and issue certificates, creating a real compliance/procurement artifact, unlike the voluntary NIST RMF.
  • It complements, rather than duplicates, ISO/IEC 23894 (AI risk management guidance) and ISO/IEC 22989 (AI terminology): 42001 is the organizational-governance layer that can incorporate those as risk methodology.
  • Scope covers any organization that provides or uses AI-based products/services: this includes companies deploying vendor AI, not only those building models.
  • Getting certified requires an actual AI system inventory and risk treatment process (see Topic 5): you cannot certify against a standard you haven't first built the underlying practice for.

Questions I Should Be Able to Ask My Team:

  1. If we pursued ISO/IEC 42001 certification today, what would an auditor find missing in our current AI governance documentation?
  2. Which of our AI vendors are ISO/IEC 42001 certified, and does that certification cover the specific product/service we use or a different part of their business?
  3. Is our AI risk methodology aligned to ISO/IEC 23894, or are we inventing our own risk taxonomy that won't map cleanly if we pursue 42001 certification later?

Technologies / Standards / Companies to Know: ISO/IEC 42001:2023, ISO/IEC 23894 (AI risk management), ISO/IEC 22989 (AI terminology), accredited certification bodies (e.g., BSI, DNV, A-LIGN)

Recommended Learning:

Time Investment: 1 hour

15.3 EU AI Act

Priority: Must Understand

Executive Definition: The EU AI Act (entered into force August 1, 2024) is binding law that classifies AI systems by risk tier: unacceptable (banned), high-risk (heavily regulated), limited-risk (transparency obligations), minimal-risk (unregulated): and imposes obligations accordingly, with extraterritorial reach to any organization whose AI system output is used in the EU. As of September 2026, prohibited-practice rules, AI literacy obligations, and general-purpose AI (GPAI) provider obligations are already in force and being enforced; most high-risk system obligations were pushed later by a 2026 "Digital Omnibus" amendment. This is legal requirement, not best-practice guidance, and this summary is not legal advice; confirm current obligations with counsel before acting.

Why It Matters: This is the first comprehensive AI-specific statute with real penalties (up to 7% of global turnover for prohibited practices) and it functions as a template other jurisdictions are watching. Enforcement has already started for GPAI and prohibited-practice provisions, and the 2026 Omnibus delay on high-risk obligations does not remove them: it moves the compliance clock, which is exactly the kind of deadline executives get blindsided by when they read "delayed" as "cancelled."

What I Need to Understand:

  • Legal requirement, current as of Sept 2026: prohibited practices and AI literacy obligations applied from Feb 2, 2025; GPAI provider obligations and governance bodies applied from Aug 2, 2025; transparency obligations (Article 50) and broader enforcement across GPAI/prohibitions/literacy took effect Aug 2, 2026.
  • Legal requirement, changed by the 2026 Digital Omnibus (agreed May 2026): stand-alone high-risk system obligations (Annex III) are now due Dec 2, 2027 (previously Aug 2, 2026); product-embedded high-risk systems (Annex I) are due Aug 2, 2028. Synthetic-content watermarking/labeling obligations were pushed to Dec 2, 2026.
  • Legal requirement: new prohibitions on AI-generated CSAM and non-consensual intimate imagery were added by the same Omnibus, effective Dec 2, 2026.
  • The Act applies extraterritorially: if your AI system's output is used by people in the EU, you can have obligations regardless of where your company is headquartered.
  • "High-risk" classification (Annex III) covers specific use-case categories (employment, credit, critical infrastructure, law enforcement, etc.): most enterprise internal tools are not automatically high-risk, but HR, hiring, and credit-adjacent AI usually are.
  • Recommended practice (not legal requirement): using NIST AI RMF or ISO/IEC 42001 as your internal control framework to evidence AI Act compliance: the Act itself does not mandate either standard, though harmonized EU standards are expected to serve as a compliance presumption pathway.

Questions I Should Be Able to Ask My Team:

  1. Which of our AI systems, if any, would fall under Annex III high-risk categories, and are we tracking the Dec 2027 / Aug 2028 deadlines for those specifically rather than assuming everything was delayed to 2026?
  2. Do we have documented AI literacy training and transparency disclosures in place for the obligations that are already enforceable today, not just the ones still years out?
  3. If we deploy a general-purpose AI model from a third party, do we understand which GPAI obligations sit with the model provider versus which "deployer" obligations sit with us?

Technologies / Standards / Companies to Know: EU AI Office, EU AI Board, GPAI Code of Practice, Annex III high-risk categories, Digital Omnibus on AI (2026)

Recommended Learning:

Time Investment: Half day

15.4 AI, Intellectual Property & Copyright Risk

Priority: Must Understand

Executive Definition: AI IP risk runs in two directions: inbound (was the data used to train the models you rely on lawfully obtained, exposing you to secondary liability or license disputes) and outbound (can your company actually own or enforce copyright in AI-generated output). As of September 2026, both questions remain legally unsettled in the US: no appellate ruling has resolved whether training on copyrighted material is fair use, and the US Copyright Office's position that purely AI-generated output lacks sufficient human authorship to be copyrightable has not been overturned by courts. This entry states legal status only; it is not legal advice, and positions here can change with any ruling.

Why It Matters: You are currently making product and vendor decisions inside a legal vacuum: the outcome of pending litigation (notably New York Times v. Microsoft and OpenAI) could retroactively affect the risk profile of models you've already built products on. Separately, if your own AI-assisted work product isn't copyrightable because a court or the Copyright Office decides it lacks human authorship, that has direct implications for what IP protection your company can claim over AI-assisted deliverables, code, and content.

What I Need to Understand:

  • Training-data fair use is unresolved: New York Times v. Microsoft and OpenAI is past motion-to-dismiss (core copyright claims survived, March 2025) but has not reached a fair-use ruling as of September 2026; the US Department of Justice filed a brief supporting OpenAI in September 2026: the first time the US government has taken a formal position on this question.
  • Outbound copyrightability is constrained: US Copyright Office guidance holds that output without sufficient human creative control/authorship is not copyrightable; the US Supreme Court declined in March 2026 to review whether AI alone can create copyrighted works, leaving the human-authorship requirement standing for now.
  • "Sufficient human authorship" is a fact-specific, unsettled line: heavy prompting alone is unlikely to qualify; substantial human selection, arrangement, or modification of AI output is more defensible, but there is no bright-line test yet.
  • Vendor indemnification clauses for AI-generated-content IP claims vary widely and are not a substitute for understanding your own exposure: read what's actually indemnified (training-data claims vs. output-infringement claims are usually treated differently).
  • This is a fast-moving area: any position taken today should be revisited at least annually, and definitely on any ruling in a marquee case.

Questions I Should Be Able to Ask My Team:

  1. For AI-generated code, content, or designs that matter to our IP position, do we have a practice of documented human review/modification sufficient to support a copyrightability claim if it were ever challenged?
  2. Which of our AI vendor contracts actually indemnify us against training-data infringement claims versus only output-infringement claims, and do we understand the difference?
  3. Are we tracking the status of the major pending training-data litigation, and do we have a plan to reassess vendor risk if a ruling goes against the AI providers we depend on?

Technologies / Standards / Companies to Know: US Copyright Office, NYT v. Microsoft and OpenAI, human-authorship requirement, AI training-data licensing markets (emerging)

Recommended Learning:

Time Investment: 1 hour

15.5 AI System Inventory, Risk Classification & Responsible AI Principles

Priority: Should Understand

Executive Definition: Before any framework (NIST RMF, ISO 42001) or regulation (EU AI Act) can be operationalized, an organization needs a living inventory of every AI system in use (internal builds, embedded vendor AI, and shadow AI) each tagged with a risk tier and an owner. Responsible AI principles (fairness, transparency, accountability, safety, privacy, human oversight) are the criteria you evaluate each inventoried system against; they are the "what to check for," while the inventory and classification are the "where to look."

Why It Matters: Every governance framework in this curriculum (NIST RMF's Map function, ISO 42001's risk process, the EU AI Act's risk tiers) assumes you already have this inventory; most mid-size enterprises don't, especially where AI arrived embedded in SaaS tools rather than through a formal build process. Without it, "we have an AI governance program" is a governance program with nothing to govern.

What I Need to Understand:

  • An inventory must capture vendor-embedded AI (the AI features quietly turned on inside your CRM, HRIS, or productivity suite), not just internally built models: this is where most shadow risk actually lives.
  • Risk classification should use a consistent, small taxonomy (e.g., aligned to EU AI Act tiers or a simple high/medium/low) applied uniformly, not an ad hoc label per team.
  • Responsible AI principles are evaluation criteria, not a governance process by themselves: a values statement without an inventory to apply it to is not a control.
  • Ownership matters more than documentation: each inventoried system needs a named accountable owner, not just a description in a spreadsheet nobody updates.
  • This is foundational infrastructure for ISO/IEC 42001 certification and for demonstrating EU AI Act compliance: treat it as a prerequisite project, not a parallel one.

Questions I Should Be Able to Ask My Team:

  1. Do we have a single, current inventory of every AI system in use across the company, including vendor-embedded AI features, with a named owner for each?
  2. What risk tier is assigned to each system, and what criteria determined that tier: is it consistent across business units?
  3. When a new AI feature gets enabled inside an existing SaaS tool we already use, what is our process for catching that and classifying it?

Technologies / Standards / Companies to Know: OECD AI Principles, NIST AI RMF "Map" function, ISO/IEC 42001 risk register requirements, EU AI Act risk tiers

Recommended Learning:

Time Investment: 1 hour