Short answer. Quality control for AI-generated content is a risk-based system with checks placed where errors are introduced, not a review at the end. Automated checks handle everything expressible as a rule — banned terms, missing disclaimers, broken links, dimensions, subtitle timing, glossary conformance, duplicate passages. Human reviewers handle what cannot be stated as a rule: factual accuracy, instruction compliance, brand fit, safety, cultural reading and whether the asset serves its purpose. Review depth is set by the consequence of an error rather than applied uniformly, sampling is stratified by template, language, model and content type rather than drawn globally, and every defect is recorded by cause rather than as a pass or fail — because a defect count tells you the programme has a problem and a defect taxonomy tells you where.
The distinguishing feature of generative production is that output volume rises by an order of magnitude while review capacity does not. That fact makes uniform review impossible and makes the QA design the thing that determines whether a programme scales or stalls. This guide is operator-side. Evaluating a vendor who runs one for you is covered in how to evaluate AI content review vendors.
Why a single final review is not enough
AIGC defects originate at six distinct points, and a reviewer at the end sees only their combined effect. By then, the cheap fixes have all expired.
| Where the error enters | Typical defect | The check that belongs here |
|---|---|---|
| Source material | Outdated facts, superseded claims, wrong version | Validate and date source packs before they enter generation |
| Prompt or template | Ambiguous instruction producing inconsistent structure | Test the template on a hard sample; version it |
| Model output | Fabricated claims, tonal drift, artefacts | Automated screening plus human factual review |
| Editing and assembly | Meaning changed during a cut or rewrite | Fidelity check against the approved source |
| Localisation | Register, idiom, legally unsayable claims | In-market native review, per market |
| Delivery | Format, dimensions, metadata, platform specification | Automated pre-flight against the delivery spec |
The economics are the argument. A defect introduced in a template and caught at the template costs one edit. The same defect caught after that template has produced four hundred assets across nine markets costs four hundred corrections and nine re-approvals — and the template is still wrong until someone traces it back.
The practical rule: place a check immediately after each point where an error can be introduced, and make the earliest checks the cheapest ones so they can run on everything.
What can be automated
Automate anything that can be stated as a rule and verified deterministically:
- Banned terms, required disclaimers, approved glossary conformance
- Broken links, missing fields, malformed metadata, schema validity
- File dimensions, resolution, duration, loudness, colour space
- Subtitle and caption timing, character-per-line limits, reading speed
- Duplicate or near-duplicate passages across the corpus
- Numeric and date formatting, currency and unit conventions per market
- Presence of required provenance fields
Models can extend this into probabilistic triage — flagging passages that look like unsupported claims, classifying likely policy issues, ranking assets by how much attention they probably need. That is genuinely useful and it has a hard boundary: automation should triage, not manufacture certainty. A confidence score on a novel content type is a number, not a judgement, and a routing rule that trusts it will send exactly the unusual assets past the humans.
One more automated check earns its place and is rarely present: conformance of the asset to its own provenance record. If the record says a market-specific template was used and the asset does not carry that market's disclaimer, something has gone wrong upstream, and this is the cheapest place to detect it.
What humans review, and who owns each dimension
Split the review by dimension rather than assigning "a reviewer". Different dimensions need different people, run at different sampling rates, and fail in ways that do not correlate.
| Dimension | Question | Typical owner |
|---|---|---|
| Factual accuracy | Is the claim true, and checked against what? | Editorial or subject-matter reviewer |
| Instruction compliance | Did it do what the brief asked? | Producer |
| Completeness and relevance | Does it serve the communication goal? | Producer or channel owner |
| Brand and tone | Does it conform to identity and prohibited claims? | Brand reviewer |
| Policy and legal | Is it sayable, here, to this audience? | Legal or compliance |
| Localisation | Does it read as natively written, and does the idea travel? | In-market native reviewer |
| Accessibility | Captions, alt text, contrast, reading level | Production QA |
| Production quality | Does it meet the delivery specification? | Production QA, largely automated |
The one that most often has no owner is factual accuracy with a defined standard behind it. "The editor checks the facts" is not a standard. A standard says which classes of claim must be verified against a source, which may pass on reviewer judgement, and what counts as an acceptable source. Without it, the programme carries whatever fabrication rate the model produced that day, distributed unevenly across reviewers.
How to tier review by risk
Uniform review is the reason AIGC programmes stall: it makes review capacity the ceiling on output. Tier it by the consequence of an error.
| Tier | Content | Review |
|---|---|---|
| Low | Internal drafts, working documents, exploratory concepts | Automated checks plus a sampled read |
| Medium | Public marketing, product copy, social variants | Automated checks plus full brand and factual review |
| High | Regulated or substantiated claims, financial or safety-related material, high-visibility assets | Full review plus named specialist or compliance approval |
| Variant | Mechanical variations of an already-approved asset | Automated conformance plus sampled human check |
The variant tier is the one that makes scale possible, and it depends on a property worth protecting: a variant is only a variant if the approved element is genuinely unchanged. Once a "variant" alters a claim, it has become a medium or high tier asset and must be routed as one. Encode that in the workflow rather than in a policy document.
Sampling within the low and variant tiers should be stratified by template, language, model, content type and creator — never drawn globally. A global sample is dominated by the highest-volume template in the highest-volume language, and the failures worth catching are concentrated in the smallest cells.
The defect taxonomy is the artefact
Recording pass or fail teaches nothing. Recording what was wrong and where it came from is what converts QA from a cost into a feedback mechanism. Record per defect:
- Class — factual, brand, tonal, structural, safety, localisation, legal, visual, technical.
- Severity — does it block delivery, require correction, or sit as a note.
- Origin — source material, template, model, edit, localisation, delivery.
- Attributes — which template, model and version, language, content type, reviewer.
- Resolution — what was changed, and whether an upstream artefact was changed too.
Two numbers follow from that record and neither is available without it.
Defect escape rate = Defects found after delivery ÷ (Defects found in QA + Defects found after delivery)
Escape rate is the only metric that measures the QA system itself rather than the content. Everything else measures the production. A rising escape rate at a steady rejection rate means review is being applied but not catching things — which usually means volume grew, sampling did not, and the tiers are stale.
Defect density = Defects per finished asset, reported by class
Reported by class, defect density tells you where to invest. Technical defects mean fix the delivery spec. Brand defects mean tighten the template and reference set. Factual defects mean move review earlier and define the fact-check standard. Localisation defects mean the in-market reviewer was added too late in the sequence.
How quality data changes the next cycle
Every correction is evidence about a system, not just about an asset. Four uses, in ascending order of return:
- Fix the asset. The minimum.
- Fix the artefact that produced it — the prompt, the template, the source pack, the style rule, the negative-example set. One template fix prevents the defect across every future asset from that template.
- Change the routing. A content type with persistent factual defects belongs in a higher tier; one with a long clean record belongs in a lower one. Tiers should move on evidence rather than being set once.
- Change the model or the mode. A defect class concentrated in one model, or in generation-from-brief rather than transformation-of-source, is a procurement or workflow signal rather than a review problem.
The test of a mature programme is simple to state: it can say not only how many assets it produced, but which defects occurred, where they came from, and whether the rate is falling. A programme that can only report volume has a dashboard rather than a quality system — and output volume is the metric that improves automatically when everything else is going wrong.
How Lifewood approaches this
Lifewood runs AIGC quality control as a layered system rather than a final gate: source packs validated before generation, templates versioned and tested, automated screening on everything, human review by dimension with the depth set from risk, and defects recorded by class, severity and origin so corrections return to the artefact that produced them. Human-in-the-loop review is a required stage in the pipeline, and the review level is defined per content type at scoping rather than assumed.
Localisation review is where the delivery model is hardest to replicate: 50+ languages, 40+ delivery centres across 30+ countries and 56,788 registered contributors mean in-market native reviewers in markets where general-purpose vendors fall back to machine translation with a spot check, and 414,120 training hours in 2025 is what keeps rubric application consistent as reviewer cohorts change. Engagements span frontier-model labs, voice-AI developers, AI compute vendors, computer-vision suppliers and autonomous-mobility programmes, with client identities withheld by agreement. The AI-data heritage runs to 2004, with the current company established in 2018.
See AIGC services, AI data validation and the QA process.
Sources and further reading
- Google Search Central, Guidance on AI-generated content.
- NIST, Reducing Risks Posed by Synthetic Content — on transparency and provenance for generated media.
- Companion guides: How to Evaluate AI Content Review Vendors and Measuring an AIGC Programme.