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

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.

Principles built into the architecture

Human-in-the-loop. The connector-approval gate means AI can’t silently use stored keys — an admin has to approve access.

Ethics, operationalized. Principles are built into the architecture instead of written into a policy doc. Request logging records every AI request, 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 is comment moderation: I’d let the AI flag sentiment and toxicity, but with two non-negotiables — transparency (logging shows what fired and why) and a human making the final publish/reject call.

AI proposes, human disposes.