Cybersecurity in the Era of AI · Part 2 — The EU AI Act: Risk Tiers, Obligations & the Road to 2027

This is Part 2 of Cybersecurity in the Era of AI, and it is where governance meets law. The EU AI Act — Regulation (EU) 2024/1689 — is the world's first comprehensive horizontal AI law, and it entered into force on 1 August 2024 with obligations phasing in through 2027. If your organization builds, deploys or distributes AI systems that touch the EU market — and, like the GDPR, its reach is extraterritorial, so "touching the EU market" catches many organizations outside the EU — the Act now sets the legal floor for what you must do. This part turns the regulation into something actionable: how it classifies AI by risk, what each tier obliges you to do, how your role (provider or deployer) changes those obligations, when each requirement bites, and — the practical crux — how to use the inventory and classification from Part 1 to work out where your own systems land and what that means for you.

A caution worth stating up front: this part explains the Act to help you build a compliance program; it is not legal advice, and the Act's detail (and the guidance and standards fleshing it out) continues to evolve. Treat what follows as the map that lets you have an informed conversation with your legal counsel and prioritize the right work — not as a substitute for that counsel.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: the Act's risk-based tiers and what falls in each; the distinction between provider and deployer obligations; the specific obligations on high-risk systems and on general-purpose AI (GPAI) models; the transparency obligations on limited-risk systems; the compliance timeline and penalties; and a method for classifying your own systems and mapping their obligations.
• Explicitly out of scope (later parts): ISO/IEC 42001, the management system that operationalizes much of this compliance (Part 3); and the technical security controls that satisfy the Act's accuracy, robustness and cybersecurity requirements for high-risk systems (Parts 5–6). This part tells you what the law requires; the later parts help you build it.
• Definition of done: the exit checklist at the end of this part. When every box is ticked, you know which tier and role each of your AI systems has, what the Act obliges you to do, by when, and you have a plan to meet it.

The Act's central design is a risk pyramid: the higher the risk an AI system poses to health, safety and fundamental rights, the heavier the obligations — from outright prohibition at the top, through a demanding regime for high-risk systems, to light transparency duties and, for most AI, essentially nothing. Classifying your systems into this pyramid is the first and most consequential compliance task.

The four risk tiers

Unacceptable risk — prohibited. A small set of AI practices are banned outright because they are judged incompatible with fundamental rights. These include social scoring by public authorities, manipulative or exploitative techniques that cause harm, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools (with narrow exceptions), and certain biometric categorization and real-time remote biometric identification in public spaces. The prohibitions have applied since 2 February 2025. For most organizations the compliance action here is simple but non-negotiable: confirm you are doing none of these, and put a check in procurement and development to keep it that way.

High risk — the heavy regime. This is the tier that dominates AI Act compliance work. A system is high-risk if it is a safety component of a regulated product (Annex I) or falls into one of the sensitive use-cases in Annex III — including AI used in employment (hiring, promotion), education (scoring, admissions), access to essential services (credit, insurance, public benefits), critical infrastructure, law enforcement, migration, and the administration of justice. High-risk systems carry the Act's full obligations (below) and are what your risk classification from Part 1 most needs to identify accurately, because the cost of the regime is real.

Limited risk — transparency. Certain systems carry transparency obligations rather than the full regime: users must be told when they are interacting with an AI (chatbots), AI-generated or manipulated content must be labelled (deepfakes), and synthetic media must be marked as such. If you run customer-facing chatbots or generate synthetic content, this tier applies to you and the obligation is comparatively light — disclosure, done properly.

Minimal risk — no obligations. The vast majority of AI — spam filters, recommendation engines, most productivity AI — falls here and carries no mandatory obligations under the Act, though voluntary codes of conduct are encouraged. Recognizing that most of your AI is minimal-risk is what keeps compliance proportionate; do not gold-plate.

Provider vs. deployer — your role changes everything

A pivotal subtlety is that the Act assigns obligations by role, and the same organization can be a provider for one system and a deployer of another. A provider develops an AI system (or has it developed) and places it on the market or puts it into service under its own name — providers of high-risk systems carry the bulk of the obligations. A deployer uses an AI system under its authority in the course of its activity — deployers of high-risk systems have lighter but real duties, chiefly using the system per its instructions, ensuring human oversight, monitoring, and (for certain uses) running a fundamental-rights impact assessment. Determining your role per system — which your Part 1 inventory should already record — is essential, because it decides which obligations are yours. Buy a high-risk AI system and you are largely a deployer; build one and you are a provider with the full load.

The obligations on high-risk systems

For a high-risk system, a provider must establish and satisfy a demanding set of requirements — and most of them map directly onto disciplines a good security and governance program already has, which is the connective tissue with the rest of this program:

risk_management_system: "continuous, across the lifecycle"      # Part 1 lifecycle controls
data_governance: "relevant, representative, error-checked data" # training/validation/test data quality
technical_documentation: "detailed, kept up to date"           # evidence for conformity
record_keeping: "automatic logging of events over lifetime"     # traceability
transparency: "clear instructions for use to deployers"
human_oversight: "designed-in, effective oversight by people"
accuracy_robustness_cybersecurity: "appropriate levels + resilience to attack"  # Parts 5-6
conformity_assessment: "before market: self- or third-party assessment"
registration: "in the EU database for high-risk systems"
ce_marking: "affix once conformity is established"
post_market_monitoring: "collect and act on real-world performance"

