The Compliance & Regulatory Catalog

The AI Compliance & Regulatory Catalog

A Catalog of Governance Frameworks, Regulations, and Documentation

Draft v0.1

May 2026

Table of Contents

About This Catalog

This is the eleventh volume in a catalog of the working vocabulary of agentic AI, and the only one I added knowing it wasn’t a major missing piece. The ten prior volumes covered the engineering substance --- patterns, skills, tools, events, fabric, memory, human-in-the-loop, evaluation and guardrails, multi-agent coordination, and retrieval. The Evaluation and Guardrails volume (Volume 8) already covered the technical governance mechanisms an engineer needs. So why an eleventh volume on compliance and regulatory frameworks?

The honest answer is audience. Volume 8 is for the engineer building safety infrastructure: classifiers, eval suites, red-team frameworks, runtime guardrails. The artifacts it produces are code, test results, traces, and configurations. The audience for those artifacts is mostly the engineering team itself, plus the immediate operations staff. Volume 11 is for the compliance officer, the auditor, the procurement team, the regulator --- audiences whose job is to look at the engineering and produce documentation that other audiences accept. The artifacts of Volume 11 are model cards, impact assessments, conformity declarations, audit reports, SOC 2 addenda. The engineering doesn’t change between Volume 8 and Volume 11; the translation of that engineering into evidence other audiences accept is the work this volume documents.

The catalog’s timing reflects the genuine momentum in the regulatory layer. The EU AI Act entered into force in August 2024, with prohibited practices effective February 2025, General-Purpose AI obligations effective August 2025, and high-risk system obligations effective August 2026 --- about two and a half months from the date on this catalog’s cover. Colorado’s SB 24-205, originally the most comprehensive US state AI law, was effectively replaced in May 2026 by SB 189 (a much more business-friendly disclosure-based regime) just days before this volume’s publication. NIST AI RMF’s Generative AI Profile shipped in July 2024. ISO/IEC 42001 finalized in December 2023. Sector-specific guidance from FDA, FINRA, and HHS continues to emerge. The regulatory layer is the part of the AI landscape moving fastest in 2026 by an order of magnitude over any other layer; documenting it in May 2026 catches it mid-stride.

Scope

Coverage:

• Comprehensive risk management frameworks: NIST AI RMF (including the Generative AI Profile), ISO/IEC 42001.

• The EU AI Act and its implementing instruments: the Act itself, GPAI Code of Practice.

• US state AI regulations: Colorado (SB 24-205 → SB 189), California, NYC AEDT, Utah, Texas.

• Sector-specific AI governance: FDA AI/ML guidance for medical devices, financial services Model Risk Management (SR 11-7), HIPAA implications for healthcare AI.

• International AI governance: China generative AI measures, UK approach, Singapore Model AI Governance Framework.

• Documentation artifacts: model cards, data sheets, AI Bills of Materials (AIBOM).

• Audit and assurance frameworks: SOC 2 with AI considerations, emerging AI assurance services.

Out of scope:

• The technical governance mechanisms covered in Volume 8 --- evals, guardrails, red-team frameworks, OWASP LLM Top 10. This volume cites them as evidence inputs; it doesn’t re-cover them.

• General-purpose privacy regulation (GDPR, CCPA, HIPAA Privacy Rule) except where the AI-specific implications matter. The privacy literature covers them better.

• Intellectual property and AI (training data licensing, copyright on AI outputs, the New York Times v. OpenAI line of litigation). Important but a separate body of law.

• Antitrust and AI (concentration in AI markets, competition implications of foundation models). Important but a separate body of policy.

• Employment law specific to AI hiring tools beyond NYC AEDT --- EEOC guidance, state-level employment AI laws beyond the comprehensive frameworks already covered.

How to read this catalog

Part 1 (“The Narratives”) is conceptual orientation: why this volume sits adjacent to Volume 8 rather than as a major missing layer; the three geographies of AI regulation (EU, US, Rest of World); the risk-tiered mental model the EU AI Act established and others have echoed; the documentation cascade that translates engineering evidence into procurement-ready artifacts; and the compliance-engineering handoff that makes the translation mechanical when done well. Five diagrams sit in Part 1.

Part 2 (“The Substrates”) is reference material organized by section. Each section opens with a short essay on what its entries have in common. Representative substrates appear in the Fowler-style template established by the prior ten volumes. Regulatory frameworks are presented with effective-date information and jurisdiction-specific obligations; the format treats them as substrates an architect needs to know about, not as the legal-analysis depth a compliance attorney would produce.

Part 1 — The Narratives

Five short essays frame the design space for AI compliance and regulatory engagement. The reference entries in Part 2 assume the vocabulary established here.

Chapter 1. Why This Volume Sits Adjacent to Volume 8

When I designed the catalog series, I called compliance and regulatory frameworks a non-gap. The reasoning was that Volume 8 (Evaluation and Guardrails) covered the technical substance of AI governance --- evals, guardrails, red-team tools, OWASP LLM Top 10 --- and that adding a separate compliance volume would be redundant. The reasoning was wrong in a specific way that’s worth naming: it conflated the engineering of AI safety with the documentation of AI safety, treating them as the same activity because they’re produced by the same team.

Volume 8 is engineer-facing. Its products --- NeMo Guardrails configurations, DeepEval test suites, Garak vulnerability reports, LangSmith trace records --- are produced by engineers, reviewed by engineers, and used by engineers. The audience the artifacts speak to is the engineering team itself plus the immediate operations function. The format reflects this: code, test results, JSON traces, dashboards. The question the artifacts answer is whether the system is safe in the engineering sense --- do the safety mechanisms work, do the tests pass, do the guardrails block what they’re supposed to block.

Volume 11 is compliance-facing. Its products --- conformity declarations, model cards, impact assessments, audit reports, SOC 2 addenda, post-market monitoring reports --- are produced by a different function (often legal-and-compliance or governance), reviewed by external auditors, and consumed by procurement teams, regulators, and corporate boards. The audience is non-engineering, often non-technical, frequently adversarial in the sense that they’re looking for reasons to deny approval. The format reflects this: structured documents that follow regulatory templates, with explicit citations back to the engineering evidence that supports each claim. The question the artifacts answer is whether the system is safe in the legal-and-regulatory sense --- does the documentation demonstrate compliance with applicable regulations, does the evidence stand up to audit, does the risk profile match what was disclosed.

The two activities share a problem space (AI safety) and a substrate (the engineering work). They differ in audience, format, and quality bar. A team that does excellent Volume 8 engineering and skips Volume 11 documentation has a safe system that won’t pass enterprise procurement. A team that does excellent Volume 11 documentation and skips Volume 8 engineering produces convincing paperwork for a system that doesn’t actually work. The disciplines need each other; conflating them produces both bad engineering and bad compliance. Volume 11 exists to make the second discipline explicit instead of leaving it as implicit overhead the engineering team doesn’t plan for and the compliance team doesn’t understand.

This framing also explains why the volume is shorter than its peers. The catalog series treats each volume as the working vocabulary for an engineering layer. Compliance isn’t an engineering layer; it’s a translation activity that depends on every other layer. A working compliance program is mostly the right engineering plus deliberate documentation handoffs plus knowledge of which frameworks apply. The substrates documented here --- NIST AI RMF, EU AI Act, ISO 42001, FDA guidance --- are reference points the architect needs to know exist; the actual compliance work uses them as inputs but isn’t about them.

Chapter 2. The Three Geographies of AI Regulation

AI regulation in 2026 isn’t one regulatory landscape; it’s three of them, with very different philosophies, very different enforcement mechanisms, and partial but increasing cross-influence. An architect designing for a single-market deployment can pick one and follow it. An architect designing for multi-market deployment inherits the union of obligations, with the strictest framework typically setting the practical bar.

The European Union’s approach is rights-based and horizontal. The EU AI Act (Regulation 2024/1689), which entered into force in August 2024 with phased application through 2027, treats fundamental rights as the regulatory north star and creates a single horizontal framework applying to AI systems across all sectors. The Act’s structure is risk-tiered: unacceptable-risk AI is prohibited outright (effective February 2025), high-risk AI faces strict obligations including conformity assessments and post-market monitoring (effective August 2026), limited-risk AI has transparency obligations (also August 2026), and minimal-risk AI is unregulated. The enforcement mechanism is European: ex-ante conformity assessment by notified bodies for high-risk systems, market surveillance by national competent authorities, and fines up to €35 million or 7% of global annual turnover for prohibited-practice violations. The philosophy is to prevent harms before they happen by certifying systems before they enter the market.

The United States approach is sectoral and state-level. No comprehensive federal AI law exists; the federal layer consists of voluntary frameworks (NIST AI RMF) and sector-specific guidance (FDA for medical AI, FINRA and OCC for financial services AI, EEOC for employment AI, HHS for healthcare AI). The active regulatory action has been at the state level, with Colorado’s SB 24-205 (originally signed May 2024) the most comprehensive attempt at a horizontal state-level framework. As of May 2026 that law has been effectively replaced by Colorado SB 189, a much more business-friendly disclosure-based regime that took the place of the original Act’s risk-management programs and impact assessments. Other state laws --- California’s AB-2013 on AI transparency, NYC’s Automated Employment Decision Tool (AEDT) bias audit law, Utah’s SB 149, Texas HB 149 --- cover narrower domains. The enforcement mechanism is American: state attorneys general using consumer-protection and civil-rights statutes, sectoral regulators applying their existing enforcement authority, private litigation under existing legal theories. The philosophy is to let sectors and states adapt existing legal frameworks rather than create new horizontal AI law.

The Rest of World category isn’t a single approach but a collection of national frameworks at varying maturity. China’s Generative AI Measures (effective August 2023) impose specific obligations on generative AI services in mainland China including content moderation, training data lineage, and security assessment requirements. The UK has taken a pro-innovation, regulator-led approach --- no horizontal AI law, but sectoral regulators (FCA, MHRA, ICO, CMA) issuing AI-specific guidance under their existing authority. Singapore’s Model AI Governance Framework and AI Verify provide voluntary frameworks influencing industry practice. Japan’s AI Strategy and AI Promotion Act take a voluntary, principles-based approach with no significant binding obligations. Australia, Canada, Brazil have frameworks under development at varying stages. Few of these regimes create binding cross-border obligations, but they shape industry practice in their markets and increasingly serve as compatibility models that vendors target alongside the EU and US frameworks.

