AI Detector API Workflow: Signals, Not Gates

An AI detector API workflow treats a detector score as one input among several, never as an automatic block. You set thresholds that route content to a human review queue, log every decision with the evidence behind it, and keep a record you can explain to a user months later.

Key takeaways

• A binary gate on a detector score fails at scale because detector output is a probability estimate, not proof of authorship.
• Set thresholds by review capacity, not by an imagined accuracy figure. Two thresholds (auto-pass, human review) beat one.
• Log the score, the model version, the threshold in force, and the reviewer’s decision. Without that, you cannot explain a flag later.
• Sentence-level scores tell you which lines carry the signal. Whole-document scores tell you almost nothing actionable.
• Detection can tell you a text resembles model output. It cannot tell you who wrote it, or whether the ideas are original.

Why does a hard gate on a detector score break at scale?

Because a gate turns a probability into a verdict, and verdicts get appealed.

Run any detector across a large enough corpus and some human writing lands above your cutoff. We measured this ourselves. On 2026-09-19 we scored 46 hand-written DeAIze guides with our own detector, local ensemble, lite tier, at a 30% flag threshold. The mean AI score was 27%, the median 25%, and the range ran from 0 to 55%. At that threshold, 17 of the 46 human-written documents were flagged.

Read that again. More than a third of documents we know are human-written crossed a 30% line. That is our instrument, on our own writing, and it still produces borderline readings. Any competitor’s detector will behave the same way, because every one of them is estimating a probability from stylistic signals.

A gate converts that estimate into a user-facing punishment: a blocked submission, a failed upload, a support ticket. You inherit the argument about whether the score was right, and you have no evidence to answer with unless you built the logging first.

The alternative is to treat detection the way you treat a fraud signal on a payments platform. It contributes to a decision. It does not make one.

What can detection actually tell you about a piece of text?

Less than most integration briefs assume, and it is worth being precise about the boundary before you write any code.

What it can tell you:

• That a passage’s statistical texture resembles the output of a language model more than the surrounding text does.
• Which specific sentences carry most of that signal, if the tool reports sentence-level scores.
• That a document is an outlier relative to a reference corpus you control.

What it cannot tell you:

• Who wrote it. A human editing a model draft, a model paraphrasing a human draft, and a human writing in a flat register can all produce similar readings.
• Whether the content is accurate, original, or in breach of any policy you actually have.
• Whether a person used AI in a way your rules permit. Detection has no concept of your policy; it has a concept of style.

There is a second trap here worth naming. Human writing is not stylistically uniform, and machine output is not stylistically obvious. In the same 2026-09-19 measurement, our human-written sample carried 3 AI-tell phrases per 100 words, while unedited model output carried 1 per 100 words. The human writing was noisier on that particular measure, not cleaner. If your pipeline assumes flagged text will look obviously machine-made, it will misroute real people.

Before you wire anything into a gate, run your own corpus through a detector and look at where your real users land. DeAIze’s free tier gives you 200 words on signup with no credit card, and paid credit packs start at $20.99 — see /pricing/ for the tiers. Knowing your own distribution beats guessing at a cutoff.

How do you choose detector threshold settings?

Pick thresholds from your review capacity, then accept the error rate that capacity implies. Not the other way round.

A single threshold forces you into a binary. Two thresholds give you a triage band:

Band	Typical action	What it costs you	Good for
Below the low threshold	Auto-pass, log the score only	You accept that some model-assisted text ships unreviewed	High-volume, low-stakes content
Between thresholds	Queue for human review	Reviewer time, and a delay the user can see	Anything with a consequence attached
Above the high threshold	Queue with priority, plus a second signal	Same reviewer time, more context to gather	Payments, credentials, published claims

Two practical rules. First, set the low threshold high enough that your review queue stays inside its staffing, not low enough to catch everything. A queue nobody can clear is worse than no queue, because it becomes a backlog you stop reading. Second, set the high threshold well above the low one. If they sit close together, the triage band collapses and you are back to a gate.

What each threshold costs: a lower low threshold buys coverage and spends reviewer hours; a higher one buys throughput and spends the risk that something slips through. Neither is free. Write down which one you chose and why, because that note is the first thing anyone will ask for when a decision is challenged.

How do you design a human review queue for flagged content?

Design it around the reviewer’s decision, not around the detector’s output.

1. Show the sentence-level view. A reviewer facing “this document scored high” has nothing to work with. A reviewer facing highlighted sentences with per-sentence scores can see which lines drove the result. DeAIze reports both a document score and a per-sentence AI probability for exactly this reason — the whole-document number is a summary, the sentence view is the evidence.
2. Give them the second signal. Account age, edit history, prior flags, whether the user disclosed AI assistance, whether the content matches a template you already accept. The detector score is one row in the panel, not the panel.
3. Make “insufficient evidence” a valid outcome. If the only reason for the flag is a borderline score, the correct decision is to let it through and note why. Reviewers who believe they must produce a verdict will produce one.
4. Cap the queue’s staleness. A review that resolves after the user has already moved on is a support ticket, not a review.

