How AI Is Transforming Threat Detection in the SOC

The traditional SOC has reached its operational limit

Security operations centres (SOCs) have been built for more than a decade on the same pattern: a central SIEM, static correlation rules, L1 analysts who triage alerts, L2 who investigate, and L3 who hunt threats proactively. The structural problem is well known across the industry: security telemetry volume grows every year, the shortage of qualified analysts is chronic, and alert fatigue — the phenomenon whereby a disproportionate volume of alerts turns out to be noise — degrades both response time and team retention.

The ENISA Threat Landscape 2025 report, which analyses 4,875 cybersecurity incidents recorded between July 2024 and June 2025, further confirms that generative AI has been incorporated into every phase of the attack cycle: threat groups use commercial LLMs as well as manipulated or "jailbroken" models (WormGPT, FraudGPT and similar) to automate social engineering and speed up the development of malicious tools [1]. Phishing remains the leading intrusion vector (around 60% of the cases analysed), and exploitation of recently published vulnerabilities (21.3%) remains a common initial access route [1]. In other words: attackers already use AI systematically. A SOC that does not is starting from a structural disadvantage.

This article describes, with the caution that a regulatory landscape still under construction demands, where AI is delivering real value in the SOC, what reference architecture makes sense, what risks the use of these models itself introduces, and what the European and Spanish regulatory framework requires from 2026 onwards.

What actually changes with AI applied to the SOC

Two generations of technology are worth separating, as they tend to get blended together in commercial discourse:

1. Classic machine learning (supervised classifiers, unsupervised anomaly detection, UEBA): this has been in production in market-leading SIEM and EDR products for years, and its application to security is not new.
2. LLMs fine-tuned or applied to security, widely in production since 2023-2024: these add a natural-language layer on top of the systems above — summarising incidents, generating search queries and assisting the analyst in drafting hypotheses.

Neither replaces human judgement in decisions with production impact. What changes is where the bottleneck sits: less time spent classifying noise, more time spent investigating what genuinely matters.

1. Reducing false positives

Supervised classifiers trained on alerts already labelled by the SOC itself can significantly reduce the volume of alerts that reach a human analyst. The exact magnitude of that reduction depends entirely on the volume and quality of the available history, how well the model is tuned to the specific environment, and ongoing review by the team: there is no universal percentage applicable to any organisation, and any figure quoted to a client must be based on measurements from their own environment after deployment, never on generic market benchmarks.

2. Assisted threat hunting

Threat hunting has historically been a human activity, slow and dependent on the individual analyst's experience. Current approaches combine:

• Behaviour-based detection (UEBA) with unsupervised models that learn the normal pattern of an identity or an asset and flag deviations.
• Graph analytics over identity and network logs to detect lateral movement, a technique MITRE ATT&CK documents as TA0008 and that modern SIEM/XDR platforms model as relationship graphs between entities.
• Specialised LLMs that help translate an analyst's hypothesis ("are there signs of beaconing towards this domain?") into a technical query against the relevant data source, lowering the barrier to each tool's query language.

3. Multi-source correlation

A modern SOC integrates EDR, firewall, IAM and cloud provider logs, each with its own schema and query language. Using a common normalisation schema — the Open Cybersecurity Schema Framework (OCSF) or the Elastic Common Schema (ECS) — before applying any AI layer is a precondition, not an option: without normalisation, the model learns source-specific noise rather than attack patterns.

4. Assisted response (SOAR)

Automated response playbooks are evolving from static decision trees towards flows where a model proposes the next step based on the incident's context. The operational recommendation — aligned with the "human-in-the-loop" principle set out in the NIST AI RMF itself [8] — is that any action with an effect on production (isolating a host, revoking credentials, blocking traffic) should keep explicit human approval, except in predefined, low-risk containment scenarios agreed in advance with the client.

Recommended reference architecture

A sensible hybrid architecture combines deterministic layers and learning layers, with the human always in the decision loop:

1. Ingestion and normalisation: common schemas (OCSF, ECS) to stop the model depending on each source's particular syntax.
2. Deterministic detection layer: Sigma rules and traditional correlation, which remain the auditable, immediately explainable foundation of any SOC.
3. Machine learning layer: classifiers built for specific use cases (algorithmically generated domains/DGA, beaconing, phishing), trained and retrained on the client's own data.
4. LLM assistance layer: incident summarisation, query generation, report drafting — always as support, never as an autonomous decision-maker on containment actions.
5. Human validation layer: any action affecting production goes through an analyst, with traceability of who approved what and when — a requirement that the ENS also demands for ongoing security management [4].

On the myth of the "SOC without humans": no serious body recommends removing the analyst from the equation. Models carry biases, can hallucinate, and do not understand a specific organisation's business context. The analyst's role shifts from "alert classifier" to "AI system supervisor": validating decisions, correcting errors, feeding retraining and closing the continuous-improvement loop.

Risks introduced by the use of AI within the SOC itself

Adopting AI in the SOC is not neutral from a security standpoint: it adds a new attack surface that the SOC itself must monitor.

Data poisoning and model manipulation

If an attacker knows an organisation uses ML classifiers for triage, they may try to contaminate the training set by injecting patterns designed to pass unnoticed as "normal". MITRE ATLAS — the ATT&CK equivalent for artificial intelligence systems — documents these techniques in a structured way (data poisoning, model evasion, model extraction, prompt injection) and their associated mitigations [6]. Any ML deployment in the SOC should incorporate ATLAS into its threat modelling, exactly as ATT&CK is incorporated for conventional TTPs.

Data privacy and residency

Sending security logs — which frequently contain personal data or sensitive business information — to public, external LLM APIs poses a risk of exfiltration and regulatory non-compliance (GDPR, and for essential-service providers, ENS/NIS2 as well). Using models deployed on the organisation's own infrastructure, in a private cloud, or with providers offering guaranteed data residency within the EU, is the recommended default, particularly in regulated environments. For Hodeitek, this is consistent with hosting client data on OVHcloud, within European Union territory.

Explainability and traceability

Any automated decision that escalates to a blocking or containment action must be explainable and auditable after the fact. Black-box models with no ability to justify their output are not acceptable in environments subject to regulatory oversight: the ENS requires traceability of the security measures applied [4], and the NIST AI RMF itself lists explainability as one of the core characteristics of a trustworthy AI system [8].

The regulatory framework to bear in mind in 2026

AI Act — Regulation (EU) 2024/1689

Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 (the "AI Act") establishes a framework of obligations graded by the AI system's risk level (unacceptable, high, limited, minimal), with a staggered application timetable between 2024 and 2027 [2][3]. Not every AI system used in a SOC is automatically "high-risk": the risk classification depends on the intended purpose and the deployment context, assessed case by case according to whether the system falls within one of the categories in Annex III of the Regulation. Each organisation's specific obligations depend on whether it acts as a provider or as the party responsible for deployment (deployer) of each system — something that should be analysed with specific legal advice [2][3].

NIS2 and its transposition in Spain

Directive (EU) 2022/2555 (NIS2) was due to be transposed into Spanish law by 17 October 2024, with Spain being one of the Member States that missed this deadline [5]. Spain's transposing legislation has been processed as a draft/bill for the Cybersecurity Coordination and Governance Act (Ley de Coordinación y Gobernanza de la Ciberseguridad), and the European Commission maintains an open infringement procedure against Spain. At the time of this publication, the exact status of the bill's passage through the BOE could not be confirmed against a live official source; it can be checked at boe.es and in the congreso.es bill tracker. Until the law's definitive publication, the applicable reference framework in the Spanish public sector remains the National Security Framework (Esquema Nacional de Seguridad).

National Security Framework (ENS)

Royal Decree 311/2022 of 3 May, which regulates the ENS, remains in force and requires ongoing risk management, separation of responsibilities and traceability of the security measures applied, irrespective of the underlying technology [4]. Incorporating AI into the SOC does not exempt an organisation from these requirements: it reinforces them, because it adds an extra risk surface that must be documented and audited just like any other component of the information system.

DORA (financial entities)

