Tomas Reinholt manages a four-person market research team at a B2B software company. One Thursday afternoon, an analyst dropped a polished two-page competitor market summary on his desk, AI-assisted, ready to go to the sales leadership team the next morning. It read beautifully. Clean structure, confident prose, a tidy table of market sizes. Tomas almost approved it on the spot. Instead he made himself slow down and read it the way he had learned to read AI-assisted work, looking not for whether it sounded right but for the specific places AI tends to go wrong. In fifteen minutes he found three separate errors, each of a different kind, any one of which would have embarrassed the team in front of sales leadership. This lesson is the reading method he used.

What This Lesson Covers

AI makes errors, and it makes them in recognizable patterns. The job of a manager is not to become an AI expert. It is to build the habit, in yourself and your team, of catching the specific kinds of mistakes AI produces. The good news is that those mistakes are predictable, which means they are catchable once you know what to look for and where it hides.

This lesson covers a taxonomy of the error types that show up in team work products, the tells that flag each one, where errors tend to hide, a practical review checklist, how to build a verification habit across a team, and a triage rule for deciding which outputs get heavy scrutiny and which get a light pass. The scope is operational oversight: reviewing the work your team actually submits.

The stakes are four-fold, and it is worth naming them because they explain why this is a management responsibility rather than an individual contributor's. Errors reduce the quality of what your team produces. They undermine trust, both in the tools and in the people using them. Some carry real legal or compliance consequences. And errors you never notice are errors you never learn from, which means your review process stops improving.

A Taxonomy of AI Errors

Naming the error types gives you a mental checklist. When you review, you are not just hoping to notice something off; you are scanning for these specific failure modes.

• Hallucinated facts and citations. The AI invents something that sounds real: a report that does not exist, a feature the product does not have, a quote nobody said. The tell is a confident, specific detail you have never encountered, often with a clean-looking source attached.
• Fabricated numbers. A close cousin, dangerous enough to call out separately. The AI produces a precise-looking figure, a market size, a percentage, a growth rate, with no real basis. Precision is the disguise; a number like "23.4 percent" reads as researched even when it was generated.
• Outdated information. The AI draws on what it learned up to its training cutoff, so time-sensitive facts can be stale. The tell is anything current-sounding, prices, rankings, "latest" anything, that you have not personally confirmed is still true.
• Subtle logical errors. The argument flows nicely but does not actually hold. A claim that something is both cheapest and highest quality, a conclusion that does not follow from its premises, a contradiction buried two paragraphs apart. The tell is a sentence that sounds right until you stop and trace the reasoning.
• Tone and bias issues. The output reflects skews in training data, describing one group more favorably than another, leaning on stereotypes, or shifting a recommendation based on demographic cues. The tell is language about people that feels uneven, or advice that would change if you swapped the names.
• Plausible-but-wrong confidence. The meta-pattern behind all of these. AI states wrong things in exactly the same assured tone it uses for right things. There is no hedging, no flicker of doubt, so confidence itself carries zero information about correctness. This is why fluent, polished output is the most dangerous: it disarms your skepticism.

Two Error Types That Do Not Look Like Errors

The six above are the ones that will get you corrected in public. Two more are quieter, and they are the ones Tomas sees most often in day-to-day team work, because nothing in the output is false.

Misunderstood context. The AI produces something relevant-sounding that misses the point of what was actually asked. You ask for a brief summary and get a lengthy overview. You ask for a professional tone and get formality so stiff it does not fit how your company talks. You ask someone to improve a specific section and the whole thing comes back rewritten. You supply detailed context about your customer base and the recommendations ignore it entirely. This happens because the model works over text probabilistically rather than understanding your situation, and because the assumptions in your head never made it into the prompt. The tell is output that is well written but does not match the picture you had in mind. Two things prevent it: state the context explicitly, including the negative case ("our culture is informal, not corporate"), and be specific about constraints ("exactly three pages, not five"). When a first attempt misses, refine the prompt rather than editing around the miss, because the miss will recur next time otherwise.

Missing nuance. The output is technically correct and still not usable, because it is flattened. A customer service reply that is polite but never addresses what the customer actually complained about. A strategy recommendation that is logical on paper and ignores the political realities of who has to approve it. A technical solution that is right in principle and impossible against your legacy constraints. A market analysis that is accurate and blind to the competitive context anyone in the room would know. Nuance comes from experience and judgment; the AI is pattern-matching without deep domain understanding, and it cannot know the contextual factors that were never written down. The tell is output that reads as sensible until someone with real expertise says "this misses something." The countermeasures are structural rather than clever: treat AI output as an initial draft and never as a final product, route specialist work past a domain expert, and expect the human contribution to be the part that engages with the complexity.