Two practical recommendations for architects designing for multi-jurisdictional deployment. First, design to the strictest applicable framework as the working baseline. In 2026 that generally means the EU AI Act, whose high-risk obligations are the most demanding and most clearly enforceable. A system designed to satisfy EU AI Act high-risk requirements usually satisfies US sectoral obligations, Singapore Model AI Governance recommendations, and most other RoW frameworks as a byproduct. The reverse direction --- designing to US sectoral obligations and trying to satisfy EU AI Act requirements after the fact --- typically requires significant rework. Second, expect the regulatory landscape to keep moving. Colorado SB 24-205 looked like the comprehensive US state-law template until it was replaced ten weeks before its effective date. The EU AI Act’s “AI omnibus” simplification reached political agreement in May 2026 with implementation effects still unfolding. Compliance programs need to be designed for change, not for the regulatory landscape as it stood when the program started.

Chapter 3. The Risk-Tiered Mental Model

The EU AI Act’s four-tier risk classification has become the canonical mental model for AI regulation, not because every framework uses identical tiers but because every working framework needs to do something like risk tiering. Regulations that apply uniformly to all AI systems are too burdensome for low-risk uses and too lenient for high-risk uses; risk-tiered frameworks scale obligations to the actual potential for harm, which is the only design that produces proportionate regulation.

Unacceptable-risk AI is prohibited outright. The EU AI Act’s Article 5 lists the specific practices: social scoring by public authorities; real-time remote biometric identification in publicly accessible spaces (with narrow exceptions for serious crime); AI that materially distorts behavior to cause harm; AI that exploits vulnerabilities of specific groups (children, disabled persons, economically vulnerable people); untargeted scraping of facial images to build recognition databases; emotion inference in workplace or educational settings (with exceptions for medical and safety purposes); biometric categorization by sensitive characteristics; and several other narrowly defined categories. These prohibitions are absolute --- no risk management or mitigation makes them compliant. Effective February 2, 2025; the highest fines in the Act apply to violations (up to €35 million or 7% of global annual turnover).

High-risk AI faces the most extensive obligations and is the category most production systems care about. Annex III of the EU AI Act enumerates the high-risk use cases: biometric identification and categorization; critical infrastructure management (transport, water, gas, heating, electricity); education and vocational training including admissions and evaluation; employment, workers management, and access to self-employment; access to essential private and public services (creditworthiness, public benefits, emergency services); law enforcement; migration, asylum, and border control; administration of justice and democratic processes. AI systems in these categories must have risk management systems, technical documentation, automatic logging, human oversight, accuracy and robustness measures, post-market monitoring, and undergo conformity assessment before being placed on the market. High-risk obligations are effective August 2, 2026 --- the deadline that determines the practical compliance posture for any organization deploying AI in these categories.

Limited-risk AI faces transparency obligations rather than substantive ones. The Act’s Article 50 covers four cases: AI systems intended to interact with humans (chatbots) must disclose their AI nature; AI-generated synthetic content (deepfakes, AI-generated images) must be marked as such; AI used for emotion recognition or biometric categorization must inform subjects; AI-generated text intended to inform on matters of public interest must be labeled. The obligations are operationally light --- they’re about user disclosure rather than internal risk management --- but they apply broadly across consumer-facing AI applications. Effective August 2026.

Minimal-risk AI faces no specific obligations under the Act. The category covers the vast majority of AI systems currently deployed: spam filters, AI-enabled video games, inventory management, recommendation systems, search ranking, autocomplete, sentiment analysis on non-sensitive data, and many more. The Commission’s explicit guidance is that the Act doesn’t introduce rules for AI deemed minimal risk; voluntary codes of conduct are encouraged but not required. For most enterprise deployments, the first question is whether the system falls into one of the higher tiers; if not, the Act’s obligations are minimal.

Other frameworks echo the risk-tiered structure with their own terminology. Colorado’s SB 189 (effective January 2027) scopes obligations to “consequential decisions” --- functionally similar to the EU’s high-risk categories, covering employment, housing, lending, education, healthcare, insurance, legal services, and government benefits. NIST AI RMF’s Generative AI Profile maps risk severity along compatible dimensions (impact on individuals, impact on society, impact on critical infrastructure) and recommends mitigations proportional to risk. NYC AEDT focuses narrowly on automated employment decision tools, a single category that would be high-risk under the EU framework. The mental model is the same across frameworks even when the labels differ; the architect’s first move in any regulatory engagement is to determine which tier the specific AI system falls into, because the tier determines every downstream obligation.

Chapter 4. The Documentation Cascade

Compliance produces documents. The volume of documentation a working compliance program generates is substantial: model cards for each deployed model, data sheets for each training corpus, AI Bills of Materials for the component stack, risk management documentation aligned to NIST AI RMF or ISO 42001, algorithmic impact assessments for high-risk deployments, conformity declarations under the EU AI Act, post-market monitoring reports, incident response records, audit trails, and SOC 2 reports with AI-specific addenda. The volume can feel overwhelming until you understand the cascade structure that connects the documents to each other and to the underlying engineering.

The cascade has four layers. Engineering evidence is the Volume 8 output: test results from DeepEval and Ragas, red-team reports from Garak and PyRIT, guardrail configurations, trace logs from LangSmith and Phoenix, eval datasets, performance metrics. The audience for this layer is the engineering team itself; the format is operational (JSON, code, dashboards). This is what actually exists in the system’s repos and observability platforms.

Technical documentation is the first translation layer. Model cards (the Mitchell et al. 2019 format) summarize what the model does, what it was trained on, how it performs, and what its known limitations are. Data sheets (the Gebru et al. 2018 format) document the training corpus: sources, processing, motivations, recommended uses, known issues. AI Bills of Materials (AIBOMs) list the components: foundation model and version, fine-tuning data, embedding models, third-party tools, dependencies. Training data summaries describe what went into the model in publishable form. The audience for this layer is technical readers who didn’t build the system: other engineers in the organization, integration partners, technical due-diligence reviewers.

Compliance artifacts are the second translation layer, mapped to specific regulatory requirements. Conformity assessments under the EU AI Act document how a high-risk system meets the Act’s requirements. Algorithmic impact assessments (originally a Canadian government tool, adopted in Colorado and elsewhere) document the potential effects of an AI system on rights and outcomes. Risk management documentation aligned to NIST AI RMF or ISO 42001 demonstrates a structured approach to AI risk. Bias audits under NYC AEDT document fairness testing for employment AI. The audience is regulators, auditors, and compliance reviewers; the format follows regulatory templates.

Procurement evidence is the third translation layer, mapping to what enterprise buyers actually want to see in vendor evaluation. SOC 2 reports with AI-specific addenda. Third-party audit attestations. Liability and warranty terms in the contract. Sub-processor disclosures. Incident response plans. Data Protection Impact Assessments (DPIAs) under GDPR. The audience is procurement teams, legal review, and executive sponsors at the buying organization; the format follows enterprise procurement vocabulary and answers the questions buyers ask in their RFP responses and vendor security questionnaires.

The cascade fails in characteristic ways. The most common: engineering produces evidence procurement doesn’t understand, so the deal stalls in vendor security review while the engineering team scrambles to produce translated documentation under time pressure. The second most common: compliance produces documentation without engineering evidence to back specific claims, which works until an auditor or regulator asks for the underlying technical proof and discovers the claims aren’t substantiable. Both failures are correctable if the documentation handoffs are designed deliberately rather than left as implicit overhead. Building the cascade as part of the original system design --- deciding what evidence the engineering will produce, how it will translate into documentation, and what compliance and procurement artifacts the documentation will support --- saves the team from reconstructing evidence under deadline pressure later.

Chapter 5. The Compliance-Engineering Handoff

Compliance is engineering or it’s nothing. A compliance program disconnected from the actual engineering work produces convincing paperwork that auditors and regulators can demolish on their first technical question. A compliance program tightly coupled to the engineering work produces documentation that’s mechanical to generate, easy to update, and defensible under scrutiny because the underlying evidence is real. The difference between the two postures is the deliberateness of the handoff between Volume 8’s engineering mechanisms and Volume 11’s compliance artifacts.

The handoff matrix is concrete. The eval suite (DeepEval, Ragas, Promptfoo runs) produces the performance section of model cards --- accuracy on representative test sets, bias evaluation results across demographic slices, robustness to perturbations. Red-team reports from Garak and PyRIT produce the risk assessment and mitigation log that any regulator-facing risk documentation expects. Guardrail configurations (NeMo Guardrails Colang scripts, Guardrails AI validators, Llama Guard policies) become the safety-measures section of conformity declarations under the EU AI Act. Trace records from LangSmith, Phoenix, or Langfuse become the audit trail for high-risk decisions --- the EU AI Act explicitly requires automatic logging of high-risk AI system events. Bias evaluation results become the substance of algorithmic impact assessments. Training data lineage records become data sheets and AI Bills of Materials. Incident records become post-market monitoring reports. The OWASP LLM Top 10 threat model becomes the security risk documentation.

The handoff is mechanical when the engineering produces traceable evidence. A team that runs DeepEval in CI/CD against versioned test sets, with results stored and queryable, can pull the model card performance section automatically. A team that runs LangSmith tracing with appropriate metadata can produce the audit trail with a query. A team whose training data has lineage tracking from ingestion produces the data sheet from existing metadata rather than reconstructing it from memory. Each Volume 8 mechanism, if instrumented for compliance from the start, produces its corresponding Volume 11 artifact as a byproduct of normal engineering operations.

The handoff is painful when evidence is reconstructed retroactively. A team facing a regulatory deadline that didn’t plan for documentation has to look back at training data they no longer have detailed records of, performance evaluations they ran ad-hoc and didn’t store, incidents they handled informally without logging, and safety measures they implemented without documenting the configuration. The reconstruction work is significant --- frequently weeks of engineering time pulled away from forward progress --- and the results are often incomplete, with gaps the auditor will find and the compliance team will struggle to fill. Most teams encounter this when their first regulated customer asks for a comprehensive vendor security questionnaire, at which point they discover that their excellent engineering didn’t produce the artifacts the customer needs.

Two practical patterns make the handoff mechanical instead of painful. First, treat documentation as a first-class output of the engineering work, not as overhead to be added later. When designing the eval suite, design the model card alongside; when configuring guardrails, document the configuration in the format the conformity declaration will consume; when implementing tracing, include the metadata that audit trails will need. The marginal cost of producing documentation during engineering is small; the marginal cost of producing it retroactively is large. Second, pick one or two regulatory frameworks as the working compliance baseline early. “We’ll figure out compliance when we need it” produces panic-driven retroactive work; “We’re building to NIST AI RMF and EU AI Act high-risk” produces deliberate forward work. The baseline frameworks anchor what documentation is required and what its structure should be; the engineering decisions flow from that anchor.

The deepest practical observation: compliance is a maturity discipline. Organizations that treat it as a forcing function for better engineering produce both better systems and better documentation. Organizations that treat it as separate from engineering produce worse systems and worse documentation, because the disciplines that compliance demands --- versioning, lineage tracking, audit trails, structured evaluation, incident response --- are the same disciplines that produce reliable software in general. The compliance frameworks documented in Part 2 are most useful when treated as engineering quality bars dressed in regulatory language rather than as bureaucratic overhead disconnected from the technical work.

