Buying an AI detector is not the same as buying a spellchecker. Its output can affect students, writers, employees, contributors, and customers. A good procurement process asks how the tool performs in the organization's own context and whether its output can be used safely in a human decision process.
Product reference: the public Pricing page captured on July 19, 2026.
Last reviewed: July 19, 2026 Use case: a team comparing detection tools before a paid rollout
Run a pilot, not a demonstration
Vendor demonstrations often use clean examples. Build a pilot set from consented or synthetic material that resembles your real documents: relevant language, expected length, permitted AI assistance, human editing, and domain terminology. Keep the known provenance of each item so that the pilot can measure errors honestly.
Procurement questions that change the decision
| Area | Questions to ask |
|---|---|
| Output | Is the result a probability, explanation, or binary label? Can it be exported and understood by reviewers? |
| Validation | Has the tool been evaluated on your language, document length, and use case? What is the date of that evaluation? |
| Workflow | Can a reviewer add context, override a signal, and record an appeal outcome? |
| Privacy | What text is retained, where is it processed, and who can access it? |
| Change control | How are model updates announced and how will you re-test after a change? |
| Cost | What happens when usage rises, and can you limit access by role? |
A simple pilot scorecard
Score each pilot document against the known source and the reviewer action it would trigger. For example, a 900-word verified human essay that receives a high-risk label matters more than a polished marketing example. Record false-positive exposure, missed escalations, explanation quality, reviewer time, and whether the decision can be appealed.
Pilot sample: include one human-written technical memo, one model-generated memo, one human-edited model draft, and one document with permitted AI proofreading. Do not infer provenance from the writing style—record it before scoring.
Define a “no-go” condition
Before testing, agree on conditions that rule out deployment: a high false-positive rate in the protected population, no meaningful appeal route, unclear retention terms, or a workflow that encourages automatic disciplinary action. A tool can be useful for low-stakes editorial triage and still be unsuitable for high-stakes decisions.
NIST's AI risk-management resources are useful here because they focus on measured, context-specific risk rather than generic claims of accuracy.