Moodle AI provider configuration guide

Moodle AI provider configuration starts with deciding where data may go

Setting up Moodle AI provider configuration means deciding, before anyone switches a feature on, which parts of Moodle may send which data to which outside AI service. Enabling a provider is quick, and an administrator can usually complete the technical steps in a short session. The harder work is the decision layer around them: which placements may send which data, who pays for each use, and how teachers and privacy reviewers take part. If you have been asked to turn on AI features in a self-hosted Moodle, treat the configuration screens as the last step of the project, not the first.

Moodle 5.3, released on 5 October 2026, adds Anthropic's Claude as an AI provider plugin, so Claude is now one of the providers an institution can consider. Moodle's core code is licensed under GPL-3.0, but that license covers the Moodle code only. A third-party AI service is a separate contract and a separate data processing relationship, with its own terms on retention, use of submitted content, data location and subprocessors. Those terms belong with your procurement and privacy teams. Before enabling any provider, confirm with the provider which data each request contains, how long it is kept, and whether your agreement covers a school or university use case.

What makes this harder than it looks is that Moodle separates three layers. A provider is the connection to an external service, held together with its credentials and settings. A placement is a point in the Moodle interface where an AI action can be offered. A capability controls which roles may trigger that action. Enabling a provider does not decide which placements use it, and enabling a placement does not decide who can call it. An administrator who turns on a provider for the whole site may expose a placement inside course areas that hold student submissions, so each layer needs its own review and its own record of approval.

Your privacy review usually has to finish before the first teacher clicks anything. Ask the reviewer to sign off each placement individually, and record what that placement sends, which roles can trigger it and who approved it. Teachers should help define acceptable use and the content that must never go into a prompt, because they will judge the output quality and see the consequences first. Confirm with the provider how usage is billed and who owns that budget, since usage costs recur and grow with adoption. These decisions set the boundaries that every later configuration step depends on.

Which Moodle AI components you configure

Moodle AI features are built from a few separate parts: a subsystem in core, provider plugins that connect to outside services, the places where AI features appear, the capabilities that decide who can use them, and the admin settings that hold credentials and switches. Confirm exact setting labels and locations against the Moodle 5.3 release notes and your installed version before you write a configuration standard.

The AI subsystem in core

Moodle core includes an AI subsystem that sits between Moodle features and the provider plugins installed on the site. It is the first place to check which providers are registered and which are enabled. Confirm in your installed version how the subsystem routes requests and which settings it exposes, because the wording and grouping of these settings have changed between releases. Record the subsystem's location and version in your configuration baseline so that later upgrades can be compared against it.

Provider plugins, including Claude

Provider plugins connect the subsystem to an external AI service. Moodle 5.3 adds Anthropic's Claude as an AI provider plugin, so sites that upgrade to 5.3 gain it as an option. Each provider has its own data handling terms, pricing and processing locations, so the choice determines what leaves your environment. Before enabling any provider on a production site, confirm the plugin version, the Moodle versions it supports, and the outbound endpoints it contacts.

Placements where AI appears

Placements are the points in the interface where an AI feature is offered to a user, such as an assistance action inside a course or activity. Each placement exposes a different kind of data and a different audience, so they should be reviewed separately from the provider. Build a list of the placements you intend to allow and map each one to the roles that will see it. Confirm in your installed version whether each placement can be switched on or off individually, and check placement names against the release notes.

Capabilities that grant access

Capabilities are Moodle's permission flags. They decide which roles can use AI features and which can manage AI settings. Access is granted through role assignments in system and course contexts, so a provider can be enabled while most users still lack the permission to use it. After an upgrade, check whether new AI capabilities have been assigned to existing roles by default. Test with sample student, teacher and manager accounts before any rollout to real courses.

Admin settings for credentials

Admin settings hold the API credentials for each provider and the switches that enable or disable it site-wide. Anyone who can read or change a provider key can call that provider under your account, so restrict these settings to a small group of administrators. Confirm the exact setting labels, where the enablement switch sits, and how the key is stored in your installed version. Plan how keys will be rotated and who is notified when that happens.

