DetectorScope Turns the Black Box of AI-Text Detectors into a Transparent One

AI-text detectors now help decide matters that affect people: peer review of scientific papers, grading at universities, admissions committees, newsrooms and content moderation. The strongest of them are fine-tuned neural classifiers, and their verdicts cannot be explained. Transparent alternatives based on stylometry and linguistic features are noticeably less accurate. A team of researchers, including Liam Dugan, Callum McDougall, Matthew Denton, Philip Pham, Christine Keser-Chen and Chris Callison-Burch, proposed a way around that trade-off. Their DetectorScope pipeline takes an existing detector and builds a classifier on human-readable concepts on top of it. The paper has been accepted to the main program of EMNLP 2026, and the code is published in the google-deepmind/detectorscope repository.

Five steps from black box to audit

The idea builds on sparse autoencoders (SAEs), an interpretability tool that decomposes a model's internal activations into individual features. The authors applied it not to a general-purpose language model but to the detector itself. The pipeline looks like this:

• SAE training. The autoencoders are trained directly on the residual stream of the fine-tuned neural detector.
• Auto-interpretation. Each SAE feature automatically gets a text description of what exactly it picks up in a text.
• Fidelity filter. Only features whose generated descriptions pass a global fidelity threshold are kept. Anything that could not be described convincingly is discarded.
• Lightweight classifier. A simple model is trained on the selected interpretable features, and it produces the final verdict.
• Audit. For any decision, you can see which concepts fired and why the text was judged to be machine-written or human-written.

The threshold filter is essential here. Automatic feature labels can be elegant and wrong, and without verification the audit would become an illusion of transparency. The global fidelity requirement leaves only features that can be trusted in the final classifier.

What turned up inside the detector

The main substantive result: SAEs extract hidden concepts that correspond to specific, predictive linguistic "markers" of AI text. These are not abstract notions like "stylistic smoothness" or "high perplexity" but specific language cues that an analyst can read, check against examples and challenge. For a journal reviewer or a teacher, that is the difference between "the system said 94%" and "the system found such-and-such constructions."

On accuracy, the authors report two findings. Auditable detectors retain the quality of the original black box, both on in-distribution data and on out-of-distribution texts. In addition, classifiers built on the extracted features outperform neural and stylometric alternatives on out-of-distribution texts. That is the most painful area for detection: generators change fast, and detectors trained on older models break on new ones.

There is also a downside. Understandable features make evasion easier as well as auditing: anyone who knows which "markers" the detector catches a text by can scrub them out. That is the usual price of transparency, and addressing it will take usage policies, not just architecture.

How to apply it

For teams that already use detectors to check submitted work, select reviewers or moderate content, DetectorScope describes a workable path: don't change the model, add an explanation layer on top of it. The method is claimed to work for an arbitrary detector, so existing solutions do not have to be replaced from scratch.

The practical implications are clear. Disputed cases can be reviewed by the list of features that fired rather than by a single probability number. Systematic errors, such as bias against authors writing in a non-native language, are easier to spot when you can see which concepts drive the verdict. And for regulators and organizations that need to document automated decisions about people, an auditable detector provides something that can be attached to a report.

The code is open, so the method can be tested on your own data and your own detector. Such tests will show how robustly the feature descriptions transfer across domains and languages.