The EU AI Act is not a cybersecurity regulation in the same way as NIS 2 or the Cyber Resilience Act. However, it creates cybersecurity obligations for high-risk AI systems and forces compliance teams to connect AI governance, security controls, incident management, and supplier oversight.
Sources: Regulation (EU) 2024/1689, European Commission AI Act page, EU AI Act implementation timeline, NIS 2 Directive.
Key takeaways
- The AI Act entered into force on 1 August 2024.
- Prohibited AI practices and AI literacy obligations apply from 2 February 2025.
- Governance rules and general-purpose AI obligations became applicable on 2 August 2025.
- The Commission page states full applicability from 2 August 2026, with exceptions including extended transition for high-risk systems embedded in regulated products.
- Article 15 requires high-risk AI systems to achieve appropriate accuracy, robustness, and cybersecurity.
- Compliance teams should monitor proposed EU simplification changes because application timelines may evolve.
Scope of this article
This article focuses on cybersecurity implications. It does not cover the full AI governance lifecycle, fundamental-rights assessment, or sector-specific AI conformity in detail.
What the AI Act changes for security teams
The AI Act uses a risk-based model. For cybersecurity teams, the highest-impact area is high-risk AI. Systems in this category require risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, and cybersecurity controls.
Application timeline
| Date | Milestone | Security relevance |
|---|---|---|
| 1 August 2024 | Entry into force | Governance preparation period starts. |
| 2 February 2025 | Prohibitions and AI literacy | Policy and training obligations become operational. |
| 2 August 2025 | GPAI and governance provisions | Supplier and model-governance checks become more important. |
| 2 August 2026 | Main application date with exceptions | High-risk AI governance becomes a core compliance workstream. |
| 2 August 2027 | Extended transition for certain embedded high-risk AI systems | Product-security and CRA coordination become central. |
Cybersecurity touchpoints
- Article 15: high-risk AI systems must be resilient against errors, faults, and attempts to alter use or performance.
- Logging: high-risk AI governance requires records that support monitoring and accountability.
- Supplier oversight: AI components and models introduce third-party security and assurance questions.
- Incident handling: AI-related incidents may need coordination with existing cyber incident processes.
- Secure development: training data, model artifacts, prompts, APIs, and integrations become part of the attack surface.
Coordination with NIS 2 and CRA
NIS 2 governs entity-level cybersecurity resilience. CRA governs products with digital elements. The AI Act governs AI systems. An organization can face all three when it provides an AI-enabled digital product and is also a NIS 2 entity. The practical answer is one integrated control map.
For adjacent context, see Cyber Resilience Act obligations and NIS 2 overview.
Checklist for compliance teams
- Inventory AI systems, models, datasets, APIs, and suppliers.
- Classify systems by AI Act risk category.
- Identify high-risk systems requiring cybersecurity evidence.
- Map AI security controls to NIS 2, CRA, ISO 27001, or internal control frameworks.
- Define incident routing for AI failures, security compromise, and data exposure.
- Review contracts for model providers, AI SaaS, and embedded components.
- Track EU implementation updates and proposed simplification measures.
Article 15 in operational terms
Article 15 is the key cybersecurity bridge for high-risk AI. The compliance team should translate it into testable controls: resilience against manipulation, protection of model interfaces, secure configuration, robustness testing, monitoring of performance drift, and fallback procedures when the system behaves unexpectedly.
| AI security area | Typical control question |
|---|---|
| Model and prompt interfaces | Can unauthorized users alter behavior or extract sensitive outputs? |
| Data pipeline | Are training, validation, and production data protected against tampering? |
| API security | Are authentication, rate limits, logging, and abuse detection in place? |
| Monitoring | Can the team detect drift, abnormal outputs, or misuse? |
| Fallback | Can the organization stop or override the AI system safely? |
Threat scenarios to include
- Prompt injection or instruction manipulation against AI-enabled workflows.
- Poisoned or low-integrity data entering training or retrieval pipelines.
- Unauthorized model access through exposed APIs.
- Shadow AI usage that bypasses procurement and security review.
- Supplier model changes that alter risk without internal approval.
Supplier due diligence
Compliance teams should ask AI suppliers for documentation on model purpose, hosting, data handling, security controls, logging, incident notification, vulnerability handling, and subcontractors. For AI SaaS, contract clauses should address both cybersecurity and AI-governance evidence.
Integrated control map
The most efficient preparation is to map AI Act requirements against existing controls for ISO 27001, NIS 2, CRA, GDPR, secure development, and supplier risk. This avoids creating an isolated AI compliance program with duplicated evidence.
Implementation pattern for cybersecurity teams
Security teams should not wait for a complete AI governance program before acting. They can start with three controls: AI system inventory, supplier review, and secure integration review. These controls give immediate visibility and can later be mapped into the broader AI Act governance model.
AI asset inventory fields
| Field | Why it matters |
|---|---|
| System purpose | Supports risk classification and business ownership. |
| Provider or model source | Identifies supplier and contractual dependency. |
| Data processed | Connects AI use to GDPR and confidentiality controls. |
| Integration points | Shows APIs, plugins, and access paths. |
| Human oversight | Documents who can review or override outputs. |
| Incident contact | Ensures AI failures reach the right response team. |
Security controls to prioritize
- Access control for AI tools and APIs.
- Logging of prompts, outputs, and administrative changes where lawful and proportionate.
- Data-loss prevention for sensitive inputs.
- Supplier review for model hosting, training data use, and incident notification.
- Change management for model updates and new integrations.
Governance boundary
Aegister’s cybersecurity view is not a substitute for a full AI legal program. The value is in the intersection: identifying AI-enabled cyber risks, connecting them to controls, and ensuring that existing security governance does not ignore AI systems.
For organizations integrating AI systems into NIS 2 or DORA scopes, Aegister's Virtual CISO service covers the cybersecurity side of AI Act readiness: risk-based control mapping, vulnerability handling for AI-enabled systems, incident classification across NIS 2 / GDPR / AI Act, and coordination with internal AI governance owners.
FAQ
Is the AI Act a cybersecurity law?
Not primarily. It is an AI governance regulation, but it includes cybersecurity obligations for high-risk AI systems.
Does Article 15 apply to every AI system?
No. Article 15 is focused on high-risk AI systems. Classification is the first step.
Should the CISO own AI Act compliance?
No single function should own it alone. The CISO should own security controls, while legal, compliance, product, data, and business teams own the broader governance model.
