>>
Industry>>
Healthcare>>
The Model Was Smarter Than the...By Dr. Brandy “Dr. Z” Zachary, Founder and CEO, TDZ Functional Medicine Academy
A randomized clinical trial recently gave physicians GPT-4 and asked them to work through difficult diagnostic cases. The doctors with AI scored 76 percent. The doctors without it scored 74 percent, a difference that was not statistically significant. Then the researchers tested GPT-4 alone, and the model outperformed the physicians using conventional resources by 16 percentage points.
That should have stopped a few people in their tracks.
The tool was clearly capable of more than the humans were extracting from it, yet simply putting that capability in front of them did not meaningfully improve performance. The intelligence was there. The transfer was not.
That is not just a healthcare problem. It is an enterprise AI problem.
Over the last two years, companies have spent heavily on models, copilots and AI platforms, then measured licenses, logins and adoption rates as though access itself were transformation. But access tells you almost nothing about whether the system improves judgment, reduces error, shortens cycle time or produces better decisions. A powerful model can sit inside an organization and create surprisingly little advantage if the human-machine interaction around it was never designed.
I noticed this problem before I had a name for it. I could sit beside another practitioner using the same AI model on the same underlying problem and get a dramatically better result.
The difference was not the tool. It was what happened after the first answer.
I would challenge the model, add missing context, tell it what it had overlooked, ask it to argue against itself, change direction, correct an assumption and push again. Someone else might ask one question, receive one answer and stop. The same model, given the same underlying problem, could produce materially different outcomes depending on the skill of the person using it.
In medicine, that kind of variance is unacceptable. It should also be uncomfortable in underwriting, procurement, engineering, legal review, cybersecurity or financial analysis.
If two capable employees can use the same system on the same class of problem and reach different decisions because one happens to know how to “talk to AI” better, that is not merely a training issue. It is a design flaw.
Much of enterprise AI is still being deployed through an empty prompt box. We have taken extraordinarily capable machine intelligence and made its usefulness depend on the least standardized part of the system: the human being typing into it.
Then we wonder why the outcomes are inconsistent.
Enterprise technology has lived with “garbage in, garbage out” for decades. Generative AI did not fix that problem. It made the garbage more persuasive.
Bad or incomplete data can now return as polished prose, a confident recommendation or an executive-ready summary. That is potentially more dangerous than an obviously bad answer because the presentation hides the weakness of the underlying inputs.
We ran into this while developing clinical technology. Imagine uploading a laboratory report containing 150 markers. A general-purpose model can produce a sophisticated analysis, but the important question is whether it actually received and processed all 150 markers correctly.
Maybe it did.
Maybe it missed 50 in the middle of a dense table and answered anyway.
In healthcare, one of those missing values could require immediate medical evaluation, so we had to build separate extraction technology before sophisticated reasoning even became useful. It was a blunt reminder that intelligence downstream cannot compensate for missing or unreliable data upstream.
The enterprise equivalent may be less dramatic, but the architecture problem is the same. Did the model receive the complete contract? The current policy? The right financial period? The customer history containing the exception? The source document that actually governs the decision?
A model cannot reason over information it never received, and the final answer may not tell you what was missing.
When we first tried to automate a complex clinical workflow, I wanted the easy answer. I assumed we could wrap a large language model, add an interface and move on.
We could not.
Once you move from generating an impressive answer to building something people can depend on, the work changes. Now you are dealing with ingestion, extraction, normalization, retrieval, structured knowledge, deterministic logic, validation, provenance, conflicting inputs, permissions, escalation and human review.
You also have to make a decision that AI enthusiasm often skips: which parts of the workflow should not be generative at all.
Probabilistic systems are powerful when interpretation, synthesis and language matter. They are not automatically the right tool for every step. Sometimes you need a rule. Sometimes you need a lookup. Sometimes you need an exact value extracted exactly the same way every time. Sometimes you need the system to stop and hand the problem to a human.
That is why asking, “Which model are you using?” tells me surprisingly little about the quality of an AI deployment. The model may be the most visible layer, but it is often not the layer that determines whether the system is reliable.
The standard answer to inconsistent AI performance is training, and training absolutely matters. A 2026 randomized trial involving physicians in Pakistan found that, after completing a 20-hour AI-literacy curriculum, physicians with GPT-4o access substantially outperformed physicians working with conventional resources alone.
That study does not prove that the training caused the entire performance difference, because the curriculum itself was not randomized. But it reinforces a broader point: how people interact with AI changes the value they get from it.
Where I part company with a lot of enterprise AI advice is what happens next.
I do not believe the long-term solution is turning the workforce into prompt engineers.
Employees should understand what the technology can do, where it fails and when not to trust it. They should know how to challenge an answer and verify a consequential conclusion. But if a product only works well when the user knows the perfect prompt sequence, understands exactly how much context to provide and recognizes when the model has quietly gone off course, then too much of the product still lives inside the user’s head.
That is not mature deployment.
The better question is how much of that complexity can be absorbed into the system itself. Can context be gathered automatically? Can relevant data be retrieved before the employee asks? Can dangerous steps require verification? Can important outputs show their source? Can uncertainty trigger escalation instead of another confident paragraph?
The goal should be to make good AI use easier than bad AI use.
Enterprise AI also needs to be more skeptical of the phrase “human in the loop.” It sounds reassuring, but it can describe almost anything.
A human who clicks “approve” on an AI-generated recommendation is technically in the loop. So is a human who never sees the source material, or one who has grown accustomed to trusting the system because it was correct the last 40 times.
The question is not whether a person appears somewhere in the workflow. The question is what job that person is actually performing.
Are they supplying context the machine does not have? Resolving ambiguity? Reviewing evidence? Challenging a consequential recommendation? Taking responsibility for the decision?
Or are they rubber-stamping machine output so the organization can claim a human approved it?
That distinction becomes more important as AI gets better, because polished, plausible output is precisely what encourages people to stop checking.
This is where many AI rollouts go wrong at the executive level. Companies count licenses, logins, active users and prompts submitted, then call the deployment successful.
Those metrics tell you that employees touched the technology. They do not tell you whether the organization got better.
The physician trial makes that painfully clear. The doctors had the tool. They used the tool. The advantage largely failed to transfer.
Enterprise leaders should be asking harder questions. Did decision quality improve? Did cycle time fall without error rates climbing? Did rework decrease? Did outcomes become more consistent across users? Are the right cases being escalated? Are mistakes easier to detect?
Most importantly, can two people using the same system reach a reproducibly good result?
That is deployment. Everything before that is access.
The strange thing about this moment is that the part everyone is obsessed with may become the least differentiating part.
Foundation models will keep improving. They will get faster, cheaper and more capable. Competitors will have access to similar underlying intelligence.
The advantage moves outward, into the data, workflow, domain knowledge, retrieval, orchestration, controls, evaluation and the places where the system knows not to use generative AI at all.
Raw intelligence is becoming abundant. Reliable application of intelligence is not.
That is why I think the companies that win the next stage of enterprise AI will not necessarily be the ones with the smartest model. They will be the ones that make extraordinary intelligence dependable enough to disappear into the work.
The doctors already taught us the lesson.
A brilliant model does not guarantee a brilliant deployment.
Comments