OnlineCCMS All articles
AI & Governance

Before You Press Generate: What UK Web Teams Should Demand From CMS AI Assistants

OnlineCCMS
Before You Press Generate: What UK Web Teams Should Demand From CMS AI Assistants

AI content assistants have moved from novelty to default. In 2026, if you open a mainstream CMS, there is a good chance a button offers to draft a page, tighten a paragraph, generate meta text or summarise a long policy document. For UK web teams, the interesting question is no longer whether these tools can write. It is whether you can defend what they do when someone from legal, the DPO or an accessibility audit asks.

This is not an argument for banning them. It is an argument for treating them like any other third-party processor with access to your unpublished content. A demo is not due diligence.

Begin with the job, not the demo

Before anyone switches on the assistant, write down the jobs you actually want it to do. Drafting meta descriptions is a different risk from rewriting a benefits page. Generating alt text for a photo of a council recycling bin is different from summarising a safeguarding policy. If the answer is simply 'make the team faster', that is not specific enough to test.

Ask what content the tool can see. Can it read unpublished drafts, user roles, form entries, comments or media metadata? Does it send the whole page to a model, or just the selected paragraph? The difference matters for data protection and for editorial control. A tool that quietly ingests the entire CMS to 'understand context' is not the same as a writing aid that works on a highlighted sentence.

Accessibility: plausible is not the same as correct

AI is very good at producing alt text that sounds right and is useless. It can describe a stock photo accurately while missing the point of the image in context. It can turn a clear heading structure into a flat wall of bold text. It can summarise a page in a way that drops the eligibility criteria. None of that will show up in a demo, but it will show up in an accessibility audit.

Ask the vendor how the assistant preserves structure. Does it keep heading levels, table headers, link text and caption relationships? Can editors accept or reject each suggestion, or does the tool rewrite whole blocks? Is there an audit trail showing what changed? Your baseline should be WCAG 2.2 AA, not 'it looks fine on screen'. If the assistant generates link text like 'click here' or alt text like 'image of document', it is creating work for your content team, not saving it.

The UK GDPR questions your DPO will ask

The data protection conversation should happen before the pilot, not after procurement. Where are prompts processed and stored? Is our content used to train models? Which subprocessors are involved? What is the retention period, and can we delete content on request? If data leaves the UK, what transfer mechanism is in place, such as the UK International Data Transfer Addendum?

Be careful with special category data and unpublished material. A draft press release about a restructure, a page about a named individual, or a form submission can contain personal data. If the assistant is only meant to improve grammar, why does it need to retain the text at all? A useful question is: can we turn off model training and set a short retention window in writing? If the answer is buried in a trust centre, ask for it in the contract.

Editorial governance: human in the loop, not human in the way

Decide which content types can use AI assistance and which cannot. Legal, safeguarding, health, safety and eligibility pages should be on the no-fly list until you have a very good reason and a named editor to sign off. For everything else, make the rule simple: no AI output goes live without a human editor who is accountable for the page.

That means updating your editorial policy, style guide and publishing workflow. Who checks facts? Who owns the final tone? How do you record that an assistant was used? You do not need a badge on every sentence, but you do need a way to answer a complaint or a correction request. The assistant is a drafting tool, not a member of staff.

Contract clauses to ask for in plain English

You do not need to be a lawyer to ask sensible questions. Look for clauses that say, in clear language, that your content will not be used to train models, that data will be deleted on exit, that subprocessors will be listed and notified, and that security incidents will be reported within a set time. Check who owns the output and whether the vendor can change the model without telling you.

Other clauses worth arguing over: audit rights, accessibility conformance, service levels, notice of material changes, and a clean exit plan that lets you export prompts, outputs and audit logs. If a vendor cannot explain a clause without jargon, treat that as a warning. In 2026, the market is crowded enough that you can walk away.

A low-risk pilot that tells you something

Pick twenty pages that matter but will not cause a crisis if they go wrong. Run the assistant for six weeks with a content designer, an accessibility lead and your DPO watching. Measure time saved, correction rate, accessibility defects and the number of times the tool produced something factually wrong. If it saves ten minutes but creates twenty minutes of checking, it is not a win.

AI content assistants are going to be part of many CMS platforms whether we like it or not. The UK web teams that get value from them will be the ones that treat them as a governed publishing tool, not a magic button. Switch them on deliberately, or they will switch on you.

All Articles

Related Articles

Don't Lift and Shift: 12 Questions UK Web Teams Should Answer Before a CMS Migration

Don't Lift and Shift: 12 Questions UK Web Teams Should Answer Before a CMS Migration