AI Act and AI-Written Blogs: What Your Company Must Do

Here is the situation most marketing teams are actually in. The blog publishes two or three posts a week. The drafts come out of an AI writing tool. Someone skims them, fixes the worst sentences, hits publish. Nowhere on the page does it say a machine wrote the first version. Nothing in the page’s structured data carries that information either. And if you asked, six months later, who approved the post about pricing that a customer is now quoting back at you, nobody could answer with certainty.

For years that was sloppy but harmless. In 2026 it is a compliance gap. The EU AI Act brings transparency duties for content generated or manipulated by AI, and those duties land on the company that publishes, not only on the company that built the model. Most businesses discover this late, usually when a procurement questionnaire, an enterprise customer or a public tender asks how AI-generated content is labelled and governed, and the honest answer is “it isn’t”.

This article explains what the AI Act means for a company blog, in plain terms: who it applies to, what disclosure and machine-readable marking actually mean for a published article, what tracked approvals look like in a real editorial workflow, and where the common AI writing setups leave gaps. It is general guidance, not legal advice — the specific application to your business should be confirmed with your own counsel.

Who the AI Act applies to when you publish AI-written articles

The regulation splits responsibilities between those who build and supply AI systems and those who use them in their own activity. The first group — the model and system makers — carries the heavy obligations: risk management, technical documentation, marking outputs at the source. The second group uses an AI system under its own authority, for its own purposes. A company running its blog with an AI writing tool sits firmly in the second group.

That distinction matters more than it looks. Companies assume that because they bought a tool, the tool’s vendor carries the compliance. Partly true, and only for the vendor’s half. The obligations attached to use — telling your audience when they are reading synthetic content, keeping your own house in order about who signed off — stay with you. You cannot outsource the fact that you published.

Why “we only edit the drafts” changes less than you think

The most common objection: our writers rewrite everything, so it is human content. Sometimes that is true. Often it is a story people tell themselves about a fifteen-minute pass over a 1,500-word draft. The useful question is not philosophical but evidentiary: if someone asked you to demonstrate how much of this article was machine-generated and who reviewed it, could you? If the answer is a shrug, the safe posture is to disclose and to keep the record. Disclosure costs nothing in credibility when it is normal and consistent. Getting caught without it costs a lot.

There is a second reason to disclose that has nothing to do with law. Readers increasingly assume AI involvement anyway. A clear, matter-of-fact note that says a system drafted the text and a named person reviewed it reads as confidence. Silence reads as hiding.

The obligations that touch text content, in order of relevance

For a company blog, three things matter. First, transparency toward the reader: the audience should be able to know that the content they are consuming is artificially generated. Second, machine-readable marking: the signal should also exist in a form that systems, not just humans, can detect — metadata and structured data rather than a sentence at the bottom of the page. Third, internal accountability: the ability to show who approved what and when, which is what turns a claim of human oversight into something you can actually evidence.

Everything else in the regulation — the heavy documentation, the conformity assessments, the high-risk categories — concerns uses far from marketing content. Your blog is not a high-risk system. It is a transparency case. That is genuinely good news: the work is bounded and mostly mechanical.

Practical takeaway: assume you are a deployer, assume disclosure applies to your published articles, and stop treating the question as something the tool vendor handles for you.

What disclosure and machine-readable marking mean on a real page

Disclosure is a plain sentence a human reads. Machine-readable marking is data a parser reads. They are two different deliverables and satisfying one does not satisfy the other. Most teams that do anything at all do only the first, and usually in the weakest possible form: a grey line in the footer that appears on every page of the site regardless of how the content was made.

The transparency note: where it goes and what it says

A transparency note is a short statement attached to the article itself, not to the site. It should say, without euphemism, that the text was produced with the assistance of an artificial intelligence system, and that it was reviewed before publication by a person. Naming the reviewer or the responsible editorial role strengthens it considerably. Placing it near the article — top or bottom, consistently, on the pages it actually applies to — is what makes it a disclosure rather than boilerplate.

