Search for an AI compliance checklist and you will find dozens. Almost none of them tell you where any given item comes from.

That is the flaw that makes them unusable. "Maintain an AI inventory" appears alongside "obtain ISO 42001 certification" and "implement continuous bias monitoring", with nothing to indicate that the first is required in some jurisdictions, the second is entirely optional, and the third is a product feature the author sells. A reader cannot tell what they must do from what someone would prefer they buy.

This checklist labels every item. Where the item is a legal duty it names the instrument. Where it is a voluntary framework practice it says so. Where it is neither, it says that too.

Step 0: scope, before you check anything

Nothing below applies to everyone. Answer three questions first, because they determine which sections you work:

  1. Which decisions do you automate? Not which tools you use — which decisions. Anything affecting employment, credit, housing, insurance, benefits, enforcement, pricing or access to services is the category that attracts obligations.
  2. Where are the affected people? Exposure follows your users, not your headquarters. This is the point organisations most often get wrong.
  3. Do you build it or buy it? Nearly every instrument splits duties between developers and deployers, and for bought systems your compliance ceiling is whatever documentation your vendor provides.

If you automate no consequential decisions, most of Section A does not apply to you and you can work Sections B and C as good practice.

These attach because an instrument says so. Each row names it. Applicability still depends on your scope answers above, and on definitions and exemptions that only the statutory text settles.

If you offer a generative AI system in California

  • Publish a training-data summary. Source: California AB 2013, in force from 1 January 2026. This reaches far more organisations than California's better-known SB 53, because it is scoped to systems offered in California rather than to the largest developers. (Secondary sources; read the statute.)

If you are a large frontier developer

  • Publication and incident-reporting duties. Source: California SB 53, in force 1 January 2026. (Secondary sources.)
  • New York RAISE Act duties from 1 January 2027. (Secondary sources.)

If you use AI in employment decisions

  • Illinois HB 3773 obligations, in force 1 January 2026. (Secondary sources.)
  • Existing anti-discrimination law applies regardless. This is not an AI rule — it is the point that a decision's legality does not change because a model produced it. No AI statute is needed for a disparate outcome to be actionable.

If you deploy automated decision-making in Colorado

  • Developer technical documentation to deployers; deployer notice before a consequential decision; explanation after an adverse one. Source: Colorado SB 26-189, the Automated Decision-Making Technology Act. The act took effect 12 August 2026; its duties apply from 1 January 2027, with Attorney General rules due by the same date and a cure period running to 1 January 2030. (Colorado General Assembly bill record.)
  • Note the vocabulary. It regulates automated decision-making technology, not "AI systems", so scoring rules and threshold models can be in scope. See what SB 26-189 replaced the old act with.

If you operate in Texas

  • TRAIGA prohibitions, in force 1 January 2026. (Enrolled statutory text.)
  • The safe harbour is narrower than commonly reported. The provision at §552.105(e)(2)(D) frames an affirmative defence around discovering the violation through an internal review process that substantially complies with NIST's Generative AI Profile — not around general compliance with the framework. If you intend to rely on it, build the review process, not just the alignment.

If you place AI on the EU market

  • Transparency obligations applied from 2 August 2026. These were not deferred. (Regulation (EU) 2026/1744, EUR-Lex.)
  • Two new prohibited practices apply from 2 December 2026, covering systems designed to generate or manipulate realistic intimate imagery or child sexual abuse material.
  • Stand-alone high-risk obligations from 2 December 2027 (Annex III), and product-embedded from 2 August 2028 (Annex I).
  • See the EU AI Act timeline after the Digital Omnibus.

If you sell AI to US federal agencies

  • Contractual terms arrive through the solicitation, not through regulation. OMB M-25-22 brings pre-award testing and performance validation for high-impact AI; M-26-04 requires terms on the Unbiased AI Principles in LLM solicitations. (OMB memoranda.)
  • Existing LLM contracts get modified at option exercise. Renewal is the checkpoint. See selling AI to the federal government.

Section B — Voluntary framework practices

Not legally required. Consequential anyway, because statutes and buyers increasingly point at them.

  • Adopt a recognised risk framework. NIST AI RMF is free and non-certifiable; ISO/IEC 42001 is paid and certifiable. Neither makes you compliant with anything. See the comparison.
  • Maintain an AI inventory. Not a general legal duty, but every other control depends on it, and several statutes are unanswerable without one. See building an AI system inventory.
  • Classify systems by impact. Federal guidance tiers around "high-impact AI"; the EU around risk categories; Colorado around consequential decisions. Different words, same underlying move.
  • Document each consequential system — purpose, data, known limitations, what it was tested against.
  • Run pre-deployment testing proportionate to impact. Increasingly what buyers ask for regardless of law.
  • Monitor after deployment. Model behaviour and population both drift.
  • Keep an incident route that reaches someone with authority to stop a system.

Section C — Good practice, required by nobody

Worth doing. Do not let anyone tell you they are compliance obligations.

  • Publishing an AI use policy externally.
  • Naming a single accountable owner per system. (Not required; the single highest-value item on this page.)
  • Red-teaming beyond what your risk tier warrants.
  • Buying a governance platform. Most organisations start effectively with a spreadsheet, and a tool bought before you know your process encodes someone else's.
  • Certifying to a standard nobody has asked you for.

Section D — Agents, if you deploy them

Not yet the subject of a specific statutory duty in most jurisdictions, but the subject of joint guidance from CISA, the NSA, Australia's ACSC and international partners in April 2026:

  • Give each agent its own verified identity rather than a shared key.
  • Use short-lived credentials.
  • Require human sign-off for high-impact actions.
  • Enforce least privilege outside the model, not in the prompt.
  • See prompt injection for why prompt-level controls do not hold.

How to keep this current

Compliance content decays without changing. Two dates on this page moved in 2026 alone: Colorado's obligations were repealed and reenacted, and the EU's high-risk deadlines shifted while its transparency obligations did not.

Practical habits:

  1. Re-check quarterly. Not annually. The pace does not currently allow it.
  2. Distrust undated resources. A confident AI compliance page with no date is unusable regardless of how good it was when written.
  3. Track the instrument, not the commentary. Commentary is written once; statutes are amended.
  4. Watch for repeal, not just amendment. Colorado is the reminder that an entire statute can be replaced.

This page carries a last-verified date and a corrections policy. Nothing here is legal advice, and whether any instrument reaches your organisation is a question for counsel qualified in that jurisdiction.