Version and platform prerequisites

Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must already run Moodle 4.4 or later to upgrade. AI provider configuration only works on a site that meets these requirements, so check them before you plan any AI rollout. Confirm the full list in the 5.3 release notes, and compare it with the platform your site currently runs on.

Which AI provider and placements to enable

This table compares the main configuration choices for Moodle's AI providers and placements, with the operational cost of each. Read each row as a decision: find the option that matches your data policy and support capacity, then check the cost column before you enable it. The main takeaway is that every option that widens data flow or teacher access also widens your review and support work.

Decision	When it fits	Operational cost
Single hosted provider versus several providers	One provider already approved by your privacy office, with a clear contract and data processing terms. Several providers fit only when a specific use case needs a different model.	One provider means one set of data terms, one review and one outage risk. Several providers multiply privacy review, usage monitoring and the fallback behavior you must test for each.
Placements enabled institution-wide versus per course or category	Institution-wide suits a small pilot group or a single faculty with clear guidance. Per course or category fits a staged rollout where you want to learn from early use before opening it up.	Institution-wide enablement creates the widest support load and the broadest data exposure at once. Per course or category needs ongoing admin effort to track which areas are enabled and why.
Opt-in versus default-on for teachers	Opt-in fits institutions that want deliberate adoption, documented teacher training and a record of who chose to use AI. Default-on fits environments where AI features are already expected and the policy has been signed off.	Opt-in means slower uptake and more questions about availability. Default-on increases the volume of prompts sent to the provider, so usage costs, teacher guidance and data review must be in place before go-live.
External provider versus no external AI	External provider fits when AI features are needed and your data terms allow it for the data types involved. No external AI fits when course content or learner data cannot leave your controlled environment.	An external provider adds data exposure review, recurring usage charges, and a plan for when the provider is unavailable. No external AI removes these costs but may leave teachers without the features they were expecting.
Staff only versus students	Staff only fits the first phase, when teachers and administrators test prompts, review outputs and learn the limits. Extending to students fits once you have tested the content risks, age considerations and student guidance.	Student access raises the volume of requests, the sensitivity of data sent to the provider and the need for clear disclosure and support routes. Each new user group needs its own review before access is widened.

How to configure a Moodle AI provider step by step

This sequence takes a Moodle site from a version and requirements check to a production AI provider that has been tested, scoped to approved roles and assigned an owner. Each step closes with a record or check that the next step depends on. Run the sequence on staging first and settle the privacy and course design decisions in writing before any credential is created.

Confirm the Moodle version and requirements
A platform administrator checks the running Moodle version, PHP version and database engine against the release notes for that version. If the Claude provider is part of the plan, the site must run Moodle 5.3 or later, which requires 64-bit PHP 8.3 or later (8.4 is supported) and a supported database such as PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Confirm that the web server document root points to the /public directory, which Moodle has required since 5.1. The step is done when a written note records each version and every check passes.
Record the data each placement sends
Before any provider is connected, the data protection lead and the course design lead list every AI placement the site will offer and write down which data categories each one sends to the provider. Include course content, user names, submissions and any personal data a prompt might contain. Ask the provider for its data processing terms, its retention periods and whether customer data is used for model training, then file the answers with the placement list. The step is done when every placement has a data record that the privacy reviewer has approved.
Store the provider credential outside the web root
The platform administrator creates the API credential in the provider's console under an organization-owned account. Store the key in a location outside the web root and outside the Moodle code directory, with file permissions that let only the web server and named administrators read it. Limit who can view the value in the admin interface, and record where the secret is kept and who is responsible for rotating it. The step is done when a browser request to the site cannot reach the stored key and the record of its location is complete.
Enable the provider on a staging site first
Bring a staging site to the same Moodle version as production and restore a recent copy of the database with personal data removed or replaced. Enable the AI provider there and confirm that it appears in the AI settings and reads the credential from the stored location. Check the provider plugin's compatibility with the Moodle version in use before enabling it. The step is done when staging shows the provider as enabled, the site logs contain no provider errors, and the change is recorded for the later production change.
Set placements and capabilities for each role
The administrator turns on only the placements approved in the data review and leaves all others disabled. Next, set capabilities so teachers hold the permissions their approved tasks need, and students receive access only where the course design calls for it. Check each role with a test account, or with the capability overview for that role, to confirm that no placement is available to a role that was not approved. The step is done when a role matrix lists each placement against each role and the test accounts match it.
Test with sample content and review logs
Test users run a fixed set of prompts for each approved placement, using non-sensitive sample content such as a dummy course or invented assignment text. Record the outputs, any errors, and whether each placement sent only the data categories listed in the data record. Review the site logs and the provider's usage reports to confirm that requests match the test activity, and ask the provider how usage is metered and billed so costs can be read correctly. The step is done when the test record and reconciled usage figures are approved by the owner.
Enable production with an owner and rollback
Schedule the production change only after staging results are approved, and name one accountable owner for the provider, its credential and its usage. Document how to disable each placement and remove the provider, and rehearse the disable step on staging before the change. Enable the approved placements on production, then check the logs and a sample of live requests during the first working session. The step is done when the owner confirms that production matches the approved role matrix and the rollback has been rehearsed and recorded with the change ticket.

