Blog
AI in medical education Dr. Alastair Dunne

What "AI in medical education" actually means: a taxonomy for educators

"AI in medical education" is not one thing. Here is a working taxonomy: five tool types, three architectures, and how to tell them apart.

A shelf of medications; packages that look alike but are not interchangeable.
They look alike on the shelf, but they are not interchangeable; what a tool can be trusted to do follows from what is inside it.

"AI in medical education" is an umbrella term for five broad types of tool that students and schools now use, each running on one of three underlying architectures: a raw model, retrieval-augmented generation, or a knowledge graph. The tools are not interchangeable, and treating them as one category gets all of them wrong.

Nearly every student is already using them: a 2026 UK survey found that 95% use AI in some way and 94% use it for assessed work (HEPI / Kortext, 2026). So the question worth an educator's time is not whether to allow AI. It is which tool, for which job, and on what architecture. This post is the map. If you have followed the rest of this series you already know why what runs underneath a tool matters more than the name on the front of it; what follows is the whole landscape in one place, and the shared vocabulary medical educators have begun to ask for (Masters and colleagues, AMEE Guide No. 178, 2025).

The five types

Five broad types are in use today. Set the branding aside and they separate cleanly by three things: what the tool actually is, the job it does, and who it was built for.

TypeWhat it isWho it's really built forArchitecture
Consumer AI tools students bringGeneral chatbots students sign up for themselves (e.g. ChatGPT, Gemini), usually free tiersGeneral consumersRaw model
Medical-skinned chatbotsA general model behind a medical interface or avatarBroad medical-adjacent usersRaw model
Source-constrained toolsA model limited to an approved document setUsers needing answers tied to a source setRAG
Clinical tools students borrowTools built for practising clinicians, used by students (e.g. OpenEvidence, UpToDate)Practising cliniciansRAG / varies
Structured-knowledge learning toolsTools built around a structured medical knowledge graphMedical learners specificallyKnowledge graph

The first two are the same engine in different clothes. Consumer tools students bring themselves, ChatGPT or Gemini on a free tier, are built to answer anything for anyone, which makes them handy for a quick explanation and unreliable for stage-appropriate study. The school never chose the tool, so it has no say in what a student pours into it, from patient details met on placement to the university's own teaching material. A medical-skinned chatbot is that same general model behind a clinical interface or an avatar. The costume is bespoke; the engine is not, so it carries every strength and every failure of the consumer tool, now dressed to look purpose-built (Information, 2025).

The next two are defined by who they were built to serve. Source-constrained tools hold a model to an approved set of documents, so answers come from a controlled library rather than open generation. It is a genuine step up in control, and its ceiling is its strength: it can point to the document behind an answer, but it still cannot show how medicine fits together. Clinical tools students borrow, OpenEvidence and UpToDate, are built for practising doctors and used by students anyway. They can be superb at their real job and still be the wrong thing in a learner's hands, because they answer at the level of a working clinician instead of building a student's own understanding, a distinction we have drawn in full before.

The fifth is the only one built for the job in question. Structured-knowledge learning tools are organised around a student at a particular stage, drawing on a curated body of real medical knowledge rather than retrieving or generating on demand. It is the hardest type to build and the only one designed for learning from the start, where clinical feedback is guided by structured medical knowledge rather than free generation. It is the category we built Gestalt around.

The three architectures underneath

Strip away the interface and each of these tools runs on one of three things. This is where the real differences live, because the architecture, not the label, decides how far you can trust a tool for someone who is still learning.

raw model generates fluent text from everything it once absorbed, with no fixed source and no sense of where a given learner is. Its signature failure is not only that it invents things but that it caves: a 2025 study found state-of-the-art models went along with plainly illogical medical requests up to 100% of the time, choosing to be helpful over being right (npj Digital Medicine, 2025). It also leans toward the common answer and quietly irons out the rarer presentations a doctor has to catch. Fluent, confident and unaccountable is a poor thing to learn from.

The usual response is retrieval-augmented generation, or RAG: hold the model to a defined library and let it answer from that set rather than from everything it has seen. It steadies the output and cuts hallucination, which is why so many tools now use it, but a 2025 review found its use in healthcare still fragmented and, tellingly, that it does not remove the problem (AI, 2025). RAG is a floor, not a destination. It can fetch the right page; it cannot, on its own, hold the web of relationships that medicine actually is.

knowledge graph is built to hold exactly that web: a structured map of how the parts of medicine connect, kept at the depth a given learner needs and traceable to its sources. It is the direction trustworthy AI is widely agreed to be heading, away from retrieval bolted onto a general model and toward real structure underneath. The teaching evidence is still young but points the same way: a 2026 randomised trial found students taught with an interactive, multi-guideline knowledge graph reached higher diagnostic accuracy than a lecture group, 89.2% against 72.5%, though the two groups were taught differently as well (BMC Medical Education, 2026). We set out our own approach in full elsewhere.

How the architecture shows up in each tool

Put the two halves together and a simple pattern appears: what a tool is good for, and what it can never do for a learner, follows from its architecture and the job it was built for. A medical-skinned chatbot is still a raw model, so it earns no more trust than the free tool underneath it. A borrowed clinician tool sits on solid retrieval, which is exactly why it shines at the point of care and fails a second-year who needs to be met at their level. A structured-knowledge tool can be held to a learner's stage because knowledge, not phrasing, is what it runs on. The interface is the easiest thing to change, and it tells you the least of all.

How to tell what you're looking at

You are rarely told which architecture you are dealing with, but a handful of questions give it away, and they are the same ones worth putting to any vendor.

Question to askIf it's a raw modelIf it's RAGIf it's a knowledge graph
Where does the knowledge come from?Everything the model absorbedAn approved document setA structured body of curated medical knowledge
Can a clinician verify a given answer?NoBack to the source documentYes, to the structured source
Can it be targeted to a learner's stage?NoPossible, but not by defaultYes, by design
What happens when it doesn't know?It may fabricate or simply agree with youIt may miss or misretrieveIt can stay within what it holds

Once you can place a tool, you can judge what to trust it with. What to do next, the policy and the procurement, is the work of our companion piece on governance.

What this means for educators

"AI in medical education" is not one thing, and treating it as one is how good intentions go wrong. Five types, three architectures: once you can see which is which, an unmanageable question becomes a simple one. Instead of asking whether to allow AI, you ask of anything put in front of you what it is for, who it was built for, and what runs underneath it.

For medical education, the tools worth building on are the ones designed for learning from the start, where the knowledge is structured, can be aimed at a learner's stage, and where clinical feedback is guided by structured medical knowledge rather than free generation. The rest each have their place. Knowing which is which is where the real decisions begin.