Designing an AI detector around review, not verdicts

The hard part of building an AI detector is not the score.

The score is the easy object to display. It is a number, a verdict label, and a tempting thing to make visually loud. But the more I worked through the product shape behind Detector de IA, the more obvious it became that the useful product is not a verdict machine. It is a review workflow.

That distinction changes almost every small decision in the interface.

The real user job is not "tell me yes or no"

People do search for a simple answer. A teacher, editor, student, or reviewer may arrive with one question in mind: does this text look AI-written?

But the next step is where the product earns or loses trust. If the tool only returns a single label, the user still has to decide what to do with it. Which parts of the text triggered the signal? How strong is the evidence? Was the sample long enough? Was this a pasted draft, a PDF, a DOCX file, or a plain text document? What should be reviewed manually before anyone acts on the result?

That is the job Detector de IA is built around: paste text or upload a supported document, run a probabilistic review, inspect sentence-level signals, and export a readable report that can support further human review.

The product is Spanish-first, with an English interface available too. That matters because many AI detection products assume the user, the report, and the surrounding review process all happen in English. The audience here is broader: Spanish-speaking users who want a free detector de IA for text and documents, plus bilingual reviewers who need to interpret the output responsibly.

Input design becomes part of the trust model

The first product choice is input scope. Detector de IA supports pasted text from 300 to 100,000 characters and accepts supported files under 12 MB, including PDF, DOCX, TXT, MD, Markdown, and plain text.

Those limits are not just validation details. They help prevent a misleading experience.

Very short samples are easier to misread. Very large inputs create reliability, performance, and abuse problems. Documents also have extraction differences: PDF and DOCX text is extracted in the browser before detection, while TXT and Markdown-style files can be handled more directly as text. If the product hides those boundaries, the report feels cleaner for a moment but less honest in practice.

This is a recurring product design lesson: constraints should not live only in error messages. When limits affect interpretation, they are part of the product's trust model.

Sentence evidence is more useful than one dramatic label

A single AI-likelihood score can be useful as a starting point, but it is not enough for a careful review. Detector de IA's report is more useful when it shows the surrounding evidence: verdict, risk, AI-generated likelihood, likely-human score, evidence strength, analysis notes, sentence highlights, and metadata.

The sentence highlights are important because they make the next action visible. Instead of asking the user to accept a global result, the report points them toward passages worth rereading. A reviewer can look for formulaic transitions, unusually even sentence structure, unsupported claims, or passages that do not match the writer's normal context.

That does not make the tool definitive. It makes the review less opaque.

For me, this is the main product lesson. If a model-backed tool produces uncertainty, the UI should not pretend uncertainty disappeared. It should help the user inspect it.

Export is not an afterthought

Export sounds like a secondary feature until you think about the real workflow. The person running the check often needs to share the result, keep a copy, or compare it with a manual review note. Detector de IA supports copying a report summary and exporting a printable report through the browser print flow.

That changes the report from a transient screen into a review artifact. It also raises the standard for wording. The exported summary should not sound like a final accusation. It should preserve the same caveats the live interface shows: the result is probabilistic, evidence strength matters, and the report is one input into a broader review.

The caveat has to stay close to the result

AI detectors can produce false positives and false negatives. That is not a footnote to hide at the bottom of the page. It is central to how the product should be used.

Detector de IA should not be used as the only basis for academic, employment, legal, disciplinary, or other high-impact decisions. It can help someone decide what to review next. It can surface sentence-level signals. It can make a report easier to discuss. It should not be treated as an accusation engine.

This is where product copy and product ethics meet. A more aggressive landing page might convert more curious clicks in the short term. A clearer caveat creates a better user relationship, especially for a tool that people may use in sensitive contexts.

The builder takeaway

The reusable lesson is that a narrow AI tool still needs a complete workflow around the model call.

For this kind of product, the workflow is:

1. Get enough usable text.

2. Preserve clear file and length boundaries.

3. Run the detection step.

4. Show the result as a probability signal.

5. Explain which evidence deserves attention.

6. Make the report portable.

7. Keep the caveat attached to the output.

That shape is less flashy than "instant AI verdict", but it is more useful. It gives the user a next step instead of just a number to worry about.

I am using Detector de IA as the concrete example here because it is the product I am shaping around this workflow. The public tool is here:

https://detector-de-ia.net/

The most important design choice is not that the tool gives a score. It is that the score does not have to stand alone.

Final thought

The more uncertainty a product has to handle, the more careful its workflow needs to be. In an AI detector, the responsible interface is not the one that shouts the strongest answer. It is the one that helps a person review the evidence, understand the limit, and decide what to check next.