Drupal AI Integration Consultant | AI for Drupal & WordPress

Most AI vendors do not know what a cache tag is. Most Drupal shops have never shipped a retrieval pipeline. The interesting work sits exactly where those two gaps meet — and after fourteen years in enterprise CMS and several years building production AI, that intersection is the thing I am most useful for.

Why this is harder than either side alone

An AI consultancy will build you a working assistant that sits beside your CMS, hits an API, and has no idea that a node is unpublished, that a user lacks access to a taxonomy branch, or that your entire front end is served from Varnish. A CMS agency will wire up an API call in a module and stop there, with no retrieval, no evaluation and no notion of why answers are wrong.

The result of the first is a data leak waiting to happen. The result of the second is a demo. What actually ships has to satisfy both sets of constraints simultaneously.

Retrieval that honours node access

This is the specific thing that gets built wrong, and it is a genuine security problem rather than a quality one.

Drupal's access system is not a simple published flag. Node access grants, entity access hooks, field-level permissions, workflow states, taxonomy-based access, group membership and translation status all decide what a given user may read. When content is exported into a vector store, none of that travels with it by default. Every embedded chunk becomes readable by anyone who can reach the assistant.

The approach that works: carry the access grants into the index as filterable metadata, resolve the requesting user's grants at query time, and filter before retrieval so restricted content is never a candidate. Re-index on entity update, and honour unpublish and delete as index operations. Filtering after generation does not work — the model has already read the content and will paraphrase it.

Building it as a module, not a bolt-on

On Drupal that means a real module: configuration in the admin UI with a schema, credentials in environment variables rather than exported config, a plugin architecture for swappable providers, queue workers for anything that calls an API, and correct cache metadata so an AI feature does not silently make a page uncacheable.

Search API integration matters where it exists — if you already run Solr or Elasticsearch through Search API, hybrid retrieval should extend that rather than duplicate it. On WordPress the equivalent is a proper plugin: settings API, capability checks, cron or Action Scheduler for background work, and object caching.

The most common failure I am called in to fix is an AI feature calling a provider synchronously during page build. Fine in staging with one editor; it falls over the first time real traffic and a slow provider response coincide.

What editors actually get

Drafting assistance in context — summaries, meta descriptions, alt text and taxonomy suggestions inside the edit form, always with a human approving before save.
Semantic search across the archive — hybrid keyword and vector retrieval so a decade of content becomes findable by meaning, not just by exact wording.
A knowledge assistant grounded in the CMS — answering from the content you already maintain and govern, with citations back to the node.
Migration and content-audit help — classifying, deduplicating and tagging a large legacy corpus during an upgrade, which is otherwise weeks of manual work.
Translation and localisation support — draft translations into your existing multilingual setup for human review.

Where it is not worth it

A general "chat with our website" box is the feature most often requested and least often used. If your visitors are looking for a phone number or a product page, better search and clearer navigation beat a chatbot, and cost a fraction as much to run.

Similarly, if your content is thin, contradictory or out of date, an assistant grounded in it will confidently repeat those problems at scale. That case starts as a content exercise, not an AI one — and I would rather tell you that up front than build on it.

How an engagement runs

Audit — the content model, the access model, the search stack and the hosting constraints that shape what is possible.
Pick the use case — usually one editorial workflow or one retrieval surface, not a platform-wide programme.
Index pipeline — extraction from entities, structure-aware chunking, embeddings, access metadata, and re-index on change.
Module or plugin — queued, cached, permission-aware, configurable, and reviewable in a pull request.
Evaluation — a real question set scored on every change, wired into CI.
Launch and operate — monitoring, cost tracking per feature, and a feedback loop from real usage.

Common questions

Will the assistant respect Drupal node access and user permissions?

It must, and this is the part most implementations get wrong. Access grants are carried into the index as filterable metadata, the requesting user's grants are resolved at query time, and filtering happens before retrieval so restricted content is never a candidate. Filtering after generation is not sufficient — the model has already read the content and can leak it through paraphrase.

Do we need to replace our existing Solr or Elasticsearch setup?

No. If you already run Search API with Solr or Elasticsearch, hybrid retrieval should extend it rather than duplicate it — keyword search from the existing index, vector search alongside, results fused. Running two disconnected search systems is a maintenance problem and usually produces worse answers than either alone.

Can this run without content leaving our infrastructure?

Yes, using self-hosted open-weight models and a vector store inside your own environment. It costs more in infrastructure and is somewhat less capable than the frontier hosted models, so it is a decision worth making explicitly at the start rather than discovering later — it materially changes the architecture.

How does this affect page caching and performance?

It should not, if built correctly. AI calls belong in queue workers rather than the page build, results are cached, and cache metadata is set so an AI feature does not silently make a page uncacheable. A synchronous provider call during render is the single most common cause of AI features taking a site down under load.

We are mid-migration to Drupal 11. Should AI wait?

Usually yes for the user-facing features, since building against a platform you are about to replace wastes effort. But AI is genuinely useful during a migration itself — classifying, deduplicating and tagging a large legacy corpus is otherwise weeks of manual work. That is often the best first use case rather than the last.