EU AI Act Compliance: What Security Teams Must Do Now

Why This Is Urgent Rather Than Theoretical

The EU AI Act (Regulation 2024/1689) entered into force in August 2024 and applies in stages. The prohibitions on unacceptable-risk practices and the AI literacy duty applied first, general-purpose AI model obligations followed, and the substantial obligations for high-risk systems land in August 2026.

For security and GRC teams the practical consequence is that AI is now a regulated asset class. If your organization builds, deploys, imports, or distributes AI in the EU market, or its output is used in the EU, you need an inventory, a classification, and evidence.

This is not legal advice. Treat it as a security and compliance orientation, and get counsel on your specific classification questions.

The Risk Tiers

The Act is risk-tiered, and almost everything depends on which tier your system falls into.

Unacceptable risk, prohibited. A defined set of practices including social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and educational settings (with narrow exceptions), certain biometric categorization, exploitation of vulnerabilities, and specified real-time remote biometric identification in public spaces for law enforcement. These are banned outright.

High risk. Two routes in. First, AI used as a safety component of products already covered by EU product legislation. Second, systems in the listed areas, which include biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential public and private services (including creditworthiness and insurance pricing), law enforcement, migration and border control, and administration of justice.

Two categories matter enormously to ordinary companies: employment (recruitment screening, task allocation, monitoring, promotion and termination decisions) and essential services (credit scoring, insurance risk pricing). A great many organizations using off-the-shelf HR or credit tooling are deployers of high-risk AI without having framed it that way.

Limited or transparency risk. Systems that interact with people, generate synthetic content, or perform emotion recognition and biometric categorization outside prohibited contexts. The obligation is disclosure: people must know they are dealing with AI, and synthetic content must be marked in a machine-readable way.

Minimal risk. Everything else, with no mandatory obligations beyond the general AI literacy duty.

What High-Risk Systems Actually Require

If you are a provider (you develop it, or you put your name on it, or you substantially modify someone else's), the obligations are heavy:

Data and data governance covering training, validation, and testing data, including relevance, representativeness, and examination for bias.

Technical documentation and automatically recorded **logs** sufficient to trace system behaviour.

Transparency and instructions for use that let deployers operate the system correctly.

Human oversight designed in, such that a person can understand, intervene, and override.

Accuracy, robustness, and cybersecurity appropriate to the intended purpose, explicitly including resilience against adversarial manipulation such as data poisoning and model evasion.

If you are a deployer (you use it under your own authority), the load is lighter but real: use the system in line with the instructions, assign competent human oversight, ensure input data is relevant where you control it, monitor and report serious incidents and malfunctions to the provider, keep logs, and inform affected workers before putting a high-risk system into use in the workplace. Certain public bodies and specified private deployers must also carry out a fundamental rights impact assessment.

Note the trap: modifying a third-party high-risk system substantially, or putting your own brand on it, can convert you from deployer to provider, with the full obligation set attached.

The Cybersecurity Angle Specifically

The Act names cybersecurity as a requirement for high-risk systems, which means security teams own a compliance deliverable, not just an advisory role. In practice you should expect to evidence:

Model and data integrity , including supply chain provenance for base models, datasets, and adapters.

Access control over training pipelines, model artifacts, and inference endpoints.

Logging and traceability adequate for incident reconstruction and for serious-incident reporting.

Resilience against attempts to alter use, output, or performance, and safe behaviour on failure.

MITRE ATLAS and the OWASP LLM list are useful for structuring the threat side of this. Neither is a legal instrument, but both help you show that you considered the relevant attack classes.

Penalties

The Act's penalty ceilings are tiered:

Lower caps apply to small and medium-sized enterprises and startups. Separate arrangements apply to general-purpose AI model providers.

A Readiness Checklist

1. Build the AI inventory. You cannot classify what you have not found. Include vendor features that quietly became AI: the resume screener, the fraud model, the chat assistant, the code assistant, the credit decision engine. Shadow AI adoption is the norm, so ask business units directly rather than relying on procurement records.

2. Classify each system by tier and by your role. Provider or deployer, and which tier. Record the reasoning, because the reasoning is what an authority will ask about.

3. Close the documentation gap for high-risk systems. Technical documentation, logging, human oversight design, and instructions for use are usually where organizations are weakest.

4. Fold AI into existing governance rather than building a parallel programme. Your risk register, third-party risk process, change management, incident response, and DPIA workflow should absorb AI systems. A separate AI silo tends to be abandoned within a year.

5. Fix transparency obligations now. Disclosure that a user is interacting with AI, and machine-readable marking of synthetic content, are comparatively cheap and highly visible.

6. Handle the overlap with GDPR deliberately. Where AI processes personal data both regimes apply. Lawful basis, data minimization, automated decision-making rights, and DPIAs do not go away because the system is now also AI-regulated.

7. Use ISO/IEC 42001 as the management-system scaffold. It is not a legal presumption of conformity, but it is the recognized AI management system standard and maps well onto the Act's governance expectations. If you already run ISO 27001, extending the management system is far cheaper than starting fresh.

8. Train people. The AI literacy obligation applies broadly, and it is one of the few duties that touches every organization using AI.

Where the Careers Are

This regulation is creating a distinct role: the person who can hold AI governance, security, and compliance together. That is why AI governance credentials moved from novelty to hiring signal within two years, and why AI audit qualifications are appearing from the established certification bodies.

CyberCertPrep covers this ground across the AIGP, AAISM, AICP, CLLMSP and GDPR banks, including AI risk management frameworks, governance structures, transparency obligations, and the security controls regulators expect, with detailed explanations for every question.