EU AI Act for Cybersecurity: Why Your SOC AI Is Usually Not High-Risk — and Where the Real Exposure Lies

Your threat-detection model is almost certainly not high-risk. Neither is your SOC alert-triage engine, your phishing classifier, or your SIEM correlation rules — and that is the honest starting point most cybersecurity teams never hear. The EU AI Act (Regulation (EU) 2024/1689) is a product-safety-style regulation with a closed list of regulated uses, and defensive security tooling is not on it. The real exposure runs the other way: Article 15 makes cybersecurity a mandatory requirement of any high-risk AI your organisation builds. This page maps that line and the traps that pull a "security" system across it.

---

Defensive Security AI Is Mostly Not High-Risk — Lead With That

The opposite assumption is widespread and wastes budget. Threat detection, network and endpoint anomaly detection, SOC alert triage, phishing and email-security classification, vulnerability triage and SIEM correlation are not listed in Annex III, and they are not safety components of an Annex I product. That places them in the minimal-risk tier — no Article 9 risk management system, no Annex IV technical file, no conformity assessment.

The four risk tiers, applied to a security stack

The EU AI Act sorts systems into four tiers: prohibited practices (Article 5), high-risk (Article 6 and Annex III), limited-risk transparency (Article 50), and everything else — minimal risk. It is targeted, not a blanket rule: it does not regulate detecting malware, scoring an alert, or correlating logs, so a SOC platform that ingests telemetry and ranks incidents touches none of the regulated use cases. Minimal-risk means no Article 8 to 15 obligations attach today — no conformity file, no CE marking, no notified body — though Article 4 AI literacy still applies to any organisation putting AI into operation.

Why defensive tooling falls outside Annex III

Annex III enumerates eight categories: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice. Ordinary IT and security operations analytics appear in none. The drafters regulated AI that decides things about people — who gets hired, who gets credit, who gets policed — not AI that defends a network. Treating a malware classifier as a high-risk recruitment model is over-compliance the Act does not ask for.

---

Where Security AI Can Cross Into High-Risk: The Narrow Exceptions

There are real exceptions. They are narrow, and they turn on function, not on how important the protected asset is.

The 'safety component' test under Annex III point 2

Annex III point 2 covers AI used as a safety component in the management and operation of critical infrastructure — critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. A security AI can fall here, but only where its failure could endanger the health, safety or essential-service integrity of that infrastructure. The bar is the safety-component function, not the prestige of the asset. Draw the distinction sharply: a SOC defending a water utility's corporate IT is protecting an important company — generally not Annex III point 2. AI that manages the operational safety of the treatment process, commanding shutdowns or governing hazardous dosing thresholds, is a different proposition. The dedicated AI as a safety component in critical infrastructure (Annex III point 2) page derives those mechanics.

Borderline: autonomous response touching OT safety functions

The Article 6(1) and Annex I route — AI as a safety component of a CE-marked product needing third-party conformity assessment — is largely irrelevant to stand-alone SOC software, which is not embedded in such a product. The genuine grey zone is autonomous response that physically actuates an OT safety system, such as a SOAR playbook that can trip an industrial control loop: that warrants case-by-case assessment.

---

The Real Exposure: Article 15 Makes Cybersecurity a Requirement of Any High-Risk AI You Build

The Act bites your team most often not because security AI is regulated, but because Article 15 makes cybersecurity a mandatory design requirement of every high-risk AI system your organisation provides — including systems built by other teams in the business.

Accuracy, robustness and cybersecurity as one combined Article 15 duty

Article 15 bundles accuracy, robustness and cybersecurity into a single obligation for high-risk systems. So when the business builds an Annex III recruitment screener (Annex III point 4(a)) or a creditworthiness model (Annex III point 5(b)), the security and AppSec functions own a compliance duty even though no security product is in scope: they must harden, test and document its resilience. The Article 15 accuracy, robustness and cybersecurity requirements sit squarely on the CISO's desk.

Threats Article 15 names, and who owns the evidence

Article 15 is unusually specific. It requires high-risk systems to be resilient against attempts to alter their use, outputs or performance by exploiting vulnerabilities, and it names the threats: data poisoning, model poisoning, adversarial examples (evasion), and confidentiality attacks — the exact attack surface a security team is equipped to test, measure and mitigate. The conformity file must show those requirements were met, and the natural authors of that evidence are the people who ran the adversarial-robustness testing and poisoning-resistance evaluations. That makes the security org a first-class stakeholder in high-risk AI conformity, not a bystander who gets a ticket after the fact.

---

Adversarial Robustness and Prompt Injection for GPAI You Deploy

Most security teams will meet the Act through general-purpose AI embedded in their own tooling, not bespoke high-risk systems.

Prompt injection as an Article 15 robustness problem

Prompt injection, jailbreaks and indirect injection through retrieved content are live adversarial-robustness risks. Where the affected GPAI is part of a high-risk system, resilience against them maps directly onto the Article 15 robustness and cybersecurity duties; for everything else, they remain general security diligence. The prompt injection and adversarial robustness playbook treats this as an attack class, as Article 15 frames it.

