Extend your existing incident response plan rather than writing a new one. Add AI-specific incident definitions, intake fields, a way to disable the system, communication to affected parties, a track for third-party AI failures, and a review loop. NIST covers these across GOVERN 4.3, MANAGE 2.4 and MANAGE 4.3.
Define what counts
Beyond security breaches, AI incidents include harmful or false output reaching users, data exposed through prompts or outputs, a model behaving outside intended use, bias discovered in production, and failures in a vendor's model that you depend on. Write examples into the plan.
Intake: what to capture
The generative AI profile suggests a minimum set of criteria for reporting incidents: system ID, title, reporter, source, date reported, date of incident, description, impacts and stakeholders impacted. Add the model version and a copy of the relevant inputs and outputs, handled under your data rules.
Be able to switch it off
MANAGE 2.4 asks for mechanisms, with assigned and understood responsibilities, to supersede, disengage or deactivate AI systems that show performance or outcomes inconsistent with intended use. In practice: a feature flag, a documented owner who can use it, and a fallback path such as manual handling.
Test it. A kill switch nobody has tried is an assumption.
Communicate
MANAGE 4.3 asks that incidents and errors be communicated to relevant AI actors, including affected communities, and that tracking, response and recovery be documented. Check this against breach notification and data protection obligations, which have their own clocks. The profile suggests aligning plans with relevant breach reporting and privacy law.
Third-party AI
If a vendor's model fails or is breached, you still answer to your customers. The profile suggests incident plans for third-party generative AI that define ownership, are shared with relevant people, and are rehearsed at a regular cadence. Ask vendors how they will notify you.
Learn from it
After each incident, update the plan, the tests, the policy and the inventory entry. NIST's MANAGE 4.2 asks for measurable continual improvement integrated into system updates.
Rehearse
Run a tabletop with a scenario such as a customer-facing assistant revealing another customer's data, or an agent taking an unintended action. Note who had to be called and what was unclear.
Where Safeguard fits
Safeguard supports agent identity and policy guardrails, which can help limit what an AI agent is allowed to do and leave a record of it. They complement, and do not replace, a tested response plan.
Evidence to preserve
Save the prompt, the output, the model and version, retrieval sources, tool calls, timestamps and any human edits. Models change over time, so a later replay may not reproduce the failure. Restrict access to this evidence, since it can contain personal or confidential data, and set a retention period that matches your data rules and any legal hold. Good records also make the post-incident review far more useful.
Quick check
Who declares an AI incident?
Anyone should be able to report one. The system owner or incident commander classifies it using the plan's definitions.
Do near misses count?
Track them. They are cheap lessons, and NIST's GOVERN 4.3 asks for practices that enable incident identification and information sharing.
Sources
Last reviewed: 19 October 2026.
