Verifying What the AI Concludes: Review for Soundness When the Analyst Depends on the AI

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?

Review for soundness: independent reproduction, seeded incidents and oversight metrics around an AI conclusion

Figure 14.1: Review for soundness: independent reproduction, seeded incidents and oversight metrics around an AI conclusion.

Dependence: the reviewer who needs the reviewed

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.

What the analyst can no longer do alone

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.

Three dependencies follow from that, and each calls for a different control.

Dependence for reading. The volume of telemetry exceeds what a person can read, so the analyst reads a selection made by the AI. A conclusion can be well argued from the evidence shown and wrong because of the evidence omitted.
Dependence for method. The agent writes the query, and the analyst may not know the query language of every source well enough to judge whether the query asked the right question. A filter that excludes a service account, a time window that ends an hour early, or a join that drops unmatched rows changes the answer without any visible error.
Dependence on evidence the adversary can influence. Logs, filenames, ticket text and command lines are written, in part, by the people the blue team defends against. An adversary who clears or alters records (MITRE ATT&CK T1070, Indicator Removal) or names a tool after a trusted one (T1036, Masquerading) shapes what the AI reads and therefore what it concludes (9, MITRE, n.d.). The open question is whether an analyst can trust a conclusion when the evidence behind it may have been written to mislead the reading. AI Red Team, Chapters 13 and 18, treat the technical side, that everything security AI reads may be written by the adversary and that the defence is a policy decision point outside the model (64, Nordqvist, 2026). Chapter 15 treats the defence of the SOC's AI. This chapter treats the human side: how a person judges a conclusion drawn from such evidence.

Automation bias and the ironies of automation

The research on human use of automation does not favour the reviewer. Parasuraman and Manzey review the evidence on complacency and automation bias and show that these are documented phenomena of people working with automated aids, found in experts and under high workload, not a failing of particular individuals (76, Parasuraman & Manzey, 2010). Bainbridge named the underlying irony in 1983: the more of a task is automated, the more the human is left with supervising the automation, which needs the most skill and gets the least practice (75, Bainbridge, 1983). AI Threat, Chapters 6 and 14, carry the argument into the present, and AI Governance, Chapters 10 and 21, add the design consequence: human oversight must be designed, with an interruption path, an override log and the authority to use them, not declared (65, Nordqvist, 2026) (62, Nordqvist, 2026). A design that relies on vigilance alone has no evidence behind it.

The AI Act states the same expectation for the systems it regulates: Article 14 requires providers of high-risk AI systems to build in human oversight, and Article 26 requires deployers to assign it to people with the competence, training and authority to exercise it (1, European Union, 2024). SOC tooling is not in general a high-risk AI system, so the articles do not bind it directly, but they describe oversight as a property of design and of named people rather than of a signature on a ticket.

Soundness criteria for a security conclusion

A reviewer cannot judge whether a conclusion is sound without a definition of sound written before the conclusion arrives. AI Red Team, Chapter 10, set the pattern for threat models: soundness is defined in advance, and the reviewer decides each candidate against its provenance (64, Nordqvist, 2026). The same pattern serves the three kinds of conclusion a SOC receives from AI.

Criterion	Triage verdict (B2, B3)	Timeline (B3)	Containment proposal (B4)
Grounding	Each claim cites event identifiers that open in the SIEM	Each entry carries a source event and a timestamp with its time zone	The trigger cites the events and the detection record `DET-*` that raised them
Completeness	Lists the sources queried and the sources that were unavailable or empty	States the window searched and what lies outside it	States which assets share the account, host or network segment affected
Alternatives considered	Names at least one benign and one malicious explanation and the fact that separates them	Marks gaps and the hypotheses that would fill them	Names the less drastic action considered and why it was not proposed
Stated confidence	A class and the basis for it, such as a rule match, a reproduced query or the agent's own estimate alone	Marks each entry as observed, inferred or assumed	States the cost of being wrong in each direction
Reversibility	Whether the closure can be reopened and by whom	Not applicable	The action class, its rollback and the stop path
Stability	A second run on the same inputs gives the same class	A second run gives the same order of events	A second run proposes the same action or states why not

