Drupal AI 1.5 in Practice: Building Governed Editorial Automation Without Losing Human Control

Drupal AI has moved beyond the stage where its main appeal was adding a prompt box to an editing form. The 1.5 release, published on 14 October 2026, adds capabilities aimed at real content operations: conversational memory, extractive question answering, embeddings-related operations, Search API reranking, request metadata and a slimmer core as some features move into more focused projects. It also continues the broader shift towards AI Automators that can be used as part of editorial and operational workflows rather than isolated demonstrations. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

That makes Drupal AI 1.5 interesting for agencies, site builders and module developers, but it does not remove the need for architecture. The difficult part is not making an API request. It is deciding what the model may see, what it may change, what must be reviewed by a person, how the request is logged, and what happens when a provider is unavailable or confidently wrong.

What has changed in Drupal AI 1.5

Drupal AI 1.5 is compatible with Drupal 10.5 and Drupal 11.2 or later. The current stable 1.5.1 release was published on 14 October 2026 and is covered by Drupal’s security advisory policy. The project page lists chat memory plugins, extractive question answering, embeddings collection operation types, AI reranking for Search API, an HTML-to-Markdown converter, request metadata and Automators exposed as tools among the 1.5-era improvements. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

There are two important qualifications.

• Drupal AI is a framework and ecosystem, not a single complete AI product. Provider modules, submodules and related projects determine the actual experience available on a site.
• Not every feature should be treated as production-ready by default. The project documentation describes some assistant-related components as experimental, and the AI project itself notes that features have moved between the main project and standalone modules over time. ([project.pages.drupalcode.org](https://project.pages.drupalcode.org/ai/modules/ai_assistant_api/?utm_source=openai))

The practical consequence is that an upgrade should begin with a capability inventory, not with a blanket decision to enable every AI submodule.

Start with an upgrade and capability inventory

Check the platform baseline

Before changing dependencies, confirm the Drupal core version, PHP version, active provider modules and the deployment process used by the project.

drush status
drush pm:list --type=module --status=enabled
composer show drupal/core-recommended drupal/ai drupal/key

The 1.5 branch supports Drupal ^10.5 and ^11.2. If the site does not meet that requirement, upgrade Drupal core through the normal dependency and deployment process first rather than forcing an incompatible AI package. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

On a Composer-managed Drupal site, the documented installation constraint is:

composer require 'drupal/ai:^1.5'

Run this in a disposable environment or a branch with a reproducible database backup. The command updates the dependency graph; it does not by itself configure a provider or grant an assistant permission to modify content.

Map the desired capability to the smallest module set

A useful first-pass inventory looks like this:

Requirement	Likely Drupal AI area	Initial governance question
Generate or evaluate field content	AI Automators	Is the output written to a draft, a moderation state or the published revision?
Answer questions from site content	AI Search or an assistant integration	How are citations, permissions and out-of-scope questions handled?
Retain conversation context	Chat memory plugins	What is stored, for how long and under whose identity?
Improve search ordering	AI reranking for Search API	Can the result be measured against the existing search baseline?
Connect a custom Drupal action	AI function calls or newer Tool API work	Can the action be read-only, permission-checked and independently audited?

This prevents a common failure mode: installing a chatbot when the actual business requirement is content quality review, or adding a vector search layer when a better taxonomy and Search API configuration would solve the problem more cheaply.

Configure providers without leaking credentials

Drupal AI depends on the Key module for managing credentials. Provider configuration is available under /admin/config/ai/providers, but API keys should not be committed to configuration exports or placed directly in tracked settings files. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

A production deployment should make the credential source explicit. Depending on the provider and hosting platform, that may be an environment-backed key provider, a secrets manager or a protected configuration mechanism. The important principle is that exported Drupal configuration should describe which key entity is used, not contain the secret itself.

drush en key ai -y
drush cr

After enabling the modules, create the key through the administrative interface and configure the provider. Do not assume that a successful provider configuration proves that every operation is available. Text generation, embeddings, image generation, vision and other operations can have different provider support and different cost profiles.

Use a provider abstraction deliberately

The provider abstraction is valuable because it keeps application code less tightly coupled to one vendor. It does not make provider differences disappear. Models vary in context limits, structured-output support, latency, regional availability, retention policy and moderation behaviour.

For each configured provider, record at least:

• the approved models and supported operations;
• the data classification allowed in prompts;
• the geographical and contractual processing boundary;
• rate limits, budget limits and failure behaviour;
• the owner responsible for reviewing provider changes;
• the fallback behaviour when the provider returns an error or times out.

For a UK organisation, this information belongs in the same operational documentation as other external processors. “The key is stored securely” is not a complete governance statement; the team also needs to know what content leaves the platform and whether the provider retains or uses it.

Build a safe editorial workflow with AI Automators

AI Automators are one of the most immediately useful parts of the Drupal AI ecosystem. They can generate, amend or evaluate field content and can be configured against compatible field types. The documentation describes them as plugins that may be triggered individually or in sequence, with optional integrations for editors and workflow systems. ([project.pages.drupalcode.org](https://project.pages.drupalcode.org/ai/modules/ai_automators/?utm_source=openai))

A sensible first implementation is deliberately boring: use AI to prepare a draft or evaluation result, then let Drupal’s normal editorial workflow decide whether anything becomes public.

Recommended workflow

1. An editor creates or updates a content item.
2. An Automator generates a suggested summary, accessibility review or metadata draft.
3. The result is stored in a dedicated field or non-published revision.
4. A human reviews the result against the source content and editorial guidance.
5. The normal moderation transition publishes the revision.
6. The request, model, result status and reviewer action are retained according to the site’s audit policy.

Do not overwrite the authoritative field during the first implementation. A separate field such as field_ai_summary_suggestion makes it possible to compare the suggestion with the final copy, measure acceptance rates and roll back without reconstructing the original text.

Prompt design is part of the content model

A prompt should describe the task, the source of truth, the output constraints and the failure behaviour. “Write a good summary” is not an adequate production specification.

You are assisting an editor.

Use only the supplied source content. Do not add facts, dates, quotations,
statistics or claims that are not present in the source.

Create:
1. A summary of no more than 60 words.
2. Three factual key points.
3. A list of claims that appear ambiguous or unsupported.

Use UK English. Return valid JSON with the keys:
summary, key_points, and review_flags.

If the source does not contain enough information, leave the relevant value
empty and add a review flag.

Even with these instructions, the output must be treated as untrusted input. Validate the shape, escape the result for its destination, enforce length limits and keep the editor in the loop for anything that affects public content.

Do not let generated HTML bypass Drupal’s filters

When an Automator writes to a formatted text field, the result should pass through the same text-format restrictions as manually entered content. Do not grant a model permission to introduce arbitrary scripts, event handlers, unsafe URLs or unapproved embeds.

For plain editorial assistance, returning structured text or Markdown is usually easier to validate than returning unrestricted HTML. If HTML is required, use a deliberately narrow field configuration and test the complete rendering path, including sanitisation, caching and revision display.

Use AI Search as retrieval, not as a replacement for source content

AI Search documentation describes retrieval-augmented generation as a way to combine site content with an assistant or search experience. It also documents integrations with Views, database or Solr search and programmatic use. ([project.pages.drupalcode.org](https://project.pages.drupalcode.org/ai/modules/ai_search/?utm_source=openai))

The architectural rule is simple: retrieval should identify authoritative source material; generation should explain or transform that material. The model should not be treated as the database.

A defensible site assistant should therefore:

• retrieve only content the current visitor is allowed to access;
• preserve language and site-section boundaries where relevant;
• show links or citations to the source entities;
• state when the answer is not supported by the available content;
• avoid silently combining draft, unpublished or restricted material with public answers;
• log enough metadata to reproduce the retrieval decision without storing unnecessary personal data.

The Drupal AI demo presented at DrupalCon Rotterdam illustrates this direction: answers are grounded in the site’s own content, sources are cited and questions outside the site’s scope are not simply answered with invented information. That is a useful product pattern, but it should be implemented as an explicit acceptance criterion rather than assumed because an AI module is installed. ([drupal.org](https://www.drupal.org/about/ai/initiatives/blog/drupal-ai-after-the-driesnote-rotterdam-what-you-can-use-today-and-what-comes-next?utm_source=openai))

Memory creates a new data-retention problem

Persistent conversation memory can improve an assistant’s usefulness, but it changes the privacy model. A stateless request contains one prompt and one response. A stateful assistant may accumulate preferences, sensitive questions, personal details and incorrect assumptions over many interactions.

Before enabling memory, decide:

• whether memory is attached to an authenticated account, an anonymous session or both;
• which fields are stored and whether raw prompts are necessary;
• how users can inspect, correct and delete their stored context;
• how long inactive conversations remain available;
• whether memory is sent to an external provider on every request;
• how memory is excluded from analytics, support exports and backups where appropriate.

Memory should not become an unreviewed profile of a visitor. Treat it as a separate data store with its own retention and access rules.

Observability: measure the workflow, not just the model

Drupal’s AI project describes an AI Observability module that can log AI requests using PSR-3-compatible logging and connect with OpenTelemetry-based monitoring. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

Operational visibility should cover more than provider latency. Track:

• the Drupal route, module or Automator that initiated the request;
• the operation type and provider identifier;
• duration, timeout and retry status;
• token or usage metadata where supplied by the provider;
• validation failures and moderation or guardrail outcomes;
• whether an editor accepted, modified or rejected the result;
• the cost centre or site feature responsible for the request.

Be careful with payload logging. Full prompts and responses can contain personal data, unpublished copy or confidential information. A useful default is to log identifiers, status and measurements while applying a short, documented retention period to payloads only where debugging genuinely requires them.

Custom integrations: keep actions narrow and permission-aware

Drupal AI documentation includes a function-call plugin approach in the 1.x line. A plugin declares a function, its context definitions and an execution method. The documentation also notes that this API is expected to be replaced by the Tool API in 2.0.x, so new integrations should avoid creating a large proprietary framework around the older mechanism. ([project.pages.drupalcode.org](https://project.pages.drupalcode.org/ai/1.5.x/developers/function_call/?utm_source=openai))

A minimal read-only function can look like this:

<?php

namespace Drupal\my_module\Plugin\AiFunctionCall;

use Drupal\ai\Attribute\FunctionCall;
use Drupal\ai\Base\FunctionCallBase;
use Drupal\ai\Service\FunctionCalling\ExecutableFunctionCallInterface;
use Drupal\Core\Plugin\Context\ContextDefinition;
use Drupal\Core\StringTranslation\TranslatableMarkup;

#[FunctionCall(
  id: 'my_module:hello_world',
  function_name: 'hello_world',
  name: 'Hello World',
  description: 'Returns a greeting for a given name.',
  context_definitions: [
    'name' => new ContextDefinition(
      data_type: 'string',
      label: new TranslatableMarkup('Name'),
      description: new TranslatableMarkup('The name of the person to greet.'),
      required: TRUE,
    ),
  ],
)]
final class HelloWorld extends FunctionCallBase implements ExecutableFunctionCallInterface {

  public function execute(): void {
    $name = $this->getContextValue('name');
    $this->setOutput("Hello, {$name}! Welcome to Drupal.");
  }

}

This example is intentionally harmless. Real actions should inject services rather than calling static APIs, validate every argument, enforce access checks and return a constrained result. A content-changing action should normally create a draft or revision, never publish directly from an LLM decision.

After adding a plugin, rebuild Drupal’s discovery cache:

drush cr

For new work, monitor the Tool API direction and keep the action boundary small enough to migrate. A single read-only “find relevant images” or “list available events” capability is easier to secure than a general-purpose action that accepts arbitrary entity types, fields and operations.

Testing and failure handling

AI features require conventional automated tests plus evaluation tests. The conventional tests verify that permissions, validation, queues, revisions and error handling work. Evaluation tests verify whether the output is useful and safe for representative content.

Build a fixture set containing:

• ordinary successful content;
• empty and very short content;
• content with misleading or contradictory statements;
• HTML containing links, tables and unsupported markup;
• restricted content that must not be retrieved;
• multilingual content and regional spelling differences;
• provider errors, slow responses and malformed structured output.

Test provider failure explicitly. A timeout should leave the original content unchanged and place the item into a visible retry or review state. A malformed response should be rejected rather than partially written. A provider quota error should be distinguishable from an editor validation error so that support teams know who must act.

Common mistakes to avoid

• Publishing generated content automatically: use drafts, revisions and moderation until quality and governance are proven.
• Sending complete entities to a provider: minimise the prompt to the fields required for the operation.
• Logging every payload forever: separate operational telemetry from retained content.
• Assuming retrieval equals truth: verify permissions, indexing freshness and source citations.
• Ignoring cost at queue level: batch operations and bulk updates can create unexpected provider spend.
• Building against experimental APIs without a migration plan: isolate integrations and follow the project’s API direction.
• Measuring only technical success: track editor acceptance, correction rate, time saved and harmful-output rate.

A practical rollout plan

A controlled rollout can be completed in four stages.

Stage one: prove the boundary

Install Drupal AI 1.5 in a non-production environment, configure one approved provider and implement one read-only or draft-only use case. Confirm that credentials, permissions, logging and configuration deployment behave as expected.

Stage two: measure editorial value

Run the feature against a representative content sample. Compare generated results with human-written results and record how often editors accept, rewrite or reject them. If the feature does not reduce work or improve quality, do not expand it merely because the model is capable.

Stage three: add governance controls

Document data classification, prompt ownership, retention, escalation and rollback. Add rate limits, queue controls, access checks and monitoring before enabling the feature for a larger editorial group.

Stage four: expand by capability

Add one operation at a time: summarisation, content review, search reranking, grounded question answering or a custom read-only action. Each should have its own success criteria and failure policy.

Conclusion

Drupal AI 1.5 is significant because it strengthens the foundations for governed AI workflows rather than treating AI as a decorative editor button. The release gives Drupal teams more building blocks for memory, retrieval, search, structured operations and workflow automation, while the surrounding project documentation makes clear that providers, submodules and experimental APIs still need to be evaluated carefully. ([drupal.org](https://www.drupal.org/project/ai?utm_source=openai))

The safest implementation pattern is also the most Drupal-like: keep authoritative content in entities, use permissions and moderation states, make changes reviewable, export configuration safely, log important operations and give editors a clear route to reject or correct automation. Start with one narrow workflow that produces measurable value. If that workflow remains useful under real content, real permissions and real provider failures, then Drupal AI becomes an operational capability rather than another ungoverned integration.