What drives the effort and cost of AI provider setup

This table lists the factors that change the effort and cost of configuring Moodle AI providers, with a way to keep each one under control. Provider usage is billed by the provider and depends on how teachers use the features, so treat the table as a checklist for your own usage forecast and quote questions rather than a price guide.

Driver	Why it changes effort or cost	How to keep it down
Number of providers and placements enabled	Each provider needs its own credentials, contract terms, data review and test cases, and each placement (such as text generation or image features in the editor or course tools) needs its own permissions and teacher guidance.	Start with one provider and the placements your pilot teachers need, then add others after review. Ask the team to list each placement and what data it sends.
Volume and sensitivity of data teachers may submit	Higher volumes raise provider usage charges, and sensitive content such as student names, grades, disability information or assessment questions raises the depth of privacy and security review.	Restrict placements to course-authoring use, instruct teachers not to paste student records, and confirm what the provider retains and whether it trains on submissions.
Number of courses and teachers involved	More teachers means more accounts to permission, more questions during rollout, and more usage that the provider bills. Usage grows with activity, not with the number of sites.	Pilot with one department or a small group of courses, then widen access in stages based on observed usage.
Privacy and procurement review depth	Review by data protection, legal and procurement teams covers the provider's terms, data location, sub-processors and contract clauses. Time spent here often exceeds the technical setup.	Prepare a one-page data flow for each provider before the review starts, and ask the provider for its current data processing terms and sub-processor list.
Staging and test environments	Provider settings, placements and permissions should be tested on a copy of the live site first. Without a staging site, testing happens in production and mistakes reach teachers.	Use a staging site on the same Moodle version as production, and test with dummy courses and accounts that contain no real student data.
Training for teachers	Teachers need guidance on what to submit, how to review generated output, and when to avoid the feature. Training effort scales with the number of teachers and the number of placements.	Write a short usage guide and a single example of acceptable use, then deliver one session per group rather than individual coaching.
Ongoing monitoring of usage	Usage reports, provider invoices and permission changes need periodic review. Without this, costs and data exposure can drift after go-live without anyone noticing.	Set a named owner, agree a monthly usage review with the provider's billing data, and set provider-side spending limits where the provider offers them.

How AI provider setup differs by deployment model

A single-node Moodle keeps the web server, PHP and the AI provider configuration on one machine. That gives you one place to set outbound rules and one place to hold credentials, but it also means that any scheduled task running on that host inherits the same egress path. Confirm the provider endpoint requirements and any proxy support with the provider and your network team before you enable a placement.

Outbound rules: allow HTTPS from the Moodle host to the provider endpoint named in the provider's documentation, and block AI traffic to any other destination.
Credentials: store the provider key in the site configuration, restrict which administrators can view or edit it, and record who rotates it and when.
Caching and cron: list the scheduled tasks and caches that can call the provider. On one host, a single egress rule covers both web requests and background work.
Proxy support: if outbound traffic must pass through a proxy, test a provider call through that proxy with the same settings Moodle uses in production.

