Before you use an AI answer at work, make a verification plan

The useful question is not whether AI is ‘accurate’

Generative AI can turn a blank page into a draft, reorganize a long note, suggest questions for a meeting, or translate plain language into a starting point for code. It can also produce a confident sentence that does not belong in a customer message, a policy, a medical decision, or a spreadsheet that moves money. These are not contradictory observations. They point to a more useful question than ‘Is this tool accurate?’: what would happen if this particular output is wrong, incomplete, misleading, or shared more widely than intended?

That question makes room for ordinary, productive use. A rough agenda for an internal brainstorming session is not the same as a summary used to decide whether a patient receives care or whether a person gets a job. Nor is an AI-written paragraph automatically reliable because it sounds polished. The purpose, audience, inputs, and consequences of a task determine how much human review it needs.

NIST’s AI Risk Management Framework is aimed at organizations, but its basic discipline is compact enough for a team or an individual: establish the context, assess what can go wrong, and manage the remaining risk. Its companion profile for generative AI notes that risks can arise from the model, the system around it, the inputs, the outputs, and the way people use it. In practice, that means a sensible workflow starts before the prompt and ends after the output is checked—not at the moment text appears on screen.

Classify the task before you open the chat window

Begin with a one-sentence description of the job: ‘turn these public meeting notes into three headline options’ or ‘draft a reply to a customer about a delayed order.’ Then name the person who will use the result and the decision it could influence. This prevents a familiar failure mode: a quick experiment quietly becoming an input to an important decision without anyone deciding what standard it should meet.

Next, sort the task by consequence. Low-consequence work is easy to undo and has a limited audience: generating alternative headings, outlining a public document you already understand, or making a checklist for your own review. Medium-consequence work may affect customers, colleagues, or a public claim, but a knowledgeable person can verify it before release. High-consequence work changes a person’s rights, safety, finances, access, legal position, or important service. The last group needs domain-appropriate controls and accountable human decision-making; a general-purpose chatbot should not be treated as the final authority.

This is not a rule that says ‘never use AI’ for consequential work. It is a rule against hiding the decision. A tool may help a qualified person organize material, spot items for review, or prepare a draft. But the organization should be able to say who checked the result, what evidence they used, and what happens when the tool is uncertain or wrong. If those answers are missing, the use case is not ready simply because a demo looks impressive.

• What is the output for, and who could rely on it?
• Can a mistake be corrected easily, or could it cause real harm?
• Who has the knowledge and authority to approve it before use?

Decide what information must stay out of the prompt

A good prompt can still be the wrong place for the underlying material. Before pasting anything, separate public information from internal, personal, confidential, regulated, or security-sensitive information. Customer records, credentials, unpublished financial results, private source material, access tokens, and details that would help someone attack a system deserve special care. ‘I only need a quick summary’ does not change the sensitivity of the source.

The safe route depends on the service and on your organization’s rules. Check the provider’s current data controls and your approved-workspace policy; do not infer them from a product name or an old social-media post. If the material is not approved for that service, use a sanitized example, remove identifying details, summarize it yourself at a higher level, or do the task without the model. Redaction should be meaningful: replacing a name while leaving a unique account number, date, and incident description can still identify a person.

It also helps to treat uploaded files, connected drives, and tool integrations as inputs, not magic features. Ask what content the tool can access, whether a result will be visible outside the intended group, and what permissions the connected account carries. Give it the least information and least access that can accomplish the task. This preserves options if the experiment stops being useful or if a review finds an unexpected risk.

Ask for work you can inspect

A prompt should make review easier, not create a polished mystery. State the source boundary: for example, ‘Use only the text below; if it does not answer a question, say so.’ Ask the tool to distinguish direct statements from inferences, to flag missing information, and to preserve links or document references supplied in the source. For a comparison, ask it to produce the criteria first. For a calculation, ask it to show the formula and inputs so a person can reproduce it independently.

This does not turn a language model into a guarantee. It turns the output into a better draft for checking. If the tool supplies citations, open them. A link may be irrelevant, outdated, or fail to support the exact sentence beside it. If it gives a number, trace it to the source data or recompute it. If it makes a recommendation, identify the assumptions behind it and consider a plausible counterexample. The more the result could affect someone else, the less sensible it is to accept a fluent answer at face value.

Avoid prompts that demand certainty where none is available. ‘Give the definitive answer’ can encourage a confident-looking response even when the provided material is thin. A better instruction is: ‘List what is known, what is uncertain, and what a human should verify next.’ That framing supports useful caution without requiring every small task to become a research project.

• Limit the model to approved source material when that is possible.
• Request uncertainty, assumptions, and missing facts alongside the draft.
• Keep enough source detail to let a reviewer reproduce key claims or calculations.

Match the review to the consequence

A verification plan need not be bureaucratic. For a low-consequence draft, read it for tone, obvious errors, and accidental disclosure before sharing. For a public post or customer-facing explanation, verify each material factual claim against the primary source, confirm dates and names, and check that any quotations are exact. For a high-consequence use, add the controls appropriate to the domain: an independent review, documented evidence, testing against representative cases, an appeal or correction route where people are affected, and a clear owner for the final decision.

NIST describes AI risk as involving both likelihood and the magnitude of consequences. That is a helpful way to allocate attention. A rare typo in an internal outline may deserve a quick correction. A less likely error that could deny a service, expose private information, or trigger a costly action deserves much more scrutiny. The point is not to calculate a perfect score; it is to avoid giving every output the same casual treatment.

Keep a small record for recurring uses: the task, approved input types, model or service, reviewer, checks performed, and known limitations. This is especially valuable when a workflow changes hands. It creates a way to notice drift—perhaps the source data changed, a new integration was connected, or a once-informal draft is now being copied into public communications. Documentation is a tool for better decisions, not evidence that a tool has become trustworthy forever.

Know the stop signs

Sometimes the correct next step is to pause. Stop when you cannot identify a responsible reviewer, cannot verify a key claim, do not have permission to share the source material, or cannot explain how a person affected by the result could correct an error. Also pause when the tool’s output would be used to make a decision that requires specialized expertise and you do not have that expertise available. Rephrasing the prompt is not a substitute for evidence or authority.

Be alert to a subtler stop sign: automation pressure. A team may begin by using a model for a single draft and then gradually remove the review step because the output is usually good enough. That is exactly when a lightweight check is most valuable. Sample completed work, compare it with source material, record errors, and adjust the use case when the evidence changes. NIST’s framework emphasizes ongoing monitoring because context and impacts do not stand still after deployment.

Generative AI is most helpful when it makes human judgment faster, clearer, or more complete—not when it makes ownership disappear. A verification plan keeps the useful parts of the tool in reach while preserving the standard that matters: people remain responsible for information and decisions they put into the world.

A five-question preflight

Before using a generative AI result beyond your own private scratchpad, take one minute to answer five questions: What is this task for? What could go wrong if the output is wrong? Is this information approved for the service? What source or calculation will I use to check the important parts? Who is accountable for the final use? If any answer is unclear, reduce the scope, gather better evidence, or wait for the right reviewer.

That habit is deliberately small. It does not promise that every risk can be predicted, and it does not assume every team has a large compliance department. It gives ordinary users a repeatable way to match a powerful general-purpose tool to the real stakes of a task. The result is less about trusting or distrusting AI in the abstract, and more about earning confidence in a particular use.