Two points in the table deserve emphasis. First, confidence that rests on the agent's own estimate alone counts for little, because, as the book's own conclusion, a model's stated confidence is part of its output and not a measurement of its accuracy. The basis column forces the agent to say whether anything outside itself supports the claim. Second, the stability row is cheap and revealing: re-running the same case through the same agent and comparing the classes costs machine time only, and a verdict that flips between runs has not earned a human's approval. AI Threat, Chapters 23 and 30, give the stronger reason to rely on more than one evaluation: where models may behave differently under test, assurance layers pre-deployment tests with a shadow period, production monitoring and decoys (65, Nordqvist, 2026). The review criteria in this chapter are the analyst-facing part of that layering.

The criteria belong in the mandate manifest of each agent (Chapter 13) and in the closure policy of each alert class (Chapter 7), so that an output that does not meet them is rejected by the pipeline before it reaches a person. A reviewer's time is then spent on the substance of a conclusion, not on discovering that its citations do not open.

Review that does not start from the AI's answer

The strongest effect of automation bias is anchoring: the reviewer who reads the conclusion first sees the evidence through it. The cheapest correction is a change in the order of work. For review that is meant to be real, the reviewer forms a provisional view before reading the AI's.

For a Level 2 containment proposal the sequence is short. The analyst opens the raw alert and its key fields. The analyst writes down a provisional verdict and one sentence naming the fact that would change it. Only then does the analyst open the agent's summary and compare. The comparison is where the review happens: the analyst asks why the two differ, or, when they agree, whether the agreement rests on the same evidence. This costs minutes per case, and cases cannot all be reviewed this way. That is why the protocol later in this chapter assigns review depth by tier. Drafting first is the response AI Threat recommends against reduced checking (65, Nordqvist, 2026), and it has a second benefit: it keeps the analyst's own investigative skill in use, which is the other half of question five.

Independent reproduction

Reproduction is the technical counterpart of drafting first. The reviewer identifies the one fact on which the conclusion depends, the key fact, and reproduces it by a route the AI did not take.

Re-run the key query by hand. The analyst writes or adapts the query for the key fact in the SIEM's own language, without pasting the agent's. If the two queries return different results, the difference is the finding.
Confirm from a second source. Where the first source is on the affected host or in a log the adversary could have altered, the second source sits elsewhere: the identity provider rather than the endpoint, the network flow record rather than the proxy log. Two sources with independent failure modes are worth more than one source read twice. A clean result from a source the adversary can edit proves little, which is the reason ATT&CK lists Indicator Removal as a technique to design detection around (9, MITRE, n.d.).
Record what was reproduced. The oversight record states the key fact, the route, and the result. A review that reproduced nothing is recorded as such, and the proportion of reviews in which the key fact was reproduced is one of the metrics below.

Reproduction is not free, and a rule that demanded it for every closed alert would defeat the purpose of delegating closure. The tiers decide where it is required: for every Level 2 proposal that would take a production system out of service, for a sample of Level 1 summaries, and for the sampled closures of a Level 3 class.

The critique agent

A second AI can reduce the reviewer's load if it is used with care. A critique agent reads the evidence and the first agent's conclusion and is asked a narrow question: which claims in the conclusion are not supported by the cited events, and which obvious alternative was not considered? Two design choices decide whether this adds assurance or only the appearance of it.

First, the critique agent runs on a different model family from the agent it critiques. This is the book's own design choice, drawn from the correlated-failure argument of AI Threat, Chapter 26: agents that share a model family may share blind spots, so a second opinion from the same family may repeat an error instead of catching it. The book has not tested the choice. Hansa Mutual runs its critique agent on a second self-hosted model family, under mandate manifest MND-HM-SOC-05 (Chapter 13): Level 0 Advisory, read-only, with flags written to the case and nothing else. Second, the critique agent supplies questions to the human, not a verdict that replaces the human. Its output is a list the analyst can check in a minute: claim 3 cites an event that does not mention the account; the benign explanation of a scheduled task was not tested. A critique agent that says "approved" has become a second approver of the same kind as the first, and the pair has the correlated-failure property that AI Threat, Chapter 26, warns about (65, Nordqvist, 2026). The critique agent also reads the same adversary-written text as the first, so it is not a defence against manipulated evidence. It lowers the cost of finding unsupported claims; reproduction and seeds remain the checks on the evidence itself.

