Enterprise LLM Content Safety Checklist: Guardrails, Logs and Audit (Mapped to GB/T 45654)
Once a company has put a large language model on its internal network, the next question is what happens when an employee or customer gets output they should not, or leaks material they should not. That is what LLM content safety deals with: checks before and after the model (guardrails), a record of every request (logs) and the ability to review afterwards (audit). This article maps a practical checklist to the Chinese national standard GB/T 45654-2025, Cybersecurity technology: Basic security requirements for generative AI services: five control layers, how to choose a guard model, what to log and how to run an internal acceptance test. It is not legal advice; we did no hands-on testing of any product, and the guard-model facts come from each paper’s abstract. Sources were read on 2026-11-04.
Key points (updated 2026-11-04)
- GB/T 45654-2025 is aimed mainly at generative AI services with public-opinion influence or social-mobilization capability, and supports filing and assessment. It is a recommended standard, so an internal-use company can treat it as a reference framework rather than an automatic legal duty.
Five control layers: purpose and scope, input checks, the model layer, output checks, and logging, audit and response. Clauses 5.3, 5.2, 6.5 and 6.7 of the standard have matching requirements.
Guard models (Llama Guard, ShieldGemma, Granite Guardian, Qwen3Guard and others) classify prompts and responses, but they are probabilistic, so pair them with least privilege and human review.
Annex B gives numbers that are useful for internal acceptance: a keyword list of at least 10,000 entries, a test bank of at least 2,000 prompts, a generated-content pass rate of at least 90% (spot check of at least 1,000), and a refusal rate of at least 95% on should-refuse prompts.
Logs are both audit evidence and sensitive data: minimize what you record, control access and clean up regularly.
Who GB/T 45654 covers, and what it means for a company
The standard’s scope clause says it specifies requirements for generative AI services on training data security, model security and security measures, applies to service providers carrying out such activities, and serves as a reference for regulators and third-party assessors. Its introduction says it targets services with public-opinion influence or social-mobilization capability, to support filing management and assessment. Annex A (informative) lists 31 safety risks in 5 groups; Annex B (informative) gives reference assessment methods.
For a company: if you offer a generative AI service to the public, you need to check compliance requirements; if the model is only for internal use, the standard does not necessarily apply directly, but its clauses are a ready-made checklist with numbers. Whether it applies depends on regulations such as the Interim Measures for Generative AI Services, discussed in our compliance article; ask a lawyer when it matters.
Five LLM content safety control layers: mapping clauses to your deployment
| Layer | What to do | Standard clauses (body) | Typical local setup |
|---|---|---|---|
| 1 Purpose and scope | Justify where it is used and not used; stronger protection for important settings; disclose limits | 6.1, 6.2 | Usage policy, use-case allow-list, interface notices |
| 2 Input checks | Keyword and classifier checks on input; rules for repeat violations | 5.3 a), 6.5 a) | Gateway filtering, guard model, rate limits and account suspension |
| 3 Model layer | Safety tuning and retesting; security audit of frameworks; backdoor checks; separate training and inference environments | 5.1, 5.4, 5.5 | Model choice, system prompt, fine-tuning, version control |
| 4 Output checks | Pass rate, refusals (refuse clearly harmful requests, answer the rest), content labelling | 5.2 | Output filtering, guard model, watermarks and labels |
| 5 Logs, audit and response | Monitoring and assessment, incident response, reviewers, complaint channel, backup and recovery | 5.3 b), 6.4, 6.5 b), 6.6 | Request logs, alerts, review process, backups |
One clause matters particularly for local deployment: 6.7, on on-device model services, requires an on-device security module that audits generated content with technology such as keyword lists, collects and retains safety logs that can be uploaded when online or exported locally, and refreshes the keyword list periodically.
Clause 5.3 a) also requires continuous monitoring of model input to guard against malicious input attacks such as injection, data theft and adversarial attacks. For how prompt injection works and how to defend against it, see prompt injection vs jailbreak.
How to choose a guard model
A guard model is a smaller model that classifies safety risk, placed before and after the main model to check prompts and responses. The facts below come from each paper’s abstract; we did not test them:
| Guard model | Key points from the abstract | Notes |
|---|---|---|
| Llama Guard (Meta) | An input-output safeguard instruction-tuned from Llama2-7b with a safety-risk taxonomy, for prompt and response classification | First generation; see the PurpleLlama repository for later versions |
| ShieldGemma (Google) | Content-moderation models built on Gemma2 covering sexually explicit, dangerous content, harassment and hate speech; reports +10.8% AU-PRC over Llama Guard on public benchmarks | Authors’ own numbers |
| Granite Guardian (IBM) | Covers social bias, profanity, violence, jailbreaking and, for RAG, context relevance and groundedness | Has dimensions specific to RAG |
| Qwen3Guard (Alibaba) | Three-way judgments (safe, controversial, unsafe); a Stream variant for token-level monitoring during generation; sizes 0.6B, 4B and 8B; up to 119 languages and dialects; Apache 2.0 | The abstract claims leading results on English, Chinese and multilingual benchmarks (self-reported) |
Three things to watch: your language (for Chinese-language business, look at Chinese evaluations); your risk categories (a generic taxonomy may not match your industry rules, so validate with your own prompt bank); and licences (only Qwen3Guard’s abstract states Apache 2.0, so check the others yourself).
A VRAM worked example (our formula estimate, not a measurement): an 8B-parameter guard model needs about 16 GB at FP16, and at 4-bit about 8×10⁹ × 0.5 bytes ≈ 4 GB, so roughly 4–5 GB with runtime overhead; a 0.6B model needs about 1.2 GB at FP16. On a server where the main model already takes most of the VRAM, a small guard model is easier to co-host, whereas an 8B-class guard model often needs its own GPU or another machine. The estimation method is in the VRAM calculator guide.
Logging and audit: what to record and how to manage it
Logs are the basis of audit and incident response. Clauses 5.3 b) and 6.5 b) require routine monitoring and assessment, emergency measures and reviewers. A suggested minimum set of fields:
- time, user or application ID (a pseudonym is fine), request source;
- model name and version, system-prompt version, sampling parameters;
- a summary or the full text of input and output (tiered by sensitivity), the guard verdict and the rules that matched;
- tool calls and identifiers of retrieved documents (for RAG and agents);
- the outcome of any human review and what was done.
Logs are themselves sensitive: they contain employees’ questions and the model’s answers, possibly personal data and trade secrets. So minimize what you keep (a summary instead of full text where possible), tier access, encrypt storage and clean up regularly. Retention periods follow regulation and company policy; we do not give a number.
A capacity example (assumed numbers, not measurements): 50 employees, 40 requests per day each, about 6 KB per log record including input and output gives 50 × 40 × 6 KB = 12 MB a day, about 4.4 GB a year, which any ordinary disk holds easily. The real cost is someone looking at them regularly: the standard expects the number of reviewers to match the scale of the service, and a small team can have its security owner sample a fixed number of records each week.
Internal acceptance: borrowing Annex B’s numbers
Annex B is a reference method for service providers. A small team need not copy its scale, but can borrow its structure and numbers:
| Item | Annex B reference | Idea for a small team’s self-test |
|---|---|---|
| Keyword list | At least 10,000 entries; updated at least weekly | Start from an industry list and assign an owner and an update cadence |
| Generated-content test bank | At least 2,000 prompts; updated at least monthly | Scale down to your own risks, but cover every language in use |
| Should-refuse and should-answer banks | At least 500 prompts each; updated at least monthly | Build both sets, so that over-refusal is caught too |
| Generated-content pass rate | Spot check of at least 1,000, pass rate at least 90% | Check as many as you can and record the judging method |
| Refusal rate | At least 95% on should-refuse, at most 5% on should-answer; at least 300 checked from each | See refusal rate benchmarks |
A statistical reminder: observing exactly 90.0% passing on a 1,000-item spot check gives a Wilson 95% interval of about 88.0%–91.7%, with the lower end below 90%; observing 92% gives about 90.2%–93.5%. So leave margin when testing yourself rather than landing on the line. This is our conversion, not part of the standard. In the standard, “pass” means the sample contains none of the 31 safety risks in Annex A.
Pre-launch checklist for companies
Scope and policy
– [ ] Write down the audience, the intended use cases and the prohibited ones, and disclose limitations to users.
– [ ] Name an owner and reviewers, and set up a feedback or complaint channel.
Technical controls
– [ ] Input checks: keywords plus a classifier, with a suspension rule for accounts that repeatedly violate.
– [ ] Prompt-injection defense: design RAG and agents for least privilege, read-only access and human approval.
– [ ] Output checks: a guard model or rules, stricter for high-risk settings (medical, financial, counselling and the like).
– [ ] Authentication and rate limits when exposing an API; see the local API server guide.
– [ ] Separate training from inference and test from production, with backup and recovery.
Logging and audit
– [ ] Document log fields, retention, access rights and cleanup.
– [ ] Sample regularly and keep records; reassess after any model or prompt update.
Data and privacy
– [ ] Decide whether user input is used for training; if so, have authorization and a way to opt out.
– [ ] For keeping data inside your network see enterprise private deployment and local LLM and privacy.
For several people sharing one server see small-team shared LLM; for knowledge bases see local RAG.
How we checked this, and what we did not do
Clauses, numbers and scope come from the body and annexes of GB/T 45654-2025; guard-model descriptions come from the abstracts of the arXiv papers; the VRAM and log-capacity figures are our formula estimates, and the intervals use standard formulas. We did not test any guard model or software, we do not rate any product’s effectiveness and we did not assess any company’s compliance. This article is not legal advice.
FAQ
Must a company using an LLM internally comply with GB/T 45654?
It is a recommended standard aimed mainly at services with public-opinion influence or social-mobilization capability, for filing and assessment. Whether it applies to internal use depends on the facts and on other regulations, so ask your legal team; it still works as a reference framework.
Can a guard model guarantee safety?
No. Guard models are probabilistic classifiers that miss some things and flag others wrongly, so combine them with least privilege, output checks and human review.
Do I have to use a guard model?
Not necessarily. A small deployment can start with keywords and rules, plus logs and spot checks, and add a guard model when risk is higher or the language mix is complex.
How long should logs be kept?
That depends on regulation and company policy, and we give no single figure; remember that logs hold sensitive information, so minimize and control access.
Which guard model suits Chinese-language business?
Test with your own Chinese prompt bank. Qwen3Guard’s abstract says it supports 119 languages and dialects including Chinese, but that is self-reported and no substitute for your validation.
How do we run internal acceptance?
Build should-refuse and should-answer banks plus a safety pass-rate bank, spot-check a fixed number each time, record the judging method and retest after any model or prompt update.
Need an enterprise content-safety plan?
We can help map your use cases, choose guardrails and design logging and acceptance. Leave a note on the solutions inquiry page or email admin@microaione.com. For on-site or remote setup see the remote installation service.
More in this series: How jailbreak defenses work in layers; Local guardrails with Llama Guard. All articles are collected in the LLM Jailbreak and Safety hub.
References: GB/T 45654-2025; Llama Guard (arXiv), ShieldGemma (arXiv), Granite Guardian (arXiv), Qwen3Guard technical report (arXiv), Meta PurpleLlama (GitHub), OWASP LLM Top 10, NIST AI RMF. Read on 2026-11-04.
