The 92% clinical-AI score does not measure the cost of human review

The often-repeated comparison is 92% for GPT-4 alone and 76% for physicians with access to it. Subtracting those medians does not establish that human review removed sixteen points of accuracy.

The underlying JAMA Network Open trial, published in October 2024, randomised fifty physicians to conventional resources with or without GPT-4 access. Participants worked on clinical vignettes. A separate exploratory analysis tested the model alone using a researcher-developed prompt.

The physicians were not simply asked to edit those same model outputs. Calling this a before-and-after test of a review gate changes the intervention the researchers actually studied.

I still take a strong operational lesson from it: the human-plus-model workflow needs its own evaluation. Neither component's score establishes what their combination will do.

Measure the intervention you intend to deploy

The trial's primary outcome was a diagnostic-reasoning rubric, not a rate of successful autonomous patient care. Physician scores with LLM access did not improve significantly over conventional resources alone. That finding deserves attention without being converted into a clinical permission slip.

For engineering teams, the transferable question is whether a proposed collaboration works under the conditions in which people will use it. Merely adding access to a capable tool does not specify the interaction.

As an illustration, I would test a hypothetical review gate for generated configuration changes in an isolated environment. Preserve the model's proposed patch, show it to the reviewer through the intended interface, and retain the reviewer's final version and decision. Evaluate both against the same independent acceptance criteria.

That design can distinguish a correction from a newly introduced defect. It can also reveal a harmful patch that a reviewer approved unchanged, or a valid patch that was unnecessarily rejected. These are properties of the review workflow that a model-only benchmark cannot supply.

I would include time and escalation behaviour as well. A gate that catches a serious defect may be worth substantial delay; one that adds delay without detecting the relevant failure needs redesign. The tradeoff should be explicit and specific to the task.

Keep the human's actual job visible

Review can mean checking correctness, supplying missing context, confirming authority or accepting responsibility for a consequential action. These jobs overlap, but a score for one cannot certify all of them.

In the hypothetical patch test, I would therefore state what the reviewer is expected to decide. If the task is to confirm that a change is authorised, a functional test alone is insufficient. If it is to find a configuration error, a manager's approval alone is insufficient.

The evaluation also needs representative reviewers and a realistic interface. An expert examining a polished answer with unlimited time is a different operating condition from an on-call engineer reviewing a proposed change amid interruptions. A result should retain that context.

I would run the exercise before expanding the gate's workload, then revisit it when the model or interface changes. The goal is evidence about the combined system, including what the person contributes and where the interaction fails.

Clinical deployment requires clinical evidence and the relevant professional and regulatory assessment. A vignette study cannot settle that decision. It can, however, stop an enterprise team from treating “human in the loop” as a complete specification—or treating a model's higher isolated score as proof that review is harmful.

Evaluate the review workflow directly; a model-versus-user comparison cannot measure what an edit gate adds or removes.