Home AI Act

AI Act

EU AI Act - risk classification, obligations by category, readiness signals.
By Eliseo Thrope
2 articles

The EU AI Act explained — risk tiers and what they mean for you

The EU AI Act explained — risk tiers and what they mean for you TL;DR — The AI Act is the EU's regulation for artificial intelligence. It classifies AI systems by risk — unacceptable, high, limited, and minimal — and scales obligations accordingly. High-risk systems carry the heaviest duties: risk management, data governance, technical documentation, human oversight, and conformity assessment. If your product embeds AI, your first job is to determine which risk tier applies. What is the AI Act? The AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive horizontal law governing artificial intelligence. It applies to providers and deployers of AI systems placed on the EU market or whose output is used in the EU — regardless of where the provider is established. Its central mechanism is a risk-based approach: the higher the risk an AI system poses to health, safety, and fundamental rights, the stricter the obligations. The four risk tiers 1. Unacceptable risk — prohibited. Certain practices are banned outright, such as social scoring by public authorities and manipulative or exploitative systems. 2. High risk — heavily regulated. AI used in critical areas (for example, safety components of products, biometric identification, critical infrastructure, employment, essential services, law enforcement) must meet strict requirements before and during market placement. 3. Limited risk — transparency obligations. Systems like chatbots or AI-generated content must disclose that users are interacting with, or seeing output from, AI. 4. Minimal risk — largely unregulated. The majority of AI systems fall here, with no specific obligations under the Act. There is also a distinct regime for general-purpose AI (GPAI) models, with obligations that scale further for models presenting systemic risk. What do high-risk obligations look like? Providers of high-risk AI systems must, among other things: - Establish a risk-management system across the lifecycle - Apply data governance to training, validation, and testing data - Maintain technical documentation and automatic logging - Ensure appropriate human oversight - Achieve suitable levels of accuracy, robustness, and cybersecurity - Undergo conformity assessment and register the system Deployers of high-risk systems carry their own obligations around use, monitoring, and human oversight. Why classification is the hard part The most consequential — and often most difficult — step is determining which tier your system falls into. Misclassifying a high-risk system as limited risk exposes you to significant non-compliance. The classification depends on the system's intended purpose and its area of use, and it interacts with existing product-safety legislation. This is why a structured scoping step matters before you invest in controls. How the AI Act overlaps with the CRA If your AI system is embedded in a product with digital elements, both the AI Act and the CRA can apply. The cybersecurity obligations of the AI Act (robustness, security of high-risk systems) align closely with CRA product-security requirements — shared evidence such as risk assessments and security testing serves both. → AI Act vs CRA overlap Timeline The AI Act applies in phases: - Prohibitions on unacceptable-risk practices apply first - GPAI obligations follow - High-risk obligations phase in through 2026-2027 Exact dates depend on the system category; confirm against current official sources. The risk pyramid at a glance ▲ UNACCEPTABLE ╱ ╲ → prohibited outright ╱ ╲ ╱ HIGH ╲ → strict obligations, ╱ RISK ╲ conformity assessment ╱─────────╲ ╱ LIMITED ╲ → transparency duties ╱ RISK ╲ (disclose AI use) ╱───────────────╲ ╱ MINIMAL ╲ → no specific ╱ RISK ╲ obligations ╱─────────────────────╲ (most AI systems live here) The higher up the pyramid, the heavier the obligations — and the fewer systems occupy each level. Most AI is minimal-risk; the regulatory weight concentrates at the top. Provider vs deployer The AI Act distinguishes two main roles, and you may be both: | | Provider | Deployer | |---|---|---| | ▸ Who | Develops/places the AI system on the market | Uses an AI system under its authority | | ▸ Core duty | Build compliant systems, run conformity assessment | Use as intended, ensure oversight, monitor | | ▸ Typical example | An AI vendor | A company using a vendor's AI tool | Getting the role right matters, because the obligations differ. A company that fine-tunes or substantially modifies a system can shift from deployer to provider. Frequently asked questions Does the AI Act apply to us if we're outside the EU? Yes, if your AI system is placed on the EU market or its output is used in the EU. Location of the provider does not exempt you. We only use third-party AI — are we covered? Potentially, as a deployer — especially for high-risk uses, where deployers carry monitoring and oversight duties. And if you modify a system substantially, you may become a provider. What about general-purpose AI models? GPAI models have their own obligations, which scale further for models presenting systemic risk. If you build on or provide such models, this regime is relevant to you. How do we know if we're high-risk? Classification depends on the system's intended purpose and area of use, and interacts with existing product-safety law. It is the decisive first step — scope it before investing in controls. What to do now 1. Inventory your AI — every model and system, and its intended purpose. 2. Classify by risk tier — this drives everything downstream. 3. For high-risk systems, begin building the risk-management, data-governance, and documentation foundations early. 4. Add transparency notices where limited-risk obligations apply. A free scope review helps you determine how the AI Act applies across your product portfolio. → Related: How EU compliance works Where do most teams get AI Act classification wrong? The most common error is treating a system as limited-risk when its intended use places it in a high-risk category. Because classification drives the entire obligation load, confirming it early — before investing in controls — is the single highest-value step. NexCyber provides a readiness analysis, not legal advice. AI Act classification and conformity assessment for high-risk systems may require legal review and accredited notified bodies. Last reviewed 2026-07-10.

