Federal vs State AI Law: Engineering for a Compliance Patchwork
An executive order set a national AI policy framework, but Colorado's and California's state laws likely stand in the short term, leaving engineers to build for a patchwork rather than a single rulebook.
On December 11, 2025, President Trump signed Executive Order 14365, "Ensuring a National Policy Framework for Artificial Intelligence." The intent suggested by the title is consolidation: one national approach. But the existing state laws are reportedly not impacted in the short term. Colorado's AI Act takes effect June 30, 2026, and California's Transparency in Frontier Artificial Intelligence Act took effect January 1, 2026. So instead of one rulebook, the near-term reality for builders is a federal-versus-state patchwork. I have shipped payment systems into multi-jurisdiction environments before, and I can tell you the patchwork is the hard part, not the individual rules.
Why a patchwork is harder than a strict single rule
A single demanding regulation is, paradoxically, easier to engineer for than several overlapping ones. With one rulebook you build to the strictest interpretation once and move on. With a patchwork you have to ask, for every feature and every user, which rules apply here — and the answer can depend on where the user is, where your company is, and which kind of system you are running.
The specific tensions I would map immediately:
- Federal framework versus state statutes — a national policy direction does not automatically preempt state law, and in the short term it reportedly does not.
- Different effective dates — California's frontier transparency law is already in force, Colorado's AI Act lands June 30, 2026, so the compliance surface changes over time, not all at once.
- Different scopes — "frontier" model transparency and a broader state "AI Act" do not necessarily cover the same systems or impose the same duties.
- Geography as a runtime input — if obligations vary by state, location stops being a billing detail and becomes part of your control logic.
Building for jurisdictional ambiguity
The engineering instinct that serves me here is the same one that serves me with feature flags and tenant isolation: do not hardcode the rules into the business logic, externalize them. When the legal landscape is genuinely uncertain and likely to keep shifting, you want a system where changing a policy does not mean changing a code path.
Practically, that means:
- Treat jurisdiction as explicit, first-class context that flows through the system, rather than something inferred late.
- Express compliance obligations as configurable policy that can differ by region and tighten on a schedule, since the effective dates are staggered.
- Build to the strictest applicable standard by default where the cost is low, so a misclassified user fails safe rather than non-compliant.
- Keep the audit trail uniform everywhere, because the one thing every regime wants is the ability to reconstruct what happened.
The take
I try not to have opinions about whether AI policy should be federal or state — that is above my pay grade and outside my lane. My job is to build systems that keep working while the lawyers argue. Executive Order 14365 points toward a national framework, but for now Colorado and California still set rules that bind real systems on real dates. That ambiguity is not going to resolve cleanly or quickly. So I design for the patchwork: externalized policy, explicit jurisdiction, strict defaults, and consistent logging. If the landscape consolidates later, that architecture simplifies gracefully. If it fragments further, it absorbs the next state without a rewrite.
Sources: State AI Laws Under Federal Scrutiny, 2026 Year in Preview: AI Regulatory Developments.