The Compliance & Regulatory Catalog

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

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, a framework some state AI laws (notably Texas TRAIGA) recognize as a defense, 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.

NIST is revising AI RMF 1.0 under the July 2025 AI Action Plan; no revised version had been published as of this edition, so check airc.nist.gov for the current text. Volume 8 lists the same framework from the engineering side; this entry is the reference one.

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 recognize framework compliance (Texas TRAIGA).

Alternatives --- ISO/IEC 42001 for the international certifiable equivalent. Sector-specific frameworks (FDA AI guidance for medical devices; for banking, the interagency Revised Guidance on Model Risk Management, Fed SR 26-2 / OCC Bulletin 2026-13, which replaced SR 11-7) 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

• airc.nist.gov (NIST AI Resource Center; revision status)

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

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. Two companion standards followed in 2025: ISO/IEC 42005 for AI system impact assessments (next entry) and ISO/IEC 42006 for the bodies that audit and certify 42001 management systems.

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

Source: iso.org/standard/42005 (published May 2025; companion to ISO/IEC 42001)

Intent

Give organizations a structured, repeatable process for assessing how an AI system affects individuals, groups, and society across its lifecycle, documenting the potential benefits and harms and the mitigations, so the impact-assessment duties in regulation, procurement, and ISO/IEC 42001 have a common template.

Motivating Problem

Impact assessments show up everywhere in AI regulation: the EU AI Act’s fundamental rights impact assessment for certain deployers of high-risk systems, the CCPA risk assessments for automated decision-making, the original Colorado SB 24-205’s annual impact assessments, and the questionnaires enterprise buyers send to vendors. Each asks for a similar exercise under a different name, and before 2025 there was no international standard describing how to run one. ISO/IEC 42001 requires an organization to assess AI system impacts but does not say how. ISO/IEC 42005 fills that gap.

How It Works

The standard sets out a process rather than a checklist. The organization defines a consistent approach for performing and documenting assessments, tailored to its context and risk appetite, and embeds it in existing risk, privacy, human rights, and environmental assessment processes rather than running it as a separate exercise.

Timing and triggers: assessments happen at design, before deployment, and again whenever the intended use, users, data, operating environment, or applicable law changes. A triage step decides which systems need a full assessment; the organization documents what it counts as high-risk and what triggers an assessment.

Scope and thresholds: each assessment defines which systems, components, and stakeholders are covered, who is responsible, and the organization’s role in the AI ecosystem (data provider, model developer, service provider). The organization sets criteria for sensitive or restricted uses, with escalation and approval paths when a use crosses them.

Documentation and review: findings, mitigations, and approvals are recorded and maintained for the life of the system, with reporting lines to management and, where appropriate, external stakeholders. Formal sign-off, ongoing monitoring, and periodic review keep assessments current. The standard is guidance, so there is no 42005 certificate; organizations certified to ISO/IEC 42001 use it to show how they meet 42001’s impact-assessment requirement.

When to Use It

Organizations that owe an impact or risk assessment under the EU AI Act, US state privacy or AI laws, or customer contracts and want one method that serves all of them. ISO/IEC 42001 programs that need a documented impact-assessment process. Agent deployments whose autonomy, tool access, or data access change often enough that reassessment triggers need to be explicit.

Alternatives --- regulator-specific templates (a jurisdiction’s own fundamental rights or algorithmic impact assessment form) when only one regime applies. Data Protection Impact Assessments under GDPR cover the personal-data part but not wider societal impacts.

Sources

• iso.org/standard/42005

• cms.law/en/are/legal-updates/iso-iec-42005-2025-a-new-blueprint-for-legal-and-commercial-leaders-navigating-ai-risk-and-governance

Source: eur-lex.europa.eu/eli/reg/2024/1689 (in force August 2024; phased application through 2028 as amended by Regulation (EU) 2026/1744)

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 2026 AI Omnibus added an Article 5 prohibition on AI that generates non-consensual intimate imagery (“nudifiers”) or child sexual abuse material, applying from 2 December 2026, and gave systems placed on the market before 2 August 2026 until 2 December 2026 to meet the Article 50(2) machine-readable marking duty; the other Article 50 duties applied from 2 August 2026. 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. After the Omnibus they apply from 2 December 2027 for Annex III systems and 2 August 2028 for AI in products covered by Annex I, fixed dates rather than dates tied to standards readiness. 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