One design note from practice: route by consequence, not by score. A high score on a comment draft and a high score on a certification upload deserve different queues, even at identical numbers.

How do you log detection decisions so they can be explained later?

Log the decision as a record with a reason, in the same shape you would want if you had to hand it to the user who was affected.

At minimum, capture:

• The raw score and the per-sentence scores, with the tool and model version that produced them.
• The threshold values in force at that moment. Thresholds change; a decision is only interpretable against the configuration that produced it.
• The other signals present at decision time, with their own values.
• The outcome: auto-passed, queued, reviewed, overturned, upheld.
• For reviewed items, the reviewer’s stated reason in their own words.

Two habits make this durable. Store the detector’s output as data, not as a rendered string, so you can re-run analysis later without re-scoring. And timestamp everything against a single clock, because “the model version changed on Tuesday” is unanswerable if your logs use three different time sources.

If you want the underlying mechanics before you pick what to persist, how AI detection works covers the signals a detector is reading and why a single number compresses a lot of information away.

Should you cross-check with a second detector?

Sometimes, and deliberately. Running every document through several detectors multiplies your cost and your disagreement rate without multiplying your information by much.

A more useful pattern: cross-check only the items that land in the triage band, and only when the decision is consequential. DeAIze runs output against real third-party detector APIs where configured — GPTZero, Turnitin, Copyleaks, Originality.ai and Sapling are the ones named on the site — rather than trusting an internal guess. That is a reasonable shape for a pipeline too: your primary detector does the triage, a named external check confirms the borderline cases, and you record both results side by side.

When two tools disagree, that disagreement is itself information. It usually means the text sits near the decision boundary, which is a reason for human review rather than a reason to pick the higher number. Are AI detectors accurate? walks through why two tools read the same passage differently.

What does a sentence-level workflow look like end to end?

Here is the shape that holds up in production.

1. Text arrives. Score it once, at intake, and store the raw response.
2. Apply your triage bands. Most content auto-passes with a logged score and no human sees it.
3. For the triage band, pull the sentence-level view and attach the second signals to a queue item.
4. A reviewer decides, in writing, with “insufficient evidence” available.
5. Persist the whole record: scores, thresholds, signals, decision, reason.
6. Feed overturned decisions back into threshold tuning on a schedule. If your reviewers overturn a lot of items in one band, that band is set wrong.

Step three is where most integrations go soft. A queue item that says “score: high” produces rubber-stamping. A queue item that shows the three sentences driving the score produces a decision.

Illustration, not a real customer record: a submitted article arrives with a high document score. The reviewer opens the sentence view and finds two dense paragraphs at the top carrying most of the signal, while the rest of the piece reads flat and specific. The reviewer notes that the flagged paragraphs match the writer’s earlier published style, marks the item as insufficient evidence, and passes it. The log holds the score, the sentences, the note, and the outcome. Six weeks later, when the writer asks why their submission was delayed, that record answers the question in one screen.

What does this cost you to run?

Three budgets, and only one of them is money.

Detection spend. Per-word pricing means your cost scales with volume, so score at intake and avoid re-scoring the same document on every page load. Cache the result against a content hash.

Reviewer hours. This is the real cost. A triage band that captures a few percent of submissions sounds cheap until you multiply it by daily volume. Size the band from the staffing you have, and revisit it when volume changes.

Support load. Every auto-blocked user who believes the decision was wrong is a ticket. Routing to review instead of blocking converts most of those tickets into a short delay, which is a much cheaper thing to explain.

For a comparison of what different tools actually return in their API responses, and how much of it is usable as a pipeline signal, the AI detector comparison is the practical starting point.

Ready to see which sentences read machine-made?

If you are designing the workflow, the fastest way to make the design concrete is to look at real sentence-level output on your own text rather than on a sample.

Start with the detector at /ai-detector/ — paste a document you know the provenance of and look at how the per-sentence scores distribute. That distribution is what your thresholds have to sit inside.

When you have drafts that genuinely need cleaning up because the flagged sentences are flat rather than because the score is wrong, the draft editor runs the closed loop: score, rewrite only the flagged sentences, keep a rewrite only when semantic similarity says the meaning survived, then re-score and report before and after. 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 verdict from any third-party detector.

Check /pricing/ for credit packs, pay-as-you-go, credits that never expire and no subscription, or /register/ to start with 200 words free and no credit card.

One thing worth saying plainly, because it belongs in your integration docs as much as in ours: detection is a signal about style, and humanizing is an editing tool for your own drafts. Neither one decides whether the ideas, data and conclusions in a document are the author’s own. That judgement stays with the person accountable for the content, and your pipeline should be built so it can be made and recorded.