Part 2 — The Substrates

Eight sections follow. Each opens with a short essay on what its entries have in common. Representative substrates are presented in the same Fowler-style template used by the prior ten catalogs, adapted to regulatory frameworks (which have effective dates and jurisdictional scope) and documentation artifacts (which have audience and format conventions) as their primary attributes.

Sections at a glance

• Section A --- Comprehensive AI risk management frameworks

• Section B --- The EU AI Act and its instruments

• Section C --- US state AI regulations

• Section D --- Sector-specific AI governance

• Section E --- International AI governance

• Section F --- Documentation artifacts

• Section G --- Audit and assurance frameworks

• Section H --- Discovery and tracking

Section A — Comprehensive AI risk management frameworks

NIST AI RMF and ISO/IEC 42001 --- the framework backbones for enterprise AI governance

Two frameworks form the backbone of comprehensive AI risk management in 2026. NIST AI RMF (NIST AI 100-1, with the Generative AI Profile NIST AI 600-1) is the US government framework, voluntary but widely adopted as the de facto standard for enterprise AI governance. ISO/IEC 42001 (published December 2023) is the international management-system standard, certification-eligible, modeled on the structure ISO 27001 established for information security.

The two frameworks complement rather than compete. NIST AI RMF is risk-process-focused (Govern, Map, Measure, Manage functions); ISO 42001 is management-system-focused (Plan-Do-Check-Act with organizational requirements). Many regulated enterprises adopt both: NIST AI RMF as the working risk management discipline, ISO 42001 as the certification target that demonstrates the discipline to external auditors. Colorado SB 189 and many other regulations explicitly allow compliance with either as an affirmative defense.

NIST AI Risk Management Framework

Source: nist.gov/itl/ai-risk-management-framework (NIST AI 100-1, January 2023; AI 600-1 Generative AI Profile, July 2024)

Classification Voluntary US government framework for AI risk management; de facto enterprise standard.

Intent

Provide a structured, voluntary framework for managing risks of AI systems across their lifecycle, organized around four core functions (Govern, Map, Measure, Manage) with detailed playbooks, profiles for specific contexts (Generative AI, Government Use), and crosswalks to other frameworks.

Motivating Problem

For US enterprises building AI systems, the absence of a comprehensive federal AI law left a vacuum: which framework defines responsible AI practice for an organization with US operations? NIST AI RMF, released in January 2023 by the National Institute of Standards and Technology under direction from the National AI Initiative Act, filled this vacuum as the federal government’s voluntary recommendation. The voluntary status means it isn’t legally binding for private organizations; the federal endorsement plus the methodological rigor plus the active community involvement made it the de facto standard within 18 months of release. As of 2026 it is the framework most US enterprise AI governance programs anchor to, the framework most state AI laws reference as an affirmative-defense option, and the framework most procurement processes expect to see referenced in vendor documentation.

How It Works

The framework defines four core functions. Govern: cultivate a culture of risk management; establish organizational structures, roles, and policies; map AI risk management to broader enterprise risk management; integrate AI risk considerations across the AI lifecycle. Map: identify context, intended uses, stakeholders, and risks; characterize the AI system and its operating environment; document assumptions and dependencies. Measure: analyze risks using metrics, evaluations, and assessments; track performance against intended outcomes; surface emergent risks during operation. Manage: prioritize risks based on likelihood and impact; allocate resources to risk mitigation; document and communicate decisions; iterate as risks evolve.

Each function decomposes into categories and subcategories with specific suggested actions. The Govern function alone has six categories covering policies, accountability structures, culture, third-party risk, monitoring, and integration with enterprise risk management. The full taxonomy is documented in NIST AI 100-1 with extensive accompanying playbook material providing implementation guidance.

The Generative AI Profile (NIST AI 600-1, published July 2024) extends the framework specifically for generative AI systems, adding 12 risk categories addressing GenAI-specific concerns: CBRN information, confabulation (hallucination), dangerous content, data privacy, environmental risks, human-AI configuration, IP infringement, obscene/degrading content, information integrity, information security, value chain risks, and harmful bias. For each risk category the profile provides specific actions across the four core functions. The Generative AI Profile is the document most current AI compliance work in 2026 references.

Crosswalks to other frameworks (ISO 42001, EU AI Act, OECD AI Principles, NIST SP 800-218A Secure Software Development Framework AI Community Profile) are maintained by NIST and the user community, making it possible to demonstrate compliance with multiple frameworks through coordinated documentation rather than duplicate effort.

When to Use It

US-based enterprise AI deployments where federal-government-endorsed framework matters for procurement or executive sponsor confidence. Multi-jurisdictional deployments needing a working framework that aligns with EU AI Act through crosswalks. Sectors without sector-specific AI regulation that need to demonstrate responsible practice. Organizations seeking affirmative defenses under state AI laws that allow compliance with recognized frameworks (Colorado SB 189).

Alternatives --- ISO/IEC 42001 for the international certifiable equivalent. Sector-specific frameworks (FDA AI/ML for medical, FINRA SR 11-7 for financial) when sectoral coverage is the primary need. EU AI Act conformity assessment when the deployment touches EU markets and high-risk categories.

Sources

• nist.gov/itl/ai-risk-management-framework

• nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

• nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

ISO/IEC 42001

Source: iso.org/standard/81230.html (published December 2023; first international AI management system standard)

Classification International management-system standard for artificial intelligence; certification-eligible.

Intent

Provide an international standard specifying requirements for establishing, implementing, maintaining, and continually improving an AI management system within an organization, structured to align with other ISO management system standards (27001, 9001) and certifiable through accredited third-party audit.

Motivating Problem

For multinational organizations and regulated industries, the question “is our AI governance program adequate” has historically been hard to answer because no internationally-recognized certification existed. ISO/IEC 42001 fills this gap: it specifies management-system requirements an organization must meet to demonstrate structured AI governance, follows the High-Level Structure (HLS) used by ISO 27001 and ISO 9001 so it integrates cleanly with existing management systems, and is certifiable through accredited bodies. Certification provides external evidence of governance maturity that procurement, regulators, and boards accept as a starting point.

How It Works

The standard follows the Plan-Do-Check-Act management system pattern familiar from ISO 27001. The organization defines AI governance objectives (Plan), implements AI risk management processes (Do), monitors and audits performance (Check), and acts on findings to continuously improve (Act). The structure overlaps significantly with ISO 27001 information security management; organizations already certified to 27001 typically find 42001 adds incremental requirements rather than parallel ones.

Specific requirements cover organizational context (understanding the organization’s AI use and stakeholders), leadership (top management commitment, AI policy, roles and responsibilities), planning (AI risks and opportunities, objectives), support (resources, competence, awareness, documented information), operation (AI risk treatment, third-party AI), performance evaluation (monitoring, internal audit, management review), and improvement (nonconformity, corrective action, continual improvement). Annexes provide implementation guidance and a catalog of controls organizations can adopt.

Certification follows the standard ISO certification process: an accredited certification body audits the organization’s AI management system, identifies any nonconformities, issues a certificate after successful audit, and conducts surveillance audits annually. The audit examines documentation, interviews staff, and reviews evidence of the management system in operation. Major certification bodies (BSI, DNV, TÜV SÜD, others) have offered ISO 42001 certification since 2024.

Crosswalks to NIST AI RMF, EU AI Act, and major sectoral frameworks are documented in implementation guides from certification bodies and industry associations. An organization implementing ISO 42001 typically inherits substantial coverage of NIST AI RMF’s Govern function and partial coverage of the other functions, making the combination economical when both are needed.

When to Use It

Multinational deployments where international certification carries procurement weight. Regulated industries (financial services, healthcare, manufacturing) where certification of management systems is an established discipline. Organizations already certified to ISO 27001 (or planning to be) where 42001 adds incremental requirements rather than parallel ones. Vendors selling to enterprises that require certified governance from suppliers.

Alternatives --- NIST AI RMF for the US-focused voluntary equivalent. Sector-specific frameworks when sectoral coverage matters more than horizontal management-system certification. SOC 2 with AI considerations for the audit-attestation alternative that’s more common in software-as-a-service procurement.

Sources

• iso.org/standard/81230.html

• Major certification bodies’ implementation guidance: BSI, DNV, TÜV SÜD, BSI Group

Section B — The EU AI Act and its instruments

Regulation 2024/1689 and the Code of Practice for GPAI providers

The EU AI Act (Regulation 2024/1689) is the most consequential AI regulation in force as of 2026. It entered into force August 1, 2024, with phased application: prohibited practices effective February 2025, General-Purpose AI provider obligations effective August 2025 (with penalties), high-risk system obligations effective August 2026, and full application by August 2027 (with the AI omnibus simplification package agreed politically in May 2026 extending some embedded-product deadlines). For organizations deploying AI systems to EU markets or to EU users, the Act’s obligations are binding and the enforcement infrastructure (national competent authorities, the AI Office, the AI Board) is operational. The Code of Practice for General-Purpose AI providers, developed under Article 56 of the Act, provides implementation guidance for the GPAI provisions specifically.

EU AI Act (Regulation 2024/1689)

Source: eur-lex.europa.eu/eli/reg/2024/1689 (in force August 2024; phased application through 2027)

Classification Binding EU regulation; risk-tiered horizontal AI framework.

Intent

Provide a binding legal framework for AI systems placed on the market or put into service in the EU (or whose output is used in the EU), with risk-tiered obligations scaling from prohibited practices to minimal obligations, ex-ante conformity assessment for high-risk systems, post-market monitoring requirements, and significant fines for non-compliance.

Motivating Problem

The EU’s approach to AI regulation reflects its broader regulatory philosophy: prevent harms ex-ante through structured market-access requirements rather than relying on after-the-fact litigation or sectoral oversight. The Act addresses AI systems’ fundamental-rights implications through binding horizontal obligations applying across all sectors, with the structure adapted from EU product safety regulation (CE marking, conformity assessment, notified bodies, market surveillance). For organizations selling AI into EU markets, the Act is the principal regulatory consideration; for those outside EU markets, the Act’s extraterritorial reach (it applies when AI output is used in the EU regardless of where the system is operated) brings most globally-deployed AI within its scope to some degree.

How It Works

Risk-tier classification is the first move. The Act prohibits specific practices (Article 5: social scoring, exploitative AI, untargeted facial scraping, several others); designates high-risk use cases (Article 6 and Annex III: critical infrastructure, education, employment, essential services, law enforcement, migration, justice, biometrics); imposes transparency obligations on limited-risk AI (Article 50: chatbots, deepfakes, emotion recognition, AI-generated content); and leaves minimal-risk AI unregulated. The first compliance question for any AI system is which tier it falls into.

