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 |
|---|---|---|
| AI inventory | Which AI systems exist, who owns them, and where they are used | System register with owner, vendor, purpose, data classes, user groups, and jurisdictions |
| Applicability map | Which laws or frameworks apply to each system | Law-by-system matrix with source URL and date retrieved |
| Control baseline | Which governance, risk, testing, transparency, and monitoring controls apply | NIST AI RMF or ISO/IEC 42001 control register |
| Legal overlay | Which statutory duties sit above the baseline | State-law obligation rows for Colorado, Texas, NYC, Illinois, Utah, California, and sector rules |
| Evidence file | What proves the control operates | Impact assessment, bias audit, disclosure copy, model card, vendor questionnaire, incident log |
| Refresh loop | When the record is rechecked | Review 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 |
|---|---|---|
| U.S.-only AI inventory and control mapping | NIST AI RMF | Free, public, structured around GOVERN, MAP, MEASURE, and MANAGE |
| Vendor assurance or board-level management-system evidence | ISO/IEC 42001 | Management-system clauses, audit cadence, and certification pathway |
| Generative-AI risk review | NIST AI RMF plus NIST GenAI Profile | More specific GenAI risk taxonomy than a generic policy |
| Multi-state legal compliance | NIST or ISO plus state-law overlay | Framework 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 |
|---|---|---|
| Colorado SB 26-189 ADMT regime | Covered 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 | Covered 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 |
| Texas HB 149 / TRAIGA | AI systems offered, sold, leased, provided, or used in Texas, with disclosure, discrimination, biometric, social-scoring, and enforcement provisions | Texas applicability row, consumer disclosure text, prohibited-use review, discrimination testing evidence. Source: Texas HB 149 enrolled text, retrieved 2026-05-15 |
| NYC Local Law 144 | Automated employment decision tools used for NYC hiring or promotion | Independent bias audit, public summary, candidate notice, data-retention record. Source: NYC DCWP AEDT page, retrieved 2026-05-15 |
| Illinois Public Act 103-0804 | Employer AI use that discriminates or uses zip codes as protected-class proxies in employment decisions | Employment-AI review, protected-class proxy testing, HR notice and escalation path. Source: Illinois Public Act 103-0804, retrieved 2026-05-15 |
| Utah SB 226 | High-risk AI interactions and regulated-occupation disclosure controls after 2025 amendments | High-risk-interaction screen, chatbot disclosure pattern, AI Learning Lab or DCP documentation where applicable. Source: Utah SB 226, retrieved 2026-05-15 |
| California SB 53 | Large frontier-model developer safety and transparency obligations | Frontier-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 |
|---|---|---|
| Days 1-15 | AI system inventory and owner map | Establish the population of systems before controls are assigned |
| Days 16-30 | Applicability map for top jurisdictions and sectors | Separate binding obligations from voluntary framework controls |
| Days 31-45 | NIST or ISO baseline control register | Create a repeatable control vocabulary |
| Days 46-60 | Evidence artifact templates | Standardize impact assessments, bias-audit packets, disclosures, and vendor questionnaires |
| Days 61-75 | Pilot on three high-impact systems | Test the register against a hiring, financial-services, and customer-support use case |
| Days 76-90 | Board or compliance committee review | Approve 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.