Vague language defeats the purpose. “This site may use technology to assist content production” tells the reader nothing. “This article was drafted by an AI system and reviewed by our editorial team before publication” tells them exactly what happened. Write the version you would be comfortable having read aloud.

The machine-readable side: marking that travels with the content

The second half is the one almost nobody does. The information needs to exist in a form that automated systems can pick up: structured data on the page describing the article and its production, metadata fields carried by the content management system, markers that survive when the article is syndicated, scraped or ingested by a search or answer engine.

This is where the “watermark” language in the debate around synthetic content comes from. For images and audio the mechanisms are embedded signals in the file. For text, the practical equivalent is the page’s own data layer: schema describing the content, custom fields recording generation and approval, a consistent property that a crawler can read without parsing your prose.

If you already invest in structured markup for search visibility, you have the habit and the plumbing. The same discipline that makes an article eligible for rich results and quotable by answer engines is the discipline that carries a compliance marker. Our guide to FAQ schema markup and structured data covers the mechanics of putting machine-readable information on a page; the marking case is the same technique pointed at a different goal.

What “good enough” looks like in practice

A published article that is in reasonable shape carries four things: a human-readable note stating AI assistance and human review, structured data on the page reflecting the same fact, a stored record of which system produced the draft and when, and a stored record of who approved it. Nothing exotic. The difficulty is never any single item — it is doing all four on every post, forever, without someone remembering to.

Practical takeaway: audit one recent post right now. Read the page, then read its source data. If the fact of AI assistance appears in the first and not in the second, you have half a disclosure.

The gap most AI writing tools leave open

Here is the structural problem. The market for AI content tools optimises for the part that demos well: you type a topic, a good-looking draft appears. What happens between “draft” and “live on the site with the right markers and a recorded approval” is where the tools stop and the exposure begins.

Draft generators hand you the liability with the text

A tool that produces text in a browser window and lets you copy it out has, by design, no idea what you do next. It cannot mark the published page because it never touches the published page. It cannot record an approval because no approval happened inside it. Every compliance artefact becomes manual work for someone in your team, and manual work that must repeat on every article is work that degrades. It survives three weeks of good intentions and then quietly stops.

The failure is not that these tools are bad at writing. Many write well. The failure is that the compliance surface of AI-generated content is at the publishing step, and they are not present at the publishing step.

Tools built outside the EU rarely model your obligations

A second gap is jurisdictional. A large share of AI writing products are built for a market where no equivalent transparency duty exists. Their data model has no field for “who approved this”, no concept of a transparency note that must be attached at publish time, no setting that writes a marking into the page. It is not negligence on their part — they built for their own regulatory environment.

The consequence for a European business is that adopting such a tool silently transfers the entire obligation to you, and gives you no mechanism to discharge it. You end up rebuilding disclosure by hand on top of a system designed to move fast and not look back. For a small blog that is annoying. For an agency running twenty client blogs it is unmanageable, and it is the client who is exposed.

Why the exposure grows with volume

A blog that publishes seriously — and owning a topic means at least three articles a week, closer to one a day on broad themes — produces a lot of surface area. Three a week is roughly a hundred and fifty articles a year. Every one of them is a page that either carries the right markers or does not. If your process depends on a person remembering, you are betting that the person remembers a hundred and fifty times.

This is precisely why compliance has to be a property of the pipeline rather than a task in someone’s checklist. The pipeline does it identically at article one and article one hundred and fifty. A person does not.

Practical takeaway: judge your content tooling by what it does at the moment of publishing, not by the quality of the draft it shows you in the demo.

Tracked approvals: the part that turns oversight into evidence

“Human oversight” is easy to claim and hard to prove. Tracked approvals are what make the claim checkable. The concept is simple: every article has a recorded state, a named person who moved it from review to published, and a timestamp. Nothing about it is specific to AI — editorial teams have worked this way for decades — but AI-assisted production makes it load-bearing.

What gets recorded, and why each field matters

