How WordPress Builds AI — and How I’d Use It

WordPress’s AI infrastructure

WordPress put the plumbing in core and kept the products separate. The Abilities API (6.9) is a registry making WordPress functions discoverable; the AI Client (7.0) standardizes talking to AI providers. Neither is user-facing on its own. The actual features — alt text, comment moderation, content resizing — live in a separate, opt-in plugin, much of it explicitly experimental. Stable substrate in core; risky features quarantined where they can break safely.

What AI Leaders taught me, showing up here

Three connections.

• Human-in-the-loop: the connector-approval gate means AI can’t silently use stored keys — an admin has to approve access.
• Ethics operationalization: they build the principles into the architecture instead of writing them into a policy doc. The clearest example is request logging — every AI request gets recorded, so an admin can see exactly what fired, which provider ran it, and how it performed. Transparency becomes a feature you can inspect, not a promise.
• Context-dependent risk posture: they shipped an admittedly incomplete security control to gather real feedback — a bolder bet than “perfect the safety layer first,” and arguably right for infrastructure running 43% of the web.

My philosophy

Learner-centered adoption, gated by security and privacy. AI earns its place when it serves the user and stays under human control — not because it’s novel.

My concrete example: comment moderation. I’d let the AI flag sentiment and toxicity, but with two non-negotiables — transparency (the logging shows what fired and why) and a human making the final publish/reject call. AI proposes, human disposes. That keeps community conversations healthy without handing judgment to a model — the human-in-the-loop pattern in practice.

AI proposes, human disposes.