This chapter describes how an analyst verifies what AI concludes when the analyst depends on the AI to read the data at all. It concerns B2 Detect, where AI drafts and tunes detections and closes alerts by class; B3 Investigate, where AI enriches, correlates and summarises cases and proposes timelines; and B4 Respond, where AI proposes containment and, inside a codified playbook, executes it. It applies the review-for-soundness approach of The Transformed Security Architect, Chapter 14, which asks the reviewer of AI output to reproduce independently, to seed errors and to measure review quality (66, Nordqvist, 2026), and the oversight-quality metric of AI Boss, Chapter 26, which treats an approval given in seconds as a signal of failure (67, Nordqvist, 2026), to security conclusions. The chapter answers five practical questions. What does soundness mean for a triage verdict, a timeline and a containment proposal? How is automation bias measured and reduced? How are seeded incidents designed, and what do they cost? How is review kept real when volume triples? How is the analyst's own skill kept calibrated?
A reviewer who can read the evidence unaided can check a conclusion against it. A reviewer who cannot has two options: trust the conclusion or build a second way of reading. Most of this chapter concerns the second option, because the first is what happens by default. The design rule the chapter arrives at is this: review of an AI conclusion is real only if the process makes it hard to approve without checking, makes checking affordable, and measures whether checking happened.
Take a night-shift analyst at Hansa Mutual's Polish service centre. An alert from the endpoint tool arrives with a summary from the investigation agent HM-SEC-001: a service account authenticated from an unusual network, the host ran a signed administration binary it does not normally run, and the agent recommends isolating the workstation. Behind the summary lie several thousand events from endpoint, identity, DNS and proxy sources. The analyst cannot read them in the time the case allows. The agent wrote the queries that retrieved them, chose which sources to consult, and ranked the findings. The analyst's view of the case is the agent's view of the case.
Primary topics explored
- Dependence: the reviewer who needs the reviewed
- Soundness criteria for a security conclusion
- Review that does not start from the AI's answer
- Seeded incidents
- Oversight-quality metrics
- Fatigue and volume
About AI Blue
AI Blue is Book 8 of The Transformed Architecture. It examines how the blue team, the people and functions that defend an organisation, is transformed when artificial intelligence takes part in their work: anticipating, detecting, investigating, responding and learning, the team's own AI and how to verify and protect it, operating models, roles, decision rights, regulation and measurement, and the careers and wellbeing of the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect and AI Boss.
Chief information security officers, heads of security operations, SOC managers, analysts, detection engineers and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 14: Verifying What the AI Concludes: Review for Soundness When the Analyst Depends on the AI in AI Blue gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Blue Team's AI Team” and is one of 32 drawn from the manuscript.