An AI validation tool is only useful if you can say what it validated.

Three different products get called AI checkers. A detector asks whether content was machine-generated. A grader asks how good the content is. A validator asks whether the artefact meets a stated standard and produces evidence for that claim.

Only the third one fits into a delivery process, because it ends in a decision rather than a probability. When a vendor cannot tell you which of the three they sell, that is the first answer you need.

The test is simple: ask what the output would look like in a client email. A validation result can be pasted into one. A detector result invites a conversation about false positives.

The report is the product. If the shape is wrong, no amount of rules behind it will help you, because you cannot argue with it or attach it to anything.

Build two files. In the first, plant defects you control: a plausible API key, an eval call, an empty catch, a statistic with no source, a skipped heading rank, an unfinished placeholder. In the second, write plain, clean prose and unremarkable code.

Run both. On the seeded file, count true positives and misses. On the clean file, count invented findings. The third number is the one that predicts how your team will behave in a month, because false positives train people to skim.

Run the seeded file twice more, days apart. Identical results mean the tool is deterministic and the report can be evidence. Different results mean you are paying for an opinion.

A validation tool needs the content to validate. The question is whether that content travels. Server-side tools create a second copy under someone else's retention defaults and often a second processor if a model provider is behind the scenes.

For internal drafts that may be acceptable. For client material under an NDA, unreleased financials or anything with personal data, a local rule engine removes the entire conversation: there is no copy, no retention and no new subprocessor.

You can verify the claim rather than take it: run a check with the browser's network panel open, then again with networking disabled. Absence of a request is a property you can see.

Licence cost is the visible half. The invisible half is what the report generates: how many items get escalated, what a specialist costs per hour, and how long a review takes.

A cheap tool with noisy findings costs more than a precise one, because the expensive resource is the reviewer reading the reports. Model your expected escalation volume during the pilot rather than assuming zero.

The same arithmetic applies to coverage. A tool that catches three of your ten defect classes leaves seven to a person, and that person's hourly rate is the real price of the gap.

Pilots fail for social reasons more often than technical ones. Pick one pipeline, one team and a gate that takes seconds, then publish the first month's findings so people can see what the tool is actually good at.

Agree the bands before rollout: what blocks, what warns, who decides and how an override is recorded. A tool without bands is a suggestion engine.

Finally, decide where the human step sits and staff it deliberately. The report tells you which items belong there; guessing in advance usually over-escalates expensive work and under-escalates the rest.