Where deploying GPAI creates obligations

General-purpose AI models carry their own regime under Articles 51 to 55, with model-level duties distinct from the high-risk stack. Deploy GPAI inside a security copilot and you may inherit obligations through that regime, as well as through Article 15 where the copilot is part of a high-risk system; treat GPAI provider compliance as something to scope, not a solved checkbox. Separately, if a security product surfaces an AI chatbot or analyst assistant to users, Article 50 requires it to disclose AI interaction and mark synthetic output machine-readably — content-marking duties that land on 2 December 2026 under the Digital Omnibus, now adopted. See the Article 50 transparency obligations guide.

---

The Trap: Don't Deploy a Genuinely High-Risk System Under a 'Security' Label

The core warning for SOC and security leaders: a use case does not become exempt because it lives in the security org. The label does not change classification.

Biometric and behavioural 'security' systems that are really Annex III point 1

Biometric identification (Annex III point 1(a)) and biometric categorisation (Annex III point 1(b)) keep their classification whether the badge on the door says "physical security" or "access control". Real-time remote biometric identification and untargeted facial-recognition scraping carry their own Article 5 prohibitions a security framing does not rescue.

Insider-threat monitoring vs Article 5(1)(f)/(g) prohibitions

This is where security framing can accidentally cross a prohibited line. Article 5(1)(f) prohibits emotion recognition in the workplace — so an "insider-threat" tool that infers staff fatigue, stress or emotional state is banned outright, not merely high-risk. Article 5(1)(g) prohibits biometric categorisation that infers sensitive attributes. Both have applied since 2 February 2025, and employee monitoring used in HR-adjacent ways can also fall under Annex III point 4. Deploy a prohibited insider-threat tool under a security label and the fine is calculated against the top tier — €35 million or 7% of total worldwide annual turnover, whichever is higher, under Article 99(3) — not the operational-tooling tier you assumed.

---

Roles, Deadlines and Penalties for Security Teams

Most SOCs are deployers; some become providers.

Provider, deployer, importer, distributor and the Article 25 flip

A provider builds a system or places it on the market under its own name. A deployer operates a vendor's tool under its instructions — most SOCs, governed by Article 26; Article 23 sets importer duties and Article 24 distributor duties. Critically, Article 25 converts a deployer, importer or distributor into a provider on three triggers — rebranding under its own name or trademark, substantial modification, or repurposing to a high-risk use — pulling in the full provider stack under Article 16.

Key dates a security org tracks

Article 5 prohibitions and Article 4 literacy have applied since 2 February 2025, and GPAI obligations under Articles 51 to 55 since 2 August 2025. Stand-alone Annex III high-risk systems carry a statutory date of 2 August 2026, deferred to 2 December 2027 under the Digital Omnibus, now adopted — European Parliament 16 June 2026, Council 29 June 2026. Article 50 content-marking applies from 2 December 2026.

Penalty tiers and the SME proportionality cap

Article 99(3), 99(4) and 99(5) each apply the higher of the fixed sum or the percentage: €35 million or 7% (99(3)), €15 million or 3% (99(4)), and €7.5 million or 1% for supplying incorrect or misleading information (99(5)). Only Article 99(6) flips this to the lower of the two, and only for SMEs and start-ups — a large enterprise never gets that cap.

---

Security AI Classification Table

The table triages common security AI use cases. Read the classification column first: the majority resolve to minimal-risk. The rows that demand a second look are the employee-scoring, biometric and GPAI-copilot ones.

---

Worked Example: A Mid-Sized MDR/SOC Vendor Scopes Its Exposure

Consider Northgate Detect, a fictional 180-person EU-based managed detection and response (MDR) vendor running an AI-assisted SOC platform. At under 250 staff, the Article 99(6) SME proportionality cap could apply.

The portfolio triage in practice

Northgate triages in three buckets. Its anomaly-detection and alert-triage models are minimal-risk: no Annex III use case, no Annex I safety component. Its customer-facing AI analyst chatbot is transparency-only — an Article 50 disclosure, with synthetic output marked machine-readably. A planned UEBA module that would score a client's employees on a "risk" index is a stop-and-assess: it engages Annex III point 4 and risks the Article 5(1)(f) emotion-recognition prohibition outright, so Northgate parks it pending a fundamental-rights review.

When security work becomes a client's Article 15 evidence

Northgate is then engaged to harden a client's high-risk recruitment model. Its penetration testing and adversarial-robustness work becomes the client's Article 15 evidence, feeding a conformity file for a high-risk system it did not build. A final contract question: if Northgate rebrands a third-party detection engine under its own name, or repurposes a tool towards a high-risk use, Article 25 can convert it from deployer to provider — pulling in the full Article 16 stack, including the Article 9 risk management system and Annex IV documentation. It audits this before operationalising any white-label or repurposing change.