High-risk obligations are the bulk of the Act’s substantive requirements. Providers of high-risk AI must establish a risk management system (continuous throughout the lifecycle), use high-quality datasets, maintain technical documentation, automatically log events, ensure transparency and user information, provide for human oversight, ensure accuracy and robustness, undergo conformity assessment, and conduct post-market monitoring. Deployers (organizations using the AI system) have parallel obligations including ensuring inputs are appropriate, monitoring operation, keeping logs, and notifying providers and authorities of identified risks.

Conformity assessment is the gating procedure. Most high-risk AI systems undergo internal conformity assessment with the provider self-certifying compliance; specific subcategories (notably biometric identification) require third-party conformity assessment by a notified body. After successful assessment the provider affixes the CE marking, registers the system in the EU database, and may place the system on the market. Significant modifications trigger reassessment.

General-Purpose AI (GPAI) provisions are a separate track. Providers of GPAI models face transparency obligations (technical documentation, summary of training content), copyright compliance, and --- for GPAI models with systemic risk (currently identified by training-compute thresholds at 10^25 FLOPs) --- additional obligations including model evaluation, risk assessment, cybersecurity, and serious incident reporting. The GPAI Code of Practice provides implementation guidance.

Enforcement is multi-layered. National competent authorities in each Member State handle market surveillance and impose fines; the AI Office (within the European Commission) oversees GPAI providers directly; the AI Board coordinates across Member States. Fines scale with violation severity: up to €35 million or 7% of global annual turnover for prohibited-practice violations, up to €15 million or 3% for high-risk obligation violations, up to €7.5 million or 1% for supplying incorrect information. The penalty regime took effect August 2025 for most categories; GPAI penalties begin August 2026.

When to Use It

Any AI system whose output is used in the EU, regardless of where the provider is based. EU-deployed AI systems regardless of risk tier (the Act’s scope determination is itself a required exercise). Multinational deployments where the EU framework typically sets the strictest applicable standard. Conformity assessment is mandatory for high-risk systems before market placement.

Alternatives --- none in the EU jurisdiction. Outside the EU, alternatives are jurisdiction-specific (US sectoral and state-level frameworks, China GenAI Measures, UK pro-innovation approach). Many organizations design to EU AI Act standards globally even when other jurisdictions are less demanding, because the marginal cost of designing once to the strictest standard is lower than maintaining different compliance postures per market.

Sources

• eur-lex.europa.eu/eli/reg/2024/1689

• digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

• artificialintelligenceact.eu/ (community-maintained explanatory site)

GPAI Code of Practice

Source: digital-strategy.ec.europa.eu/en/library/general-purpose-ai-code-practice (developed 2025)

Classification Implementation guidance for General-Purpose AI provider obligations under EU AI Act.

Intent

Provide voluntary implementation guidance for providers of General-Purpose AI models to demonstrate compliance with Articles 53-55 of the EU AI Act, developed through a multi-stakeholder process under the AI Office’s coordination per Article 56 of the Act.

Motivating Problem

The EU AI Act’s GPAI provisions impose obligations on GPAI providers (transparency, copyright compliance, training data summaries; for systemic-risk GPAI also model evaluation, risk assessment, cybersecurity, incident reporting) without specifying in detail how providers should meet them. The Code of Practice, developed through a working-group process involving GPAI providers, civil society, academia, and Member States, translates the high-level obligations into specific commitments and reporting templates. Adherence to the Code is voluntary but presumed to demonstrate compliance with the underlying obligations; non-adherence requires the provider to demonstrate compliance through alternative means.

How It Works

The Code is organized around the GPAI obligations in the Act. The transparency commitment covers what providers should publish about their models: capabilities, limitations, training data characteristics, evaluation methodology, known risks. The copyright commitment covers how providers should respect Union copyright law including the text-and-data-mining opt-out mechanism. The training data summary commitment specifies the format and granularity of the publicly available summary GPAI providers must publish.

For systemic-risk GPAI specifically, the Code adds commitments around the additional Article 55 obligations: model evaluation methodology (covering capability evaluations and adversarial testing), systemic risk assessment processes, cybersecurity protections including model weight security, and serious incident reporting timelines and formats.

The Code’s development through 2025 reflected the practical difficulty of writing implementation guidance for obligations the Act left intentionally flexible. The result is a working document that GPAI providers can adopt as their compliance strategy and that the AI Office uses as the benchmark for assessing GPAI provider compliance. The Code is expected to be revised periodically as GPAI technology and regulatory experience evolve.

When to Use It

Providers of General-Purpose AI models placed on the EU market. Organizations selling GPAI models or services to EU customers. Foundation model providers regardless of headquarters location when their models are used by EU deployers.

Alternatives --- demonstrating compliance with Articles 53-55 through alternative means without Code adherence is permitted but requires the provider to construct and defend its own compliance approach. Few providers find this preferable to Code adherence.

Sources

• digital-strategy.ec.europa.eu/en/library/general-purpose-ai-code-practice

Section C — US state AI regulations

Colorado, California, NYC, Utah, Texas --- the patchwork US state landscape

In the absence of comprehensive federal AI legislation, US states have moved to fill the regulatory gap with frameworks varying widely in scope and stringency. Colorado attempted the most comprehensive approach with SB 24-205 (signed May 2024), but the law was effectively replaced by SB 189 in May 2026 --- a more business-friendly disclosure-based regime that takes effect January 2027. NYC’s Automated Employment Decision Tool (AEDT) law has been enforced since 2023 as the longest-running US AI-specific employment regulation. California has taken a multi-bill approach with narrower laws like AB-2013 on AI training transparency. Utah and Texas have enacted their own frameworks. The resulting patchwork is the working state of US AI regulation in 2026; the federal preemption question remains unresolved.

Colorado: SB 24-205 and its SB 189 replacement

Source: leg.colorado.gov (SB 24-205 signed May 2024; SB 189 passed May 2026, effective January 2027)

Classification Comprehensive US state AI law, transitioning from risk-management regime to disclosure-based regime in May 2026.

Intent

Originally to impose comprehensive risk-management and impact-assessment obligations on developers and deployers of high-risk AI systems making consequential decisions affecting Colorado residents (SB 24-205); replaced in May 2026 by a narrower disclosure-and-consumer-rights framework (SB 189) ahead of the original law’s effective date.

Motivating Problem

The Colorado story illustrates the difficulty of US state-level AI regulation. SB 24-205, signed by Governor Polis in May 2024 (with the governor expressing reservations in his signing letter), was the first comprehensive US state AI law, modeled partly on the EU AI Act and imposing risk-management programs, annual impact assessments, duty of care to prevent algorithmic discrimination, and detailed disclosure obligations. The law’s complexity and compliance burden prompted significant industry pushback. Through 2025 and early 2026 the legislature, industry, and the governor’s AI Policy Working Group negotiated revisions. In May 2026 SB 189 passed both chambers --- a substantial rollback to a notice-and-disclosure framework with limited consumer rights, taking effect January 2027. The original law never reached its enforcement date.

How It Works

SB 189 (the May 2026 replacement) creates two consumer disclosure obligations for deployers of automated decision-making technology (ADMT) used to materially influence consequential decisions about Colorado residents. Pre-use notice: before the ADMT is used to influence a consequential decision, the deployer must provide a clear and conspicuous notice (which can be a point-of-interaction notice) describing the use, the consumer’s rights, and how to obtain additional information. Post-adverse-outcome disclosure: when the consequential decision is adverse to the consumer, the deployer must provide additional information including the principal reasons for the decision and the consumer’s rights to correct erroneous data or appeal.

Consequential decisions are defined narrowly relative to the original SB 24-205: employment, housing, lending, education, healthcare, insurance, legal services, and government benefits. Several categories present in SB 24-205 (consequential decisions broadly defined) were narrowed; some (anti-fraud tools without facial recognition, cybersecurity, narrow procedural assistants) were excluded.

The enforcement mechanism is exclusively the Colorado Attorney General, with no private right of action. The AG must complete rulemaking before enforcement begins; the governor and AG have indicated rulemaking will take months, so practical enforcement is unlikely before mid-2027. SB 189 creates a three-year record retention requirement for deployers and limited transparency obligations for developers (substantially less than under SB 24-205).

The original SB 24-205 framework remains historically relevant. A federal magistrate judge stayed enforcement of SB 24-205 in April 2026; the DOJ and xAI joined a lawsuit challenging its constitutionality. The original law’s framework --- risk management programs, annual algorithmic discrimination impact assessments, duty of reasonable care to prevent algorithmic discrimination, mandatory reporting of credible discrimination risk to the AG --- may inform future rulemaking under SB 189 or shape replacement legislation in other states, even though it never took effect in Colorado.

When to Use It

Organizations using AI to make or materially influence consequential decisions affecting Colorado residents. Multi-state deployments where Colorado is among the covered jurisdictions. Vendors selling AI tools to Colorado deployers in covered domains (employment, housing, lending, etc.).

Alternatives --- SB 189 doesn’t preempt other state frameworks; multi-state deployments must comply with each state’s applicable law. NIST AI RMF or ISO 42001 compliance does not automatically satisfy SB 189 but informs the substantive content of disclosures and record-keeping.

Sources

• leg.colorado.gov/bills/sb24-205

• leg.colorado.gov/bills/sb26-189

• Tracking resources at ailawsbystate.com, troutmanprivacy.com, littler.com

NYC AEDT, California AB-2013, and other state AI laws

Source: Various state and local laws covering specific AI use cases

Classification Narrower-scope US state and local AI laws covering specific domains.

Intent

Cover the patchwork of US state and local AI laws that, taken together, form the working US state regulatory environment for AI in specific domains (employment, transparency, training data, generative AI disclosures).

Motivating Problem

Where Colorado attempted a horizontal state-level framework, most other US states have taken a narrower approach: laws covering specific AI use cases or specific transparency obligations rather than comprehensive risk management. The resulting patchwork is operationally complex for multi-state deployers but legally simpler than the EU AI Act’s comprehensive structure. Each law has its own scope, obligations, and enforcement mechanism; compliance requires identifying which laws apply to which AI systems in which states.

How It Works

NYC Automated Employment Decision Tool (AEDT, Local Law 144 of 2021, effective July 2023): NYC employers using automated employment decision tools (AI for hiring, promotion, employment-related decisions) must conduct annual bias audits by independent auditors, publish audit summaries, and notify candidates that an AEDT is being used. The law was the first AI-specific employment regulation enforced in the US and established the bias-audit pattern other jurisdictions have considered.

California AB-2013 (Generative AI Training Data Transparency, signed September 2024, effective January 2026): Developers of generative AI systems must publish on their website summary information about the data used to train the system, including the source, ownership, time period covered, copyright status, and personal information handling. The law applies to generative AI made publicly available in California.

