NIST splits AI incident response into two separate guidance tracks

NIST's Center for AI Standards and Innovation is working toward two distinct incident response documents, framed by separate audiences and separate threat models. The first updates existing cybersecurity incident response guidelines to account for attacks on AI systems, model theft, adversarial inputs, supply-chain compromise of AI components. The second breaks new ground: recommendations for responding to incidents where an AI system is the cause of harm, not the victim. NIST's proposed working definition covers "incidents where the development, use, or malfunction of an AI system caused harm," intentional or not.

Peter Cihon, senior advisor at CAISI, presented the two-track structure at a May 14 workshop convened to gather feedback as NIST prepares to formally launch the work streams under the White House's AI action plan, which assigns NIST a role in promoting mature federal capacity for AI incident response. Kevin Stine, director of NIST's Information Technology Laboratory, noted that NIST's recent request for information on AI and cybersecurity drew more than 500 responses, with AI monitoring and incident response emerging as a dominant theme, which Stine framed as direct validation for the convening.

What the two tracks mean for practitioners

The split matters operationally. NIST computer scientist MS Raunak was direct about it: the policy-level framework may not change, but practitioners will need substantially more detailed playbooks calibrated to specific incident types and system components. That's a meaningful signal for contractors already running NIST SP 800-171-based incident response programs. Adding AI-induced incidents as a distinct class means the existing controls (designed around traditional IT compromises) are unlikely to map cleanly onto scenarios involving model malfunction or AI-enabled misuse.

Cihon confirmed the two documents are aimed at different audiences. The first targets organizations deploying AI systems and their users. The second's intended audience was cut off in available reporting, but the workshop framing suggests it addresses developers and the broader AI supply chain. NIST indicated the scope would be "narrowly focused on the most severe harms," though the agency acknowledged that resulting practices could be more broadly useful.

The liability gap

Workshop participants flagged the liability question throughout the day. NIST's broad definition of AI-induced incidents (covering development, use, and malfunction) spans the full stack from model developer to end-user deployer. That breadth was welcomed by participants who wanted unintentional harms included, but it defers the harder question: when something goes wrong, who is responsible and under what standard?

For defense contractors, that question has real teeth. Federal AI deployments that touch controlled unclassified information or defense systems will eventually face incident reporting obligations. Until NIST's guidance assigns responsibility across the stack with some specificity, contractors building AI into their workflows carry undefined exposure. The guidance is scoped to fulfill the July 2025 AI action plan deadline, but no final publication date has been announced.

The EU's AI Act code of practice and California's SB 53 offer limited comparison: both focus incident reporting obligations solely on frontier AI developers, not deployers or users. NIST's second work stream, if finalized as proposed, would reach significantly further down the stack.