The regulatory map every public sector leader must know

# The regulatory mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → every public sector leader must know

A state unemployment agency in Ohio wants to deploy one AI tool: a chatbot that screens benefit claims and flags likely fraud. Simple enough, until you count the rulebooks it touches. The EU AI Act reaches it if the vendor's model was trained or offered by an EU-linked provider. A federal executive order shapes how the agency procures it. Ohio's own algorithmic accountability rules govern how it's used on residents. Three regulatory regimes, one chatbot, and a compliance timeline that no single office fully owns.

This collision is now routine. Public sector leaders don't get to pick one rulebook. They have to know where all of them overlap, and where they contradict each other.

Why one deployment triggers multiple regimes

AI regulation follows three different logics depending on the jurisdiction:

• The EU regulates by risk category. The EU AI Act (in force since August 2024, with obligations phasing in through 2026-2027) sorts AI systems into unacceptable, high, limited, and minimal risk. Public sector uses like fraud detection, benefits eligibility, and predictive policing are explicitly named "high-risk" (Annex III). High-risk means mandatory conformity assessments, human oversight, logging, and registration in an EU database before deployment.
• The US regulates by executive and agency action, not one statute. There is no federal AI law equivalent to the EU AI Act. Instead, guidance comes from presidential executive orders (which shift with each administration; the 2023 Biden order on "Safe, Secure, and Trustworthy AI" was rescinded and replaced by a 2025 Trump order prioritizing innovation and reduced restrictions) and agency-specific guidance, such as OMB (Office of Management and Budget) memoranda on federal agency AI use.
• US states fill the gap with their own laws. Colorado's AI Act (the first comprehensive US state law, originally set for 2026 enforcement, has faced delay votes), Illinois, and others impose duties on "deployers" of "high-risk" automated decision systems, defined state by state, with no consistent threshold.

A single tool can be minimal-risk under one framework and high-risk under another, simply because the definitions don't match.

The three-way collision, concretely

Take that Ohio chatbot again.

Under the EU AI Act: if the underlying model comes from an EU-established provider, or the output is used to affect people located in the EU (unlikely here, but relevant for federal agencies with EU citizen data), it may fall in scope with high-risk obligations: a fundamental rights impact assessment, technical documentation, and human oversight built into the design.

Under US federal rules: if this is a federal agency (not the case here, but imagine an IRS equivalent), the relevant OMB guidance would require an AI impact assessment and a designated Chief AI Officer sign-off before deployment. State agencies aren't directly bound by federal executive orders, but often adopt similar templates because federal funding (for example, from the Department of Labor for unemployment systems) increasingly comes with AI-use conditions attached.

Under Ohio or comparable state law: the agency, as a "deployer," may need to conduct an algorithmic impact assessment, notify claimants that AI is involved in the decision, and offer a human appeal path, obligations modeled on Colorado's and Illinois's approach even where Ohio's own statute lags behind.

The result: the agency needs three overlapping but non-identical assessments, three sets of documentation, and no single regulator to call for a definitive answer.

A simple decision table

| Question | EU AI Act lens | US federal lens | US state lens |

|---|---|---|---|

| Is this "high-risk"? | Yes if listed in Annex III (benefits, fraud, policing) | Depends on OMB category ("safety-impacting" or "rights-impacting") | Depends on state definition (often mirrors EU list loosely) |

| Main obligation | Conformity assessment, logging, human oversight | Agency impact assessment, CAIO sign-off | Impact assessment, notice to affected individuals |

| Who enforces | National market surveillance authorities, coordinated by the EU AI Office | OMB, agency Inspectors General | State attorney general or dedicated agency |

The core AI risks driving all three frameworks

Strip away the jurisdictional labels and the underlying risks are the same everywhere. This is the part worth memorizing, because it transfers across every law you'll encounter next:

1. Bias and disparate impact. A model trained on historical claims data can encode past discrimination (for example, flagging claimants from certain zip codes as higher fraud risk because enforcement was historically concentrated there).

2. Opacity ("black box" risk). If caseworkers can't explain why the system flagged someone, due process rights are hard to honor. This is why "explainability" appears in nearly every framework.

3. Data drift and model degradation. A model trained on 2022 claims patterns may misfire on 2026 patterns (new fraud schemes, new economic conditions) if never retrained or monitored.

4. Automation bias. Human reviewers rubber-stamp AI recommendations instead of genuinely reviewing them, defeating the "human oversight" requirement that regulators everywhere demand on paper.

5. Vendor and supply-chain risk. Most public agencies buy AI, they don't build it. The vendor's training data, update cycle, and subcontractors become the agency's regulatory exposure too.

Guardrails to run before deployment

A practical pre-deployment checklist, usable regardless of which jurisdiction's paperwork you're filling out:

• Classify the use case first. Does it decide or meaningfully influence eligibility, benefits, or enforcement against a person? If yes, assume high-risk treatment under whichever framework applies.
• Run a documented impact assessment. Not a formality, an actual analysis of who could be harmed and how (this satisfies EU, federal, and most state templates simultaneously if done well).
• Require a human-in-the-loop with real authority to override, not just a rubber stamp. Log every override for audit.
• Demand model documentation from vendors before signing: training data provenancedata provenanceData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition →, known failure modes, bias testing results, and update/retraining schedule. The US NIST AI Risk Management Framework (free, from NIST) is a solid vendor-questionnaire template.
• Build an appeal and notice path for affected individuals, since nearly every state law and the EU AI Act both require this in some form.
• Monitor post-deployment, not just pre-launch. Drift and bias can emerge after go-live even if the initial audit was clean.

# Simple pre-deployment risk flag (illustrative, not a compliance tool)
def flags_high_risk(use_case):
    triggers = [
        use_case.affects_benefits_eligibility,
        use_case.affects_law_enforcement,
        use_case.lacks_human_override,
        use_case.uses_protected_class_proxies
    ]
    return any(triggers)  # any True → treat as high-risk across all regimes

Why this matters for leaders, not just compliance teams

The mistake most public sector leaders make is delegating "AI regulation" entirely to legal or IT. But the collision described above is a governance design problem, not a paperwork problem. Deciding who owns the impact assessment, who has override authority, and how vendor contracts allocate liability are leadership decisions. If they're made only at the point of a legal review, it's usually too late to redesign the system cheaply.

Key Takeaways

• No single law governs public sector AI. Expect the EU AI Act, US federal executive guidance, and state algorithm laws to apply simultaneously to the same tool, with different definitions of "high-risk."
• Build compliance around the strictest applicable standard rather than trying to satisfy each framework separately; it's cheaper and more defensible.
• The underlying risks (bias, opacity, data drift, automation bias, vendor risk) are consistent across jurisdictions even when the legal language differs. Master the risks, not just the statutes.
• Treat impact assessments, human override authority, and vendor documentation as leadership decisions made before procurement, not compliance paperwork added after.
• Regulatory frameworks change fast (US executive orders in particular). Build governance processes that survive a change in administration or a delayed state law, rather than processes tied to one specific regulation's exact text.