In many pathology AI projects, failure does not arrive when the model is tested. It comes later, when the team shows a convincing result and nobody knows who owns the decision to use it in daily work. That is the core of Dr Luis Cano’s article in Beyond the Slide, titled “The Problem Is Not the Model. It’s the Meeting After the Model.” The point matters because it touches a problem laboratories see more often than they like to admit.
The model may produce a valid prediction. The whole slide image is clear. The histologic or spatial analysis is coherent. Yet the meeting ends with a request for more data, another experiment, or another presentation to another committee. This does not always happen because the evidence is weak. Sometimes it happens because the next decision carries clear responsibility, and no person or governance body is ready to carry it.
Adoption starts with the decision, not the server
Discussion of AI in pathology often focuses on performance: sensitivity, specificity, AUC, reader agreement, or the model’s ability to handle variation in staining and scanners. These metrics are necessary, but they do not answer the adoption question by themselves. The pathologist needs to know what will happen when the system produces its output inside the diagnostic pathway.
Does it change case prioritization? Does it trigger additional IHC? Does it escalate a case for second review? Does it enter the diagnostic report? Who stops it when there is an obvious failure? And who has the authority to ignore the result? If these questions remain unanswered, the project will stay a good meeting demonstration, not a tool used on the work platform.
The article points to a familiar gap: many laboratories own WSI scanners, but routine daily use is much lower. The exact number varies between health systems, but the meaning is familiar. Buying a scanner does not make a laboratory digital. Installing an AI model does not mean diagnosis has changed.
Paralysis from endless evidence
One failure pattern described in the article is the request for new evidence every time the team gets close to a decision. At first the request is scientific and reasonable: an external validation set, a scanner comparison, or performance analysis by specimen type. After a certain point, the request becomes organized postponement.
In pathology, this pattern appears when a team presents a successful model for case triage, biomarker measurement, or suspicious-region detection, then enters a loop of questions: what about a different stain tone? What about another fixation protocol? What about another scanner? Some of these questions are important. But if there is no predefined threshold for when the evidence is enough for a limited and safe decision, the project will not reach the clinic.
The problem is not a love of precision. Precision is required in diagnosis. The problem is that the absence of a clear decision threshold makes the team confuse scientific validation with avoidance of responsibility. Every tool needs a stopping point: if it meets these criteria, it enters this defined use, under this monitoring, with these permissions.
Intent exists, authority is missing
The second pattern is more frustrating because it happens in enthusiastic teams. Everyone agrees that the tool is useful. The pathology department wants it. Health informatics does not oppose it. Administration sees its value. Still, final approval never arrives. There is no real scientific disagreement, but nobody has enough delegated authority to connect the model to a diagnostic or operational decision.
This slowly kills enthusiasm. The team that built the model keeps updating and maintaining it without a clear effect on work. Pathologists try it in limited sessions, then return to the old pathway. Months later, the project becomes an administrative burden rather than a tool that reduces pressure or variation.
In a busy laboratory, it is not enough to say the system is useful. The decision owner must be named: the laboratory director, department chair, quality committee, informatics lead, or a joint team with written authority. Without that, AI becomes a file that is always open and never adopted.
A lesson from clinical decision support alerts
The article cites the experience of Epic’s sepsis prediction model, where alert volume rose during the COVID-19 wave, and the alerts were eventually stopped because clinical teams did not have a clear framework for translating the alert into treatment action. The example is outside pathology, but it is close to our reality.
Any system that adds new signals to a pathologist’s day must answer the cognitive-load question. If the model adds alerts without priority, or results without a pathway, it becomes noise. If every alert needs a new discussion, it will not survive in a laboratory processing hundreds of slides per day.
Good tools do more than produce a result. They place that result at a defined point in the workflow. Examples include triaging HER2 cases for faster review, marking ROI areas before measurement, or suggesting cases for second read under defined rules. A narrow and clear use is better than broad promises that end in a screen nobody opens.
What this means for the pathologist
The pathologist should not leave an AI project to the technical team alone. The model touches diagnostic decisions, prioritization, documentation, and professional responsibility. The first question when evaluating any tool should be: where does it enter the pathway? The second: who owns the decision that follows from it?
If the tool measures Ki-67 or PD-L1 or detects nodal metastases, the intended use must be written before launch. Is it a reading aid? Does it provide a measurement that enters the report? Is it used only for triage? What are its limits in poor samples or slides with artefacts? What is the plan to pause it if performance changes after a scanner update or staining-protocol change?
These are not minor administrative details. They are safety conditions. They also protect the tool from slow death after the first wave of enthusiasm.
A practical test before buying or building any tool
Before adopting a new model in a pathology laboratory, the team can ask five short questions. Who will use the output? Which decision will change? What is the minimum evidence required before deployment? Who reviews errors and drift? And when do we decide that the tool has failed or needs recalibration?
If the team cannot answer in clear sentences, the project is not ready, no matter how attractive the performance curves look. It may be better to run it in a narrower scope: one specimen type, one marker, or one workflow step. A limited success that can be measured is more useful than a large project with no entry point into routine work.
Professional takeaway
The article identifies a common flaw in medical AI projects: teams over-engineer the model and postpone engineering the decision. In pathology, this is costly because the diagnostic output does not live in isolation. It lives inside a report, a tumor board, a clinical trial, or a treatment decision.
Every AI project needs a written decision pathway with the same clarity we expect from staining protocols and quality-control procedures. Without it, the model will succeed in the presentation and remain absent from diagnosis.
Source: Beyond the Slide