Where Errors Hide

Errors cluster in predictable places, which is where your attention should go first. Specific facts and named sources are prime territory for hallucination. Precise numbers and any statistic without a cited basis are where fabrication lives. Anything time-sensitive is where staleness hides. The connective tissue of an argument, the "because" and "therefore" sentences, is where logical errors lurk. And anything written about people is where bias surfaces. Polished, confident passages deserve more suspicion, not less, because fluency is exactly the surface under which a wrong fact sits most comfortably.

The instinct to spot-check only the parts you suspect might be wrong is the trap. You catch the errors you anticipated and miss the ones you did not. Systematic review of the high-risk zones, especially every fact and every number, is what catches the surprises.

Worked Example: Catching Three Errors in One Market Summary

Back to Tomas and the competitor market summary. Here is what he found, and the specific tell that flagged each.

Error one, a fabricated number. The summary stated the competitor's market segment was worth "$4.2 billion, growing at 23.4 percent annually." The tell was the suspicious precision combined with no source. A real figure that specific comes from a named report. Tomas asked the analyst where it came from. The honest answer: the AI produced it, and the analyst had assumed it was pulled from somewhere. It was not. The whole figure was invented.

Error two, a hallucinated citation. A sentence read, "according to the 2024 Henderson Industry Review, the competitor leads in mid-market adoption." The tell was a confident, specific source Tomas had never heard of in a market he knew well. A two-minute search confirmed no such review exists. The AI had assembled a plausible-sounding authority out of nothing.

Error three, a subtle logical error. The summary concluded the competitor was "both the low-cost option and the premium quality leader," and used that to argue they were unbeatable. The tell was a claim that sounded strong but described a position that almost never holds; low cost and premium quality are usually a trade-off, not a pairing. Tracing the reasoning showed the conclusion rested on two cherry-picked data points that did not actually support it.

Three errors, three different types, three different tells: precision without a source, a citation that does not exist, and a conclusion that does not follow. None of them announced themselves. All three sat inside fluent, confident prose, which is exactly why a fast approval would have shipped every one of them. Tomas sent it back with specific notes, and the corrected version went to sales leadership a day later with real numbers and no invented authorities.

A Review Checklist

Turn the taxonomy into a short, repeatable pass. For any AI-assisted deliverable, walk these steps.

1. Underline every fact, name, and number. These are your verification targets. If it is specific, it is checkable.
2. Verify every citation actually exists. A source the AI names but you cannot find is a red flag, not a footnote.
3. Confirm anything time-sensitive is current. Prices, rankings, "latest" claims, and recent events get independent confirmation.
4. Trace the key argument. Read the "because" and "therefore" sentences slowly. Does each conclusion follow from what came before? Do any two statements contradict each other?
5. Check anything about people for fairness. Is the language even across groups? Would the recommendation change if you swapped demographic details?
6. Distrust your own first impression. If it reads beautifully and you feel the urge to approve fast, that is the moment to slow down.

A Triage Rule: What Gets Heavy Versus Light Review

You cannot deep-review everything, and you should not try. The skill is matching review intensity to risk. Tomas uses a simple two-question triage on every AI-assisted output his team submits.

• Question one: who sees it? Anything leaving the building, going to customers, executives, or partners, is higher risk than internal-only work.
• Question two: how reversible is a mistake? A wrong number in a published report or a client deck is hard to walk back. A wrong note in an internal brainstorm is cheap to fix.

From those two questions falls a clear rule. Heavy review, the full checklist, every fact and number verified, for anything external, anything with numbers a decision will rest on, and anything novel or high-stakes. Light review, a quick sanity read for obvious problems, for routine internal work where a human will use the output as a starting point and any error is easy to catch downstream. The competitor summary was external, numbers-heavy, and headed for leadership, so it earned the heaviest review Tomas had. That triage judgment is what told him to slow down instead of signing off.

Why AI Makes These Errors in the First Place

