Can You Prove Who Wrote That? Why Governance Is the Real AI Story in Content Management

Picture a regulator, an auditor, or opposing counsel asking a simple question about a paragraph on your website: who wrote it?

A few years ago, the answer was in your editorial workflow. An author drafted it, an editor reviewed it, legal signed off, and someone hit publish. Now a large language model may have written the first draft, rewritten the second, and generated the summary underneath. So the question gets harder. Which model? Which version? What prompt? Did a human review it, or did it move straight to production?

Most of the AI conversation in our industry is about speed: more content, in more places, with fewer people. But for teams in financial services, healthcare, life sciences, government, and higher education, speed is not the hard part. Trust is. And trust is a governance problem, not a generation problem.

AI content governance is the set of controls that decides which AI models can touch your content, what data they can see, who approves their output, and how every AI interaction is recorded. In a CMS, it’s the difference between saying a human reviewed AI-generated content and being able to prove it. Drupal handles this through granular permissions, configurable moderation workflows, provider-agnostic AI integration, guardrails, and auditable AI logging.

What does "content governance" mean when AI writes content?

Traditional content governance was built for human authors. You needed to know who could edit what, who could publish, and what changed between versions. That model assumed every word came from a person with a login.

AI breaks that assumption. Models are non-deterministic, so the same prompt can produce different answers. They can invent facts. And every prompt is a potential path for sensitive data to leave your organization. Regulations such as the EU AI Act, along with long-standing frameworks such as HIPAA and FedRAMP, raise the stakes further. They expect you to show your work.

It is no longer enough to have user roles and an approval button; the bar for a CMS has moved. Organizations now need to answer questions like:

• Can we control which AI models touch which content, and where that data goes?
• Can we stop sensitive information from reaching an external model in the first place?
• Can we make sure a human reviews AI output before it goes live?
• Can we produce a complete record of every AI interaction if someone asks?

How do different platforms handle AI governance?

Every major approach to content management was designed for a specific job, with each one handling AI governance a little differently. None of them is wrong. They simply optimize for different things.

Website builders are designed for small teams who want to launch quickly. They keep things simple with a handful of broad roles, and their AI features are typically built in and managed by the vendor. That is a great fit for a local business. It is a harder fit for an organization that needs to decide exactly where its data goes.

Plugin-driven open-source platforms offer enormous flexibility and huge ecosystems. Advanced permissions, multi-step approvals, and AI features often come from separate add-ons. That gives teams choice, but it also means governance can end up spread across several tools that were not designed to work together.

Headless SaaS platforms bring strong, fine-grained API permissions to decoupled architectures, and many now include role-based controls for AI features. Teams that need deep AI telemetry or provenance records often build that layer themselves, outside the platform.

Proprietary digital experience platforms carry impressive compliance certifications and some genuinely innovative provenance features. They tend to pair those strengths with a defined set of AI partners and infrastructure, which works well for organizations comfortable committing to that ecosystem.

Each of these is a reasonable choice for the right organization. The question is what you need when the stakes are high, the regulations are strict, and you want the freedom to choose your own path.

Where Drupal stands apart on AI governance

Drupal took a different route from the start. It was built as a structured content framework, and that foundation turns out to matter a great deal in the age of AI. Here is how Drupal answers each of the four governance questions above.

Permissions that match how your organization works

Drupal breaks system actions into hundreds of individual permissions instead of a few broad personas. You can let someone draft a specific type of content without letting them publish it, edit the live version, or change the site's taxonomy.

Since Drupal 10.3, the Access Policy API has taken this further. Permissions can now respond to context, not just roles. A policy might remove publishing rights outside business hours, require multi-factor authentication before someone can take sensitive actions, or keep one department's content separate from another's. The Access Policy API also changed how Drupal handles its original administrator account. The admin account used to bypass every permission check automatically. Now its powers are just another policy your security team can limit or remove.

Workflows with real checkpoints

Can you make sure a human reviews AI output before it goes live? Yes. In Drupal, publishing is a series of states and transitions that you define with the core Workflows and Content Moderation modules: Draft, Needs Editorial Review, Needs Legal Review, Published, Archived, or whatever your process requires. Each transition has its own permission, so the step from legal review to published can belong only to the people who are accountable for it.

Every change creates a new revision with a timestamp, the person responsible, and a log message. Teams can work on new drafts while the approved version stays live. When someone asks what changed and who approved it, the answer is already there.

You can also use AI reasoning as a first pass in your workflow: AI Content Review lets you automatically check content drafts for tone, clarity, and SEO. You configure the criteria and how they’re weighted. When you run a report, each check gets a 0-100 score, a severity level, and a plain-language reason. It can even suggest an improved version where necessary.

AI that you can point anywhere

Can you control which AI models touch which content, and where that data goes? Yes. The Drupal AI framework is provider-agnostic. It connects to major commercial models and also to self-hosted and open-weight models running inside your own infrastructure, something important for data sovereignty. A healthcare organization could send patient-adjacent content only to a model running in its own private cloud, while routing public marketing copy to a commercial provider. You make that call, and you can change it as the market evolves.

How Drupal keeps sensitive data out of AI prompts and processed responses

Can you stop sensitive information from reaching an external model in the first place? Yes. Drupal AI guardrails can inspect prompts before they leave your environment, masking personal information and blocking off-topic or malicious requests. Drupal AI guardrails can also check responses before they reach an editor or a field, testing for banned terms, brand voice issues, or malformed data.

AI assistance in Drupal can also be scoped to individual fields. With the Field Widget Actions module, an editor can generate a summary, alt text, or suggested tags for one field at a time, so AI helps with specific tasks instead of rewriting whole pages.

Most importantly, AI output can flow into the same moderation workflow as everything else. An AI-assisted change can land in a "Needs Human Review" state instead of going live, so a person stays in the loop.

How to prove who wrote AI-assisted content

Can you produce a complete record of every AI interaction if someone asks? Yes, and this is how Drupal answers the “who wrote that?” question. Drupal AI logging can capture each AI transaction as an auditable record: who triggered it, which provider and model handled it, the prompt, the response, token usage, and timing. Retention settings let compliance teams decide how long those records live.

For organizations with a security operations center, Drupal can also send AI telemetry through OpenTelemetry, easily set up using the AI Observability OpenTelemetry recipe, to the observability tools those teams already use. Drupal’s AI metering module helps teams set and enforce token budgets and catch runaway costs before they become a surprise.

Agents that follow the same rules as people

As AI agents start to take actions on their own, Drupal treats them like any other user, with clear boundaries. When an agent creates or edits content in Drupal, it goes through the same access checks and validation as a human editor. If it lacks permission, the action fails and the attempt is logged. The same principle applies as Drupal adopts the Model Context Protocol through the MCP module: external AI tools can interact with your site only within the permissions you grant.

Governance is what makes AI adoption possible

It is tempting to see governance as the brake on AI. We think it is the opposite. Teams that can prove what their AI did, and show that a person approved it, are the teams that will get permission to use AI more widely. Strong controls let you move with confidence.

That is the real promise of Drupal in this moment. It gives you the freedom to choose your models, infrastructure, and workflows without giving up the audit trail your organization depends on. And because it is open source, the governance layer is not a black box. It’s backed by the Drupal Security Team, and you can inspect it and adapt it to fit the way your teams work.

At Acquia, we help organizations put that foundation to work, from secure, compliant hosting to Acquia AI capabilities and guidance that help editorial teams adopt AI responsibly. To see where the work is heading, follow the Drupal AI Initiative.