Moodle's Built-In AI vs an LTI AI Tool: Which Do You Need?

Every Moodle administrator who has switched on the AI subsystem eventually gets the same email from a head of department: we've got AI now, why are we also being asked to pay for an AI tool? It is a fair question, asked badly, and the honest answer disappoints both sides — the two things barely compete.

We build one of the LTI tools, so read this with the appropriate scepticism. The specific way to check us is to notice how much of the piece argues for switching on Moodle's own AI first, and to see whether the limitations we describe on our side of the line are ones you would have found yourself.

The answer, first

• If what you need is authoring assistance — rewrite this, summarise that, explain this dense paragraph to a struggling learner — Moodle's built-in AI is the answer, and it is free of licence cost. Switch it on before you evaluate anything else.
• If what you need is assessment work — question banks, rubric-based marking, grades reaching the gradebook, a tutor scoped to your lessons — built-in AI does not do it and is not going to. That is an LTI tool, or a plugin.
• If you need both, run both. They do not conflict, they cost different things, and the combination is what most institutions land on after a year.

What Moodle's built-in AI actually is

Moodle 4.5 introduced an AI subsystem in core, and it has been extended in every release since. It is a three-layer design: an administrator configures one or more providers, enables placements — the surfaces where AI appears — and chooses which actions each placement offers. Everything is off until somebody turns it on.

It is worth stating the surface area precisely, because vagueness here is what causes the disappointed email. Core ships two placements: the HTML text editor, and course assistance. Core ships four actions: generate text and generate image in the editor, summarise text and explain text on course content — the last of these added in Moodle 5.0. That is the whole of it.

Around that surface, the subsystem is more grown-up than its size suggests:

• Providers are your own account. OpenAI and Azure AI shipped at 4.5; Ollama for self-hosted models arrived in 5.0, DeepSeek in 5.1, and Gemini and Amazon Bedrock in 5.2. You supply the API key and pay the provider directly — Moodle operates no AI service of its own.
• Consent is built in. The first time a user tries any AI action in any placement, they must accept an AI usage policy before proceeding.
• Reporting exists. Moodle 5.0 added an AI usage report — how and when each provider was used, with tokens, context and users — and an AI policy acceptance report. Both are manager-only.
• Control has moved closer to teachers. Moodle 5.1 added AI access controls at course and activity level, so it is no longer purely a site-wide permissions exercise.

The self-hosted option deserves emphasis because no LTI tool can match it. Point the Ollama provider at a model running on your own infrastructure and the AI call never leaves your network. If your data-protection position is that student text must not reach a third party at all, this is the only route on the table, and it is a genuinely good reason to choose built-in AI over everything else.

What an LTI AI tool actually is

An LTI 1.3 tool is an external application registered once by your administrator under External tool, which then behaves like a native activity in every course. Moodle has supported LTI 1.3 since 3.7 and dynamic registration since 3.10, so this is old, boring, well-trodden plumbing rather than anything experimental.

Three LTI Advantage services do the actual work. Deep Linking lets the tool hand a specific item back into the course. Names and Role Provisioning tells the tool who the learner is and what role they hold, so there is no second user list. Assignment and Grade Services writes grades into the Moodle gradebook. For anything involving marking, that third one is the entire point.

Because the tool runs on the vendor's infrastructure, it can carry workflows that would be unreasonable to install on your own server. In EduGears AI's case that is 26 tools inside one registration: question generation across nine question types with QTI export, quizzes with grade passback and availability windows, rubric-based marking, capstone and project work, course import from SCORM, Common Cartridge and Moodle backups, slides, study guides, worksheets, a lesson planner, and Cog, one assistant on every page that already knows the lesson you have open.

And because the integration is a standard rather than a Moodle add-on, the same tool behaves the same way in Canvas, Blackboard and Brightspace. Built-in AI is Moodle-only by construction — it is implemented as Moodle plugin types, rendered by Moodle's UI, gated by Moodle capabilities. Nothing about it travels.

The cost is the one you already guessed: student submissions and generated content pass through a third party. That is answered with contracts and configuration rather than reassurance — a data processing addendum, a retention window you set, an explicit commitment that submissions are not used to train models, and bring-your-own-key so inference runs on your institution's own provider account.

The comparison table

Where they genuinely overlap

Two rows in that table are real overlap, and it is worth being straight about them rather than pretending the tools are perfectly complementary.

