EU AI Act and Quantum Security: What Critical Infrastructure Operators Must Address Before December 2027

The EU AI Act's high-risk rules now apply from 2 December 2027. The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the date back from August 2026, days before it would have taken effect. From the new date, high-risk AI systems, including AI systems used to manage critical infrastructure, must comply with the Act's conformity assessment and documentation obligations. This article addresses one dimension of that compliance that most AI Act guidance does not discuss: the intersection with quantum security.

Before the jurisdictional note: this article applies to operators and providers of AI systems subject to EU law, EU-based operators, and organisations placing AI systems on the EU market or operating infrastructure within the EU. UK-only organisations are not subject to the EU AI Act. A dedicated section at the end of this article addresses what that means in practice for UK readers.

The December 2027 Deadline: What Changed and What Did Not

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. Its enforcement is phased. 2 February 2025 brought the prohibition of AI practices listed in Article 5, uses of AI that the Act bans outright, including certain biometric categorisation applications and social scoring systems. Obligations for general-purpose AI models followed on 2 August 2025, and the Act became generally applicable on 2 August 2026, when the AI Office's enforcement powers and the Article 50 transparency duties took effect. The high-risk rules were due to apply on the same day. The AI Omnibus, proposed by the Commission on 19 November 2025 and published in the Official Journal on 24 July 2026, moved them: Annex III systems to 2 December 2027, and AI embedded in products covered by Annex I to 2 August 2028. From those dates, providers and deployers of high-risk AI systems face conformity assessment obligations, documentation requirements, and the penalty framework.

High-risk AI systems are defined by Annex III of the Act. The list is specific. For critical infrastructure operators, the relevant category is Annex III, paragraph 2: AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating, or electricity. An AI system with a safety function in grid management, in the control of water supply, or in road traffic management is likely to fall in this category. The Omnibus tightened the safety component test: an AI function that only assists users or optimises performance is not caught unless its failure would endanger health or safety. Operators that classified their systems before July 2026 should check them again against the amended text.

Non-compliance with high-risk AI system obligations carries penalties of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. The penalty applies to non-compliance with the high-risk system requirements in Chapter III. The date also matters for systems already in service. Under Article 111(2), a high-risk system placed on the market before the application date falls under the rules only if its design later changes significantly. Operators that have not assessed their AI systems against the Annex III classification well before December 2027 will not know their own compliance position, or which upgrades would bring a system into scope.

Where Quantum Security Intersects with the AI Act

Article 15 of the EU AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. The Act does not specify cryptographic algorithms. It uses the phrase "state of the art" as the benchmark for technical robustness, a deliberately technology-neutral formulation. That phrase is consequential: it is the same standard used in GDPR Article 32 for data protection security measures and NIS2 Article 21 for network and information system security. Regulators and courts interpreting "state of the art" look to published technical standards as the benchmark for what that phrase requires at any given point in time. NIST FIPS 203, 204, and 205, published in August 2024, are now part of the published cryptographic state of the art. FIPS 206 (FN-DSA) is still to be finalised.

Article 15(5) specifies that high-risk AI systems must, to the extent possible, be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities. This encompasses the security of AI model serving infrastructure, inference APIs, training pipelines, and the cryptographic protection of AI-related data flows.

The connection to quantum security follows. An AI system at a critical infrastructure operator that is still protected by quantum-vulnerable cryptography, RSA or ECDH key exchange on data pipelines, ECDSA JWT tokens on inference APIs, RSA-encrypted model weights at rest, has a demonstrable gap between its current cryptographic posture and the emerging "state of the art" standard. The EU Cybersecurity Act (Regulation (EU) 2019/881) and ENISA's technical guidance increasingly reference NIST PQC standards as the baseline for cryptographic resilience. Regulators interpreting Article 15 post-2024 will have those standards available to them as a benchmark.

The relationship to quantum security is interpretive, not explicit. The Act does not say "implement ML-KEM." The correct framing is: Article 15's state-of-the-art robustness standard will be interpreted in light of the cryptographic standards that exist. ETSI TS 119 312 on cryptographic suites, and ENISA's guidance on PQC as part of the cybersecurity baseline, provide the standards context regulators will apply. For the algorithm transition timeline that underpins this, the NIST IR 8547 transition timeline covers the deprecation schedule in full.

