AI Safety & Guardrails interview questions
AI Safety & Guardrails questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is a guardrail in an LLM application, and where does it sit?
The strongest answer: A check outside the model that enforces policy the prompt cannot guarantee — on the input before the call and on the output before it reaches a user or a tool — written as code or a separate classifier
Why it works: Exactly — the prompt asks, the guardrail checks. Because it runs outside the model, it still works on the day the model ignores its instructions.
- The prompt asks; the guardrail checks.
- Check input before the model call.
- Check output before users or tools.
- Keep the policy in code you own.
Your assistant gets a question it has no information to answer. What should happen, and how do you get that behaviour?
The strongest answer: It should say it does not know, ask for clarification or hand over — not guess. I design for it: when retrieval finds nothing relevant the app says so, and unanswerable questions are in the test set
Why it works: Exactly — abstaining is a feature you build and measure. A confident tone says nothing about whether the answer is right.
- Not knowing is a valid answer.
- Give the app a “nothing found” path.
- Put unanswerable questions in the tests.
- Never read confidence from tone.
A health-information assistant was tightened after a complaint. It now refuses ordinary questions about common medicines, and support tickets say it is useless.
How do you approach fixing it?
The strongest answer: Both errors cost: over-refusal fails legitimate users, under-refusal lets harm through. I build a test set with should-answer and should-refuse cases, measure both rates on every change, and make refusals say what the assistant can help with
Why it works: Exactly — it is a two-sided error, so both sides go in the evaluation. Otherwise every fix for one complaint creates the opposite complaint.
- Refusing too much is also a failure.
- Test should-answer and should-refuse cases.
- Measure both rates on every change.
- Make a refusal point somewhere useful.
Your sales chatbot told a customer they were entitled to a discount that does not exist, and the customer is holding the company to it.
How do you make sure the assistant cannot commit the company to things that are not true?
The strongest answer: Take commitments out of free text: prices and policy come from the system of record via code, the model only explains them, and an output check blocks any amount or promise that does not match the source
Why it works: Exactly — constrain the output so the risky part is not generated at all, then verify what is left. The model explains; the system of record decides.
- Do not generate what must be exact.
- Numbers and policy come from code.
- Validate output against the source.
- Block or fall back on a mismatch.
Your output content filter is a separate classifier call, and your answers stream to the user. What happens when the filter times out, and how do the two fit together?
The strongest answer: Fail-open or fail-closed is decided per surface by risk, not left to an exception handler; high-risk surfaces fail closed to a safe fallback. With streaming I check buffered chunks before release, and every block is logged for review
Why it works: Exactly — a guardrail that silently disappears under load is not a guardrail. Decide the failure mode on purpose, pay the buffering latency where the risk justifies it, and keep the evidence.
- Choose the filter’s failure mode on purpose.
- Fail closed where the risk is high.
- Buffer streamed chunks before release.
- Log every block and review them.
You run an AI career coach. Now and then a message shows real personal distress rather than interview nerves. The model currently improvises a sympathetic reply and carries on with the session.
What do you build, and what do you refuse to leave to the model?
The strongest answer: A defined escalation path: a detector tuned to miss few cases, the normal flow stops, the reply is expert-reviewed fixed text pointing to real human help, and cases are audited. The model does not improvise here
Why it works: Exactly — the rare high-stakes case gets a deterministic, reviewed path and a human, decided before launch, with missed cases treated as worse than false alarms.
- High stakes get a fixed, human path.
- Detect first; prefer false alarms to misses.
- Stop the flow; use reviewed text.
- Point to real people, then audit.
Your organisation is about to launch an LLM feature that summarises and ranks CVs for recruiters. A vice-president asks you to confirm in writing that it is “unbiased”.
What do you say?
The strongest answer: I cannot certify “unbiased”. I can report what we tested — paired CVs differing only in name, gender or age signals, results by group, known limits — and require a recruiter to decide, monitoring after launch, and a way to contest
Why it works: Exactly — state what was measured and what was not, keep a person accountable for the decision, and keep measuring. An honest scope is worth more than a certificate nobody could defend.
- Report what you tested, not “unbiased”.
- Use paired cases that vary one attribute.
- Keep a person deciding and accountable.
- Monitor by group; allow a challenge.