A product manager opens the EU AI Act for the first time, finds "high-risk" in Article 6, decides her hiring tool is clearly not high-risk, ships it, and only later discovers that recruitment and candidate selection sit in Annex III — the list of high-risk uses — by name. Nothing about her reading was lazy. She simply read one article in isolation, which is exactly how almost everyone starts learning AI regulation, and exactly why so many people finish a course on the subject still unable to classify their own system.
The topic is deceptively large: the EU AI Act, the US Executive Order on AI, the OECD AI Principles, the UNESCO Recommendation on AI Ethics, ISO/IEC 42001, the NIST AI Risk Management Framework, the Council of Europe Framework Convention on AI. Each is a different kind of document with a different legal weight. The most common failure is not ignorance of any single one — it is treating them as one big pile of "AI rules" and learning them in the wrong order.
Mistake one: memorising documents instead of learning what kind of document each one is
Here is the distinction that changes everything, and that beginners routinely skip. The EU AI Act is a regulation: binding, with obligations and penalties. The US Executive Order is an instrument of executive policy — it directs federal agencies rather than creating duties you can be sued over directly. The OECD AI Principles and the UNESCO Recommendation are soft law: they shape expectations, procurement language and public policy, but nobody fines you for them. ISO/IEC 42001 is a certifiable management-system standard — an auditable way of running AI governance. The NIST AI Risk Management Framework is voluntary guidance, structured around govern, map, measure and manage.
Why does this matter in practice? Because a compliance plan built on the wrong category of document is either overbuilt (spending months on controls nobody requires) or underbuilt (telling a board "we follow OECD principles" when a binding regulation applies to your product). The first skill in AI regulation is sorting documents by legal weight, not memorising their contents. More on the topic: “IT Legal & Compliance: What Developers Get Wrong About GDPR, Licenses and IP — and How to Choose Your Path”.
Mistake two: classifying the technology instead of the use
People ask "is our model high-risk?" The question is wrong. Under the EU AI Act, risk attaches to the intended purpose and context of use, not to the model's size or architecture. The same language model is low-risk as a marketing copy assistant and high-risk when it screens job applicants, scores creditworthiness, or supports medical triage.
A walkthrough makes this concrete. Imagine a team building an internal assistant that summarises customer support tickets. Step one: write down the intended purpose in one sentence — "summarise inbound tickets for human agents." Step two: check that purpose against the Annex III categories (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice). Summarising tickets is not on the list. Step three: check whether the output feeds a decision about a person — here, no; a human agent reads the summary. Step four: check transparency duties — if the system interacted with end users directly, disclosure obligations could apply. The answer is not "our model is X," it is "this use, in this context, with this output, is Y." More on the topic: “Personal Data Protection: A Step-by-Step GDPR and CCPA Compliance Checklist for Founders and Marketers in 2026”.
Change one variable — let the same assistant auto-draft rejection letters — and the classification shifts, because now it touches an employment decision. Same model, different use, different obligations. That is the mechanism, and it is the thing a course on AI regulation has to drill, not just describe.
Mistake three: reading the EU AI Act without a map of the other frameworks
A practitioner dealing with a global product rarely faces a single regime. A useful mental model is layered:
| Layer | Examples | What it governs |
|---|---|---|
| Binding law | EU AI Act, GDPR, US state AI laws | Duties, penalties |
| Policy direction | US Executive Order on AI | Agency priorities, federal posture |
| Standards (certifiable) | ISO/IEC 42001 | Management system, auditability |
| Standards (voluntary) | NIST AI RMF | Risk process design |
| Ethical principles | OECD AI Principles, UNESCO Recommendation | Values, procurement, public expectations |
The mistake is starting from the bottom of this table (ethics) and hoping it satisfies the top (law). It won't. The other mistake is starting from the top and ignoring the middle — which is where ISO/IEC 42001 earns its keep, because a management system is how you demonstrate, repeatably, that you are governing AI rather than just asserting it.
If your product also carries CE marking under EU technical regulations, the conformity file is being rewritten by the AI Act in ways that surprise teams who treated the two as unrelated. More on the topic: “CE Marking and EU Technical Regulations — Product Compliance: How the AI Act Rewrites the 2026 Conformity File”. More on the topic: “HIPAA Compliance: US Healthcare Privacy and Security — How the Privacy Rule, Security Rule and Breach Notification Actually Work (and Where Beginners Get Stuck)”.
Mistake four: confusing AI governance with information security
Teams with an ISO 27001 habit assume AI governance is the same animal with a new label. It isn't. ISO 27001 protects information assets — confidentiality, integrity, availability. ISO/IEC 42001 governs how an organisation develops and uses AI: risk assessment of AI systems, roles and responsibilities, data governance, transparency, monitoring of model behaviour over time. The overlap is real (both want documented processes and management review), but the objects differ. A company can be perfectly ISO 27001 certified and still have no answer to "who signed off on this model's intended purpose?" More on the topic: “GDPR (EU Data Protection): What Data Processing Principles Actually Demand — A Hands-On Breakdown”.
This is where self-study tends to stall. The standards are readable, but the mapping between them is not obvious from any single text, and there is nobody to check whether your mapping is right. More on the topic: “ISO 27001 vs SOC 2: How to Choose the Right Cybersecurity Standard for Your SaaS (and Why It Matters)”.
Mistake five: learning alone and never testing a classification against anyone
The pattern repeats. Someone reads the Act, builds a spreadsheet, classifies their systems, and feels confident — until a colleague asks a question that exposes a gap: what about the general-purpose model we fine-tuned, what about the vendor's system we integrate, what about the pilot we ran last quarter and shut down? Regulation is full of situations that look like edge cases until you meet them.
A concrete example of where solo learning breaks: a team integrates a third-party hiring tool. Who is the provider and who is the deployer under the Act? The answer changes the obligations entirely — and it is not something you can derive reliably from a single afternoon with the text. Feedback on your own classification is the bottleneck, not access to information.
Which learning path actually fits you
There are three realistic routes, and they differ in what you pay and what you get.
Self-study. Free to cheap. You read the official texts, the standards, and public guidance. You gain breadth and a feel for the vocabulary. You pay in time and in the absence of correction: no one tells you that your classification is wrong until an auditor does.
Practice inside a real compliance project. Fastest learning curve, highest stakes. You learn by doing, with colleagues to check your work — but you can only take this route if such a project exists where you work, and mistakes are made on live products.
A structured course. A middle path: someone has already sequenced the documents by legal weight, walks through classification with examples, and gives you a place to test your reasoning. The cost is money and the discipline of following someone else's order rather than your own curiosity.
A reasonable sequence for most people: get the vocabulary from a structured source first, then apply it to your own product, then use self-study to go deep on the one regime that actually binds you. Doing it in the reverse order — deep-diving the Act before understanding how it relates to ISO/IEC 42001 and the NIST AI RMF — is how people spend weeks and still can't answer a board question.
Who this suits, and who it doesn't
This path rewards people who will actually use it: product and compliance managers at companies deploying AI in the EU or selling to EU customers, founders preparing for procurement questionnaires, engineers who need to know what documentation their system requires, and legal or risk staff moving into AI.
It suits you less if you want to build models rather than govern them — the technical depth here is about obligations, not architectures. It also suits you less if your organisation has no AI systems and no plans for any; the material is dense and the value is in application. And if you only need a one-line answer to "does the Act apply to us?", a course is overkill — read the scope provisions and move on.
What to do this week
Pick one AI system you actually use or build. Write its intended purpose in a single sentence. Check that sentence against the Annex III categories. Note whether the output feeds a decision about a person. Then ask who the provider and deployer are. If you can answer all four without hedging, you already think like a practitioner. If you can't, that gap is the whole point of structured learning — and it is exactly the gap a course closes by walking through classification with worked examples and letting you check your reasoning against feedback rather than against your own confidence.
The course AI Regulation: EU AI Act & Global Standards covers the EU AI Act, the US Executive Order, the OECD AI Principles, the UNESCO Recommendation, ISO/IEC 42001, the NIST AI RMF and the Council of Europe Framework Convention, with lessons adapted to your level. Start with the one system on your desk and classify it properly.