Understanding the cause makes the tells obvious instead of arbitrary. AI generates text by predicting what words tend to follow other words, not by retrieving verified facts or reasoning through logic. That single fact explains the whole taxonomy. It hallucinates because a plausible-sounding source is statistically likely even when no such source exists. It fabricates numbers because a precise figure fits the pattern of a research summary, whether or not the figure is real. It serves outdated information because its knowledge stops at a training cutoff and it does not know what it does not know. It makes logical slips because stringing together plausible sentences is not the same as checking that they cohere. It misses your context because your assumptions were never in the text, and it flattens nuance because pattern-matching is not domain understanding. And it reflects bias because the patterns it learned carry the skews of the data it learned from. Once you see that the AI is matching patterns rather than knowing things, you stop being surprised by any of these and start expecting them in the exact places they appear.

A Verification Protocol With Real Time Costs

"Verify the facts" is easy to say and easy to skip when work is moving fast. A named protocol with a known time cost is what survives a busy week. Tomas's team uses one.

1. Identify the key claims. List every fact, number, and cited source in the output. For a typical two-page summary that is usually six to ten items.
2. Verify each against a reliable source. A primary source for numbers, the actual document for citations, a current source for anything time-sensitive.
3. Flag what you cannot verify. Anything you cannot confirm does not get a pass for sounding plausible. It either gets removed or gets confirmed before the work ships.

The honest cost is about five to ten minutes for a fact-dense deliverable. That feels expensive until you weigh it against the alternative: the competitor summary, shipped unverified, would have put three errors in front of sales leadership and cost the team far more than ten minutes of credibility to recover. The protocol is cheap insurance, and over time it gets faster as the team learns which sources to check first.

Three Habits That Catch What Fact-Checking Misses

Verification catches false claims. It does nothing about the two quiet error types, and nothing about the errors you keep making. Three further habits close those gaps.

The context check, two to five minutes. Before you review the output, reread the original request. Then compare: did the AI address the full request, or only the easiest part of it? Did it use the context that was provided, or ignore it? And a question people forget to ask: would a reader who did not supply that context still understand this? Output that only makes sense to the person who wrote the prompt is not finished work. Adjust and re-prompt where the answer is no.

Expert review, for anything specialized. When the work sits in a domain where you are not the deepest expert, route it past someone who is, and ask them specifically about nuance and appropriateness rather than about correctness. The time cost varies by domain, and for high-stakes output it is simply the price of admission. An expert reading takes minutes and catches the class of problem no checklist can, because the missing consideration is by definition not on your list.

Pattern spotting, ongoing. Every time someone on the team catches an error, write it down: what type it was, what task produced it, what tell caught it. Over a couple of months, patterns appear. Perhaps your competitive research consistently invents sources while your internal summaries never do, or a particular tool fabricates numbers on one kind of prompt. Then adjust where review attention goes, and tell the team what to watch for. This habit costs no extra time, only attention, and it is what turns individual catches into a review process that keeps getting sharper.

Tailoring Trust to the Task

The goal is not blanket suspicion of everything AI produces, which would waste the very efficiency that makes it useful. Two opposite mistakes are worth naming. One is assuming the AI is always right because it is sophisticated and the output looks good; that lets systematic errors escape. The other is assuming the AI is always wrong and refusing to trust any of it; that throws away real value, because for some tasks AI is genuinely reliable.

The right stance is calibrated. Trust high-reliability output for low-risk tasks, reformatting text, drafting an internal outline, suggesting structure, where a mistake is obvious and cheap. Apply heavy skepticism to low-reliability, high-stakes output, anything involving specific facts, numbers, or external audiences. Tomas tells his team to think of AI as a fast, fluent junior researcher: useful and quick, but never the final word on a fact, and always reviewed before the work carries the team's name.

Building the Verification Habit on a Team

A manager who catches errors personally has solved the problem once. A manager who builds the habit across the team has solved it permanently. A few practices make it stick. Show real examples: walk the team through an output you reviewed, point to the made-up sentence, and explain exactly how you caught it. Practice together: review an output as a group and ask what looks suspicious and what each person would verify. Debrief without blame when an error slips through, asking "how could we have caught this?" rather than "how did you miss this?", because a blame culture teaches people to hide errors instead of surfacing them. Celebrate good catches out loud so the behavior spreads. And bake verification into your standards, so "verify every fact and every cited source" is simply how customer-facing work gets done, not a favor someone remembers to do.

Anti-Patterns Worth Naming

Five recurring postures quietly defeat all of the above. Naming them helps you notice when you or your team have drifted into one.

