GUIDE
Reviewing AI tools before adoption — the guide
Every week a new tool knocks: a browser extension, a writing assistant, a meeting transcriber. This guide gives review its toolkit: one request card, data questions before capability questions, and a recorded decision with its constraints and review date.
AI tool review becomes disciplined in six steps: one request card, then the data-path check (residency, retention, training), then identity and access, then a narrow trial under tight permissions, then a named recorded decision with constraints, then periodic review of the approved — turning the queue into a measurable lane.
THE PROBLEM
The problem: a queue without a standard
Approval requests arrive faster than any team can review them. And each gets judged differently depending on who picked it up: one asks about encryption, another about price, a third approves because the requesting department is in a hurry. The result is a slowness that pushes employees to try without waiting — that is, into the shadow.
The missing standard wrongs both sides: the reviewer carries decision liability without a toolkit, and the requester can't fathom why their ask was refused while its twin passed last month.
Good review is neither the slowest nor the harshest; it is standardized questions answered once, and a recorded decision citable for every similar request after.
Judge a tool by what leaves your data toward it — not by what appears on its screen.
THE PRINCIPLES
The principles
- Review the usage, not the logo. The same tool can be safe for one case and risky for another — the unit of review is tool × use case × data classification.
- Data first. Where is it sent? Where does it reside? Do models train on it? Who at the vendor sees it? These questions precede any capability demo.
- The output is a recorded decision. Approve, refuse, or trial under constraints — every decision under its owner's name, with its constraints and review date, in a retrievable register.
THE STEPS
The six steps
The first three steps are paperwork and require buying nothing — and they save most of the time.
- Standardize the request card. Tool name, intended use case, expected data classification, anticipated user count — one page the requester fills, killing half the debates before they start.
- Check the data path. Read the processing terms, not the marketing page: residency, retention, training on your data, sub-processors, deletion path — any ambiguity becomes a written vendor question.
- Check identity and access. Does the tool sit behind your SSO? Does it understand roles? Does it write an exportable event log? A tool that doesn't know your identity starts the review from behind.
- Trial narrowly. Few users, non-sensitive data, a pre-set duration — inside your gate where possible, so the register writes the trial's trail instead of it being retold as impressions.
- Decide with a name and a date. A recorded decision with its owner, constraints (for whom, which data, what limits), and review date — cited on every similar request, so no review is repeated twice.
- Re-review the approved periodically. Tool terms change quietly: a new model, a new sub-processor, a new retention policy. A decision without a review date ages exactly like a forgotten policy.
ILLUSTRATIVE
WHERE AN APPROVAL REQUEST SPENDS ITS TIME — ILLUSTRATIVE
An illustrative split — standardization attacks the waiting and the chasing, not the decision moment.
EVALUATION
Evaluation questions
- How many requests wait today, and since when? If the answer isn't a ready number, the queue itself is invisible — that's gap one.
- Can you retrieve last year's decisions with their constraints? An irretrievable decision will be made again — usually with a different outcome.
- What is the fast lane for low-risk tools? One lane for everything means one queue for everything — a declared fast lane protects the full lane from being bypassed.
EVALUATION QUESTIONS
Questions raised in every evaluation.
Who should sit on the review committee?
Three suffice: security checking the technical path, a compliance rep checking the terms, a business owner vouching for the need — more than that is slowness the queue pays for.
Does this replace the full legal review?
No — it precedes and feeds it: the card and checks hand legal a complete file instead of a cold start. The full contractual review has its own playbook.
What about refused tools still being used?
A refusal without an alternative becomes shadow — so tie every refusal to the official path serving the same need inside your gate, and watch the gap in the register.
CLOSE
Closing: from heroics to a lane
Review that relies on an expert reviewer's heroics doesn't scale; review that becomes a lane — standardized questions, recorded decisions — scales and accelerates at once. The difference isn't the team's intelligence; it's the existence of the toolkit.
The toolkit is ready: a full playbook and a security checklist —
Standardize the questions. Speed the decision.
Print the guide and its security checklist, and test them on a tool awaiting your decision this week — then bring what you found.