AI-Edited WordPress Content and the EU AI Act: What an Audit Trail Actually Needs to Log
Most AI-edited WordPress content — blog posts, product copy, landing pages — falls under the EU AI Act’s , not the heavier Article 12/19 audit-trail rule: mark it as AI-generated, unless a human reviewed it under editorial responsibility. The audit-trail rule only bites if the content sits inside a regulated flow (hiring, credit, healthcare, legal). Either way, “what should an audit trail actually log” is a concrete engineering question, so we opened our own shipped answer to it: mumcp’s AI action log, live in production WordPress installs since June 7, 2026. It logs before/after snapshots on every write, supports rollback, exports to CSV, and prunes on a retention schedule. One gap we found in our own product while writing this: the default 90-day retention undershoots the Act’s actual six-month floor for genuinely high-risk systems.
Two different obligations get flattened into one scary phrase — “the EU AI Act requires an audit trail” — and most writing about it stays at that altitude, which doesn’t help anyone editing a WordPress site with an AI agent decide what to build or turn on. So this post does the opposite: it takes one real, shipped implementation — mumcp, the WordPress MCP plugin we build — and maps exactly what it logs, what it doesn’t, and where its own defaults fall short of the regulation’s letter.
We covered the abstract shape of agent governance and the August 2, 2026 deadline in Agent Governance and the EU AI Act. This post is the concrete case: one content-management system, one shipped audit-log feature, read straight from the code that runs it.
What does the EU AI Act require for AI-edited content?
Two separate articles apply, and they cover different content.
Article 50 — transparency for AI-generated content — is the one that reaches ordinary WordPress content. It requires that “the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated” for any generative AI system producing text, image, audio, or video (Article 50(2)). If an AI agent writes or substantially edits a blog post, a product page, or marketing copy, this is the rule in play. It applies broadly — there’s no “high-risk” gate on it — and it takes effect August 2, 2026, the same date as the rest of the Act’s main obligations.
There’s a real exemption, and it matters for anyone running an approval workflow: disclosure is not required for AI-generated text published to inform the public on matters of public interest “where the AI-generated content has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content” (Article 50(4)). That’s close to how mumcp’s approval workflow already runs — an agent proposes a page or post, a human approves it in the Control Room before it goes live. We won’t tell you that queue satisfies the exemption on its own; that’s a call for your counsel, not us. But “human review + a named responsible party” is exactly what an approval-first publishing flow produces as a byproduct, and it’s worth knowing the exemption exists before assuming every AI-touched paragraph needs a disclosure banner.
Article 12, Article 19, and Article 26 — the actual audit-trail-and-retention rules — apply only to “high-risk” AI systems under Annex III: hiring and worker management, credit and insurance eligibility, healthcare, legal services, education admissions, law enforcement, and a handful of other regulated categories. Most WordPress content editing is not one of these — a blog, a marketing page, or product descriptions edited by an AI agent isn’t automatically a high-risk AI system under the Act. But if the WordPress site is the delivery mechanism for one of those flows — a recruitment page tied to real candidate screening, a lending or insurance quote tool, health-triage content that itself performs the service — the AI system doing that work is high-risk, and the heavier rule applies to it specifically, not to the rest of the site.
Either way, “what does a real audit trail need to log” is worth answering concretely, because nobody selling WordPress AI tooling has actually shown their work on it. So here’s ours.
What does a compliant audit trail actually log?
mumcp shipped an AI action log on June 7, 2026 (v2.8.46 at the time, under the plugin’s prior name). We went back into our own codebase to verify it still works as documented rather than trust memory of what shipped a month ago.
It’s wired directly into the tool dispatcher. Every MCP tool call an AI agent makes against a connected WordPress site passes through one function; immediately before it executes, Mcpwp_Action_Log::begin() fires, and immediately after — success or failure — ::complete() fires. A failed edit gets logged with the same rigor as a successful one; there’s no path where a write attempt disappears because it errored.
Not every tool call is logged. The log only fires for write tools — anything whose name starts with a mutating prefix (wp_create_, wp_update_, wp_delete_, wp_set_, wp_edit_, wp_bulk_, wp_patch_, and a dozen similar prefixes). Read-only calls — listing posts, reading SEO data, checking site health — never touch the table. That’s a deliberate filter: a log that records every read call is unusable noise for a compliance reviewer trying to find the ten edits that actually changed something.
For every write call, the system captures a before snapshot immediately before dispatch and an after snapshot immediately on success. It knows how to snapshot exactly three resource shapes:
| Resource type | What gets captured |
|---|---|
| WordPress post/page | title, content, status, slug, excerpt, post type, featured image ID |
| Elementor page | the full _elementor_data layout JSON |
| WordPress option | the option’s raw stored value |
Each logged row carries: a unique log ID, a UTC timestamp, the tool name and category, the API key that made the call, the tool’s arguments (as JSON, with the API key itself stripped out before storage — so a credential never ends up sitting inside its own audit trail), the before/after snapshots, the affected resource’s type and ID, call duration, success/failure and error code, and whether the entry is rollback-eligible.
Rollback and retention — what “reversible” means in practice
“One-click rollback” doesn’t mean every action is reversible. Only twelve specific tools qualify: five that write posts and pages directly (wp_update_post, wp_update_page, wp_bulk_update_posts, wp_bulk_update_pages, wp_set_featured_image) and seven that write Elementor layouts (wp_set_elementor, wp_edit_section, wp_add_section, wp_remove_section, wp_edit_widget, wp_replace_section, wp_patch_elementor). Deleting a page, creating new content, or flipping a site option is fully logged — but there’s no undo button for it in this version. The log answers “what happened”; it doesn’t promise it can reverse everything that happened.
The rollback itself is self-auditing. Restoring an entry’s before-snapshot runs through the exact same begin()/complete() cycle, under the tool name mcpwp_rollback, and writes a new row that points back at the entry it reverted — then marks the original entry rolled_back = true. The question a compliance reviewer asks next — “was this touched again after the fact, and by what” — has its own answer inside the same table, not a separate note someone has to remember to write.
Four guardrails run before a rollback actually executes: entry not found, already rolled back, not rollback-eligible, or a missing/corrupt snapshot — each returns a distinct error rather than silently doing nothing.
Retention defaults to 90 days and is configurable from 1 to 3,650 days in WordPress admin, enforced by a daily cron job that hard-deletes rows past the cutoff. Here’s the finding worth being straight about: the plugin’s own settings page describes 90 days as “Required for EU AI Act compliance (minimum 90 days recommended).” That undersells the actual rule. For a genuinely high-risk AI system, Article 19 (providers) and Article 26 (deployers) both set the statutory floor at “a period appropriate to the intended purpose… of at least six months” — 180 days, not 90. If your WordPress AI editing sits inside an Annex III high-risk flow, the shipped default is half the legal floor; raising it is a config change, not a rebuild, but the default doesn’t self-correct and the help text overstates what it delivers out of the box. Naming our own product’s imprecise language here is the same discipline this post is arguing for.
One more honest gap: this is a plain relational log table, not a tamper-evident one. There’s no hash chain linking entries together and no cryptographic anchor proving a row hasn’t been altered after the fact — a database administrator could, in principle, edit or delete a row directly, and nothing in the table would prove it happened. That’s a materially different guarantee from the audit-chain design we run on our own multi-agent orchestration substrate, where every entry is SHA-256 hash-linked to the one before it and periodically Merkle-anchored with an RFC 3161 timestamp so that kind of edit is cryptographically detectable — documented in our Article 12 reference implementation paper. For a WordPress content log where the realistic question is “did the AI agent do this,” a straightforward table is proportionate. For a system that’s actually classified high-risk, where tamper-evidence is part of what Article 12 implies, it isn’t enough on its own yet.
Exporting for a compliance review
The log exports as CSV over a single REST call — up to 1,000 rows per request — with thirteen columns: log ID, timestamp, tool name, category, API key ID, resource type and ID, duration, success, error code, and rollback status (supported / executed / when).
What’s deliberately absent: the raw before/after content snapshots and the full tool arguments. Those stay in the underlying row, fetchable one entry at a time by ID, but don’t ride along in a bulk export. That’s a useful distinction for anyone building this: what a reviewer wants for a first pass is a manifest — what happened, when, to what, by which key, did it succeed, was it undone — not a spreadsheet full of page content. The detail stays one call away for entries that need a closer look.
Worth saying plainly: this isn’t a paid add-on. The action log runs on mumcp’s free tier — staging workflows, SEO automation, WooCommerce tooling, and third-party AI provider integrations are the paid features; logging what an agent did to your site isn’t one of them.
Where this leaves you
If someone asks whether your WordPress AI setup is ready for August 2, 2026: figure out which bucket the content is actually in first. Marketing copy and blog posts need a disclosure practice under Article 50, with real relief if you already run human review before publish. Content that’s genuinely part of a hiring, lending, healthcare, or legal decision needs the heavier logging-and-retention regime, meeting the six-month floor rather than a rounder number that sounds close. Either way, check what your tooling logs against what we just walked through — not against its own settings-page copy.
You can see the action log running today at mumcp.com, or read how to connect an AI client to WordPress through it.
Related
- Agent Governance and the EU AI Act
- Connect WordPress
- Multi-Tenant Audit Chain Compliance with EU AI Act Article 12: A Reference Implementation
Sources
- Article 50 — Transparency obligations for providers and deployers of certain AI systems
- Article 12 — Record-keeping
- Article 19 — Automatically generated logs
- Article 26 — Obligations of deployers of high-risk AI systems
- mumcp.com — product homepage, verified live 2026-07-08
- mumcp/wp-ai-operator codebase, verified directly against source 2026-07-08:
mcpwp/includes/core/class-mcpwp-action-log.php,mcpwp/includes/api/class-mcpwp-rest-action-log.php,mcpwp/includes/api/class-mcpwp-rest-mcp.php,mcpwp/includes/admin/class-mcpwp-settings.php,mcpwp/mcpwp.php,version.json; commitsc7914b3/a64f37f/5619358(feature ship, 2026-06-07),7dd8efd(spai/mumcp → MCPWP rebrand, v3.0.0),9199f78(WordPress.org compliance pass, no logic change to the action log)