Organisations adopting advanced AI for cybersecurity face a difficult question: how can they use it to strengthen defences without introducing new cyber risks? The EU links cybersecurity to AI oversight by bringing model evaluation, AI Act supervision, secure testing and cyber resilience into a more coordinated policy approach.
This approach matters to AI providers, security teams, critical-sector operators and public authorities for different reasons. Some AI Act duties already apply, while parts of the EU’s July 2026 cybersecurity-and-AI action plan describe capabilities that are still being developed. Understanding that distinction is essential before treating a policy proposal as a compliance requirement or assuming that an existing AI Act obligation covers every security decision.
What it means when the EU links cybersecurity to AI oversight
Direct answer: The EU is connecting the oversight of advanced AI to cybersecurity by evaluating cyber-related risks, supervising relevant AI systems and general-purpose AI models under the AI Act, and developing secure ways to test AI for defensive use. The aim is to address both sides of the technology: AI can improve cybersecurity, but it can also help malicious actors conduct cyber operations.
The European Commission described its 7 July 2026 action plan as a “structured response” to the risks and opportunities of advanced AI for cybersecurity. Its framing brings together three activities that are often discussed separately: governing AI, evaluating its capabilities and risks, and improving the resilience of organisations that may use or be affected by it.
That connection is more specific than a general call for trustworthy AI. The Commission has said its AI Act oversight includes general-purpose AI models presenting “systemic risks related to cybersecurity,” and its communication discusses assessing whether providers have identified and mitigated those risks. Cybersecurity is therefore part of the substance of relevant AI oversight, not merely an external concern for a separate security team.
The practical distinction is between assessing what an AI model might enable, securing an AI system as deployed, and deciding whether an organisation can use that system safely. Each question needs evidence, but the evidence and responsible parties may differ.
The EU’s position also reflects a basic operational reality. A model could help a defender analyse complex security information while also making certain malicious tasks easier. An AI system could perform a useful defensive function yet still introduce vulnerabilities through its integration, access permissions or handling of sensitive data. Oversight has to consider both the model’s potential and the conditions in which it is used.
The action plan is not, by itself, a substitute for reading the applicable AI Act provisions or examining an actual deployment. It signals how the Commission intends to connect existing supervisory powers, specialist expertise and planned testing infrastructure. For organisations, the immediate value is a clearer set of questions to ask before procurement, release or deployment: What is being evaluated, which cyber risks matter, who is responsible for mitigation, and how will performance and safety be monitored afterward?
How the AI Act brings cyber risk into supervision
The AI Act provides the regulatory route through which the Commission says it will exercise supervisory and enforcement powers over relevant AI systems and general-purpose AI models. As of 2 August 2026, the Commission said that oversight includes models with systemic risks related to cybersecurity. A Commission representation summary also describes the AI Office and national authorities as beginning enforcement of AI Act rules from that date, including rules aimed at risks to European cybersecurity.
It is important not to collapse all AI Act responsibilities into one category. The Commission’s policy pages describe requirements addressing robustness, cybersecurity and accuracy for AI systems, as well as post-market monitoring and human oversight responsibilities for relevant providers and deployers. They also describe a division of work after an AI system reaches the market: authorities undertake market surveillance, while deployers carry out human oversight and monitoring within their responsibilities.
Model oversight is not the same as deployment oversight
Supervision of a general-purpose model can focus on risks associated with the model and the provider’s risk identification and mitigation measures. Oversight of an AI system also has to consider what that system does, how it is supplied and how it operates in practice. Deployment adds another layer: a user’s access controls, human review, incident handling and operational context can affect whether a particular use is safe.
These layers are connected but not interchangeable. A provider’s model evaluation cannot, on its own, establish that every downstream deployment is secure. Equally, strong local security controls cannot answer every question about a model’s capabilities or systemic risks. The EU’s framing is significant because it makes room for scrutiny at more than one point in the chain.
- Providers: Identify which AI Act duties apply to the system or model they supply, and retain evidence relevant to risk identification, mitigation and monitoring.
- Deployers: Examine how a system will be used, who can act on its outputs, and how human oversight and monitoring will work in that setting.
- Authorities: Use the supervisory and market-surveillance roles described in the EU framework, supported by specialist input where relevant.
These are practical categories, not a claim that every AI product has identical legal duties. An organisation should avoid treating the phrase “AI Act compliant” as a complete answer to a cybersecurity assessment. The useful follow-up is narrower: compliant with which applicable requirement, supported by what evidence, and for which model, system or use?
This is also why the AI Act is increasingly being presented as relevant to cybersecurity policy rather than only to AI policy. The Commission’s AI governance and cybersecurity pages place the July 2026 action plan alongside broader efforts to support secure, responsible AI use and European cyber resilience. That framing gives security teams a reason to participate in AI governance decisions rather than waiting until an AI tool has already been purchased or released.
Why AI creates a two-sided cybersecurity problem
The Commission’s case for linking these policies starts with a trade-off: AI can improve security, yet it can also be misused to identify vulnerabilities, automate attacks and increase the scale or speed of cyber incidents. That does not mean every advanced model presents the same level of risk, or that defensive uses should be avoided. It means capability assessments need to consider beneficial use and plausible misuse together.
ENISA’s 2026 Threat Landscape reinforces the concern. It says emerging AI models are expected to be increasingly used to support malicious cyber operations. It also warns that expanding cyber dependencies require “a new level of vigilance” to prevent and mitigate incidents. These assessments help explain the direction of EU policy, but they are not a prediction that any particular model or organisation will experience a particular attack.
Where defensive value and exposure meet
Consider an organisation using AI to assist analysts with cybersecurity work. Faster review of relevant information may help a team recognise and respond to problems. Yet the team still needs to decide whether the tool’s output is reliable enough for the intended task, whether a human checks consequential decisions, and whether the system’s access to internal information is appropriately limited.
A separate question arises when the same organisation supplies an advanced model to others. It may need to consider whether capabilities useful to defenders could also support malicious activity, and whether its testing and mitigations adequately address relevant risks. That is a model-governance question even before a particular customer decides how to integrate the model into its systems.
- Capability: What cyber-related tasks can the model or system perform, and under what conditions?
- Misuse: Could those capabilities make harmful activity easier, faster or more scalable?
- Deployment: What information, systems and decisions will the AI be allowed to influence in a real organisation?
- Resilience: What controls and human checks remain effective if an AI output is wrong, manipulated or used outside its intended purpose?
Working through those questions helps prevent two opposite mistakes. One is assuming that a useful security application must therefore be low risk. The other is treating potential misuse as proof that an application has no defensible use. The Commission’s action plan instead supports testing and structured access so that organisations can examine benefits and risks before relying on advanced AI in security operations.
The growing number of cyber dependencies makes that examination more important. An AI tool need not be the direct cause of an incident to affect resilience; it may influence how people interpret alerts, prioritise work or respond under pressure. Conversely, denying defenders access to useful capabilities has a cost of its own. The policy challenge is to make access, evaluation and safeguards work together, rather than choosing between unrestricted use and blanket avoidance.
What pre-deployment evaluation can establish,and what it cannot
The Commission’s July 2026 communication says advanced AI models must be evaluated and their risks assessed before being placed on the EU market, in support of the AI Office’s regulatory function. It also identifies external evaluations as an emerging best practice for frontier AI safety and says Europe needs greater evaluation capacity within the EU. In this context, evaluation is a way to generate evidence for decisions, not simply a label that declares a model safe.
For cyber-related systemic risks, evaluation can help clarify whether a model has relevant capabilities, what conditions affect its behaviour and whether identified mitigations address the risks being considered. The Commission’s stated oversight also encompasses assessment of providers’ risk identification and mitigation measures. That makes the quality of the reasoning and evidence behind a mitigation important, not just the presence of a written policy.
Ask what the evaluation actually covers
Readers of an evaluation report should distinguish its scope from its conclusion. An assessment of a model before market placement may not capture a later system integration, a change in available tools or an organisation’s decision to give the system access to sensitive workflows. Even an independent assessment is most useful when its methods, tested conditions and limitations are understandable to the people who must act on the result.
- Subject: Is the evidence about a general-purpose model, a finished AI system or a particular deployment?
- Conditions: Which capabilities, interfaces and access permissions were available during testing?
- Risk: Which cyber-related harms or misuse scenarios were examined, and which were outside scope?
- Mitigation: What action followed from the findings, and who is responsible for checking that it remains effective?
These questions are useful whether an evaluation is performed internally or externally. External expertise can add an independent perspective, but it does not remove a provider’s or deployer’s need to understand the result. Nor does a successful pre-deployment assessment eliminate the need for post-market monitoring and human oversight where those responsibilities apply.
There is also a practical limit to any test: it examines defined conditions at a point in time. Organisations change their integrations, workflows and reliance on a tool after deployment. The sounder approach is to connect pre-deployment evaluation to decisions about release and use, then keep monitoring relevant outcomes. That is consistent with the EU’s broader emphasis on both evaluation before market placement and oversight once systems are in use.
For buyers, this creates a useful alternative to asking a vendor whether a model is simply “safe.” Ask for evidence relevant to the intended use and for an explanation of what remains the buyer’s responsibility. For providers, the corresponding task is to make claims proportionate to the testing actually done. Those conversations are more actionable than a broad assurance that cannot be checked against a specific cyber risk.
How secure testing and structured access could help defenders
Evaluation capacity is only useful if organisations can test relevant applications under appropriate conditions. The EU action plan says ENISA and the Joint Research Centre will create a secure platform for testing AI for cybersecurity, including simulated environments. The stated purpose is to support safer deployment, particularly for organisations that need to understand how AI solutions behave before introducing them into consequential settings.
A simulated environment offers a practical middle ground between an abstract demonstration and immediate use in a live operation. It can give an organisation room to examine an AI tool’s usefulness, limitations and interaction with security tasks without assuming that a promising result in a demonstration translates directly into operational readiness. The action plan identifies energy, transport, health, finance and public administration among the sectors the platform is intended to help.
The Commission also says it will work with ENISA on a European blueprint for structured access to advanced AI capabilities for cybersecurity. The proposed access is for both public and private organisations. Access and testing are related but distinct: an organisation may need an opportunity to work with advanced capabilities, and it also needs conditions under which it can evaluate those capabilities responsibly.
What a prospective user should decide before testing
The platform and blueprint are described as initiatives to be developed, not as proof that every organisation can already use a finished EU testing service. While that work proceeds, teams can still identify what they would need from a test. The central question is not whether an AI tool produces an impressive output in isolation; it is whether the tool helps with a defined task while preserving the organisation’s ability to verify results and manage risk.
- Set a use case: Specify the security task and the decision the tool might support, rather than testing “AI for cyber” in general.
- Define a safe setting: Decide what information and system access are appropriate for the test, especially before any move toward live use.
- Set review points: Identify when a person must validate outputs and who can approve a change in how the tool is used.
- Record limitations: Note where results depend on simulated conditions and what would need further checking in an operational environment.
These are sensible planning questions, not a description of mandatory procedures for the planned platform. They reflect the difference between gaining access to an advanced capability and being ready to rely on it. A secure test can reveal reasons to proceed, reasons to adjust a use case or reasons to stop; all three outcomes are useful if they are documented clearly.
The trade-off for policymakers is similar. Too little access may limit defenders’ ability to understand and use advanced AI. Access without suitable evaluation may transfer uncertain risks into organisations that are not equipped to manage them. The Commission’s combination of a testing platform and a structured-access blueprint addresses both sides of that problem, although their practical value will depend on how they are implemented.
Why critical sectors need deployment decisions, not just model claims
The EU action plan explicitly connects secure AI testing to sectors such as energy, transport, health, finance and public administration. These organisations have different missions, but they share a reason to be cautious about technology that influences security work: an error, misuse or poorly understood dependency may affect services that others rely on. The fact that a model has been evaluated is valuable, but it cannot settle every question about its use in a particular sector.
Take a proposed AI assistant for a security team in a critical-sector organisation. Before adopting it, the organisation needs to know which information it will receive, what it may recommend, and whether its output could influence a time-sensitive response. A human oversight plan should be more concrete than saying a person remains “in the loop”: the team must know what the person reviews and what they are empowered to reject or escalate.
Monitoring matters after introduction as well. A system that appeared useful in testing may be used more widely than originally intended, or its outputs may gradually be treated as more authoritative than the evidence supports. The Commission’s AI policy pages place human oversight and monitoring alongside market surveillance as parts of the broader post-market picture. For a deployer, that makes routine operational review relevant to AI governance, not merely to internal IT practice.
A decision sequence for a consequential use case
- Identify the decision affected: Separate advice to an analyst from an output that could trigger an operational response.
- Map dependencies: Determine what data, tools and people the AI-enabled process relies on, and what happens if its output is unavailable or wrong.
- Review available evidence: Compare provider information and model evaluations with the organisation’s specific task and environment.
- Test before reliance: Use an appropriately controlled setting to examine performance and limitations for the intended use.
- Keep oversight active: Assign responsibility for reviewing outputs, monitoring use and revisiting the deployment decision when conditions change.
This sequence does not replace applicable legal analysis, sector-specific requirements or an organisation’s existing security processes. Its purpose is to keep the relevant decisions visible. A provider may be well placed to explain a model’s assessed capabilities, while the sector operator is better placed to understand the consequences of relying on a particular output in its own workflow.
The alternative to a structured decision is often an informal one: teams try a tool, find it helpful and let it become part of routine work without revisiting its original assumptions. That is precisely where a link between AI oversight and cyber resilience becomes useful. It encourages organisations to treat adoption as an ongoing governance decision, with testing before deployment and monitoring afterward, rather than as a one-time procurement choice.
Who coordinates EU AI and cybersecurity oversight
The Commission’s plan brings several institutions and groups into view, but their roles should not be confused. The Commission and its AI Office are central to the AI Act supervision described in the Commission’s communications. National authorities have enforcement and market-surveillance roles within the EU framework. ENISA contributes cybersecurity expertise, while the Joint Research Centre is named with ENISA in the planned secure testing platform.
Independent expert support has also been built into the enforcement environment. On 1 June 2026, the Commission appointed a Scientific Panel and an Advisory Forum to support AI Act enforcement, with ENISA listed among the permanent institutional participants. This does not make any one responsible for every cyber-related AI decision; it shows how specialist advice can feed into the wider oversight structure.
The AI Board’s 17 September 2026 meeting illustrates another coordination point. It reviewed AI Act implementation, Commission enforcement priorities and the cybersecurity-and-AI action plan. Those topics appearing together matter because decisions about AI rules, cyber risk and practical implementation cannot be handled effectively as entirely separate conversations among authorities.
- Regulatory oversight: Apply the relevant AI Act powers and examine evidence about systems, models and risks within the applicable remit.
- Cyber expertise: Help define and understand security concerns, including the changing threat environment described by ENISA.
- Testing capacity: Build ways to examine prospective cybersecurity applications under safer conditions.
- Operational responsibility: Ensure providers and deployers make defensible decisions about their own products and uses.
The broader cyber policy context also matters. ENISA’s programming material describes a longer-running effort to secure AI and machine learning, while a 2026 Commission document identifies additional ENISA resources for work including the Single Reporting Platform and the EU Cybersecurity Reserve. Those resource references indicate operational support for cybersecurity implementation; they should not be read as a claim that a dedicated AI testing platform is already fully funded, complete or available to all users.
Finally, the Commission says it will work with like-minded partners on a trusted and secure global approach to frontier AI and cybersecurity. International coordination may help when advanced models and cyber risks cross borders, but it does not remove the need for EU authorities and individual organisations to make decisions under their own responsibilities. The test of coordination will be whether it produces usable evidence, clear accountability and safer deployment, not simply more policy language.
What organisations should take from the EU approach now
The most useful response depends on an organisation’s role. An advanced-model provider should focus on identifying applicable AI Act duties and explaining how it assesses and mitigates relevant cyber risks. An AI system provider should be able to connect claims about robustness and cybersecurity to the system it actually supplies. A deployer should examine whether the intended use, human oversight and monitoring arrangements are appropriate for its own environment.
Across those roles, a common discipline is to keep three records distinct: what was learned about a model, what was established about a system, and what was observed in deployment. Combining them into a single claim of “approved AI” hides uncertainty. Keeping them separate makes it easier to see where another evaluation, a safer test or an operational control is needed.
Organisations should also watch for the difference between current oversight and planned support. The Commission describes AI Act supervisory and enforcement powers in use from 2 August 2026, while the secure testing platform and European blueprint for structured access are development commitments in the action plan. Planning around those initiatives can be sensible; relying on them as though they already resolve a present deployment question is not.
For a security leader, the near-term decision is practical: choose a defined use case, request evidence that speaks to its cyber risks, and identify the person or team accountable for reviewing the tool once it is used. For policymakers and buyers, the corresponding question is whether emerging evaluation and testing capacity will make that evidence more accessible and meaningful. These are complementary responsibilities, not alternatives.
The EU links cybersecurity to AI oversight because advanced AI can change both defensive capability and cyber exposure. Its approach combines AI Act supervision, pre-deployment evaluation, planned secure testing and continued attention to human oversight and resilience. The strongest takeaway is not that one test or regulation can settle every risk, but that each stage should produce evidence for the next decision.
Before adopting or supplying an AI capability for cybersecurity, ask what has been assessed, what remains untested and who will act if real-world use challenges the original assumptions. That keeps the benefits of AI within reach without treating its cyber risks as some else’s problem.
