AI Hallucinations Cost Real Money in 2026. Here's How B2B SaaS Founders Stop Them.

1 Give the model permission to say "I don't know"

Anthropic's number one recommended technique, sitting at the top of their official Reduce Hallucinations documentation, is also the most underused: explicitly tell the model that uncertainty is acceptable (Anthropic — Reduce Hallucinations).

Without that permission, the training objective rewards confident response. The model fills gaps because filling gaps is what training data taught it people want. Once you give the model an explicit out, it uses it.

Verbatim prompt to add to any system prompt or instruction:

If you do not have enough information to answer with confidence, say "I do not have enough information to answer this" and stop. Do not guess. Do not infer. Do not extrapolate.

This single sentence is free. It takes 30 seconds to add. It works on Claude, ChatGPT, Gemini, and any other major LLM because the underlying training problem is universal — every frontier model is incentivized to bluff unless told otherwise.

This is the foundation. The other four techniques layer on top of this one.

2 Set temperature to 0 for any factual task

This is an API-level setting most teams never touch. They run their production AI calls at the default temperature (typically 0.7 or 1.0) without realizing what that number controls.

Temperature controls randomness in token selection. At temperature 1.0, the model picks among many plausible next tokens, weighted by their probability. At temperature 0, the model picks the single most probable token every time. The output becomes deterministic — the same prompt produces the same answer every run (OpenAI temperature documentation).

For creative writing, temperature 0.7 to 1.0 is correct. For anything factual — extracting data from a document, generating a summary, answering a customer question against a knowledge base, classifying intent, scoring a lead — temperature 0 should be your default.

What this looks like in code:

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    temperature=0,   # this line
    messages=[...]
)

One line. Zero cost. Material reduction in inconsistency between identical queries.

The reason most teams miss this: tutorials and quickstart guides default to higher temperatures because they make demos look more "creative." Demos are not production. In production, you want predictable, repeatable, debuggable output.

Caveat: at temperature 0, models can occasionally get stuck in repetitive output patterns. If that becomes a problem, set temperature to 0.1 or 0.2 — still nearly deterministic, with enough variation to break repetition loops.

3 Run a two-model judge gate before any AI output reaches a customer

This is the technique that caught the BCAA hallucination from the opening of this post.

The pattern: your primary model (the expensive one — Claude Sonnet, GPT-4) generates the response. Before that response reaches the customer, a cheap secondary model (Claude Haiku, GPT-4-mini) gets the source documents plus the generated response and answers a single binary question per claim:

Does this claim appear in the source documents? Yes or No. If No, output: REJECT.

Any REJECT routes the response to manual review. An all-pass routes the response to send.

The cost is trivial. Claude Haiku 4.5 runs around $0.25 per million input tokens and $1.25 per million output tokens. For a typical 1,000-token verification call (roughly 800 input + 50 output), that works out to about $0.0003 per call — roughly $0.30 per 1,000 verifications. Compare against the cost of one fabricated customer name in a cold email going to a 10,000-prospect campaign — domain reputation damage compounds fast and silently.

What makes this different from asking the same model to verify itself: a different model has a different training-data baseline and different bias patterns. Self-verification has well-documented blind spots — the model that generated the fabrication tends to also rationalize it. Cross-model verification catches what same-model verification misses.

This builds on Anthropic's "verify with citations" technique by adding cross-model robustness — Anthropic's official guidance is to have the model find a supporting quote and retract any claim it cannot support; using a different model to do that retraction step removes the documented blind spot of self-verification (Anthropic — Reduce Hallucinations).

Production sketch:

def safe_generate(prompt, source_docs):
    # Primary model generates
    answer = sonnet.generate(prompt, source_docs)

    # Secondary cheap model judges
    verdict = haiku.judge(
        question=f"Does '{answer}' have support in {source_docs}?",
        return_format="REJECT or APPROVE"
    )

    if verdict == "REJECT":
        return MANUAL_REVIEW_QUEUE
    return answer

Every customer-facing AI feature in your product should have a judge gate. Not the agentic ones. Not the back-office ones. The customer-facing ones — the ones where a fabrication ends in a churn email instead of an internal log.

4 Force structured outputs (JSON schema) instead of free-form text

Free-form text gives a model maximum room to fabricate. Structured outputs give it almost none.

Both OpenAI and Anthropic support structured outputs natively. OpenAI calls it Structured Outputs (OpenAI Structured Outputs docs). Anthropic implements the same pattern through tool calling. The mechanics are identical — you define a JSON schema describing exactly what the response must contain, and the model generates conforming output or fails.

Why this kills a whole class of hallucinations: a free-form prompt asks the model "tell me about this customer." The model generates plausible prose. Plausible prose is the enemy. A schema-constrained prompt asks the model to fill in this exact object:

{
  "type": "object",
  "properties": {
    "customer_name": {"type": "string"},
    "plan_tier": {
      "type": "string",
      "enum": ["starter", "pro", "enterprise"]
    },
    "mrr_dollars": {"type": "integer"},
    "signup_date": {"type": "string", "format": "date"}
  },
  "required": [
    "customer_name", "plan_tier",
    "mrr_dollars", "signup_date"
  ]
}

The model has nowhere to invent — every field has a type and a constraint. If the source data does not contain a plan tier, the model has to either return null or refuse the call.

OpenAI documents that Structured Outputs guarantee schema conformance for supported models (OpenAI Structured Outputs docs). That guarantee is the closest you can get to "the model literally cannot lie about the shape of its answer."

When to use it: any production AI feature where the output gets parsed downstream. Lead scoring. Customer classification. Data extraction. Form filling. Anywhere a person or another system reads the result programmatically.

When not to use it: open-ended creative output (drafting an email, summarizing a meeting). For those, layer it with Technique 3 — generate free-form, then run a structured judge gate that returns { "verdict": "APPROVE | REJECT", "failed_claims": [] }.

5 Best-of-N consistency voting for critical answers

Anthropic documents this as an advanced technique in their guardrail guidance: run the same prompt multiple times and only ship the answer that appears in the majority (Anthropic — Reduce Hallucinations, advanced techniques section).

The mechanics: for any high-stakes generation, run the prompt three or five times. Compare outputs. If the model gives the same factual answer in all runs, ship it. If two runs give one answer and one gives another, you have detected uncertainty the model itself did not flag. Route to manual review.

Cost: 3 to 5 times the inference cost on the calls you apply this to. Not appropriate for every call. Appropriate for the calls that matter — anything customer-facing in regulated industries, anything that informs a downstream automated decision, anything where being wrong is more expensive than being slow.

Where this catches what other techniques miss: a deterministic temperature-0 call always returns the same answer, even if that answer is wrong. Best-of-N at temperature 0.7 across 5 runs surfaces inconsistency the model would never flag itself. The 4-out-of-5 pattern is a signal that the answer is probably right. The 2-2-1 pattern is a signal that the model genuinely does not know — even if it answered confidently each time.

This is your last line of defense before a high-stakes generation reaches a customer.