How Do You QA an AI-Drafted Case Study Before It Goes Live?

How do you check an AI-drafted case study before it goes live?

Check it against the source, not against your memory. Every number, quote, timeline, and named tool in the draft must trace to an interview note, a customer email, or a report the customer approved. Anything that does not trace gets cut. Then the customer reviews the final version before you publish it.

AI models are very good at turning messy interview notes into a clean story. That is exactly why they are risky for case studies. A model that is asked to make a story compelling will fill gaps with details that sound right. A plausible percentage. A tidy quote nobody said. A timeline that is a little shorter than reality.

Each of those small inventions is a problem. A case study is proof. If a buyer, the customer, or an AI assistant later finds a claim that does not hold up, the damage reaches every other page on your site. A QA checklist is how you keep the speed of AI drafting without that risk.

Why are case studies riskier to draft with AI than blog posts?

Because a case study makes specific claims about a real company and real people. A blog post can be wrong in a general way. A case study that invents a metric or a quote misrepresents a named customer. That can damage the relationship, mislead buyers, and in some places create legal exposure for fake testimonials.

The legal side is worth knowing about, even if you are not in a regulated industry. In the United States, the Federal Trade Commission announced a final rule on August 14, 2024 banning fake reviews and testimonials. The FTC said the rule covers reviews that misrepresent they are by someone who does not exist, such as AI-generated fake reviews, and reviews that misrepresent the reviewer's experience.

I am not a lawyer, and how that rule applies to a specific B2B case study is a question for your own counsel. But the direction is clear. Regulators treat invented testimonials as deception, and they have named AI generation specifically. That is reason enough to treat every quote and claim in a case study as something you must be able to prove.

The commercial risk is more immediate. Customers who agree to a case study are doing you a favor. If the published version credits them with results they never saw, you may lose the reference, and the customer.

What should the AI be allowed to do in a case study draft?

Let the AI structure, shorten, and clarify. Do not let it add facts. Give it the interview transcript and approved notes, and instruct it to use only what those sources contain. Its job is to organize the customer's own words and numbers into a readable story, not to make the story more impressive.

This is how I use AI for most drafting, and I described the broader workflow in my piece on whether AI should write your first draft. The model is good at turning a long, rambling interview into a clear sequence of problem, approach, and result. It is bad at knowing which details are true.

The prompt matters. I tell the model to mark any sentence it could not source with a clear tag, and to leave numbers out rather than estimate them. I also tell it to keep quotes word for word from the transcript, with no cleanup beyond removing filler words. Those three instructions catch most of the problems before review even starts.

What goes on the case study QA checklist?

The checklist covers five things: every number traced to a source, every quote matched word for word to a transcript, every named tool and product confirmed, the timeline checked against real dates, and the overall framing checked so it does not claim more credit than the work earned. Each item needs a yes before publishing.

Numbers come first because they are the most likely to be invented and the most likely to be quoted elsewhere. For each figure, I note where it came from: the customer's own dashboard, an email from their team, or the interview. If the customer said "about half," the draft says "about half," not a precise percentage.

Quotes come second. I search the transcript for each quote in the draft. If the exact words are not there, the quote is either rewritten as a paraphrase without quotation marks or cut. AI models tend to merge two real sentences into one smoother one. That merged sentence is not a quote anymore.

Named tools, timelines, and framing come last. If the draft says the customer moved from one CRM to another, confirm both names. If it says the project took six weeks, check the dates. And read the whole piece once for credit: does it describe what the customer did, or does it quietly make your product the hero of every step?

How do you trace each claim back to a source?

Keep a simple claims table beside the draft. One row per checkable sentence, with the claim, the source, and the exact supporting words. If a row has no source, the sentence goes. This takes minutes for a short case study and turns review from opinion into a checklist.

I use the same habit for my own articles. Every checkable sentence in a piece like this one is logged with its source before it publishes, and anything I cannot support is removed. It is slower than trusting the draft. It is much faster than issuing a correction.

The table also helps the customer. When you send the draft for approval, you can include the sources for the numbers. That makes it easy for their team to confirm quickly, and it shows you took their story seriously.

What should you do when the customer cannot share numbers?

Write the case study without them. A clear story about the problem, the decision, the approach, and the qualitative result is more credible than a vague or invented metric. Describe what changed in the customer's own words, and let the reader judge. Never fill a gap with a number that sounds plausible.

This happens often in B2B. Legal teams restrict figures, or the customer simply does not track the metric you hoped for. An AI model will happily suggest something like "improved efficiency by 40%." That sentence is the single most dangerous output in the whole process.

There are good ways to tell a strong story with limited data. I covered several in how to write a customer story when the customer cannot be named. The same principles apply when the customer can be named but the numbers cannot.

Why does this matter for AI search and citations?

Because AI assistants quote case studies as evidence. When a buyer asks an assistant which tools work for their situation, a clear, specific case study is exactly the kind of page that gets cited. If that page contains an invented claim, you have just taught an AI system to repeat something false about your product and your customer.

Answer engines reward pages that state concrete facts clearly. That is good news for honest case studies. A short page that names the customer, the problem, and a verified result in plain sentences is easy to quote accurately.

It is bad news for inflated ones. A made-up metric on your site can spread into AI answers that you do not control and cannot easily correct. The safest case study for AI search is the same as the safest one for buyers: specific, sourced, and approved by the customer.

How many case studies should go through this process?

All of them, including old ones. Run new AI-drafted case studies through the full checklist before publishing, and audit existing ones the next time you touch them. A small library of fully verified case studies is worth more than a large library with a few invented claims hiding inside it.

Most B2B sites need fewer case studies than they think. Quality and fit matter more than volume. I made that argument in how many case studies a B2B site actually needs, and it applies doubly when each one needs real verification.

When you audit old case studies, focus on the numbers and quotes first. Those are the claims most likely to be repeated by buyers, partners, and AI assistants.

What should you do next?

Write your case study prompt so the model uses only the transcript and approved notes, tags anything unsourced, and never estimates numbers. Build a one-page checklist covering numbers, quotes, names, timelines, and framing. Then run your next case study through it, with a claims table, before the customer sees the draft.

AI can make case study production much faster, and I think every B2B team should use it for that. The speed is only worth having if the result is something your customer would happily put their name to, word for word.

If you want help setting up an AI content workflow with real QA built in, for case studies or anything else on your site, reach out. I am happy to share how I would set it up for your team.