• eur-lex.europa.eu/eli/reg/2026/1744/oj (AI Omnibus amending regulation)

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

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

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

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 is voluntary and is an accepted way to demonstrate compliance, assessed by the AI Office; it does not create a legal presumption of conformity (that comes from harmonised standards). Non-adherence requires the provider to demonstrate compliance through alternative means.

How It Works

The Code has three chapters: Transparency, Copyright, and Safety and Security. The Transparency chapter covers what providers should document and share about their models: capabilities, limitations, training data characteristics, evaluation methodology, known risks. The Copyright chapter covers how providers should respect Union copyright law including the text-and-data-mining opt-out mechanism. The public summary of training content is not a Code commitment; it uses a separate, mandatory template the Commission published in July 2025.

For systemic-risk GPAI specifically, the Safety and Security chapter 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. Most major Western providers signed the Code in full (Amazon, Anthropic, Google, IBM, Microsoft, OpenAI, Mistral); Meta declined, and xAI signed only the Safety and Security chapter.

Sources

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

• en.wikipedia.org/wiki/General-Purpose_AI_Code_of_Practice (signatory list)

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

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 (formally SB 26-189) passed both chambers and Governor Polis signed it on May 14: a substantial rollback to a notice-and-disclosure framework with limited consumer rights, taking effect January 1, 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). Adverse-outcome explanations are due within 30 days. Before enforcing, the AG must give 60 days’ notice and a chance to cure (a provision that sunsets January 1, 2030). SB 189 also removed SB 24-205’s safe harbor for following NIST AI RMF or ISO 42001 and its small-business exemption.

The original SB 24-205 framework remains historically relevant. xAI sued to block SB 24-205 on April 9, 2026 and the DOJ intervened about two weeks later, the first use of the December 2025 executive order’s AI Litigation Task Force against a state law; on April 27, 2026 a magistrate judge entered a stipulated stay of enforcement after the AG agreed not to enforce until rulemaking concluded. 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. SB 189 has no NIST AI RMF or ISO 42001 safe harbor; following either framework informs the substantive content of disclosures and record-keeping but is not a defense.

Sources

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

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

• natlawreview.com/article/colorados-sb-26-189-understanding-new-automated-decision-making-technology-law

• privacyworld.blog/2026/05/the-colorado-ai-act-hits-a-wall-litigation-legislative-uncertainty-and-an-enforcement-standstill/

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

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

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, operative August 2, 2026 after AB 853 delayed it; AB 853 also added duties for large online platforms from January 1, 2027 and capture-device makers from January 1, 2028): 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; narrowed by SB 226 in 2025, sunset extended to July 1, 2027 by SB 332): Requires generative AI used with consumers to disclose its AI nature on a clear and unambiguous request or in high-risk interactions, with a safe harbor added in 2025, and creates a regulatory sandbox for AI innovation. It is a disclosure law, not a comprehensive framework.

Texas HB 149 (Texas Responsible AI Governance Act, TRAIGA, signed June 22, 2025, effective January 1, 2026): Prohibits a short list of intentional harmful AI uses (manipulation toward self-harm, intentional unlawful discrimination, CSAM and sexual deepfakes, infringing constitutional rights), puts disclosure duties and social-scoring limits on government agencies, and creates a regulatory sandbox. It has no high-risk-system risk-management regime. The AG enforces exclusively, with a cure period, and substantial compliance with NIST AI RMF or a similar recognized framework is a defense.

Other state activity: California’s vetoed SB 1047 (foundation model safety, 2024) was followed by SB 53 (Transparency in Frontier AI Act, effective January 1, 2026), and New York’s RAISE Act takes effect January 1, 2027; both are covered in the frontier model transparency entry below. 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 (no statute; a December 2025 executive order set up a DOJ AI Litigation Task Force that has challenged state laws in court). 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

