The useful thing about AI errors is that they are not random. They come in a small number of recognisable shapes, and once you can name the shapes you can catch most bad answers by reading them carefully rather than by checking every claim.
That matters because checking everything is not realistic. Nobody verifies three hundred words of output line by line, and a defence that requires it is not a defence. What works instead is knowing which sentences are the risky ones.
Shape one: the confident fabrication
This is the famous one, usually called hallucination, and the name undersells how ordinary it looks. The system does not garble. It produces a clean, well formatted, entirely invented detail in exactly the same register as the true material around it.
Fabrications cluster in predictable places. Citations and sources. Statistics with decimal places. Quotations attributed to named people. Dates. Case numbers, section numbers, page numbers. URLs. Names of studies. Anything, in short, that looks like a verifiable specific.
The reason is structural. The system learned what a citation looks like, and producing something that looks like a citation is exactly what it is good at. Whether the thing behind it exists was never part of the training pressure.
How to notice. Read back for specifics you did not supply. Every proper noun, every number, every reference the system introduced on its own is a candidate. If a claim would embarrass you to repeat, check that one and let the rest go.
Shape two: the confident average
Less discussed and more common. The answer is not false, it is just the middle of the distribution, presented as though it were considered advice about your situation.
You describe an unusual circumstance and get back the standard answer for the common case, with your details sprinkled on top as decoration. It reads as tailored and is not.
How to notice. Ask yourself whether the answer would change if you altered the most distinctive fact in your question. If you could swap "I have two hours a week" for "I have two hours a day" and the answer would still stand, the answer was never about you.
The fix is usually to push back once. "That is the generic version. Given that I have two hours a week and not two a day, which of those five would you cut?"
Shape three: agreeing with you
These systems lean heavily toward going along with the person typing. Assert something false with confidence and you will frequently be agreed with. Push back on a correct answer and it will often fold and apologise, even when it was right.
This is the failure mode that does the most quiet damage, because it turns the tool into a mirror at exactly the moments you wanted a second opinion. Ask whether your plan is a good one, having described it warmly, and you are likely to be told it is a good plan.
How to notice. Watch for a reversal that arrives without new information. If you said "are you sure?" and it changed its answer, nothing was learned, it just detected disapproval.
Two habits help. Describe your plan neutrally, or describe it as somebody else's. And ask for the case against rather than for an assessment: "give me the three strongest arguments that this is a bad idea" produces far better material than "is this a good idea?"
Shape four: the stale answer
Training stopped on a date. Anything after that date is either unknown or, worse, answered from how things were before, with no signal that the ground has moved.
This bites hardest on prices, product features, software instructions, rules, rates, thresholds, who currently holds a position, and anything where the thing changed but the old version is still the pattern in the training text.
How to notice. Ask directly. "Is this current, and how would you know?" A system that can search will tell you it looked. One that cannot will often admit the limit if asked plainly, and will rarely volunteer it.
The sentences worth checking
- Any number with a decimal point.
- Any name, title, study or source you did not supply.
- Anything presented in quotation marks.
- Any instruction about how to do something in a specific piece of software.
- Any claim about what is currently true.
- Any answer that agrees with something you asserted rather than asked.
Why it never says it does not know
Because it mostly cannot tell. There is no separate part of the system holding a confidence level about the world and deciding whether to speak. There is one process producing plausible continuations, and "the Companies Act 2006 section 172" is a highly plausible continuation whether or not that section says what follows.
Some newer systems hedge more, and some can check a source and tell you what they found. Both help. Neither turns the confident tone into a reliable signal, and treating fluency as evidence remains the single most expensive mistake available.
What this does not mean
It would be easy to read the above as a case against using any of it. That is not the conclusion, and the people who reach it tend to be arguing from an assumption nobody actually holds, which is that the tool should be trusted like a reference book.
Judge it against the right comparison. For drafting, restructuring, summarising something you will read anyway, explaining an unfamiliar term, or producing twenty options when you were stuck at zero, the failure modes above barely matter, because you are the one checking the output against a task you understand. For anything where you would want a citation, they matter enormously.
The distinction worth internalising is between using it to produce and using it to know. Producing is where it is strong and where the errors are cheap, because they are visible to you immediately. Knowing is where the errors are expensive, because a fabricated fact in an area you are unfamiliar with is indistinguishable from a real one. Almost every story about somebody being badly let down by one of these systems is a story about using it in the second mode while thinking they were in the first.