AI Detector for Publishers: Triage, Not Verdict

An AI detector for publishers belongs at the triage step of your pipeline, not the verdict step. Use it to decide which submissions get a closer human read, set a threshold that triggers review rather than rejection, and write down why each decision was made. The score is a probability estimate, not proof of authorship.

Key takeaways

• A detector score is a screening signal. It tells you where to spend editorial attention, not who wrote the piece.
• Set two thresholds: one that triggers human review, one that triggers a request for the contributor’s drafting record. Automatic rejection on a score alone is indefensible.
• Non-native-English writers get flagged more often. Route those flags to a human who reads for meaning, not for statistics.
• Every decision needs a line in the file: date, tool, score, reviewer, reason, action. That record is what protects the contributor and you.
• Publish the policy before submissions open. A contributor who learns the rules after a rejection will not submit again.

The pressure to formalise this came from outside editorial. Platforms and publishers now have to answer questions about how machine-generated text entered their pages, and the honest answer is that most newsrooms still triage by gut feel. Gut feel does not survive a contributor dispute. A written process does.

Where does an AI detector actually belong in an editorial pipeline?

At the front door, before a human spends an hour on a piece that may need to be sent back. That is the whole job.

Picture a typical freelance submission flow: pitch, acceptance, draft, edit, fact-check, publish. The detector belongs between “draft arrives” and “editor reads closely”, as a sorting step. It answers one question: which pieces deserve a slow read first?

It does not belong at the publish gate as a final veto, and it does not belong in the rejection email as the stated reason. Both of those turn a screening tool into an accusation machine. Contributors talk to each other. A newsroom that rejects on a score alone develops a reputation within a season.

A workable triage rule looks like this:

1. Run the draft through detection at intake. Record the whole-document score and the sentence-level highlights.
2. If the score is low, the piece enters the normal edit queue. No flag, no note to the contributor.
3. If the score is borderline, the piece enters the normal queue but the editor reads it with the sentence highlights open.
4. If the score is high, the piece goes to a second reader before any decision is made.
5. Only after that second read does anyone contact the contributor.

The sentence-level view matters more than the headline number. A document can score high because three paragraphs read smoothly and uniformly, while the rest carries the writer’s fingerprints. Seeing which sentences carry the signal tells you whether you are looking at a machine-written piece or a human piece with a tidy middle section.

If you want to see which sentences in a submission carry the signal before you decide anything, run the draft through the DeAIze detector and read the highlights, not just the headline score. Plans and word credits are on the pricing page when you are ready to test it on real submissions.

How do you set thresholds that trigger review instead of rejection?

Two thresholds, one policy, no exceptions.

Score band	Pipeline action	Who decides	Record kept
Low	Normal edit queue	Assigned editor	Score and timestamp
Borderline	Normal queue, highlights open	Assigned editor	Score, highlights, editor note
High	Second reader before contact	Two editors	Score, both reads, decision, reason
Any band, contributor disputes	Full record pulled	Managing editor	Everything above plus correspondence

Automatic rejection should not exist as a category. There is no score at which a machine gets to end a contributor relationship without a person signing off. If your workflow cannot accommodate a second read, then your workflow is not ready to use detection at all.

Thresholds themselves are a judgment call, and they should be set by your team on your own archive, not borrowed from a vendor’s marketing page. Run detection across a set of pieces you know are human-written and a set you know were machine-generated, and see where the two groups actually land in your genre. Opinion columns and breaking-news copy will not sit in the same place as long-form features.

Our own measurement gives a sense of the spread. On 2026-09-19 we scored two corpora with the DeAIze detector at a 30% flag threshold. A human-written sample of 46 hand-written DeAIze guides had a mean AI score of 27% and a median of 25%, with a range from 0 to 55%. Unedited model output, 12 passages generated from fixed prompts with no editing, had a mean of 35% and a median of 34%, ranging from 25 to 49%. At that threshold, 17 of the 46 human-written pieces flagged.

Read that last number again. That is the whole reason a threshold triggers review and not rejection. A flag threshold that catches machine output also catches a meaningful share of human writing, and the human writing is the part you cannot afford to lose.

What does the false-positive problem look like in practice?

It looks like a contributor who has written for you for years, whose draft scores high, and whose only crime is writing in a second language.

Non-native-English writers are the group most exposed here. When someone writes in a language they learned later, they tend to reach for safe constructions: standard transitions, conventional sentence shapes, fewer idiosyncratic asides. Those habits overlap with what detection models read as machine-like. The result is a flag on a piece that is unmistakably that person’s work.

We have written about this at length in why an AI detector flags non native English writers, and the practical takeaway for editors is simple. A flag on a non-native writer’s draft is a prompt to read more carefully, never a prompt to send an accusation.

The same logic applies to any writer working in a house style that flattens individual rhythm. Wire copy, legal-adjacent explainers, and tightly templated reviews all produce prose that reads uniform. Uniformity is a detection signal. It is also sometimes just the job.

Three things reduce false-positive damage without weakening the process:

• Never name the score in the first conversation. Ask about the drafting process. Ask which sections came easily. Let the writer describe how the piece was made before you introduce a number.
• Read the sentence highlights yourself. If the flagged sentences are the ones doing the factual heavy lifting and the connective tissue reads like the writer, you are probably looking at a false positive.
• Keep a log of resolved false positives. When the same pattern shows up three times, adjust your threshold or your genre-specific rules. A static threshold across every section of the publication is a policy you will be defending forever.