The AI System Cryptographic Attack Surface

An AI system deployed at a critical infrastructure operator presents multiple cryptographic surfaces, each of which is potentially quantum-vulnerable. Working through them systematically is the starting point for any Article 15 compliance assessment:

Data pipelines. Training data sourced from HTTPS APIs, model weights transferred over TLS between training infrastructure and serving infrastructure, and inference results transmitted to operational systems are all typically protected by TLS with RSA or ECDSA certificates and ECDH key exchange. Quantum-vulnerable across all three flows.

Model storage. Model weights encrypted at rest under AES typically use an RSA-wrapped or ECDH-derived key management scheme. The AES-encrypted data is not directly quantum-vulnerable, but the key wrapping is.

API authentication. JWT tokens authenticating inference requests commonly use RSA or ECDSA signatures. An adversary running Shor's algorithm on a cryptographically relevant quantum computer (CRQC) could forge API authentication tokens.

Audit logs. Signed with ECDSA or RSA to ensure tamper evidence. The signature algorithm is the exposure point.

MLOps pipeline integrity. Code signing for model packages and pipeline scripts using ECDSA or RSA certificates.

The Harvest Now, Decrypt Later (HNDL) risk for AI systems is asymmetric and worth stating plainly. An adversary who captures encrypted model weights or proprietary training data today could potentially decrypt them after a CRQC exists. The central estimate for when a CRQC might emerge is 2033 to 2035. For critical infrastructure operators whose AI systems process operational data with multi-year retention periods or embody intellectual property with long commercial lifetimes, the confidentiality exposure begins accumulating now. The Mosca inequality framework, which quantifies the relationship between data sensitivity lifetime, migration time, and CRQC probability, provides the risk quantification tool. A system trained on ten years of sensitive operational data has a confidentiality window that extends well into the period when HNDL attacks become executable.

DORA and NIS2: The Overlapping Compliance Landscape

Many EU critical infrastructure operators are subject to multiple regulatory frameworks simultaneously. The EU AI Act is not the only instrument that creates quantum security compliance obligations, and understanding the overlap is part of compliance planning.

NIS2 (Directive 2022/2555) applies to operators of essential services across energy, transport, water, digital infrastructure, health, financial markets, and other critical sectors. Article 21 requires these operators to implement "state-of-the-art" cybersecurity measures, including encryption. The same "state of the art" standard applies. A critical infrastructure operator that is subject to both the EU AI Act and NIS2 faces consistent cryptographic expectations from both frameworks, and the convergence makes the PQC migration argument more robust, not more complex.

DORA (Regulation (EU) 2022/2554, Digital Operational Resilience Act) applies to EU financial entities and their ICT service providers. DORA's Article 9 on ICT protection and prevention, with Articles 6 and 7 of Delegated Regulation (EU) 2024/1774 on encryption and key management, sets equivalent expectations for cryptographic resilience. The detailed analysis of what DORA requires of financial sector operators on PQC migration is covered at DORA and post-quantum cryptography.

One note on DORA jurisdiction that matters here: DORA binds EU financial entities and their ICT service providers. A UK-only financial organisation is not subject to DORA. UK financial services firms should refer to FCA PS21/3 on building operational resilience and the PRA's cryptographic controls guidance.

For critical infrastructure operators at the intersection of all three frameworks, an EU energy utility with financial services subsidiaries operating AI systems across both, the compliance landscape requires a single coherent cryptographic programme rather than three parallel ones. The cryptographic state-of-the-art standard runs through all three.

Article Obligations: What the Act Actually Requires

Translating the Act's articles into specific quantum security actions requires working through four provisions.

Article 9, Risk management system. Providers of high-risk AI systems must establish and maintain a documented risk management system throughout the AI system's lifecycle. From a quantum security standpoint, this system should include: identification of the cryptographic controls protecting the AI system; assessment of HNDL risk for AI-system data with long confidentiality lifetimes; and a roadmap for upgrading cryptographic controls to post-quantum standards aligned with NIST FIPS 203, 204, and 205. The Article 9 documentation is the audit trail a regulator will examine. Absence of any engagement with quantum security risk in the risk management system will be a finding.