Check that the endpoint list, proxy behavior and key owner are written into your change record before go-live.

Securing AI provider keys, data and access

Connecting Moodle to an external AI provider adds a new path for credentials, personal data and administrator actions to leave your environment. The cards below cover the controls that keep that path narrow, visible and reversible, and each one maps to a setting or check you can confirm in your own Moodle site.

Store provider API keys in a secrets store

Provider API keys should live in a secrets manager, environment variable or protected server configuration, never in course content, forum posts, shared spreadsheets or wiki pages. Confirm where the key is held, who can read the server file or secret, and that it does not appear in backups, support tickets or exported logs. Check that it is not echoed back in the admin settings form after saving.

Restrict who administers AI providers

Changing a provider, endpoint or placement affects what data leaves the site, so limit those settings to a small set of named site administrators. Review which roles hold the capabilities that control AI placements and provider configuration, and make sure teachers can use approved AI features without being able to alter provider settings. Enforce multi-factor authentication for every account in that group.

Allow outbound traffic only to approved endpoints

Configure egress rules on the firewall, proxy or cloud security group so the Moodle server can reach only the provider endpoints your review approved, plus the update and package sources you already need. Test the rules with a request to a blocked destination, since a failed AI call can look like a Moodle fault. Document each allowed hostname and the reason it is required.

Review what each AI placement may send

Each AI placement can send different content, such as a user's prompt, course text, uploaded files or profile details. For every placement you enable, list the fields and documents it can transmit and whether any personal data is included. Confirm the result against your data classification policy and privacy assessment before enabling the placement for students or teachers.

Log AI requests and administrator changes

Keep an audit trail of which placements made requests to a provider, which user triggered them, and every change to provider settings or permissions. Check that the logs record enough to answer an incident question without storing the content of prompts or responses unless your policy allows it. Decide how long the logs are kept and who can read them.

Rotate credentials when staff change

When an administrator who knew the provider key leaves, or a vendor account is reassigned, issue a new key, update the secrets store, and revoke the old one. Record the rotation date and owner in your operations runbook. Ask your provider how keys are scoped and whether usage can be tracked per key, since that determines how quickly you can isolate a suspected leak.

How to test that Moodle AI providers work and fail safely

Testing an AI provider configuration in Moodle is not finished when a test prompt returns text. Before any teacher or student uses a placement, confirm that each enabled placement reaches only the provider you intended. Work through every placement in the AI settings and record which provider handles it, then trigger each one from a test account and check the provider's usage or request record on the provider side. A placement that quietly falls back to another configured provider, or a provider left enabled from an earlier trial, is the kind of fault this step catches. Keep the results in a table with the placement, the account used, the provider, and the date, so the same check can be repeated after upgrades or plugin changes.

Next, test access. Create test accounts that mirror the roles you have assigned, including a student, a non-editing teacher, an editing teacher and a manager, and confirm that each can or cannot use each AI action as your capability decisions require. Check the capabilities at both the system and course context levels, because a permission granted in one context can appear to work in another. Use synthetic content only: invented course text, fictional student names and made-up assignments. Do not use real learner submissions or staff records in testing, because the test data itself would then be sent to a third party. Label the synthetic material clearly so that anyone reviewing logs can tell test traffic from production traffic.

Then test failure behavior deliberately. Enter an invalid API key, disable outbound access in a staging network, or point the provider at an unreachable endpoint, and observe what a user sees. The expected result is a clear, specific message that the AI action is unavailable, with no partial output saved as if it were complete, no loss of the user's own draft content, and no silent retries that multiply requests and charges. Watch the web server and task logs during these tests for repeated calls. Confirm that the same behavior occurs for scheduled or background tasks, since those can fail without any visible prompt. Ask your provider and your Moodle administrator to confirm which retry settings apply, because defaults can differ between releases and plugins.