How do you document a decision a contributor can actually read?

The record is not for you. It is for the contributor who asks why their piece was held, and for the editor who has to answer six months later when nobody remembers the details.

One row per decision, kept in the submission file:

Field	Example value
Date and time	Intake date
Tool and version	Detector name, tier, threshold used
Whole-document score	The number the tool reported
Sentence highlights	Which sentences carried the flag
First reader	Name, read completed yes/no
Second reader	Name, read completed yes/no
Decision	Accept, hold, request drafting record, decline
Reason	One or two sentences in plain language
Contributor contact	Date, method, summary

Two rules make this record useful rather than bureaucratic. First, the reason field must be readable by someone outside the newsroom. “Flagged at intake” is not a reason. “Three consecutive paragraphs read as uniform in rhythm and the piece lacks the source-specific detail typical of this contributor’s work” is a reason. Second, the record must be complete before the contributor is contacted. Writing the justification after the conversation means you are reverse-engineering an argument, and it shows.

If a contributor asks for the record, give it to them. Withholding it turns a process question into a trust question, and trust is the only thing that keeps a freelance bench together.

When should you tell contributors about the policy?

Before they submit. Not in the acceptance email, not after the first flag, and not buried in a style guide nobody opens.

A contributor-facing AI policy needs four things in plain language:

1. What you screen for. Say that submissions are screened for machine-generated text as one signal among several. Do not describe it as proof of anything.
2. What a flag means. A flag means the piece gets a second read. It does not mean rejection, and it does not mean an accusation.
3. What you may ask for. Drafting history, notes, earlier versions, or a short conversation about how the piece was made. Say this up front so the request is not a surprise.
4. What you will not do. You will not reject on a score alone, and you will not share scores with third parties.

Publishing that policy does two things at once. It filters out contributors who were planning to pass off machine output wholesale, and it reassures the contributors you actually want, who have nothing to hide and everything to lose from a process that feels arbitrary.

There is a related conversation worth having with regular contributors, and it is not about detection at all. It is about disclosure. If a writer used a model to draft a section, tidy a transition, or check a fact, that is a different situation from a model writing the piece. A disclosure line in the commissioning email handles it cleanly. We cover the contributor-side version of this in AI detection and freelance work, and the same logic applies to staff writers filing into the same system.

What does a detector score not tell you?

It does not tell you who wrote the piece. It does not tell you whether the facts are correct. It does not tell you whether the argument is any good. It does not tell you whether the writer used a model to check a spelling or to generate three thousand words of filler.

What it gives you is a probability estimate on a piece of text, produced by a model that has its own biases and its own blind spots. Two detectors will disagree on the same paragraph, and both will be reporting something real about the text. That is why the score belongs in a triage slot and not in a verdict slot.

Editors sometimes ask whether they should run two detectors and compare. It is a reasonable instinct and a poor use of time. If two tools disagree, you have learned that the text sits in an ambiguous zone, which is exactly what a borderline reading already told you. Spend the second read on a human instead. If you want to understand why tools diverge in the first place, how AI content detectors work covers the mechanics without the vendor spin.

One more limit worth naming. Detection is weakest on short text. A 200-word news brief does not carry enough signal for any tool to say much, and treating a flag on a brief as meaningful will generate false positives at a rate no newsroom can absorb. Keep detection to pieces long enough to have a rhythm.

A worked example

The following is an illustration, not a real submission.

A contributor files a 1,200-word explainer. Intake detection returns a high whole-document score, with the middle four paragraphs highlighted and the opening and closing reading clean.

The editor opens the highlights. The flagged paragraphs are the ones summarising a regulatory process, written in flat, evenly paced sentences with no source attribution and no specific examples. The opening and closing carry the writer’s usual habits: a short first sentence, a direct address to the reader, a closing line that references an earlier conversation.

The picture is not “the contributor used a model for the whole piece”. The picture is that the contributor likely pasted a summary from somewhere and built around it. The editor asks a specific question: can you walk me through how you put the middle section together? The contributor explains that they pulled the summary from a trade publication and rewrote it under deadline. The editor asks them to replace the summary with their own reporting or add attribution. The piece runs.

No accusation. No score quoted. One documented conversation. That is what triage looks like when it works.

Ready to see which sentences read machine-made?

Run a real submission through the DeAIze detector and look at the sentence-level highlights, not just the headline score. The whole-document number tells you a piece is worth a second look; the highlights tell you which paragraphs are actually carrying the signal, which is the part that makes a triage decision defensible.

When a flagged piece is the contributor’s own work and the problem is flat, uniform prose rather than authorship, the humanizer rewrites only the flagged sentences, checks that the meaning survived, and re-scores before and after. On the example paragraph on the site, a 92% AI score becomes 4%. The site reports an average AI-score reduction of 60%+ after humanizing, with a best case of 71%. Those are the product’s own predicted scores, not a third-party detector’s verdict, and they are not a guarantee on your text.

If you are testing this on a backlog, the free tier gives you 200 words on signup with no credit card, and credits never expire, so a trial run on one submission costs you nothing. When you are ready to put a real pipeline behind it, register here and start with the drafts sitting in your queue right now.