Solutions / 01
AI-Ready SOC
A security operations architecture where AI assists triage and enrichment, high-risk actions stop at a human, and every step is auditable.
The problem
Most proposals to put AI into a SOC begin at the wrong end. They add a model to a triage queue whose underlying data is unnormalised, whose detection content is unversioned, and whose alert volume is a symptom of missing aggregation rather than missing intelligence. The model then produces confident summaries of low-quality inputs, which is worse than no summary at all.
The second failure is subtler. An assistant that can act — close an alert, isolate a host, query a system — inherits the analyst's authority without the analyst's accountability. If its actions are not distinguishable in the audit trail, the SOC has quietly lost the ability to reconstruct its own decisions.
Architecture
What the system looks like.
TELEMETRY
Sources, pipelines, lineage
SIEM
Platform and storage
DETECTION
Detection-as-code, risk-based
ENRICHMENT
Asset, identity, threat context
AI ASSISTANCE
Triage and summarisation
HUMAN VALIDATION
Named approval, recorded
AUTOMATION
Authorised response only
The architecture is layered so that each layer can be built, tested and reasoned about independently. Telemetry is engineered before it is analysed. Detection runs as versioned content. Enrichment and AI assistance sit above detection rather than replacing it. Automation executes only what a policy — and where required, a person — has authorised.
- Telemetry layer
- Sources, pipelines, normalisation and lineage. Fidelity limits are recorded here so downstream layers cannot silently assume more than the data supports.
- Detection layer
- Detection-as-code: content in version control, with tests, review and a deployment pipeline. Risk-based aggregation turns individual signals into something worth attention.
- Enrichment & AI assistance
- Context assembly, correlation and summarisation. The assistant's inputs and outputs are logged as events, so its contribution to a decision is reconstructable.
- Human validation gate
- An explicit boundary. Actions above a defined impact threshold stop here and require a named person to approve, with that approval recorded against the action.
- Automation layer
- Executes authorised response. Every automated action emits its own telemetry, including what authorised it.
- Observability
- Surrounds the whole architecture: is the pipeline healthy, is detection content still matching, is the assistant behaving as it did last month.
Capabilities
- Telemetry architecture with recorded fidelity and lineage
- Detection-as-code with tests and a deployment pipeline
- Risk-based alerting and signal aggregation
- Context enrichment from asset, identity and threat sources
- AI-assisted triage and investigation summarisation
- Human validation gates on high-impact actions
- Response automation with full action provenance
- SOC observability — platform, pipeline and content health
Security controls
- AI assistance operates on read paths by default; write paths require explicit authorisation
- Every AI input and output is logged as a security event
- Actions are attributed to the identity that authorised them, human or service
- Impact thresholds are configured and reviewed, not implicit in the model's confidence
- Prompt and context assembly is treated as untrusted-content handling
- Detection content changes follow the same review path as any other production code
Integration approach
The architecture is intended to be adopted incrementally into an existing SOC, in the order the dependencies require: data first, then detection engineering, then aggregation, and only then assistance and automation. Each stage delivers value on its own, which matters because the later stages are the ones that fail loudly when the earlier ones were skipped.
- Engineer the telemetry: inventory, schema, normalisation, quality gates, lineage.
- Move detection content into version control with tests and a deployment pipeline.
- Introduce risk-based aggregation so alert volume reflects design rather than triage load.
- Add enrichment and context assembly as a service the SOC can call and inspect.
- Introduce AI assistance on read paths, logged end to end.
- Define impact thresholds and validation gates, then automate below them.
Expected outcomes
- Alert volume shaped by aggregation design rather than by triage capacity
- Detection content that can be tested and rolled back
- Investigation context assembled once, not re-derived per analyst
- AI contribution that is visible and attributable in the audit trail
- Automation limited to what a policy actually authorised
Limitations
AI assistance in a SOC remains an active research area, including at KOR IT. The failure mode that concerns us most is silent degradation: an assistant whose summaries remain fluent while its underlying inputs decay. The architecture above is designed so that this is detectable, not so that it is impossible.