• infobytes.orrick.com/2025-10-17/california-delays-its-ai-transparency-act-and-passes-new-content-laws/ (SB 942 and AB 853)

• skadden.com/insights/publications/2025/06/texas-charts-new-path-on-ai-with-landmark-regulation (Texas TRAIGA)

• fpf.org/blog/chatbots-in-check-utahs-latest-ai-legislation/ (Utah SB 226 and SB 332)

• bakerlaw.com/insights/navigating-the-emerging-federal-state-ai-showdown-doj-establishes-ai-litigation-task-force/

Source: cppa.ca.gov (CCPA regulations approved September 2025; effective January 1, 2026; ADMT compliance from January 1, 2027)

Intent

Give California consumers notice, an opt-out, and access rights when a business uses automated decision-making technology (ADMT) to make a significant decision about them, and require a documented risk assessment before such processing, under regulations issued by the California Privacy Protection Agency (CPPA) under the CCPA.

Motivating Problem

Colorado’s law covers only Colorado residents and was narrowed before it took effect. California’s privacy regulator reached the same territory through the CCPA instead of an AI statute: the regulations avoid the term “artificial intelligence” and define ADMT, as technology that processes personal information and uses computation to replace or substantially replace human decision-making, so a scoring model and an agent are covered alike. Because the CCPA already applies to most large businesses with California customers or employees, these rules reach more agent deployers than Colorado does, and they apply to job applicant, employee, and B2B data as well as consumer data.

How It Works

Significant decisions: the rules apply when ADMT is used to make a significant decision about a California consumer concerning financial or lending services, housing, education enrollment or opportunity, employment or compensation, or health care services. Advertising to a consumer is not by itself a significant decision.

Consumer rights: before using ADMT for a significant decision the business gives a conspicuous pre-use notice stating the specific purpose, describing the rights to opt out and to request access, explaining how the ADMT works and what output it produces, and describing the alternative process for consumers who opt out. Consumers can request information about how the ADMT was used in a decision about them.

Risk assessments: processing that presents significant privacy risk, including using ADMT for a significant decision and using personal information to train ADMT for significant decisions, requires a risk assessment before it starts. Activities that began before 2026 and continue must be assessed by December 31, 2027. Businesses submit an annual summary with a signed attestation to the CPPA, the first due April 1, 2028, and must hand over full assessments within 30 days of a request from the CPPA or the Attorney General.

Timeline: the regulations took effect January 1, 2026. A business using ADMT for significant decisions before January 1, 2027 must comply by that date; new uses after that must comply before they start. Annual cybersecurity audit requirements for certain businesses phase in from 2028.

When to Use It

Any business subject to the CCPA that uses an agent or model to make, or substantially replace human judgment in, employment, lending, housing, education, or health care decisions about California residents. Vendors building such tools, since their customers will need the documentation the notice and access rights demand. Multi-state programs choosing a baseline: these rules are a practical US floor for consequential-decision disclosures.

Alternatives --- Colorado SB 189 for Colorado residents (overlapping but not identical domains and duties). A process where a human makes the decision with real involvement, and the system only supports it, does not substantially replace human decision-making and falls outside the ADMT rules; the rules define what counts as human involvement.

Sources

• gtlaw.com/en/insights/2025/9/revised-and-new-ccpa-regulations-set-to-take-effect-on-jan-1-2026-summary-of-near-term-action-items

• natlawreview.com/article/california-privacy-regulations-admt-cybersecurity-audits-and-risk-assessments

Source: California SB 53 (Transparency in Frontier AI Act, signed September 29, 2025, effective January 1, 2026); New York RAISE Act (final amendments signed March 27, 2026, effective January 1, 2027)

Intent

Require developers of the largest foundation models to publish how they assess and mitigate catastrophic risk, publish a transparency report at each model release, and report critical safety incidents to the state within fixed deadlines (15 days in California, 72 hours in New York).

Motivating Problem

