Responsible AI — Module 20.1

How This Lesson Fits the Module & Volume

The first half of Vol. 20 named harms and threat classes: bias, fairness, explainability, transparency, privacy, AI safety, copyright, prompt injection, jailbreaking, and poisoning. Responsible AI is the operating system that turns those topics into repeatable practice: principles, evaluations, conceptual red-team process, and incident response.

It is not a slogan slide. It is how a team ships Vol. 13 guardrails, Vol. 14 RAG, and Vol. 15 agents without hoping ethics happens in spare time. Next, governance assigns roles and artifacts (boards, inventories, risk registers); compliance maps engineering controls to legal regimes at a high level.

Learning Objectives

By the end of this lesson, students should be able to:

State a compact set of responsible-AI principles and map each to a practice.
Design a pre-ship eval gate that includes safety, fairness, and quality (Vol. 19).
Describe a conceptual red-team process (charter, scope, findings, fixes)—no exploits.
Outline incident response for LLM products (detect, contain, communicate, learn).
Connect HITL, logging, and rollback to everyday engineering, not only crises.
See responsible AI as the bridge into governance and compliance lectures.

Definition

Responsible AI is the discipline of specifying who could be harmed, which principles constrain the product, and which measurable practices (evaluation, review, monitoring, incident response) make those principles real. Principles without gates are posters. Gates without principles are arbitrary blocks. This lecture is product and process education—not legal advice (that nuance continues under compliance).

From Principles to Practices

Principle	Vol. 20 / prior lecture	Practice (what you actually do)
Benefit & non-maleficence	AI safety	Use-case allowlist; refuse out-of-scope high-risk tasks
Fairness	Fairness / bias	Slice metrics; human review on disparate errors
Privacy	Privacy	Minimization, retention, no train-on-user by default
Transparency	Transparency / explainability	User-facing limits; citation when using RAG
Accountability	This lecture + governance	Named owners, logs, incident roles
Security	Injection / jailbreak / poisoning	Guardrails, allowlists, integrity gates

The Operating Loop

Specify

Use case, users, harms, policy.

Evaluate

Quality + safety + fairness gates.

Review

Red-team process + go/no-go.

Operate

Monitor, HITL, incidents.

Eval (always on)

Vol. 19 quality: groundedness, latency, cost
Safety categories + false-refusal rate
Fairness slices where labels exist
Block ship if gates fail (fail closed on high severity)

Red-team (conceptual)

Written charter and in-scope threat classes
Independent reviewers; time-boxed
Findings → tickets → guardrail + eval case
No public exploit recipes; no production abuse

Incident response

Detect via logs, user reports, eval cliffs
Contain: disable tool, roll back, rate-limit
Communicate: users, leadership, as required
Learn: postmortem + new canary

Conceptual Red-Team (Not a Cookbook)

A responsible red-team answers: Under our policy, what could go wrong, and did our controls catch it? It is closer to a safety review than to an exploit workshop. Scope is threat classes already taught (injection, jailbreak, poisoning, privacy leakage, unfair outcomes)—not step-by-step attacks. Vol. 15 HITL and Vol. 13 guardrails are in-scope mitigations to test for presence, not puzzles to bypass for sport.

Phase	Artifact	Done when
Charter	Scope, severity scale, out-of-bounds	Leadership signed; no live customer abuse
Review	Architecture + policy walkthrough	Trust boundaries drawn (prompt / RAG / tools)
Exercise	Tabletop + defensive test cases	Gaps logged; no payload publication
Close	Fixes + eval cases + residual risk	Owner + date; residual risk accepted or blocked

Defensive Snippet: Eval Gate + Incident Ticket

Policy-as-code for a pre-ship gate and a minimal incident record. Thresholds are illustrative; real teams set them with governance and safety owners.

# Responsible-AI practices as code: ship gate + incident record.
# Defensive / process only.

from datetime import datetime, timezone

SHIP_POLICY = {
    "max_safety_fail_rate": 0.01,
    "max_fairness_gap": 0.10,
    "min_groundedness": 0.85,
    "require_hitl_for": ("send_email", "issue_refund"),
}

def ship_decision(metrics: dict, enabled_tools: list[str], hitl_covered: set[str]) -> dict:
    reasons = []
    if metrics.get("safety_fail_rate", 1) > SHIP_POLICY["max_safety_fail_rate"]:
        reasons.append("safety_gate")
    if metrics.get("fairness_gap", 1) > SHIP_POLICY["max_fairness_gap"]:
        reasons.append("fairness_gate")
    if metrics.get("groundedness", 0) < SHIP_POLICY["min_groundedness"]:
        reasons.append("rag_faithfulness_gate")
    for tool in enabled_tools:
        if tool in SHIP_POLICY["require_hitl_for"] and tool not in hitl_covered:
            reasons.append(f"hitl_missing:{tool}")
    return {"ship": not reasons, "block_reasons": reasons}

