Build a habit of careful AI review.

A useful starting point is a small task with an inspectable result. Describe the input, the person who needs the output and the decision that person must still make. Keep those three things separate: an assistant can draft an answer without being authorized to send it, and it can summarize a document without being allowed to see every source.

Synthetic scenario: a support reviewer wants a draft answer about a fictional product’s export settings. The approved help article says that only a workspace administrator can enable exports. An old team note says that anyone can enable them. The reviewer needs an answer based on the approved article, with the conflict visible rather than silently merged.

Before testing, name the source owner, the reviewer and the action boundary. In this exercise the boundary is drafting only. A correct-looking answer does not authorize an export change or a message to a customer. Keep the initial question narrow enough that the reviewer can compare every claim with the small source set.

• Expected authority: the approved help article.
• Expected limitation: the older note conflicts with that article.
• Expected action: prepare a draft for review, without changing settings.

Reviewing AI output is a task of its own. Give the reviewer specific things to inspect: whether each claim follows from the source, whether a proposal became a commitment and whether an unknown was turned into an invented detail. Fluent writing can make those mistakes easy to overlook.

Synthetic scenario: meeting notes say that a designer will explore two layouts and an engineer will investigate a technical constraint. The group did not choose a launch date. A draft summary says, “The team approved the new layout for launch next Friday.” The sentence is concise, but neither the approval nor the date appears in the notes.

A useful correction identifies the unsupported claims and preserves what is known. The next instruction can ask for separate sections for accepted actions, proposals and unresolved questions. Retest the same notes after changing the instruction so the reviewer can see whether the specific mistake has been addressed.

• Keep accepted actions separate from options under discussion.
• Write “not specified” when the source contains no deadline.
• Use the same example to check a targeted correction.

A small evaluation can expose a problem without establishing broad reliability or business impact. Decide what evidence would justify a next step, then record both the results and the conditions under which they were produced. Include correction effort and failures instead of keeping only successful outputs.

Synthetic scenario: a team tries three fictional questions against a tiny document set. Two answers match the expected source, and one invents a missing policy. The team corrects the instruction and gets three acceptable answers on another attempt. That is evidence about those examples and that revision; it is not a measurement of organization-wide accuracy, saved time or readiness for unrestricted access.

The useful next decision is bounded: record the failure, repeat the exercise and add a different case with an explicit expected result. If workplace material is considered later, obtain the relevant source owner’s approval first. Keep a stop condition, a reviewer and an explanation of what remains untested in the decision note.

• Report the sample and its limitations together.
• Track review and correction work as well as final output.
• Do not turn a synthetic exercise into a performance claim.