Seeded incidents

A team cannot tell by introspection whether its review is real. It can measure by injecting cases whose correct answer is known and counting what is caught. A seeded incident is a known case injected into the queue, and a seeded error is a known fault placed in an AI output. Both are measures of the review process, not of the person reviewing.

Seeds come from three places that the blue team already owns. The post-incident reviews of Chapter 11 supply realistic past cases, rewritten so that no real identity or host remains. The purple exercises with the red team supply scenarios that the detections were built against (AI Red Team, Chapter 26, set out the loop). The detection tests of Chapter 6 supply the event patterns that a given detection must flag. A seed describes what the telemetry and the alert look like, not how an intrusion is carried out, and seeds contain nothing that would work as attack tooling. Seeds are tagged in a registry that reviewers cannot read, and any seed that reaches a playbook is routed to a no-action path, so that a seeded case can never isolate a real machine. A seed on that path tests the closure or approval decision and not the playbook; the playbook itself is tested by the chaos experiments of AI Red Team, Chapter 25, as Chapter 10 describes (64, Nordqvist, 2026).

There are two kinds of measurement.

Seeded errors in AI output. A known fault is placed in an otherwise correct summary: a wrong timestamp, a claim whose cited event does not support it, a missing source, an omitted alternative. The measure is the proportion of faults the reviewer catches. This tests the review of Level 1 and Level 2 output.
Seeded incidents in a delegated class. A synthetic alert, known to be malicious, is injected into a class that the AI closes at Level 3 Bounded. Two questions follow. Did the agent close or escalate it? If the agent closed it, did the sample review catch the closure? The first is the escape rate of the class, and the second is the catch rate of the sample.

Seeding has costs, and they are real. Someone must design and maintain the seeds, at roughly the effort of writing a small detection test each. The seeds must stay realistic as the environment and the detections change, or reviewers learn to recognise them by their staleness. The programme must be announced, because seeding that staff do not know about is covert monitoring, which this book rejects. Staff know that a programme exists, which classes it covers and how results are used, but not which case is a seed. Results are reported for the team and the class, never for a person.

A small sample limits what a rate can mean. With five seeds in a month, a single miss moves the monthly rate by 0.20; over a quarter of fifteen seeds, one miss moves it by about 0.07. The programme therefore reports counts with the rate, reads the trend over a quarter, and treats one bad month as a prompt to look at the seeds and the protocol before it is read as a fact about the team.

Practical guide: Starting a seeded-incident programme

Purpose. Measure whether review of AI conclusions in one alert class catches known faults, and stop extending delegation if it does not.

Roles. The SOC lead owns the programme. A lead analyst or detection engineer acts as seed owner and holds the registry; the seed owner does not review the seeded cases. A second detection engineer reviews each seed for realism and harm. The data protection officer or privacy officer checks that seeds contain no real personal data. Employee representatives agree the reporting rules before the first seed is injected.

Steps.

Choose one class that the AI handles at Level 2 or Level 3, preferably the class with the highest volume and the lowest severity, because that is where attention is thinnest.
Agree the reporting rules with the employee representatives: team and class level only, no individual figures, no use in appraisal or discipline, an aggregate report each quarter, and a review date.
Build the first ten seeds from past cases and detection tests: six seeded errors in AI summaries and four seeded incidents, written so that the correct answer is unambiguous.
Inject five seeds a month at random times and, in a follow-the-sun rota, across shifts. Keep every seed tagged in the registry and routed to a no-action path.
Record each outcome: caught by the reviewer, caught by the critique agent, caught by the sample, or missed. Record the time from injection to catch.
Compute the catch rate over a rolling quarter. Set the threshold at 0.80 to begin and raise it to 0.85 when two quarters have passed above it.
Apply the stop rule. If the rolling-quarter catch rate falls below the threshold, or a seeded incident of high severity is closed and not caught, freeze any extension of delegation for the class; a class at Level 3 returns to Level 2 until the catch rate is back at the threshold for two consecutive months. Record the freeze in an AI Decision Record.
Replace seeds every quarter, and analyse every miss as a design question: was the seed unclear, the presentation misleading, the volume too high or the time too short?