Authoring assistance. Both will help a teacher write a paragraph. Built-in AI does it where the teacher already is — inside the editor, no context switch, no extra activity. An LTI tool usually does it with more structure, producing a whole lesson page or slide deck rather than a paragraph, and grounded in course materials you uploaded. If all you need is the paragraph, built-in AI wins on friction and you should not pay anyone for the difference.

Learner-facing explanation. Both will explain a piece of content to a confused learner. Moodle's course assistance placement summarises and explains the text on the page, generically. A tutor inside an LTI tool is typically scoped — it answers from the lesson and the institution's own materials, keeps a thread per context, and refuses to hand over the answer to a graded item. If your worry is learners using AI to skip the thinking, that scoping is the difference that matters; if it isn't, the core placement is free.

"Both" is a valid answer — and usually the right one

The framing of "which one" quietly assumes they are substitutes, and they are not. The shape most institutions settle into looks like this: built-in AI switched on with an institutional provider key for editor assistance, and one LTI tool registered for assessment and content workflows. Nothing competes, because nothing overlaps in the places that cost money.

The one thing worth being deliberate about is telling staff which is which. Two AI buttons in one Moodle with no explanation produces support tickets rather than adoption. A single paragraph in your staff guidance — "the AI button in the editor drafts text; the EduGears AI activity builds and marks assessments" — prevents most of it.

When built-in AI alone is enough

• Your teachers want editor-level help and nothing more — and it is worth asking them rather than assuming, because a surprising number genuinely do.
• Nothing may leave your infrastructure. With a self-hosted provider this is the only option, and no vendor contract is a substitute for the call never being made.
• You have an institutional model contract already and want every call on that one key, with the usage report to prove it.
• You are early in an AI policy conversation and want the governance artefacts — policy acceptance records, usage reports, per-capability control — before you widen the surface.
• Your assessment volume genuinely does not hurt. If marking is not a pain point, do not buy a marking tool.

When you need the LTI tool

• Marking is the bottleneck. This is the single most common trigger, and built-in AI does not address it at all.
• You need question banks at volume with an export your LMS accepts, rather than questions written by hand one at a time.
• You want a learner-facing tutor that is safe during assessment — grounded in your material, and unwilling to hand out answers to graded items.
• Your Moodle is on hosting that will not let you install plugins, which closes the plugin route entirely and leaves this one.
• You run more than one LMS, or are midway through a migration, and would rather not do this exercise twice.
• You need content in and out — importing an existing SCORM package or Moodle backup, and exporting again — rather than starting from an empty course.

What a Moodle Certified Integration does and doesn't tell you

If you are evaluating LTI tools for Moodle you will see the Certified Integration badge, ours included, so it is worth knowing exactly what it is evidence of.

EduGears AI is a Moodle Certified Integration: our features and our standards-compliant LTI 1.3 integration were reviewed and verified by Moodle, and the listing is on Moodle's own site rather than only on ours. Moodle's published criteria for the programme are user experience, coding standards, and compatibility across operating systems, devices and Moodle versions.

Now the part vendors skip. A security audit is not among those criteria. The programme does not describe penetration testing, vulnerability scanning, or a compliance framework such as SOC 2, and you should not read the badge as any of those. Moodle also notes that for some integrations there is code to review and for others there is not — which for an LTI-based tool generally means the coding-standards criterion has nothing to bite on.

So treat certification as what it is: useful, external, and narrow. It tells your procurement team that a third party checked the integration works as described and behaves properly inside Moodle. It tells them nothing about how the vendor handles data, and that question needs its own answer — a DPA, a retention policy, a training commitment. Ask for those separately, of us and of everyone else.

How to decide in an afternoon

1. Switch on Moodle's built-in AI first. It is already in your Moodle, it costs a provider key, and it establishes your baseline. Anything you buy afterwards should be justified against it, not against nothing.
2. Ask five teachers what they actually want. Sort their answers into "help me write" and "help me assess". The ratio decides your budget conversation.
3. Settle the data question before shortlisting. Must inference stay on your infrastructure? If yes, you are choosing built-in AI with a self-hosted provider and the rest is moot.
4. If marking is on the list, find the approval step in every candidate. Whose rubric, and does a human see the score before the learner? Vague answers are answers.
5. Pilot in one real course for one term, with one teacher who will tell you the truth. Every comparison table, this one included, loses to a term of use.

Frequently asked questions

Related reading: how to add AI to Moodle, all three paths covers the plugin route this piece skips, and can Moodle grade essays with AI takes the marking question on its own.