What is an AI SOC, and what is it not?

The queue that greets a team in the morning is mostly nothing, and the job is finding the part that is not. That work has a specific shape: read a detection, gather the events around it, decide whether the combination is benign, and write down why. It is high volume, moderately skilled, and almost entirely reading.

That shape is what makes it the entry point. It is not that triage is the most valuable analyst work; it is that triage is the work where volume rather than judgement is the binding constraint, and volume is the thing a model relieves.

The consequence is worth stating plainly, because it is often overstated in the other direction. An AI SOC does not remove the analyst role. It changes what arrives at the analyst's desk from a queue of raw detections to a set of verdicts with reasoning attached, of which some fraction needs a human to disagree with it.

Alerts do not stop at 5 p.m., and the queue that greets a human at 09:00 is mostly nothing. The work worth a person's attention is the last line of this list, and finding it is the job.

A verdict that arrives without its working is a score, and a score is not reviewable. This has a practical consequence and a regulatory one, and the practical one bites first.

Practically, an analyst who cannot see why the system ruled something benign has two options: accept it, or redo it. If they accept it, the system's errors become the organisation's errors silently. If they redo it, the system saved nothing. Neither is the outcome the tool was bought for, and both follow directly from hiding the reasoning.

In regulatory terms it is sharper. Under NIS2 an entity has to be able to describe how it detects and handles incidents, and a detection process whose decisions cannot be explained is difficult to describe. The same logic underlies the NIST framework's measure function: knowing that verdicts are right requires cases you can re-examine, not an accuracy figure.

There is also a failure mode specific to this category. OWASP lists misinformation as LLM09:2025, and a confident, well-written, wrong verdict is more dangerous than an ambiguous one precisely because it reads as finished work.

Excessive Agency enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM.

It is not a staffed operations centre. A model working the queue at three in the morning is not the same as people being awake, and a vendor that lets those two be confused is selling the difference between them. Coverage of the queue and availability of a human are separate commitments and should be priced and described separately.

It is not a replacement for a response process. Somebody still has to decide to isolate a segment, tell a regulator, and call a customer. Under NIS2 the first of those reporting steps runs on a 24-hour clock, and the clock is not started by the tool.

It is not a compliance control on its own. Deploying one does not satisfy a risk management requirement, because the requirement is about the measures you have chosen and can justify. A tool is evidence within that argument rather than a substitute for it.

A definition of an AI SOC is easier to judge against the real distribution of what arrives. The ENISA Threat Landscape 2025 curated 4875 European events over the year to June 2025, and the shape of that dataset explains why triage is where the category starts.

Social engineering is the primary entry point, with phishing and its variants accounting for around 60 percent of observed cases. Vulnerability exploitation follows at 21.3 percent, botnets at 9.9 percent and malicious applications at 8 percent. Insider unauthorised access is 0.8 percent, which is small in count and disproportionate in consequence.

Read as a workload rather than as a threat report, that distribution is mostly high-frequency events whose significance depends on context that is not in the alert. Availability attacks affected 81.4 percent of EU sectors and were largely hacktivist and low impact, which is the definition of work that must be done and produces nothing most of the time.

Based on the analysis of the dataset, social engineering tactics remain the primary entry point for threat actors, with phishing (including vishing, malspam, and malvertising) accounting for about 60% of observed cases.

A SIEM correlates according to rules somebody wrote, which means it can only recognise the patterns that were anticipated. That is a strength in the cases it covers, because the behaviour is deterministic and auditable, and a weakness at the edges, where the interesting activity tends to sit.

An AI SOC forms a judgement about a combination it has not been told about in advance. The trade is exactness for coverage: the SIEM rule fires identically every time and the model's judgement does not, which is why the reasoning has to be inspectable for the output to be usable.

In practice the two coexist rather than compete. The rules that reliably matter stay rules, because a deterministic detection is cheaper and easier to defend, and the model handles the residue the rules were never going to catch.

SOAR executes a playbook you wrote, in order, with branches you anticipated. It is automation of a decision that has already been made. An AI SOC makes the decision, which is a different category of thing and carries different risk.

The distinction matters most when something goes wrong. A SOAR playbook that misfires did what it was told, and the fix is in the playbook. A model that reached a wrong verdict did not violate an instruction, and the fix is either in the context it was given or in the boundary around what it may do with a verdict.

Most deployments end up with both. The judgement is the model's, the execution is the playbook's, and the boundary between them is where the approval requirement sits.

Reading every alert with full context means a model call per alert, sometimes several, and that is a running cost rather than a licence. It behaves differently from the software line items around it: it scales with incident volume, which is the one variable nobody controls.

The consequence is that spend control belongs in the architecture rather than in a monthly review. A system without a hard ceiling in front of model calls converts an unusual day into an unusual invoice, and unusual days are the ones the system exists for.

This is also where the European hosting question becomes concrete rather than philosophical. Inference has to run somewhere, that somewhere is named in a contract, and for an organisation inside NIS2 scope the answer belongs in the same file as the rest of the supply chain assessment.

A hard spend cap sits in front of every model call, so autonomy never becomes an open tab.

The safe trial shape is shadow mode: the system reads the live queue and produces verdicts, and nothing it produces reaches the estate. You compare its verdicts against what your analysts concluded, on the same events, for long enough to include a bad week.

Two measurements are worth defining before starting, because defining them afterwards invites motivated reasoning. The first is disagreement rate broken down by direction, since a system that is over-cautious and one that is over-confident fail differently and only one of them is dangerous. The second is what the reasoning looked like on the cases where it was wrong.

Resist the temptation to measure time saved during a shadow trial. Nothing is saved while a human is still doing the work, and a figure produced under those conditions describes an experiment rather than a deployment.

Model quality is the least useful axis of comparison, because it changes underneath you and because no vendor will describe their model as the weaker one. The durable differences are architectural and contractual.

Four questions do most of the work. Which actions execute without approval. Whether the reasoning for each verdict is retained and exportable. Where inference runs and under whose contract. And what the rollback path is when an automated action was wrong.

Each of those has a demonstrable answer. A vendor can show you the approval configuration on a screen, export a verdict with its reasoning, name the hosting region, and walk through a rollback. A vendor who answers any of the four with a percentage has answered a different question.