---

How Confir Helps Security and Compliance Teams

Security teams face a split picture: most of their AI is minimal-risk, a narrow set crosses into high-risk or prohibited territory, and the largest exposure is the inverse Article 15 duty on systems built elsewhere in the business. Confir's classification engine is deterministic and rule-based — no model inference, no hallucination — so the same inputs always yield the same documented finding. It walks each use case through the Annex III, Annex I and Article 5 tests in sequence and records a rationale a CISO or auditor can follow and challenge.

For the inverse Article 15 exposure, Confir structures the high-risk evidence pack — the Article 9 risk management system, the Article 11 and Annex IV technical documentation, and the accuracy, robustness and cybersecurity records under Article 15 — so a security team's hardening work lands where the conformity file needs it. It surfaces the role question (provider versus deployer, and the Article 25 flip) and tracks deadlines across the portfolio. The GPAI provider workflow (Articles 51 to 55) is partial and on the roadmap, presented as scoping support rather than a completed compliance claim.

---

Frequently asked questions

Is threat detection or anomaly detection AI high-risk under the EU AI Act? Generally no. Network, endpoint and behavioural anomaly detection, SIEM correlation and alert triage are not listed in Annex III and are not safety components of an Annex I product, so they sit in the minimal-risk tier with no mandatory high-risk obligations under Regulation (EU) 2024/1689. The exception is narrow: if such a system acts as a safety component in the management and operation of critical infrastructure under Annex III point 2 — where its failure could endanger safety — it can be high-risk. Defending an important company is not the same as managing infrastructure safety.

Why does Article 15 matter to a security team if our security AI isn't high-risk? Because Article 15 makes accuracy, robustness and cybersecurity a mandatory requirement of every high-risk AI system your organisation provides — even when no security product is in scope. The Act expressly requires resilience against attempts to alter a system's use, outputs or performance by exploiting vulnerabilities, including data poisoning, model poisoning, adversarial examples and confidentiality attacks. Your security and AppSec functions are the natural owners of that hardening, testing and documentation. In practice the Act reaches security teams more through this inverse duty than through regulating security tooling itself.

Can a SOC deploy an employee-monitoring or biometric system as long as it's framed as security? No. A use case does not change its classification because it sits in the security org. Biometric identification and categorisation fall under Annex III point 1, and worker monitoring can fall under Annex III point 4. More seriously, Article 5(1)(f) prohibits emotion recognition in the workplace and Article 5(1)(g) prohibits biometric categorisation inferring sensitive attributes — these are banned outright since 2 February 2025, not merely high-risk. An 'insider-threat' tool inferring staff stress or sensitive traits can breach these prohibitions, with fines up to €35 million or 7% of total worldwide annual turnover under Article 99(3).

How does prompt injection relate to EU AI Act obligations? Prompt injection, jailbreaks and indirect injection via retrieved content are adversarial-robustness risks. Where the affected GPAI is part of a high-risk AI system, resilience against them maps onto the Article 15 robustness and cybersecurity duties. For everything else they remain general security diligence. Separately, general-purpose AI models carry their own regime under Articles 51 to 55. If you deploy GPAI inside security tooling, scope both the Article 15 implications and any GPAI-level duties rather than assuming a single checkbox covers it.

Does my SOC become a 'provider' if we customise a third-party detection tool? Potentially. Most SOCs are deployers under Article 26 — operating a vendor's system per its instructions. But under Article 25 a deployer becomes a provider if it puts the system on the market under its own name or trademark, substantially modifies it, or changes its intended purpose to a high-risk use. That flip pulls in the full provider stack under Article 16. Managed detection and response vendors that rebrand an underlying engine, or repurpose a tool towards an Annex III use, should audit this before operationalising the change.

When do these obligations actually apply to security AI? Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025. GPAI obligations under Articles 51 to 55 have applied since 2 August 2025. Stand-alone high-risk Annex III systems carry a statutory date of 2 August 2026, deferred to 2 December 2027 under the Digital Omnibus, now adopted — European Parliament 16 June 2026, Council 29 June 2026. Article 50 content-marking duties apply from 2 December 2026.

What are the penalties, and is there relief for smaller security vendors? Penalties are tiered. Breaching the Article 5 prohibitions reaches €35 million or 7% of total worldwide annual turnover under Article 99(3); breaching high-risk obligations reaches €15 million or 3% under Article 99(4); supplying incorrect or misleading information reaches €7.5 million or 1% under Article 99(5). Each is the higher of the fixed sum or the percentage. Only Article 99(6) flips this to the lower of the two, and only for SMEs and start-ups (under 250 staff and turnover at or below €50 million, or balance sheet at or below €43 million). A large enterprise never gets that cap.

---

Related guides

• Article 15 accuracy, robustness and cybersecurity requirements
• prompt injection and adversarial robustness
• Article 50 transparency obligations
• limited-risk and minimal-risk classification
• AI as a safety component in critical infrastructure (Annex III point 2)