How to use AI to Draft, not Publish

Okay, let's jump right into this explainer. Today, we're looking at a highly secure architectural pattern for integrating AI into content management systems, based on some really fascinating insights from Arc AI. You know, we hear so much hype about AI just completely taking over content generation, running wild, and writing everything for us. But today, we're exploring a fundamentally different approach. We're looking at using AI as a strictly bounded, highly secure assistant. We're going to break this down into a problem, solution, and boundary framework, moving through these five logical steps: the tedious CMS problem, delegating to the AI, setting conversion limits, enforcing zero trust, and finally, a practical safety checklist.

Let's kick things off with section one, the tedious CMS problem. This really gets to the heart of the issue, doesn't it? Authors naturally start with a simple plain-text document. You've got a title, you've got your body text, and you're good to go. But the actual reality of getting that text into a content management system is a completely different story. Suddenly, you're dealing with URL slugs. You need strict meta descriptions, very specific SEO fields, and in a lot of cases, you have to do all of that twice if you're publishing in dual languages. Because this manual data entry is just so mind-numbingly tedious, it practically invites people to take shortcuts. And when people take shortcuts, you end up with embarrassing, easily avoidable mistakes, like a meta description accidentally copied and pasted from a completely different article.

So let's move into section two and look at how we can actually solve this by securely delegating specific tasks to the AI. The absolutely crucial takeaway here is that we are only handing off arithmetic and pattern-matching tasks to the language model. We are definitely not asking it to decide if an article is inherently good or if it should even exist. We're just asking it to read the document and generate a slug, an SEO title strictly under 60 characters, an excerpt under 160 characters, and to pick a category from a fixed, pre-existing list. It handles alt text and translations, but only when explicitly required. These are tasks a model does flawlessly, while human beings find this work exhausting.

But here's the truly brilliant part of this pattern. The AI prompt itself is generated directly from the exact same limits the CMS validator enforces. If you change a character limit in your CMS, it automatically updates the prompt. That means the AI and your system are always perfectly in sync.

Convert, do not rewrite. This is where we establish our first hard boundary. What's really fascinating here is just how absolute this constraint is. The instruction to the AI is incredibly narrow, and that's completely by design. Think about it. If you ask a model to generally just clean up a paragraph, it's inevitably going to rewrite things you didn't want changed. In a professional publishing environment, you literally cannot afford that. The words in the body are the precise words the author chose, and they must reach the database totally untouched. The AI here is strictly a formatting and import tool. It is never an autonomous editor.

The zero trust policy handles the heavy-duty security architecture you need to make this work in the real world. If you take away nothing else, adopt this foundational mental model right here. You absolutely must never trust the AI's output blindly. There are zero exceptions to this rule. Even if you wrote the prompt yourself, you have to treat whatever comes back from the AI exactly like some random stranger uploading a file to your server. It has to be subjected to the exact same rigorous checks that a human editor's input would face.

To actually enforce that zero trust mindset, the output has to survive this strict validation gauntlet before it gets anywhere near your live database. The HTML doesn't just get a quick skim. It goes through a real parser, checked against a tiny, hyper-strict list of permitted tags. Scripts are refused outright. External images are completely blocked. It even verifies that the body contains exactly one main heading. A harmless little quirk, like the AI wrapping its answer in a Markdown code fence, might be tolerated, but absolutely nothing beyond that gets a pass.

And here is the all-or-nothing rule in action. Every single field, for both languages if you have them, is checked before a single byte of data is ever written to the database. If there's even one error anywhere, say an 11th keyword when the hard limit is 10, or a description that's just one single character too long, it results in exactly zero database writes. There's no scenario where the English half saves perfectly but the translated half sits there broken. It is entirely all or nothing. And even when it does pass with flying colors, it only ever lands as a draft.

Let's look at how this philosophy applies to handling new features. Early on, a natural idea comes up: "Hey, why not let the AI name image URLs so the server can just fetch them automatically? It saves a manual step, right?" Well, this slide defines exactly why that kind of feature is incredibly dangerous: server-side request forgery. Allowing a server to fetch an address based on an uploaded file, or in this case an AI prompt, gives bad actors a direct way to manipulate the server. Blocking SSRF risks proves that sometimes the absolute most secure feature is the one you intentionally refuse to build. That's exactly why humans still upload images by hand in this secure system.

Finally, we arrive at section five, our blueprint for your own systems: the final safety checklist. This checklist really distills everything we've talked about into actionable hard rules. You need to ask yourself: Are you relying on hope, or is the AI's task actually verifiable by code? Are your prompt rules generated directly from your validators, so they never drift out of sync? Are you validating the AI's output exactly like it came from a human? Is your import all-or-nothing, to prevent half-broken pages? Most importantly, does the output always strictly land as a draft? And finally, is your server totally blocked from fetching anything the AI names?

Because at the end of the day, despite all this brilliant automation taking care of the tedious double-entry work, there is a triad of tasks that must always, always remain in human hands. The AI handles the arithmetic, the character limits, the slug formatting. But human judgment is completely irreplaceable when it comes to deciding what is actually true, verifying that a piece is genuinely finished, and making the final critical call to hit that publish button.

So, as we wrap up this explainer today, I'm going to leave you to ponder this. Based on the exact guardrails you have built into your systems right now, which one of these is actually running your content management? Are you letting an autonomous publisher loose on your database, or have you securely constrained it into being just a really, really fast typist?