It is 4:47 on a Friday and a tweet with eleven thousand retweets says your new brand campaign ripped off a beloved artist, or a disability advocate has posted a video of your checkout flow being completely unusable with a screen reader, or a customer has screenshotted a hallucinated, nonsensical piece of UI copy that shipped to production and is now a meme. The asset was AI-generated. Nobody on your team can immediately say which tool made it, who approved it, or whether the claim is even true. The clock is running, the company Slack is lighting up, and a VP just asked "what's our response?" The three risk lessons before this one were about prevention; this one is about the day prevention failed. Because it will, occasionally, fail - no register, governance doc, or CI gate catches everything - and the difference between a contained incident and a self-inflicted catastrophe is whether you wrote the playbook before the Friday or are improvising during it. This lesson scripts the response for the three worst-case scenarios and produces the artifact every design org needs and almost none has: a one-page incident playbook.

Why Design Needs Its Own Incident Playbook

Engineering has had incident response for two decades. There is a runbook, an on-call rotation, a severity scale, a blameless-postmortem culture, and everyone knows that when the site goes down you page the on-call, open a channel, and follow the steps. Design has none of this, and the gap was tolerable when design's failures were slow and private - a bad layout got fixed in the next sprint, an off-brand asset got quietly replaced. AI changed the failure profile. Design now ships at engineering velocity and volume, which means design failures now happen at engineering frequency, but design failures land differently than engineering failures: they are public, they are reputational, and they arrive through Twitter and press rather than through a monitoring dashboard.

A site outage is measured in minutes of downtime and dollars; a brand-infringement claim or a viral accessibility failure is measured in reputation, trust, and legal exposure, and reputation does not come back as cleanly as uptime. This is exactly why design needs its own playbook rather than borrowing engineering's: the failure modes are different, the stakeholders are different (legal, comms, and the CMO, not just the on-call engineer), and the response moves are different. The instinct under pressure is to improvise, and improvisation under public scrutiny is how a contained problem becomes a compounding one - the defensive statement that admits liability, the silence that reads as guilt, the hasty deletion that looks like a cover-up. The playbook exists so that the worst forty minutes of your quarter are governed by decisions you made calmly in advance rather than reflexes you produce in panic.

The strategist's job here is unglamorous but high-stakes: to have written the thing nobody wants to think about, so that when the unthinkable happens the team executes instead of flails. An incident playbook is the artifact that signals organizational maturity to leadership more than almost anything else, because it proves the design org has thought about its own failure honestly, which is precisely the posture that survives a layoff cycle and earns the trust to keep moving fast.

The Shape of Every Design AI Incident

Before scripting the three specific scenarios, recognize the shared shape underneath them, because a playbook built on the common structure is one you can apply to the incident you did not anticipate. Every design AI incident moves through the same five phases, and the playbook's job is to define the moves for each phase before you need them.

The first phase is detection and triage: someone notices, and the first decision is whether this is real and how bad. The second is containment: stopping the bleeding - pausing the campaign, pulling the asset, rolling back the feature - without yet committing to an explanation. The third is assessment: figuring out what actually happened, which for an AI-generated asset means reconstructing provenance (which tool, which prompt, who approved). The fourth is response: the external move - the statement, the fix, the outreach - calibrated to what the assessment found. The fifth is the postmortem: the blameless analysis that turns the incident into a strengthened preventive control so the same failure cannot recur the same way.

The single most important property running through all five phases is that provenance is what makes fast response possible. An org that logged provenance can answer "which tool, which prompt, who approved" in minutes, which collapses the assessment phase and lets the response be accurate and fast. An org that did not log provenance spends the critical first hours doing forensics on its own asset library while the public clock runs, and is forced to either respond before it knows the facts (dangerous) or stay silent while it investigates (also dangerous). This is the moment the L1-and-L3 provenance discipline pays its largest dividend: it is the difference between an incident you assess in twenty minutes and one you assess in two days.

You cannot respond accurately to a problem you cannot trace. Provenance logged on a quiet Tuesday is what lets you answer "which tool, which prompt, who approved" in the twenty minutes of a Friday when the answer is the whole game.

Scenario One: A Brand-Identity Infringement Claim

The first worst-case is the one the IP risk register warned about: a public claim that an AI-generated asset infringes someone's protected work - a character, a style, a photograph, a mark. This is the scenario where the wrong instinct is most expensive, because anything you say in the first hours can become evidence, and the gap between "we are looking into it" and "we apologize for using your work" is the gap between a manageable matter and an admission.

