You publish texts written with AI and someone reviews them: a proofreader, a colleague, or you on a Sunday evening. Reviewing AI content is not like reviewing a human draft. Spelling mistakes are rare, the text flows, and that is exactly what lulls your attention. The errors are elsewhere: a figure that does not exist, advice that does not hold up, a voice that sounds like everyone else's.
I publish this blog with a content machine I built, and I review every article myself, on the live site, before it moves to "Reviewed". On one engagement I also worked with a proofreader whose feedback became written rules in the pipeline. Here is how I organise the work so that a reviewer spends their time on what no tool can see.
01What a reviewer catches in a generated text, and what they miss
A good reviewer quickly spots the habits of generated text: sentences all the same length, lists of three, opening lines that announce nothing, inflated adjectives. They can also tell when a paragraph says nothing, however well written it is.
What they miss is anything that requires looking beyond the text. Google's documentation on generative AI content puts it plainly: a model does not retrieve facts, it predicts a likely sequence of words. An invented source therefore looks just as serious as a real one. A reviewer who only reads the text will not catch it. You have to open the link.
They also struggle to see what is missing. An article can be correct and empty, with no lived example and no honest limit. Spotting an absence means knowing what the article should have contained, so the brief needs to be on the desk.
02What Google and the AI Act expect from human review
On Google's side, the guidance fits in one sentence: check the accuracy and reliability of all generated content by hand before publishing it. The same page adds a detail many people forget. The check also covers metadata, meaning the title tag, the meta description, structured data and image alt text. These are the texts nobody rereads, and the ones that show up in search results.
Google's page on helpful, reliable content asks three questions: who created the content, how, and why. For substantially automated content, it suggests explaining to readers how AI was used. So I say it openly: the articles on this blog are written with my content machine, then reviewed.
Article 50 of the EU AI Act goes further for one specific case: texts published to inform the public on matters of public interest. It requires disclosure that they were generated by AI, unless they have undergone human review or editorial control and someone holds editorial responsibility for them. The word I keep is "responsibility". A review that changes nothing and that nobody signs off hardly looks like editorial control. I am not a lawyer, and a B2B blog post may well fall outside that case. If I had a real doubt, I would ask one.
03Review in four passes rather than one
Reading once while looking for everything means missing half of it. I suggest splitting the review into four passes, each with a single question. It looks longer on paper and is shorter in practice, because nobody goes back over the same paragraph three times.
1. The facts
Every figure, every name, every quotation: where does it come from? The reviewer opens the source and checks that it says what the text claims. Anthropic's documentation on hallucinations suggests a rule I apply as it stands: a claim without a supporting quote is withdrawn. It also points out that these techniques reduce errors without eliminating them. I go into this at more length in the article on checking the sources of AI content.
2. Meaning and angle
Does the article keep its promise? Is the advice sound, and honest about its limits? Is there a lived example, or only generalities? This is the pass where the brief earns its keep: you compare what was planned with what was written.
3. Voice
Does it sound like the person whose name is on it? My test: is this a sentence you would say out loud to a client in a meeting? If not, it gets rewritten. In his video for Semrush, Brian Dean makes the same point about the sites he studied: a line such as "reviewed by a specialist" is not enough if the text reads like a generic article. The experience has to show in the text itself.
4. Metadata and the published page
Title, description, alt text, FAQ: reviewed like everything else. Then the live page, viewed as a visitor would see it, because a CMS can show the right content in its form while the public page is broken.
04Keep a corrections log
A correction made in the text disappears with it. The day the same mistake comes back, nobody remembers it. So I suggest the reviewer notes their corrections separately, in a short format:
``` Text: article title or number Before: the sentence as it was After: the corrected sentence Type: fact, meaning, voice, form, metadata Frequency: first time, or seen before ```
The frequency column is the one that matters. A mistake seen once gets fixed. A mistake seen three times points to a flaw in the machine, not in the text. That is the logic I applied to the proofreader's feedback: rather than carrying it over by hand, text after text, I wrote it up as rules in the pipeline. A remark made once never has to be made again, and her attention can go to what no rule can see.
05Sort each correction: rule, guideline or judgement
Every recurring correction goes to one of three places. The sort is easy to do, and it is what makes the machine improve.
- An automatic rule, when the mistake is visible in the text without any thinking. The em dash, stock closing formulas, hollow invitations to get in touch: in my configuration these are red and block publication. Inflated adjectives are orange, and turn red beyond two occurrences. The English version has its own lists.
- A written guideline, when the mistake depends on context. "No figure without a source in the same paragraph" is partly detected by the tool, but the full rule lives in the references the model reads before writing: the voice, the usable facts, the sources. I explain how that is built in the article on my article-writing prompt.
- Judgement, when no rule holds. Is an example credible? Is a piece of advice right for this reader? These corrections stay with the reviewer, and that is where their time should go.
Two precautions. The rules live in the tool's configuration, not in the prompt: a rule repeated in a prompt gets forgotten, a rule in the config blocks. And deliberately bad test articles must always come out red, because when you change the rules you can weaken the check without noticing. I described the whole set-up in the article on the content machine and human review.
06The limits of human review
A reviewer is not a fact-checker by default. Without the time or access to the sources, they will fix the form and let the error that matters slip through. Tell them clearly which pass is theirs.
Banned-word lists have their own side effect. Take one adjective away from a model and it reaches for its neighbour, and a new habit appears. That is why the log never stops: the rules follow the mistakes, they do not exhaust them.
Finally, review cannot rescue a text written with nothing to say. If the model had no lived material to work with, the reviewer can smooth the form but cannot invent the substance. In that case I would rather not publish. In my machine, an article that cannot pass honestly is abandoned with a note, and the topic goes back to "to do".
07Where to start with your reviewer
On Monday, take the last three reviewed texts and ask the reviewer to rebuild their corrections in the log. You will soon see the ones that keep coming back. Sort them into rule, guideline or judgement, and start by automating the two or three most frequent: often that is a word list and a link check.
Then separate the passes. If one person reviews, have them do the facts first and the voice afterwards. If there are two of you, give the facts to whoever knows the subject.
The aim is simple: your reviewer should never fix the same thing twice. If you want to set up this kind of chain, with its machine and its checks, my services describe what I do, and the portfolio shows where I have built it before. Happy to talk it through.