11. Responsible AI practices — how institutions keep the courtroom honest¶

~15 min read. Principles matter only when teams turn them into routines, owners, drills, and gates.

Built on the ELI5 in 00-eli5.md. The appeal process — the way bad verdicts get challenged — depends on organizational habits like red teaming, impact assessments, and governance forums.

Picture first: responsible AI is operations, not posters¶

Many companies write beautiful principles. Fairness. Transparency. Safety. Human oversight. Good words. But a principle poster does not stop a bad verdict. Routines do.

Responsible AI practice means scheduled work. Risk reviews. Red-team sessions. Impact assessments. Launch gates. Owner sign-offs. Incident drills. Monitoring reviews. Simple, no? The courtroom stays honest through procedure.

principle poster
      │
      └── not enough

operating loop
risk review ──→ red team ──→ launch gate ──→ monitor ──→ incident review

See the shift. We move from values language to control language. Who owns the case record? Who signs the jury instructions? Who can pause rollout? Who receives appeals? That is responsible AI in practice.

Red teaming: try to break the judge on purpose¶

Red teaming means adversarial testing before or during deployment. The goal is not embarrassment. The goal is discovery. Find hidden harms before users do.

For fairness, red teaming can probe sensitive prompts, proxy features, edge dialects, protected-group slices, and downstream workflow effects. Ask brutal questions. Can the model recommend fewer interviews for similar resumes with different names? Can it misread disability accommodations as low performance? Can it produce stereotypes under mild prompt pressure? Can it over-refuse one group's complaints as fraud?

Worked example. Suppose a red team runs 100 paired hiring prompts. Before mitigation, 12 produce a materially worse recommendation for the protected variant. Failure rate = 12%. After prompt and threshold changes, only 3 do. Failure rate = 3%. Reduction = 9 percentage points. Relative drop = 75%.

Good. That is measurable progress. But the case record should also note what the red team did not cover. One successful drill is not a universal guarantee.

Impact assessments: think before the launch, not after the headline¶

An impact assessment asks structured questions before deployment. Who is affected? What goes wrong if the judge is wrong? Who absorbs false positives? Who absorbs false negatives? Can a person appeal? Can a human override? What evidence supports launch confidence?

Use a simple prioritization score. Suppose a support automation feature has: - harm severity = 4 - user reach = 5 - reversibility = 2, where low reversibility is worse Create a rough priority score = 4 × 5 × 2 = 40. Now compare with a low-stakes drafting helper scoring 2 × 3 × 1 = 6. You would not govern them the same way.

Look. The exact formula is local. The discipline is universal. Impact assessments make the team articulate stakes before the judge starts scaling decisions.

Governance: who decides, who blocks, who learns¶

Governance sounds heavy. It can be light and still useful. You need named owners. A review forum. Escalation paths. Release criteria. Periodic refresh. That is enough to start.

A mature governance loop often includes: - product owner for use-case scope - model owner for technical behavior - policy or legal partner for external obligations - operations owner for appeals and overrides - incident lead for production failures

Yes? This is not bureaucracy for its own sake. It prevents the common failure where everyone assumes someone else checked the fairness risk. The appeal process collapses when ownership is vague.

What responsible teams do every quarter¶

They rerun high-risk evaluations. They review drift. They update the case record. They refresh red-team suites. They check whether new product surfaces changed the jury instructions. They review incidents and near misses. They ask whether a once-acceptable use case has become higher risk. They review appeal volume and override trends. They check whether old mitigations are still actually applied.

So what to do if your team is small? Start with three habits. One lightweight impact assessment template. One quarterly red-team review. One launch checklist requiring documentation, slice evaluation, and owner sign-off. That alone is a big upgrade over principle posters.

Responsible AI is institutional memory. It keeps the courtroom from relearning the same lesson through repeated harm.

Where this lives in the wild¶

Microsoft Responsible AI reviews — product governance lead: require structured impact analysis and cross-functional approval before high-risk launches.
GitHub Copilot safety evaluations — trust and safety manager: combine red teaming, policy review, and release gating for developer-facing features.
Klarna AI customer support operations — automation owner: must define escalation paths when the assistant touches refunds, identity, or disputed transactions.
Enterprise HR software vendors — responsible product counsel: use impact assessments and governance boards for screening and talent-ranking features.
Healthcare copilot teams — clinical AI program manager: rely on periodic review forums because even helpful assistants can create quiet allocation harm.

Pause and recall¶

Why are principles alone not enough for responsible AI?
In the red-team example, what showed measurable improvement?
What does an impact assessment force a team to articulate early?
Why is named ownership essential for an effective appeal process?

Interview Q&A¶

Q: Why run red teams and not rely only on benchmark suites for responsible AI review? A: Because red teams explore product-specific failure paths, edge cases, and adversarial compositions that canned benchmarks often miss. Common wrong answer to avoid: "Because benchmark suites are useless once a product reaches production scale."

Q: Why conduct impact assessments before launch instead of after the first incident? A: Because authority boundaries, user harm, and fallback design should shape the system before it starts producing real verdicts at scale. Common wrong answer to avoid: "Because impact assessments are mainly for public relations teams."

Q: Why is governance about clear owners rather than just more committees? A: Because accountability fails when everyone assumes someone else reviewed fairness, safety, or escalation responsibilities. Common wrong answer to avoid: "Because good engineers can replace governance if they are careful enough."

Q: Why should responsible AI review recur quarterly rather than happen once? A: Because models, prompts, data, and product surfaces drift, so yesterday's acceptable judge can become today's unreviewed risk. Common wrong answer to avoid: "Because quarterly meetings automatically improve fairness metrics on their own."

Apply now (5 min)¶

Exercise. Pick one AI feature. Write three red-team prompts or test cases that target fairness or proxy harm. Then assign an owner who would receive the resulting appeal process findings.

Sketch from memory. Draw an operating loop with impact assessment, red team, launch gate, monitoring, and incident review. Under each step, write one concrete artifact the team should produce.

Bridge. Governance before launch is necessary, but it is still not enough. After deployment, fairness can drift, slices can shift, and old verdict patterns can return unless we monitor them continuously. → 12-fairness-monitoring-production.md