Yes, AI belongs in incident response, but only in an assistive role: drafting scenarios, summarizing evidence, and surfacing gaps, never making containment, notification, or disclosure decisions. Boards and regulators in 2026 are converging on the same standard: AI can accelerate the work, but a named human stays accountable for every decision and has to be able to explain it.

In December 2025, Google Cloud's own security leadership flagged a shift in what boards are asking their CISOs: “Boards are asking us about business resilience and the impact of advanced, machine-speed attacks.” That question, once confined to security committees, is now showing up in board minutes across regulated industries, precisely as organizations start layering AI into incident response, detection, and crisis coordination. The result is a governance question every resilience leader now has to answer: not whether AI helps, but where the line sits between AI assisting and AI deciding.

Key Takeaways

• Google Cloud's security leadership reports that boards are directly asking CISOs about business resilience against machine-speed, AI-enabled attacks (Google Cloud, December 2025).
• ISACA's 2026 research found only 42% of professionals are confident their organization could investigate and explain a serious AI incident to leadership or regulators, and just 11% are completely confident.
• The EU AI Act's high-risk obligations, fully applicable from August 2026, require reporting of serious incidents involving high-risk AI systems and demand demonstrable human oversight, not aspirational policy.
• FINRA's 2026 Annual Regulatory Oversight Report makes the same point for financial services: accountability remains fully human, regardless of how a decision was reached.

Why Are Boards Suddenly Asking About AI in Incident Response?

Boards are asking because the threat side of the equation changed first. Attackers are already using AI to scale and automate campaigns, and boards want to know whether their own incident response can keep pace, and whether the AI tools their own teams are adopting introduce new risk of their own.

Google Cloud's Cybersecurity Forecast 2026 describes threat actors moving from experimental to routine AI use across the full attack lifecycle, and the same report flags “shadow AI agents” — unauthorized AI tools employees deploy on their own — as a growing source of invisible risk. Put those two trends next to each other and the board-level question becomes obvious: if attackers are moving at machine speed and employees are already using ungoverned AI tools, does the organization's own incident response process have the same problem it's trying to defend against?

Where Does AI Actually Help During an Incident?

AI is genuinely useful for the parts of incident response that are about speed and volume: drafting a first-pass scenario, summarizing a sprawling timeline of alerts and actions into something a human can review quickly, and flagging patterns across past incidents that a person would take hours to find manually.

This is close to what Google Cloud's forecast calls the “Agentic SOC”: AI generating case summaries, decoding commands, and mapping activity to frameworks like MITRE ATT&CK, so analysts spend their time on validation and containment instead of manual assembly. Applied to broader operational readiness rather than just security operations, the same pattern holds. Opsbook, for instance, uses AI to build a continuously updated model of an organization's roles, systems, and dependencies from its existing documentation, then uses that model to recommend which playbooks are missing or unvalidated, and to assemble a first-draft after-action report the moment an exercise or incident ends. None of that requires AI to make a decision — only to make the material a human needs to decide faster to prepare.

Where Should AI Not Be Making the Call?

Containment decisions, regulatory notification timing, and external disclosure are exactly the decisions ISACA's 2026 research shows organizations are least confident explaining after the fact, which is precisely why they shouldn't be delegated to a model in the first place.

ISACA's research found that fewer than half of professionals, 42%, are confident their organization could investigate and explain a serious AI incident to leadership or regulators, and only 11% are completely confident. That confidence gap matters most exactly where the stakes are highest: deciding whether to isolate a system, when a breach becomes reportable, and what an organization tells customers or regulators. Those are judgment calls with legal and reputational consequences attached to a specific, accountable person, not outputs a model should generate unsupervised.

What Do Regulators Expect From AI-Assisted Incident Response in 2026?

Across very different regimes, from the EU AI Act to FINRA, the expectation converges on one principle: using AI doesn't change who's accountable, and documentation of that accountability, not the existence of a policy about it, is what regulators are checking for.

The EU AI Act's high-risk obligations become fully applicable in August 2026 and require organizations to report serious incidents involving high-risk AI systems to Market Surveillance Authorities, which means the incident-response process itself now has to account for AI as both a tool and a potential subject of the incident. In U.S. financial services, FINRA's 2026 Annual Regulatory Oversight Report makes the same point from a different angle: existing accountability rules apply to generative AI without exception, and firms must retain clear ownership of outcomes regardless of how a decision was reached. Neither regulator is asking organizations to stop using AI. Both are asking for proof that a human remains answerable for what it produces.

What Does a Defensible Human-in-the-Loop Process Actually Look Like?

A defensible process has three parts that all leave a record: the source material an AI recommendation was based on, the recommendation itself, and the named human who reviewed and approved it before anything was published or acted on.

Opsbook's own governance model follows this chain of custody directly: source material feeds an AI recommendation, which passes human review before it's published, with every finding traceable back to its origin, whether that's a document, an exercise, or a real incident. Outputs are structured to map to the frameworks regulators and auditors already examine, including DORA, NERC CIP, CMMC, HIPAA, NIS2, and SEC cyber disclosure rules. The point isn't the specific tooling — it's that “AI recommended it” is never, on its own, the answer to “who decided this,” and a defensible program can always name the second part.

How Should Organizations Start Governing AI in Their Incident Response Program?

1. Write down where AI is already involved. Most organizations underestimate this; map every tool that touches detection, response, or reporting.
2. Draw an explicit line between “AI assists” and “human decides” for each of those tools, in writing.
3. Require a named human sign-off on containment, notification, and disclosure decisions, logged with a timestamp.
4. Keep the source material behind every AI recommendation, not just the recommendation itself, so a finding can be explained later.
5. Test the human-in-the-loop process itself in an exercise, not just the technical response, so the accountability chain is proven, not assumed.

Where Does AI Help vs. Where Must a Human Decide?

Conclusion

• AI belongs in incident response as an accelerant, not a decision-maker — the regulatory consensus in 2026 is remarkably consistent on this point across the EU AI Act and FINRA.
• Boards are already asking the question; ISACA's research shows most organizations aren't yet confident they could answer it under scrutiny.
• The safest place to draw the line is the same place regulators are drawing it: AI can recommend, but a named human has to decide and be able to explain why.
• Test the human-in-the-loop process itself, not just the technical response, so accountability is proven before an incident, not assumed during one.

Opsbook uses AI to build a dynamic model of your organization, surface preparedness gaps, and draft recommendations, but every output routes through human review before it's published, with evidence and provenance that trace back to their source. See how Opsbook's governance model holds up under audit — book a walkthrough.