Atlas / GOVERN & LEAD / Governance / US AI Governance
DEEP-DIVE · GOVERNANCE

AI Governance in the United States: an Architect’s Field Guide

There is no omnibus US AI law, and none is coming soon. What binds you is NIST guidance, a growing state patchwork, and sector regulators applying existing law. Here is how an architect turns that into controls.

TL;DR
  • As of mid-2026 there is no omnibus federal AI statute: the operative US landscape is NIST guidance, binding state laws, and sector regulators enforcing decades-old law against AI systems today.
  • Colorado, Texas, Illinois, New York City, and California rules are live or imminent, and they converge on the same duties: inventory, risk tiering, bias testing, disclosure, and human oversight.
  • One well-built control set satisfies most of the landscape. Build it once, maintain a mapping to each obligation, and every new law becomes a gap analysis instead of a program.

The three-layer map: guidance, statutes, regulators

Architects keep asking which single US law governs their AI systems, expecting an American counterpart to the EU AI Act. As of mid-2026 there is not one, and no omnibus federal AI statute looks close. That absence is not a governance vacuum. It is a differently shaped set of obligations, and it rewards the teams that map it correctly instead of waiting for a clarity that is not coming.

Layer one is federal guidance and executive action. NIST's AI Risk Management Framework is voluntary, but it has become the shared vocabulary for AI risk in American enterprises and government procurement. Executive direction, by contrast, has swung with administrations: the October 2023 executive order on AI (EO 14110) was rescinded in January 2025 and replaced by a deregulatory order centered on American AI leadership, with OMB issuing replacement federal-agency memos in April 2025. The practical lesson is to build on NIST, which survives elections, rather than on executive orders, which demonstrably do not.

Layer two is the state patchwork: binding statutes from Colorado, Texas, Illinois, New York City, and California, with effective dates clustered around 2026. Layer three is the oldest and sharpest layer: sector regulators applying existing law to AI. Banking supervisors do it through model risk guidance, the FDA through medical device regulation, the FTC through consumer protection, the EEOC through employment law. Nothing in layer three required a new statute, and it is where enforcement is actually happening.

 LAYER 1 . FEDERAL GUIDANCE        (voluntary, sets vocabulary)
   NIST AI RMF + GenAI Profile | executive orders | OMB memos
                              |
                              v
 LAYER 2 . STATE STATUTES          (binding, patchwork)
   CO SB 24-205 | TX TRAIGA | IL HB 3773 | NYC LL144 | CA laws
                              |
                              v
 LAYER 3 . SECTOR REGULATORS       (binding, enforced now)
   Fed/OCC SR 11-7 | FDA devices | FTC Sec. 5 | EEOC Title VII
            
The US AI governance stack as of mid-2026: vocabulary at the top, statutes in the middle, enforcement at the bottom.

Read the map top to bottom as decreasing ambiguity and increasing enforcement risk. Most enterprise programs over-index on layer one because it is well documented, and under-invest in layers two and three, where the penalties originate.

NIST AI RMF: the de facto standard

NIST released AI RMF 1.0 in January 2023 and followed it with the Generative AI Profile (NIST-AI-600-1) in July 2024, which maps the framework onto generative-specific failure modes such as confabulation, prompt injection, and data leakage. The framework organizes risk work into four functions: Govern, Map, Measure, and Manage. Those names read as abstractions until you force each one into a concrete artifact that your organization produces and keeps current.

In practice the translation looks like this. Govern becomes a written AI policy, named accountable owners, and a review board with real authority to block a launch. Map becomes an AI system inventory with risk tiers, covering vendor features with embedded AI, not just in-house models. Measure becomes measurement plans: which bias, robustness, and quality evaluations run for which tier, at what cadence, with results stored where an assessor can find them. Manage becomes incident response runbooks that treat model failures like production incidents, with rollback criteria and decommissioning paths.

If your program cannot point to those artifacts, it has adopted the RMF's vocabulary without its substance, and a competent assessor will notice within roughly one meeting. The framework is deliberately non-prescriptive, which means the burden of turning it into engineering reality falls on the architect. That is a feature: it leaves room to fit the controls to your stack rather than bolting on someone else's.

Voluntary does not mean optional. The RMF carries no penalties, but it is contractually and reputationally load-bearing: enterprise procurement questionnaires ask for RMF alignment, cyber insurers reference it, and state laws such as Colorado's point to recognized frameworks like the RMF when defining reasonable care. When something goes wrong, having followed the national reference framework is a materially better position than the alternative.

The state patchwork that actually binds

Guidance shapes behavior; statutes compel it. The table below lists the state and municipal rules most likely to bind an enterprise deployment. It is current as of mid-2026 and worth re-verifying quarterly, because this layer moves faster than any other part of the map.

LawWhat it targetsStatus (mid-2026)
Colorado AI Act (SB 24-205)High-risk AI systems; duties on developers and deployers to prevent algorithmic discriminationEffective June 30, 2026, after a delay from the original date
Texas TRAIGA (HB 149)Prohibited AI practices and government AI use; signed June 2025Effective January 1, 2026
Illinois HB 3773AI in employment decisions, under the Illinois Human Rights ActEffective January 1, 2026
NYC Local Law 144Independent bias audits for automated employment decision toolsEnforced since July 2023
California AB 2013Training-data disclosure for generative AIEffective January 1, 2026
California SB 53Frontier-model transparency and safety reportingSigned September 2025