The playbook's moves here are specific. Containment first: pause distribution of the asset across every surface it touches - not delete, pause, because deletion can read as spoliation of evidence and because you may need the asset for the assessment. Loop in legal before any external statement, because this scenario is the one where comms and legal must move together and where a well-meaning designer's apology can waive a defense. Run the provenance assessment: which tool generated it, was that tool indemnified, what was the prompt (and did it reference protected IP, which both raises the merit of the claim and may have voided indemnification). The external response is legal-approved and narrow: acknowledge receipt, state you are reviewing, commit to nothing about merit. The postmortem move is to update the IP risk register - this incident just gave you real data about which workflow produced the exposure, and that data should harden the tool-tier rule or the prompt-hygiene policy that would have prevented it.

Scenario Two: A Public Accessibility Failure

The second worst-case is the one the accessibility lesson warned about, now public: a disability advocate, a journalist, or a user demonstrates that a shipped feature is unusable with assistive technology, and the demonstration is spreading. This scenario differs from the infringement claim in a crucial way - the right response is rarely defensive, because the claim is almost always true and visibly so, and defending the indefensible is the fastest way to make it worse.

The playbook's moves reflect that difference. Containment may mean shipping an immediate fix rather than pulling the feature, because for an accessibility failure the best containment is often to make the thing accessible fast, and a token-level or CSS hotfix can sometimes resolve a contrast or focus failure within the hour. Assessment uses your CI and audit infrastructure: if you have the three-layer net, you can immediately determine whether this slipped through a bypassed gate or a coverage gap, which tells you both the scope (is this one screen or a systemic pattern) and the honest cause. The external response here is the opposite of the infringement scenario: acknowledge directly, do not be defensive, state what you are fixing and by when, and thank the person who surfaced it, because the accessibility community responds far better to genuine remediation than to legal hedging. The postmortem feeds the CI a11y-policy: this failure either reveals a gap in coverage (add the check) or a bypassed gate (close the override loophole), and the fix is structural, not a one-screen patch.

Scenario Three: A Hallucinated UI Shipped to Production

The third worst-case is the most purely AI-native: a piece of generated UI or copy that is nonsensical, wrong, or embarrassing shipped to production and a user found it - the placeholder that says "Lorem ipsum" on a live pricing page, the hallucinated feature that does not exist, the error message that tells users to do something impossible, the cheery-bot microcopy that is wildly inappropriate for the context (a "Great job!" on a failed payment). This scenario is usually less legally fraught than the other two but can be the most reputationally bruising, because it reads as carelessness and invites the "they just let the AI ship it" narrative that every design team fears.

The playbook's moves are fastest here because the fix is usually clear. Containment is the immediate correction or rollback of the offending UI, which is typically reversible and quick. Assessment asks the question that matters most for prevention: how did unreviewed generated output reach production at all - was there no human review step, was the review step skipped under deadline, or did the reviewer trust a generated output that looked plausible. The external response is usually light - often no public statement is needed beyond fixing it, and over-apologizing for a typo-class problem can amplify it - but if it went viral, a brief, human, non-defensive acknowledgment ("that one's on us, it's fixed") defuses better than silence or corporate-speak. The postmortem move is the most important: this incident is evidence that the human-in-the-loop step failed, and the fix is to make the review step structural for production-bound generated content rather than relying on a tired designer to catch it - the same shift from relaxable attention to structural enforcement that runs through the whole risk chapter.

The One-Page Incident Playbook

The artifact this lesson produces is a one-page incident playbook, and the one-page constraint is not a stylistic preference - it is functional. An incident playbook that is twelve pages will not be read at 4:47 on a Friday; it will be the document someone is frantically scrolling while the situation worsens. The playbook has to be a single page that a panicking person can scan and act from, because the entire value of a playbook is that it works under exactly the cognitive conditions - stress, time pressure, fear - that destroy improvised judgment.

The page has a defined structure. At the top, the severity triage: a fast rule for deciding if this is a real incident and how severe, because not every angry tweet is an incident and treating them all as one is its own failure. Then the first five moves, in order, that apply to any incident: who to notify (the on-call equivalent - a named person or role, not "someone"), open the incident channel, pause-don't-delete, pull provenance, loop in legal-or-comms per severity. Then a compact per-scenario branch: three short columns for the infringement, accessibility, and hallucinated-UI cases, each with its containment move, its assessment focus, and its response posture (defensive-and-legal for infringement, direct-and-remediating for accessibility, light-and-human for hallucinated UI). Then the roles: who decides on the external statement, who owns the fix, who runs the postmortem - named roles, because an incident with ambiguous ownership is an incident that stalls. And finally the postmortem trigger: the commitment that every incident produces a blameless postmortem that hardens a specific preventive control.

