This is Post 1 of 7 in the series “Building Security Operations That AI Can Run.”
Every security transformation programme I have seen start the wrong way begins with the same question: what should we collect? A new SIEM gets deployed. Logging infrastructure gets expanded. The team starts ingesting everything — firewall logs, endpoint telemetry, cloud audit trails, DNS queries, authentication events. Within six months the organisation has petabytes of data, a SIEM bill that grows faster than the security budget, and no meaningful improvement in their ability to detect or respond to threats. The data is there. The capability is not.
The reason is that data without a decision context is not intelligence — it is noise at scale. And the only way to distinguish between data that matters and data that does not is to start from the decisions you need to make, not from the data you could collect. The correct founding question for any security programme modernisation is: what are the decisions my security operation makes every day, and which twenty of them are consuming the most analyst time, generating the most errors, or creating the most organisational risk? That question, answered honestly, produces a prioritised map of where AI can add value. The data collection strategy follows directly from it.
In practice, this mapping exercise surfaces three tiers of decision — each requiring a different response.
The base of the pyramid — high-volume, low-complexity decisions — is where your AI programme should start. Alert triage on well-characterised event types, IOC enrichment, known malware classification: these are made dozens or hundreds of times per shift, they are well-defined, and their volume creates the large labelled datasets AI models need to learn from. The apex — low-frequency, high-stakes calls like major incident declarations or regulatory disclosures — must stay with humans. They require organisational context and accountability that no model can carry.
The dangerous middle tier is where most programmes fail. These decisions appear routine — they arrive with the same alert format, the same metadata, the same initial pattern as the automatable decisions at the base. But they contain hidden context that changes the correct response entirely. Mapping the middle tier explicitly — identifying the conditions that distinguish it from the automatable base — is the hardest part of the inventory exercise and the most important.
The hidden complexity tier is also where large language models offer something classical ML cannot. An ML model on a middle-tier decision produces a confidence score. An LLM can reason about the same decision — surfacing the contextual factors that distinguish a true positive from a false positive, flagging the specific data point that would change the assessment, and explaining its reasoning in language an analyst can evaluate in seconds. This does not eliminate human authority over middle-tier decisions. It makes it possible to begin augmenting them.
The practical output of this exercise is a decision inventory — a documented list of every recurring decision type, its tier, the data it currently requires, the analyst time it consumes, and the error rate when it goes wrong. That inventory is the foundation every subsequent step in the programme builds on. Without it, you are buying AI capability without knowing which tier it should operate in.
The organisations that get this right typically discover that a small number of decision types — usually between five and ten — account for the majority of analyst time and operational risk. They also discover that many of their current data collection investments are not feeding any decision in the pyramid at all. Eliminating that noise is often as valuable as the improvements that follow.