LibraryFoundational AI: Do's and Don'ts6 min read
Separate what someone did from why you think they did it
AI can turn a late reply or missed deadline into a confident story about someone's intent. Keep the observed behavior separate from the explanation before it shapes a business decision.

A customer replies three days after receiving a proposal. The account note says, “They’re not serious about moving forward.” Maybe that’s true. The message itself only shows that the reply came three days later.
AI can make the jump from event to explanation sound tidy. A few messages become a story about a customer avoiding a decision, a colleague resisting change, or a team member not caring about a deadline. Those explanations may feel useful because they give you something to do. But unless the source supports them, they’re guesses about another person.
Use AI to organize what the records show. Keep a person responsible for deciding what the behavior means, if anything. The distinction matters whenever a generated interpretation could affect a relationship, a customer record, a performance conversation, or the next step in a deal.
Label the observation and the interpretation separately
An observation is a statement you can point to in the material you reviewed: a date, a sent message, a missed meeting, or words someone used. An interpretation explains what that event might mean. It can be reasonable to consider interpretations, but they shouldn’t quietly become facts just because AI wrote them fluently.
In the proposal example:
| Statement | What it is | What the source establishes | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------- | | “The customer replied on November 6.” | Observation, if the message date confirms it. | The reply date. | | “They asked to discuss the pricing section.” | Observation, if those words appear in the message. | What the customer asked to discuss. | | “They’re delaying because they don’t want to buy.” | Interpretation. | Nothing about their reason, unless another source establishes it. |
The last statement could be one possible explanation. Other explanations could fit the same delay: the customer was unavailable, needed input from someone else, or had another priority. Those are possibilities too, not facts. The useful conclusion is narrower: you don’t yet know why the customer replied when they did.
Ask for a factual account before asking for a read
If you want AI to help organize a conversation, make the boundary part of the task. For example:
From these messages, list the dated events and the person’s exact requests or commitments. Separate direct statements from interpretations. Do not infer motives, emotions, interest, or intent. If the material doesn’t answer a question, label it unknown. Include the source message for each observation. Do not update a customer record or send a reply.
This is an illustrative prompt, not a tested recipe or a guarantee. A model may still produce an unsupported interpretation, misread who said what, or cite the wrong message. Open the source and check the account, wording, dates, and context yourself.
Then review the answer in two passes:
- Check the events. Does each date, action, quote, and person match the original material? Is any relevant message missing?
- Check the boundary. Did AI add an explanation, such as “uninterested” or “resistant,” that no source actually states? If so, remove it or label it clearly as an unconfirmed possibility.
The NIST Generative AI Profile describes how generative AI can produce confident but false or inaccurate content, including content that diverges from its input. NIST also recommends evaluating outputs against known information and checking sources and citations. That supports verifying the account against the source. It doesn’t mean a prompt can reliably prevent every inference.
Keep the record useful without making it a verdict
A customer record or internal handoff should help the next person act. It doesn’t need a theory about why someone behaved a certain way. A more useful note might say:
Proposal sent November 2. Customer replied November 6 and asked to revisit the pricing section. Reason for the gap is unknown. Follow up by asking whether they need any information before the review.
This records what happened, marks the uncertainty, and gives the team a sensible next step. It doesn’t transform a delay into a buying signal or a judgment about the customer.
The same habit can help with team communication. Suppose a colleague hasn’t provided an update by the agreed date. AI might describe them as “disengaged” or “blocking the project.” Before carrying that description into a personnel note or escalation, check what the source actually says: Was a deadline recorded? Was the request received? Did the colleague explain a dependency or ask for a change? If the records don’t answer those questions, the responsible next step may be to ask the colleague, not to save a generated diagnosis.
A direct statement of intent is still evidence of what a person said, not proof that the intent will be fulfilled. Keep that distinction too. “They said they expect to decide next week” is different from “They will buy next week.”
Don’t use a prompt as a substitute for judgment
There’s a fair limit to this practice. People routinely make working interpretations from incomplete information, and an interpretation can help you decide what question to ask next. You don’t need to ban AI from suggesting possibilities. You do need to avoid treating those suggestions as knowledge about a person.
If possible explanations would help, ask AI to list them explicitly as hypotheses and include what evidence would distinguish them. For example: “List a few possible reasons for this delay, but don’t rank them as facts. For each, identify what information would support or rule it out.” Then use the list to prepare a neutral question or identify missing context. Don’t paste the most compelling possibility into a record as if the person confirmed it.
Be especially careful when the interpretation could affect someone’s access, employment, a customer relationship, or a financial decision. The model can help you prepare a chronology or locate a message. It can’t establish fairness, determine what another person intended, or take responsibility for a decision. If the decision matters, the person accountable for it needs to review relevant evidence and ask for context where appropriate.
For a low-consequence task, like sorting your own reminders, the formal two-pass review may be unnecessary. For a note that will guide how the team treats a customer or colleague, the extra check is usually worth the few minutes it takes.
Before saving an AI-assisted summary about a person, ask: Can I point to a source for every factual claim, and have I labeled every explanation as an interpretation? If not, correct the note, ask the person for context, or leave the reason unknown. A clear record of what you don’t know is more useful than a confident story the evidence can’t support.
Sources: NIST’s Generative AI Profile.
Sources
Every claim above traces back to one of these. Go read them yourself.
- 01Artificial Intelligence Risk Management Framework: Generative AI Profile
National Institute of Standards and Technology / nvlpubs.nist.gov / retrieved Nov 06, 2026
Suggested reading
Selected articles based on topic, tags, and skill focus across the library.
Foundational AI: Do's and Don'ts
Make a decision table before asking AI to apply a rule
When a work rule depends on several conditions, map the combinations and their outcomes before asking AI to apply it. The table can expose gaps your prompt would otherwise hide.
Foundational AI: Do's and Don'ts
Give AI a scope note before a review
When AI reviews only part of a report or record set, make that boundary visible before you use its conclusion. A short scope note helps you spot what the answer cannot cover.
Foundational AI: Do's and Don'ts
Use a premortem to find a plan’s weak spots
Before committing to a plan, ask AI to imagine it has failed and list plausible reasons. Use the results to find questions your team should answer, not to predict what will happen.