The playbook must explicitly establish that the postmortem is blameless, and this matters more than it appears. The fastest way to ensure incidents get hidden rather than surfaced is to punish the person who shipped the asset, because then the next person who notices a brewing problem will hope it goes away rather than raise it. A blameless culture treats every incident as evidence of a process gap, not a personal failing, which is both more accurate (the failures in this chapter are structural, not individual) and the only culture in which people surface problems early enough to contain them. The playbook codifies blamelessness so that the response to an incident strengthens the system instead of teaching the team to hide the next one.

Rehearsing the Playbook Before You Need It

A playbook that has never been rehearsed is a document, not a capability. The difference between the two is revealed only under pressure, and the worst time to discover that the playbook is unclear, that the named on-call person left the company, or that nobody actually has legal's after-hours contact is during the real incident. The strategist's move is to run a tabletop exercise: gather the team, present one of the three scenarios as if it were live, and walk the playbook in real time, noting every place it stalls, every role that is ambiguous, every step that assumed access someone does not have. Thirty minutes of rehearsal surfaces the gaps that would otherwise cost hours in the real event.

Socializing the playbook also does quiet strategic work. When the design org has a rehearsed incident playbook, it changes how leadership perceives design's relationship to AI risk - from a team that is naively shipping AI output and hoping, to a team that is moving fast deliberately with a tested safety net underneath. That perception is worth real budget and real trust, because it lets leadership say yes to velocity knowing the downside is governed. The playbook is simultaneously a response tool and a credibility artifact, and a strategist should present it as both: this is how we contain the rare failure, and this is the evidence that we have earned the right to move at AI speed.

Putting It to Work This Quarter

Write the one page this week, even roughly, because the rough version is infinitely better than the nothing you have now. Draft the severity triage, the five first moves, and the three scenario branches, and put a real name or role on every step - the single most common playbook failure is the step that says "notify the right person" without naming who that is. Confirm that the provenance log exists and is queryable under pressure, because the entire assessment phase depends on it, and an incident is the worst time to discover the log is incomplete.

Then do two things. Run one tabletop exercise on the scenario you think is most likely for your org - the infringement claim if you do heavy brand generation, the accessibility failure if you ship a lot of AI UI - and fix every gap it surfaces. And establish the blameless-postmortem norm now, in calm conditions, by saying it out loud to the team before any incident, because a blameless culture cannot be created in the middle of the incident that would test it. You will know the playbook is real when a tabletop runs smoothly and the team treats the eventual real incident not as a catastrophe to survive but as a procedure to execute - which is the entire difference between an org that AI risk can sink and one that has decided, in advance and in calm, exactly how it will not.

Key Takeaways

• Prevention fails occasionally - no register, governance doc, or CI gate catches everything - so a design org needs an incident playbook for the day it does. Design failures now happen at engineering velocity but land as public, reputational, legal problems, which is why design needs its own playbook rather than borrowing engineering's.
• Every design AI incident moves through five phases: detection and triage, containment, assessment, response, and a blameless postmortem. Provenance is the property that makes fast response possible - a logged org assesses in twenty minutes; an unlogged one does forensics for two days while the public clock runs.
• Infringement claim: pause-don't-delete, loop in legal before any statement, run the provenance assessment, respond narrowly and legally-approved (acknowledge receipt, commit to nothing on merit), and harden the IP register in the postmortem.
• Public accessibility failure: the claim is usually true and visible, so the response is direct not defensive - often an immediate hotfix, acknowledge and thank the reporter, state what you are fixing and when, and feed the CI a11y-policy to close the coverage gap or override loophole.
• Hallucinated UI in production: fast and usually clear - correct or roll back, assess how unreviewed output reached production, respond lightly and humanly (over-apologizing amplifies), and make the human-in-the-loop review step structural for production-bound generated content.
• The artifact is a one-page playbook (functional, not stylistic - it must be scannable under panic): severity triage, five first moves with named roles, a three-column per-scenario branch, named ownership, and a blameless-postmortem trigger. Rehearse it with a tabletop exercise before you need it; it doubles as a credibility artifact that earns leadership's trust to move at AI speed.