Defaults to adapt. Five seeds a month suits a class with a few hundred reviewed items a month; a larger class needs more. The 0.80 threshold and the two-month recovery period are starting points that the SOC lead may raise but should not lower without a recorded reason. A works agreement may restrict the hours or classes in which seeding is allowed, and it takes precedence.

Definition of done. The programme runs for a quarter with the reporting rules signed, every miss has a recorded analysis, the stop rule has been tested at least once by a tabletop run, and the quarterly report reaches the SOC lead and the representatives in the same form.

Oversight-quality metrics

Seeds measure what review catches. Oversight-quality metrics measure how review is conducted, so that the failure mode of approving in seconds is visible before a seed is missed. AI Red Team, Chapters 6 and 15, define approval quality by time to approval, rejection rate and reversals, and require that where works councils have rights those metrics are agreed first and reported in aggregate (64, Nordqvist, 2026). This book adds the measures that seeding and reproduction make possible.

Metric	What it measures	Reading it
Time to approval	Median and 90th percentile from the proposal appearing to the approval	A median that falls steeply while volume rises is the first sign of rubber-stamping. A median far above the time that reproduction needs signals a queue, not care
Rejection rate	Share of proposals rejected or sent back	Near zero suggests approval without review or a flawless agent, and only seeds can tell which. Very high suggests a mandate, prompt or detection that needs repair
Reversals	Approved actions undone within 24 hours and within 7 days	A rising reversal rate means approvals are not catching wrong actions
Caught-seed rate	Seeded faults caught over seeded faults injected	The direct measure of review quality; read with its counts
Reproduction rate	Share of reviews in which the key fact was reproduced by another route	Shows whether the reproduction rule is followed where it is required
Unassisted share	Share of cases a person works from raw data without the AI's summary	Measures whether the investigative skill that supervision depends on is being exercised

No one metric stands alone. A time floor alone invites waiting before clicking approve. A rejection quota alone invites rejecting for the sake of the number. The metrics are read together and at the level of the team and the class, and a movement in one is a reason to look at the others and at the protocol. They also feed the board page of Chapter 20 as measures of the quality of judgement, beside speed and coverage. The combination is the book's own design, not a published standard.

Worked example: Review protocol and oversight report

The following examples are illustrative. The first is the review protocol Hansa Mutual's SOC keeps in version control; the second is its quarterly oversight report for the third quarter of 2027.

# reviews/protocol/soc-tiers.yaml  (illustrative)
protocol: soc-review-tiers
version: 1.1.0
decision_record: AIDR-0769
owner: group-soc-lead
review_date: 2027-12-01
tiers:
  - id: T1
    scope: HM-SEC-001 summaries and enrichments (Level 1 Assisted)
    review: sample
    sample_rate: 0.10
    reproduce_key_fact: sampled
  - id: T2
    scope: HM-SEC-001 containment and escalation proposals (Level 2 Supervised)
    review: individual
    reviewer_starts_from: raw_alert_and_own_hypothesis
    reproduce_key_fact: required
    critique_agent: required
  - id: T3
    scope: PBK-HM-ISOLATE-01, session revocation and collection (Level 3 Bounded)
    review: playbook_sample_and_seeds
    sample_rate: 0.05
    stop_path: outside_soc_platform
  - id: T4
    scope: HM-SEC-006 closure of classes SC-01 and SC-02 (Level 3 Bounded)
    review: class_sample_and_seeded_incidents
    sample_rate: 0.05
    class_owner_signs_quarterly: true
critique_agent:
  mandate: MND-HM-SOC-05
  model_family: second-self-hosted-family   # not the family of HM-SEC-001
  output: questions_for_reviewer            # never an approval
seeds:
  incidents_per_month: 5                    # synthetic alerts, T3 and T4 classes
  errors_max_share_of_t2_proposals: 0.05    # a ceiling, not a quota
  registry_visible_to_reviewers: false
  seed_actions: no_action_path
limits:
  open_proposals_per_reviewer: 12
  open_proposals_per_night_reviewer: 8
  back_pressure:
    level_2_class: drop_to_level_1          # agent summarises, stops proposing
    level_3_class: pause_intake_and_escalate_to_duty_manager
