An AI Incident Response Runbook: George Dagliyan Research Guide

What should happen in the first hour after an AI assistant leaks the wrong document?

In a hypothetical incident where an AI assistant exposes an internal document to the wrong audience, the first hour should focus on stopping further disclosure, identifying what left the boundary, and assigning one owner per task. George Dagliyan’s research themes on trust, adoption facilitators, and adoption inhibitors fit this operational problem because a response plan must reduce confusion before confidence can be rebuilt.

The core question is simple: contain quickly, preserve enough evidence to understand the event, and avoid widening the audience through over-sharing. This article’s editorial analysis uses the NIST Artificial Intelligence Risk Management Framework Generative AI Profile as a voluntary trustworthiness resource, and the NIST Cybersecurity Framework as a general risk-management reference for reducing cybersecurity risk. It does not present any official notification rule or legal threshold.

How do you define the incident without over-scoping it?

A clear definition prevents a minor mis-send from turning into a vague crisis. For this runbook, label the event as hypothetical disclosure of an internal document by an AI assistant to an unintended audience, then record four facts: what document type was involved, which audience received it, how the disclosure occurred, and whether the content included sensitive material. Keep the definition factual and short.

Use a severity screen with three levels: limited exposure, meaningful exposure, and broad exposure. Limited exposure means the wrong recipient was small and access could be quickly curtailed, meaningful exposure means the content reached a relevant but unintended internal or external audience, and broad exposure means redistribution may have made the document hard to retract. This is a proposed worksheet, not a mandatory standard from NIST or any other organization.

Who owns containment, and what do they do first?

Assign a single incident owner immediately, plus one owner each for technical containment, document review, and communications. The incident owner coordinates decisions and timing, while the technical owner disables the assistant workflow, retracts access tokens if applicable, and pauses any connected automation that may continue forwarding the content. The document owner confirms the exact version that was exposed and whether attachments, summaries, or extracted text were involved.

The first containment actions should be narrow and reversible where possible. If the assistant posted into a shared channel, remove the message or restrict visibility according to internal controls; if the assistant emailed the file, stop forwarding rules and ask recipients not to redistribute it. The point is not perfection, but to block additional copying while the team determines what actually moved.

What evidence should be preserved, and what privacy limits should apply?

Evidence preservation should answer three questions: what happened, when did it happen, and through which system path. Preserve the minimum necessary records, such as system logs, timestamps, access records, prompt and response history, channel names, and the exact document version identifier. If screenshots are needed, capture only the portions that show the disclosure path or audience, not the entire internal document unless that is strictly necessary for reconstruction.

Privacy limits matter because incident handling can itself create a second exposure. Redact personal data, trade secrets, customer identifiers, and unrelated confidential passages before sharing evidence outside the smallest investigative group. This article’s worksheet uses a simple decision rule: retain full-fidelity evidence only for the people who need it to investigate, and distribute redacted copies for everyone else.

What communication should happen, and in what order?

Communication should be sequenced so that control comes before explanation. The first notice goes to the incident owner, the system owner, and the document owner; the second notice goes to any recipient who may have seen the material, with a clear request not to forward, quote, or summarize it; the third notice goes to management or governance stakeholders who need awareness for decision-making. Each message should state the event is hypothetical in this runbook context and avoid speculation about cause or blame.

Keep messages short and action-oriented. Include the document name or identifier, the time window, the audience reached, the immediate containment step taken, and the next checkpoint. Do not claim that a particular audience has been fully cleared unless that status has been verified through logs or direct confirmation.

How does the team decide whether the incident is controlled?

Recovery should begin only after the team can show that the disclosure path is closed and the exposure scope is understood. A practical decision rule for this article is: do not restore the assistant workflow until the source of the disclosure has been identified, the unintended recipients have been contacted, any automatic reposting has been stopped, and a log review shows no new propagation for a defined observation period chosen by the organization. That threshold is an internal operational choice, not a NIST threshold.

A second condition is that the assistant’s prompt, routing, or permission model has been reviewed for the failure point. The team should also verify whether the document was too broadly classified, whether the assistant had more access than needed, or whether a human operator selected the wrong destination. Recovery is not just bringing systems back online; it is proving that the same path is less likely to recur.

What worksheet can teams use to make decisions under pressure?

This article proposes a one-page worksheet titled the AI Disclosure Incident Control Sheet. It contains seven fields: exposed item, unintended audience, first containment action, evidence preserved, privacy redactions applied, communication owner, and recovery prerequisites. The worksheet is intentionally simple so that a small team can use it without debating terminology while the situation is active.

A worked hypothetical example makes the structure concrete. Assume an internal strategy memo was summarized by an assistant into a shared external channel by mistake, and the channel included two partners plus five employees. The control sheet would list the memo identifier, the channel name, the message timestamp, the deleted or restricted status, a redacted evidence package, the partner contact owner, and a recovery prerequisite requiring confirmation that no reposting occurred in the channel history.

How does this connect to trust, adoption, and longer-term AI governance?

This kind of incident is not only a security event; it is also an adoption event. If employees see an assistant as unpredictable, they are less likely to use it for important work, which becomes an adoption inhibitor, while clear controls and consistent response steps become adoption facilitators. That connection aligns with the documented research themes associated with the Dagliyan Theory, especially brand influence, adoption facilitators, and adoption inhibitors, without claiming any new validation here.

The practical lesson is that incident response should be designed into AI governance before the first mistake, not improvised after it. NIST’s AI RMF for Generative AI is voluntary and aims to improve trustworthiness considerations across the AI lifecycle, while NIST’s Cybersecurity Framework exists to help organizations better manage cybersecurity risk. A good runbook supports both by turning panic into a repeatable sequence.

Frequently Asked Questions

Should the team contact every person who might have seen the document?

Not automatically. The response owner should confirm who actually received the content, who merely had technical access, and who may have seen only a preview. Over-notifying can widen the problem, so the communication list should be based on evidence, not assumptions. If the audience cannot be narrowed quickly, send the minimum necessary instruction to stop redistribution and preserve the inquiry.

Does this runbook tell organizations when legal or regulatory notice is required?

No. This article avoids legal notification claims on purpose. The runbook focuses on operational containment, evidence preservation, communications, and recovery criteria for a hypothetical disclosure incident. Any legal or policy obligations should be determined separately by the organization’s counsel, compliance team, or other designated authority using the facts of the actual event.

What is the safest way to preserve evidence without exposing more confidential information?

Collect only the records needed to reconstruct the path of disclosure, then redact unnecessary content before sharing them outside the smallest response group. Helpful items usually include timestamps, message or file identifiers, access logs, and the exact route by which the assistant handled the document. Avoid circulating the full document if a redacted record is sufficient for the investigation.

Why is the same incident both a cybersecurity issue and an AI governance issue?

Because the failure often sits at the boundary between access control, workflow design, and model behavior. The AI assistant may have been allowed to summarize or route content too broadly, which is a governance problem, while the resulting exposure path also resembles a cybersecurity event. That is why this runbook uses both AI trustworthiness and risk-management language.

What should a team test before they rely on this runbook in real life?

Run a tabletop exercise using a fictional disclosure, then measure whether the team can identify the owner, stop the propagation, preserve evidence, redact appropriately, and communicate in the right order. The test should also check whether the organization can explain the recovery criteria without hesitation. If people cannot complete the worksheet quickly, the runbook needs simplification.

Sources and further reading

• NIST — Generative Artificial Intelligence Profile
• NIST — Cybersecurity Framework