Article 15, Accuracy, robustness, and cybersecurity. The state-of-the-art cybersecurity standard. Documented engagement with the quantum security dimension of AI system cryptographic controls is the minimum defensible position. An operator that can show it has assessed its cryptographic surface, documented the gap against the emerging post-quantum standard, and produced a migration roadmap is in a materially different position from one that has not considered the issue.

Article 11 and Annex IV, Technical documentation. Providers must prepare technical documentation before placing a high-risk AI system on the market, and Annex IV requires it to describe the cybersecurity measures put in place. Including the quantum security posture of the AI system's cryptographic controls in that documentation is not explicitly required by the Act's text, but it is a defensible and prudent approach given the Article 15 robustness obligations. The Act sets no quantum-specific format, so check the harmonised standards and ENISA publications before finalising the documentation approach.

Article 26, Deployer obligations. Organisations that deploy high-risk AI systems in a professional context must ensure the system is used in accordance with the provider's instructions and must monitor its operation for anomalies. Where anomaly detection systems are themselves AI-based and meet the Annex III critical infrastructure classification, the deployer's monitoring obligation extends to the security of the monitoring system, including its cryptographic security.

Four Steps Before December 2027

Step 1: Classify AI systems against Annex III. Conduct an audit of all AI systems deployed across critical infrastructure against the Annex III criteria. The classification question for each system: does this AI system manage or operate components of critical infrastructure in the Annex III sector categories? If yes, apply the amended safety component test. A system that meets it is likely to be a high-risk AI system requiring compliance by 2 December 2027. Complete this audit early, because conformity work has to follow it.

Step 2: Conduct a cryptographic surface assessment for each Annex III classified system. Map the cryptographic controls across data-in-transit (TLS configuration, certificate key types), data-at-rest (storage encryption key management), API authentication (JWT key types and signature algorithms), audit log signing (algorithm and key size), and MLOps pipeline code signing. The NIST NCCoE SP 1800-38B CBOM methodology provides the framework for this work, scoped to the AI system's infrastructure.

Step 3: Include quantum security risk in the Article 9 risk management documentation. For systems handling long-lived sensitive data, operational telemetry with multi-year retention, proprietary model weights, AI training datasets built over years of operational history, document the HNDL risk explicitly and produce a roadmap for quantum-safe cryptographic controls. Operationally, this means documenting the gap between current RSA/ECDSA-based controls and the FIPS 203, 204, and 205 post-quantum standards, and producing a phased transition plan.

Step 4: Update the Article 11 technical documentation. Include the current quantum security posture of the AI system's cryptographic controls and the migration roadmap produced in Step 3. With no quantum-specific template in the Act, frame this section as evidence of Article 15 compliance engagement.

The December 2027 deadline requires the risk management system and technical documentation to be in place. It does not require the quantum migration to be complete. An operator that can demonstrate it has assessed the quantum risk, documented it appropriately, and produced a credible roadmap is in a defensible position under Articles 9 and 11 while the cryptographic migration is still underway. The operator that has done nothing, no assessment, no documentation, no roadmap, is the one in genuine difficulty when supervisory authorities begin enforcement.

UK Organisations: This Does Not Apply to You Directly

The EU AI Act is a regulation of the European Union. The UK left the EU before the Act was adopted and is not subject to it through membership.

A UK-based operator with no EU market presence and no infrastructure within the EU has no EU AI Act obligation. Full stop. The Act's territorial scope (Article 2) covers providers placing AI systems on the EU market and operators using AI systems within the EU. A UK-only operation with no EU customers, no EU-located infrastructure, and no EU-market AI products falls outside that scope.

UK operators that do have EU market presence, UK companies selling AI systems to EU customers, UK cloud infrastructure providers serving EU operators, UK financial services firms with EU-regulated entities, should assess their EU footprint against Article 2 specifically, not against this article's general framing.

For UK-only organisations, the applicable frameworks are different. The UK Government's pro-innovation AI regulation approach operates through sector-specific regulators: FCA for financial services AI, ICO for data protection, Ofcom for digital communications, CMA for competition. The NCSC's AI cyber security principles guidance covers the cybersecurity dimension of AI systems for UK operators. On the quantum security side, the NCSC's PQC migration timeline guidance (March 2025) and the UK National Quantum Strategy provide the relevant planning framework. The quantum security case for UK operators is strong and the timeline is substantively aligned with the EU frameworks, but the regulatory basis is different, and conflating EU and UK obligations would be inaccurate.