Tool first or task first?

Always the task first. A tool with no named task gets bought, rolled out, and abandoned after a quarter.

How many tools does an organisation need?

Fewer than are on offer. One general tool plus one or two specialist ones covers most needs.

By missing statements on data processing, model changes and exit. All three are uncomfortable and therefore informative.

01
Name the task
Frequent, checkable, with a baseline. Without this step every criterion is missing.
02
Derive the requirements
Which kinds of data, which integrations, which output form, which review steps.
03
Assess two or three candidates
On your own evaluation set, not on a demo.
04
Settle contract and exit
Before deciding, not after rolling out.

Criterion	Why it counts
Fit to the task	A tool with no task does not get used
Data processing	Processing agreement, locations, sub-processors, training exclusion
Connection to your sources	Without retrieval there are no verifiable answers
Permissions and tenant separation	Who sees what, technically enforced
Logging	What the tool records itself and can export
Output form	Structured output as soon as anything is processed further
Model changes	Announced, or silent
Exit	Export of your content, notice period, format
Price	Last, because it is meaningless without the points above

Processing locations and a full sub-processor list, with notice of changes.
Exclusion of any use of inputs and outputs for training, technically evidenced.
A duty to announce model changes, with a notice period.
Statements on accuracy, limits and foreseeable misuse; at high risk, instructions for use.
Export format and period for your own content after the contract ends.
Logs: what is recorded, for how long, and whether it is exportable.
Inspection rights beyond producing a certificate.

Route	When sensible	Cost
Finished tool	Standard task, no special need	fast, less control
Your own application on an API	Your data, your workflow	moderate effort, full control of the flow
Local model	Data may not leave	highest effort, full control

The middle row is underestimated. A lean application over an API is often built in days, binds your own sources, and logs exactly what is needed.

Can prompts, templates and your own content be exported, in a readable format?
Do logs stay available after the contract ends, for as long as the retention period runs?
Is there a rehearsed fallback path, for instance to a local model?
How long does a switch realistically take, measured rather than estimated?

The last point deserves being played through once. A fallback that exists only on paper is not one in an emergency. See Local and open models.