Introduction
An AI answer can be clear, well written and wrong. That is the main trap. Good style creates an impression of reliability, but it does not prove the facts.
For personal use, an error can simply be annoying. For a company, it can create a wrong public price, a legally fragile claim, false technical information, a misleading marketing decision or content that weakens trust.
This article provides a simple checklist for auditing an AI output before using it. It does not promise zero error. On the contrary: it assumes that any important AI output must be verified before publication or decision.
Why errors happen
OpenAI guides on accuracy explain that optimizing an LLM system depends on the type of error: missing context, outdated information, missing proprietary data, inconsistent behavior, unstable format or poorly followed reasoning.
The practical consequence is simple: if the model does not have the right source, it can produce a plausible but unreliable answer. If instructions are vague, it can answer in the right tone but with the wrong level of proof. If the format is not constrained, it can produce an output that is difficult to verify.
The 4 types of errors to spot
| Error type | Example | Verification |
|---|---|---|
| False fact | Price, date, model, feature | Official source or runtime file |
| Missing context | Generic answer about a specific product | Read the exact page, code or brief |
| Unstable format | Invalid JSON, incomplete table | Structured Outputs or schema validation |
| Overstated claim | “best”, “guaranteed”, “zero error” | Business proof or removal |
Most bad AI-assisted publications come from a combination of these errors: the text sounds good, but it contains an outdated price, an unproven claim and no source.
Checklist before using an AI output
1. Identify the role of the output
Before verifying, you need to know what the output will become:
- Internal draft.
- Public article.
- Client email.
- SEO schema.
- Pricing page.
- Video script.
- Social post.
- Business decision.
The more public or sensitive the output is, the stronger the proof level must be.
2. Highlight verifiable claims
A verifiable claim is a sentence that can be true or false:
- A price.
- A number of clients.
- A performance metric.
- A model name.
- An API permission.
- A product feature.
- A certification.
- A compatibility claim.
Every claim must have a source or be rewritten.
3. Classify each claim
Use four statuses:
| Status | Meaning | Action |
|---|---|---|
| Proven | Official source, file, runtime or API | Can stay |
| Not proven | No sufficient proof | Remove or qualify |
| To verify | Probable source but not reviewed | Block publication |
| Hypothesis | Deduction or opinion | Label clearly |
4. Verify critical sources
For an AI/LLM article, critical sources are often:
- Official provider documentation.
- Official pricing page.
- Changelog or product announcement.
- Source file if the claim concerns WG.
- Live runtime if the claim concerns a page or SaaS.
- Official read-only proof if the claim concerns Meta, GA4, GSC, Stripe or an external API.
A secondary source can help with understanding, but it should not carry a sensitive claim alone.
5. Test the format when format matters
OpenAI documents Structured Outputs to force an output to match a JSON Schema. This helps reduce format errors: missing key, invalid enum, incorrect structure.
But be careful: a valid schema does not prove that the content is true. It only proves that the shape is compliant.
6. Evaluate when the output becomes a system
For a simple internal note, human review may be enough. For a repetitive system, evals are needed.
OpenAI recommends defining an evaluation objective, collecting a dataset, choosing metrics, comparing results and evaluating continuously. This avoids relying on gut feeling.
Example: if WG Writer generates articles, it is not enough to say that an article looks good. Factuality, sources, structure, SEO relevance, internal links, brief compliance and high-risk errors must be checked.
Quick audit template
Template to use before publication:
| Question | Yes/No | Proof |
|---|---|---|
| Does the output have a clear role? | ||
| Are prices verified? | ||
| Are dates verified? | ||
| Are model/tool names verified? | ||
| Are strong claims proven? | ||
| Are sources official or runtime-based? | ||
| Do internal links exist? | ||
| Does the output avoid absolute guarantees? | ||
| Is human approval required? | ||
| Is publication authorized? |
WG example: the right formulation
Formulation to avoid:
WG Writer guarantees an output with no factual error.
More cautious formulation:
WG Writer should be used with a fact-checking process, sources and human validation for public or sensitive content.
The second sentence is less spectacular, but more robust. It avoids turning a quality objective into a guarantee that cannot be proven.
When to reject an AI output
Reject the output or send it back for correction if:
- It invents a price or offer.
- It cites an API permission that is not visible.
- It claims unmeasured performance.
- It replaces strong positioning with a generic sentence.
- It creates a bio or platform post without verified character limits.
- It produces public content without a source.
- It hides uncertainty behind a confident tone.
Go further
Verified official sources
Sources rechecked on 2026-05-20 before publication.
- https://developers.openai.com/api/docs/guides/optimizing-llm-accuracy
- https://developers.openai.com/api/docs/guides/evaluation-best-practices
- https://developers.openai.com/api/docs/guides/structured-outputs
Note: AI prices, model names and features can change. Official sources must be rechecked before any budget or technical decision.