Drupal AI: What the AI Module Actually Does, and What It Costs

Drupal's AI work is real, installable software rather than a roadmap: an AI Core module that abstracts providers, plus a set of submodules that put generation, translation, search and logging inside the admin interface. This page describes what is actually in the package, read from the copy installed on the codebase behind this site, and what it costs an organisation to run it responsibly.

What is actually installed when you add the AI module

The project is called AI Core, and its .info.yml describes it plainly: "This module provides an abstraction layer for AI services." That is the important part — AI Core does not talk to any model itself. It defines the interfaces, and a provider module for OpenAI, Anthropic, Ollama or another service does the talking.

Two facts from the same file are worth having before you plan anything:

• core_version_requirement: ^10.5 || ^11.2. It will not install on Drupal 10.4 or on 11.1, and the copy I read declares no Drupal 12 support. If your site is behind on minor releases, that is the first piece of work, not the AI integration.
• It depends on the Key module and on core's File module. The Key dependency is a design decision worth appreciating: your API credentials live in a key provider, not in exported configuration, so they do not end up in your repository.

The version on the codebase I read is 1.5.0-rc3, packaged on 3 September 2026. Any article quoting an AI module version — including the earlier version of this page, which said 1.1.0 — goes stale within weeks. Check your own composer.lock.

The submodules, and what each one is for

The package ships fourteen submodules. These are the ones most sites care about, described from their own .info.yml files:

• AI CKEditor integration — a CKEditor 5 plugin that lets editors prompt for text generation without leaving the edit screen.
• AI Content Suggestions — passes content to a configured model and suggests alterations.
• AI Translate — one-click AI translation, working with core's content translation.
• AI Search — a Search API implementation backed by a vector database, which is the piece that makes semantic search on your own content possible.
• AI Automators — automatic field values generated on content creation, driven by tokens.
• AI Assistant API and AI Chatbot — a decoupled assistant back end and a front end for it.
• AI Logging and AI Observability — request and response logging, and export to the Drupal logger and OpenTelemetry.
• AI Validations and AI API Explorer — field validation support, and a developer surface for testing settings.

Two entries are marked as ending, which is exactly the kind of detail a feature list will not tell you. AI ECA integration states in its own description that it is "deprecated and being removed in AI 2.0.0", and AI External Moderation is labelled deprecated because its functionality was copied into AI Core. If you are building a workflow on either one today, you are building on something with a published end date.

AI Agents — the natural-language site-building piece that most write-ups lead with — is a separate project rather than a submodule. AI Core's composer.json lists drupal/ai_agents at ^1.3 in its development requirements only.

What this is genuinely good at today

Three uses are well matched to what the software does now, in rough order of how quickly they pay back.

Editorial assistance in the editor. Summaries, tone adjustment, meta descriptions, alternative headlines. The value is not the text quality; it is removing the copy-paste round trip to an external tool, which is where editorial time actually leaks.

Translation at volume. If you maintain the same content in five languages and today you either pay per update or let translations rot, AI translation with a human review step changes the economics substantially.

Semantic search over your own content. AI Search plus a vector store answers "what do we already have about X" in a way keyword search never has. On a site with a decade of content this is often the highest-value item on the list, and it is the one people think of last.

What it does not do, and what it costs

Nothing here removes the need to understand Drupal. Generated code still has to be reviewed by someone who knows why accessCheck(TRUE) exists; an agent that creates a content type still leaves you with a content model somebody has to live with. The realistic claim is compression of routine work, not replacement of judgement — which is the same conclusion reached in Hello, my name is AI.

The costs are ordinary but they are real, and they are the part rarely written down:

• Per-token API spend, which scales with editorial activity rather than with traffic, and which nobody owns by default.
• Credential management. The Key dependency handles storage; someone still has to own rotation and decide who can spend against the account.
• A data decision. Content leaving your site for a third-party model is a governance question before it is a technical one. Self-hosted models through Ollama exist precisely for organisations that cannot answer that question with "it is fine".
• Review workload. Generation without review moves the bottleneck rather than removing it, and a site that publishes unreviewed generated content will find out in its search performance.

How to adopt it without regretting it

1. Get to a supported core version first. ^10.5 || ^11.2 is not negotiable, and it is a good excuse to do the update that was overdue anyway.
2. Install AI Core and exactly one provider on a development site. Nothing else. Confirm credentials work through the Key module and that logging captures what you expect.
3. Enable one submodule with one user. AI CKEditor for a single editor is the usual first choice, because the failure mode is visible immediately and costs nothing.
4. Turn on AI Logging before anyone else gets access. Cost and misuse questions are unanswerable retrospectively.
5. Write the policy down. What may be sent to a model, who reviews output, and what happens if it is wrong. One page is enough; zero pages is what causes the incident.

If the decision is bigger than one module — where content lives, what may leave the estate, how many sites are affected — that is an architecture conversation, and the Drupal architect page describes how those decisions get made and documented.

What it means for people who build Drupal sites

The realistic effect on a Drupal developer's week is that boilerplate gets faster and reading unfamiliar code gets easier, while the parts that were hard stay hard: deciding where behaviour belongs, understanding an inherited codebase, and being accountable when something breaks in production. Work that was billed for typing is under pressure. Work that is billed for judgement is not.

The same shift is visible in how Drupal itself is being packaged for newcomers — the argument in how Drupal CMS is bringing experienced site builders back to Drupal is the non-AI half of the same story.

Common questions

Which AI provider should we use?

AI Core exists so that answer can change later. Choose on data policy and price first, model quality second, because the abstraction layer makes switching a configuration change rather than a rewrite.

Can we run this without sending content to a third party?

That is the reason self-hosted model support exists in the ecosystem. It is a real option and it costs you infrastructure and model quality instead of per-token fees. Treat it as an architecture decision with a budget, not a checkbox.

Is AI content bad for SEO?

Unreviewed, undifferentiated content is bad for SEO whoever wrote it. Generated drafts that are edited by someone who knows the subject are indistinguishable from any other drafting process. The risk is volume without review, and AI makes volume very cheap.

Should we wait for version 2?

If you want AI features in production, no — but note that AI ECA is scheduled for removal in 2.0.0, so avoid building critical workflows on it. If you have no concrete use case, waiting costs nothing.

Next steps

Start from a use case rather than the module list. Write down the one task your team repeats most often that is text-shaped, then check whether one submodule addresses it. If the answer is no, you have saved yourself an integration.

If you would like the adoption path scoped for your site — core version first, then a controlled pilot — see Drupal services, request a quote, or get in touch.