Responsible AI as an Engineering Practice

"Responsible AI" sounds like a compliance topic. In interviews — and in real systems — it's an engineering topic: a set of concrete design patterns with names. Candidates who can translate the buzzword into build decisions stand out immediately, because most people can only recite principles. This lesson is the translation table.

Advisory vs. determinative — the load-bearing distinction

The single most important design question for government AI: does the system decide, or does it advise? A determinative system's output is the decision (an application auto-denied). An advisory system informs a human or feeds a deterministic, auditable rule that makes the call.

Nearly everything else follows from choosing advisory:

• Output wording is part of the architecture. "Appears to meet the requirement" routes a user toward verification; "You are qualified" creates reliance — and potentially an appeal. Architects specify the wording, not just the model.
• Escalation is a feature, not an apology. Design the low-confidence path first: what confidence threshold, routed to whom, with what context attached, at what staffing cost.
• The human must be able to disagree cheaply. If overriding the AI takes more work than accepting it, your human-in-the-loop is theater. Measure override rates — a 0% override rate usually means rubber-stamping, not perfection.

Grounding and citations — auditability you can demo

For language-model features, retrieval-augmented generation with citations is the responsible-AI workhorse: the model answers from retrieved authoritative text, and every claim links to its source. This converts "the AI said so" into "the AI pointed to section 4 of the published requirement, and here it is." In an interview, connect the dots explicitly: grounding isn't a quality trick, it's what makes an AI answer auditable — a reviewer can check the citation the way they'd check a colleague's memo.

Name the failure mode too, because it shows real experience: retrieval can over-match — confidently citing a source that's topically related but not actually applicable. Mitigations: relevance thresholds (below the bar, say "I don't have a grounded answer" rather than improvising), corpus scoping (only authoritative documents, versioned), and evaluation questions specifically designed to trigger wrong-source answers.

The control plane: the unglamorous 80%

The difference between a demo and a production government AI feature is the wrapper:

• Role-based access — who can invoke the AI feature at all.
• Audit logging — every invocation: who, when, what context went in, what came out. This is your incident-response record and your public-records answer.
• Feature toggles — the capability can be disabled at runtime, by an administrator, without a deployment. When leadership asks "can we turn it off?", the answer must be a click, not a sprint.
• PII minimization at the prompt boundary — the narrowest possible context enters the model. Prompts are an egress path; treat them like one.
• Fail closed — when the AI service is down, degraded, or uncertain, the system does the safe thing (route to a human, show the deterministic result) rather than guessing.

If you have built even one AI feature with this wrapper, say so in exactly these terms. The sentence "the AI is advisory, role-gated, audit-logged, and behind a feature toggle" is a complete responsible-AI answer in fourteen words.

Deterministic first, AI second

A pattern that reads as senior judgment everywhere, and doubly so in government: use AI only where a rule can't do the job. If a requirement is mechanical — a count, a threshold, a lookup — encode it as data-driven deterministic logic: cheaper, testable, explainable, and it never hallucinates. Reserve the model for the genuinely fuzzy parts (interpreting free text, matching equivalent-but-differently-worded things), and ground even those. Bonus architecture point: keep the rules as versioned configuration that subject-matter experts can review, not as code — the people who own the policy can then own its encoding.

Evaluation before launch, monitoring after

Responsible AI's measurable half: no gold set, no launch. Build an evaluation set from historical decisions made by experts; measure the AI against it; pick the metric that reflects the worst failure (for an eligibility-style system: false positives — telling someone they qualify when they don't — must stay near zero, and you accept more false negatives as the price). After launch, monitor in production: sampled human review, override rates, drift in input data, complaint signals. In the interview, the phrase "we measured against historical determinations before launch and monitored override rates after" is what separates "I integrated an API" from "I operate AI systems."