A doctor should explain the task the AI performs, the information it uses, its important limitations and who checks or acts on its output. The explanation should also make the available alternative clear. Reassurance is useful only when it is specific, accurate and supported by the actual service arrangements.
Describe the task before describing the technology
"We use artificial intelligence" tells a patient less than "this system prepares a draft note from our conversation". The first names a broad technology; the second identifies the activity that may affect the encounter.
The GMC's guidance on innovative technologies, checked on 10 October 2026, says clinicians should discuss relevant options, uncertainties and limitations with patients. It also distinguishes clinicians' decisions from the responsibilities of people who develop and maintain technology. An explanation should therefore avoid implying that either the doctor or the software company is responsible for absolutely everything.
Begin with the patient's practical question: what is happening to my care? Technical detail can follow when relevant, but a description of a language model is not a substitute for explaining whether the system is recording, recommending, sending or deciding.
A proposed script for an AI scribe
Where it accurately reflects the approved workflow, a clinician could say: "This tool records our conversation to prepare a draft note. I check the note before it is used. It can make mistakes, and we can continue without it or stop it during the appointment. Our information notice explains how the recording and draft are handled."
This is original suggested wording, not an official script or a guarantee about a particular product. The clinician should not use it when the system's actual behaviour differs. For example, a workflow that sends generated material elsewhere before review needs a different explanation and a separate safety assessment.
Avoid adding "nothing is stored" because a supplier says it does not train on patient data. Avoid saying "only I can see it" without checking access arrangements. A confident statement about security may be less useful than a precise explanation of who processes the data, for what purpose and under which controls.
NHS England's scribing guidance, checked on 10 October 2026, requires patients to be informed and dissent to be respected in the individual-care setting it describes. The conversation should occur while a choice can still change what happens, not after recording is complete.
A proposed script for a clinical-reference search
A reference search is a different activity. A clinician might say: "I am checking the current guidance for this question. The tool summarises sources, but I will look at the relevant guidance and decide how it applies to your circumstances. I do not need to include your identifying details in this general question."
The final sentence should be used only when true. A general evidence question and a patient-specific record-processing workflow have different data requirements. The clinician should not describe an identifiable upload as anonymous simply because the patient's name was removed.
As described in iatroX's product information for October 2026, Ask-iatroX is a free clinician-facing reference tool with linked sources. That does not make every generated sentence correct. This Journal is published by iatroX, and the same explanation standard applies to its tools as to any other reference service.
The patient does not need a catalogue of model names. They need to understand that checking a source can support the consultation without transferring the clinical decision to the search interface.
A proposed script for patient-facing triage
A triage service needs an explanation of what it can change. Suggested wording for a hypothetical clinician-reviewed service is: "This form helps the team understand your request and decide how to respond. It is not a completed diagnosis. The information is reviewed through our clinical pathway, and this is how you can contact us when the form does not fit your problem."
Do not use that script for a system making different decisions or operating without the stated review. Also avoid promising an immediate response unless that response is genuinely provided. A message being received is not the same as a clinician assessing it.
The HSSIB investigation into digital tools for online consultation, reviewed on 10 October 2026, examined safety issues around implementation and patient access. It concerned online consultation systems, not a verdict on every generative-AI product. Its relevance is that explanations must match the whole service pathway, including what happens after submission.
Replace absolute reassurance with inspectable commitments
Several common statements deserve rewriting. "It is completely safe" can become "we have assessed this use and have a process for checking and correcting the output". "The AI understands everything" can become "it may miss or misunderstand information, so please correct anything that does not reflect what you said".
Similarly, "the doctor is always in the loop" should be made specific. Does the doctor approve the output before it is used, review selected cases afterwards, or become available only when someone asks? Those are different arrangements, and a broad phrase should not conceal the distinction.
These revised statements remain claims. They should be used only when the assessment, checking and correction arrangements exist. A more cautious tone does not rescue an inaccurate description of the service.
Check understanding without turning the encounter into a test
After an explanation, a useful invitation is: "What would you like to know about how it is being used?" In a more complex workflow, the clinician could ask the patient to describe what they expect to happen next, making clear that the purpose is to check the explanation rather than assess the patient.
The GMC's decision-making and consent guidance, checked on 10 October 2026, treats decision-making as a dialogue rather than a signature alone. For AI, an editorial application is to revisit the explanation when the task changes or the patient's understanding appears different from the actual workflow.
A person may be content with note preparation but concerned about automated messages. That is not inconsistency; it may reflect a meaningful difference in the action being delegated.
Keep the explanation proportionate and available afterwards
Not every consultation needs a long technical briefing. A short, accurate account supported by accessible written information is often a more practical starting point. The written material should contain the details that cannot reasonably be explained during the opening exchange, including contacts for questions and correction requests.
The organisation should support clinicians with task-specific wording, not a single promotional paragraph for every product. It should also tell staff what remains unknown so that they can say, "I need to check that detail," rather than improvise a reassuring answer.
The best explanation leaves the patient knowing what the system does and what it does not establish. It neither frightens them with every theoretical failure nor asks them to accept confidence as evidence.
Frequently asked questions
Should a doctor say that healthcare AI is completely safe?
No. The explanation should identify the relevant safeguards and limitations without promising infallibility or absolute security.
Is the same explanation suitable for a scribe and a triage tool?
No. Recording a conversation, summarising evidence and influencing access to care involve different tasks, data and consequences.
What should a clinician do when they do not know a data-handling detail?
Check the approved organisational information or ask the relevant team. Do not substitute a general claim about AI for the actual processing arrangements.
Explore a general clinical question and inspect its supporting sources →