WordPress shipped an AI plugin. It’s good. It’s also a starting point — and if you’re a publisher, the starting point is exactly where the interesting work begins.
This is a field report on building an enterprise governance layer for the WordPress AI plugin — what we learned about the plugin’s architecture, what we changed, what we left alone, and why other teams should do the same kind of extension instead of forking. If you run a publication on WordPress and you’ve been eyeing AI features with a mix of “we need this” and “we cannot let this go sideways,” this is for you.
What the WordPress AI plugin gives you for free
Install the plugin, activate it, and your editors get a small bundle of AI capabilities directly inside the editor:
- Title generation
- Excerpt generation
- Meta description writing
- Content summarization
- Content classification (auto-tagging, basically)
- Content resizing (rewrite shorter or longer)
- Image alt-text generation
- Comment moderation analysis
- Editorial notes and updates suggestions
- Image generation
For a small publisher, that’s a lot of value out of the box. It’s also free, GPL-licensed, and maintained by people inside Automattic and the broader WordPress community.
The deeper architectural choice is what makes the plugin actually interesting. Under the hood, every one of those features is built on top of two abstractions:
- The WordPress Abilities API, a recent core-adjacent project that gives WordPress a structured concept of “things AI can do, that you can call with parameters and check permissions on.”
- The WordPress AI Client SDK, a PHP library that talks to different model providers (OpenAI, Anthropic, Google Gemini, etc.) behind a single interface.
Sitting between the two is the plugin’s experiment framework — a registration system where each AI feature is just a small class that says “I do X, here’s my prompt, here’s who can use me, here’s what I need to be enabled.”
That last detail is the one that matters most. The plugin was built so that other plugins can extend it. Not as a fork-and-modify proposition, but as a publish-your-own-plugin-that-hooks-in proposition.
Why “out of the box” isn’t enough for a real publisher
Here’s the problem that surfaces about ten minutes after a real editorial team installs it.
The default title generation prompt is something like “Generate a compelling title for this article.” That’s fine for a blog. It is not fine for the New York Post, where titles need to be punchy and tabloid. It is also not fine for The Economist, where titles need to be measured and informative. It is especially not fine for a regulated publisher in finance or healthcare, where titles can’t make claims the body doesn’t substantiate.
This is the gap between “AI capability” and “AI capability that fits your brand and survives a lawyer’s read.”
A real publisher has a much longer wish list than a default prompt can satisfy:
- “Don’t say ‘shocking’ or ‘unbelievable’ in titles.”
- “Never reference our three biggest competitors by name in summaries.”
- “All meta descriptions must end with our brand tagline.”
- “Editorial team can generate titles; staff writers cannot.”
- “If we spend more than $500 on AI calls this month, stop.”
- “Strip PII from any content sent to a model — we have a compliance team.”
- “We can’t use OpenAI; everything goes through our Azure deployment.”
- “We need an audit log of every AI call, who made it, and what came back.”
None of that is unreasonable. All of it is necessary at scale. None of it is in the box.
Two paths: fork or extend
When you hit that gap, you have two technical paths. They look superficially similar and they are wildly different in practice.
Path one: fork the plugin. Clone WordPress/ai into your own repo. Edit the source. Change the prompts. Add your governance code directly inside the plugin classes. Now you have full control.
This is what teams do when they’re new to WordPress, or when they don’t know that path two exists. It looks fast for two weeks. Then the upstream plugin ships v1.1, and you have to merge. Then v1.2 lands, and the merge has conflicts. Then a security patch comes out, and now you have to backport it into your fork because the upstream version diverged. After a year, your fork is its own product. After two years, it’s a maintenance burden you can’t get out of.
Path two: extend the plugin via its hooks. Don’t touch a single line of the WordPress AI plugin’s code. Write your own plugin alongside it. Have your plugin subscribe to the dozens of documented filters and actions WordPress AI exposes. When the upstream plugin releases, you update it like any other plugin and your governance layer keeps running.
The second path is the well-trodden one in the WordPress ecosystem. It’s how Yoast SEO extends WordPress core. It’s how dozens of WooCommerce extensions work. It’s how ACF integrates with everything. You can do the same with the WordPress AI plugin because the WordPress AI plugin was designed for it.
What the extension surface actually looks like
The plugin exposes its integration points as ordinary WordPress filters and actions. A few of the most useful:
wpai_system_instruction— the prompt itself, passed through a filter before being sent to the model. You can prepend, append, or replace it. You also get the ability name and the call data, so you can apply different rules to different features.wpai_pre_normalize_content— the input content, before any sanitization. This is where you redact PII or strip internal identifiers.wpai_preferred_text_models,wpai_preferred_image_models,wpai_preferred_vision_models— the model selection lists. Return a filtered array and you’ve locked your site to specific providers.wpai_feature_{feature_id}_enabled— per-feature kill switches. Combine these with role checks and you have per-role AI access.wpai_has_ai_credentials— credential resolution. Hand it off to your secrets manager.wpai_request_log_retention_days— how long to keep AI request logs. Set it to your compliance requirement.
There’s also a deeper hook into the AI Client SDK itself: AiClient::defaultRegistry()->setHttpTransporter(). The plugin’s logging experiment uses it. So can yours. You can wrap every HTTP request to every provider with your own decorator and emit your own events — perfect for cost tracking, rate limiting at the transport layer, or full audit logging.
What we built on top
Working through that surface, we put together a small companion plugin — Extend AI Enterprise — that turns the WordPress AI plugin into something a real publisher can deploy without losing sleep.
The pieces, in plain terms:
Per-ability prompt control. A small React admin app lists every AI feature your site has. Click any one and you can override its prompt — prepend a house style guide, append a compliance footer, or replace the whole thing. Templates support variables: {site_name}, {user_role}, {post_title}, {current_date}, anything else passed by the ability. Every edit is logged, with who edited what and when. You get a brand-voice editor and an audit trail for free.
Model allowlist. Decide centrally which provider/model pairs are approved. The plugin can only use what’s on the list. If your compliance team says “Azure GPT-4o only,” that’s one row in a table.
PII redaction. Pattern-based stripping of emails, phone numbers, SSNs, anything else you can write a regex for — applied before any content leaves your server.
Role-based access. Per-ability, per-role gating. Editors can use everything; contributors can use only safe features. Or build whatever matrix your editorial workflow needs.
Rate limits and cost caps. Per-user, per-minute, per-day request quotas at the REST layer (so you never spend on rejected requests). A monthly USD spend cap that automatically disables AI features for a user who exceeds it.
Audit logging and retention. Every AI call captured in a custom table — user, ability, provider, model, tokens, duration, cost. Configurable retention so your data lawyers stay happy.
Drift detection. Because we don’t fork, we depend on the upstream plugin keeping its hook contracts stable. A nightly GitHub Actions job runs a suite of contract tests against the WordPress AI plugin’s development branch, so if a filter gets renamed or a signature changes upstream, we know about it before it ships to production.
Total scope: about 20 PHP files, one React app, a custom table, and a CI workflow. The repo is public at github.com/alansmodic/extend-ai-enterprise if you want to read or fork it.
How you can do the same
If you run a publication on WordPress and you want to do this yourself, the path is shorter than you’d expect.
Start with the question, not the code. What does your editorial team actually need from AI features? Brand voice in titles? A no-fly list of phrases? Compliance review of every output? Cost controls? Write the list. The list maps almost one-to-one to plugin features you’ll build.
Read the WordPress AI plugin’s source. Specifically the abilities (includes/Abilities/*) and the experiments framework (includes/Experiments/*). You’ll see exactly which filters fire where. The plugin is well-documented, and the team behind it is responsive to questions.
Build a sibling plugin, not a fork. Create a new plugin in wp-content/plugins/yourname-ai-governance/. It declares the WordPress AI plugin as a required dependency. It hooks the filters you care about. Nothing more. When upstream ships an update, you update it. Your code keeps running.
Add contract tests. This is the part most teams skip and then regret. Write small PHPUnit tests that assert “the filter we hook still exists with the signature we expect.” Run them on a schedule against the upstream’s main branch. When upstream breaks your contract, you find out from CI, not from a production incident.
Be ready to push back upstream. If a filter you depend on gets removed, open an issue. If the signature changes in a backward-incompatible way, ask why. The WordPress AI plugin is being built in the open, and downstream consumers’ voices count.
Why this matters beyond AI
The pattern here isn’t specific to AI. It’s the WordPress extension pattern, applied to a new domain.
For thirty-some years, the WordPress ecosystem has been built on the same architectural bet: plugins should extend core through documented hooks, not by modifying it. That bet is why Yoast SEO has shipped through every WordPress release without merging. It’s why WooCommerce extensions outnumber the people who could possibly review them. It’s why ACF, BuddyPress, and Polylang have survived as long as they have.
AI is just the latest domain where that pattern applies. The WordPress AI plugin is good not because it has good defaults — though it does — but because it has a stable, documented extension surface that other plugins can build on. That’s what makes it a foundation instead of a destination.
If you’re a publisher looking at AI on WordPress, the right mental model isn’t “should we use this plugin or build our own?” It’s “this plugin is the foundation; what do we build on top?”
The answer to that second question is where your competitive advantage lives. Your house voice, your compliance posture, your editorial workflow, your relationship with your providers — those aren’t things a generic plugin can capture, and they aren’t things you want a generic plugin to dictate. They’re yours, and the hook surface is there to let you express them.
Build the small companion plugin. Subscribe to the filters. Test the contracts. Ship.
That’s the whole playbook.
The full source for the governance layer described here is at github.com/alansmodic/extend-ai-enterprise. The WordPress AI plugin itself lives at github.com/WordPress/ai.