Check the logs and the data flow. Confirm that Moodle records the events your policy requires, such as the placement used, the user, the time, the provider and the outcome, and that the log does not store prompt or response text unless you have decided it should. Then run a privacy check that compares the actual outbound request, captured at a proxy or with network monitoring in a test environment, against the data flow you documented for this topic. Any field sent that is absent from the documentation is a finding to resolve before go-live. Finally, confirm that disabling a provider stops all calls: turn it off, repeat the placement tests, and verify with the provider's usage record that no new requests arrive.

The last step is a teacher acceptance test with a written sign-off. Ask a small group of teachers to complete realistic tasks using synthetic material, and record whether the controls, labels and messages behave as described in your teacher guidance. Collect their findings in writing, resolve the defects, and have a named owner, usually the academic lead together with the data protection contact, sign the result with a date and the configuration version tested. Confirm with your own governance team how long sign-off records must be kept and where they are stored. This document is evidence for your internal review, not an independent audit or certification, so treat it as an input to your privacy and compliance process rather than a substitute for it.

What to monitor, document and upgrade after go-live

Once AI placements are live, the configuration keeps changing: spend moves, providers and placements get reconfigured, credentials age, and Moodle releases arrive on a fixed schedule. The cards below cover the recurring checks that keep the setup cost-controlled, documented and supported.

Monitor provider usage and billing

Compare metered usage and invoices from each AI provider against the forecast agreed before go-live, broken down by placement and by provider account. Set alert thresholds for spend and request volume so that a sudden rise, such as a new course or a looping scheduled task, is caught in days rather than at the end of the billing cycle. Confirm with each provider how usage is metered and how billing periods are reported, because those definitions drive how you reconcile.

Review AI request logs and errors

Review the request logs Moodle keeps for AI actions, along with provider-side error rates, timeouts and rejected requests. Look for patterns by placement, provider and time of day, and for failed calls that users retry, since retries multiply cost. Confirm which log fields are retained, for how long, and whether prompts or responses are stored, because the answer determines what your log review can and cannot show.

Keep the data flow record current

Update the record of what data leaves Moodle for each AI placement whenever a provider, model, region or placement is added, changed or switched off. Each change should trigger a fresh privacy review covering the data categories sent, the provider's processing terms and any transfer location. Treat a placement that was enabled informally as an unreviewed change until its record exists.

Rotate provider credentials

Store each provider API key in the Moodle configuration or your secrets manager with a named owner, and rotate keys on a fixed schedule and whenever staff with access leave. Check that a rotated key is updated in every site, cron host and staging copy that calls the provider, since a missed copy produces silent failures. Remove keys for retired providers rather than leaving them disabled in the database.

Track Moodle security and support dates

Moodle 5.3 has general support until 4 October 2027 and security support until 1 October 2029. Moodle 5.1 has security support until 19 April 2027, so sites still on 5.1 should plan a move to a supported release before that date. Major releases come every six months and point releases every two months, so schedule a recurring review rather than waiting for a deadline.

Re-test placements and check plugins on upgrade

After every Moodle upgrade, re-test each AI placement end to end: enablement, permissions, provider connection, a sample request and the user-facing output. Check plugin compatibility for any third-party AI or reporting plugin before the upgrade, not after. Confirm that the new release still accepts your provider configuration and that the document root and PHP version meet the requirements of the target release.

Questions buyers ask about Moodle AI provider configuration

What does Moodle AI provider configuration cost, and what drives it?

Two separate bills apply. DeployOpen's fees cover the scoped work: confirming your Moodle version, setting up providers and placements, configuring data handling and teacher controls, and testing. These fees follow from a written scope, and DeployOpen does not publish a price list.

Provider usage fees are paid directly to each AI provider and recur for as long as the AI features are used. Read each provider's own price list and estimate your pilot volume against it.

The number of providers, the placements you enable, the number of teacher pilot groups and whether a privacy review is included all shape the DeployOpen quote. Ask for one-time and recurring items to be listed separately.

How long does configuration take, and what makes it longer?

Duration depends mostly on how quickly internal reviews close. The technical settings are a short task on a site that already runs a supported Moodle version. The privacy review, the teacher pilot and provider account setup usually set the timeline.

