AI in Moodle comes in two layers. First is Moodle's built-in AI subsystem (from Moodle 4.5, expanded in every release since, up to 5.3 LTS on 5 October 2026), which connects providers like OpenAI, Azure OpenAI, Ollama, DeepSeek, Google Gemini, Amazon Bedrock and Anthropic Claude to placements such as the course assistant and the text editor, enabling actions like generate text, generate image, summarise and explain. Second is a growing set of third-party plugins — AI Chat, OpenAI Chat Block, Exabis AI Chat, provider plugins, and several question-generators like qbank_genai and local_aiquestions — that add chatbots, tutoring and automated assessment authoring. The catch is that assembling and governing them yourself means juggling API keys, dependencies, cost and privacy. edzlms ships AI already integrated on managed Moodle, and adds Gelato AI roleplay and a SCORM AI study layer on top.
Key takeaways
- Moodle now has a native AI subsystem — you no longer need a plugin just to add basic AI text/image generation or summarise/explain tools.
- The native subsystem is built on three concepts: providers (the AI service), placements (where AI appears in the UI), and actions (what it does).
- Third-party plugins still matter for chatbots, tutoring, question generation and extra infrastructure. Core still has no AI question generation, no conversational practice and no AI over SCORM content.
- Watch the dependencies: some chat and question plugins require the AI Manager (local_ai_manager) infrastructure plugin, while others run on the native subsystem alone.
- Privacy, cost control and version maintenance are the real challenges of a DIY AI-plugin stack, especially for compliance-sensitive Indian organisations.
- edzlms delivers AI-ready managed Moodle with Gelato roleplay and a SCORM AI study layer, so you get the capability without assembling and maintaining it yourself.
Two layers of AI in Moodle: native + plugins
If you searched for ‘AI plugins for Moodle’ expecting a simple list, here's the important nuance for 2026: a lot of what people used to install plugins for is now built into Moodle core. Since Moodle 4.5, and considerably expanded in 5.0 and 5.1, Moodle ships a native AI subsystem. On top of that core, a healthy ecosystem of third-party plugins adds chatbots, tutoring, question generation, extra AI providers and reporting.
Understanding the split saves you money and rework. You don't want to pay for a plugin that duplicates something core already does, and you don't want to assume core covers a use case (like a course-aware student chatbot) that still needs a plugin. This guide walks through both layers in detail — with direct links to each plugin in the Moodle plugins directory — then the practical questions (privacy, cost and maintenance) that decide whether you assemble this yourself or run it on a managed platform.
New to Moodle plugins generally? Start with our wider roundup of the best Moodle plugins for e-learning, then come back here for the AI-specific layer.
Layer 1: how Moodle's native AI subsystem actually works
Moodle's built-in AI is structured around three ideas — get these and the whole system clicks into place. The official reference lives in the Moodle AI tools documentation.
| Concept | What it is | Examples |
|---|---|---|
| Provider | The external or local AI service Moodle talks to, using your API key | OpenAI, Azure OpenAI, Ollama (local), DeepSeek, Google Gemini |
| Placement | Where and how AI appears in the Moodle interface | Course assistant, text-editor (TinyMCE) tools |
| Action | What the AI actually does when invoked | Generate text, generate image, summarise text, explain text |
A worked example: what happens when a learner clicks ‘Summarise’
Say a learner is reading a dense compliance page and clicks the Summarise button. Moodle's placement (the course assistant) captures the request and the page text, hands the action (summarise) to whichever provider you configured (say OpenAI), receives the response, and renders it back in the Moodle UI — all governed by the permissions and quotas you set. Swap OpenAI for Ollama and nothing changes for the learner, but the data now stays on your own server. That separation of provider, placement and action is the whole point: you change the engine without changing the experience.
Why this matters
Before the subsystem, every AI feature was a separate plugin with its own API key and its own idea of how AI should look. Now there's one consistent framework: configure a provider once, and every placement can use it. It also gives admins a single place to control cost, access and privacy rather than chasing settings across a dozen plugins.
Choosing an AI provider: cloud vs local, cost vs privacy
The provider is the most consequential choice you'll make, because it decides where your prompts go and what you pay. Core supports several out of the box, and provider plugins add more. Here's how they compare for a typical Moodle deployment (see the Moodle AI providers docs for setup):
| Provider | Hosting | Best for | Plugin / status |
|---|---|---|---|
| OpenAI | Cloud (OpenAI) | Strong general quality, easy start | Core |
| Azure OpenAI | Cloud (your Azure tenant) | Enterprises wanting Azure governance | Core |
| Ollama | Local / self-hosted | Privacy & data residency (prompts never leave your server) | Core from 5.0 |
| DeepSeek | Cloud | Cost-conscious deployments | Core from 5.1 |
| Google Gemini | Cloud (Google) | Text, image & summarise via Gemini models | Core from 5.2 (was the aiprovider_gemini plugin) |
| Amazon Bedrock | Cloud (your AWS account) | Teams already on AWS | Core from 5.2 |
| Anthropic Claude | Cloud (Anthropic) | Text and summarise (no image generation) | Core from 5.3 |
| Any OpenAI-compatible | Cloud or self-hosted | Alternative/self-hosted models that speak the OpenAI API | aiprovider_openaicompatible |
The privacy short version: if learner data is sensitive or you have data-residency obligations (common in Indian BFSI, healthcare and government), lean toward Ollama for local processing or an OpenAI-compatible endpoint you host yourself. If quality and speed of setup matter most and data sensitivity is low, a managed cloud provider is the quickest path.
Placements: where AI shows up for teachers and learners
Placements decide which actions appear where. The two you'll meet first:
- Course assistance — puts Summarise (since 4.5) and Explain (since 5.0) beside the main text of a course page, so learners can unpack dense material without leaving it.
- Text editor placement — adds Generate text and Generate image inside the editor for teachers drafting content.
Third parties extend placements too — for example the Exabis AI Chat course-assistant placement adds a course-aware assistant as its own placement.
What changed from Moodle 5.0 to 5.3
5.0 added the Explain action, the Ollama provider for local models, multiple instances of the same provider, and the AI usage report and policy-acceptance report. 5.1 added DeepSeek and the governance layer institutions asked for: AI access controls at course and activity level, so a teacher can enable AI for one activity and switch it off for a graded exam next door. 5.2 brought Google Gemini and Amazon Bedrock into core. 5.3 LTS (released 5 October 2026, security support to October 2029) adds an Anthropic Claude provider and AI user reporting. For the bigger release picture, see our summary of Moodle's AI integration release.
What core Moodle AI still doesn't do (as of 5.3 LTS)
The native subsystem is a solid base, and it is deliberately narrow. Based on the Moodle 5.3 placement docs and the release notes from 4.5 to 5.3, core gives you four actions (generate text, generate image, summarise, explain) in two places (the text editor and course assistance). Here is what is not in core:
- No AI question or quiz generation. No core placement works in the quiz or question bank. That is why plugins like local_aiquestions and qbank_questiongen exist.
- No conversational practice. There is no chat, roleplay or practice simulation, and nothing scores a conversation against a rubric.
- No AI over SCORM content. Course assistance reads the main text of a Moodle page. It cannot see inside a SCORM package, which is where most corporate training content lives.
- No AI proctoring. The 5.3 quiz changes are Safe Exam Browser options, not AI.
Where edzlms fits
edzlms runs on the same Moodle core and uses the native subsystem as it is. It adds the three things above that core leaves out, inside the same LMS and on infrastructure you control:
- Gelato AI: roleplay practice for sales, service and compliance conversations, scored against criteria you write.
- SCORM AI study layer: summaries, glossary, flashcards, quizzes and ask-AI over the SCORM packages you already own.
- edzproctor: AI-assisted proctoring built into Moodle quizzes, running on your own server, with no per-exam fee.
Layer 2a: AI chat & tutoring blocks
Core covers generation and summarise/explain. For conversational tutoring you turn to the plugins directory. These three are the ones worth knowing in 2026 — the right choice depends mainly on whether you want a lightweight block or a fully-featured, multi-model chatbot, and whether you're willing to run the AI Manager dependency.
| Plugin | What it does | Dependency | Choose it when |
|---|---|---|---|
| AI Chat (block_ai_chat) | Full-featured chatbot with history and docked / modal / full-screen modes; works with GPT-4o, Gemini, Llama 3 | Requires AI Manager | You want the richest chat UX and multi-tenant model management |
| OpenAI Chat Block (block_openai_chat) | Lightweight chatbot with customisable AI persona, built on the native AI subsystem | None (uses core AI) | You want a simple 24/7 chat block without extra infrastructure |
| Exabis AI Chat (block_exaaichat) | Course-aware chat, configurable per course or target group, with dynamic placeholders (name, date, gradebook) | Works with OpenAI, Ollama, Gemini & OpenAI-compatible | You want personalised, privacy-first chat that doesn't store student data outside Moodle |
Want a conversational tutor specifically? We go deeper on that use case in our guide to the AI coach for Moodle.
Layer 2b: AI question & content generation
One of the highest-ROI uses of AI in Moodle is turning your existing material into assessment items in minutes instead of hours. Several mature plugins do this, and they differ in where the source content comes from and whether they need the AI Manager. In every case, treat the output as a first draft a human must review before it reaches learners.
| Plugin | How it generates | Question types | Notes |
|---|---|---|---|
| Generative AI Question Bank (qbank_genai) | From a course's own files/content | Multiple choice & essay | Adds items straight to the course question bank for editing |
| AI Text to questions (local_aiquestions) | From text you paste, via the course menu | Multiple choice | Needs an OpenAI API key |
| AI questions generator (qbank_questiongen) | From supplied text via an LLM | Configurable | Requires AI Manager |
| OpenAI Question Generator (block_openai_questions) | From a paragraph you submit | True/False, Short Answer, MCQ | Uses your paid OpenAI account |
How to pick: if you want to generate from material already inside a course, qbank_genai is the natural fit; if you're pasting ad-hoc text, local_aiquestions or the OpenAI question block are simplest; if you've standardised on the AI Manager for central model management, qbank_questiongen keeps everything in one place. Also worth a look for AI-assisted study features is SmartEdu (block_smartedu).
Layer 2c: providers & infrastructure plugins
Two kinds of plugin sit beneath the visible features and are easy to overlook until something won't install. Understanding them prevents the classic ‘I installed the chatbot but it does nothing’ problem.
Provider plugins (extend model choice)
These add AI services beyond the core set: the Gemini API provider brings Google's Gemini models (text, image and summarise) with a privacy-first design, and the OpenAI-compatible provider lets you point Moodle at any endpoint that speaks the OpenAI API — including self-hosted models.
Infrastructure plugins (the plumbing)
The AI Manager (local_ai_manager) is a central management layer that several chat and question plugins build on. It supports multiple models (ChatGPT, Ollama, Gemini) via a subplugin structure and lets each tenant procure its own credit and make it available to teachers and students — which is why it's popular in multi-tenant and district deployments. The lighter AI Connector (local_ai_connector) simply connects Moodle to AI services for other plugins to use. Neither is user-facing; they exist so the plugins above have something to talk to. Check a plugin's dependencies before installing — if it needs AI Manager, install that first.
How to choose your Moodle AI stack
With core plus a dozen plugins, the risk is over-installing. Use this simple decision path instead of collecting plugins:
- Start with core. If all you need is summarise/explain and content generation, configure one provider in the native subsystem and stop there — no plugins required.
- Add a chat block only if you need conversation. Pick OpenAI Chat Block for a simple, dependency-free bot, AI Chat for a richer multi-model experience, or Exabis AI Chat for course-aware, privacy-first tutoring.
- Add a question generator only if you author assessments at volume. Match it to where your content lives (course files vs pasted text).
- Add a provider plugin only for a specific model or privacy need (Gemini, or a self-hosted OpenAI-compatible endpoint).
- Standardise on AI Manager if you're multi-tenant or want central credit and model control; otherwise skip it and keep the stack lean.
The best stack is the smallest one that meets your use cases — every extra plugin is another thing to update and secure on each Moodle upgrade.
The part the plugin list doesn't tell you
Installing an AI plugin is the easy 20%. The other 80% — the part that decides whether your AI rollout is safe, affordable and durable — sits in three questions:
1. Privacy and data residency
Every prompt a learner types can contain personal or sensitive data. Where does it go? Cloud providers process prompts on their infrastructure, often outside India; local models via Ollama keep data in-house but need hardware. For banking, insurance, healthcare and government buyers, this is a procurement blocker, not a footnote — and it intersects directly with the DPDP Act. Choose providers and hosting with residency in mind.
2. Cost control
Bring-your-own-key means bring-your-own-bill. Without quotas and reporting, a popular chatbot can quietly run up token costs. Moodle 5.1's AI usage reporting helps, and AI Manager adds per-tenant credit control — but you still need a policy on which models, which placements, and which user roles get access.
3. Maintenance and version drift
A DIY stack might be core AI + AI Manager + AI Chat + a provider plugin + a question generator. Each has its own release cadence and its own compatibility with your Moodle version. Every Moodle upgrade becomes a regression test across the whole AI stack. This is manageable — but it is real, ongoing work.
- 1Update to a current Moodle version
The native AI subsystem needs 4.5+, and the best governance (course/activity access control, usage reporting) lands in 5.0/5.1. Upgrade first.
- 2Choose and configure your provider(s)
Decide between cloud (OpenAI/Azure/Gemini/DeepSeek) and local (Ollama) based on privacy and budget, then add API keys or install the provider plugin.
- 3Enable the placements you want
Turn on the course assistant and editor tools, and set which actions (generate, summarise, explain) are available in each.
- 4Add third-party plugins for gaps only
Install a chat block, question generator or extra provider for what core doesn't cover — and install any AI Manager dependency first.
- 5Set access, quotas and a privacy policy
Use course/activity access controls, usage reporting and (via AI Manager) credit limits to govern who uses AI, how much, and with what data.
- 6Test through every Moodle upgrade
Treat the AI stack as a unit and regression-test providers, placements and plugins after each core update.
DIY AI-plugin stack
- Assemble core AI + manager + chat + provider + generators yourself
- Manage multiple API keys, dependencies, quotas and bills
- Own privacy, data residency and DPDP alignment
- Regression-test the whole stack on every upgrade
- Roleplay and SCORM AI need separate tools, if available at all
AI-ready managed Moodle (edzlms)
- AI integrated and configured on managed Moodle
- Cost, quotas, dependencies and updates handled for you
- India data-residency options for compliance-sensitive teams
- Upgrades tested so the AI stack keeps working
- Gelato AI roleplay + SCORM AI study layer included
Want AI on Moodle without assembling it yourself?
edzlms is managed, performance-tuned Moodle with AI already integrated — native subsystem plus Gelato AI roleplay and a SCORM AI study layer — with India data-residency options. Tell us your use case and we'll configure it for you.
Try local models before you rule out AI on privacy grounds
If data residency is your blocker, the Ollama provider runs open models on your own server so prompts never leave your infrastructure. It's the fastest way to pilot Moodle AI in a compliance-sensitive environment.
Frequently asked questions
What is the Moodle AI subsystem?
It is the AI framework built into Moodle core since version 4.5. Administrators connect an AI provider, such as OpenAI, Azure OpenAI or a local Ollama model, and enable placements like the course assistant and the text editor, which give teachers and learners actions such as generate text, summarise and explain.
Can AI tutors work with existing Moodle or Canvas systems?
Yes. In Moodle you can use the core AI subsystem or add an AI chat plugin. For both Moodle and Canvas, external AI tools usually connect through LTI, so learners stay in the courses they already use.
Are there AI learning platforms with Moodle integration?
Yes. Besides Moodle's own AI features and third-party plugins, managed platforms such as edzlms run on Moodle and add AI course creation and Gelato AI roleplay practice, so you get AI features without maintaining the plugins yourself.
How can universities use AI for assessment in Moodle?
Common starting points are AI question-generation plugins that draft quiz questions from course files, which teachers then review, and the core AI placements for summaries and feedback drafts. Keep a human review step before any AI-generated question or grade reaches students.
Does Moodle have built-in AI, or do I need a plugin?
Moodle has a built-in AI subsystem from version 4.5, expanded in every release up to 5.3 LTS. It covers generate text, generate image, summarise and explain through providers like OpenAI, Azure, Ollama, DeepSeek, Gemini, Amazon Bedrock and Anthropic Claude. You only need plugins for extras such as chatbots, question generation or central credit management.
What are the best AI chat plugins for Moodle?
AI Chat (block_ai_chat) is the most full-featured, supporting GPT-4o, Gemini and Llama 3 but requiring the AI Manager plugin. OpenAI Chat Block (block_openai_chat) is a lighter option built on the native subsystem with no dependency. Exabis AI Chat (block_exaaichat) offers privacy-first, course-aware chat. All three are free in the Moodle plugins directory.
Which plugin generates quiz questions with AI in Moodle?
Several do. qbank_genai generates multiple-choice and essay questions from a course's own files; local_aiquestions works from pasted text; qbank_questiongen uses the AI Manager; and block_openai_questions creates True/False, Short Answer and MCQ from a paragraph. Always have a human review AI-generated questions before use.
Which AI providers does Moodle support?
As of Moodle 5.3, core supports OpenAI, Azure OpenAI, Ollama (local models, since 5.0), DeepSeek (5.1), Google Gemini and Amazon Bedrock (both 5.2) and Anthropic Claude (5.3). Other OpenAI-compatible endpoints can be reached through the OpenAI provider's endpoint setting or the aiprovider_openaicompatible plugin.
What is the AI Manager (local_ai_manager) and do I need it?
AI Manager is an infrastructure plugin that centrally manages AI models and per-tenant credit, and several chat and question plugins depend on it. You need it only if you install a plugin that requires it or want central model/credit control — otherwise the native subsystem and dependency-free plugins are enough.
Is Moodle AI safe for sensitive or student data?
It can be, with the right setup. Cloud providers process prompts on their servers, so for sensitive data consider the Ollama provider (local models on your own server) and hosting with India data residency. Moodle 5.0 added an AI usage report and 5.1 added course- and activity-level access controls to govern use — important under the DPDP Act.
How does edzlms handle AI on Moodle?
edzlms delivers AI-ready, managed Moodle with the native subsystem configured for you, plus Gelato AI roleplay for sales and compliance practice and a SCORM AI study layer (summaries, flashcards, quizzes and ask-AI over your content) — with India data-residency options and upgrades tested so nothing breaks.
Get AI-ready Moodle without the assembly
The plugin ecosystem is powerful, but a production AI rollout is about privacy, cost and maintenance as much as features. If you'd rather skip assembling and testing the stack, we'll set up AI on managed Moodle for your exact use case — and add Gelato roleplay and the SCORM AI study layer on top.
Curious where this is all heading? Read the companion piece: Agentic AI in Learning — how autonomous AI agents are reshaping digital education.
Already sitting on a library of static SCORM? adding an AI study layer to SCORM you already own.
Prefer to pick a slot directly? Grab a time here, or email marketing@edzlms.com.
Written by Mihir Jana, founder of edzlms — connect on LinkedIn.