• Assuming the AI is always right. "It is sophisticated, and it looks good, so it is good." The errors AI makes are systematic, not random, so an absence of skepticism guarantees they escape. The correction is to verify by default, especially facts and high-stakes work.
• Assuming the AI is always wrong. "It always has errors, we cannot trust it." Blanket distrust wastes the opportunity, because for plenty of tasks the output is reliable. The correction is calibration: match the level of trust to the task and its risk.
• Checking only what you already suspect. Spot-checking the parts that feel shaky feels efficient and catches exactly the errors you anticipated. The ones that hurt are the ones you did not think to look for. The correction is systematic review of the high-risk zones, whether or not anything feels off.
• Not learning from errors. An error surfaces, it gets fixed, everyone moves on, and the same error appears next quarter. The correction is the debrief: what should we have checked, and how do we prevent this specific failure next time?
• Blaming the person for the AI's error. "You should have caught that" builds a culture where mistakes get hidden rather than surfaced, which is precisely the opposite of what error recognition needs. The correction is to treat every escape as a process question: an error got through, what did we learn, what changes?

Practice and Reflection

Error recognition is a skill built by repetition, not by reading. Five exercises, each usable this week.

• Hunt every type in one document. Take a piece of AI-generated text and deliberately look for each error type in turn: hallucination, misunderstood context, bias, missing nuance, outdated information, logical inconsistency. Going type by type is slower than reading for sense and finds far more, which is the point of having a taxonomy at all.
• Run the verification protocol once, with a timer. Pick an AI-generated piece with real claims in it, list the claims, verify each one, and record how long it took and what you found. That number is what you will use to decide how much verification your team's work actually warrants.
• Plan the teaching. Write down how you would teach your team to recognize AI errors. Which real examples would you use? Which of your own catches would make the point best? A manager who cannot explain the method cannot spread it.
• Keep an error log for a month. Have the team note every AI error they encounter, with the type and the task. At the end of the month, look for the patterns and change your review focus to match what you found.
• Design one habit. Choose the single error type your team is most vulnerable to and build a specific process to catch it. One habit that actually runs beats five that live in a document nobody opens.

Then take two minutes on this reflection. Think of an AI-assisted output you reviewed recently. Which error type did you catch, and more usefully, which type might have slipped past you unnoticed? What habit would have caught it? Write the answer down; that is your error-prevention strategy, tailored to the work you actually do.

Related Lessons

This lesson is the diagnostic half of responsible oversight. Three others complete the picture.

• When AI Assistance Crosses Ethical Lines takes the next step. You have learned to catch errors in output; that lesson deals with the prior judgment call about whether AI should be used for a given task at all.
• Establishing AI Review Checkpoints turns the triage rule here into structure. Knowing which work deserves heavy review is only useful if the review reliably happens at a defined point in the workflow.
• Coaching Team Members on AI Quality Standards is where the teaching practices in this lesson get developed properly, including how to give feedback on AI-assisted work without creating the blame culture that drives errors underground.
• Verification Workflows covers the personal discipline underneath the team process: how much checking a given output deserves, and how to keep it fast enough that you do it every time.

Key Takeaways

• Learn the error taxonomy. Hallucinated facts and citations, fabricated numbers, outdated information, subtle logical errors, and tone or bias issues are the recurring failure modes. Naming them turns review from hoping into scanning.
• Watch for the quiet two. Misunderstood context and missing nuance produce output that is not false and still not usable. Give explicit context and constraints up front, treat AI output as a draft, and route specialist work past a domain expert.
• Confidence carries no information. AI states wrong things in the same assured tone as right things, so fluent, polished output deserves more scrutiny, not less. The urge to approve fast is the signal to slow down.
• Go where errors hide. Verify every specific fact, every named source, every precise number, anything time-sensitive, the argument's "because" sentences, and any language about people.
• Each error type has a tell. Precision without a source flags a fabricated number; an unfamiliar specific citation flags a hallucination; a too-good conclusion flags a logical error. Match the tell to the type.
• Triage by exposure and reversibility. Heavy review for external, numbers-heavy, high-stakes, or novel work; light review for routine internal output that is easy to correct downstream.
• Log the errors you catch. Patterns emerge within a month or two, and they tell you where to point review attention next. Errors nobody records are errors the team repeats.
• Build the habit across the team. Show real examples, practice together, debrief without blame, celebrate catches, and write verification into your standards so it becomes how the work is done, not an afterthought.