The minimum useful record is which system generated the draft, when, on what prompt or brief, who reviewed it, what they changed, and when it went live. The generation side answers “what produced this”. The review side answers “who is accountable”. The timestamp answers “in what order did this happen”, which is the question that actually gets asked when something goes wrong months later.

The change record matters more than people expect. It is the difference between a reviewer who read the article and a reviewer who clicked approve. If a piece goes out with a factual error, the useful forensic question is whether the reviewer saw the sentence. A diff answers that. A checkbox does not.

Approval belongs inside the publishing system

Approvals kept in a spreadsheet, a chat thread or somebody’s memory decay immediately. The record has to live where the content lives, attached to the article, surviving staff turnover and CMS migrations. If the person who approved the article leaves the company, the record should still say their name.

This is also the moment where the compliance case and the quality case converge. A workflow where a named person must approve before anything goes live is the same workflow that stops a bad draft reaching the public. You are not adding bureaucracy to satisfy a regulation — you are adding the editorial control that a serious blog should have had anyway. Automated publishing with human review is simply how a company blog is run in 2026: a system that writes, illustrates and schedules, and a person who says yes.

Scaling approvals without turning them into a bottleneck

The objection is obvious: if we publish three or five times a week, approvals become a queue. They do, unless the review surface is designed well. Reviewers need the article, the changes, and a single action — approve, or send back with a note. What kills approval workflows is making the reviewer hunt for context across three systems.

A well-designed queue lets an editor clear a week of content in one sitting. Batch the review, keep the record automatic, and the overhead per article drops to a couple of minutes. The cost of a missed approval is far higher than the cost of the approval itself.

Practical takeaway: pick one article published last month and try to reconstruct its approval trail. How long that takes tells you exactly how much of a system you have.

A checklist you can run against your current setup

Before the table, the framing: the goal is to find where a step depends on a person remembering, because that is where the process will fail once volume rises. Read each row as a question about your pipeline, not about your intentions.

Element	What good looks like	Common failure
Reader-facing note	Clear sentence on the article stating AI assistance and human review	Generic site-wide footer line
Machine-readable marking	Structured data and CMS fields carrying the same fact	Prose disclosure only, invisible to parsers
Generation record	System, date and brief stored with the article	Nothing stored outside the drafting tool
Approval record	Named reviewer, timestamp, changes made	Verbal or chat-based sign-off
Consistency	Applied automatically to every post	Applied when someone remembers
Ownership	A named person accountable for the policy	“Marketing handles it”
Vendor fit	Tool acts at publish time, in your CMS	Tool stops at the draft

Most teams score well on the first row and badly on everything after it. That is the honest starting point for nearly every company blog running on AI assistance today, and it is fixable in an afternoon of configuration if the underlying system supports it — and never, if it does not.

Building the compliance into the way you publish

The teams that handle this well share one trait: they stopped treating transparency as an editorial afterthought and made it a property of the publishing mechanism. The article cannot go live without the note. The structured data is written by the same process that writes the post. The approval is the action that triggers publication, so it cannot be skipped without the article simply not appearing.

Start from the publishing step, not from the drafting step

Reorganise the question. Instead of asking “which AI writer should we use”, ask “what does our publishing step guarantee”. If the answer is “it guarantees the post appears on the site”, that is one guarantee and it is the easy one. You want a publishing step that also guarantees marking, disclosure and a recorded approval — because those are the three things that are impossible to reconstruct afterwards.

This reframing also solves the vendor evaluation problem. Any tool can show you a nice draft. Few can show you the published page with the markers in place and the approval logged. Ask for that demo. Our WordPress auto-publishing evaluation checklist goes through what to inspect on the publishing side before committing.

Write the policy once, then let the system enforce it

A one-page internal policy is worth writing: what you disclose, where, who approves, what you keep, for how long. It takes an hour. Its real value is that it makes the rule explicit enough to be automated — a policy nobody can state precisely cannot be enforced by a machine, and a policy enforced only by people will drift.

