AI to support, not replace: a practical reading for learning design
The phrase is easy to say and hard to build. Here is what it actually means when you are the one deciding what a learner sees, and how I hold the line in real projects.
"AI to support, not replace" has become the standard line whenever a regulated sector talks about artificial intelligence. The Care Quality Commission uses a version of it in its own principles for AI in health and social care. Most organisations agree with it in the abstract. Fewer have worked out what it demands of the person actually building the training, which is where the principle either holds or quietly collapses.
I design learning for regulated and professional audiences, and AI now sits inside almost every project I run. It drafts scripts, proposes assessment items, restructures long documents, and speeds up localisation work that used to take weeks. None of that is the interesting part. The interesting part is what happens after the model produces something: who checks it, who is allowed to say no, and who is accountable if it is wrong. Get that part right and the principle is real. Get it wrong and "support, not replace" is just a slogan sitting on top of an unreviewed AI draft.
What the principle actually asks of a designer
In practice, "support, not replace" breaks down into four working commitments, and I treat all four as non-negotiable rather than aspirational.
- AI does the mechanical work. First drafts, pattern-matching, restructuring, translation passes, generating variations of a question stem. Work that is fast for a model and slow for a person.
- A qualified human makes the judgement calls. Is this accurate. Is this the right level for this audience. Is this safe to publish. Those are not tasks I hand to a model, because they are the actual job of instructional design, not a step around it.
- The review is real, not decorative. A review gate that exists on a workflow diagram but gets rubber-stamped in practice is worse than no gate, because it creates false confidence.
- Someone is accountable by name. Every module I ship has a person who signed off the content. Not "the system," not "the AI," a person.
The test I use: if I removed the human step entirely, would anything catch a wrong answer, a tone-deaf scenario, or an inaccessible interaction before a learner saw it? If the honest answer is no, the gate is not doing its job.
Human-in-the-loop is a specific set of gates, not a mood
"Human-in-the-loop" gets used loosely, so I try to be specific about where the loop actually closes. On a typical AI-assisted build, there are three gates I never skip.
- Content accuracy gate. Anything AI drafts about a clinical process, a regulatory requirement, or a procurement rule gets checked against the source policy or by someone who does that job for a living, before it goes anywhere near a storyboard.
- Assessment gate. AI-generated questions and scenarios are reviewed by a subject-matter expert for correctness and for whether the "right" answer actually reflects real practice, not just plausible-sounding text. Skills for Health makes the same point directly: AI can speed up production, but it does not replace the expertise needed to validate what learners are actually being tested on.
- Publication gate. A final sign-off by a named designer or SME before anything goes live, distinct from the earlier checks, because a module can pass every individual review and still be wrong as a whole.
None of this is exotic. It is closer to the editorial discipline any serious publisher already applies. AI just increases the volume of drafts arriving at the gate, which makes the gate matter more, not less.
Where this is not theoretical: the CIPS localisation pipeline
The clearest example I can point to is the SCORM localisation pipeline I run at the Chartered Institute of Procurement and Supply, where I design learning for a professional body serving more than 90,000 procurement professionals worldwide. Localising SCORM modules across languages used to be a slow, manual process. AI now does the heavy lifting on the mechanical parts of that work: draft translation, terminology consistency checks, restructuring content to fit different text lengths.
What does not change is the review step. A designer signs off every localised module before it is published, checking that meaning has survived translation, that terminology matches how the profession actually talks in that market, and that nothing has drifted from the source content in a way that would confuse or mislead a learner. The AI made the pipeline faster. It did not make the sign-off optional. That distinction is the whole principle, applied to a real, ongoing piece of work rather than a slide.
Where this is not theoretical: AI Fundamentals for Imaging and Oncology
The same discipline shaped a Rise 360 module I built called AI Fundamentals for Imaging and Oncology, which is live and playable in my portfolio. It teaches clinical and technical staff what AI tools in imaging and oncology can and cannot do, and just as importantly, where a clinician's judgement has to remain the deciding factor regardless of what a model recommends.
Designing that module about AI while also using AI to help build it meant I could not treat the subject as abstract. Every scenario in the module makes the same point I was applying to my own workflow: AI narrows the options and surfaces a recommendation, a qualified person makes the call. The NHS AI and Digital Regulations Service draws a similar distinction between the organisation that develops an AI tool and the one that adopts and uses it, and either way, the clinician using the output stays responsible for the decision it informs. Writing that into a module made it obvious that the principle is not a caveat you add to AI content. It is the actual subject matter.
Transparency and choice are part of the design, not an afterthought
The CQC's principles do not stop at oversight. They also call for transparency about where AI is used, and for non-digital routes to remain available for people who need or prefer them. I apply the same thinking to learning design. If a module uses an AI-driven element, such as an adaptive path or a generated practice scenario, learners should be able to tell, and there should be a way to raise a concern about it. A learner should never have to guess whether they are getting a human-reviewed answer or a raw model output, and an organisation should never be in the position of having no non-digital fallback if the digital route fails someone.
This matters more, not less, in a sector where the L&D community itself is still working out how far to lean on AI. The Global Sentiment Survey 2026 has AI as the single most talked-about topic in learning and development again this year, but it also shows interest has passed its peak and practitioners are becoming more selective about where they actually use it. That is a healthy sign. It means the field is moving from "use AI everywhere" towards "use AI where it earns its place and prove the review holds," which is the same standard I hold my own projects to.
Accessibility is part of doing this responsibly, not a separate project
None of the above works if the output only reaches some of the audience. Every module I build, AI-assisted or not, is designed to WCAG 2.2 AA. In the UK, that standard is not a best-practice suggestion for public sector bodies, it is the legal baseline, and the government's own guidance is explicit that the requirement extends to intranets and extranets, which is exactly where compliance and professional training tends to live.
AI tools can help here too, drafting alt text, checking colour contrast, generating a first-pass transcript. But the same rule applies as everywhere else: a human confirms the alt text actually describes the image correctly, that the contrast holds up in the real interface, and that the transcript reads as sense rather than plausible noise. Accessibility reviewed by a person is part of what "support, not replace" means in practice. Accessibility rubber-stamped by a tool is the opposite of it.
A working checklist
Before I let an AI-assisted module go live, I ask the same questions every time.
- Can I name the person who reviewed the AI-drafted content for accuracy?
- Has a subject-matter expert checked every AI-generated assessment item against real practice, not just plausibility?
- Would a learner know if part of this experience was AI-generated, and is there a way to flag a concern?
- Is there a non-digital or human-supported route for anyone who needs one?
- Does this meet WCAG 2.2 AA, checked by a person rather than assumed from a tool's output?
- If I removed the AI entirely, would the human review process still function on its own?
If the answer to all six is yes, the module reflects the principle rather than just quoting it.
The short version: AI can draft, translate, and suggest, but a qualified person decides what is accurate, appropriate and accessible before a learner ever sees it. That discipline is what makes AI-enhanced learning trustworthy rather than merely fast. Learning that changes behaviour, not just tick boxes.
Frequently asked questions
What does "AI to support, not replace" mean in learning design?
It means AI is used to do the mechanical, repetitive work of building learning, such as drafting scripts, generating first-pass questions, or localising content, while a qualified human stays accountable for what actually goes live. The person, not the model, decides whether the content is accurate, appropriate and safe to publish.
What are the CQC's principles for using AI in care?
The Care Quality Commission has set out principles for the safe and effective use of AI in health and social care, including that AI should support rather than replace professional judgement, that there must be meaningful human oversight, that use of AI should be transparent to the people affected by it, and that non-digital routes must remain available for those who need or prefer them.
Do AI-generated assessments need subject-matter-expert review?
Yes. Guidance from bodies such as Skills for Health is clear that AI can accelerate the production of training and assessment content, but it does not replace the expertise of a subject-matter expert. Every AI-drafted question or scenario needs a qualified reviewer to check it for accuracy, currency and fitness for purpose before it reaches a learner.
Is WCAG 2.2 AA a legal requirement in the UK?
For public sector bodies, yes. UK accessibility regulations set WCAG 2.2 AA as the legal standard for websites and apps, and this extends to intranets and extranets, which is where much workplace and compliance training lives. Designing to that standard from the outset is the safest and most defensible approach for any organisation building training at scale.
I'm Mags Jacobs, an Instructional Designer and Learning Experience Designer. I build accessible, AI-enhanced learning for regulated and professional teams. See how I work.