AI Regulation Is Splitting, Not Settling

The regulatory path for AI in the channel is not converging on one standard. Washington is trying to force a single national framework and is fighting state AI laws in court, while states keep writing and defending their own rules anyway. For an MSP reselling AI tools, build compliance flexibility into your stack now, not around one rulebook winning.

Why is Washington trying to override state AI laws?

On December 11, 2025, President Trump signed Executive Order 14365, setting federal policy toward a single, minimally burdensome national AI framework instead of what the order calls a patchwork of fifty different state regimes. The order directs the Attorney General to stand up an AI Litigation Task Force whose sole job is challenging state AI laws the administration considers unconstitutional or already preempted by federal law. It also tells the Commerce Department to identify the most onerous state AI laws and instructs the FTC chair to issue a policy statement on when state rules that force AI systems to alter their truthful outputs are preempted by the FTC Act's ban on deceptive practices. The order further directs agencies to use federal grant money, including remaining BEAD broadband deployment funds, as leverage against states with AI laws the administration calls onerous.

None of this repeals a single state law by itself. An executive order can direct agencies to sue, to write policy statements, and to withhold discretionary funding, but only Congress or the courts can actually strike a state statute down. The order also limits its own reach in one notable way, since any legislative recommendation it produces is barred from proposing preemption of state laws covering child safety protections, AI compute and data center infrastructure, or state government procurement and use of AI. That carve-out is worth watching if any of your clients sit in those excluded categories, because state authority there is not going away regardless of how the federal fight ends. That gap between stated intent and legal authority is exactly where the fights below are playing out.

What happened when Colorado tried to go it alone?

Colorado passed the country's first comprehensive state AI law in 2024, Senate Bill 24-205, which would have required companies to run impact assessments and disclosures on any AI system used in a consequential decision like hiring, lending, or healthcare, before the law was later scaled back. Lawmakers pushed the effective date from February 1, 2026 to June 30, 2026 after failing to agree on amendments, and then the law's path changed fast. A federal magistrate judge blocked Colorado from enforcing the law after xAI sued and the Department of Justice intervened on its side, arguing the law's disclosure rules amounted to compelled speech and its anti-discrimination provisions imposed unconstitutional obligations on developers. Governor Jared Polis then signed a replacement, Senate Bill 26-189, which strips out the impact-assessment framework in favor of a narrower notice-and-disclosure model and pushes the new effective date to January 1, 2027.

SB 189 also rewrites who is on the hook for a problem, assigning fault between developers and deployers based on whether an AI tool was used as intended and whether proper documentation was provided, while barring both joint-and-several liability and contract clauses that try to shift that allocation. That is a law passed, delayed, blocked by a federal court, and rewritten inside roughly two years. If you build client contracts or configurations around any single state's current AI statute, you are building on ground that can move before the ink dries.

Is Texas's approach the new model?

Texas took a different route. Governor Greg Abbott signed HB 149, the Texas Responsible Artificial Intelligence Governance Act, with an effective date of January 1, 2026, and unlike Colorado's impact-based approach, TRAIGA only creates liability when a company intentionally builds or deploys AI to discriminate, manipulate someone into self-harm or crime, or violate constitutional rights. Enforcement sits exclusively with the Texas Attorney General, who must give notice and a 60-day cure period before pursuing a case, and penalties then escalate quickly: curable violations run $10,000 to $12,000, uncurable violations run $80,000 to $200,000, and violations left open past the cure period add $2,000 to $40,000 per day.

TRAIGA also created a 36-month regulatory sandbox administered by the Texas Department of Information Resources, letting approved participants test AI systems without obtaining otherwise-required state licenses while still following the law's core prohibitions. TRAIGA also gives companies a safety net. Businesses that substantially comply with the NIST AI Risk Management Framework, catch violations through their own internal testing, or get hit by a third party's misuse of their system can use those facts as a safe-harbor defense. That is a strong argument for building documented AI governance into your own service catalog now, since the documentation that protects your client under Texas law is the same documentation a regulator in almost any other state will eventually ask for.

What does the FTC's enforcement push mean for AI resellers?

The federal government is not only taking state laws to court, it is also widening its own enforcement at the same time. The FTC brought more than a dozen cases last year against companies for overstating or inventing their AI capabilities, and in April 2026 testimony Chairman Andrew Ferguson described that enforcement as part of fostering American innovation. That enforcement has also reached business-to-business vendors who supplied misleading AI marketing materials, not just consumer-facing products.

For an MSP white-labeling an AI product, that second point matters more than the state law fights. A deceptive-practices case does not require a state statute at all, and it reaches the marketing copy you put around a tool just as easily as it reaches the vendor who built it.

How should MSPs build their stack for this environment?

None of this is settled, and that is exactly the point for how you should plan. A law can pass, get delayed, get blocked by a federal court, and get rewritten inside the same two years, the way Colorado's did. Betting your service catalog on any single state's rules, or on the federal preemption push succeeding, means rebuilding client contracts and configurations every time the ground shifts again.

If you operate across state lines, and most MSPs with more than a handful of clients do, you are not really choosing between Colorado's rules and Texas's rules. You are complying with whichever law covers the state where each client's own end users sit, which means your AI vendor contracts and configuration checklists need enough flexibility to satisfy the strictest rule touching any one client, not just the rule in your own headquarters state.

The more durable move is to build AI governance into what you already sell: documented system inventories, usage disclosures, vendor risk reviews, and a change log for when an AI feature in your stack gets modified. That kind of record travels across jurisdictions better than chasing each new statute, and it gives your technicians something concrete to point to if a state attorney general or the FTC ever comes asking. Vendors are already pitching AI governance to MSPs as a recurring service line built around assessment, policy design, monitoring, and audit-readiness reporting rather than a one-time project, which maps onto the way you already bill for managed security.

Building that function takes training, not just tooling. If your team cannot explain the difference between a disclosure requirement and an impact-assessment requirement, that is a gap Forge University is built to close, giving technicians and account managers a shared vocabulary before a client asks why their AI chatbot needs a visible disclosure on the homepage.

Figuring out which parts of your current stack actually trigger these rules is its own project. Running your tools through the stack builder gives you a structured way to see where a disclosure, documentation, or human-review requirement might already apply, before a regulator points it out for you instead. The products you resell matter here too, since a developer's own documentation and safe-harbor practices become your evidence if a deployer obligation is ever challenged, and reviewing the full product catalog is a reasonable place to start matching what you already sell against what each new rule actually requires.

The regulatory map will keep moving, in Washington and in state capitals alike, but what you build into your own stack today does not have to wait on either one. See the full stack to find white-labeled tools built with that kind of flexibility in mind.