Two structural notes. First, employment is the densest zone: Illinois and New York City regulate AI hiring tools directly, and Illinois's separate BIPA, a long-standing biometric privacy law with a private right of action, has already produced some of the largest privacy settlements in US history. If your platform touches candidate screening or biometrics, treat those jurisdictions as your design baseline and read them alongside Privacy & PII.

Second, do not plan for this patchwork to consolidate. A congressional attempt to attach a moratorium preempting state AI laws to the 2025 budget bill was stripped out by an overwhelming Senate vote in mid-2025. The signal was unambiguous: states will keep legislating, and the rational architectural response is a control set designed for the union of requirements, not a bet on federal preemption.

Sector regulators with teeth

The third layer predates the AI boom by decades, which is exactly why it has teeth. In banking, the Federal Reserve and OCC's SR 11-7 guidance on model risk management dates to 2011, and its requirements (a model inventory, independent validation, documentation, ongoing monitoring) extend naturally to GenAI. Examiners do not much care whether the model is a logistic regression or a fine-tuned LLM; if it informs decisions, it belongs in the model risk framework. See Model Risk Management for that discipline in detail.

The FDA regulates AI and machine learning in medical devices, including through predetermined change control plans, which let a manufacturer pre-specify the envelope within which a model may be updated without a new submission. It is one of the few places in US regulation with a worked answer to the question every MLOps team eventually asks: how do we retrain in production without seeking re-approval each time?

The FTC needs no AI statute either. Section 5 of the FTC Act covers unfair and deceptive practices, and the agency's Operation AI Comply, launched September 2024, has pursued companies over exaggerated AI claims. Your marketing copy is part of your compliance surface. Meanwhile the EEOC has been explicit that Title VII applies to AI-driven hiring tools, and that buying the tool from a vendor does not transfer the liability to the vendor.

The pattern worth internalizing: none of these agencies waited for Congress. If your system touches credit, health, hiring, or public claims about capability, you are already regulated. The useful question is not whether an AI law applies, but which existing law does.

Turning obligations into architecture

Here is the good news hiding in all of the above: the obligations converge. Read the Colorado act, SR 11-7, the NYC audit rule, and the NIST RMF side by side and you find the same control families under different vocabulary. The correct strategy is therefore to build one strong control set and maintain an explicit mapping from each control to each obligation. Build once, map many.

The mapping matrix is what makes this compound. When a new obligation lands, as the Colorado act did when it took effect in June 2026, you run a gap analysis against controls you already operate instead of launching a compliance program from zero. In practice the delta per new law is typically small once the baseline exists: a disclosure here, an impact-assessment template there. You can pressure-test the approach interactively in the Governance Sandbox.

Resist the temptation to buy this as a product before you have built the inventory. Governance tooling amplifies a working process; it does not create one. The inventory and the tiering logic are decisions only your organization can make.

Operating globally from a US base

A US base does not confine you to US obligations. The EU AI Act applies to providers placing systems on the EU market and, in many configurations, to systems whose outputs are used in the EU, regardless of where the provider sits. Similar extraterritorial patterns appear in other jurisdictions' AI and privacy regimes. If your product has EU users, EU duties are your duties, and the same logic repeats for the UK, Canada, Brazil, and parts of Asia as their frameworks mature.

The wrong response is a per-jurisdiction fork of your governance program: N regimes times M products is an unmaintainable matrix, and the forks will drift. The right response is the same move recommended within the US, applied one level up: architect a superset control baseline that satisfies your strictest applicable regime, and let lighter jurisdictions be satisfied for free. The increments beyond a US-only baseline are predictable:

None of those items is wasted effort in a US-only posture; each one strengthens exactly the controls the state patchwork and sector regulators already reward. For a US architect the summary fits in one sentence: govern to the superset, market to the jurisdiction.

A pragmatic 12-month playbook

None of this requires a two-year transformation program. Twelve months, a small core team, and named owners are enough to reach a defensible posture, provided you resist the urge to gold-plate. A workable sequence, one quarter at a time:

  1. Q1: see what you have. Build the AI inventory, including shadow deployments and vendor features with embedded AI. Assign risk tiers. Adopt NIST RMF vocabulary in every document so contracts and audits speak the same language. Owner: lead or chief architect.
  2. Q2: stand up governance. Charter an AI review board with real authority and a turnaround target measured in days, not months. Publish the control baseline from the previous section and apply it to top-tier systems first. Owner: a CTO sponsor plus the board chair. See AI Operating Models for board patterns that scale.
  3. Q3: push controls into production paths. Wire bias testing into pre-deployment gates and recurring schedules, make logging and traceability a platform default rather than a per-team request, and refresh vendor contracts with documentation and change-notification clauses. Owner: platform engineering lead.
  4. Q4: prove it works. Assemble an evidence pack for each top-tier system, run a tabletop drill on a model failure with regulatory exposure, and dry-run an audit against one binding law; the Colorado act is the natural candidate. Owner: risk or compliance partner.

The sequencing matters more than the calendar: inventory before board, board before production controls, controls before audit. Keep every artifact lightweight enough that engineers do not route around it, because a governance program teams evade produces paper assurance without operational truth. Aim for the smallest control set you can defend in front of a regulator, and let it grow with your top risk tier, not with your ambitions.

← Prompt Injection: The Security Problem You Cannot Fully Solve ALL OF GOVERNANCE Privacy and PII in AI Systems →