California’s SB 1047 tried to impose safety duties on frontier model developers and was vetoed in 2024. SB 53 replaced that approach with transparency: rather than prescribing safety measures, it requires the largest developers to publish their own safety frameworks and report incidents, then holds them to what they published. New York’s RAISE Act, amended in 2026 to align its thresholds with SB 53, followed with a shorter incident deadline. Together they are the US template for developer-side obligations, and they turn voluntary documents such as responsible scaling policies and system cards into legally required publications.

How It Works

Who is covered: a frontier developer is anyone who has trained a foundation model with more than 10^26 integer or floating-point operations; a large frontier developer also has over $500 million in annual revenue. Both laws use the same thresholds.

Frontier AI framework: large frontier developers publish a framework describing how they incorporate national standards, set thresholds and mitigations for catastrophic risk, use third-party assessments, secure unreleased model weights, govern internal use, and respond to critical safety incidents. The framework is reviewed at least annually; California requires a published justification within 30 days of a material change.

Transparency reports: before or when releasing a new or substantially modified frontier model, the developer publishes a report with release date, languages and modalities, intended uses and restrictions, and (for large developers) summaries of catastrophic-risk assessments and third-party involvement. A model card or system card that contains this information satisfies the requirement; trade secrets and security details may be redacted with a recorded justification.

Incident reporting: California requires reports to the Office of Emergency Services within 15 days of discovering a critical safety incident, and within 24 hours to an appropriate authority when there is imminent risk of death or serious injury. New York requires reports to a new office within the Department of Financial Services within 72 hours. Large developers in both states send the state quarterly summaries of their catastrophic-risk assessments.

Enforcement: the state Attorney General enforces. California sets civil penalties up to $1 million per violation and adds whistleblower protections, including an anonymous internal reporting channel at large developers. New York sets up to $1 million for a first violation and up to $3 million for later ones.

When to Use It

Foundation model developers above the compute threshold whose models are available in California or developed, deployed, or operating in New York. Agent builders on top of those models do not carry these duties, but they can use the published frameworks, system cards, and incident disclosures as supplier evidence in their own risk assessments and AIBOMs.

Alternatives --- the EU AI Act’s GPAI systemic-risk obligations and the GPAI Code of Practice’s Safety and Security chapter cover similar ground for the EU market; a developer can build one framework that serves all three.

Sources

• cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2025/10/sb-53—california-sets-standards-for-ai-transparency.html

• wiley.law/alert-New-York-Finalizes-RAISE-Act-for-Frontier-AI-Models-Law-Takes-Effect-January-1-2027

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

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 and transparency for AI-enabled medical devices. The lifecycle approach is set out in the January 2025 draft guidance “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations”, not yet final as of October 2026. The agency maintains a public list of AI-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/digital-health-center-excellence/artificial-intelligence-enabled-medical-devices

• fda.gov/regulatory-information/search-fda-guidance-documents/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing

Source: federalreserve.gov SR 26-2 / OCC Bulletin 2026-13, Revised Guidance on Model Risk Management (April 2026), which replaced SR 11-7 (2011)

Intent

Establish supervisory expectations for managing risk associated with quantitative models used by financial institutions, originally focused on credit and market risk models and applied by banks to AI/ML models. SR 11-7 predated modern AI by over a decade; its April 2026 replacement keeps the core discipline (model development, validation, ongoing monitoring, governance), which maps onto traditional AI/ML model management directly, but excludes generative and agentic AI from its scope.

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, adopted by the FDIC in 2017) established the supervisory expectation that financial institutions have model risk management programs covering the full model lifecycle. On April 17, 2026 the OCC, Federal Reserve and FDIC replaced it with the Revised Guidance on Model Risk Management (Fed SR 26-2, OCC Bulletin 2026-13), which also rescinded the 2021 BSA/AML model risk statement. The revision is shorter and principles-based, narrows the definition of a model to complex quantitative methods, sizes model risk by inherent risk and materiality, and is framed as most relevant to banks with over $30 billion in assets (the old figure was $1 billion). Both treat traditional 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 (from SR 11-7): 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 2026 guidance keeps effective challenge and the core validation components (conceptual soundness, outcomes analysis, ongoing monitoring) but states them more briefly and allows lighter oversight for immaterial, low-risk models.

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).

