---
title: "AI workflows in Drupal 11: What really relieves editorial teams"
lang: en
type: blog
canonical: https://www.arocom.de/en/blog/drupal-ai-content-workflows
alternate: https://www.arocom.de/blog/drupal-ki-content-workflows
author: "Axel Roth"
published: 2026-04-21
last_updated: 2026-10-31
---

# AI workflows in Drupal 11: What really relieves editorial teams

In Drupal 11 (and well-maintained Drupal 10 installations), routine editorial tasks can be delegated to LLMs via the AI module ecosystem: meta descriptions, alt texts, teasers and raw translation drafts. The approval process stays unchanged: the AI writes suggestions into draft fields, editors review and publish. Our experience across projects: 20–30% time savings in ongoing content maintenance, driven mainly by translations and metadata. Tone of voice, fact-checking and prioritisation remain non-delegable.

## AI workflows in Drupal 11: What really relieves editorial teams

Back in 2023, the old arocom blog featured an experiment: a Drupal
module that generated meta descriptions via the OpenAI API. At the
time, a toy at the edge of the system. Three years later, it has
grown into a reliable pattern that we use productively in client
projects. The constant throughout: the AI writes suggestions, the
human publishes.

## Which tasks can be delegated

The most rewarding candidates are tasks that can be derived from
existing content. The editorial team has already done the real
work, the article. Everything else is transformation:

- **Meta title and meta description** from the article text, with a
  length limit and a keyword hint
- **Alt texts** for images in their media context (what does the
  image show, what is it for on this page)
- **Teaser variants** for overview pages, newsletters, social media
- **Raw translation drafts** DE→EN that a human edits, as the
  successor to the old DeepL/TMGMT workflow
- **Structure suggestions**: subheadings, FAQ extraction, related
  internal links

