The Sovereign AI SOC: A Reference Architecture for Regulated Industries

Every AI SOC platform on the market today is marketed against the same architecture diagram. Customer telemetry flows to a vendor-managed cloud. A commercial LLM API does the reasoning. Outputs come back to the analyst console.

For a mid-market SaaS company, that architecture is fine. For a bank, a critical infrastructure operator, or a defense supplier, it is structurally unusable. NIS2, DORA, GDPR, CMMC, and the EU AI Act each rule out a different part of it. Stacked together, they rule out the whole thing.

This is the architecture we built instead. It is the reference we use when deploying Minerva into regulated environments, and it is the answer to a question we get on every first call: what does an AI SOC actually look like when none of the data, none of the compute, and none of the models can leave the customer's control?

What "sovereign" actually means

The word gets used loosely. We use it strictly. A SOC architecture is sovereign when all six of the following hold at the same time:

Data residency. All customer telemetry, logs, alerts, case data, derived intelligence stays inside a perimeter the customer controls. On-premise, sovereign cloud, or air-gapped. Never replicated outside it.
Compute residency. Every inference, every embedding, every agent step executes on infrastructure under the same control. No API calls to externally hosted models that you cannot control.
Model independence. The platform runs without any third-party AI provider. Updates are explicit, scheduled, and auditable, not streamed.
No vendor telemetry. The vendor receives no logs, no usage data, no derived metadata. Nothing flows back.
Decision auditability. Every agent action, what it saw, what it concluded, what it did, is logged in a tamper-evident trail the customer owns and can hand to a regulator.
Regulatory mapping by design. NIS2, DORA, GDPR, CMMC and the EU AI Act are not addressed in a compliance appendix. They shape the architecture itself.

The reference architecture

We think of it as six layers inside a single sovereign boundary. The boundary is the perimeter the customer defines and controls — typically on-premise, sometimes a sovereign cloud region under SecNumCloud or equivalent qualification, sometimes air-gapped for defense or classified environments.

Layer 1 — Data ingestion

Connectors pull telemetry from the customer's existing stack: SIEM, EDR, NDR, IAM, cloud audit logs, ticketing, threat feeds. Everything terminates locally. There is no ETL to a vendor cloud, because there is no vendor cloud in the path. The same applies to enrichment: where commercial threat intelligence is used, it is mirrored into the local environment, not queried live across a public network.

The design principle here is mundane and important: connectors are the most common place where sovereignty quietly breaks. A single integration that phones home is enough to invalidate the rest of the architecture. Every connector in this layer is built or audited against that constraint.

Layer 2 — Knowledge layer

A knowledge graph and vector store hold the operational memory of the SOC: assets, identities, network topology, prior incidents, custom detections, business context, regulatory obligations. Both stores are local. Agents read and write here, and analysts can query it directly.

The knowledge graph is the part of the architecture that lets agents move past pattern-matching. An alert isn't an alert in isolation, it is an entity touching other entities the SOC already knows something about. That context is what separates an AI SOC from a faster log search.

Layer 3 — Model serving

This is the layer most cloud-native AI SOCs hand-wave around. In a sovereign architecture, model serving is local. Open-weight LLMs run on customer-controlled GPUs, on dedicated on-premise inference clusters, or on HPC infrastructure for customers operating at scale. Embedding models, reranking models, and any specialized classifiers run on the same fabric.

A few decisions follow from this. Latency budgets shape model choice. A 70B-parameter model running locally serves a triage workflow differently than a 7B one, and the architecture has to accommodate both. Throughput is finite, so the orchestration layer above has to be efficient about when reasoning is necessary and when retrieval is enough. And model updates are versioned events, not background streams.

Layer 4 — Agent orchestration

Six specialized agents operate on top of the layers below: Triage, Threat Hunting, Vulnerability Management, Incident Response, Detection Engineering, and Threat Intelligence. Each agent has scoped tools, scoped data access, and scoped authority. None of them have wholesale autonomy.

The reason for six agents instead of one general-purpose one is operational, not architectural fashion. A triage agent that can also push detections is a triage agent that can quietly disable detections. Separation of duties exists in human SOCs for the same reason it exists here. The orchestration layer enforces those boundaries and logs every crossing.

