You're launching a customer-facing LLM assistant and the company is worried it could produce harmful, off-brand, or unsafe responses. How would you design the guardrail layer, and how would you know it's actually working?

technical-conceptual · Senior level · data-ml

What the interviewer is really asking

Assesses whether the candidate can design a layered input/output safety system for a public LLM product — content classification, PII handling, topic/scope boundaries, refusal behavior — and, critically, measure it with a red-team and eval set rather than assuming the base model's alignment is enough.

What to say

• Guard both the input and the output as separate stages: screen incoming requests for disallowed or out-of-scope content and known jailbreak patterns, and screen the model's response before it reaches the user for harmful content, PII leakage, and off-policy claims — the base model's built-in alignment is a baseline, not your guarantee.
• Define policy concretely and design the refusal: decide what's in scope, what must be refused, and how the assistant declines gracefully and hands off, so 'safe' is a written spec the guardrails enforce rather than a vibe — and tune the threshold against the cost of over-blocking legitimate requests.
• Measure it like a real system: build a safety eval set plus an adversarial red-team set, track block-rate, false-positive (over-refusal) rate, and leak/violation rate, run it in CI so a model or prompt change can't regress safety, and monitor production with logging and an escalation path.

What to avoid

• Assuming the foundation model's built-in safety training is sufficient and skipping an application-level guardrail layer entirely.
• Only adding an input filter and ignoring output screening, so a harmful or PII-leaking response still reaches the user.
• Shipping guardrails with no measurement, so you can't tell whether they block real attacks or just over-refuse harmless requests and frustrate customers.

Example answers

Strong: I'd treat the base model's alignment as a baseline, not the guarantee, and add an application-level guardrail layer on both sides. On input I'd screen for disallowed or out-of-scope topics and known jailbreak patterns; on output I'd screen the response before it reaches the user for harmful content, PII leakage, and off-policy claims. Crucially I'd write the policy down — what's in scope, what we refuse, and how the assistant declines gracefully and hands off — so 'safe' is a spec, not a vibe, and I'd tune thresholds against the cost of over-blocking real customers. Then I'd measure it: a safety eval set plus an adversarial red-team set, tracking block-rate, over-refusal rate, and violation/leak rate, run in CI so a model or prompt change can't silently regress safety, with production logging and an escalation path.

Weak: Modern models are already trained to be safe and refuse harmful requests, so I'd mostly rely on that, and add a content filter on the user's input to catch anything obviously bad. That should keep the assistant from saying anything harmful.