US AI law in 2026: what teams must track

US AI rules are fragmented, so teams now need a documented control map.

I've been tracking AI policy the way I track production incidents: not because I enjoy it, but because it keeps showing up in the middle of real work. And honestly, the US situation has been a mess. One team asks me if they can ship a model feature nationally. Another wants to know whether a state law will bite them first. A third assumes the federal government has already settled it. It hasn’t.

What keeps tripping people up is that there’s no single federal AI statute to point at and move on. Instead, I keep seeing a pile of executive orders, agency guidance, state bills, and preemption fights that change the answer depending on where the system runs and what it does. That’s not a legal strategy. That’s a spreadsheet with anxiety attached.

The piece that pushed me to write this was Software Improvement Group’s 2026 overview of US AI legislation. They do a decent job of laying out the federal-state split, the Trump administration’s current posture, and the fact that organizations now need evidence of control, not vibes. I’m using their article as the anchor here, then I’m translating it into the stuff I’d actually want in a compliance or engineering checklist.

The real problem: nobody gets to ignore geography anymore

“The complexity of federalism still makes a unified AI policy difficult.”

What this actually means is simple: if your AI system touches users in multiple states, you can’t assume one policy covers the whole deployment. I’ve seen teams build one “US policy” doc and call it done. That works right up until a state rule asks for something slightly different, like notice, opt-out, impact assessment, or human review in a specific use case.

SIG points out that by March 2026 lawmakers in 45 states had introduced 1,561 AI-related bills, which is already more than the total volume from all of 2024. That number matters because it tells me this is no longer theoretical noise. It’s operational drift. State-level AI tracking is now part of normal release planning, the same way privacy and accessibility became normal release planning.

I ran into this kind of mess when a product team wanted to roll out a recommendation feature across the US. Their assumption was that if legal signed off once, they were fine. Nope. The deployment path, customer segment, and data flow all changed the risk profile. We had to map jurisdictions, not just features.

How to apply it: build a jurisdiction matrix. For each AI system, record where the company is based, where the system is hosted, where users are, and which state rules may apply. Keep it boring and explicit. If you can’t answer those four questions quickly, you’re not ready for a compliance review.

• System name
• Hosting region
• User geography
• Applicable state rules

Stop treating AI like a side project and start inventorying it

One thing SIG gets right is the emphasis on evidence of control. That means a clear inventory of AI systems, defined ownership, and documented compliance across jurisdictions. I like that framing because it cuts through the usual nonsense. “We have AI” is not a control. “We know every model, who owns it, where it runs, and what rules apply” is a control.

What this actually means is that teams need a real inventory, not a slide deck. If your company can’t list its AI systems, the business units using them, the vendors behind them, and the data they touch, then any legal review is basically guesswork. And guesswork is expensive once regulators or customers start asking questions.

I’ve seen this break in the same way software asset inventories break. The first pass is always incomplete because shadow tools exist. Someone used a hosted model in a prototype. Someone else wrapped an API in a workflow. A support team started using a summarizer in a browser plugin. Suddenly the company has “AI” everywhere and no one owns the mess.

How to apply it: create an AI register with at least these fields: system name, purpose, owner, vendor, model type, data sources, deployment region, user population, human oversight, and legal status. If a field is unknown, mark it unknown. Don’t fake completeness. That only buys you trouble later.

• Business owner
• Technical owner
• Vendor or model provider
• Deployment environment
• Decision impact level

Federal policy is still a moving target, and that’s the point

SIG highlights Executive Order 14365, signed on December 11, 2025, which directs federal agencies to promote a “minimally burdensome” national AI framework and sets up an AI Litigation Task Force to challenge state laws seen as inconsistent with federal policy. That’s not a final answer. That’s a signal that the administration wants to shape the field without waiting for a full statute.

What this actually means is that federal policy is trying to pull in one direction while the states keep writing enforceable rules in their own direction. Congress has already rejected moratorium proposals twice, including the 99-1 Senate vote to strip a 10-year freeze from the “One Big Beautiful Bill Act.” So the idea that the federal government will simply erase state rules is not where reality is right now.

I keep seeing people read executive orders like they’re settled law. They’re not. They matter, sure. They can change agency behavior and procurement rules. But they do not magically create a comprehensive AI statute. If your compliance plan depends on a future federal preemption win, you’re betting your release schedule on politics. That’s a bad bet.

How to apply it: build two tracks in your compliance plan. Track one covers current state obligations. Track two watches federal developments, especially procurement guidance, agency rulemaking, and litigation. If federal policy changes, you update the second track. You do not throw away the first one.

For reference, the federal sources SIG mentions include the January 23, 2025 executive order and the White House’s AI Action Plan. For state tracking, I’d keep NCSL’s AI Legislation Database and MultiState bookmarked.

Frontier model oversight is coming back through the side door

