Tracking human-oversight mandates across jurisdictions
A multinational tracking AI regulation faces a research problem with no shared taxonomy: fifteen jurisdictions, different instruments, different definitions, and the same underlying question.
How much do human-oversight mandates actually differ?
Less than the vocabulary suggests. Different regimes use different words — human oversight, meaningful human involvement, competent supervision — and ask three overlapping questions: was an identified person involved, did they have real authority, and can you produce evidence.
- Requirements differ in scope and vocabulary and converge on four demands: identify the person, record what they saw, show authority, retain it.
- Tracking is expensive because there is no common structure; most of the cost is normalisation rather than reading.
- A structured schema turns an annual research exercise into a maintained dataset.
Part of Research, datasets and methods
Why this is expensive to track
The difficulty is not finding the instruments. It is that they cannot be compared without normalisation.
| Dimension | Variation |
|---|---|
| Instrument type | Statute, regulation, sector guidance, supervisory expectation |
| Trigger | Risk classification, sector, decision type, or effect on individuals |
| Vocabulary | Human oversight, meaningful human review, human intervention, natural person verification |
| Record requirement | Explicit and detailed, explicit and vague, or implied |
| Timing | In force, phased, announced, or in consultation |
| Enforcement | Administrative penalty, private right of action, supervisory action |
Reading one instrument takes an hour. Making it comparable to fourteen others takes considerably longer, and doing it consistently over time is what defeats most internal efforts.
The convergent core
Beneath the variation, the same four demands recur.
- Identify the person. A natural person, not an account or a team.
- Record what they considered. The output, and often what was displayed.
- Establish their authority. Could they have decided otherwise?
- Retain it. For a period, retrievable and intact.
An organisation that satisfies these four is well positioned under most instruments. One that satisfies none is exposed under all of them, and the specific jurisdiction is a detail.
A schema for tracking
{
"jurisdiction": "...",
"instrument": { "name": "...", "type": "statute|regulation|guidance",
"status": "in_force|phased|proposed|consultation" },
"scope": { "trigger": "risk_class|sector|decision_effect",
"applies_to": "provider|deployer|both" },
"human_oversight": {
"required": true,
"terminology": "as used in the instrument",
"identifies_natural_person": true,
"requires_authority_to_override": true,
"requires_record_of_content_reviewed": false
},
"records": { "required": true, "retention": "...", "format": "unspecified" },
"dates": { "adopted": "...", "effective": "...", "phases": [] },
"enforcement": { "mechanism": "...", "private_right": false },
"sources": [ "..." ],
"last_reviewed": "2026-07-15"
}The last_reviewed field is what makes a dataset like this trustworthy. A regulatory tracker without review dates is a snapshot presented as current, which is worse than no tracker.
Why an open dataset works better than a proprietary one
| Property | Proprietary tracker | Open dataset |
|---|---|---|
| Coverage | Depends on one team's capacity | Contributions from local practitioners |
| Accuracy | Unverifiable by the user | Checkable against cited sources |
| Correction speed | A support ticket | A correction with a citation |
| Bias | Reflects the vendor's product interest | Visible, because the sources are shown |
The bias row deserves acknowledgement. Any tracker maintained by a party with a commercial interest in the requirements being demanding should be read with that in mind, and publishing the sources is how that is made checkable.
Using it without over-reading it
Three appropriate uses and one inappropriate one.
- Scoping: which jurisdictions have requirements that plausibly reach your systems
- Sequencing: which deadlines come first
- Design: what the convergent core requires, so you build once
- Not: determining whether a specific obligation applies to you — that is a legal question about your systems and your facts
A tracker tells you where to look. It cannot tell you whether your particular deployment is in scope, and treating it as though it can is how organisations get this wrong in both directions.
What to build regardless
The four convergent demands. They are required by every instrument in some form, they are expensive to retrofit, and they are useful independently of regulation — an incident investigation asks the same four questions.
This describes regulatory structure at a general level and is not legal advice. Applicability and timing depend on your systems and jurisdiction; take specifics to counsel.
A starting schema
A tracker is only useful if each row answers the same questions, so the schema matters more than the coverage. Eight fields are enough to be useful and few enough to keep current.
| Field | Contents |
|---|---|
jurisdiction | Country or bloc, plus sub-national where applicable |
instrument | Statute, regulation or guidance, with a citation |
status | Proposed, enacted, in force, or lapsed |
trigger | What brings a system into scope |
oversight_language | The exact phrase used, untranslated |
identity_required | Whether a natural person must be identifiable |
record_obligation | What must be retained, and for how long |
verified_on | Date the entry was last checked against source |
What a starter set looks like
A handful of entries, recorded in that schema, makes the overlap visible immediately. Statuses move, so each row carries a check date and each is a pointer to the primary source rather than a substitute for it.
| Jurisdiction | Instrument | Oversight language |
|---|---|---|
| European Union | Regulation (EU) 2024/1689, Articles 14 and 26 | “human oversight” by natural persons |
| European Union | GDPR Article 22 | decisions “based solely on automated processing” |
| United States — Colorado | SB24-205 (Colorado AI Act) | duties of care around algorithmic discrimination |
| United States — California | CCPA automated decision-making regulations | access and opt-out around automated decisions |
| United Kingdom | Sectoral, via existing regulators | varies by regulator |
Entries lapse. A bill that dies when a legislature is dissolved should stay in the dataset with status lapsed rather than being deleted, because the drafting tells you where the next attempt will start.
Objections and honest limits
“A proprietary tracker would be better maintained.” The opposite, usually. A dataset anyone can correct gets corrected, and the corrections are visible. A proprietary one is as current as one vendor's staffing.
“This is close enough to legal advice.” It is not, and the dataset should say so on every page. A tracker is an index to primary sources, and the verified_on field exists to stop anyone treating a row as current by default.
Using a tracker without over-reading it
- Read the primary source before relying on a row. The row is an index, not an authority.
- Check the verification date. Statuses move faster than trackers.
- Do not treat translations as operative. Record the original phrase.
- Keep lapsed entries. Dead bills predict live ones.
- Build to the convergent core. Not to any single jurisdiction.
Terms used here
- Convergent core
- The requirements that recur across regimes regardless of vocabulary — identity, authority, evidence.
- Trigger
- What brings a system into a regime's scope, which varies far more than the obligations do.
- Lapsed instrument
- A proposal that died procedurally, which usually returns in similar form.
Frequently asked questions
Why is regulatory tracking expensive? Finding instruments is easy; normalising them so they are comparable is not. Most of the cost is structural, and consistency over time is what defeats internal efforts.
What do the instruments have in common? Identify the natural person, record what they considered, establish their authority to decide otherwise, and retain it.
Why does a review date matter? A tracker without one is a snapshot presented as current, which is worse than no tracker at all.
Can a tracker tell us whether we are in scope? No. It tells you where to look. Whether a particular deployment is in scope is a legal question about your systems and facts.
Why track the exact phrase used? Because translations and paraphrases lose the distinctions that determine scope. Record the original and link the source.
Why keep dead bills? Drafting that lapsed procedurally usually returns in similar form, so it tells you where the next attempt starts.
Is this legal advice? No. A tracker is an index to primary sources, which is why every entry carries a citation and a verification date.
Where this fits in Manav
Every regime in the dataset asks the same three questions. Manav produces one artefact that answers all three.
Sources and further reading
- Regulation (EU) 2024/1689 (AI Act) — consolidated text
- State and national AI statutes addressing automated decision-making.
- Sector regulator publications on AI oversight expectations.
- GDPR Article 22 — automated individual decision-making
- GDPR Article 22 — automated individual decision-making
- Colorado SB24-205 — signed act