Before you give an AI tool real work, ask these six questions.

An AI tool can be useful before it is trustworthy. Those are different judgments. Before connecting it to real files or accounts, identify what it can see, what it can change, and what evidence you will have when it gets something wrong.

Start with the task, not the demo. Write down the decision the tool will influence, the data it needs, and the result that would count as failure. If the task is vague, a polished answer can hide a bad fit.

Six questions worth answering

1. What data enters the system? Check prompts, uploaded files, connected apps, retention, training use, and deletion controls. Do not assume a private-looking interface tells you the full data path.
2. What can the tool do? Separate reading from writing, and suggestions from actions. A tool that can send, purchase, delete, or change records needs a narrower test than one that only summarizes.
3. How does it show uncertainty? Look for citations, logs, confidence limits, or an explicit way to inspect the source material. A fluent answer is not evidence by itself.
4. What happens when it fails? Find the recovery path, undo behavior, support channel, and incident process before the first consequential task.
5. Who owns the decision? NIST's AI Risk Management Framework treats accountability and transparency as part of trustworthy use. Assign a person or team who can stop the workflow and explain the result.
6. How will you test it? Use a small set of representative, known-answer cases. Record the prompt, inputs, output, corrections, and permission changes so the evaluation can be repeated.

NIST describes trustworthy AI as a lifecycle concern that includes design, deployment, use, testing, privacy, security, accountability, and transparency. That is the useful shift: an AI tool is not cleared once by a clever demo. It is evaluated against a real task and revisited when the tool, data, or stakes change.

The safest first run is deliberately boring. Use non-sensitive examples, keep permissions narrow, require confirmation before external actions, and preserve the evidence needed to understand the result. Expand access only when the smaller test earns it.