Last updated on Jul 13, 2026

AI Act — Annex III high-risk areas and provider obligations, deep dive

In one paragraph Annex III of the EU AI Act lists the areas where an AI system is considered high-risk. Providers, deployers, importers, and distributors of such systems carry the bulk of AI Act obligations. This article walks each Annex III area, explains the provider-side expectations, and maps each to the evidence NexCyber tracks. The eight Annex III areas Annex III defines eight areas where an AI system is high-risk. The exact wording follows the regulation; the working summary below is for orientation. 1. Biometrics Remote biometric identification systems; biometric categorisation; emotion recognition. Narrow exceptions apply for verification. NexCyber tracks: data governance, accuracy and bias testing, oversight, fundamental-rights impact assessment. 2. Critical infrastructure Safety components of management or operation of critical digital infrastructure, road traffic, supply of water, gas, heating, or electricity. NexCyber tracks: risk management for safety, robustness testing, post-market monitoring, integration with NIS2 obligations where the operator is also an essential entity. 3. Education and vocational training Determining access, admission, assignment to educational institutions; evaluating learning outcomes; assessing the appropriate level of education; monitoring and detecting prohibited behaviour of students during tests. NexCyber tracks: data quality and representativeness, human oversight, transparency to learners and educators, accuracy testing. 4. Employment, workers management, and access to self-employment Recruitment or selection; making decisions about promotion or termination; allocating tasks; monitoring and evaluating performance. NexCyber tracks: fairness testing, transparency to candidates and workers, oversight, technical documentation. 5. Access to and enjoyment of essential private and public services and benefits Eligibility for public assistance benefits and services; creditworthiness; risk assessment for life and health insurance; dispatching of emergency services. NexCyber tracks: accuracy and bias testing, human oversight, transparency to applicants, appeal mechanisms in the design. 6. Law enforcement Profiling; assessing risk of becoming a victim or offender; lie detection; evaluating reliability of evidence; predicting recurrence; profiling for prevention or investigation. NexCyber tracks: legal-basis documentation, oversight, data minimisation, accuracy testing, transparency to the extent allowed. 7. Migration, asylum, and border control management Lie detection; risk assessment; verification of authenticity of travel documents; examination of applications. NexCyber tracks: legal-basis documentation, accuracy testing, oversight, fundamental-rights impact assessment. 8. Administration of justice and democratic processes Researching and interpreting facts and the law; influencing the outcome of an election or referendum. NexCyber tracks: legal-basis documentation, oversight, transparency, accuracy testing. Provider obligations — the seven workstreams Whichever Annex III area applies, providers of high-risk AI systems carry seven workstreams. NexCyber tracks each as a section in the AI Act assessment workspace. Risk management A continuous risk management system across the lifecycle. Not a one-off document; a living process. Evidence: risk management policy, risk register, mitigation plans, post-incident review records. Data and data governance Training, validation, and testing datasets must meet quality, representativeness, and integrity expectations. Evidence: dataset provenance, quality criteria, bias and representativeness tests, data labelling guidelines, data versioning. Technical documentation A documented description of the system, its components, lifecycle, datasets, training, validation, and testing methodology, performance metrics, and known limitations. Evidence: technical file, model card, change log, training pipeline diagram, performance reports. Record-keeping and logs Automatic logs over the lifetime of the system. Evidence: logging architecture, retention policy, audit log samples, integrity controls. Transparency and information to deployers Instructions for use, performance characteristics, intended purpose, human oversight measures, expected lifetime, foreseeable misuse. Evidence: instructions for use, model card published to deployers, change notices. Human oversight The system must be designed to allow humans to oversee its operation, intervene, and override where necessary. Evidence: oversight design document, escalation and override mechanisms, training of oversight roles, test of overrides. Accuracy, robustness, and cybersecurity The system must achieve appropriate levels of accuracy, robustness, and cybersecurity, and behave consistently against errors, faults, attacks, and inconsistencies. Evidence: accuracy reports, adversarial robustness tests, threat model, cybersecurity controls, post-deployment monitoring. Deployer obligations Deployers carry their own obligations: using the system in accordance with instructions, monitoring its operation, ensuring human oversight, keeping logs, conducting fundamental-rights impact assessment in some cases, and informing affected persons where required. NexCyber tracks deployer-side evidence alongside provider-side, so a customer using a partner's high-risk system can demonstrate appropriate use. GPAI considerations General-Purpose AI models carry model-level obligations even outside the Annex III high-risk areas (technical documentation, copyright policy, training data summary). Systemic-risk GPAI carry additional obligations (model evaluation, systemic risk assessment, incident reporting, cybersecurity protection). If your estate includes GPAI components, NexCyber surfaces the model-level obligations in the AI Act assessment. Conformity assessment High-risk providers must run conformity assessment before placing the system on the market. The route depends on the area and on the use of harmonised standards. NexCyber prepares the technical file and tracks the assessment artefacts; it does not perform the assessment. Fundamental-rights impact assessment For some high-risk AI systems, deployers must perform a fundamental-rights impact assessment (FRIA). NexCyber tracks the FRIA artefacts and the link to the underlying risk management system. Post-market monitoring High-risk systems require a post-market monitoring plan: how field data is collected, evaluated, and fed back into the risk management system. NexCyber tracks the monitoring plan, the field telemetry inventory, and the periodic monitoring reports. Reporting of serious incidents Providers must report serious incidents to market surveillance authorities within tight timelines. NexCyber offers the playbook scaffold; the report itself remains your filing. What the AI Act does NOT do via NexCyber - It does not issue conformity certificates. - It does not interpret whether your system is high-risk for a specific borderline case (we flag for human regulatory triage). - It does not perform testing — NexCyber tracks evidence of testing you have done. Common pitfalls - Treating risk management as a one-off document. - Skipping representativeness testing on datasets. - Logging without an integrity story. - Human oversight in the architecture but no training for the oversight role. - Post-market monitoring plans with no telemetry. Related articles - AI Act basics — wider picture. - What evidence should I prepare? — cross-regulation evidence list. - What NexCyber does NOT replace — boundary with legal advice. Next step Confirm your Annex III area in scope, open the AI Act assessment, and attach evidence per workstream.

Last updated on Jun 03, 2026