Three things are not delegable, and we mean that as a finding, not
as a precautionary phrase: tone of voice ("does this sound like
us?"), fact-checking and the decision on what gets published at all.

## Architecture: draft fields instead of autopilot

Technically, we use the Drupal AI module ecosystem with a provider
abstraction layer. The language model stays interchangeable, which
at the current pace of model releases is no theoretical advantage.
The decisive design pattern is simple: AI results never land
directly in the published field. They land in a suggestion field
that the editorial team sees in the familiar form, then adopts,
changes or discards.

```php
// Event subscriber: on presave, draft a meta description
// suggestion for nodes that lack one. Never overwrites.
public function onPresave(EntityPresaveEvent $event): void {
  $node = $event->getEntity();
  if (!$node->hasField('field_meta_suggestion')) {
    return;
  }
  if (!$node->get('field_meta_suggestion')->isEmpty()) {
    return; // editor already has a pending suggestion
  }
  $suggestion = $this->aiProvider->chat([
    'system' => 'Write a meta description, max. 155 characters, '
      . 'phrased in active voice, no superlatives.',
    'user' => $node->get('body')->summary
      ?: mb_substr(strip_tags($node->get('body')->value), 0, 2000),
  ]);
  $node->set('field_meta_suggestion', $suggestion);
}
```

The same mechanism carries alt texts (a vision model describes the
image, the editor sharpens the page context) and translations (the
raw draft goes into the translation queue instead of directly into
the EN node). The approval process, in our case Draft → Review →
Published, stays untouched. That is exactly why editorial teams
accept the system: it takes typing off their hands, not control.

## One workflow from start to finish: the meta description

The meta description workflow, step by step, shows what this feels
like in everyday editorial work. An editor writes a technical
article and saves the node as a draft. On save, the event
subscriber from the code example above checks whether the
suggestion field is empty. If it is, the article text goes to the
model with a fixed instruction: maximum 155 characters, active
voice, no superlatives. A few seconds later, the suggestion appears
in the edit form, clearly marked as a suggestion, right next to the
actual meta field.

The editor now has three options: adopt it, adopt it and sharpen
it, or discard it and write her own. In our projects, we see the
middle one most often. The suggestion captures the content, the
editor replaces a generic verb or moves the most important keyword
to the front. Only with her approval does the text move into the
real meta field and, with the status "Published", out into the
world.

For the editorial team, almost nothing changes in the familiar
form; it is one more field. No new tool, no second browser tab, no
half-day training session. This unobtrusiveness is no accident but
the most important acceptance criterion we took away from the first
projects.

## Alt texts with a vision model: what the AI sees and what it lacks

In the alt text workflow, a vision model describes the image when
it is uploaded to the media library. It reliably sees what is in
the picture: "Two people in front of a monitor in a meeting room."
What it cannot know is the function of the image on the page. Does
the photo document a workshop report, does it serve as a symbolic
image, or does it show the team from the article? The editor adds
this context in half a sentence, something like "editorial workshop
at the client's office in March".

The division of labour is clean: the model delivers the correct,
complete base description, the human delivers the meaning.
Previously, alt texts often stayed empty because describing from
scratch was tedious. Now the tedious part is done, and the human
contribution takes ten seconds per image. The effect pays off twice:
into accessibility and into image search.

## Translations: from the DeepL workflow to the LLM raw draft

Multilingual Drupal sites have had a well-rehearsed translation
path for years: TMGMT queue, machine raw draft (for a long time
DeepL), human editing. Switching to a language model changes the
quality of the raw draft more than the process. An LLM does not
translate sentence by sentence; it knows the whole article and
keeps terminology consistent across the text. We steer technical
terms via a glossary in the prompt: which terms stay German, which
product names are never translated, which register the brand
speaks in the target market.

So what does the human reviewer still change? In our projects,
mainly three things: idioms that sound wooden when translated
literally, legally tinged phrases that go by different names in
the target market, and headlines that are correct as translations
but weak as headlines. The effort drops from "translating" to
"editing". That is the difference between hours and minutes per
page.

## What comes out of it

Averaged across several projects, we see 20–30% time savings in
ongoing content maintenance. At the upper end are multilingual
sites, where the raw translation drafts make up the largest block.
Just as important is the quality effect: fields that used to stay
empty because they were tedious (alt texts!) are now consistently
maintained. Accessibility and SEO benefit in equal measure.

To put the number in its proper place: it is an observation across
several projects, not a laboratory value, and it refers to ongoing
content maintenance, not to writing the articles themselves. The
largest single item on multilingual sites is the raw translation
drafts, roughly half of the effect. Metadata and teaser variants
follow, and last come the alt texts, which are small in time but
previously simply got left undone. Monolingual sites accordingly
land at the lower end of the range.

If you want to check whether this pays off for your editorial
team: measure for one week how much time goes into metadata, alt
texts and translations. That number decides whether the workflow
is worth it.

## Prerequisites: what you need for this

For the pattern to run, four things are needed:

- **A current Drupal base:** Drupal 11 or a well-maintained Drupal
  10.3+. The AI module ecosystem supports both.
- **The AI module ecosystem:** the central AI module with the
  provider plugin for your chosen model vendor, plus building
  blocks for translation and media depending on the workflow.
- **Clean field structures:** The workflows build on defined
  fields. A site whose content lives in a single body field needs
  structural work first.
- **An API budget:** for ongoing editorial workflows, realistically
  a low two-digit euro amount per month. The one-off translation of
  large back catalogues costs more depending on volume, but stays
  far below the cost of human first translation.

The biggest item is not the inference but the setup: prompts per
content type, permissions, editorial training. Plan days for it,
not weeks.

### Which model do you use?

Deliberately none in particular. The Drupal AI ecosystem separates workflows and model vendors through a provider abstraction, and we configure for each task the model that best balances quality and cost. At the current pace of new model releases, this interchangeability is the real architectural advantage: a better or cheaper model is a configuration change, not a project.

### What does operation cost?

The model costs are rarely the problem. For typical editorial workflows (metadata, alt texts, teasers), in our experience they sit in the low two-digit euro range per month; the raw translation of larger back catalogues costs more as a one-off. Add the upkeep of prompts and occasional model updates, realistically a few hours per quarter. The bigger item is the one-off setup, and that depends on the number of workflows.

### Does this work in Drupal 10 too?

Yes. The AI module ecosystem supports Drupal 10.3 and Drupal 11 equally. If an upgrade is due anyway, it is worth planning both together, because the workflows build on well-maintained field structures. An AI workflow project is, however, no reason to migrate a stable Drupal 10 prematurely.