CMS Development

AI Drafting in an API-First CMS: What Works and What Is Hard

Where AI drafting fits in a modular, API-first CMS, which tasks to give it first, and the review, data and cost checks to set up before drafts pile up.

5 min readBy BizHues Engineering

Working on this?

Talk it through with an engineer.

A 30-minute requirements call, no charge.

Book a call

A marketing team adds AI drafting to its CMS and expects publishing to speed up. Drafting does speed up. Then review becomes the slow part, because nothing in the CMS was built to catch a wrong claim, an off-brand paragraph or a customer's name sitting in the text. This piece is for the people who will run that review: how the AI step fits into a modular, API-first CMS, which jobs to hand it, and what to settle before it goes live.

How the pieces fit together

API-first means the content is reachable through a defined interface before any particular website exists. Modular means the CMS is one part among several, a content store, a media library, search, maybe a personalisation service, each of which you could replace. An AI drafting step is then one more client of that interface. It reads entries, produces drafts or suggestions, and writes them back through the same API the editors and the frontends use.

A modular, API-first content stack
  • Channelswebsite, app, email
  • Content APIone contract for all clients
  • Modulescontent store, media, search, AI helper
  • Review and auditwho approved what

Each layer can be replaced without rewriting the ones above it.

We care about this arrangement because of control. If the AI helper is a module behind the API, you can restrict which fields it may write, log every call it made, and replace it next year when a better model turns up. If it is wired straight into the editor's rich-text box, you can do none of those things cleanly, and the editor cannot tell which sentences the model wrote.

Which jobs to hand over first

Good first tasks share two traits. A usable draft saves the editor a few minutes, and a wrong draft is obvious at a glance. Long articles, and anything about products, prices or legal terms, need a person who knows the facts, because the model does not.

Task Hand it to the model? Who checks the output
Image alt text Yes, as a suggestion The editor placing the image
Meta description, social snippet Yes, as a draft The editor publishing the entry
Tag and category suggestions Yes, editor accepts each one The section editor
Prices, fees, eligibility No The team that owns the number
Legal and policy text No Legal or compliance

Picture a hospital chain in Pune that publishes doctor profiles and health camp notices. Letting a model draft the alt text and the meta description for each camp notice is fine. Letting it draft the consultation charges or the list of insurers accepted is not, because a wrong number there turns into an argument at the front desk.

Personalisation tends to get mentioned in the same breath. It depends on having audience data you are allowed to use and a content model that stores variants cleanly. Without both you get forty near-duplicate entries that nobody maintains.

Where AI drafting goes wrong

Review does not grow with output

If an AI step triples the number of drafts, the same two editors now have three times the reading, and they still go home at six. Teams that skip review to keep up end up publishing errors under their own name. Plan the review capacity before you plan the drafting volume.

Nobody can say whether the drafts are good

"The drafts look fine" is not a test. What works better is a small fixed set of real inputs, say twenty product entries from last quarter, and a checklist of what a good output must contain. Run it again every time the prompt or the model changes, and keep the outputs you accepted so you can compare.

Private fields leave the building

Content entries carry customer names, internal notes, unpublished prices, sometimes a GST number pasted into a draft. Sending whole entries to an outside model without deciding which fields may leave is the first thing we would check in any setup like this.

Cost and shape show up late

Calling a model on every save costs nothing in a test with fifty entries and quite a lot on a catalogue with a few lakh SKUs. And if the model returns a paragraph where the CMS expects a title, a summary and three tags, somebody ends up pasting by hand. The automation has then created a job instead of removing one.

A draft state the public site cannot see

AI-assisted draft with a human gate
  1. 01Brieffields and sources
  2. 02Draftsaved as unpublished
  3. 03Checkfacts, tone, data
  4. 04Approvenamed editor
  5. 05Publishvia content API

Nothing reaches the public API until a named person approves it.

The step that matters is the second one. The draft is saved in a state the public API does not serve, so a generated entry cannot go live by accident, whatever the model produced. Everything after that is ordinary editorial work your team already knows how to do. If you want the review step itself worked out in detail, the piece on putting a review step around generated text covers it.

The field rules belong in the integration's configuration, where the code enforces them, rather than in a policy document nobody opens. Something along these lines:

ai_helper:
  may_read: [title, summary, body, category]
  never_send: [internal_notes, customer_name, unpublished_price]
  may_write: [alt_text, meta_description, suggested_tags]
  writes_as: draft
  monthly_call_limit: 5000

A checklist before you switch it on

  • The fields the model may read, and the ones that never leave your system, are enforced in code.
  • A named person approves generated content, and the approval is recorded on the entry. "The marketing team" is not a name.
  • A fixed sample set exists, with the outputs you accepted, and it is rerun after any prompt or model change.
  • The output matches the content model field by field, so nothing is copied by hand.
  • There is a cap on how often the step runs and what it may cost in a month.
  • The step can be switched off. If the AI module is down on a Tuesday, publishing still works on Tuesday.

Most of these get answered in the CMS design rather than in the prompt, which is good news for the team that has to maintain it.

Why the modular setup pays off later

The AI tools will change faster than your CMS. A content API with a clear contract lets you try a new tool as a module and drop it if it fails your checks. A monolithic CMS makes that harder, because the AI feature arrives on the vendor's release schedule and leaves on it too. If you are still choosing the CMS itself, the comparison of headless and traditional CMS setups is the place to begin, and our AI solutions page lists the kinds of AI work this connects to.

Start small. Pick one low-risk task, alt text suggestions is the usual one, put it behind the unpublished draft state, and count how many suggestions editors accept over a month before you widen it to anything that touches prices.

Share this article
CMS Development

Talk to an engineer

Have a requirement worth building?

Book a 30-minute call with an engineer, at no charge. Tell us the problem and the systems involved, and you leave with questions answered and a suggested first step, not a sales deck.