For financial-sector clients subject to Regulation (EU) 2022/2554 (DORA), any external provider of AI-based detection and response services becomes an ICT third-party service provider subject to the Regulation's registration obligations, third-party risk management and, where applicable, the direct oversight framework for critical providers. The Regulatory Technical Standards (RTS) on incident classification (2024/1772) and ICT risk management tools (2024/1774) were adopted on 25 June 2024. The Implementing Technical Standards (ITS) on Register of Information templates (2024/2956) were adopted on 29 November 2024 and published in the Official Journal of the EU on 2 December 2024. The application details of these standards, and of future RTS/ITS, must be verified against the version in force as published by the European Supervisory Authorities (EBA, ESMA, EIOPA) at the time of each deployment [9].

Practical steps for incorporating AI into a SOC responsibly

1. Start with the data, not the model. Before evaluating any AI product, audit the quality, coverage and normalisation of the available log sources. A model trained on inconsistent data produces inconsistent decisions.
2. Keep a deterministic baseline. Signature-based correlation and detection rules (Sigma, YARA, known IOCs) do not disappear: they remain the explainable, auditable layer any ML layer rests on.
3. Define the boundary of autonomous decision-making. Document in writing which actions an AI system may execute without human approval (normally none with production impact) and which require explicit analyst validation.
4. Build MITRE ATLAS into threat modelling. The SOC's own AI pipeline is an asset that must be protected, not just a defence tool [6].
5. Assess the risk classification under the AI Act for each specific system, with legal advice, before committing to any contractual undertakings about how it operates [2][3].
6. Maintain data residency and control. Prioritise deployments on the organisation's own infrastructure or with providers offering guaranteed EU data residency, avoiding sending sensitive logs to public APIs without contractual control over their use.
7. Measure impact in the actual environment, not against market benchmarks. Any improvement in MTTD, MTTR or false-positive reduction must be measured before and after deployment in the specific organisation, with a documented methodology.
8. Review and retrain periodically and under audit. An unsupervised retraining pipeline is, in itself, a vector for manipulating the system.

Conclusion

AI does not replace the SOC: applied well, it makes it more efficient by reducing the noise reaching the analyst and speeding up investigation of what genuinely matters. But it introduces a risk surface of its own — model poisoning, data leakage, opaque decisions — that demands explicit governance, and its deployment in Spain and the EU must be read against a regulatory framework still in motion: the AI Act, with its staggered application timetable running to 2027; a NIS2 transposition law in Spain still pending publication in the BOE at the time of writing; and a National Security Framework that continues to require traceability and ongoing risk management regardless of the technology used. Any specific improvement figure — false-positive reduction, MTTD, MTTR — must be measured in the client's real environment, not cited as a generic benchmark.

Sources

1. ENISA Threat Landscape 2025 (octubre 2025) — https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
2. Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024 (Reglamento de IA), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=es
3. BOE — DOUE-L-2024-81079, Reglamento de Inteligencia Artificial — https://www.boe.es/buscar/doc.php?id=DOUE-L-2024-81079
4. Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad, BOE-A-2022-7191 — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
5. Directiva (UE) 2022/2555 (NIS2), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
6. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — https://atlas.mitre.org/ ; repositorio de referencia: https://github.com/mitre/advmlthreatmatrix
7. INCIBE — Inteligencia Artificial (IA) y ciberseguridad — https://www.incibe.es/ciudadania/tematicas/inteligencia-artificial
8. NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework
9. Reglamento (UE) 2022/2554 (DORA), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554

Sources

• Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024, por el que se establecen normas armonizadas en materia de inteligencia artificial — https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=es
• BOE — DOUE-L-2024-81079, Reglamento de Inteligencia Artificial — https://www.boe.es/buscar/doc.php?id=DOUE-L-2024-81079
• Directiva (UE) 2022/2555 (NIS2), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191 — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
• ENISA Threat Landscape 2025 (octubre 2025) — https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
• MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — https://atlas.mitre.org/ y repositorio https://github.com/mitre/advmlthreatmatrix
• INCIBE — Inteligencia Artificial (IA) y ciberseguridad — https://www.incibe.es/ciudadania/tematicas/inteligencia-artificial
• NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework