AI Compliance Framework
Last verified: 2026-06-02 - primary-source review of NIST AI RMF, ISO/IEC 42001, Colorado SB 26-189, Texas HB 149, NYC DCWP Local Law 144 guidance, Illinois Public Act 103-0804, Utah SB 226, and California SB 53.
An AI compliance framework is the operating model that connects AI systems, applicable laws, framework controls, evidence artifacts, owners, and refresh dates. It should not be only a policy document. For U.S. teams, the practical pattern is to use NIST AI RMF or ISO/IEC 42001 as the control backbone, then overlay binding state, municipal, and sector-specific requirements where a particular AI system triggers them.
Quick answer
A workable AI regulatory compliance framework has six layers:
| Layer | What it answers | Evidence artifact |
|---|---|---|
| LayerAI inventory | What it answersWhich AI systems exist, who owns them, and where they are used | Evidence artifactSystem register with owner, vendor, purpose, data classes, user groups, and jurisdictions |
| LayerApplicability map | What it answersWhich laws or frameworks apply to each system | Evidence artifactLaw-by-system matrix with source URL and date retrieved |
| LayerControl baseline | What it answersWhich governance, risk, testing, transparency, and monitoring controls apply | Evidence artifactNIST AI RMF or ISO/IEC 42001 control register |
| LayerLegal overlay | What it answersWhich statutory duties sit above the baseline | Evidence artifactState-law obligation rows for Colorado, Texas, NYC, Illinois, Utah, California, and sector rules |
| LayerEvidence file | What it answersWhat proves the control operates | Evidence artifactImpact assessment, bias audit, disclosure copy, model card, vendor questionnaire, incident log |
| LayerRefresh loop | What it answersWhen the record is rechecked | Evidence artifactReview calendar tied to law effective dates, model changes, and guidance updates |
AI regulatory compliance framework: the control map
The control map is the difference between AI governance as an operating model and audit-ready compliance evidence. A compliance team should be able to open one row for one AI system and see the use case, data categories, jurisdiction, role, legal trigger, selected framework controls, evidence owner, and next review date.
That row should also record the source behind the trigger. NIST says the AI RMF is intended for voluntary use and to help organizations manage risks to individuals, organizations, and society associated with AI systems. Source: NIST AI Risk Management Framework, retrieved 2026-05-15. ISO describes ISO/IEC 42001:2023 as an AI management system standard for organizations that develop, provide, or use AI systems. Source: ISO/IEC 42001:2023, retrieved 2026-05-15.
Those sources answer different questions. NIST supplies a public risk-management vocabulary and suggested outcomes. ISO/IEC 42001 supplies a management-system structure that can support certification and supplier assurance. Neither source replaces a binding state-law duty when a statute applies.
Baseline framework choice
| Program need | Better starting point | Reason |
|---|---|---|
| Program needU.S.-only AI inventory and control mapping | Better starting pointNIST AI RMF | ReasonFree, public, structured around GOVERN, MAP, MEASURE, and MANAGE |
| Program needVendor assurance or board-level management-system evidence | Better starting pointISO/IEC 42001 | ReasonManagement-system clauses, audit cadence, and certification pathway |
| Program needGenerative-AI risk review | Better starting pointNIST AI RMF plus NIST GenAI Profile | ReasonMore specific GenAI risk taxonomy than a generic policy |
| Program needMulti-state legal compliance | Better starting pointNIST or ISO plus state-law overlay | ReasonFramework controls help, but statutory duties still need jurisdiction-specific evidence |
A mature program often uses both: NIST for the working control taxonomy and ISO/IEC 42001 for management-system evidence. The selection should be documented, because the audit trail explains why a control family exists and why another source was not used as the primary baseline.
State-law overlay
The legal overlay turns the baseline into a compliance map. Each row below is a source-backed trigger, not legal advice.
| Source | Primary trigger | Evidence to attach to the framework |
|---|---|---|
| SourceColorado SB 26-189 ADMT regime | Primary triggerCovered automated decision-making technology used to materially influence consequential decisions; covered developer documentation duties start January 1, 2027 and deployers need notice, records, correction, and human-review workflows | Evidence to attach to the frameworkCovered ADMT classification memo, technical documentation request, deployer records file, consumer notice, correction and human-review workflow, remediation log. Source: Colorado SB 26-189, retrieved 2026-06-02 |
| SourceTexas HB 149 / TRAIGA | Primary triggerAI systems offered, sold, leased, provided, or used in Texas, with disclosure, discrimination, biometric, social-scoring, and enforcement provisions | Evidence to attach to the frameworkTexas applicability row, consumer disclosure text, prohibited-use review, discrimination testing evidence. Source: Texas HB 149 enrolled text, retrieved 2026-05-15 |
| SourceNYC Local Law 144 | Primary triggerAutomated employment decision tools used for NYC hiring or promotion | Evidence to attach to the frameworkIndependent bias audit, public summary, candidate notice, data-retention record. Source: NYC DCWP AEDT page, retrieved 2026-05-15 |
| SourceIllinois Public Act 103-0804 | Primary triggerEmployer AI use that discriminates or uses zip codes as protected-class proxies in employment decisions | Evidence to attach to the frameworkEmployment-AI review, protected-class proxy testing, HR notice and escalation path. Source: Illinois Public Act 103-0804, retrieved 2026-05-15 |
| SourceUtah SB 226 | Primary triggerHigh-risk AI interactions and regulated-occupation disclosure controls after 2025 amendments | Evidence to attach to the frameworkHigh-risk-interaction screen, chatbot disclosure pattern, AI Learning Lab or DCP documentation where applicable. Source: Utah SB 226, retrieved 2026-05-15 |
| SourceCalifornia SB 53 | Primary triggerLarge frontier-model developer safety and transparency obligations | Evidence to attach to the frameworkFrontier-model threshold review, safety framework, incident-reporting workflow, transparency report. Source: California SB 53, retrieved 2026-05-15 |
Control register fields
A defensible register should include these fields before a system moves from pilot to production:
- System name, owner, vendor, business purpose, and production status.
- Developer, deployer, vendor, or both-role classification.
- Jurisdictions where the system is offered, used, or affects consumers.
- Data classes processed, including sensitive personal information, PHI, biometric data, employment data, financial data, or children's data.
- Decision domain: employment, lending, insurance, housing, healthcare, education, legal services, government services, marketing, customer support, security, or internal productivity.
- Baseline framework controls selected from NIST AI RMF or ISO/IEC 42001.
- Legal overlay rows with citation, date retrieved, role, trigger, duty, owner, and due date.
- Evidence artifacts and storage location.
- Vendor due-diligence status and contractual controls.
- Review cadence, last verification date, and next verification date.
This field set is the unique operating layer. Many competitor pages define AI compliance in broad terms; the Atlas page ties each framework decision to a law trigger and an evidence artifact.
AI for regulatory compliance
The phrase AI for regulatory compliance usually means using AI to classify laws, summarize obligations, draft policies, test controls, or route compliance tickets. That use case can be valuable, but it is still an AI system and should be recorded in the same inventory.
A compliance AI tool should have narrower permissions than a general-purpose assistant. The register should record the source materials it is allowed to use, whether it handles privileged or regulated data, whether outputs require human review, how hallucination risk is tested, and whether generated policy text is traceable to source citations. If the tool processes healthcare, employment, lending, insurance, or consumer-service records, the organization should run the same legal overlay used for customer-facing systems. For healthcare data flows, pair the register with the HIPAA compliance for AI guide.
90-day implementation sequence
| Timeframe | Work product | Purpose |
|---|---|---|
| TimeframeDays 1-15 | Work productAI system inventory and owner map | PurposeEstablish the population of systems before controls are assigned |
| TimeframeDays 16-30 | Work productApplicability map for top jurisdictions and sectors | PurposeSeparate binding obligations from voluntary framework controls |
| TimeframeDays 31-45 | Work productNIST or ISO baseline control register | PurposeCreate a repeatable control vocabulary |
| TimeframeDays 46-60 | Work productEvidence artifact templates | PurposeStandardize impact assessments, bias-audit packets, disclosures, and vendor questionnaires |
| TimeframeDays 61-75 | Work productPilot on three high-impact systems | PurposeTest the register against a hiring, financial-services, and customer-support use case |
| TimeframeDays 76-90 | Work productBoard or compliance committee review | PurposeApprove risk acceptance, refresh cadence, and escalation thresholds |
Frequently asked questions
What is an AI compliance framework?
An AI compliance framework is a structured way to map AI systems to applicable laws, voluntary frameworks, controls, evidence, owners, and refresh dates. It should produce an auditable register, not only a policy narrative.
Is NIST AI RMF enough for AI compliance?
No. NIST AI RMF is a voluntary risk-management framework — and NIST does not itself certify organizations against it. It can serve as the control backbone, but binding duties from Colorado, Texas, NYC, Illinois, Utah, California, HIPAA, employment law, financial-services law, or other sources still need their own legal-overlay rows and evidence artifacts.
Is ISO/IEC 42001 required?
ISO/IEC 42001 is not generally required by U.S. AI statutes tracked by the Atlas. It can be useful when a company needs a certifiable AI management system, supplier assurance evidence, or a board-level operating model for AI governance.
How often should an AI compliance framework be refreshed?
At minimum, refresh annually and whenever a high-impact AI system changes purpose, data, vendor, model, decision domain, or jurisdiction. In 2026, state AI law effective dates and amendments also justify a quarterly legal-source check for systems in regulated decision domains.
Can AI be used for regulatory compliance work?
Yes, but the compliance tool should itself be governed. The organization should record what sources the tool uses, whether regulated data enters prompts or logs, whether human review is mandatory, and how outputs are tied back to primary sources.