The regulatory map every public sector leader must know

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.Voir la définition complète →, 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.

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.