When Your CMS Gets a Brain: Building AI into LocalGov Drupal on AWS

I learnt something unexpected last year while watching a local authority content editor at work. She was creating a service page about waste collection — a task she'd done perhaps three hundred times before — and she paused, mid-sentence, to manually check the Flesch reading score of her draft in a separate browser tab. The irony struck me: here was a skilled professional, using a computer to write content for other humans, while manually performing a task that the computer beside her could do rather better. It felt a bit like watching someone use a calculator to check whether their spreadsheet was correct.

That moment shaped what became the LocalGov Drupal AI scenario — one of a growing collection of "try before you buy" demonstrations we have been building through the National Digital Exchange (NDX). Our attempt to bridge the gap between what local government organisations need and what cloud services can already provide, if only someone would wire them together in a way that makes sense.

The problem is not technology. It is confidence.

UK local government is stuck in a curious paradox. Research shows the vast majority of local authorities are actively exploring AI, yet cloud spending growth has flatlined. G-Cloud has existed for over twelve years, and many local government organisations have never used it. The barrier is not lack of interest — it is lack of confidence to evaluate and act.

NDX:Try exists to address precisely this. It provides UK local government organisations — from county councils and metropolitan boroughs to district authorities and parish councils — with free, time-limited AWS sandbox environments pre-loaded with realistic scenarios drawn from genuine local government needs. No procurement. No commitment. No risk. Just guided curiosity in an isolated environment that cleans itself up afterwards.

However, an empty sandbox is rather like giving someone a fully equipped kitchen and no recipes. What we needed were scenarios — complete, deployable demonstrations that let a service manager or a technology lead experience the possibilities firsthand.

A recipe, not a restaurant

Perhaps the most instructive analogy comes from cooking (a domain I think about more than is strictly professional). When you follow a recipe for the first time, you are not just making dinner — you are building a mental model of how ingredients combine, what heat does to protein, why timing matters. A good recipe teaches you principles whilst producing something edible.

Our approach to the LocalGov Drupal scenario follows this pattern. We did not build a bespoke application. We took the standard LocalGov Drupal — the same open-source CMS already used across local government by organisations like Croydon Council , Brighton & Hove City Council , and Bracknell Forest Council — and layered seven AI capabilities onto it using Amazon Web Services (AWS) managed services. The architecture is deliberately transparent:

Users → CloudFront (HTTPS) → ALB → ECS Fargate → LocalGov Drupal
                                        ↓
                                   Aurora Serverless v2 (MySQL)
                                   EFS (persistent files)
                                        ↓
                              Bedrock · Polly · Translate
                              Textract · Rekognition
        

Every component maps to a service you could provision independently. Five CDK constructs — networking, database, storage, compute, CDN — each doing one thing well. I must admit I find the simplicity slightly deceptive; a fair amount of hard-won learning is buried in those clean interfaces.

Seven features that meet real workflows

The seven AI capabilities were chosen not for technical impressiveness (though I think some of them are genuinely impressive) but for their proximity to what local government teams actually do every day:

1. AI Content Editing — Amazon Bedrock suggests improvements to draft content directly in the Drupal editor. No copy-pasting into a separate tool.
2. Readability Simplification — One click transforms complex policy language into plain English, targeting an appropriate reading age for public-facing content.
3. Auto Alt-Text — Upload an image, receive a description. This might sound modest until you realise most local government websites have thousands of images with empty alt attributes.
4. Listen to Page — Amazon Polly provides neural text-to-speech in seven languages, with speed controls and language selection. Accessibility compliance as a feature, not an afterthought.
5. Content Translation — Amazon Translate delivers 75+ languages instantly. For any authority serving diverse communities, this moves translation from a procurement exercise to an immediate capability.
6. PDF-to-Web Conversion — Amazon Textract extracts content from uploaded PDFs. Given the volume of PDF-only content on local government websites (and the accessibility problems that creates), this addresses a genuine gap.
7. AI-Enhanced Search — Bedrock-powered semantic search that understands what you meant, not just what you typed.

What makes this interesting is the orchestration

However, I believe the most technically interesting aspect is not the AI integration itself but what happens when someone clicks deploy. A single CloudFormation template provisions roughly twenty AWS resources, then a container starts, installs Drupal, enables forty-odd LocalGov modules, configures the AI features, and then — the part that still makes me slightly nervous — invokes Amazon Bedrock to generate an entire fictional council identity.

Each deployment creates a unique fictional authority: a plausible name, a heraldic logo generated by Nova Canvas, service pages, news articles, and step-by-step guides. You are not exploring a generic demo with placeholder text. You are exploring what feels like a real local government website, complete with locally-flavoured content about bins, planning applications, and library services. The user sees a live progress page while this happens, which I think strikes the right balance between transparency and not overwhelming people with details they did not ask for.

Three things we learnt

Three lessons from building this that I think generalise beyond our specific context:

First, the gap between "working" and "useful to someone else" is wider than you expect. The infrastructure code is perhaps 200 lines of TypeScript. The initialisation script that makes it usable by a non-technical person is over 1,000 lines. The ratio tells you where the real complexity lives: not in the cloud services, but in the human experience of using them.

Second, AI features are only as good as their integration points. We initially tried building a sophisticated CKEditor plugin for the AI writing assistant. It needed webpack, which complicated the container build. The simpler approach — injecting toolbar buttons via Drupal's hook system — delivered identical functionality with perhaps a tenth of the complexity. Sometimes the less technically sophisticated path is simply the correct one.

Third, people need to experience things to believe them. We can write about AI-generated alt-text or one-click translation until we are blue in the face. It does not land until someone uploads their own image, sees the description appear, and thinks: "oh, that is actually quite good." NDX:Try exists because of this insight. Reading about cloud services and using cloud services are fundamentally different experiences, and the gap between them is where institutional inertia lives.

Returning to the kitchen

It seems to me likely that what we have built is less a product and more a recipe card. The ingredients are all managed services; the method is infrastructure as code; the result is something a council can taste, understand, and — critically — decide whether to cook themselves. Perhaps the content editor I watched struggling with her Flesch score tab will never use our specific implementation. But if she deploys this scenario and sees her CMS suggest clearer phrasing, generate alt-text automatically, and offer page content in Urdu, Polish, or Welsh with a single click — perhaps that changes what she expects her tools to do for her.

We should not pretend that deploying AI into a CMS solves the structural challenges facing local government. It does not. But it does something arguably more valuable at this stage: it makes the abstract concrete, the theoretical practical, and the unfamiliar safe to explore.

If you work in UK local government, you can try this scenario (and several others) for free through NDX:Try. No procurement, no cost, no commitment — just a sandbox and 24 hours.

If you work elsewhere in the public sector (or are simply curious about what we are building), drop us a line at ndx@dsit.gov.uk. We would genuinely like to hear from you.

(Views in this article are my own.)