Can a security operations centre use AI on incident data without a cloud SIEM?

Yes. A security operations centre can run AI triage, enrichment, correlation and report drafting entirely inside its own security perimeter, on hardware the operator owns, reading from the log stores it already maintains. No alert, packet capture or analyst note needs to leave the building, and every AI action can itself be written to a sealed, independently verifiable ledger. The genuine trade is cross-tenant threat intelligence, and a hybrid design recovers most of it through inbound-only feeds.

The question matters in 2026 because SOC teams are under pressure to adopt AI triage at exactly the moment boards are asking where incident data physically goes. Incident data maps every weakness an organisation has, which makes the choice of AI architecture a security decision rather than a procurement detail.

Why is incident data different from other enterprise data?

Incident data is a map of an organisation's weaknesses. Alerts show which detections fire and which do not. Packet captures expose internal network topology, naming conventions and unpatched services. Analyst notes record what the defenders worried about, what they missed and how long they took to respond. Aggregated on infrastructure the organisation does not control, this becomes an attacker's handbook held by a third party.

That is why shipping incident data to a cloud AI service is categorically different from shipping marketing copy. A breach of the provider, a misconfigured tenant or an over-broad retention clause does not leak one document. It exposes the defensive posture of every customer whose telemetry sits in the same estate.

What can AI actually do inside the perimeter?

Everything the cloud pitch promises, except the parts that depend on other tenants. Sovereign models running on hardware the SOC owns can read from the existing on-premise SIEM or log store and take on the four tasks that consume most analyst time:

• Triage: scoring and de-duplicating alerts so analysts open the ones that matter first.
• Enrichment: joining an alert to asset inventories, identity records and historical incidents held on site.
• Correlation: linking events across sources into a single timeline for an incident.
• Report drafting: producing incident summaries and post-incident reviews from the case record.

None of these tasks requires an outbound connection. They require compute next to the data, and read access to stores the SOC already runs.

What does a SOC give up without a cloud SIEM?

Cross-tenant threat intelligence is the honest cost. A large cloud SIEM observes attacks across thousands of customers and can push a detection learned from one tenant to all the others within hours. A sovereign deployment does not see other tenants and never will. That is the containment trade, and it should be stated plainly rather than argued away.

The mitigation is directional. Threat intelligence is valuable inbound and dangerous outbound. Commercial and community feeds, vendor detection content and indicator lists can flow into the perimeter on a controlled, one-way path. What never flows is the SOC's own telemetry going the other way.

How does the SOC meet the evidence bar it enforces on others?

A SOC that tells the business every privileged action must be logged cannot exempt its own AI. Under the sovereign pattern, each AI action carries its own per-action identity and is written to an append-only audit ledger signed under FIPS 204, the primary post-quantum digital signature standard, so the record remains verifiable offline and long after the incident closes.

This is where our architecture applies the rule to itself. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on hardware the operator owns. Every action a model or agent takes inside it is cryptographically sealed to the ledger with hardware-attested identity, so the question of what the AI read and produced during an incident has a checkable answer. The mechanisms involved sit within 104 filed UK patent applications, with 2,340 claims, owned by Mickai LTD.

What does a defensible hybrid design look like?

The workable pattern is a zero-egress inbound perimeter. Nothing inside the SOC enclave initiates an outbound connection to an AI provider. Inbound threat intelligence feeds terminate at a controlled boundary, are inspected, and are then replicated inward. Model updates arrive the same way, as signed artefacts verified before deployment.

A named test settles most architecture debates. Call it the egress enumeration test: list every byte of incident data that leaves the perimeter, its destination and its legal basis. A sovereign deployment produces an empty list. A cloud SIEM produces a long one, and each line on it is a dependency on someone else's controls.

“A security operations centre should not have to export the map of its own weaknesses to gain the benefit of AI.”

Does the sovereign pattern satisfy regulators and auditors?

Regimes such as DORA, in force since 17 January 2025, and NIS2, which covers essential and important entities, push organisations to understand and evidence their ICT dependencies. An in-perimeter AI deployment shortens that evidence chain: the data location is known, the processing hardware is owned, and the audit ledger verifies without reference to any provider. A contractual promise from a cloud provider is not a technical guarantee, and supervisors increasingly ask for the latter.

How the perimeter, the sealed ledger and the studios that sit on them fit together is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Can I run AI triage on my SIEM data without sending anything to the cloud?

Yes. Triage models can run on hardware inside the security perimeter, reading from the existing on-premise SIEM or log store. Alert scoring, de-duplication and prioritisation are local computations, and no outbound connection is required for any of them.

Do I lose threat intelligence if my SOC AI is fully on-premise?

Outbound participation in cross-tenant learning is lost, and that is a real cost. Inbound intelligence is not: commercial and community feeds can enter through a controlled, one-way path. The design principle is that intelligence flows in while telemetry never flows out.

How do I prove what the AI did during an incident?

By making the AI's own actions part of the incident record. In a sovereign deployment every model and agent action carries a per-action identity and is sealed to an append-only ledger signed under FIPS 204, so the sequence of reads and outputs can be verified offline, months later, without trusting any vendor's logs.

Is a private cloud tenant the same as running SOC AI on our own hardware?

No. A private tenant narrows exposure, but the infrastructure, the hypervisor and the operational staff remain a third party's, and telemetry still crosses an organisational boundary. Whether that is acceptable is a risk decision, and it is not equivalent to processing on hardware the SOC owns inside its own perimeter.

What should we ask a vendor offering AI for the SOC?

Ask where inference runs, what leaves the perimeter, whether the system still functions with outbound connectivity removed, and how AI actions are logged and verified. If the answers depend on contractual assurances rather than architecture, treat the gap as a finding rather than a footnote.