California SB-942 (AI Transparency Act, signed September 2024, effective January 2026): Covered providers of generative AI systems with over 1 million users must provide free AI detection tools and require user-visible disclosures on AI-generated content. The law targets deepfake and synthetic-content concerns specifically.

Utah SB 149 (Artificial Intelligence Policy Act, effective May 2024): Requires consumer-facing AI to disclose its AI nature when directly asked, and creates a regulatory sandbox for AI innovation. The law’s scope is narrower than Colorado’s but its early effective date made it the first comprehensive state AI law to take effect.

Texas HB 149 (Texas Responsible AI Governance Act, effective 2026): Comprehensive framework imposing disclosure and risk-management obligations on developers and deployers of high-risk AI systems used in Texas, structured similarly to but with different specifics than Colorado’s original SB 24-205.

Other state activity: California’s vetoed SB 1047 (foundation model safety, 2024) shaped subsequent legislative proposals; Florida, Pennsylvania, Nebraska, and others have AI-related laws covering narrower domains; the state legislative landscape continues to evolve faster than this catalog can track.

When to Use It

Multi-state US deployments need state-by-state mapping: which AI systems are used in which states, which laws apply, what obligations result. The mapping is operationally complex but legally tractable for narrow-scope laws covering specific domains.

Alternatives --- federal preemption (not yet enacted, repeatedly proposed). Designing to the strictest state framework as the working baseline produces deployment-time simplification at higher initial compliance cost.

Sources

• ailawsbystate.com (tracking resource)

• iapp.org/resources/article/global-ai-legislation-tracker/ (international tracker)

• Direct legislative sources for each state

Section D — Sector-specific AI governance

FDA, financial services Model Risk Management, and HIPAA implications

Where horizontal AI regulation in the US has lagged, sectoral regulators have moved aggressively to apply their existing authority to AI systems. The FDA’s framework for AI/ML-enabled medical devices, originally proposed in 2019 and substantially developed through 2023-2025 guidance documents, governs AI in healthcare products. The financial services sector applies Model Risk Management practices originally codified in SR 11-7 (Federal Reserve, 2011) to AI models, with significant updates in 2023-2025 OCC and Federal Reserve guidance reflecting GenAI-specific concerns. HIPAA’s privacy and security rules apply to AI processing protected health information, with HHS Office for Civil Rights issuing AI-specific guidance addressing healthcare AI.

These sectoral frameworks predate the horizontal AI laws in most cases and continue to evolve independently of them. For organizations in regulated sectors, the sectoral framework is the binding constraint; horizontal frameworks like NIST AI RMF and EU AI Act apply in addition but typically don’t supersede sector-specific obligations.

FDA AI/ML guidance for medical devices

Source: fda.gov (Software as a Medical Device framework; AI/ML Action Plan 2021; Predetermined Change Control Plan guidance 2024; AI/ML-enabled device list 2025)

Classification US sectoral framework for AI/ML in regulated medical products.

Intent

Establish how the FDA regulates AI/ML-enabled medical devices throughout their lifecycle, with specific guidance on premarket submission, software changes (Predetermined Change Control Plans), and post-market monitoring of AI/ML medical devices.

Motivating Problem

AI/ML in medical devices presents specific regulatory challenges: continuous learning from real-world data is incompatible with traditional medical device regulatory frameworks that assume devices don’t change after market authorization; bias in training data has clinical consequences that may emerge only in deployment; transparency and explainability requirements differ from device performance in physical hardware. The FDA’s framework, developed iteratively since 2019, addresses these challenges with AI-specific guidance layered on top of the Software as a Medical Device (SaMD) regulatory framework.

How It Works

Software as a Medical Device classification: AI/ML medical devices are classified by intended use and risk level (Class I, II, III), with corresponding regulatory pathways (510(k), De Novo, Premarket Approval). The classification determines what evidence the FDA requires for market authorization.

Predetermined Change Control Plan (PCCP) framework: Recognizing that AI/ML models benefit from ongoing learning, the FDA established PCCPs as a mechanism for sponsors to specify in advance the changes they intend to make to an approved AI/ML device. A PCCP describes anticipated modifications (which parameters may be retrained, which inputs may be added, which performance characteristics may evolve), the methodology for implementing changes (validation procedures, performance criteria), and impact assessment (how changes will be evaluated for safety and effectiveness). PCCP guidance issued in December 2024 formalizes this approach; devices with approved PCCPs can implement specified changes without new submissions.

AI/ML Action Plan and ongoing guidance: The FDA published its AI/ML Action Plan in January 2021 outlining five planned actions; subsequent guidance documents have addressed Good Machine Learning Practice (GMLP) principles, transparency for AI/ML-enabled medical devices, and the lifecycle approach to AI/ML medical device regulation. The agency maintains a public list of AI/ML-enabled medical devices that have received FDA authorization, providing market visibility into authorized AI medical products.

Sector-specific intersections: For AI/ML medical devices, HIPAA Privacy Rule applies to protected health information used in training and deployment; FTC consumer protection authority applies to claims about device performance; state medical practice laws apply to clinical implementation. The FDA framework is necessary but not sufficient for the full healthcare AI compliance picture.

When to Use It

Any AI/ML system intended to be used as a medical device under FDA jurisdiction --- software intended to diagnose, treat, mitigate, or prevent disease; software providing clinical decision support; software for medical imaging interpretation. The intended-use determination is critical; software with explicit medical claims is regulated regardless of whether the developer intended medical-device status.

Alternatives --- for software providing general wellness information without specific medical claims, FDA jurisdiction may not apply (though FTC consumer protection and state law still apply). For software supporting healthcare workflows without making medical decisions, the regulatory analysis is fact-specific.

Sources

• fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device

• fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabled-medical-devices

Financial services Model Risk Management (SR 11-7 and successors)

Source: federalreserve.gov SR 11-7 (April 2011); OCC Bulletin 2011-12; subsequent updates

Classification US financial services framework for managing risk from quantitative models, including AI/ML models.

Intent

Establish supervisory expectations for managing risk associated with quantitative models used by financial institutions, originally focused on credit and market risk models but extended through subsequent guidance to AI/ML models. The framework predates modern AI by over a decade but its discipline (model development, validation, ongoing monitoring, governance) maps onto AI/ML model management directly.

Motivating Problem

Financial institutions use quantitative models for high-stakes decisions: credit underwriting, market risk measurement, fraud detection, capital adequacy, anti-money-laundering, customer interaction. Model errors translate directly to financial and regulatory consequences. SR 11-7 (jointly issued by the Federal Reserve and OCC in 2011) established the supervisory expectation that financial institutions have model risk management programs covering the full model lifecycle. The framework treats AI/ML models as a subset of quantitative models, with the same risk management discipline applying with appropriate adaptations for AI-specific concerns (training data bias, explainability, drift, adversarial robustness).

How It Works

Three pillars structure: model development and implementation (controls during model construction including data quality, methodology selection, documentation, testing); model validation (independent challenge of model design, implementation, and use; effective challenge requires expertise, status, and influence to provide meaningful review); ongoing monitoring (performance tracking, outcomes analysis, change management). The three pillars apply across all model types including AI/ML.

Governance structure: Model risk management requires defined organizational structure including senior management oversight, model risk function (often within the second line of defense), model inventory (comprehensive registry of all models in use), and risk tiering (models prioritized by materiality with proportionate management attention).

AI/ML-specific extensions: Through 2023-2025 the OCC and Federal Reserve have issued guidance addressing AI/ML-specific concerns: bias testing in model validation, explainability requirements for high-stakes models, third-party AI risk management (model risk extends to vendor and open-source models), drift monitoring for AI models that may degrade as data distributions shift. The Generative AI use case (LLMs in customer interaction, document analysis, code generation) is the active frontier of regulatory development; institutional practice is evolving faster than formal guidance.

Examination focus: Federal Reserve and OCC examiners actively review model risk management programs during institutional examinations; AI/ML model governance is increasingly part of standard examination scope. Deficiencies result in matters requiring attention, supervisory letters, and in severe cases enforcement actions. Practical implementation matters more than documentation: examiners look for evidence that the model risk management program actually constrains and informs the use of models, not just that the policies exist.

When to Use It

All financial institutions supervised by the Federal Reserve, OCC, or FDIC. AI/ML used in customer-facing decisions, risk measurement, regulatory reporting, or any other quantitative model function. Vendor AI/ML used in financial services (third-party model risk extends to vendor models).

Alternatives --- in financial services, none. Outside financial services, sectoral equivalents (FAA for aviation, NRC for nuclear, EPA for environmental) apply their own risk-management frameworks to AI/ML in their domains.

Sources

• federalreserve.gov/supervisionreg/srletters/sr1107.htm

• occ.gov (bulletin 2011-12 and successor guidance)

• FFIEC interagency examination guidance on AI/ML

HIPAA and AI in healthcare

Source: hhs.gov Office for Civil Rights (HIPAA Privacy and Security Rules; AI-specific guidance)

Classification US privacy and security framework for protected health information processing, applied to AI/ML systems.

Intent

Apply existing HIPAA Privacy and Security Rule obligations to AI/ML systems that process protected health information (PHI), with additional considerations addressing AI-specific risks (training data PHI exposure, model memorization, output PHI disclosure).

Motivating Problem

AI/ML systems in healthcare process protected health information at scale: training corpora that may include PHI; production inference with PHI inputs; outputs that may include PHI; logs and traces that may persist PHI. HIPAA’s Privacy Rule (limiting use and disclosure of PHI) and Security Rule (administrative, physical, technical safeguards) apply throughout, with the model and its data processing constituting Business Associate activities when the AI is provided by a third party to a covered entity.

How It Works

Covered Entities and Business Associates: HIPAA applies to Covered Entities (healthcare providers, health plans, healthcare clearinghouses) and to Business Associates (entities performing services for Covered Entities involving PHI). AI vendors providing services to healthcare organizations are Business Associates and require Business Associate Agreements (BAAs) governing PHI handling.

Training data implications: If PHI is used in training AI/ML models, the use must comply with HIPAA --- typically through patient authorization, de-identification (Safe Harbor or Expert Determination methods), or a Limited Data Set with appropriate Data Use Agreement. De-identification’s adequacy for AI training is an active area of regulatory and academic concern (re-identification risk from model outputs, membership inference attacks).

Output disclosure risk: AI/ML models may memorize and reproduce training data including PHI. Output filtering, training-time differential privacy, and post-deployment monitoring address this risk. Volume 8’s PII detection guardrails apply directly.

Security Rule implementation: The Security Rule’s administrative, physical, and technical safeguards apply to AI/ML systems processing PHI. Access controls, audit logs, encryption, transmission security, integrity protections --- the standard security discipline plus AI-specific additions (model weight protection, prompt injection defenses, training data security).

