For many organizations, the question about AI in the SOC is not whether it works. It is whether they are allowed to use it. Banks, healthcare providers, public-sector bodies, defense suppliers, and critical-infrastructure operators hold security telemetry that is among the most sensitive data they have, and their regulators, auditors, or contracts often restrict where it can be processed and by whom. Sending alert context to a third-party model API, however well governed, can be a non-starter.
That does not have to mean opting out of AI-run operations. It means moving the model to the data.
What on-prem means here
mysoc.ai runs in our cloud at cloud.mysoc.ai or in your own environment. In an on-prem deployment, SiemCore, the AI operations layer, and tenant data all run on infrastructure you control, and the AI layer can use a locally hosted model instead of a cloud provider. Triage, investigation, ATT&CK mapping, customer chat, and reporting all run against that local model. The investigation context, meaning alert details, log excerpts, and entity history, is processed inside your network and does not leave it.
It is the same platform either way. What changes is where it runs and which model it calls.
Data residency
Data-residency requirements come in many forms: regulation that keeps certain data in-country, contracts that specify where processing may happen, internal policies that rule out particular sub-processors. They are hard to satisfy with a chain of cloud services, because every link, including the platform, the model provider, and the provider's own infrastructure, has to be accounted for.
On-prem with a local model shortens that chain to one link: your environment. That makes the residency answer simple to state and simple to audit. If your requirement is narrower, for example a limited list of approved sub-processors, a cloud deployment with a specific configured provider may be enough. That is a conversation to have with your compliance team, with our privacy policy and sub-processor list in hand.
Air-gapped networks
Fully disconnected environments are the strictest case, and worth being precise about. A locally hosted model removes the biggest external dependency, the model API. But an air-gapped SOC also has to plan for everything else that normally arrives over the internet:
- Threat intelligence. Enrichment against external intel needs an offline import path, and the intel is only as fresh as the last import.
- Platform and model updates. New versions of the platform, its detection logic, and the model itself have to come through your controlled transfer process.
- Data sources. Cloud-hosted sources such as SaaS identity providers or cloud workloads may not be reachable from an isolated network at all, which limits what that deployment can see.
None of these are blockers, but they belong in the deployment plan from day one rather than being discovered afterwards.
It is also worth agreeing on the security model of the transfer process itself. Anything carried across the gap, whether intel bundles, platform releases, or model weights, should be verified before it is imported, using the same controls you apply to any other software entering the network. An isolated SOC is only as isolated as its weakest import path. The cadence matters as well: a weekly intel import is a very different security posture from a quarterly one, and the right answer depends on how quickly your threat picture changes.
The tradeoffs, honestly
Running the model yourself buys control. It also costs something.
- Model capability. The most capable frontier models are offered as cloud APIs. Locally hosted models are increasingly capable, but expect differences on the hardest cases, and evaluate on your own incidents rather than on anyone's marketing, including ours.
- Hardware. Inference needs GPU capacity sized to your investigation volume and chat usage. Because SiemCore removes around 99% of events before the model is involved, the model only handles what remains, so sizing tracks findings rather than raw event volume.
- Operations. Your team runs the model infrastructure: capacity, monitoring, patching, and upgrades. Budget the time for it.
- Update cadence. Cloud deployments pick up improvements as they ship. On-prem upgrades happen on your change-management schedule.
A practical test: run a set of your own historical incidents through the local model and compare its verdicts and write-ups with what your analysts concluded at the time. That will tell you more than any benchmark.
Sizing questions to answer up front
Most on-prem projects that run long do so because sizing was guessed rather than measured. Before the hardware order, get answers to these:
- How many environments? One organization, several business units, or many customer tenants, each with its own baseline.
- How many findings per day after noise removal? This, not raw event volume, drives model load. Your current SIEM alert volume is a reasonable upper bound to start from.
- How heavily will chat be used? Interactive questions from analysts and customers add load at business hours, not evenly across the day.
- What availability do you need? If the SOC must keep investigating during a hardware failure, plan redundant inference capacity.
- How long must investigation records be kept? Retention requirements drive storage for verdicts, evidence, and reports.
Hybrid patterns
On-prem and cloud are not either-or across an organization. A common pattern for enterprises is cloud for most business units and on-prem for a regulated subsidiary or a sensitive network segment. For MSSPs, it is cloud for the bulk of customers and on-prem for the handful in banking, healthcare, or the public sector whose contracts require it. In both cases, analysts work in one platform and tenants stay isolated from one another, wherever each one runs.
What stays the same
Most of what makes an AI-run SOC work does not depend on where it runs. The per-tenant baseline, noise elimination, the evidence chain behind every verdict, and human approval on escalations all work the same on-prem. So does tenant isolation, which matters for MSSPs with regulated customers: a provider can run most customers in the cloud and deploy on-prem for the ones whose data cannot leave the building, on the same platform. Installing on-prem follows your own infrastructure timelines, but once the platform is in place, connecting a new environment is still a matter of hours, not weeks.
Making the call
If a regulation or contract rules out third-party processing, on-prem with a local model is the direct answer. If your constraint is a list of approved providers, a cloud deployment configured to match may be enough. If you are air-gapped, plan the intel and update paths alongside the hardware.
Regulated does not have to mean manual. Our security page covers how deployments are secured in either model, the privacy policy lists the cloud model providers, and we are happy to go through your specific requirements.
See mysoc.ai in action
One AI-run platform for your entire SOC—triage, investigation, customer communication, and reporting.