When should I block an AI response instead of reviewing it?

Block when the verdict is unsafe, risk is high, or findings indicate executable markup, threats, phishing patterns, or clear policy violations that must not reach users under any circumstance.

When is human review appropriate?

Review suspicious verdicts, context-dependent policy topics, high-value transactions, or borderline technical language where false positives are likely and a trained reviewer can approve or edit safely.

Should users ever see flagged model text with a warning label?

No. Warning banners still expose harmful or executable content. Replace blocked or pending-review outputs with static safe messaging.

What is a practical default mapping for IdenticAPI verdicts?

Many products deliver on safe, queue suspicious for review with a neutral user message, and block unsafe with a fallback. Document overrides in version-controlled policy config.

Do block and review decisions apply to streaming partials?

Apply decisions to the assembled message. Do not deliver unmoderated stream chunks to the DOM; buffer server-side before routing verdicts.

When Should an AI Response Be Blocked vs Sent for Review?

An AI response should be blocked when automated screening indicates high-confidence harm, executable markup, or clear policy violations that must not reach users — and sent for human review when signals are ambiguous, context-dependent, or severity is medium, where a trained reviewer can approve, edit, or reject without exposing raw flagged text to the end user.

There is no universal rule for every product; you define thresholds on top of IdenticAPI safe, suspicious, and unsafe verdicts. This guide helps you design those policies with comparison tables and workflow patterns.

Verdict semantics (IdenticAPI)

AI Output Safety returns structured results from:

curl -X POST https://www.identicapi.com/api/v1/security/output-safety \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"text": "Assistant message to evaluate"}'

Key fields:

Field	Meaning
`verdict`	`safe`, `suspicious`, or `unsafe`
`risk`	Severity hint (e.g., low, medium, high)
`findings`	Categorized reasons
`reasons`	Human-readable explanation list

Verdicts are risk signals, not legal judgments or guarantees. Your policy maps them to block, review, or allow. Full schema: documentation.

Block vs review vs allow

Action	When to use	User sees	Internal handling
Allow (deliver)	`safe` verdict; content passes rendering controls	Normal assistant reply	Log metadata optional
Review	`suspicious` verdict; borderline policy; novel phrasing	Generic holding message or delayed reply	Queue with context for human
Block	`unsafe` verdict; high `risk`; executable markup; disallowed categories	Static safe fallback only	Do not echo flagged text

Default posture for unknown failures: fail closed (block or review) rather than delivering unmoderated LLM output — see improper output handling.

Decision matrix by finding category

Use API findings[].category plus your product context:

Category (illustrative)	Typical verdict	Recommended action	Rationale
Unsafe markup (script, event handlers)	`unsafe`	Block	XSS and injection risk if rendered
Deceptive / phishing patterns	`unsafe`	Block	User harm, brand damage
Harassment or threats	`unsafe`	Block	Safety and policy
Sexual content (non-consent contexts)	`unsafe`	Block	Audience policy
Medical/legal/financial advice (restricted products)	`suspicious`–`unsafe`	Review or Block	Context-dependent liability
Mild profanity in adult product	`suspicious`	Review or allow with rules	Brand dependent
Technical docs mentioning "kill process"	`suspicious`	Review or Allow after sanitizer	False positive prone
Benign formatting HTML (allowlisted tags)	`safe`	Allow after sanitizer	Defense in depth still applies

Tune rows for your audience — developer docs vs consumer support bots differ sharply.

Block workflow

When action is block:

Replace assistant output with pre-approved fallback text
Log request_id, verdict, categories — not necessarily full text in production logs
Optionally increment abuse counters for session monitoring
Do not show the model's unsafe reply "for debugging" to end users

Example fallback:

"I can't provide that response. Please rephrase or contact support."

Blocking patterns: How to Moderate LLM Output, real-time chat.

Review workflow

When action is review:

Customer/user sees a neutral message ("Thanks — a team member will follow up") — not flagged content
Review queue stores: user prompt (redacted), model output (access-controlled), findings, timestamp
Reviewer options: approve edited version, reject with template, escalate
SLA targets defined by team (support vs public social)

Review is appropriate when:

Verdict is suspicious but not clearly malicious
High-value transactions mentioned (refunds, credits) — support bot guide
Regulatory language requires human approval
New model version increases suspicious rate temporarily

Avoid review queues as dumping grounds — if >30% of traffic lands in review under synthetic tests, tune policies before launch (threshold is guidance for testing, not an industry stat).

Comparison: block-first vs review-first products

Factor	Block-first	Review-first
User experience	More refusals	More delays / handoffs
Safety margin	Higher	Depends on reviewer capacity
Best for	Public consumer chat, HTML rendering	Enterprise support, regulated workflows
Operational cost	Lower staffing	Requires reviewer tooling
False positive impact	Higher user friction	Higher reviewer load

Many teams use block for unsafe and review for suspicious — a hybrid default.

Risk level overlay

Combine verdict with risk when provided:

verdict	risk	Suggested routing
`unsafe`	high	Block
`unsafe`	medium	Block (or review if niche false positives documented)
`suspicious`	high	Review (or block for strict products)
`suspicious`	low	Review or allow with logging
`safe`	any	Allow after rendering pipeline

Document overrides in version-controlled policy config, not scattered if statements.

Streaming and partial output

Block/review decisions apply to the assembled message. Do not deliver stream chunks to the DOM before final verdict — partial bypass splits payloads across tokens. Buffer server-side, then route.

Unified Guard and multiple detectors

When using Unified Guard with multiple checks, define precedence:

Any unsafe from output safety → block
Conflicting signals → conservative route (review or block)
Compare orchestration vs single-purpose moderation in AI Guardrails vs Content Moderation

Metrics to track

Metric	Purpose
Block rate	Detect model/policy drift
Review queue depth	Staffing
Approval vs rejection in review	Tune `suspicious` handling
Top finding categories	Targeted tests
Time-to-deliver for allowed messages	Latency budget

Prototype category distribution with the AI Output Safety Checker.

Anti-patterns

Showing flagged text with a warning banner — Users still exposed; attackers still benefit
Review without access control — Leaks sensitive flagged content internally
Auto-approve review after timeout — Converts review into delay-only block
Different policies per client — Mobile bypasses web moderation
Blocking user messages but never assistant output — Input vs output gap

Testing policy before launch

Synthetic corpus:

Clearly malicious → must block
Borderline technical → expect review or allow per your doc
Benign FAQ → must allow

Automate in CI; manual review weekly on sampled suspicious production cases.

Implementation references

Limitations

Automated verdicts cannot capture full business context:

Legal interpretations vary by jurisdiction
Brand voice allows edgy content in some products and not others
Humans remain accountable for final decisions in high-stakes review

Use safe / suspicious / unsafe as inputs to a documented policy — block when harm is clear, review when judgment is required, and never deliver unmoderated output when checks fail.