AI-specific HHS guidance: HHS Office for Civil Rights has issued guidance addressing AI applications including the use of AI in clinical decision support, anti-discrimination requirements under Section 1557 of the Affordable Care Act applied to AI, and intersection with the FDA framework for AI/ML medical devices.

When to Use It

Any AI/ML system that processes protected health information directly or through training. AI vendors selling to US healthcare organizations. Healthcare AI deployments in hospitals, clinics, payers, and life sciences. Any AI/ML medical device under FDA jurisdiction also subject to HIPAA when processing PHI.

Alternatives --- none for US healthcare. International healthcare AI faces analogous frameworks (GDPR health-data provisions, NHS Code of Practice in UK, sector-specific laws in EU member states). De-identification of training data can remove HIPAA applicability to the training stage if performed adequately, but production processing of PHI remains regulated.

Sources

• hhs.gov/hipaa

• hhs.gov/ocr (Office for Civil Rights AI guidance)

• hhs.gov/about/agencies/asfr/hsr-rules.html

Section E — International AI governance

China generative AI measures and the varied Rest-of-World frameworks

Outside the EU and US, AI governance frameworks vary in approach, maturity, and binding force. China’s framework is the most distinct: binding measures specific to generative AI, recommendation algorithms, and deep synthesis, with substantive obligations enforced by the Cyberspace Administration of China. The UK has taken a pro-innovation regulator-led approach: no horizontal AI law, but sectoral regulators issuing AI-specific guidance under existing authority. Singapore’s Model AI Governance Framework provides voluntary guidance that has influenced industry practice. Japan, Australia, Canada, Brazil have frameworks at various stages of development. The collection doesn’t form a coherent international regime, but the frameworks shape industry practice in their markets and provide compatibility models that vendors increasingly target.

China generative AI measures and related frameworks

Source: Cyberspace Administration of China (CAC); Generative AI Measures effective August 2023

Classification Binding Chinese framework for generative AI services and related algorithms.

Intent

Regulate generative AI services, algorithmic recommendation systems, and deep synthesis (synthetic media) provided to users in mainland China through specific, binding obligations enforced by the Cyberspace Administration of China and other regulators.

Motivating Problem

China was the first major jurisdiction to enact binding generative-AI-specific regulation. The Interim Measures for the Management of Generative Artificial Intelligence Services (effective August 15, 2023) established obligations specific to generative AI, building on earlier regulations covering algorithmic recommendations (2022) and deep synthesis (2023). The framework reflects the Chinese regulatory philosophy: substantive obligations on service providers, prior security assessment for high-impact services, content moderation aligned to Chinese social and political requirements, and ongoing administrative oversight. For organizations providing generative AI services to users in mainland China, the framework is binding and the enforcement infrastructure is active.

How It Works

Scope: The Generative AI Measures apply to generative AI services provided to the public in mainland China. Public services include consumer-facing chatbots, image generation tools, and other generative AI accessible to end users. Internal enterprise uses, services explicitly limited to research, and services available only outside mainland China are out of scope.

Substantive obligations: Providers must implement content moderation aligned to Chinese law including the prohibition on content endangering national security, inciting subversion, undermining national unity, or violating social ethics. Training data sources must be lawful; intellectual property of others must be respected. Service providers must label generated content as AI-generated. User identity verification (real-name registration) is required. Algorithm filing with the CAC is required for services with public opinion or social mobilization potential.

Security assessments: Generative AI services with the potential to mobilize public opinion or with significant social impact must undergo security assessment before deployment. The assessment process is administered by the CAC and provincial counterparts; the criteria are substantive and include content compliance, technical safety, and operational maturity. The assessment is a prerequisite to lawful operation for in-scope services.

Related frameworks: The Algorithmic Recommendation Provisions (effective March 2022) cover recommendation algorithms broadly with obligations on transparency, user rights, and content moderation. The Deep Synthesis Provisions (effective January 2023) cover synthetic media specifically, with marking and consent requirements. The Personal Information Protection Law (PIPL, effective November 2021) provides the underlying data protection framework that intersects with AI processing of personal information.

When to Use It

Any generative AI service provided to users in mainland China. Cross-border services accessible to Chinese users (the framework’s extraterritorial reach is unsettled but actively asserted). Recommendation algorithms used by services operating in mainland China. Synthetic media services in mainland China.

Alternatives --- within the People’s Republic of China, none. Services unavailable in mainland China are not subject to the framework but should consider its substantive standards as a likely template for other jurisdictions adopting similar substantive obligations.

Sources

• cac.gov.cn (Cyberspace Administration of China)

• Multiple legal commentary sources covering Chinese AI regulation; few are official English-language translations

UK, Singapore, Japan, and other emerging frameworks

Source: Various national frameworks at varying maturity

Classification Voluntary or sector-led AI governance frameworks influencing industry practice.

Intent

Cover the collection of national AI governance frameworks outside the EU, US, and China that shape industry practice in their markets through voluntary frameworks, sectoral guidance, or developing legislation.

Motivating Problem

Many jurisdictions outside the EU, US, and China have AI governance frameworks at varying stages of development. Few create binding cross-border obligations, but they shape industry practice in their markets and influence how vendors design products targeting those markets. The collection isn’t coherent enough to treat as a single regulatory regime, but it’s influential enough that architects with multi-jurisdictional deployments need to track it.

How It Works

United Kingdom: Pro-innovation, regulator-led approach. No horizontal AI law; the AI Safety Institute (formerly AI Safety Summit framework) focuses on frontier model safety. Sectoral regulators (FCA for financial services, MHRA for medical, ICO for data protection, CMA for competition) issue AI-specific guidance under their existing authority. The Algorithmic Transparency Recording Standard provides a voluntary framework for public-sector AI transparency. Future legislation has been considered but not enacted at scale.

Singapore: Model AI Governance Framework (first edition 2019, second edition 2020, generative AI edition 2024) provides voluntary guidance covering accountability, ethics, transparency, fairness, and reliability. AI Verify is the testing framework operationalizing the Model AI Governance Framework. The Infocomm Media Development Authority (IMDA) administers both. Singapore’s influence exceeds its market size because the framework is methodologically rigorous and widely adopted as a compatibility model.

Japan: AI Strategy (2019, revised 2023) and the AI Promotion Act (2024) provide a principles-based, voluntary framework. The approach favors industry self-regulation and government-industry cooperation over binding requirements. Sector-specific guidance from METI and other ministries supplements the horizontal framework.

Other jurisdictions: Australia has produced voluntary frameworks through the Australian Government and the Australian Human Rights Commission; binding legislation is under consideration. Canada’s Artificial Intelligence and Data Act (AIDA) was introduced as part of Bill C-27 but stalled; provincial frameworks (Quebec Law 25) cover narrower domains. Brazil’s Artificial Intelligence Bill (PL 2338/2023) is under legislative consideration. South Korea, India, and other major economies have AI strategies under development.

When to Use It

Multi-jurisdictional deployments where any of these markets is in scope. Cases where compatibility with international frameworks (Singapore Model AI Governance, OECD AI Principles) is valued by procurement or regulators. Tracking jurisdictions likely to enact binding frameworks in the near future.

Alternatives --- for binding compliance, the EU AI Act, China measures, and US federal-and-state frameworks are the primary considerations. The frameworks in this entry shape industry practice but generally don’t create binding obligations crossing borders.

Sources

• AI Safety Institute (UK)

• AI Verify Foundation and IMDA (Singapore)

• iapp.org/resources/article/global-ai-legislation-tracker/

• OECD AI Policy Observatory

Section F — Documentation artifacts

Model Cards, Data Sheets, and AI Bills of Materials

Across regulatory frameworks the common substrate is documentation: structured artifacts that translate engineering work into formats other audiences can review. Three documentation patterns recur across virtually every regulatory framework and procurement context. Model Cards (Mitchell et al. 2019) summarize what a model does, how it performs, and what its limitations are. Data Sheets (Gebru et al. 2018) document the training corpus. AI Bills of Materials (AIBOMs) list the components in the AI system stack. These patterns predate most binding regulation; the regulations adopted them rather than inventing alternatives, which means investing in them satisfies multiple regulatory frameworks simultaneously.

Model Cards and Data Sheets

Source: Mitchell et al. 2019 (Model Cards); Gebru et al. 2018 (Datasheets for Datasets); widely adopted standards

Classification Standard documentation formats for AI models and training datasets.

Intent

Provide standardized documentation formats summarizing what AI models do (Model Cards) and what data they were trained on (Data Sheets), with enough structure to be machine-readable and enough flexibility to apply across model types.

Motivating Problem

AI models and their training data require documentation that goes beyond traditional software documentation: performance characteristics across demographic groups (not just averages), training data composition and processing, intended uses and out-of-scope uses, known limitations and failure modes, ethical considerations. Model Cards (introduced by Margaret Mitchell and colleagues at Google in 2019) and Data Sheets (introduced by Timnit Gebru and colleagues in 2018) provided the foundational formats. Both formats have been adopted across the field as the standard way to document AI systems for non-engineer audiences.

How It Works

Model Card sections: Model Details (basic information, version, type, contact, license), Intended Use (primary intended uses, primary intended users, out-of-scope use cases), Factors (relevant demographic factors, environmental conditions, instrumentation), Metrics (model performance measures, decision thresholds, variation approaches), Evaluation Data (datasets used, motivation, preprocessing), Training Data (datasets, motivation, preprocessing), Quantitative Analyses (performance broken down by factors), Ethical Considerations (data sensitivities, mitigations), Caveats and Recommendations.

Data Sheet sections: Motivation (purpose, creators, funding), Composition (instances, sampling, missing data), Collection Process (data acquisition, mechanisms, consent), Preprocessing (cleaning, labeling, transformation), Uses (intended uses, restrictions), Distribution (third-party sharing, licensing), Maintenance (updates, deprecation).

Format flexibility: Both formats are templates rather than rigid schemas. Hugging Face’s Model Card format is the most widely-used machine-readable variant; many organizations have internal Model Card templates with additional sections for their specific governance requirements. The structure adapts to the AI system type (the Model Card for a foundation model differs from the Model Card for a fine-tuned classifier in scope and emphasis).

Regulatory uptake: The EU AI Act’s technical documentation requirements substantially overlap with Model Card content. NIST AI RMF references Model Cards as a recommended artifact. ISO 42001 documentation requirements include Model-Card-style content. NYC AEDT bias audit summaries are essentially partial Model Cards focused on fairness metrics. Producing Model Cards as a standard engineering output satisfies multiple regulatory requirements through one artifact.

When to Use It

Every deployed AI model in any organization with documentation obligations to anyone outside the immediate engineering team. Procurement responses for AI products. Regulatory submissions where structured AI documentation is required. Internal governance where boards and risk committees review AI deployments.