Keep it short and concrete. Which content types are covered. What the transparency note says, verbatim. Who the named approvers are. Where the records live. Review it when your tooling changes, and have counsel confirm it fits your sector, because some industries carry additional communication duties on top of the general ones.

Transparency as a visibility asset, not a tax

There is a strategic argument that deserves more attention than it gets. Structured, explicit, well-marked content is exactly what answer engines and AI search systems prefer to cite. Clear authorship, explicit production information, consistent schema — these make a page easier to trust and easier to quote. The work you do for the AI Act overlaps substantially with the work you do to be cited by AI systems.

That overlap is why treating disclosure as a burden is a mistake. Companies that mark their content properly end up with cleaner, more machine-legible pages than competitors who publish silently. If your wider goal is being quoted in generated answers, our explainer on getting cited by AI search shows how the same structural signals do double duty.

Practical takeaway: write the policy this week, then check whether your current stack can enforce it without human memory. If it cannot, that is your real finding.

What to do in the next thirty days

Pick three recent articles and check them against the table above, reading both the page and its source data. Write the one-page policy. Then test whether your publishing pipeline can apply the note, the marking and the approval record automatically on the next post, without anyone doing anything manually. If any of the three requires a human to remember, you have identified the thing to fix.

Do not wait for perfect certainty about the regulation’s finer points before acting. The disclosure-and-record baseline is stable, cheap and defensible regardless of how the details settle, and it is far easier to apply going forward than to retrofit across hundreds of archived posts. Confirm the specifics with your legal advisor; build the habit now.

Frequently asked questions

Does the AI Act require me to label AI-written blog posts?

The regulation introduces transparency duties for artificially generated content, meaning your audience should be able to know they are reading machine-produced text, and the information should also exist in machine-readable form. For a company blog this translates to a clear note on the article plus structured data carrying the same fact. Confirm the precise application to your sector with legal counsel.

Am I a provider or a deployer under the AI Act?

A company that uses an existing AI writing system to produce its own content is normally a deployer, not a provider. Providers build and supply the system and carry the heavier technical obligations. Deployers carry the use-side duties, transparency toward their audience among them. Buying a tool does not transfer your deployer obligations to the vendor.

Is a footer line saying “this site uses AI” enough?

It is weak. A site-wide footer appears on pages where AI was never involved and says nothing specific about the article being read. A useful disclosure sits with the article, states that the text was drafted by an AI system and reviewed by a person, and is mirrored in the page’s structured data so automated systems can detect it too.

What does machine-readable marking mean for text?

For images and audio it means signals embedded in the file. For text published on the web, the practical equivalent is the page’s data layer: structured markup describing the article and its production, plus content management fields recording the generating system and the approval. The goal is that a crawler can establish the fact without parsing your sentences.

Do heavily edited AI drafts still need disclosure?

If a meaningful part of the published text originated from an AI system, the safe posture is to disclose and keep the record. Drawing a line at “how much editing makes it human” is subjective and hard to evidence later. Consistent disclosure costs nothing in reader trust and removes the need to defend a judgement call case by case.

What risks do EU businesses run with AI writing tools built abroad?

Tools designed for markets without equivalent transparency duties usually have no field for approvals, no transparency note attached at publish time, and no way to write a marking into the page. The obligation stays with you while the mechanism to discharge it does not exist, so every compliance artefact becomes manual work that degrades as publishing volume rises.

How do I prove human oversight if someone asks?

With records, not assurances. Store which system generated the draft and when, the brief behind it, the named reviewer, the changes they made, and the publication timestamp, attached to the article inside your publishing system. A diff showing what the reviewer changed is far stronger evidence than a checkbox confirming they approved it.

The strategic point

Transparency obligations around AI-generated content are not a reason to publish less; they are a reason to publish through a system rather than through improvisation. The companies that will find this easy in a year are the ones that made marking, disclosure and approval automatic properties of their publishing step, so that compliance scales at the same rate as output instead of breaking the moment the blog gets serious. If you want to see how a publishing pipeline with transparency built in actually works, read why we built RankGrove this way.

This article was produced and published automatically with the help of artificial intelligence.