Most AI products are designed around what the software can do. The ones people trust are designed around what the person still has to decide.
In clinical and regulated work, that isn't a nice-to-have. A clinician signs the record. A compliance officer owns the filing. An underwriter answers for the decision. If the screen makes it easy to approve without looking, the product has quietly moved the risk onto the person least able to see it.
Regulation is catching up. The EU AI Act asks that high-risk systems are designed so a person can oversee them. In practice that means understanding what the system can and can't do, noticing when they are leaning on it too hard, reading its output correctly, and being able to override or stop it. Those obligations arrive over the next couple of years. The design problem is already here, in every product that drafts, triages, flags or acts.
These are the twelve patterns I keep coming back to. Some come from building Kaido, a clinical workspace where the software records and proposes and the clinician decides. The rest come from watching how people actually review what software suggests.
The judgment layer is the part of an AI product where software hands a decision to a person to review, approve or override: the evidence they see, the controls they use and the record that remains.
1. Separate the measurement from the decision.
In Kaido, a physio records a heel-raise count changing from 18 to 19. The record updates straight away. The patient's status stays at Not yet, because readiness is the clinician's call, not the count's. The data, the suggestion and the decision are three different things. They should look like three different things.
2. Put the evidence before the approve button.
If approve sits above the evidence, people approve and then skim. Put what the system relied on first: the source line, the measurement, the document. Put the action after it, so reading comes before deciding.
3. Show what was assumed, not just what was found.
Most errors hide in the gaps the system filled in by itself: a date inferred, a name matched, a missing field defaulted. Mark those separately from what it confirmed. That one distinction does more for review quality than a confidence score.
4. Say how sure, in the reviewer's language.
A percentage means little to a GP at six in the evening. "Matched on NHS number and date of birth" or "two sources disagree" tells them where to look. Express confidence as a reason, and let low confidence change the layout, not just the colour.
5. Put the gate where the consequence is.
Not every step needs a confirmation. Too many gates and people click through all of them. Put the hard stop where an action is hard to undo or leaves the building: sending, filing, prescribing, paying. Keep the rest light.
6. Make disagreeing as easy as agreeing.
If accepting is one tap and disagreeing is a form, the product has picked the answer for the person. Editing, rejecting or changing a suggestion should cost the same effort as agreeing with it.
7. Undo, with a window people can see.
Where an action can be reversed, show for how long, and keep the undo where the action happened. People take sensible risks when they can see the way back.
8. A stop that actually stops.
Every system that acts on its own needs an obvious way to pause it, and a clear account of what was already done and what wasn't. Paused should never mean "still finishing the queue".
9. Let autonomy be earned, one task at a time.
Most products offer two settings: ask about everything, or ask about nothing. The trusted ones have a ramp. The system proposes, is approved often enough on one type of task, then acts on that type and reports back. Make the ramp visible, and make it easy to step back down.
10. Design the handback.
When the system reaches the edge of what it can do, the handover to a person is the moment most likely to fail. Show what it tried, what it is unsure of and what the person needs to do next. "Needs review" is not a handback.
11. Watch for rubber-stamping, on purpose.
People get used to systems that are usually right. That is when review turns into a reflex. Make it visible: how often does a reviewer accept without opening the evidence? Bring that back to the team as a signal, not a reprimand.
12. Keep a record a person can read.
Audit logs are usually written for engineers. The person who has to explain a decision later needs a different record: what the system suggested, what they saw, what they changed and why. When that record is easy to read, people review more carefully, because they know it will be read.
The test I use
For any screen where software suggests and a person decides, I ask three questions. Can they see why, before they agree? Is disagreeing as easy as agreeing? Afterwards, could they explain what happened in a sentence?
If the answer to any of them is no, the AI isn't the hard part. The design is.
Questions
What is the judgment layer in an AI product?
It is the part of the product where software hands a decision to a person to review, approve or override. It covers the evidence the person sees, the controls they use to agree, change or reject, and the record that remains afterwards.
How do you design human oversight into an AI product?
Start with three questions for every screen where software suggests and a person decides. Can they see why, before they agree? Is disagreeing as easy as agreeing? Afterwards, could they explain what happened in a sentence? The twelve patterns above are ways to get each answer to yes.
How do you stop people rubber-stamping AI suggestions?
Put the evidence before the approve button (pattern 2), mark what the system assumed (pattern 3), make disagreeing as cheap as agreeing (pattern 6), and measure how often people accept without opening the evidence (pattern 11).
Does the EU AI Act require human oversight?
Yes, for high-risk systems. Article 14 asks that they are designed so people can oversee them effectively: understand what the system can and can't do, notice over-reliance, read its output correctly, and override or stop it. Those obligations are phasing in.
Can you review my product against these patterns?
Yes. A Judgment Review scores one critical flow against the twelve patterns in three days and hands over annotated screens and a prioritised list of fixes. If you'd like a smaller first step, I'll send three free observations within 48 hours.
If you're building an AI product where people review, approve or override what it does, I'll send three specific observations on your flow, free, within 48 hours. Send me your product or email hello@cybercyber.ai.