def open_incident(severity: str, threat_class: str, summary: str, owner: str) -> dict:
    return {
        "id": datetime.now(timezone.utc).strftime("INC-%Y%m%d-%H%M%S"),
        "severity": severity,  # sev1..sev4 — defined in the playbook
        "threat_class": threat_class,  # e.g. injection | privacy | fairness
        "summary": summary,
        "owner": owner,
        "status": "open",
        "containment": [],
        "comms_required": severity in {"sev1", "sev2"},
        "opened_at": datetime.now(timezone.utc).isoformat(),
    }

def contain(incident: dict, action: str) -> dict:
    # Examples: disable_tool:send_email | rollback_index | rate_limit
    incident["containment"].append({"action": action, "ts": datetime.now(timezone.utc).isoformat()})
    return incident

Incident Response for LLM Apps

Classic IR still applies: detect, contain, eradicate, recover, lessons learned. LLM specifics: you may contain by disabling a tool, rolling back an index or adapter (poisoning lecture), tightening egress filters, or forcing HITL—not only by taking a server offline. Preserve logs for compliance and postmortems; follow privacy retention rules when logs contain user text.

Do

Name an incident commander and a comms owner
Time-box containment; prefer reversible controls
Add a canary so the same failure fails the next gate
Record residual risk explicitly

Don’t

Quietly prompt-patch production with no eval
Publish exploit details in the public postmortem
Blame “the model” without checking tools, RAG, and data
Skip user notification when policy or law requires it

Related Lectures

Lecture	Role
Benchmarks / human evaluation	Quality + safety measurement
Guardrails / HITL	Runtime practices
AI safety / fairness	Principle sources
Governance	Next: roles, boards, inventories

Common Misconception

“Responsible AI is a values workshop; engineering can ignore it.” If it does not change eval gates, tool allowlists, and incident playbooks, it is theater. Second: red-teaming means publishing jailbreaks—in this curriculum it means scoped, defensive review. Third: one launch review lasts forever; models, indexes, and prompts drift. Fourth: incident response is only for security; fairness and privacy incidents need the same muscle. Fifth: more principles always beat fewer with owners—unowned principles do not ship.

Knowledge Check

Short Answer: What is responsible AI in this curriculum? Answer: Principles plus measurable practices (eval, review, monitoring, incident response).
True/False: Principles without ship gates are sufficient. Answer: False.
Multiple Choice: A conceptual red-team should: (a) charter, find gaps, add eval cases, (b) publish exploit PoCs, (c) disable logging. Answer: (a).
Short Answer: Name two LLM-specific containment actions. Answer: Disable a tool, rollback index/adapter, force HITL, tighten egress (any two).
True/False: This lecture is legal advice. Answer: False.
Multiple Choice: Fairness as a principle maps to: (a) slice metrics and review, (b) increasing batch size, (c) RoPE theta. Answer: (a).
Short Answer: Why require HITL on some tools before ship? Answer: High-impact side effects need a human control, not only a model decision.
True/False: Vol. 19 eval belongs inside responsible-AI gates. Answer: True.
Multiple Choice: Next lecture: (a) governance, (b) t-SNE, (c) perplexity. Answer: (a).
Short Answer: Link one prior Vol. 20 harm lecture a principle should cite. Answer: Bias / fairness / privacy / AI safety / copyright (any valid).

Key Takeaways

Responsible AI = principles mapped to eval, review, ops, and IR.
Red-team is a scoped defensive process, not an exploit tutorial.
Incidents: contain with tools/index/HITL; learn with new canaries.
Unowned principles do not change products.
Next: Governance.

Trainer’s Guide

Lab: Students pick a fictional RAG + tools assistant. They write five principles, a ship-gate table (metrics + thresholds), a one-page red-team charter (in/out of scope), and a sev1–sev4 IR sketch. No attack payloads.

Tabletop: “Groundedness dropped after an index refresh and users report unfair tone on one locale.” Walk detect → contain → comms → new eval case.

Recap: Responsible AI turns Vol. 20 harms into an operating loop—specify, evaluate, review, operate. Assign the loop to people and artifacts next in Governance.