Model Cards, Audit Logs & Incident Response

L236 (AI Governance & Compliance — EU AI Act, NIST AI RMF) told us what the law requires. This lesson is the three concrete artifacts and operations that actually satisfy it — the things you build, keep, and rehearse so that accountability is real and provable, not a value on a slide:

• Document it — the model / system card. Before launch: a standardized record of what the system is, how well it performs (and for whom), and where it shouldn't be used.
• Record it — the audit log. During operation: an immutable, timestamped trace of every consequential decision — the evidence.
• Respond to it — the incident runbook. After something goes wrong: a rehearsed plan to detect, contain, disclose, and learn.

The through-line is a maxim every regulated industry lives by: if it isn't documented, recorded, and rehearsed, it didn't happen. You can have done everything right, but without the card, the log, and the incident report, you can't prove it to an auditor, a customer, or a court — and in a serious incident, the evidence is all that matters.

Scope vs. neighbors: this builds directly on L223 (The Monitoring & Observability Layer) but is not the same — observability is for you (debug, latency, cost), while an audit log is evidence (immutable, retained, complete). And it's the operational follow-through on L236's legal duties. It's also the bridge to the section finale, L238 (Hands-On: Build a Guardrail Layer), where this all becomes code.

The model card (Mitchell et al., 2019 — Model Cards for Model Reporting) is the foundational AI documentation artifact: a short, standardized document that travels with a model so anyone using it knows what it is and where it's safe. It has ~9 sections:

• Model details — name, version, date, owner, architecture.
• Intended use — what it's for, and crucially, what it's not for (out-of-scope uses).
• Factors — the subpopulations, conditions, and environments performance may vary across.
• Metrics & Evaluation data — how you measured it, on what.
• Training data — what it learned from (the datasheet for datasets, Gebru et al. 2018, documents this in depth: provenance, composition, collection, consent).
• Quantitative analyses — results, broken down by subgroup (this is where the fairness audit from L235 (Content Moderation & Responsible AI) lives — overall accuracy hides disparities).
• Ethical considerations and Caveats & recommendations — known risks, limitations, and how to deploy responsibly.

The honest sections — intended use, limitations, by-subgroup results, ethical considerations — are the point. A model card that only lists benchmark wins is marketing; a real one tells you where the model fails so you don't deploy it there. (HuggingFace made model cards the de-facto standard — every model on the Hub has one.)

A model card describes a model; but you don't ship a model, you ship a system — the model plus its prompts, guardrails, tools, policies, and monitoring. The system card documents that: how the deployed thing behaves, what mitigations wrap it, and what safety testing it passed.

This is now industry practice for frontier models: OpenAI publishes a system card with every major release (e.g. the GPT-5 system card, Aug 2025), and Anthropic does the same for each Claude (the Claude Opus 4 / Sonnet 4.5 system cards, 2025) — documenting capabilities, safety and alignment evaluations, red-teaming, agentic-safety tests, and the deployment decision. Read one: they're a masterclass in honest AI documentation.

Here's the governance payoff: a thorough system card is, in substance, the technical documentation the EU AI Act demands for high-risk systems (and that NIST's Map/Measure functions describe). So the documentation you write for good engineering — so the next team understands the system — is the same artifact that satisfies the regulator. Write it once, well; keep it current as the system changes; and make it the single source of truth for what this system is and where it must not go.

The card documents the system in the abstract; the audit log records what it actually did, decision by decision, in production. For a high-risk system the EU AI Act makes this a legal requirement (automatic event logging, retained ≥ 6 months; technical docs 10 years). What to log, per consequential request:

• the input / prompt and the output / response,
• the model version and key parameters,
• a timestamp and the user identity,
• the decision and its rationale,
• every guardrail action taken (blocked? redacted? fell back?) — the L231/L232 verdicts,
• and any human approval or override (the HITL from L227/L230).

But the part that makes it an audit log rather than just logs is its properties, and this is where it differs sharply from the observability of L223 (The Monitoring & Observability Layer):

Same plumbing, different contract. The audit log must be tamper-evident — you (or anyone) must not be able to quietly edit history. A simple, powerful technique is an append-only, hash-chained log: each record includes the hash of the previous one, so altering any past entry breaks the chain and is detectable (the same idea behind a blockchain or git). For real compliance you'd add qualified timestamps and independent retention.

The card and the log are your preparation; the incident is the test. Take the on-call seat: an AI failure has fired — work the runbook and make the calls.

The lab drills the three judgment calls that separate a handled incident from a disaster: triage (under-triage lets harm compound; over-triage burns the team), containment (the least-disruptive action that actually stops the harm — a kill switch for a minor jailbreak is as wrong as a filter for active exfiltration), and disclosure (a serious incident in a high-risk system must reach the regulator — silence is itself a violation). Below, the lifecycle behind those calls.

You will have an AI incident — a harmful output, a leak, a bias failure caught in the wild, a jailbreak gone viral. The teams that survive them have a rehearsed runbook, borrowed from SRE and adapted for AI. Five phases:

1. Detect. You can't respond to what you can't see — incidents surface from monitoring & alerts (L223), user reports, or red-team findings. (Detection you don't have is the most common real failure.)
2. Triage. Classify severity = harm × scale × reversibility. This sets the response: a wrong answer to one user is not a database exfiltration. Triage honestly — both under- and over-reacting are costly.
3. Contain. Stop the bleeding with the least-disruptive intervention that actually works, escalating along a ladder: filter output → block users → patch the guardrail → roll back the model → kill switch. The kill switch (full offline) and rollback are reserved for active exfiltration or mass harm — for a contained jailbreak, a guardrail patch is right and taking the whole product down is self-inflicted damage. (This is where L234 (Fallbacks, Retries & Circuit Breakers) pays off — rollback and circuit-breakers are your containment tools.)
4. Disclose. Tell who you must, on the clock: under the EU AI Act, providers of high-risk systems report serious incidents to the authority within ~15 days (GPAI-systemic has its own template); notify affected users when their data or safety is involved. Be timely, factual, and plain-language — and log the decision.
5. Learn. A blameless post-mortem (next).

Two rules that save you: pre-authorize the containment actions (you don't want to be debating who can hit the kill switch during an exfiltration), and rehearse — an incident plan you've never run is fiction, exactly like the resilience code in L234.

The final phase is where an incident becomes an asset. A post-mortem documents what happened — root cause, timeline, affected users, containment actions, and corrective measures — and it's blameless: it targets the system and process, never a person. The reason is practical, not just kind: if people get punished for incidents, they hide them, and you lose the very signal you need. Psychological safety is what makes the next incident visible.

And the corrective action closes the loop back to everything in this section. A post-mortem that ends at "we'll be more careful" is worthless; a good one ships a concrete fix that makes the incident structurally impossible to repeat:

• a PII leak → a new output guardrail (L232) + a regression test,
• a jailbreak → a patched input guardrail + the pattern added to evals (L231),
• a bias incident → a by-group fairness gate + monitoring (L235),
• an agent exfiltration → an approval gate on the risky tool + least-privilege (L230).

This is the data flywheel of L228 (Feedback UI & Human-in-the-Loop: The Data Flywheel) applied to safety: every incident, captured and learned from, makes the system harder to break. (Industry shares these publicly too — the AI Incident Database catalogs real-world AI harms so the whole field learns.)

Put together, the three artifacts form a cycle: the card says what should happen, the log records what did, and the incident process turns the gap between them into the next card update and the next guardrail. That cycle is operational accountability.

Use the Incident Response Lab and what you've learned:

1. Run Prompt-injection exfiltration. Try containing it with patch or rollback — why isn't that enough, and what is?
2. On that same incident, skip the regulator disclosure. Why does the lab flag it?
3. Run Jailbreak and hit the kill switch. It contains the harm — so why does the lab still warn you?
4. Why must an audit log be immutable, and how does a hash chain achieve that?
5. Your post-mortem concludes "the on-call engineer should have caught it." What's wrong with that, and what should it say instead?

→ (1) The data is actively being exfiltrated, so anything short of stopping the egress lets it continue — only the kill switch (take the agent offline) halts it now; patch/rollback fix the cause but not the active leak. (2) It's a serious incident in a high-risk system, so reporting to the authority (within ~15 days) is legally required — failing to disclose is itself a violation, on top of the breach. (3) A viral-but-contained jailbreak is medium severity; a kill switch takes the whole product offline — massive self-inflicted downtime for a harm a guardrail patch would have stopped. Containment should be proportionate. (4) Because the log is legal evidence — if you could quietly edit it, it would prove nothing. A hash chain links each record to the hash of the previous one, so altering any past entry breaks every subsequent hash and is detectable. (5) It blames a person, which teaches people to hide incidents (and ignores that the system let one human error cause harm). It should name the system/process root cause and a structural corrective action — e.g. "no detection alert existed; add monitoring + a guardrail so this can't recur."

• “A model card is a marketing one-pager.” A real card documents intended use, limitations, ethics, and by-subgroup performance — it tells you where the model fails, so you don't deploy it there.
• “Model card = system card.” A model card describes the artifact; a system card describes the deployed system (model + policies + tooling + monitoring) — and that is the Act's technical documentation.
• “My observability stack is my audit log.” No — observability is for engineers (sampled, mutable); an audit log is evidence (complete, immutable, timestamped, retained). Different contract.
• “We'll write the incident plan when something happens.” An unrehearsed plan is fiction. Pre-authorize the containment actions and drill it before you need it.
• “Containment means hit the kill switch.” Use the least-disruptive action that stops the harm — kill switch / rollback only for active exfiltration or mass harm; over-containment is needless downtime.
• “Quietly fix it and move on.” Serious incidents in high-risk systems carry a legal duty to disclose (regulator ≤15 days, affected users). Silence compounds the violation.
• “Find who screwed up.” Post-mortems are blameless — blame makes people hide incidents. Fix the system, and feed the corrective action back into the guardrails.

• Accountability is artifacts — document, record, respond: if it isn't written down, recorded, and rehearsed, it didn't happen. These satisfy the EU AI Act duties from L236.
• Model & system cards (document it): Mitchell's 9 sections — intended use, limitations, ethics, and by-subgroup metrics; the system card documents the deployed system (OpenAI/Anthropic publish them) and is the Act's technical documentation.
• Audit logs (record it, immutably): log input · output · version · user · rationale · guardrail actions · overrides — complete, immutable (hash-chained), timestamped, retained ≥6mo. It's evidence, distinct from the observability of L223.
• Incident response (when it fails): a rehearsed runbook — detect → triage → contain (least-disruptive that stops the harm; kill switch/rollback only for active/mass harm, via L234) → disclose (regulator ≤15 days, users) → learn.
• Blameless post-mortems close the loop: fix the system, never the person; the corrective action feeds back into the guardrails (the L228 flywheel for safety) so the incident can't recur — the bridge to the hands-on finale L238 (Build a Guardrail Layer).