Content governance decides what your AI is allowed to produce, who signs off, and how outputs get labeled. Guardrails are the code that enforces those decisions at runtime. Confuse the two and you end up with a policy nobody applies and filters nobody wrote rules for.
A watermark is not a policy. A content filter is not governance. We keep meeting teams that bought a moderation API, wired it into their chatbot, and called the problem solved. Then legal asks who approved the marketing copy the model wrote, and nobody can answer, because the approval step was never designed. Content governance and runtime guardrails are two different layers doing two different jobs, and both have to exist.
Two layers, one pipeline
Think of content governance as the rulebook and guardrails as the referee. The rulebook is written by humans, mostly away from the codebase: it says which content types need a human reviewer before publication, which subjects are off-limits, when an output has to carry an "AI-generated" label, and who owns the result. The referee is code sitting on the request-response path, checking each input and output against those rules in milliseconds and blocking what fails.
You can have a beautiful rulebook and no referee. That's a governance deck that never touches production. You can also have a referee with no rulebook, which is what a raw toxicity classifier is: it blocks slurs but has no opinion on whether your model should be drafting legal advice at all. Our content governance work always defines the policy layer first, then maps each rule to a runtime control, so nothing in the rulebook is aspirational.
What content governance actually covers
The policy layer breaks into five decisions, and each one is a human judgment, not a setting.
Provenance. For every output that matters, you should be able to say what produced it and how: the prompt, the model and version, the retrieved sources, and any human edits. For images, audio, and video, we lean on C2PA Content Credentials, the cryptographically signed manifest standard backed by Adobe, Microsoft, Google, and the BBC. For text, provenance is mostly your own generation logs, because text watermarks are fragile. A green-list/red-list statistical watermark clears a z-score above 4, but a single round of paraphrasing can strip it.
Approval workflows. Decide which content classes need sign-off before they leave the building. High-visibility marketing, anything published under the company name, and anything with legal exposure get a named reviewer. Internal scratch work does not. Write this down as a matrix, because "use judgment" is how unreviewed content ships.
Prohibited content. The rulebook names what the system must never generate, regardless of how it's asked. This is where you encode both regulatory red lines and your own: no synthetic media of real people without consent, no fabricated citations, no competitor disparagement.
Human review. The most protective thing we do for IP is refuse to treat AI output as a finished product. Under current US law, purely machine-generated content without meaningful human authorship may not be copyrightable (Thaler v. Perlmutter, 2023). So we design hybrid workflows where the model is a starting point and a human materially edits, selects, and arranges. That protects the work and catches errors.
Labeling and disclosure. Some disclosure is legally required, not optional. The EU AI Act's Article 50 sets transparency obligations that a content policy has to encode directly.
The disclosure rules you can't hand-wave
Article 50 is specific, and vague internal guidance won't satisfy it. Here's the short version we build policy against:
| Context | Disclosure | Basis |
|---|---|---|
| Chatbots interacting with people | Required | Art. 50(1) |
| Synthetic audio, image, video, text | Machine-readable mark | Art. 50(2) |
| Deep fakes | Required | Art. 50(4) |
| Marketing content | Recommended | Consumer protection |
| Internal documents | Optional | Internal QA |
Article 50(2) is the one teams miss: providers of systems that generate synthetic media must mark outputs in a machine-readable format so they're detectable as artificially generated. That's a build requirement, not a footer you add later. There's a carve-out for AI-assisted content under genuine human editorial control, which is another reason the human-review step earns its place.
Where guardrails do the enforcing
Once the rulebook exists, LLM guardrails turn each rule into a check at a specific point in the pipeline. Guardrails run at two boundaries.
On the way in, input guardrails validate the prompt: PII detection redacts or rejects personal data, topic restrictions block prohibited subjects, and injection detection catches attempts to override the system instructions. On the way out, output guardrails validate the response before the user sees it: PII scrubbing and secret detection stop leaks, a factuality check flags claims unsupported by your retrieved sources, schema validation enforces structured formats, and a brand-safety pass blocks off-brand or competitor mentions.
Four configuration defaults carry most of the weight, and we set them the same way every time:
- Fail secure. When a guardrail is uncertain or errors, block the content. Don't let it through on a shrug.
- Layered defense. No single check. Overlapping guardrails at different stages, because any one of them will be bypassable.
- Audit logging. Every trigger gets logged with the input, the action taken, and the reason. This is the record that proves the policy was enforced, which is the whole point when a regulator asks.
- Graceful degradation. When you block, say something useful. A dead end trains users to route around you.
The factuality guardrail is where the two layers meet most visibly. Your policy says outputs must be grounded; the runtime enforcement is retrieval-augmented generation with citation checking, verifying that each claim actually traces to a source document rather than trusting the model's confidence.
Making the two layers talk
The failure we see most is a policy layer and a runtime layer built by different teams that never reconciled. Legal writes a content standard; engineering ships a filter; the standard says "no medical advice" and the filter only knows how to catch profanity. Close that gap by treating every rule in the governance document as a ticket: it isn't done until a guardrail enforces it and a log proves the enforcement.
Recommendations, in order:
- Write the rulebook before you tune a single filter. List content types, approval owners, prohibited categories, and disclosure obligations.
- Map each rule to a specific guardrail at a specific pipeline stage. If a rule has no runtime enforcement, it isn't a control, it's a wish.
- Encode Article 50 directly: machine-readable marking for synthetic media, clear disclosure for chatbots and deep fakes.
- Require human review for anything published externally, and log the human edits, both for quality and for IP protectability.
- Turn on audit logging for every guardrail trigger and review it. The log is your evidence that governance is real.
The full RAI framework treats these as one continuous system rather than a policy binder and a separate pile of code, which is the only version that survives contact with production.