Library
Human Oversight by Design
Oversight that cannot be performed on a Tuesday afternoon is not oversight. The reusable pattern is: the system flags, a named person confirms, the refusal path is normal, and the decision is recorded. That pattern now sits under EU, UK and GDPR legal hooks, and it is how we built Vista.
Last reviewed
MikeFounder & developer
- AI governance
- Compliance
On this page
Who this is for
- Product and operations teams putting a model into a live path
- Compliance owners who need “human in the loop” to mean something a regulator could watch
- Readers of AI Flags It, You Confirm
The pattern
Vista's design is “AI flags it, you confirm”: human oversight as a product requirement, not a slide. Generalised, the pattern is:
- The system proposes (a flag, a draft, a rank, a suggested change).
- A named person sees the inputs that mattered.
- They confirm, edit, or refuse before anything lands.
- The system records who did what, and when.
- Saying no is a normal path. It is not an incident.
That is the pattern. Everything below is how to make it survive contact with a busy queue.
Legal hooks (so you know why the pattern exists)
| Hook | What it asks | When it bites |
|---|---|---|
| EU AI Act Article 14 | Effective oversight of high-risk systems: understand limits, resist automation bias, interpret output, disregard or reverse, stop the system. Two-person verification for certain remote biometric identification. | High-risk Chapter III: 2 December 2027 (Annex III) / 2 August 2028 (Annex I), after Regulation (EU) 2026/1744. Classification: Annex III. |
| EU GDPR Article 22 | Right not to be subject to solely automated significant decisions; human intervention, expression of view, contest, in the exception cases. | Live now for EU people. Article 22 page. |
| UK GDPR Arts 22A–22D | “Solely automated” = no meaningful human involvement. Safeguards: information, representations, human intervention, contest. | Live from 5 February 2026. DUAA ADM. |
You may owe the UK or GDPR duty years before Article 14 applies. Build the loop now.
This is guidance on design, not a claim that every Lathestone system is high-risk.
Design patterns you can actually staff
Flag, then confirm
Use when the model is good at spotting candidates (out-of-date facts, likely category, likely duplicate) and a person must own the change. Vista's shape. A content change, a record update, a message to a customer.
Fail mode: auto-publish on a high confidence score.
Draft, then send
Use when the model writes and a person transmits. Complaints, emails, listings.
Fail mode: auto-send. A “send in 10 seconds unless cancelled” timer is not review.
Rank, then choose
Use when the model orders a list and a person still picks. Shortlists, triage queues.
Fail mode: dropping rows the person never sees. A CV ranker that hides the bottom 80% is often still a decision about those people. See Annex III point 4 and Article 22.
Stop button
Article 14(4)(e) requires a way to interrupt a high-risk system and bring it to a safe halt. Even off high-risk, a kill switch on a live generator is basic craft. Put it where the operator works, not in a runbook nobody opens.
The staffing test
Before you ship:
| Check | Pass |
|---|---|
| Named owner | A person who can be interrupted |
| Visible evidence | Reviewer sees what the system saw |
| Authority to refuse | No is a normal path |
| Time to look | Queue sized so review can actually happen |
| Record | Who confirmed, what changed, when |
| High-stakes extra | A second competent person where the law or the harm requires it (Art. 14(5) for listed biometric identification) |
If any row fails, you have a suggestion engine with a rubber stamp. Fix the loop before you scale the model.
Start from the inventory. Mark which rows can change a decision, a message, a price or a record. Fill the table honestly, including the ones that fail.
Questions
Does sampling 5% of outputs count as oversight?
Not for the 95% that landed unreviewed. Sampling is quality control. Oversight is about the decision the person is subject to.
We cannot afford a reviewer on every draft.
Then do not automate that path, or narrow what the model is allowed to do until the queue fits. When not to automate is the companion argument. Automation vs AI is the table.
Is this legal advice?
No. The hooks above are citations. The patterns are how we build. Counsel owns the file.
What changed
- 13 August 2026: First publication. Cadence: stable / evergreen (180–365 days). Next review due 13 May 2027. Off-cycle if Article 14's application date moves again or the ICO finalises ADM guidance on meaningful involvement.
Note: This is compliance consulting and training, not legal advice. We work alongside your legal counsel, translating regulation into operational reality rather than replacing them. For a structured pass, see AI compliance.
Was this helpful?
Also in the library
- The AI Vendor Risk ChecklistA procurement list you can actually use. Data handling, training-on-your-data, sub-processors, audit rights, and model-change notifications: the clauses that decide whether a vendor is safe to put on a live path.
- What Counts as High-Risk Under Annex IIIAnnex III is a use-case list, not a model list. Most Lathestone clients who over-classify do it because the tool is 'AI'; most who under-classify miss internal HR and customer-decision systems. Article 6(3) exemptions exist. They are narrow, and profiling is not one of them.
- Building an AI System InventoryStart with a list. Most governance programmes stall because nobody has an honest register of what is already in use, including the vendor copilots people forget to mention. The sheet below is the one we use in an audit. Copy it.