thresholds:
  caught_seed_rate_min: 0.80
  reproduction_rate_min_t2: 0.80
  unassisted_share_min: 0.20
  rejection_rate_band: [0.05, 0.30]
  approval_median_floor_seconds: 60        # triggers protocol review, not individual action
stop_rule:
  action: freeze_delegation_and_return_to_level_2
  recover_after_months_at_threshold: 2
reporting:
  level: team_and_class
  individual_figures: never
  agreed_with: [konzernbetriebsrat, polish-service-centre-representatives]

# reporting/oversight/2027-q3.yaml  (illustrative)
report: OQM-HM-SOC-01
period: 2027-Q3
protocol: AIDR-0769
reporting_level: team
proposals_reviewed: 9600
volume_vs_2026_baseline: 3.0
time_to_approval_median_minutes: 4.2
time_to_approval_p90_minutes: 18
rejection_rate: 0.12
reversals_within_7_days: 0.02
seeds_injected: 28               # 15 seeded incidents (5 a month) and 13 seeded errors
seeds_caught: 24
caught_seed_rate: 0.86
caught_seed_rate_status: met_within_sampling_error   # 23 of 28 is 0.82, 22 of 28 is 0.79
misses_analysed: 4
reproduction_rate_t2: 0.71
reproduction_rate_target: 0.80
reproduction_status: missed                          # flagged below
unassisted_share: 0.10
unassisted_share_target: 0.20
unassisted_status: missed                            # read in Chapter 23
delegation_changes: none
flags: [reproduction_rate_below_target, unassisted_share_below_target]
decisions_requested: [review_t2_time_allowance_for_reproduction]

The report is deliberately not a clean pass. The caught-seed rate meets its threshold, but two more misses would breach it, and the report says so beside the figure. The reproduction rate for Tier 2 missed its target of 0.80, which means that in 29 per cent of Tier 2 reviews a step the protocol marks as required was not done, and the report flags the gap and requests a decision on the time allowance instead of calling the quarter met. The unassisted share of 0.10 is half the policy's one case in five; Chapter 23 reads that gap as a finding about skill.

Fatigue and volume

Review is work, and the more AI proposes, the more of it there is. When Hansa Mutual's SOC extended the investigation agent across the follow-the-sun rota, the number of proposals reaching reviewers rose to about three times the baseline, and review became the new queue. A queue of machine conclusions that are nearly always right trains the reviewer toward approval, which is the mechanism by which automation bias gets its effect.

The research on alert handling supports the concern, within limits. Alahmadi and colleagues surveyed 20 SOC practitioners and then ran a qualitative discovery study with 21. They found that most false positives are benign true alarms, and they describe alarm validation as a tedious task that can cause alarm burnout and eventually desensitisation (69, Alahmadi et al., 2022). The study concerns alarms raised by detection tools, not the review of AI conclusions, and it is qualitative, so it does not establish how large the effect is. The interpretation in this book is that review of AI conclusions shares the structure the study describes, many items, mostly benign, each needing a check that feels unnecessary, and should be designed with the same risk in mind. Whether AI reduces or intensifies fatigue overall is not settled by any evidence the book relies on; Chapter 21 returns to it.

Four design measures keep review real at volume.

Cap open proposals. Each reviewer holds at most a stated number of open proposals, 12 by default and fewer at night when a single reviewer covers the shift. The cap makes the limit of human attention a property of the system.
Apply back-pressure to the agent, not pressure to the person. When the cap is reached, a Level 2 class drops to Level 1: the agent continues to summarise but stops proposing, until the queue clears. Dropping a Level 3 closure class to Level 2 would put every closure in front of a reviewer and add to the queue, so a Level 3 class instead pauses its intake to the agent and escalates to the duty manager. Either way delegation shrinks when oversight cannot keep up, which is the reverse of the usual drift.
Rotate reviewers and mix the work. Reviewing for hours without a change of task degrades attention. Rotate reviewers between review, investigation and engineering at least every two hours, and keep the unassisted share of cases as part of the working week.
Treat speed as a signal for the protocol. A time floor, 60 seconds in the Hansa protocol, does not block an approval or identify a person. It tells the SOC lead that in some class approval is faster than reproduction allows, and the lead then reviews the class, the tier and the volume.

These measures cost throughput. A SOC that adopts them closes fewer cases per hour than one that does not. That is the point, and Chapter 20 explains why closure rate is the wrong measure of a SOC's output.