SIG says the Trump administration is reportedly considering pre-release evaluation requirements for frontier AI models, driven by national security concerns around Anthropic’s Mythos model. At the same time, CAISI, the renamed US AI Safety Institute, has announced evaluation partnerships with Google, Microsoft, and xAI. That is a pretty clear sign that “no oversight” was never really the whole story.

What this actually means is that the highest-risk models are getting special treatment, even in a policy environment that talks a lot about reducing friction. If you’re building or buying frontier-capable systems, you should expect more scrutiny around testing, evaluation, and release gates. The label may change, but the control pattern is familiar: prove you looked before you launched.

I’ve been through enough security reviews to know how this goes. The teams that do best are the ones that already have evaluation logs, red-team notes, model cards, incident response paths, and a release approval process. The teams that struggle are the ones saying, “We’ll document it after launch.” That never ages well.

How to apply it: if your system is anywhere near frontier capability, define a pre-release checklist now. Include safety evaluation, misuse testing, privacy review, security review, and rollback criteria. If you use third-party models, ask vendors for the same evidence. If they can’t provide it, that’s not a minor gap. That’s a procurement problem.

Useful references here are Anthropic, Microsoft, Google’s AI blog, and xAI, since SIG specifically mentions those evaluation partnerships.

States are writing the rules, so your controls need to be localizable

One of the cleaner points in SIG’s article is that state laws are already in effect and enforceable. That matters because it means your control set can’t be one giant national blob. You need controls that can vary by jurisdiction, use case, and product surface.

What this actually means is that the same model can have different compliance obligations depending on where it’s used. A hiring tool, a consumer chatbot, and a fraud detector do not belong in the same bucket just because they all use machine learning. If your policy language is too generic, it won’t help anyone make a release decision.

I’ve seen teams collapse everything into “AI governance,” which sounds nice until someone asks whether the policy covers employment decisions, biometric data, or consumer disclosures. Then everyone starts searching through three docs and a SharePoint folder that nobody trusts.

How to apply it: split controls into reusable modules. I’d use separate modules for inventory, human oversight, model evaluation, vendor review, incident handling, and jurisdiction mapping. Then attach those modules to each AI system based on risk and geography. That gives legal, security, and product a shared structure instead of a giant policy blob.

• Inventory module
• Risk module
• Vendor module
• Jurisdiction module
• Release approval module

What I’d actually tell a team on Monday morning

If I had to boil SIG’s overview down to one operational lesson, it would be this: stop asking whether AI is “regulated” and start asking whether you can prove control. The article keeps circling the same truth from different angles. The US doesn’t have one neat federal AI law. States are moving. Federal preemption is contested. Frontier oversight may tighten. That means your internal evidence matters more than your assumptions.

What this actually means is that the teams who win this year are the ones who can answer basic questions fast: what systems exist, who owns them, where they run, what data they use, which jurisdictions apply, and what testing happened before release. That’s not glamorous. It’s just the work.

My advice is to treat AI governance like release engineering, not like a policy memo. If you can’t trace a system from idea to deployment to oversight, you’re going to get surprised. And in this area, surprise usually means delay.

The template you can copy

# AI System Compliance Register

## 1) System details
- System name:
- Business purpose:
- Product or workflow:
- Business owner:
- Technical owner:
- Vendor / model provider:
- Model type:
- Deployment date:

## 2) Where it runs
- Hosting region:
- Cloud / on-prem / hybrid:
- User geographies:
- Data residency constraints:

## 3) What it touches
- Input data types:
- Personal data used? (yes/no):
- Sensitive data used? (yes/no):
- Automated decision-making? (yes/no):
- Human-in-the-loop? (yes/no):

## 4) Jurisdiction check
- Federal obligations:
- State obligations:
- Sector-specific obligations:
- Pending legislation watched:
- Legal reviewer:

## 5) Controls and evidence
- Risk assessment completed? (yes/no)
- Safety / misuse testing completed? (yes/no):
- Security review completed? (yes/no):
- Privacy review completed? (yes/no):
- Vendor due diligence completed? (yes/no):
- Release approval recorded? (yes/no):
- Monitoring plan defined? (yes/no):
- Incident response path defined? (yes/no):

## 6) Ownership and review
- Review cadence:
- Next review date:
- Change trigger events:
- Escalation contact:

## 7) Evidence links
- Policy link:
- Test report link:
- Approval record link:
- Monitoring dashboard link:
- Vendor contract / DPA link:

## 8) Decision
- Approved / conditionally approved / rejected:
- Conditions:
- Notes:

That template is my version of the SIG article’s main point: inventory first, then jurisdiction, then evidence. If you can fill that out for every AI system, you’re already ahead of most teams I see.

Source attribution: this breakdown is based on Software Improvement Group’s article “AI legislation in the US: A 2026 overview”. I’ve paraphrased and operationalized their points, but the legal framing and source references come from SIG.