Layer 5 — Human interface

The analyst console presents agent output the way a senior analyst presents a case to a junior one: with the evidence, the reasoning, the conclusion, and the suggested action — separable and inspectable at each step. Analysts can accept, modify, or reject. Nothing irreversible happens without human confirmation by default, and the threshold for what counts as "irreversible" is configurable per agent and per environment.

This layer is also where explanation lives. An agent that cannot explain why it concluded what it concluded is not deployable into a regulated SOC. Explanation is a feature, not a debugging convenience.

Layer 6 — Audit and compliance overlay

Every action — every prompt, every tool call, every model response, every analyst intervention — is recorded in an append-only audit log under customer control. The same overlay maps recorded events to the specific obligations they evidence: NIS2 Article 23 reporting, DORA Article 17 incident classification, GDPR Article 30 records of processing, EU AI Act Article 12 logging requirements for high-risk systems.

This is the layer that turns a SOC platform from a security tool into a defensible compliance artifact. When an auditor asks how a decision was made, the answer is in the log. When a regulator asks who saw what data, the answer is in the log. The architecture treats that as a first-class requirement.

Decisions we made and why

A reference architecture is also a set of explicit tradeoffs. The ones worth surfacing:

Local inference over hosted APIs. Slower at the bleeding edge of frontier model performance, but the only choice compatible with the GDPR cross-border transfer regime for sensitive telemetry. The performance gap is also narrowing fast, open-weight models in 2026 are good enough for the SOC workloads we actually run.

Six agents over one. More engineering overhead, cleaner separation of duties, better explainability, better failure isolation. A monolithic agent is easier to demo and harder to defend in front of a regulator.

Knowledge graph over pure vector search. Vector search is excellent for similarity. It is poor at "show me everything connected to this entity through three hops." Threat hunting and incident response are graph problems before they are similarity problems.

Explicit updates over streaming ones. A model that updates itself overnight is a model that changed its behavior without an audit trail. In a regulated SOC, that is a non-starter.

What is deliberately not in the architecture

Listing what isn't there is sometimes more useful than listing what is.

No outbound calls to commercial LLM APIs.
No vendor-managed cloud component in the customer's data path.
No telemetry, usage metrics, or model feedback flowing to the vendor.
No agent with unrestricted tool access or unscoped data permissions.

Each of these absences is the answer to a real audit question we have been asked.

How the layers map to regulation

A short version, because the full mapping is its own post:

NIS2 — Articles 21 (risk management) and 23 (incident reporting) are addressed by the audit overlay (Layer 6), the detection engineering agent (Layer 4), and the documented response workflows the orchestration layer produces.
DORA — Article 17's classification and reporting timelines fall out of the agent orchestration and audit layers. Article 28's third-party risk requirements are satisfied because the architecture has no third-party data processor in the critical path.
GDPR — Article 30 records of processing and Article 32 security of processing are evidenced by the audit log and the sovereign boundary itself. Cross-border transfer concerns under Schrems II do not arise, because there are no transfers.
EU AI Act — The platform is designed to meet the obligations placed on providers and deployers of high-risk AI systems: logging (Article 12), transparency (Article 13), human oversight (Article 14), and robustness (Article 15). The human interface and audit overlay carry most of this load.
NCA-NCC — sovereign boundary + audit overlay map to NCA's data residency, access governance, and audit-logging requirements for CNI and regulated industries.
CMMC — sovereign boundary handles CUI residency, audit overlay covers the audit-and-accountability domain, agent-scope separation maps to access control at Level 2 (aligned with NIST SP 800-171).

The shorter version

A sovereign AI SOC is an AI SOC where the architecture itself — not a deployment option, not a configuration flag — guarantees that data, compute, models, and decisions remain under the customer's control. The reference architecture above is how we built Minerva to meet that bar.

If you operate in regulated European industries and the AI SOC vendors you have evaluated cannot answer where their model inference happens, where their customer data lives, or how their agent decisions get audited — those are not implementation details. Those are the architecture.

Minerva is CyberACI's sovereign AI SOC platform, deployed across data privacy aware enterprises, finance, critical infrastructure, and defense. If you'd like to see the reference architecture applied to your environment, book a call.