The works-council dimension

Everything in this chapter measures people's work, however carefully it is framed as a measure of the system. The time an analyst takes to approve a proposal is a data point about that analyst, and the system that logs it can produce an individual ranking with one query. Chapter 21 treats the analyst's experience of being measured. The generic terms of an agreement on logging (purpose, granularity, reporting and change) are those of Chapter 12; the oversight metrics add three terms of their own.

Aggregate only, and not for appraisal. Figures are reported by team, class and quarter. A missed seed is a finding about the system and is not used in appraisal, promotion or discipline; a reviewer who misses one is asked what in the tool, the volume or the protocol made the miss likely.
Disclosed seeding. The works agreement describes the seeding programme, the classes it covers and the way results are used. Seeds are not announced individually, and the programme is never secret.
A review date for the metrics, the thresholds and the seeding rates.

At Hansa Mutual the Konzernbetriebsrat co-determines under BetrVG §87(1) no. 6 on tools that can monitor employees' behaviour or performance, and the oversight metrics and the seeding programme are agreed under the SOC annex to KBV-IT-2024; the Polish service centre's representatives agree the same terms, and the Swedish subsidiary consults its unions. At Nordvik Region the union has negotiated that closure rates and similar measures are never reported by name, and the oversight metrics fall under the same rule. Groups of fewer than five people are not reported at all (Hansa's agreement). Data about identified employees is personal data under the GDPR, which leaves room for national rules on employee data in Article 88 (8, European Union, 2016).

The reason is practical. A reviewer who fears that a missed seed will count against them has an incentive to reject everything or to hide doubt, and either behaviour makes the metrics worthless. AI Boss, Chapter 26, makes the same argument for managers who oversee decisions about people: oversight is only real where the overseer can say no without penalty (67, Nordqvist, 2026).

Who answers for a missed closure

Who is accountable for a missed intrusion when AI closed the alert and an analyst accepted the closure without reading the evidence? The law gives a partial answer. NIS 2 Article 20 places responsibility for cybersecurity risk-management measures on the management bodies of entities in scope, and DORA Article 5 does the same for the management body of a financial entity (3, European Union, 2022) (2, European Union, 2022). Neither article lets responsibility pass to a tool, and the chain of accountability in Chapter 13 shows who holds each link: the authority that granted the level, the class owner who answers for closing the class and for the sampling that should have found an escape, and the analyst who accepted the closure. The agent answers for nothing, because it holds no accountability to answer with.

This chapter adds the conclusion about the last two links, which is the book's own. Accountability for a missed closure rests in the first place with the people who designed the review, and in the second place with the person who approved. An analyst who approved a conclusion that the process made impossible to check carries less of the responsibility than the SOC lead who accepted the process. The analyst who approved a conclusion in seconds, in a process that provided a reproduction route, a cap on volume and the time to use them, carries more. The oversight record makes the distinction visible: it states what was reproduced, what was available and what the reviewer's provisional view was. Without it, accountability falls on whoever clicked last, which is neither fair nor effective. What the SOC must avoid is the empty cell: a closure class with no owner, or an approval given in seconds that nobody measures.

Across the degrees of delegation

Review depth follows the degree of delegation. At Level 1 and Level 2, the AI's output is reviewed item by item (at Level 1 by sample). At Level 3, the review moves from the action to the playbook, the sample and the seeded incident. Level 4 Autonomous is not used for an irreversible B4 Respond action or for an action that decides about a named person's access to work, and so no tier below describes it. Mode 0 Ambient AI, such as a managed service's own triage, falls outside this table because the customer cannot review what it cannot see; the review there is by contract and sampling, which Chapter 16 takes up.

Level	What is reviewed	How	Seeds
Level 0 Advisory	The advice, when the analyst chooses to use it	Analyst's judgement; no protocol needed beyond drafting first on sampled cases	None
Level 1 Assisted	Summaries and enrichments	Sample, with the key fact reproduced on a share	Seeded errors at a low rate
Level 2 Supervised	Each proposal before action	Individual review; own provisional view first; reproduction required; critique agent required	Seeded errors in about 5 per cent of proposals
Level 3 Bounded	The playbook or the closure class, its sample and its results	Review of the playbook manifest (Chapter 10) or the closure policy (Chapter 7), a sample of executions or closures, reversals, the stop path	Seeded incidents in the class

Outlook

Three statements about the future of verification, each labelled. It is observable that automation bias and complacency are documented in people working with automated aids (76, Parasuraman & Manzey, 2010), and that AI tools in SOCs already produce summaries and proposals that people review. It is expected that AI outputs will increasingly carry structured, machine-checkable reasoning traces, in which each claim references the event that supports it and a script can test that the reference holds. This follows the move to evidence as code that Architecture as Code (Chapter 15A) describes (61, Nordqvist, 2025), and a checkable trace would let the pipeline reject unsupported claims before a person sees them. It remains speculation that AI will verify itself so reliably that no human check is needed for security conclusions; no present evidence supports it, and a check that sits inside the system it checks fails in the same way as the system.

Nordvik Region and Hansa Mutual

Nordvik Region has six analysts and no detection-engineering function, so its review problem is small in volume and large in dependence. The triage assistant NR-SEC-001 runs at Level 1 Assisted on the Region's reserved capacity (AIDR-0301), so every summary is advice that an analyst reads. The senior security analyst, Karin Lund, seeds known errors into three of the five summaries that go to a deep review each month; a second analyst reviews them without knowing which are seeded. The practice is recorded as AIDR-0715. In the first quarter the team caught seven of the nine seeded errors, a count too small to call a rate, and the Region reports it as a count for the team as a whole and never by individual. What Nordvik cannot yet review is the provider's out-of-hours AI, which closes a class of low-severity alerts under a framework agreement that says nothing about sampling; the review there depends on the contract terms of Chapter 16.

Hansa Mutual has a different problem. When HM-SEC-001 was extended across the rota, proposals to reviewers tripled and the median time to approval fell sharply. The SOC lead opened the review protocol of AIDR-0769: tiers by level, reproduction required for Level 2, a critique agent on a second model family, a cap of 12 open proposals per reviewer, five seeded incidents a month and a stop rule. The Konzernbetriebsrat and the Polish service centre's representatives agreed the metrics as aggregate. In the third quarter of 2027 the median approval time was 4.2 minutes and the caught-seed rate 0.86 against a threshold of 0.80, while the reproduction rate and the unassisted share missed their targets and the report said so. The two organisations differ in what they can measure and what they can only ask for: Nordvik measures a small assistant closely, and Hansa measures an agent team at scale with a protocol it controls.

Summary

This chapter described how an analyst verifies what AI concludes when the analyst depends on the AI to read the data. The dependence has three forms, reading, method and evidence that an adversary can influence, and automation bias is a documented property of people working with automated aids, not a failing of individuals. Verification therefore has to be designed. The chapter concerns B2 Detect, B3 Investigate and B4 Respond.

The design has four parts. Soundness is defined in advance and written into the mandate manifest and the closure policy. Review does not start from the AI's answer: the analyst forms a provisional view, reproduces the key fact by another route and uses a critique agent on a different model family for questions, not verdicts. Seeded errors and seeded incidents measure what review catches, with a stop rule that freezes delegation when the catch rate falls. Oversight-quality metrics show how review is conducted and are read together, and a report that misses a target says so. Review stays real at volume only if the system gives way before the reviewer does, through caps, back-pressure, rotation and protected unassisted work. Because these measures concern people's work, they are agreed with employee representatives first, reported in aggregate, disclosed and never used in appraisal.

The book's own conclusion is that accountability for a missed closure rests first with those who designed the review and then with the person who approved, and that the oversight record makes the distinction visible. Chapter 15 turns from verifying the SOC's AI conclusions to defending the SOC's AI itself, where the evidence the agents read is written by the adversary and the SOC platform is a tier-0 asset.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (8, European Union, 2016)
MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (61, Nordqvist, 2025)
Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (64, Nordqvist, 2026)
Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (65, Nordqvist, 2026)
Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6. (66, Nordqvist, 2026)
Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7. (67, Nordqvist, 2026)
Alahmadi, B. A., Axon, L. & Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. 31st USENIX Security Symposium. (69, Alahmadi et al., 2022)
Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (75, Bainbridge, 1983)
Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3). (76, Parasuraman & Manzey, 2010)