The last items make the compliance model concrete: a high-risk provider runs a conformity assessment (often a self-assessment against harmonized standards, third-party for some categories), affixes CE marking, and registers the system in the EU database — and then keeps monitoring it in the field. The accuracy_robustness_cybersecurity line is where Parts 5 and 6 of this program earn their place: the Act requires high-risk AI to be resilient to error and to attempts to manipulate it, which is exactly the secure-AI-development and adversarial-robustness work those parts cover.

General-purpose AI models

The Act added a distinct regime for general-purpose AI (GPAI) models — the foundation models that power much of the current wave. Providers of GPAI models must maintain technical documentation, provide information to downstream developers who build on them, put in place a policy to respect EU copyright law, and publish a sufficiently detailed summary of training data. Models deemed to pose systemic risk (very capable models above a compute threshold) carry additional obligations: model evaluation, adversarial testing, systemic-risk assessment and mitigation, incident reporting, and cybersecurity protection. Most organizations are consumers of GPAI rather than providers, but if you fine-tune or distribute a foundation model you may take on provider obligations — another reason your inventory records the model provenance of each system.

The compliance timeline

The Act phases in, which lets you sequence the work:

• 1 Aug 2024 — entered into force.
• 2 Feb 2025 — prohibitions on unacceptable-risk AI apply; AI literacy obligations begin.
• 2 Aug 2025 — GPAI model obligations, governance bodies, and the penalty provisions apply.
• 2 Aug 2026 — the main high-risk obligations (Annex III use-cases) apply — the deadline most high-risk deployers and providers are working toward.
• 2 Aug 2027 — high-risk obligations for AI as a safety component of regulated products (Annex I) apply; GPAI models placed on the market before Aug 2025 must be brought into compliance.

Penalties are GDPR-scale and then some: up to €35M or 7% of global annual turnover for prohibited-practice violations, up to €15M or 3% for breaching other obligations (including the high-risk requirements), and up to €7.5M or 1% for supplying incorrect information. The scale is deliberate — the Act is meant to be taken as seriously as data protection.

Classifying your own systems

The practical method pulls Part 1's inventory through a decision flow. For each AI system: first, is it a prohibited practice? (If so, stop doing it.) Second, is it high-risk — a safety component of a regulated product, or an Annex III use-case? If yes, determine your role (provider or deployer) and scope the corresponding obligations. Third, does it trigger transparency duties (chatbot, synthetic content)? If none of these, it is minimal-risk and carries no mandatory obligations. Running every inventoried system through this flow produces your AI Act obligation map — the deliverable of this part — which then feeds the ISO 42001 management system (Part 3) as the control set you need to operate and evidence.

Definition of done — EU AI Act exit checklist

You are ready for Part 3 when every one of these is true:

• Prohibited practices ruled out: you have confirmed none of your AI use falls in the unacceptable-risk tier, with a control in procurement and development to keep it that way.
• Classification complete: every inventoried AI system is classified against the Act's tiers (unacceptable / high / limited / minimal), and your role (provider / deployer) is recorded per system.
• High-risk obligations scoped: for each high-risk system, the applicable obligations are identified and a plan exists to meet them (risk management, data governance, documentation, logging, human oversight, accuracy/robustness/cybersecurity, conformity assessment, CE marking, registration, post-market monitoring).
• GPAI position understood: you know whether you are a provider of any GPAI model (e.g. via fine-tuning/distribution) and, if so, the obligations that follow.
• Transparency duties met: chatbots disclose they are AI and synthetic/manipulated content is labelled, where applicable.
• Timeline mapped: obligations are mapped to their applicable dates (notably 2 Aug 2026 for Annex III high-risk) with owners and a schedule.

Tick every box and you have turned a 100-page regulation into a per-system obligation map with owners and deadlines — the difference between "we're worried about the AI Act" and "here is exactly what we must do, for which systems, by when."

What's next

Part 3 — ISO/IEC 42001 is the natural sequel, because it is the management system that operationalizes and evidences much of what the AI Act requires. Rather than treating AI Act compliance as a one-off project, ISO 42001 gives you a certifiable AI Management System that runs the risk assessments, controls, impact assessments and continual improvement the Act demands — and demonstrates responsible AI to customers and regulators in the process. Part 3 shows how to build and certify it, and how a single well-run management system can serve both your 42001 certification and your AI Act obligations. It ships next month.

If you would like experienced hands to determine your AI Act exposure — classify your systems, establish provider/deployer roles, scope the high-risk obligations and build the compliance plan — that is exactly what Axelia's consultants do, and ISMShed maps each system's AI Act obligations to the controls and evidence that satisfy them, alongside ISO/IEC 42001, ISO 27001, NIS2, DORA and GDPR. Understand your obligations now, and Part 3 gives you the management system to meet them durably.