AI-Generated Summary: Artificial intelligence has promising applications in antimicrobial stewardship, but its effectiveness is limited by incomplete clinical documentation, historical prescribing practices, and discrepancies between when clinical decisions are made and recorded. Rather than replacing clinical judgment, AI can help stewardship teams identify patients needing intervention, recognize complex patterns, and reduce missed opportunities to optimize antibiotic therapy.
Authored by: Martijn M. Siepel, Ph.D. Candidate
Article Under Construction, 17 October 2026
AI is everywhere. Most people already use it in daily life for simple tasks, like writing an email, summarizing a paper, or coming up with a new recipe. In healthcare it is increasingly being used too, and infectious diseases is no exception. For example, a lot of work is going into models that can predict which patients are at risk of developing sepsis, so they can be treated earlier, and models that predict antimicrobial resistance, to help choose the right empirical treatment before culture results are available. Additionally, a growing line of research focuses on antimicrobial stewardship (AMS): monitoring and improving how antibiotics are prescribed. Here, models predict outcomes such as when a patient can switch from IV to oral antibiotics, when treatment can be de-escalated, or when it can be stopped altogether.
Two kinds of AI are at play here. The first is the one most people know: large language models (LLMs) that read and write text. The second is the prediction model, or classifier: it learns patterns from past data to predict an outcome, like which patient is at risk of sepsis. Those are the models I build, and they are what this post is about.
Developing these stewardship models is the focus of my work as a Ph.D. researcher and medical informatician in the antibiotic stewardship team (the A-team) at Amsterdam UMC in the Netherlands. In this post I want to share some of what I have learned building them, so that the next time you come across a tool like this, you understand where its limits come from and how it can actually make your work easier.
What I have learned is that the hard part is rarely the AI itself. The hard part is infectious diseases, and the way we record what we do. Most of what limits a model has to do with how care is delivered and written down. So this post is not about how the models work, and you do not need a technical background to follow it. It is about three places where these models struggle and three places where they already help.
The running example: switching from IV to oral
To keep this concrete, I will use one example throughout: predicting when a patient can switch from IV to oral antibiotics.
I picked it because everyone in stewardship knows it. It is one of the most common interventions, the benefits are clear, and on paper the criteria are simple. That makes it look like the ideal job for a model. It is also one I build models for myself.
Here is what the task looks like from the model’s side. Every day a patient is on IV antibiotics, the model looks at what we know about that patient up to that point and answers one question: can this patient switch tomorrow? To learn that, we show it a lot of past treatment courses, with everything that was recorded along the way and the day the switch actually happened.
In the data, an antibiotic course for a hospitalized patients might look something like this: day one IV, day two IV, day three IV, then on day four the clinician switches to an oral antibiotic. It seems straightforward, but most of the problems I will discuss below come back to how a course like this ends up in the data.
One more thing before we start. IV to oral is just the example. Most of these points, if not all of them, translate to other stewardship decisions as well: de-escalation, stopping treatment, and probably most other decisions we would want a model to help with. Wherever a model learns from what we did in the past, you will run into the same things.
WHERE AI STRUGGLES
1. Nothing to learn from, so AI learns you
When I build a model like this, the first step is always defining what it should predict. In our running example, that is whether a patient can switch from IV to oral tomorrow. The model then learns from past courses where the answer is already known, and those known answers are what we call labels.
So where do the labels come from? From the data. In our example the oral antibiotic shows up on day four, so day three gets the label: that is the day the model should say “this patient can switch tomorrow”.
But here is the problem. Because you derive the labels from the data, the labels are generated by how clinicians treat patients. At best, a perfect model that perfectly mimics the labels will treat patients exactly the same way the clinicians did. But we know clinicians are not always perfect with their IV to oral switches. They might be late, there might be delays, and all of that puts the label later than the actual best switch day.
And when we train the model, we score whether the prediction matched the label. In our example, the model is right if it says “switch tomorrow” on day three. Saying it on day four or five is wrong, too late. But if the patient was actually ready a day earlier, and the model says so on day two, that counts as an error too, because the clinician only switched on day four. So the model can only ever learn to imitate the clinician, good habits and bad alike. A model that seems to perform really well might simply have learned all of our delays: the switch someone forgot, the one that waited for the next ward round, or the one that slipped to Monday because it was the weekend.
2. The chart is not the patient
For the IV-to-oral model, we have to ask: which features would an actual clinician look at to decide whether a patient can switch? Some of it is hard rules the model has to learn. How long has the patient been on IV, what do the guidelines say? And some indications may not be eligible for switch, like initial treatment for infective endocarditis, so the model has to learn that endocarditis patients maybe cannot switch even if everything else looks fine.
Then there is the vaguer requirement that the patient should be clinically stable. What features indicate that? CRP, temperature for fever, blood pressure, heart rate. These are relatively easy to extract, but you have to know where to look and how to combine them, and sometimes you have to turn them into a sense of clinical stability yourself before the model can use it.
But then there’s a whole category that rarely makes it into the structured data. This is what’s called tacit knowledge: things clinicians know and act on, but don’t usually write down. Whether the patient can actually take oral medication at all, or whether they’re fasting for a procedure tomorrow. Whether the team is still waiting for an abscess to be drained or an echo to rule out endocarditis. Or simply whether the patient looks well enough to the people at the bedside. These things are often not recorded in a structured way. Most of what we do record in a structured way is there for billing or handovers, and these factors do not always fit into those categories. Often they end up somewhere in a note instead, written differently by every clinician, which is much harder for a model to rely on. That’s slowly changing now that LLMs can read notes, but it’s not solved.
So when a clinician decides whether a patient can switch, they implicitly weigh everything they know about that patient: what they see at the bedside, what the nurses tell them, what was discussed on rounds. The model gets the fraction of that which made it into the record. This is worth remembering the first time a model flags a patient who obviously cannot switch, or misses one who obviously can. In my experience the explanation is rarely that the model is bad. It is that the reason was never written down anywhere it could find it. A better model doesn’t fix that. Better documentation would, but that’s a much harder project than training a model.
3. Decisions are not events
This ties back to the first point. You have to be aware that whenever an event happens, an IV-to-oral switch, a de-escalation, a stop, what you see in the data is when it was recorded, not when it happened. And there are really two gaps you have to keep separate.
The first is between when the patient was actually ready and when the decision was made. The patient might have been ready earlier, but if it wasn’t seen or wasn’t considered, the decision wasn’t made, so it was never carried out and never recorded. That’s the human delay, and it’s the same problem from the first point: the clinician can be late.
The second gap is a different one, between when the decision was made and when it landed in the data. What you actually see, precise to the hour and minute, is the moment the order was started or stopped. But that order followed a decision that was probably made earlier. On morning rounds the team decides to change treatment, it gets passed to a nurse, and only when the nurse carries it out does it get recorded. The decision itself was made hours before. In our example the oral antibiotic may actual materialize on day four, but the decision may well have been made on day three.
This is the part to keep in mind when you look at a model. A model should be trained to predict at the moment the decision was made, not when it was recorded, using only the information available up to that moment. So be critical about what information a model was given, and whether that matches what the clinician actually knew at the time. If a model was trained on information that only became available after the decision, it has seen things the clinician couldn’t have known. This is called leakage and it makes a model look much better on paper than it can reasonably be expected to perform in practice.
WHERE AI HELPS
1. AI finds the patients worth a look
The most useful thing an IV to PO switch model does is not deciding who switches, or when. It’s finding them. On any given day, a stewardship team cannot look at every patient on IV antibiotics, so the question is where to spend the limited time. That is a question a model can answer well, because it can look at all of them, every day, in a few seconds. It won’t have the full picture (the second struggle made clear what it misses), but it doesn’t need the full picture to tell you who deserves a closer look.
So what it produces is a shortlist. Every day, it points out the patients who on the surface look ready to switch, with the relevant history already gathered. Someone with the right clinical background then goes through the top of that list, however many is manageable that day, and adds what the model cannot see: the tacit knowledge from the second struggle. Can the patient actually take oral medication, is a procedure coming up, how do they look at the bedside. That’s where the clinical judgement goes, and that’s what makes the decision. The model narrows down who’s worth a look, and the person makes the call.
This is not a new way of working. Many hospitals already shortlist patients with simple rules, for example based on published IV-to-oral switch criteria, and someone checks the patients those rules flag. The model takes the place of the rules; the human step stays the same. Why that’s an improvement is the next point.
2. AI learns relations, not rules
Rules are a good place to start. They’re transparent, easy to implement, and everyone can see why a patient was flagged. But they oversimplify reality. Each criterion is checked on its own against a fixed threshold, like no fever for 24 hours or CRP below some cut-off, while a clinician looks at how things fit together. A CRP that is still high but dropping fast can mean something different in a patient who is otherwise recovering than in one who is not. One day of fever means something different on day two than on day six. Rules cannot express that, or only by adding more rules until nobody can maintain them.
A model does not need thresholds. It learns from thousands of past treatment courses how the features relate to each other and to the switch, including relations nobody ever wrote into a guideline because they are hard to put into words. This is the same property that caused the trouble in the first struggle: the model learns whatever pattern is in the data, our bad habits included. Here it works in our favour. The tacit knowledge is still missing, so the list isn’t a decision, but it’s a better list: patients ordered by how much they resemble the ones we actually switched, not by how many boxes they tick.
3. AI never forgets
These models do not get tired, and they always pay attention in the same consistent way. Unlike humans. And even though we do not fully understand how they work internally, they are consistent.
In a busy clinical workflow, some patients who could switch from IV to oral slip through the cracks. The clinician simply forgets, or never gets to it. A model running quietly in the background does not forget them: those patients keep coming up at the top of the shortlist from the first point, until someone takes a look.
And even if the predictions are not perfect, it still works. Say the model is a day late, either because it simply is not that accurate, or because, as in the first point, it learned from switches that were a day late themselves. For a patient who would otherwise have been missed entirely, that doesn’t really matter: a late switch still beats no switch at all. That is one of the biggest advantages of having a model like this run in the background.
Closing thoughts
AI is everywhere now, and the idea of using it in antimicrobial stewardship is an attractive one. But in my experience, the models are still held back by the data they learn from: labels that copy our own habits and delays, records that miss the tacit knowledge, and timestamps that show when something was recorded, not when it was decided.
That doesn’t make them useless. A model can take over the searching, with more nuance than a checklist, so we can spend our clinical knowledge on what only a human can evaluate anyway. In a busy workday, that is how AI can help close the gaps: not by replacing the clinician or the stewardship team, but by making sure the right patients end up in front of them.
EDITOR’S COMMENT
In this article, the author raises important concerns about the accuracy and reliability of medical record data available to AI models. I wholeheartedly agree that this represents a significant limitation that healthcare systems must recognize and address when developing clinically useful AI tools.
Having worked on numerous research projects involving chart reviews, I have repeatedly observed that what is documented in the medical record often paints a very different picture from what is actually happening with the patient. This disconnect underscores the critical importance of communication, clinical judgment, and the unique perspective of healthcare professionals who interact directly with patients. There is simply no substitute for evaluating a patient face-to-face, and we must recognize the limitations of relying on incomplete or inaccurate documentation to inform clinical decisions. AI can only interpret the information available to it, and that information does not always reflect the clinical reality.
ABOUT THE AUTHOR
PENDING
DISCLOSURES
The views and opinions expressed in this article are those of the author and do not necessarily reflect the position or policy of any former, current, or future employer. Artificial intelligence was used for refining original content and for copy editing.
RECOMMENDED TO YOU
