5 Levels of Human-in-the-Loop: How Safe Is the AI Touching Your Health Data?
Almost every AI vendor now says there is a human in the loop. Where that human sits, who they are and what happens to their corrections is what decides whether your health data can be trusted.
Suhina Singh
Founder & CEO, Jonda Health
October 26, 2026
·
9 min read
Ask almost any artificial intelligence (AI) vendor in healthcare whether there is a human in the loop, and the answer will be yes. It is the right answer, and on its own it tells you very little. A person who glances at one record in a thousand after the data has already reached a clinician is technically "in the loop". So is a clinically trained reviewer who checks every uncertain value before it is used, and whose corrections improve every run that follows. These two set-ups carry very different levels of risk.
For health data, where a single misread value can travel into a care decision, an insurance claim or a research dataset, the useful question is not whether a human is involved. It is how that human is involved. We find that four questions get to the heart of it.
Where
Is review before the data is used, or after it has already moved on?
Who
Is the reviewer clinically trained, and accountable to you?
When
What triggers a human to look: chance, confidence scores or clinical rules?
What next
Do corrections fix one record, or improve every record after it?
Why this matters more now
Human oversight has moved from a reassuring line in a sales deck to something that clinicians, regulators and buyers now examine closely. Three pressures are driving that shift.
01 · CLINICAL RISK
The dangerous errors look plausible
The errors that matter most in health data are rarely obvious. A value in the wrong unit, a misplaced decimal in a dose or a local test name mapped to the wrong test can each look perfectly reasonable on screen.
02 · REGULATION
Oversight is becoming an expectation
The EU AI Act requires high-risk AI systems to be designed so people can oversee them effectively, and Singapore's updated healthcare AI guidelines ask organisations to scale governance to potential patient harm.1,2
03 · PROCUREMENT
Buyers are asking "who checks the AI?"
Hospitals, laboratories, insurers and pharma teams increasingly ask how review works, who does it and how accuracy is measured before they sign.
Here is what a plausible-looking error can look like in practice. None of these would trip a simple "is this field empty?" check, and each one changes what the data means.
Glucose in the wrong unit
5.5 mmol/L normal fasting result
5.5 mg/dL severe hypoglycaemia
One millimole per litre of glucose is about 18 milligrams per decilitre, so the same number can describe two very different patients.
A local test name
SGPT = alanine aminotransferase
Unmapped lost from the liver trend
Older and regional names for the same test are common across Asia and Africa. If they are not recognised, a patient's history quietly breaks into pieces.
A photographed device reading
171 / 94 as displayed
111 / 94 as read from an angled photo
Glare and angle can turn a reading that needs attention into one that looks reassuring.
Research on human oversight also carries a warning. People reviewing AI output are prone to automation bias, the tendency to accept what the system says, especially at high volume. That is why the EU AI Act names it explicitly, and why a human in the loop only works when the loop is designed around it.1,3
The 5 levels at a glance
We use a simple ladder to describe how human oversight is set up around AI that reads, extracts or transforms health data, whether that is laboratory reports, imaging reports, discharge summaries, clinical notes, medication lists or device readings. Each level up adds a clearer answer to the four questions above.
12345
No review
Spot checks
Rule-based flags
Clinical reviewon flags
Closed loop
Random samples,after the fact
Low confidencegoes to a person
Trained clinicianscheck before use
Corrections improveevery future run
HUMAN AS AN AFTERTHOUGHT
HUMAN BY DESIGN
Levels 1 and 2 add people after the fact. Levels 3 to 5 design them in from the start.
The 5 levels in detail
1
No review
AI output goes straight into your systems.
What it looks like
Documents are processed by a model, often a general-purpose large language model, and the structured result is written directly into a database or application.
The risk it leaves
Nobody knows the error rate. Mistakes surface only when a clinician, patient or auditor happens to notice them, if they notice at all.
Good enough for
Internal prototypes using test data. It is not suitable for live patient data.
Signs you are here
You cannot say how accurate your extracted data is, and there is no route for a person to correct it.
2
Spot checks
A sample is reviewed, usually after the data has been used.
What it looks like
Someone on the team reviews a handful of records each week, or checks a batch when a problem is reported.
The risk it leaves
Errors in the records nobody sampled carry on into care, claims and analytics. The review measures the problem rather than preventing it.
Good enough for
Early, low-stakes analytics while a better process is being built.
Signs you are here
Review depends on who has time that week, and fixes are made in the sampled records only.
3
Rule-based flags
Uncertain outputs are routed to a person before use.
What it looks like
Low-confidence extractions or missing fields are held back and sent to a reviewer, typically an operations or data team member, before the data is released.
The risk it leaves
Confidence scores catch what the model is unsure about, not what it is confidently wrong about. A non-clinical reviewer may also approve a value that looks fine but is clinically implausible.
Good enough for
Administrative and non-clinical fields, such as dates, identifiers and facility details.
Signs you are here
You have a review queue, but the reviewers are not clinically trained and the same errors keep returning.
4
Clinical review on flags
Clinically trained reviewers check exceptions before data is used.
What it looks like
Flags are raised by clinical logic as well as model confidence, for example values outside a plausible range or units that do not fit the test. Clinically trained reviewers check them against the source document before release.
The risk it leaves
Each record is right, but the system does not learn. The same local test name or report layout keeps generating the same flag, so review effort grows with volume.
Good enough for
Data that informs care, claims or research at moderate volume.
Signs you are here
Accuracy is good, but reviewer workload rises with every new client, laboratory or market.
5
Closed loop
Corrections improve the system, and performance is measured.
What it looks like
Everything in Level 4, plus every correction is captured and fed back into mappings, local test names and the organisation's own ontology, so the same issue is not flagged twice. Field-level accuracy, override rates and reviewer workload are tracked over time.
The risk it leaves
Governance still matters. Feedback needs clinical sign-off, and reviewer load needs watching so that automation bias does not creep back in as volumes grow.
Good enough for
Scaled, multi-market and regulated use, including data that feeds clinical systems, claims and evidence generation.
Signs you are here
Flag rates fall as the system learns each new source, and you can show an auditor exactly how any record was produced.
Sourcedocuments
AI extraction
Confidence andclinical checks
Passes
Clinicalreviewer
Structureddata out
Corrections updatemappings and ontology
The loop that
makes Level 5
The dashed line is what separates Level 4 from Level 5: corrections do not stop at the record that was fixed.
Levels side by side
Level
Who checks
When
What happens to corrections
Fit for
1 · No review
No one
Never
None are made
Prototypes on test data
2 · Spot checks
Whoever is available
After use, on a sample
Fixed in the sample only
Low-stakes analytics
3 · Rule-based flags
Operations or data staff
Before use, on low confidence
Fixed record by record
Administrative fields
4 · Clinical review
Clinically trained reviewers
Before use, on clinical and confidence flags
Fixed and logged
Care, claims and research data
5 · Closed loop
Clinically trained reviewers, with governance
Before use, with ongoing monitoring
Improve every future run
Scaled, multi-market, regulated use
Where do your humans sit? Take the 2-minute check
Answer eight questions about the AI that reads or transforms your health data today, whether you built it or use a vendor's. Choose the answer closest to how things work in practice, not how they are meant to work.
How to move up one level
Most teams do not need to jump straight to Level 5. Moving up one level is usually enough to change your risk profile, and each step builds what the next one needs.
LEVEL 1 TO 2
Start measuring
Review a fixed share of records every week, and record what you find in a consistent way.
Name an owner for errors, so that a finding leads to a fix.
LEVEL 2 TO 3
Review before use, not after
Define what counts as uncertain, such as low confidence, missing fields or values outside a plausible range.
Hold those records back until a person has checked them.
LEVEL 3 TO 4
Put clinical eyes on the exceptions
Add clinical checks for units, plausible ranges and test names, because confidence scores miss confident mistakes.
Have clinically trained reviewers check flags against the source document, with written guidance on how to decide.
LEVEL 4 TO 5
Close the loop
Capture each correction in a structured way and use it to update mappings, local test names and your ontology, with clinical sign-off.
Track field-level accuracy, override rates and reviewer workload over time, so that you can spot automation bias early.
Human review is often the part of a health data pipeline that teams underestimate. Building and running a clinically trained review team, with guidance, quality checks and a feedback loop, takes significant time and effort. When it is missing, the burden falls on your own clinicians and staff. There are two ways we can support you.
JondaX
Level 5 oversight, built in
JondaX turns laboratory reports, device readings, clinical notes and other clinical documents into structured, standardised information through a single API. Flagged items are checked by clinically trained reviewers who are part of the Jonda Health team, and their corrections feed back into your mappings and your own ontology, so the system keeps improving on your sources. The result is 99% field-level accuracy with expert review. JondaX is ISO 27001 certified and designed to comply with HIPAA, GDPR and PDPA.
Jonda Health Services
Design your oversight model
If you are building or running your own AI, we help you decide where people need to stay in the loop, set the clinical rules that trigger review, design the feedback loop and the measures that prove it works, and train and support an in-country review team where you need one.
Book a free 30-minute data readiness conversation
Bring your result from the check above, and we will talk through where your oversight stands, what moving up a level would take, and where to start.
European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: Human oversight. Requires high-risk AI systems to be designed so they can be effectively overseen by natural persons, with measures commensurate with the risks, and names automation bias. High-risk obligations apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). European Commission AI Act Service Desk. See also our article on the EU AI Act delay.
Ministry of Health and Health Sciences Authority, Singapore. Artificial Intelligence in Healthcare Guidelines (AIHGle 2.0), published 10 March 2026. Recommends a risk-based approach to deployment and governance, proportionate to potential patient harm. Guidelines (PDF). See also our article on what AIHGle 2.0 means for developers, hospitals and clinicians.
Fink M. Human Oversight under Article 14 of the EU AI Act. SSRN working paper, 2025, forthcoming 2026. Discusses the limits of human oversight, including cognitive constraints and automation bias. SSRN.