Alternatives --- organization-specific documentation formats can work but typically translate poorly to external audiences and regulatory frameworks that increasingly cite Model Cards by name. The investment in adopting standard formats pays off in reduced translation friction.

Sources

• arxiv.org/abs/1810.03993 (Model Cards for Model Reporting, Mitchell et al.)

• arxiv.org/abs/1803.09010 (Datasheets for Datasets, Gebru et al.)

• huggingface.co/docs/hub/model-cards (operational Model Card format)

AI Bills of Materials (AIBOM)

Source: Various emerging standards; Linux Foundation, CISA, NIST guidance

Classification Component inventory documentation for AI systems, modeled on Software Bills of Materials.

Intent

Provide a structured inventory of components, dependencies, and provenance information for AI systems, modeled on Software Bills of Materials (SBOMs) used in software supply-chain security, adapted to capture AI-specific components (foundation models, fine-tuning data, embedding models, prompts as code).

Motivating Problem

AI systems have complex supply chains: a deployed AI agent might depend on a foundation model from one vendor, fine-tuning data from a second source, an embedding model from a third vendor, a vector database from a fourth, retrieval framework from a fifth, prompt templates curated internally, third-party tool integrations, and many other components. Tracking the supply chain matters for security (which components have known vulnerabilities), compliance (which licenses apply, which countries’ export controls apply), and incident response (what changed when the system’s behavior shifted). AIBOMs apply the SBOM discipline to AI systems.

How It Works

Component inventory: The AIBOM lists every component in the AI system stack with identifying information: foundation models (provider, model identifier, version, fine-tuning history), datasets (source, version, processing, license), embedding models, retrieval components, orchestration frameworks, third-party tools, prompts and prompt templates (when treated as code).

Provenance and license information: For each component, the AIBOM records where it came from (vendor, repository, internal team), what license applies (with particular attention to model weights and training data licenses), and any restrictions on use. The license inventory is critical for IP compliance --- model weight licenses vary substantially (Apache 2, MIT, custom community licenses, commercial-only licenses) and downstream restrictions cascade.

Vulnerability and risk information: Like SBOMs, AIBOMs support vulnerability tracking. Known issues with specific model versions (bias issues, jailbreak vulnerabilities, training data concerns) can be tracked against the AIBOM’s component list. The pattern is the same as software vulnerability management; the components and concerns differ.

Standards development: AIBOM is an emerging discipline rather than a fully standardized format. The Linux Foundation’s SPDX format has been extended to cover AI components; CycloneDX has added AI-specific extensions; CISA and NIST have issued guidance on AI supply-chain security that informs AIBOM development. As of 2026 no single AIBOM format dominates; the discipline is the meaningful adoption, with format conventions to follow.

When to Use It

Production AI deployments needing supply-chain visibility for security, compliance, or incident response purposes. Regulated industries where supply-chain documentation is expected. Multi-vendor AI stacks where understanding which component is responsible for what behavior requires explicit inventory.

Alternatives --- ad-hoc inventory in spreadsheets or wikis works for simple stacks but doesn’t scale; the AIBOM discipline becomes valuable as the stack complexity grows. SBOM tooling extended to AI components is the working pattern for organizations with mature software supply-chain practices.

Sources

• cisa.gov (AI supply chain guidance)

• spdx.dev (SPDX format with AI extensions)

• cyclonedx.org (CycloneDX format with AI-BOM extensions)

Section G — Audit and assurance frameworks

SOC 2 with AI considerations and emerging AI assurance services

Enterprise procurement of AI services typically requires audit-attested evidence of governance. SOC 2 (Service Organization Control 2) is the dominant audit framework for software-as-a-service procurement in the US; AI-specific SOC 2 considerations have emerged as auditors and AI vendors developed approaches to covering AI governance in standard SOC 2 reports. Beyond SOC 2, dedicated AI assurance services (offered by major audit firms, specialized AI auditors, and emerging assurance frameworks) provide third-party validation of AI governance programs. The market is young; the conventions are emerging; the procurement demand is real and growing.

SOC 2 with AI considerations and emerging AI assurance services

Source: AICPA (SOC 2 framework); major audit firms’ AI assurance practices; emerging assurance standards

Classification Audit-attested evidence of AI governance, integrated with established SOC 2 framework or as standalone assurance.

Intent

Provide audit-attested evidence of AI governance practices through SOC 2 reports with AI-specific Trust Services Criteria considerations or through standalone AI assurance services, in formats that enterprise procurement accepts as third-party validation.

Motivating Problem

Enterprise buyers of AI services need third-party attestation that the vendor’s AI governance is adequate. The vendor cannot self-attest; the buyer’s in-house assessment is often insufficient; an established auditor providing structured attestation provides procurement evidence that scales. SOC 2 is the working framework most US enterprise procurement processes accept; AI considerations have been integrated into SOC 2 examinations as the demand grew through 2024-2026. Beyond SOC 2, dedicated AI assurance services address governance specifically with deeper AI-focused examination.

How It Works

SOC 2 framework: AICPA’s SOC 2 examination produces attestation reports addressing Trust Services Criteria across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type 1 reports describe controls in place at a point in time; Type 2 reports describe controls operating effectively over a period (typically 6-12 months). The audit is conducted by a CPA firm following AICPA standards.

AI considerations integration: Through 2024-2025 the major audit firms developed approaches to integrating AI governance into SOC 2 examinations. Controls covering AI-specific concerns --- model governance, training data handling, output filtering, bias evaluation, third-party AI risk --- are evaluated under the standard Trust Services Criteria with AI-specific testing procedures. The result is a standard SOC 2 report that covers AI alongside other in-scope services, accepted by procurement processes already familiar with SOC 2 evaluation.

Dedicated AI assurance: Beyond SOC 2 integration, dedicated AI assurance services have emerged. Major audit firms (Deloitte, EY, PwC, KPMG) offer AI assurance practices providing deeper examination of AI governance. Specialized AI auditors (Babl AI, Holistic AI, others) focus exclusively on AI assurance. Emerging standards (ISO/IEC 42006 for AI management system audits; Singapore AI Verify) provide structured frameworks for AI-specific assurance.

Format expectations: Procurement processes typically accept the SOC 2 Type 2 report with AI considerations as adequate third-party validation. The report’s acceptance depends on the auditor’s reputation, the scope of services covered, the controls tested, and the absence of significant exceptions. Dedicated AI assurance reports are increasingly accepted in regulated industries and high-stakes procurement; their format and acceptance criteria are still developing.

When to Use It

AI service vendors selling to enterprise customers that require audit-attested evidence of governance. Regulated industries where audit attestation is expected as a baseline. Procurement-driven compliance where the buyer’s requirements drive the vendor’s assurance investment.

Alternatives --- specific regulatory certifications (ISO 42001 certification, EU AI Act conformity assessment) where they apply. Buyer-conducted audits where the buyer has the capability and the vendor accepts the access. Self-attestation where the buyer-vendor relationship doesn’t require third-party validation.

Sources

• aicpa-cima.com (SOC 2 framework)

• Major audit firms’ AI assurance practice publications

• ISO/IEC 42006 (AI management system audit requirements; under development)

Section H — Discovery and tracking

Resources for staying current as the regulatory landscape continues to move

AI regulation moves faster than any catalog can keep up with. The frameworks documented in this volume will see updates, replacements, and supplements within 12 months of publication. Effective architects in 2026 don’t rely on a static reference; they rely on tracking infrastructure that monitors regulatory developments and surfaces what matters. The resources documented here are the working tracking infrastructure as of mid-2026.

Regulatory tracking resources and discovery infrastructure

Source: Various trackers and resources for monitoring AI regulatory developments

Classification Discovery and tracking resources for the AI regulatory landscape.

Intent

Provide pointers to the tracking infrastructure that monitors AI regulatory developments across jurisdictions, sectors, and frameworks, updated continuously by communities of practice, law firms, advocacy organizations, and government agencies.

Motivating Problem

No printed catalog of AI regulations is current six months after publication. Colorado SB 24-205 was the canonical comprehensive US state law in March 2026 and effectively replaced by May 2026. The EU AI Act’s “AI omnibus” simplification reached political agreement in May 2026 with implementation effects unfolding through 2026 and 2027. State-level US activity continues every legislative session. Sector-specific guidance emerges from FDA, FINRA, OCC, HHS, EEOC, and other regulators on rolling timelines. Tracking the landscape requires continuous monitoring, not periodic reading.

How It Works

International trackers: IAPP’s Global AI Legislation Tracker tracks AI legislation across major jurisdictions. The OECD AI Policy Observatory provides international comparison. The Future of Life Institute’s EU AI Act Newsletter tracks EU developments specifically. Major law firms (DLA Piper, Latham & Watkins, Hogan Lovells, others) publish AI regulation updates that consolidate recent developments.

US state-level: AI Laws by State (ailawsbystate.com) tracks US state AI legislation comprehensively. State attorney general guidance and enforcement actions provide on-the-ground enforcement signal. State legislative tracking services (LexisNexis, Westlaw, Bloomberg Law) provide subscription-based comprehensive tracking.

Sector-specific: FDA AI/ML guidance updates through fda.gov; Federal Reserve supervisory letters through federalreserve.gov; FINRA and OCC bulletins through their respective sites; HHS Office for Civil Rights guidance through hhs.gov/ocr. Each agency publishes on its own schedule; tracking requires subscribing to multiple feeds.

Industry resources: NIST AI Resource Center (airc.nist.gov) provides US government resources. The AI Office (digital-strategy.ec.europa.eu) provides EU resources. The AI Safety Institute (UK) and AI Verify Foundation (Singapore) provide their respective national resources. The Partnership on AI and other industry associations publish research and guidance.

Practical pattern: Most enterprise compliance functions maintain a regulatory tracking spreadsheet or specialized GRC tool, populated from the sources above, with assigned owners for each tracked framework. Quarterly review identifies changes; ad-hoc reading addresses urgent developments. The maintenance burden is real; the alternative (discovering regulatory changes through enforcement) is worse.

When to Use It

Any organization with AI governance responsibilities that must stay current with regulatory developments. Compliance programs that need quarterly or more frequent updates. Architects evaluating new deployments who need to know what regulations apply at design time rather than after launch.

Alternatives --- outsourcing tracking to external counsel works for specific high-stakes deployments but doesn’t scale across the breadth of AI use cases. The combination of self-tracked frameworks and outside counsel for specific deep dives is the working pattern for most enterprise compliance programs.

Sources

• iapp.org/resources/article/global-ai-legislation-tracker/

• oecd.ai (OECD AI Policy Observatory)

• airc.nist.gov (NIST AI Resource Center)

• digital-strategy.ec.europa.eu (EU AI Office and policy resources)

• ailawsbystate.com (US state tracking)

Appendix A --- Framework Reference Table

Cross-reference of the major AI governance frameworks covered in this volume with status, effective dates, and type.