Generative and agentic AI: the 2026 revised guidance expressly excludes generative and agentic AI models from its scope, calling them novel and rapidly evolving. Banks govern those under their broader risk management and governance practices while the agencies run a request for information on banks’ use of AI, including generative and agentic AI. No formal AI-specific model risk guidance was issued between 2023 and 2025. This is the main gap for agent deployments in banking: the practices banks apply to traditional AI/ML models (bias testing in validation, explainability for high-stakes models, third-party model risk, drift monitoring) are a reasonable starting point for agents, but no supervisory text requires or describes them.

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. The 2026 guidance states that it sets no enforceable standards and that non-compliance with it will not result in supervisory criticism; the agencies keep their authority to act on unsafe or unsound practices that stem from weak model risk management. 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

Banking organizations supervised by the Federal Reserve, OCC, or FDIC, most directly those over $30 billion in assets. 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). Generative and agentic AI sit outside the guidance and need their own governance.

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/SR2602.htm

• occ.gov (Bulletin 2026-13)

• orrick.com/en/Insights/2026/04/Agencies-Overhaul-Model-Risk-Management-Guidance-for-Banks-Heres-What-Changed

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

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 rules: the Section 1557 final rule (45 CFR 92.210, 2024), enforced by the HHS Office for Civil Rights, requires covered entities to identify and mitigate the risk of discrimination from patient care decision support tools, including AI. It sits alongside the FDA framework for AI-enabled 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/hipaa/for-professionals/security/index.html

• healthaffairs.org/content/forefront/section-1557-rule-mandates-identification-and-mitigation-discriminatory-clinical

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

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. Since September 1, 2025, the Measures for Labeling AI-Generated Synthetic Content and the mandatory national standard GB 45438-2025 require explicit labels and embedded (metadata) labels on generated content, with duties on distribution platforms and app stores as well as providers. 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)

• insideprivacy.com/international/china/china-releases-new-labeling-requirements-for-ai-generated-content

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

Source: Various national frameworks at varying maturity

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 Security Institute (renamed from AI Safety Institute in February 2025) focuses on frontier model security risks. 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, agentic AI edition January 2026, covered in the next entry) 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 (enacted May 2025, most provisions in effect June 2025) 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) died with Bill C-27 when Parliament was prorogued in January 2025; provincial frameworks (Quebec Law 25) cover narrower domains. Brazil’s Artificial Intelligence Bill (PL 2338/2023) is under legislative consideration. South Korea’s AI Basic Act took effect January 22, 2026, the second comprehensive AI law after the EU AI Act, with high-impact AI obligations, generative AI labeling, and penalties phased in after a grace period. 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

• aisi.gov.uk (AI Security Institute, UK)

• cooley.com/news/insight/2026/2026-01-27-south-koreas-ai-basic-act-overview-and-key-takeaways

• parl.ca/legisinfo/en/bill/44-1/c-27 (Canada Bill C-27)

• AI Verify Foundation and IMDA (Singapore)

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

• OECD AI Policy Observatory

Source: imda.gov.sg / mddi.gov.sg (launched by IMDA on 22 January 2026 at the World Economic Forum)

Intent

Give organizations deploying AI agents, whether built in-house or bought, a government reference for doing it responsibly: bound the agent’s risks up front, keep humans meaningfully accountable with defined approval checkpoints, apply technical controls across the agent lifecycle, and equip end users to use and oversee agents.

Motivating Problem

Earlier AI governance frameworks, including Singapore’s own 2020 and 2024 editions, assume a system that produces outputs a person then acts on. Agents act themselves: they plan, select tools, update records, and make payments. That creates risks the older frameworks do not address, such as unauthorized or erroneous actions, data breaches through tool access, and automation bias, where people over-trust an agent that has worked reliably before. IMDA described the framework as the first government governance framework designed for agents; it is the compliance-side counterpart to the agent patterns in the rest of this series.

