When Your Role Spans Jurisdictions That Disagree

When your role spans jurisdictions that disagree.

A system built once and deployed everywhere does not get to obey one law. It has to satisfy the strictest applicable rule in every jurisdiction it touches, simultaneously, which is a harder engineering and governance problem than most organisations budget for.

It is now the ordinary case, not the exception, for a single AI system to be bound at once by the EU AI Act, a US state law like Colorado’s or California’s, and a third regime, UK, or an APAC jurisdiction with its own emerging rules, each written independently, on different timelines, with different definitions of what counts as “high-risk,” different disclosure requirements, and different enforcement mechanisms.

Our own Statute tracks sixteen of these side by side precisely because none of them defer to each other, and a system compliant in one is routinely not compliant in another.

Why “pick the strictest rule” isn’t sufficient on its own

The intuitive shortcut, build to the strictest applicable standard and assume it covers the rest, works for some requirements and fails for others, and knowing which is which is most of the actual skill.

It works reasonably well for data protection: GDPR’s requirements are stringent enough that meeting them satisfies most lighter regimes elsewhere, though not all, some US state laws impose specific disclosure requirements GDPR does not require in the same form.

It works poorly for risk classification, because different laws do not just set different bars on the same scale, they sometimes classify the same system differently. A hiring tool might sit in the EU AI Act’s high-risk tier, trigger a narrower, sector-specific obligation under a US state’s automated-decision law, and fall entirely outside a third jurisdiction’s current scope. There is no single “strictest” setting that satisfies all three, because they are not measuring the same thing.

Timelines compound this further. The EU AI Act’s obligations phase in over several years, some US state laws are already in force, and a jurisdiction can amend or delay its own rules with little warning, Colorado’s own AI Act was pushed back and substantially rewritten after its original passage. A compliance posture built against a snapshot of the regulatory landscape at deployment time can be materially wrong within a year, not because anyone did anything incorrectly… but because the ground moved!

What actually works in practice

The organisations handling this well tend to do three things consistently.

First, they maintain a live jurisdiction map tied to the system itself, not a one-time legal memo: which laws currently apply, based on where the system is deployed and who it affects, reviewed on a set cadence.

Second, they build configurability into the system’s governance layer, not just its features, so a stricter disclosure requirement or a narrower permitted-use case in one jurisdiction can be applied there specifically without a full redeployment.

Third, and most often skipped, they name a single accountable owner for tracking regulatory change across all applicable jurisdictions, rather than leaving it distributed across legal, compliance, and engineering with the assumption that someone else is watching the given jurisdiction.

None of this eliminates the underlying difficulty.

Jurisdictions will keep disagreeing, on different timelines, for the foreseeable future. The realistic goal is not a single compliance posture that resolves every conflict permanently. It is a maintained, current, honestly-uncertain-where-it-needs-to-be map of what applies where, reviewed often enough that the gap between what the map says and what the law actually requires stays small.

Written by us at Ethics Directive. If anything here needs correcting, we will say so in the open, dated.