Framework	Status	Effective	Type
NIST AI RMF + GenAI Profile	Voluntary; US federal	January 2023 / July 2024	Risk-process framework with playbooks
ISO/IEC 42001	Voluntary; certifiable	December 2023	Management-system standard
EU AI Act	Binding; EU regulation	Phased: Feb 2025–Aug 2027	Risk-tiered horizontal framework
Colorado SB 189	Binding; state law	January 2027 (with rulemaking)	Disclosure-based framework
NYC AEDT	Binding; local law	July 2023 (enforced)	Employment AI bias audit
FDA AI/ML for medical devices	Binding; US federal	Ongoing	Medical device pathway with AI extensions
SR 11-7 + AI/ML extensions	Supervisory expectation	April 2011 + updates	Financial services model risk
HIPAA + AI applications	Binding; US federal	Ongoing	Healthcare PHI protection
China GenAI Measures	Binding; PRC regulation	August 2023	Generative AI service obligations
Singapore Model AI Governance	Voluntary; influential	2019/2024	Voluntary framework + AI Verify testing

Appendix B --- The Eleven-Volume Series

This catalog joins the ten prior volumes to form an eleven-layer vocabulary for agentic AI.

• Volume 1 --- Patterns of AI Agent Workflows --- the timing of agent runs.

• Volume 2 --- The Claude Skills Catalog --- model instructions in packaged form.

• Volume 3 --- The AI Agent Tools Catalog --- the function-calling primitives.

• Volume 4 --- The AI Agent Events & Triggers Catalog --- the activation layer.

• Volume 5 --- The AI Agent Fabric Catalog --- the infrastructure substrate.

• Volume 6 --- The AI Agent Memory Catalog --- the state and context layer.

• Volume 7 --- The Human-in-the-Loop Catalog --- the human-agent interaction layer.

• Volume 8 --- The Evaluation & Guardrails Catalog --- engineer-facing governance.

• Volume 9 --- The Multi-Agent Coordination Catalog --- the agent-to-agent communication layer.

• Volume 10 --- The Retrieval & Knowledge Engineering Catalog --- the discipline of finding the right information in a corpus.

• Volume 11 --- The AI Compliance & Regulatory Catalog (this volume) --- compliance-facing governance.

Ten of the eleven volumes describe engineering layers an architect designs. Volume 11 is different in shape --- it documents what happens when the engineering is translated into evidence for compliance officers, auditors, procurement teams, and regulators. The volume sits adjacent to Volume 8 rather than as a new layer beneath; the engineering doesn’t change between the two, the translation into evidence does.

The series can be read top-down as the agent designer’s sequence (how runs compose through how the system is governed), bottom-up as the operator’s sequence (how humans approve and observe through how runs trigger), or matrix-style with Volume 11 as the cross-cutting view applied to whichever engineering layer the architect is currently designing. The compliance documentation in Volume 11 applies to every engineering layer above it; the engineering layers shape what the compliance documentation says. The framework is intended to be useful from multiple directions for different practitioners; the cross-references support each path.

Appendix C --- The Eight Compliance Anti-Patterns

Eight recurring mistakes that distinguish working AI compliance programs from improvised ones. Avoiding these is most of the practical wisdom in the field:

1. Treating compliance as overhead to add at the end. A compliance program designed after the engineering is built requires reconstructing evidence retroactively, which is expensive, incomplete, and discovers gaps the engineering would have closed if the compliance requirements had been visible during design. Build compliance considerations into engineering decisions from the start.

2. Conflating engineering safety with compliance documentation. Volume 8’s engineering work and Volume 11’s compliance documentation serve different audiences with different formats and different quality bars. A team that produces excellent engineering and skips documentation has a safe system that won’t pass procurement. A team that produces excellent documentation without engineering evidence has paperwork that won’t survive an audit. Both are common; both are correctable; both must be corrected.

3. Treating system prompts as security or compliance controls. OWASP 2025 was explicit on the engineering side: “System prompts are not security controls.” The compliance side has the same constraint: claims of safety based on prompt instructions don’t survive scrutiny because LLM behavior is stochastic. Anything that must hold for compliance must be enforced outside the model in deterministic, auditable code.

4. Picking a framework after the deployment is built. “Which framework should we comply with” is a question to answer before significant engineering investment, because the framework choice shapes evidence requirements throughout the lifecycle. Retroactive framework selection produces gaps the framework would have avoided if it had been the design anchor.

5. Underestimating the documentation cascade. The cascade from engineering evidence to procurement documentation has four layers; each layer needs deliberate construction; the cascade fails when any layer is missing. Most failures occur at the second layer (technical documentation): engineering produces evidence, compliance produces regulatory artifacts, but the structured technical documentation that translates between them is missing.

6. Ignoring jurisdictional scope. “Is our AI compliant” is jurisdiction-specific. EU AI Act compliance doesn’t imply US state law compliance; FDA AI/ML compliance for medical devices doesn’t imply ISO 42001 compliance for management systems. Multi-jurisdictional deployments inherit the union of obligations; mapping which obligations apply where is the first compliance program activity, not the last.

7. Treating the regulatory landscape as static. Frameworks update, replace, and supplement on rolling timelines that don’t respect any single team’s release schedule. Compliance programs need tracking infrastructure (Section H), quarterly review, and the operational maturity to absorb framework changes without rebuilding the entire program. Colorado SB 24-205 → SB 189 in May 2026 demonstrated how quickly the canonical framework can change.

8. Designing to the least-strict applicable framework. The temptation is to find the regulatory minimum and design to it. The working pattern is the reverse: design to the strictest applicable framework and inherit lesser obligations as a byproduct. EU AI Act high-risk compliance typically satisfies US sectoral requirements; the marginal cost of designing once to the strictest standard is lower than maintaining different compliance postures per market.

Appendix D --- Discovery and Standards

Resources for tracking AI compliance and regulatory developments:

• NIST AI Resource Center (airc.nist.gov) --- the canonical NIST AI RMF resource hub.

• EU AI Office (digital-strategy.ec.europa.eu) --- EU AI Act implementation, GPAI Code of Practice.

• artificialintelligenceact.eu --- community-maintained EU AI Act explanatory resource.

• IAPP Global AI Legislation Tracker (iapp.org) --- cross-jurisdictional legislation tracking.

• OECD AI Policy Observatory (oecd.ai) --- international AI policy comparison.

• ailawsbystate.com --- US state AI law tracking.

• Future of Life Institute EU AI Act Newsletter --- EU implementation updates.

• Major law firm publications (DLA Piper AI Law and Regulation Tracker, Latham & Watkins Privacy & Cyber Blog, Hogan Lovells Engage) --- legal analysis of regulatory developments.

• ISO/IEC 42001 certification body publications (BSI, DNV, TÜV SÜD) --- implementation guidance.

• Sector-specific regulators: FDA AI/ML page, Federal Reserve supervisory letters, OCC bulletins, HHS Office for Civil Rights, EEOC technical assistance.

Two practical recommendations. First, assign explicit ownership for regulatory tracking. The maintenance burden is real and ongoing; without assigned ownership, the program drifts and gaps accumulate. Second, design compliance programs for change rather than for any single regulatory landscape snapshot. The frameworks in this volume will see updates within 12 months; the program that anticipates change costs less to maintain than the program that doesn’t.

Appendix E --- Omissions

This catalog covers about 15 substrates across 8 sections. The wider compliance ecosystem is significantly larger; a non-exhaustive list of what isn’t here:

• General-purpose privacy regulation (GDPR, CCPA, HIPAA Privacy Rule) except where AI-specific implications dominate. The privacy literature covers these comprehensively.

• Intellectual property and AI (training data licensing, AI output copyright, NYT v. OpenAI line of litigation). A separate body of law with its own substantial literature.

• Antitrust and AI (concentration in foundation models, competition implications of vertical integration). Important but a separate body of policy.

• Specific employment AI laws beyond NYC AEDT (EEOC technical assistance on AI, Illinois AI Video Interview Act, others).

• State-by-state coverage beyond the major frameworks (Florida, Pennsylvania, Nebraska, other states with narrower AI-specific laws).

• International frameworks beyond the major regions covered (Latin America beyond Brazil, Africa, smaller European jurisdictions, Middle East).

• Industry-specific bodies’ guidance beyond FDA/FINRA/HHS (FAA for aviation AI, NHTSA for autonomous vehicles, NRC for nuclear AI applications, others).

• Voluntary corporate frameworks (Anthropic’s Responsible Scaling Policy, OpenAI’s Preparedness Framework, Google’s AI Principles) that shape industry practice but don’t create binding cross-organization obligations.

Appendix F --- A Note on the Moving Target and the Volume’s Role

The regulatory layer is the part of the AI landscape moving fastest in 2026. The EU AI Act’s high-risk obligations take effect in two and a half months as of this writing; the “AI omnibus” simplification reached political agreement two weeks ago. Colorado SB 24-205 was the canonical comprehensive US state law in March 2026 and was effectively replaced by SB 189 in May 2026, days before this catalog’s publication. ISO/IEC 42001 is barely two years old. NIST AI RMF’s Generative AI Profile is less than two years old. The regulatory frameworks documented here will see updates, replacements, and supplements faster than this catalog can be revised.

The structural facts are more stable than the specifics. AI regulation organizes around three geographies (EU, US, RoW) with different philosophies. Risk-tiered classification is the canonical mental model across frameworks. The documentation cascade translates engineering evidence into compliance artifacts into procurement evidence. Compliance is engineering when done well; paperwork when done poorly. The frameworks in this volume are reference points the architect needs to know exist; the working compliance program uses them as inputs but isn’t about them.

This volume’s purpose is twofold. First, to make explicit the distinction between Volume 8’s engineering governance and Volume 11’s compliance documentation --- a distinction the catalog series previously elided by treating compliance as adequately covered by engineering. Second, to provide the working vocabulary for the regulatory frameworks an architect needs to know about in 2026 even though those frameworks will change. The vocabulary should hold up better than the specific framework details; an architect who internalizes the structure (three geographies, risk tiers, documentation cascade, compliance-engineering handoff) can map any new framework onto the structure in minutes.

Eleven volumes. Patterns, Skills, Tools, Events, Fabric, Memory, Human-in-the-Loop, Evaluation & Guardrails, Multi-Agent Coordination, Retrieval & Knowledge Engineering, AI Compliance & Regulatory. The series documents the working vocabulary of agentic AI as of mid-2026 across the engineering and governance dimensions. The catalog’s value is in the structural vocabulary, not in the products and frameworks that implement it; products and frameworks change; the structural understanding holds up. That’s the catalog’s value proposition. Eleven volumes in, the proposition still holds.

--- End of The AI Compliance & Regulatory Catalog v0.1 ---

— The Eleven-Volume Series —