How It Works

The framework is organized around four dimensions.

Assess and bound risks up front: run use-case-specific assessments that consider agent-specific factors such as autonomy level, access to sensitive data, and breadth of data, then limit what the agent can do by design through tool access, permissions, operating environment, and the scope of actions allowed. Bounding by design is treated as the primary defense.

Make humans meaningfully accountable: allocate responsibilities across developers, deployers, operators, and end users, and define significant checkpoints where human approval is required. Oversight mechanisms must be able to override, intercept, or review agent actions, especially those with real-world material impact.

Implement technical controls and processes across the lifecycle: during design, tool guardrails, plan reflection, and least-privilege access to tools and data; before deployment, testing of overall task execution, policy compliance, and tool-use accuracy across varied datasets; during and after deployment, staged roll-outs and real-time monitoring.

Enable end-user responsibility: tell users what the agent can do, give them a contact point for escalation when it malfunctions, and train them so the human skills needed to supervise agents are kept.

The framework is voluntary and published as a living document; IMDA invited feedback and case studies and is developing separate guidelines for testing agentic AI applications.

When to Use It

Organizations deploying agents in Singapore, and any agent deployment that needs a published, government-issued reference to anchor its governance documentation. Teams mapping their human-in-the-loop and guardrail designs to a framework a compliance reviewer will recognize: the four dimensions line up with the approval-checkpoint, least-privilege, and monitoring patterns in Volumes 7 and 8.

Alternatives --- the broader Model AI Governance Framework and AI Verify for non-agentic AI. ISO/IEC 42001 and NIST AI RMF for certifiable or US-anchored management of AI risk in general, which do not address agents specifically.

Sources

• mddi.gov.sg/newsroom/singapore-launches-new-model-ai-governance-framework-for-agentic-ai—/

• bakermckenzie.com/en/insight/publications/2026/01/singapore-governance-framework-for-agentic-ai-launched

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

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)

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

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 added AI and Dataset profiles in SPDX 3.0; CycloneDX added machine-learning BOM (ML-BOM) support; 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)

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

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. Standards for AI-specific assurance are arriving: ISO/IEC 42006:2025 (published July 2025) sets requirements for bodies that audit and certify ISO/IEC 42001 management systems, and Singapore’s AI Verify provides a testing framework 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.org/standard/42006 (ISO/IEC 42006:2025, requirements for bodies certifying AI management systems; published July 2025)

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
ISO/IEC 42005	Voluntary; guidance	May 2025	AI system impact assessment process
EU AI Act	Binding; EU regulation	Phased: Feb 2025 - Aug 2028	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
California CCPA ADMT rules	Binding; state regulation	Jan 2026 (ADMT Jan 2027)	Notice, opt-out, risk assessment
California SB 53 / NY RAISE	Binding; state laws	Jan 2026 / Jan 2027	Frontier developer transparency
FDA AI/ML for medical devices	Binding; US federal	Ongoing	Medical device pathway with AI extensions
SR 26-2 (replaced SR 11-7)	Supervisory guidance	April 2026	Bank model risk; excludes GenAI/agents
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/2026 (agentic)	Voluntary framework + AI Verify testing

Appendix B --- The Series

This catalog joined the ten prior volumes to form an eleven-layer vocabulary for agentic AI; the series has since grown to nineteen volumes.

• 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 first 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 (Appendix D), 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. Earlier drafts carried these as a catalog entry (“Regulatory tracking resources and discovery infrastructure”); they are link roundups rather than patterns, so they live here:

• 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 18 substrates across 7 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 CCPA rules on automated decision-making technology are covered in Section C). 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. California SB 53 and New York’s RAISE Act now require the largest frontier developers to publish such frameworks; see Section C.

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 were due in August 2026 until the AI Omnibus (Regulation (EU) 2026/1744, in force July 2026) moved them to December 2027 and August 2028, less than a month before the original date. 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 at the time of writing (the series has since grown to nineteen). 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 Agentic AI Series —