Choosing a Moodle AI plugin: 5 questions to ask before signing

The Moodle plugin catalogue now includes dozens of AI-labelled extensions. They all show convincing screenshots. Few document how they integrate with the platform, and even fewer explain what they do with the data that passes through them.

For a Moodle administrator or platform manager, the difficulty is not finding a tool. It is distinguishing an integration built to last from a connector quickly assembled around an API key.

Here are the five questions we would ask a provider, including ourselves. They are ranked in descending order of importance, and the first already eliminates a substantial part of the market.


1. Does the plugin use Moodle's native AI subsystem?

This is the most decisive technical question, and the least asked.

Moodle introduced an official AI subsystem in version 4.5. Its architecture strictly separates two component types: Placements, which manage the interface and where AI appears in the platform, and Providers, which manage communication with the model. A central manager orchestrates both and applies policies.

This architecture is not decorative. It centralises user acceptance of the AI-use policy, usage reports, access controls and integration with Moodle security mechanisms. A compliant plugin inherits all of this. A plugin that ignores it must rebuild everything, generally less well.

Yet many Moodle AI plugins were designed before this subsystem arrived, or bypassed it to move faster. They include their own API key management, configuration screens and storage logic. They work until the next major upgrade.

Put simply, we suggest asking: “Is your plugin declared as a Provider, a Placement, or both? And which minimum Moodle version does it support?” A provider who knows their subject answers in one sentence. One who hesitates tells you just as much.

A free additional check: the official Moodle plugins catalogue lists supported versions and the last update date. In a field that evolves this fast, an AI plugin not updated for over a year deserves at least a question.


2. Which legal regime applies to the data, and who are the subprocessors?

Two distinct questions, often confused with the location of the servers.

Location matters, but it is not enough. What determines who can access data is the law governing the company that processes it. A company subject to US law remains required under the CLOUD Act to comply with an order for data it controls, including data stored in Europe.

The practical questions are:

  • What is the legal nationality of the processing entity, and of its parent company?
  • Is the list of subprocessors published and kept up to date?
  • Are learner identifiers pseudonymised before any external call, or is the Moodle identity transmitted as is?
  • Can the retention period be administered from Moodle?
  • Does the plugin implement Moodle's Privacy API, which enables a user's data to be exported and deleted?

This last point is an excellent indicator. The Privacy API is the standard mechanism through which Moodle honours GDPR requests. A plugin that stores conversations without implementing it puts your institution in difficulty from the first deletion request. And it can be verified in the code.

Since 2 August 2026, the AI Act has added its own transparency and traceability requirements to those of the GDPR.


3. Is the tool designed to make learners work, or to save them from working?

A demonstration cannot settle this question. An assistant that answers quickly and well always makes a good impression.

Yet recent research is unambiguous about the consequences. The study by Bastani and colleagues, published in 2025 in the Proceedings of the National Academy of Sciences, followed nearly a thousand secondary-school students. With AI available during exercises, results improve markedly: +48% for the group with a standard assistant, and +127% for the group with an assistant featuring pedagogical guardrails.

But when access is removed and students take the exam alone, the group that used the standard assistant scores 17% lower than the group that never had AI access. This is the study's decisive point: this penalty largely disappears in the guided group. The guardrails did not improve final performance; they prevented it from deteriorating.

The guardrail in question was simple: asking AI to provide teacher-designed hints rather than the answer.

What should therefore be examined:

  • Does the assistant ask a question before answering, or does it provide the solution directly?
  • Are there progressive levels of help, and are they configurable?
  • What does the tool do when a learner explicitly asks it to write their assignment for them?

Ask for a demonstration of this last scenario. It is the fastest and most revealing test there is.


4. Is behaviour configurable at activity level?

A global setting for the whole platform is not enough.

A single course contains discovery activities, where generous support is desirable, and assessments, where it is not. If the plugin offers only a global switch, the administrator must choose between two poor options: disable it everywhere or accept AI's presence during tests.

Three levels of granularity to check:

By activity. Can the instructor disable the assistant for a specific quiz without administrator intervention?

By role. Are Moodle capabilities used, or does the plugin reimplement its own permissions management? The former integrates with your existing permissions matrix; the latter creates a parallel system to maintain.

By default. What behaviour is delivered at installation? Most users never change the initial settings. A plugin delivered with the assistant active everywhere, including in assessments, has made a pedagogical decision on your behalf.


5. What happens in two years?

The AI-tools market has a high rate of disappearance. This is not a theoretical question.

Maintenance and compatibility. What commitment does the provider make to supporting future Moodle versions? A plugin compliant with the official subsystem is structurally less likely to break during an upgrade than a plugin that manipulates the core.

Reversibility. If you stop the service, what happens to what already exists? Do generated activities remain standard Moodle activities that can be used without the plugin? Or do they depend on a proprietary format that would make them unusable? This is the difference between a tool that produces Moodle and one that produces captive content.

Business model. On what basis does pricing change? Model inference costs vary considerably, and a provider unable to explain its cost structure exposes you to an abrupt revision.


A note on how these questions are received

We develop an AI plugin for Moodle, so we are asked these questions and ask them of our own providers.

Our observation after several months of discussion on the subject: the quality of an answer matters more than its content. A provider who answers, "We are not yet compliant with the 4.5 subsystem; here is our timeline," inspires more trust than a provider who claims to master everything without going into detail.

A tool that processes learner data in a public institution engages that institution's responsibility. Providers who understand this know how to answer precisely. The others talk about user experience.


References