Things that lengthen it include a Moodle upgrade needed first, network allowlisting by your firewall team, procurement of provider accounts and a pilot that needs more than one review cycle.

Ask for the duration in the written scope, with the dependencies it assumes. Confirm each internal step with its owner before the plan is agreed.

What does our internal team need to provide?

Four roles need to be named before work starts.

Privacy reviewer: approves what data each placement may send to a provider and signs off the retention and training terms.
Moodle administrator: confirms the Moodle version, database and admin access, and owns the settings after handover.
Teacher pilot group: a small set of teachers who test placements, report unexpected output and confirm the teacher controls work.
Network contact: confirms outbound connections to provider endpoints and any proxy or allowlist rules.

Agree who makes the final decision on each placement before the pilot starts, so approvals do not stall the project.

Can our own Moodle administrators configure AI providers without a partner?

Yes, a capable Moodle administrator can usually complete the settings. The harder parts are the decisions around data, placements and teacher controls, which need people beyond the administrator, such as a privacy reviewer and a teacher group.

A partner adds documented decisions for each placement, a tested configuration, a rollback path and evidence the privacy review can use. Your team may still prefer to do it internally if it has the time and the Moodle experience.

Before deciding, confirm your administrators' experience with Moodle's AI subsystem and how much of their time the project will take.

Does Claude as an AI provider require Moodle 5.3?

Moodle's 5.3 release notes list Anthropic's Claude as an AI provider plugin added in 5.3. Moodle 5.3 was released on 5 October 2026. It requires 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and an existing site must run Moodle 4.4 or later to upgrade.

If you run an earlier release, check the release notes and your version's plugin list to see whether the Claude option is offered there. Do not assume it is.

Confirm your current version and database before choosing Claude, because an upgrade to 5.3 changes platform requirements as well as the AI options.

Can AI features in Moodle be turned off completely?

Yes, the aim is to switch AI off fully, but confirm the exact steps on your Moodle version. Providers and placements are administered in Moodle's settings, so disabling them stops those features from calling external services.

To verify, confirm that no provider is enabled, that user-facing placements are hidden and that teacher-level options are off. Then test with a non-admin account.

Also ask your network team to confirm that outbound connections to provider endpoints are blocked. A settings change alone does not prove that no traffic leaves the site.

What data gets sent to an AI provider from Moodle?

The content depends on each placement and on what the user submits, so map every placement before enabling it. Text a teacher or student enters into an AI feature is sent to the provider, and some placements may also send surrounding course or activity content.

For each placement, document the fields and file types it sends, whether personal data can appear, and the provider's retention and training terms. Confirm these against the provider's current terms and the Moodle documentation for your version, because placements differ.

The privacy review should approve each placement separately rather than approving the whole site once.

How DeployOpen works on this

DeployOpen scopes Moodle AI provider configuration in writing before work starts, so the data flows, placements and teacher controls are agreed up front. We then configure and test the providers in your own Moodle environment, document the settings and hand them over with the evidence your privacy and governance reviewers need.

How we scope

Map which AI placements your teachers and staff will use, and which providers each placement may call.
Record what content, user data and course material could be sent to each provider, in writing.
Agree the Moodle version, hosting location and provider accounts in the fixed-scope document before any build starts.

How we build

Configure the AI provider and placement settings on a staging copy of your Moodle site first.
Test each placement with sample courses and non-production accounts to confirm what is sent and returned.
Set role capabilities so only approved users can access AI placements, and review each setting against the agreed scope.

How we hand over

Deliver a configuration record listing each provider, placement, role permission and data decision.
Provide a test script and results so your team can repeat the checks after any change or upgrade.
Walk your administrators and privacy reviewers through the settings, usage cost controls and the points that need their sign-off.

How we support

Offer ongoing support and upgrades as a retainer, covering provider changes and Moodle release updates.
Re-test AI placements after each Moodle upgrade, since provider plugins and settings can change between releases.
Confirm with your provider accounts and privacy team how usage is billed and reviewed before scaling AI features to more courses.