The Cyber Academy take
The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive AI regulation. Four risk tiers: unacceptable (banned), high (heavy obligations and conformity assessment), limited (transparency), minimal. Dedicated rules for general-purpose AI models. Applies in phases until August 2027. ISO 42001 is the management-system answer to the AI Act's organisational requirements.
TL;DR
- 1Risk-based: unacceptable practices banned (since February 2025), high-risk systems heavily regulated, limited risk requires transparency, minimal risk untouched.
- 2High-risk systems (employment, critical infrastructure, education, biometrics, law enforcement, justice…) require risk management, data governance, technical documentation, transparency, human oversight, accuracy and cybersecurity.
- 3GPAI model rules apply to general-purpose AI providers, with tighter obligations for systemic-risk models.
- 4Conformity assessment required before placing a high-risk system on the EU market. CE marking applies.
- 5Pair with ISO/IEC 42001 for the management-system layer. The AI Act tells you what to demonstrate; ISO 42001 tells you how to organise the proof.
Classify the system before you do anything else
Every AI Act decision starts with one question: which tier does this system fall into. Get the classification wrong and you either over-engineer a chatbot or under-protect a CV-screening tool that a regulator will treat as high-risk. The four tiers are not a spectrum you slide along; they are discrete buckets with different legal consequences, and a single product can sit in more than one if it bundles several functions.
Classification is a function of intended purpose, not technical sophistication. A simple logistic regression that decides who gets a loan is high-risk. A large multimodal model that recommends recipes is not. The Act looks at what the system is used for and who it affects, so the classification work belongs to product and compliance together, not to the data-science team alone.
| Risk tier | Examples | Core obligation | Gate before market |
|---|---|---|---|
| Unacceptable | Social scoring, untargeted facial-recognition scraping, manipulative or exploitative systems | Prohibited. The practice cannot be placed on the market or used at all. | Banned outright (prohibitions apply from February 2025) |
| High | Employment and recruitment, credit scoring, critical infrastructure, education, biometrics, law enforcement, justice | Full obligation set: risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity | Conformity assessment plus CE marking and EU database registration |
| Limited | Chatbots, emotion-recognition, deepfakes and other generated content | Transparency only: tell people they are interacting with AI or that content is AI-generated | No conformity assessment; disclosure obligations |
| Minimal | Spam filters, recommendation engines, most consumer AI features | No mandatory obligations under the Act; voluntary codes encouraged | None |
Most disputes in the audit room are not minimal-versus-high; they are high-versus-limited at the boundary. If you cannot defend the classification in writing, treat it as the higher tier until you can. The AI Risk Manager course walks through the classification logic and the evidence you need to stand behind a decision.
What "high-risk" actually means in operations
The TL;DR lists the seven obligation areas. The operational reality is that each one is a recurring process, not a document you write once. High-risk compliance is a system you run for the life of the product, and the Act expects you to demonstrate that the system is live, not that it existed on launch day.
- Risk management is continuous. You identify foreseeable misuse and harms, mitigate them, test the residual risk, and repeat across every substantial change. A frozen risk register from launch is a finding, not a control.
- Data governance covers the training, validation and test sets: representativeness, bias examination, gaps and the provenance of the data. You need to show what you checked and what you found, not just assert the data was "good".
- Technical documentation is the spine of the file. It describes the system, its purpose, its design choices, its performance metrics and its limitations in enough detail that a third party could assess conformity from it.
- Record-keeping means automatic logging over the system lifetime so that events are traceable. If something goes wrong, you must be able to reconstruct what the system did.
- Human oversight has to be designed in, not bolted on: the people supervising the system need the ability to understand, intervene and override, and the interface has to make that possible.
- Accuracy, robustness and cybersecurity have to be measured and declared, then held under real conditions including adversarial ones. "It works on the demo" is not a robustness claim.
These obligations map cleanly onto a management system, which is why teams pair the Act with ISO/IEC 42001. The ISO 42001 Lead Implementer course builds the operating model that turns these seven areas into repeatable processes with owners, evidence and review cycles.
The conformity-assessment workflow
Conformity assessment is the gate a high-risk system passes before it is placed on the EU market. For most high-risk categories this is an internal control assessment run by the provider against the Act requirements; certain categories, notably some biometrics, route through a notified body. Either way the sequence is the same, and it is worth treating as a project plan rather than a checklist.
- Confirm the classification and the applicable requirements for your specific use case and category.
- Stand up the risk-management and data-governance processes and run them, generating real evidence rather than placeholders.
- Assemble the technical documentation so it is complete and internally consistent with the logs, test results and risk register.
- Run the conformity assessment (internal, or via a notified body where required) and resolve the gaps it surfaces.
- Draw up the EU declaration of conformity, affix the CE marking, and register the system in the EU database before going to market.
- Move into post-market monitoring on day one, because the obligation does not end at launch.
Post-market monitoring and the phased timeline
Placing a system on the market is the midpoint of the obligation, not the end. Providers must run a post-market monitoring plan that actively collects performance and incident data over the deployed life of the system, and serious incidents have to be reported to authorities within defined windows. Substantial modifications can re-trigger conformity assessment, so your change-management process and your AI Act process have to be wired together.
The timeline is phased, which trips up teams that read "August 2027" and assume they have until then for everything. The prohibitions on unacceptable practices already apply. GPAI obligations and several governance provisions land earlier in the schedule, and the high-risk obligations phase in across the period to August 2027 depending on the category. The right posture is to map each of your systems to its own applicable date rather than planning to one cliff edge.
Operating the monitoring and incident loop is where the AI auditor and risk roles earn their keep. The AI auditor (AAIA) course covers how to audit an AI management system against this evidence, and the advanced AI auditor (AAIR) course goes deeper on the testing and assurance work behind a defensible post-market file.
General-purpose AI: a separate obligation you can inherit
GPAI model rules sit alongside the risk tiers, not inside them. If you build or fine-tune a general-purpose model, you carry provider obligations: technical documentation for the model, information for downstream deployers, a copyright policy, and a public summary of training content. Models judged to carry systemic risk take on tighter duties including model evaluation, adversarial testing and incident reporting.
The trap for most teams is the other side of that relationship. If you integrate a third-party foundation model into your own high-risk system, you do not escape the Act by pointing at the model provider. You inherit the integration risk and remain responsible for your system reaching conformity. Treat the model provider documentation as an input to your file, not a substitute for it, and put the contractual flow-downs in place before you ship.
Common mistakes and the decision in front of you
- Treating classification as a one-off. A feature that started as a recommendation engine becomes high-risk the moment it gates a hiring or credit decision. Re-classify on every material change of purpose.
- Writing documentation as a launch artifact. The file has to stay synchronized with the running system; a stale file is worse than an incomplete one because it actively misleads.
- Confusing the management system with the regulation. ISO 42001 organizes your proof, but it does not by itself make a system AI Act compliant. You still classify, assess and register against the Act.
- Assuming GPAI provider obligations cover your integration. They do not. Your high-risk system needs its own conformity story.
- Planning to one deadline. The phased dates mean some obligations are already live while others are years out; plan per system, per category.
The decision in front of most teams is not whether to comply but how to build the capability to comply repeatedly. If you are starting from zero, the ISO 42001 Foundation course gives the team a shared vocabulary, and the AI security management (AAISM) course connects the Act's cybersecurity and robustness obligations to the security program you already run. Pick the role nearest your gap and build outward from there.
Frequently asked questions
01Is my AI system high-risk?
Annex III lists eight categories of high-risk AI systems: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential public and private services, law enforcement, migration and border control, justice and democratic processes. Plus AI systems that act as a safety component or product covered by EU harmonised legislation (Annex I).
If your system fits one of those categories, it is high-risk. There is a narrow exception under Article 6(3) when the system performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing the human assessment, or is a preparatory task. Document the exception; the supervisor will ask.
02When does the AI Act apply?
Phased application. The prohibitions (Article 5) and AI-literacy obligations apply from 2 February 2025. The GPAI obligations apply from 2 August 2025. The bulk of the high-risk obligations apply from 2 August 2026. Specific high-risk obligations relating to systems already on the market and to systems falling under Annex I apply from 2 August 2027.
Practical implication: if you place a high-risk system on the EU market in 2026, the bulk of Chapter III obligations applies. Start the conformity assessment work now.
03What does the conformity assessment look like?
For most high-risk systems, internal control conformity assessment under Annex VI. The provider declares compliance themselves, based on: a quality management system, technical documentation per Annex IV, post-market monitoring, registration in the EU database.
For certain high-risk systems (notably biometric identification systems), a third-party notified body must be involved (Annex VII). CE marking and an EU declaration of conformity follow.
04What is the role of ISO/IEC 42001?
ISO/IEC 42001 is the international standard for AI management systems (AIMS), published in late 2023. It is the AIMS equivalent of ISO 27001's ISMS. The standard does not satisfy the AI Act on its own, the Act has product-specific technical requirements, but it provides the management-system foundation that auditors and notified bodies will recognise.
A typical readiness path: ISO 42001 Lead Implementer to build the AIMS, then map the AI Act high-risk obligations onto the AIMS controls, then run the conformity assessment for each in-scope system.
05What about general-purpose AI models?
Articles 51-56 govern providers of general-purpose AI models. Baseline obligations: technical documentation, information for downstream providers, policy on copyright compliance, summary of training data. Systemic-risk GPAI models (currently those with cumulative training compute above 10^25 FLOP) face tighter obligations including model evaluation, systemic risk assessment and mitigation, incident reporting.
The AI Office at the European Commission issues a code of practice clarifying the GPAI obligations. Most non-frontier providers adhere to the code rather than negotiate compliance from first principles.
