On 7 July 2026 the European Commission published its Action Plan on Cybersecurity and Artificial Intelligence, formally COM(2026) 577 final. Most of the coverage has compressed it into a single line: Europe wants to use AI against cyberattacks. That is not wrong, but it misses what the document actually does. It sets out how Europe intends to reorganise the evaluation of advanced models, access to AI capabilities with offensive potential, testing in controlled environments, vulnerability management, the security of open source software, and the training of the people who will have to run all of it.
Worth being clear about what it is not. The Action Plan is not a law, a regulation or a directive. It is a Commission Communication: a policy instrument that sets priorities, owners and actions. No organisation will be fined for failing to comply with the plan. Binding obligations continue to come from the AI Act, NIS2, DORA, the Cyber Resilience Act, the GDPR and whatever sectoral rules apply.
Its significance lies elsewhere. The plan sets out how the Commission, the AI Office, ENISA, the Joint Research Centre and the European Cybersecurity Competence Centre intend to apply that framework against a specific operational hypothesis: that the most advanced models will compress the full attack cycle — reconnaissance, vulnerability discovery, exploitation, lateral movement and exfiltration — into a tempo that current decision-making structures cannot match.
If you take one thing from it, take this. The plan does not require anyone to buy AI tooling. It requires a rethink of the operating model. Priority shifts from finding more issues to verifying, deciding and remediating faster; from testing models in production to evaluating them in controlled environments; and from trusting an AI supplier to requiring that supplier to demonstrate capabilities, limits, continuity, traceability and human control.
Why the legal nature of the plan is worth getting right
The EU runs on instruments with very different effects. A regulation, such as the AI Act or DORA, applies directly. A directive, such as NIS2, obliges member states to achieve certain outcomes through national transposition. A Commission Communication expresses a strategy, interprets priorities and announces actions, but imposes nothing equivalent to a regulation on its own. The Action Plan sits in that third category.
Getting this right avoids two opposite mistakes, and both are being made at the moment. The first is presenting it as a new rulebook and manufacturing a compliance urgency that does not exist. The second, more expensive over time, is dismissing it as a document without consequences: the plan determines where European capabilities, guidance, evaluations, funding and coordination will concentrate, and it reveals which practices the Commission considers necessary to properly apply obligations that genuinely are binding.
Read sensibly, it is execution policy wrapped around a core of law already in force — a bridge between the AI Act and day-to-day security operations. The pieces sit as follows:
- Action Plan COM(2026) 577. Policy and coordination. Nine European actions with named owners and, in most cases, deadlines.
- AI Act, Regulation (EU) 2024/1689. Directly applicable. Requirements for AI systems and for general-purpose models, including the systemic risk regime.
- NIS2, Directive (EU) 2022/2555. Applies through national transposition. Risk, incident, vulnerability and supply chain management for essential and important entities.
- DORA, Regulation (EU) 2022/2554. Directly applicable in financial services. Operational resilience, testing, incidents and ICT third parties.
- Cyber Resilience Act, Regulation (EU) 2024/2847. Directly applicable to products with digital elements. Security by design and vulnerability handling across the product's life.
- Cyber Solidarity Act. European operational capacity for preparedness, detection and support during significant or large-scale incidents.
The plan should be read alongside the official Commission text, not as a substitute for any of those instruments.
Frontier AI, high-risk systems and systemic-risk GPAI are three different things
The vocabulary needs care, because the coverage has been using these terms interchangeably and they are not. The plan uses frontier AI to describe the most advanced models available or in development, capable of performing a wide range of tasks and of approaching, matching or exceeding the state of the art. It borrows that working definition from the proposed Cloud and AI Development Act.
It is not a standalone legal category under the AI Act, which works with three others:
- High-risk AI system. A classification tied to use and context: certain systems in biometrics, employment, education, critical infrastructure or regulated products.
- General-purpose AI model (GPAI). A model capable of competently performing a wide range of tasks and of being integrated into numerous systems.
- GPAI with systemic risk. A general-purpose model with high-impact capabilities, or designated as such by the Commission on the basis of its capabilities and foreseeable effects.
The distinction has practical consequences. A model can be technically at the frontier without that label alone determining its legal regime. Conversely, an enterprise application can be high-risk because of its purpose even when it runs on a model nowhere near the technological frontier.
Commission guidance uses an indicative threshold of 10²³ training floating-point operations to identify certain general-purpose models generating text, image or video. The AI Act presumes systemic risk above 10²⁵ operations, although that threshold is subject to review and the Commission may designate a model on capability grounds without it, per its own GPAI obligations documentation.
For providers of systemic-risk GPAI, Article 55 of the AI Act requires, among other things, evaluating the model using standardised protocols and tools including adversarial testing, identifying and mitigating systemic risks, recording and reporting serious incidents, ensuring an adequate level of cybersecurity for the model and its infrastructure, and retaining evidence that allows AI Office oversight.
GPAI obligations began to apply on 2 August 2025. From 2 August 2026 the Commission has signalled full application and the availability of its enforcement powers, with fines for GPAI providers of up to 3% of annual worldwide turnover. Models placed on the market before 2 August 2025 generally have until 2 August 2027 to comply, according to the Commission's governance framework.
Working out whether an organisation is acting as a provider, an integrator or simply a deployer is not settled by reading the model contract. What matters is who develops it, who substantially modifies it, under whose name it is marketed and how it reaches the market. Minor fine-tuning does not automatically make a company a GPAI provider, but substantial modification or own-brand marketing may well change the analysis.
Why the Commission thinks the current defensive model falls short
The plan starts from a specific asymmetry: AI can accelerate vulnerability discovery and exploitation faster than an organisation can verify, approve and deploy the fix. This is not a hunch, it is an observation about the rate at which capabilities are improving.
In February 2026 the UK's AI Security Institute estimated that the time horizon of cyber tasks models could complete with 80% reliability had been doubling roughly every 4.7 months since reasoning models emerged in late 2024. The number matters less than its trajectory: the institute's own previous estimate, from November 2025, put that period at around 8 months. The measurement accelerated between one revision and the next, and later models have exceeded even that trend, according to the institute's published analysis. AISI is careful to note that the metric is imperfect and not a linear forecast. It does, however, explain why the Commission is not waiting for these capabilities to become widespread.
ENISA published its report Cybersecurity in the Frontier AI Era on the same day. Its analysis is considerably less comfortable than the institutional summary and rewards reading in full. It identifies seven structural problems.
The speed asymmetry and the authority gap
The barrier is no longer purely technical. Even when an organisation correctly identifies a risk, its change boards, service owners and maintenance windows may need days to authorise an intervention. An automated attacker is subject to none of that.
ENISA calls this the authority gap: the inability to approve a defensive action within the time available. Technical capability is not what is missing — enforceable authority within the window is. Organisations will have to decide when an automated fix carries less risk than leaving an exposure open with a high probability of exploitation. That is not the same as enabling indiscriminate auto-patching. It means defining in advance which assets, changes and conditions permit an automated decision, which require human validation, and how a faulty intervention gets rolled back.
The collapsing economics of discovery
Finding vulnerabilities is getting cheaper. Scarce value moves to validation, prioritisation and remediation.
ENISA cites a case shared by industry: an organisation went from roughly 80 CVEs in the first quarter of 2025 to around 500 in the same quarter of 2026 and, once frontier AI tooling was introduced, began receiving in the region of 500 findings per day. That does not mean all of them were exploitable, nor that every organisation will see that volume. What it demonstrates is that a process designed for hundreds of reports a year collapses when the marginal cost of producing a finding approaches zero. CERT-EU has developed the same argument in its analysis of how AI is changing the economics of vulnerability discovery.
Technical debt as a first-order risk
AI makes it easier to analyse old code, reconstruct logic and locate combinations of weaknesses. Legacy and end-of-support systems therefore accumulate exposure to a form of analysis that used to be expensive and no longer is.
The answer cannot be to patch faster when the vendor has stopped issuing patches. Segmentation, hardening, isolation, enhanced monitoring, compensating controls and planned retirement all become part of the same strategy.
The verification bottleneck
An AI-generated patch is not a reliable fix by definition. It has to compile, pass tests, preserve functionality, avoid introducing new vulnerabilities and work in real configurations.
The paradox is that the same AI accelerating discovery can shift the bottleneck onto human validation. It also forces a rethink of a very common practice: routinely dismissing low-severity findings. Several minor weaknesses can chain into a critical exploitation path that no isolated assessment will surface.
Weaponising N-day vulnerabilities
Publishing a patch informs the defender, but it also hands the attacker the material needed to diff versions, analyse the changes and reconstruct the vulnerability that was fixed.
The consequence is worth internalising: the exposure window does not close when the vendor ships the update. It closes when the organisation has deployed the fix or an effective compensating control across every affected asset and has verified that closure.
Saturated disclosure channels
Open source maintainers and disclosure platforms are already receiving large volumes of AI-generated or AI-assisted reports. Noise is not the only problem: if the quality of findings improves, the volume of genuine vulnerabilities may still exceed anyone's capacity to review them.
Coordinated disclosure policy will need to build in requirements for reproducibility, evidence, deduplication, prioritisation and submission limits. Without them, a channel designed to improve security starts behaving like a denial of service against the maintainer.
Attacks from inside the trust boundary
A compromised open source component, a signed but malicious update, or a tampered security tool can place an attacker inside the trust boundary without crossing any monitored perimeter.
The defensive model has to assume that a legitimate dependency may be the initial vector. That reinforces the case for internal telemetry, segmentation, least privilege, dependency inventory and behaviour-based detection rather than reliance on signatures and known indicators.
The nine actions: what Europe will actually do, and when
The plan does not stop at principles. It assigns nine actions with responsible bodies and, in most cases, deadlines. Grouped by pillar:
Safe use of advanced AI
- European model evaluation capacity, led by the Commission and the AI Office, planned for 2027. Independent evaluation of capabilities and mitigations with a cybersecurity focus.
- Blueprint for structured access to advanced AI, Commission and ENISA, Q4 2026. Criteria for authorised European organisations to access advanced cyber capabilities.
- Secure testing platform, ENISA and the Joint Research Centre, Q4 2026. Testing AI in cyber ranges and simulated environments without exposing live infrastructure.
- Guidance on threats and safe use of AI, ENISA and European bodies, from Q3 2026.
European cyber resilience
- Vulnerability management adapted to the AI era, Commission, member states, ENISA and industry, from Q3 2026. Evolution of the European vulnerability database, coordinated disclosure and prioritisation tooling.
- Critical Open Source Resilience Campaign, ENISA, Commission, communities and industry, with a pilot in Q4 2026.
Industrial capacity and skills
- Grand Challenge on AI-assisted remediation, Commission, European Cybersecurity Competence Centre and ENISA, Q4 2026.
- Access to AI Factories capacity, Commission and member states, no fixed date.
- Training for cybersecurity professionals, Commission, member states and industry, Q4 2026.
The Commission has also identified around €200 million already earmarked in Horizon Europe and Digital Europe for advanced AI cybersecurity technologies before the end of the current multiannual financial framework, per the official announcement. Useful for calibrating expectations: this is meaningful funding for European research and capability building, not a pot organisations will draw on to buy tooling.
Evaluation, access and testing are three separate activities
The first pillar separates three functions that many organisations treat as one, with predictable consequences when an auditor turns up.
Model evaluation answers what capabilities and systemic risks a model has and whether its mitigations work. It is carried out by the provider, independent evaluators and the AI Office, and produces a report on capability, risk and mitigation.
Operational testing answers whether that model is fit for a specific detection, triage, threat intelligence or response use case without creating unacceptable risk. It is carried out by the user and, in the European framework, by ENISA, the JRC and the cyber range operator. It produces evidence of suitability and limits in a realistic environment.
Conformity assessment answers whether a high-risk system meets the applicable legal requirements before being placed on the market or put into service. It is carried out by the provider and, where relevant, a notified body, and produces a declaration or certificate.
The European evaluation capacity announced for 2027 will not be a conformity assessment body. Its role will be to support independent evaluation of advanced models, generate early risk signals and provide technical capacity to the AI Office. Conflating the two leads to two expensive errors: treating a security report as legal conformity, or treating a regulatory marking as a guarantee of operational resistance to attack.
The European Blueprint for structured access
The most advanced providers can restrict access to sensitive cyber capabilities through private programmes. The plan accepts that such decisions may be justified on security grounds, while noting that the criteria are often opaque and rest with non-European companies.
The Blueprint planned for Q4 2026 will need to define which types of organisation can request access — authorities, critical infrastructure, security providers and researchers — how the requester's identity and legitimacy are verified, what security conditions reduce the risk of abuse, how knowledge is shared between authorised organisations, how planned access programmes are notified, and what contingency applies if a provider or a third country restricts or withdraws access.
It will impose no new obligations on providers: it is a voluntary reference and a basis for international cooperation. But it raises a continuity question worth writing into contracts now, namely what happens to defensive capability if the model becomes unavailable. A tool embedded in the SOC or in the remediation process cannot have waiting for the API to come back as its only continuity plan.
The ENISA and JRC testing platform
The platform planned for late 2026 will allow models to be tested on use cases such as vulnerability analysis, remediation and incident response. The design described by the Commission carries limitations that usefully bound its scope: participants will use their own model access credentials and bear their own costs, testing will follow shared security and confidentiality rules, each participant retains responsibility for its methods, ENISA and the JRC will govern access and aggregate results, and existing cyber ranges will be reused rather than duplicated.
There is no intention to certify models or assess AI Act conformity. The intention is to find out whether a capability works safely under realistic conditions.
For an individual organisation, the minimum equivalent is an environment in which you can measure detection rate and false positives, incorrect or out-of-scope actions, resistance to prompt injection, data poisoning and tool manipulation, sources used and confidence levels, traceability of every recommendation, rollback capability, behaviour when data is incomplete, provider dependency and safe degradation, plus consumption, latency and cost per incident.
If an agent can isolate endpoints, revoke credentials or modify rules, that list is not enough. An AI agent and MCP security audit also needs to examine identity, per-tool authorisation, transaction limits, secrets, memory, logging and the separation between trusted instructions and untrusted content.
Vulnerability management stops being a process and becomes a decision system
The second pillar is the one that matters most to the majority of organisations. The Commission is not claiming there is a shortage of scanners. It is claiming the problem is converting a growing volume of findings into fixes that actually reach production.
The shift is clearest phase by phase, comparing the traditional model against what this scenario demands.
- Discovery. From periodic scans to continuous coverage of assets and dependencies. Minimum evidence is an inventory with an SBOM and a real measure of coverage.
- Validation. From manual review in arrival order to deduplication, reproduction and assisted validation, with technical evidence and an explicit validation state.
- Prioritisation. From CVSS in isolation to a combination of real exposure, known exploited vulnerability catalogues, exploitation probability, VEX data, asset criticality and existing controls. Every priority needs a reason and an owner.
- Decision. From a generic change board to authority predefined by risk level and asset type, with an authorisation and exception matrix.
- Remediation. From a standard patch window to a range that includes patching, mitigation, isolation or retirement, always with an approved and traceable change.
- Verification. From closing the ticket on deployment to rescanning, testing and monitoring, with evidence of effective closure.
- Learning. From a quarterly report to metrics that adjust the rules, with trends, failures and resulting actions.
Databases, coordinated disclosure and the CRA platform
The plan calls for adapting the European vulnerability database and the future single reporting platform under the Cyber Resilience Act to a higher volume of AI-assisted discoveries. It also proposes reviewing national coordinated disclosure policies and checking whether the underlying ISO/IEC standards remain adequate.
This is not an administrative footnote. If different databases describe the same defect with incompatible data, automation multiplies errors instead of reducing them. Prioritising at machine speed requires stable identifiers, product and version relationships, exploitability, mitigations and patch states that machines can process.
VEX takes on a role here that tends to be underestimated. An SBOM tells you a component is present; VEX lets you express whether a specific vulnerability actually affects the product in that context. Without that layer, a complete inventory produces an unmanageable volume of false positives, and the team ends up ignoring the tool it has just deployed.
The critical open source campaign
The Commission and ENISA want to map open source components critical to essential infrastructure and launch a first resilience campaign in late 2026. The proposed model goes beyond funding audits: it envisages identifying components whose criticality justifies intervention, matching projects with public or private sponsors, providing specialists, tooling or models to maintainers, drawing on trusted providers from the EU Cybersecurity Reserve, creating a catalogue of AI services for analysis, patching and remediation, and feeding results into the future European open source maintenance instrument.
The idea addresses a well-known market failure: a component maintained by two or three people in their spare time can underpin services of enormous value without anyone who depends on it funding its security proportionately.
No organisation should wait for Europe to publish that map. Four questions get you started: which open source components run critical functions, which versions are out of support or depend on a single maintainer, how long it takes to establish whether a new CVE affects production, and whether there is any real capacity to replace, isolate or internally maintain the component. A vulnerability management programme should answer those with assets, owners and evidence rather than a severity dashboard.
Technological sovereignty, industrial capacity and skills
The third pillar is the most strategic and the least immediate. The Commission acknowledges that the AI capabilities with the greatest cyber potential are concentrated in non-European providers, and that access may depend on private decisions or on third countries.
The Grand Challenge on assisted remediation
The Commission, with the European Cybersecurity Competence Centre and ENISA, will launch a challenge in late 2026 to develop a solution supporting the entire remediation cycle rather than discovery alone.
The emphasis is deliberate and correct. Europe does not need another demonstration that a model can find flaws; that problem is solved. It needs systems that can validate the vulnerability, understand the asset's context, propose a fix or mitigation, generate tests, estimate operational impact, support deployment and verify that risk has genuinely been reduced.
AI Factories and sovereign compute
The plan proposes opening access to the AI Factories for testing, training and deploying models applied to cyber resilience. Sovereignty does not mean every organisation should train its own model; it means avoiding a situation where critical capabilities depend exclusively on infrastructure, data and access conditions outside European control.
For an individual organisation the question is less geopolitical than contractual: provider, region, portability, continuity, keys, logs, sub-processors and genuine capacity to switch.
Skills and new competencies
The Commission will use the Cybersecurity Skills Academy to build modules on AI applied to cybersecurity, and ENISA will update the European Cybersecurity Skills Framework.
Teaching people to write prompts will not cover it. These roles will need to handle model evaluation and the limits of benchmarks, agent and tool security, data provenance and poisoning, the design of human-gated controls, threat modelling of AI systems, adversarial testing, regulatory evidence, and continuity under model dependency.
The serious risk is not that AI replaces the analyst. It is that the analyst ends up carrying responsibility for an action they can neither explain nor reconstruct.
How the plan fits with the AI Act, NIS2, DORA and the CRA
The plan does not create a fifth independent framework. It tries to make the four existing ones produce one coherent response instead of four parallel ones.
AI Act: securing the model and the system
For systemic-risk GPAI, the focus is capability evaluation, misuse risk, incident reporting and the cybersecurity of the model and its infrastructure. For high-risk systems, the framework covers risk management, data governance, technical documentation, logging, information for deployers, human oversight, accuracy, robustness and cybersecurity.
The timeline needs care. On 29 June 2026 the Council gave final approval to the Digital Omnibus on AI, moving the application of high-risk rules to 2 December 2027 for standalone Annex III systems and 2 August 2028 for systems embedded in regulated products, per the Council's statement. That deferral removes none of the GPAI obligations already in force, and it does not make waiting a sensible strategy: the dates moved because harmonised technical standards and designated national authorities were missing, not because the risk went away.
NIS2: operational risk and the supply chain
NIS2 requires proportionate risk management measures for essential and important entities: incident handling, continuity, supply chain security, secure acquisition and development, vulnerability handling and disclosure, effectiveness assessment, cryptography, access control and authentication.
The directive is technology-neutral, so an AI-accelerated threat is simply a risk that has to be managed. What changes is the evidence of proportionality: a patching service level that was defensible two years ago may not survive scrutiny if exploitation now happens within hours.
It also imposes staged reporting, with an early warning within 24 hours and notification within 72 hours for significant incidents. ENISA notes that response flows will have to retain human review while operating fast enough to meet those deadlines even as volume rises.
DORA: resilience and ICT third parties in financial services
DORA requires governing ICT risk, classifying critical functions, managing incidents, testing resilience and controlling providers. Where a financial entity introduces a model into fraud detection, the SOC, development or customer service, it has to assess simultaneously the criticality of the service, the data and secrets reachable, concentration and subcontracting, continuity if the model is withdrawn or fails, information location and processing, auditability, testing and reversibility, and the impact on the ICT third-party register.
Procuring an AI tool does not transfer resilience responsibility to the supplier. That is probably the sentence that will need repeating most often over the next two years.
Cyber Resilience Act: security across the product's life
The CRA becomes fully applicable on 11 December 2027 and requires manufacturers of products with digital elements to handle vulnerabilities and security throughout the product's life.
The plan connects the CRA to the new economics of discovery: a manufacturer will have to absorb more findings, determine whether they apply, fix them, distribute updates and actively report actively exploited vulnerabilities and serious incidents. SBOM, VEX, security by design and coordinated disclosure processes stop being optional extras.
One piece of evidence, several frameworks
The efficient response is not four compliance folders but reusable evidence. Eight items serve all four frameworks, with caveats: the inventory of models, systems and purpose; the register of assets and dependencies; risk and threat assessment; logs and decision traceability; testing and its results; the record of providers, sub-providers and exit arrangements; incidents and their notification criteria; and remediation with verified closure.
What differs is the purpose, scope and authority that will review each one. Reuse does not mean copy without context: the same technical evidence can serve an ISO 27001 auditor and a financial supervisor, but not with the same narrative or the same level of detail.
What the plan means depending on the role you play
GPAI provider. Must establish whether the model meets the general-purpose definition, whether systemic risk applies, what documentation to supply to integrators and authorities, and how it handles copyright, incidents, evaluation and cybersecurity.
Developer or integrator. Needs sufficient information about the base model's capabilities, limits, data and integration conditions, and must document its own layer: system instructions, retrieval, tools, permissions, memory, filters, monitoring and intended use. Base model documentation is not documentation of your system.
Deploying organisation. Even without being the model provider, it must govern purpose, data, users, oversight, suppliers, incidents and controls. Where the system affects individuals or material decisions, GDPR, fundamental rights and employment or sectoral rules come into play as well.
NIS2 or DORA entity. Must fold both AI-accelerated attacks and failures of its own AI tooling into the operational risk framework, with playbooks that coordinate security, continuity, legal, communications and notification.
Manufacturer under the CRA. Must build security and vulnerability handling into the product's life, maintain dependencies, and prepare disclosure channels capable of absorbing AI-assisted reports.
MSSP or SOC. Must show where AI intervenes, what data it processes, how it reduces false positives, which decisions it can execute unaided, what human review exists and how the service recovers if the model fails. A managed SOC should not present AI as a black box that prioritises alerts: it should be able to show use cases, metrics, limits, logs and escalation criteria.
The control architecture a CISO should insist on
Before authorising AI in security operations, insist on a minimum architecture across seven planes. This is not a statement of good intentions — every plane is auditable.
- Identity. Every user, agent, service and tool needs its own identity. No shared generic credentials, no keys with global permissions.
- Authorisation. The model may recommend an action, but authorisation must sit in a policy external to it. Tools must enforce least privilege and limits by operation, environment and asset.
- Data. Classify prompts, context, retrieved documents, telemetry, secrets and outputs, and define retention, training use, residency and provider access.
- Execution. Actions should be deterministic where possible, transactional, reversible and observable. An agent should not improvise privileged commands without a constrained interface.
- Verification. Material outputs must be checked against sources, policy and telemetry. For patches that means compilation, testing, analysis and staged rollout.
- Audit. It must be possible to reconstruct what information the model received, which version acted, which tools it used, what it proposed, who approved it and what resulted.
- Continuity. Operations must degrade safely if the model, the interface or the provider becomes unavailable, and critical data and playbooks must remain accessible.
Four decisions to settle before choosing any tool
The temptation with a document like this is to open a project and spread it across calendar phases. That is a common mistake: a calendar creates the sensation of progress while the hard decisions get deferred. Four are worth closing before evaluating any product, because everything else depends on them.
First: what the real perimeter is, not the declared one
Nobody governs what they have not inventoried. Find the models, copilots, agents, integrations and unsanctioned uses; assign each a technical and a business owner; and document purpose, users, data, tools, permissions and provider. In parallel, measure the starting exposure: asset coverage, outstanding backlog, mean time to detect and respond, and actual patching time, which rarely matches the committed figure.
The output is a register of AI systems signed off jointly by security, IT, legal and the business. Without that joint sign-off, the inventory is stale within three months.
Second: what legal role the organisation plays in each use case
Provider, integrator, importer, distributor or deployer. The answer can differ for every system, and it determines which obligations bite under the AI Act, NIS2, DORA, the CRA, the GDPR and sectoral rules. This is also where you decide which actions are permitted, which are prohibited and which require approval, and where you review contracts, sub-providers, training use, retention, portability and exit.
Third: where the limit of automated authority sits
This is the decision almost nobody takes explicitly, and the one that determines whether the organisation survives a fast-moving incident. Set out what a machine may decide unaided, what requires human approval and who carries the risk of not intervening. Also what evidence allows the decision to be reconstructed afterwards, what happens when the model gets it wrong, and how an emergency outside the change window is handled.
A mature design runs at three speeds: automatic for bounded, reversible, low-impact actions; human-gated for urgent decisions with sufficient evidence and pre-assigned authority; and collective for structural changes, risk acceptance and decisions with business impact. That design has to exist before the incident. During an intrusion moving at machine speed there is no time left to negotiate who may isolate a critical asset.
Fourth: what has to be tested before a use case is accepted
Before production, a use case should have faced direct and indirect prompt injection, manipulation of documents, data and tools, missing context and contradictory telemetry. Measure false positives and negatives, execute a full rollback, simulate loss of model access, and confirm that every decision can be reconstructed after the fact.
The deliverable here is not a working demonstration but a test report with limitations accepted in writing and explicit criteria for going into production.
What a supplier should be able to answer in writing
A credible supplier answers these in a document, not during a sales demonstration. Grouped by theme.
On the model. Which model and version is used; whether it can change without approval or notice; what security evaluations have been carried out; how cyber capability and misuse risk are measured; and what known limits it has.
On data. Whether prompts, files, telemetry or outputs are used for training; where they are processed and stored; what retention applies; which sub-providers are involved; and how data is deleted and exported.
On actions. Which tools the system can invoke; how each agent authenticates; where authorisation is enforced; whether limits exist by value, volume, asset or environment; and how an executed action is reversed.
On security. How prompt injection, data poisoning and exfiltration are mitigated; which logs are handed to the customer; how incidents and vulnerabilities are reported; whether an SBOM or dependency inventory exists; and what independent testing is permitted.
On continuity and compliance. What happens if model access is withdrawn; whether the model can be replaced without redesigning the integration; what service level covers availability and incident response; what documentation is provided for the AI Act, NIS2, DORA or the CRA; and who retains responsibility for the automated decision.
A vague answer on agent authentication, the authorisation enforcement point, logs provided, incident notification or continuity on model withdrawal is a risk signal, however impressive the product's performance.
Metrics that actually show whether AI is improving security
Counting alerts processed or documents summarised demonstrates nothing about risk. Useful metrics compare the process before and after, and nearly all of them are temporal.
- Time from publication or detection to validation; from validation to decision; and from decision to effective mitigation.
- Percentage of known exploited vulnerabilities still open beyond the committed deadline.
- Rate of revalidated closures, and percentage of AI actions that had to be reversed.
- False positives and negatives per use case, and human interventions per high-impact decision.
- Log coverage and traceability, and incidents caused or worsened by the automation itself.
- Recovery time on loss of the provider, and percentage of critical dependencies with an SBOM, VEX data and a named owner.
ENISA suggests orienting operations towards detection and response times measured in minutes for accelerated scenarios. That should not become a universal target divorced from context, but it works well as a stress test: if an attack chains identity, cloud and exfiltration inside an hour, which part of your defensive process still depends on a meeting the following day?
Our reading: the real change is about authority and evidence
The European plan is usually framed as a capability race between attackers and defenders. That reading is incomplete. The central problem will not be having a powerful model — everyone will have one, attackers included — but authorising fast decisions without losing control, and being able to demonstrate afterwards why they were the right ones.
Organisations already have automation. What many lack is an explicit model of authority. And automating a poorly governed process does not remove the delay: it relocates it and makes it less visible, which is worse, because it disappears from the indicators precisely when you most need to see it.
The organisation prepared for this scenario will not be the one that grants its agents the most autonomy, but the one that can demonstrate what it permits them to do, under what conditions, with what evidence, and how it takes back control when something goes wrong.
Conclusion
The European Action Plan announces no single technological fix. It acknowledges that the balance between attack and defence is shifting because AI lowers the cost of discovery, accelerates the chaining of vulnerabilities and renders obsolete decision processes designed for a different tempo.
Europe's answer is independent model evaluation, structured access to advanced capabilities, testing in controlled environments, modernised vulnerability management, open source support, sovereign compute and skills. It is a reasonable response, though its calendar — 2027 for the evaluation capacity — runs behind the pace the document itself describes.
For organisations the message is more concrete and more immediate: inventory, authority, verification, traceability and continuity. If you need to turn this framework into a technical and regulatory assessment of your own estate, you can review our work on EU AI Act compliance, NIS2, DORA and AI security, or put the specific case to us through the contact form.
Primary sources and documents analysed
- European Commission. Action Plan on Cybersecurity and Artificial Intelligence, COM(2026) 577 final
- European Commission. Announcement of the plan, 7 July 2026
- ENISA. Cybersecurity in the Frontier AI Era, July 2026
- European Commission. General-purpose AI obligations under the AI Act
- European Commission. AI Act governance and enforcement
- EUR-Lex. Regulation (EU) 2024/1689, AI Act
- Council of the EU. Final green light to the Digital Omnibus on AI, 29 June 2026
- CERT-EU. AI is changing the economics of vulnerability discovery
- AI Security Institute. How fast is autonomous AI cyber capability advancing?