Manifesto: compliance is a design constraint, not a check at the end
There are two ways to meet AI regulation. The first — build the product, then hand it to a lawyer "to check for conformity." The lawyer opens the EU AI Act, finds that candidate scoring is a high-risk system, and tells the team it needs a risk management system, technical documentation, human oversight and registration in the EU database. By that point the architecture, the data and the roadmap are already fixed — and conformity turns into either theater (a folder of documents assembled for the audit date) or an expensive rework under deadline pressure.
The second way — learn the product's regulatory class at the input and design from it. Then "we need human oversight" is not a surprise before release, but a line in the requirements alongside "we need authorization." This course is about the second way. The thesis is simple and hard: the regulatory class of an AI system is an input design constraint, not an output check.
What AI compliance is, in plain words
No jargon: AI compliance is the answer to three questions about your AI system.
- Am I in scope of regulation, and which one? Not all AI is regulated the same way. The law looks not at whether the product is "smart," but at what it does to people: selects people for jobs, scores credit, makes a diagnosis — or just drafts emails.
- What does it include? If the system falls into a strict class — which concrete list of duties is on me: what documents, what processes, what human control, what reporting.
- How do you prove it? To the regulator, the auditor, the corporate client in an RFP — that the system actually operates within bounds, not that you promised it in a slide.
An analogy: food production. No one is surprised that a restaurant kitchen must follow sanitary rules, keep logs, pass inspections — because health risk to people runs through the food. AI compliance is the same thing for AI systems that make or prepare decisions about people: risk now runs through them, and rules have appeared that acknowledge it.
It matters what compliance is not. It is not "ban AI" and not endless bureaucracy for the sake of paper. On the contrary: a clear regulatory class accelerates the team — because it removes uncertainty. The worst thing is not a strict regime, but an unknown one, when no one in the company knows whether their product is high-risk or not, and the decision hangs until the first letter from a regulator or the first refusal by a corporate client to sign the contract.
Why "check at the end" doesn't work
Regulatory requirements are not about how the code behaves at runtime, but about properties of the system that cannot be added after the fact. A risk management system cannot be "written up in a week": it presupposes that you analyzed risks *while* making design decisions. Data governance cannot be produced retroactively: if the training data was collected without regard for representativeness and bias, the only honest answer to an auditor is "we don't know what this was trained on." Human oversight cannot be glued onto a finished product whose UX is built on full automation — that changes the product itself.
Compliance assembled by hand for the inspection date is a specification without an implementation. This course refuses to write such specifications. Every chapter shows how a regulatory requirement becomes a design decision on Kompas, not a line in a report.
Why the flagship is the EU AI Act
There are many regulatory regimes, and they diverge in philosophy (more on that in chapters 9–10). But the course builds its spine on the EU AI Act for three reasons:
- It is the most structured. The risk-based approach gives clear mechanics: the risk class determines the regime. It is a convenient place to learn to read regulation in general.
- It is the de facto global floor, like GDPR. Extraterritoriality means: if your AI is used in the EU — you are under it, wherever you sit. It is easier to build the product to the strictest regime and sell "AI Act ready" than to maintain different versions.
- It has teeth. Penalties are calculated from global turnover (details in ch. 8), not symbolic. That moves compliance from "desirable" to "mandatory."
The other regimes — US, UK, China, the international layer — come closer to the end, as a map of the horizon: where the industry is heading and what touches the product when it leaves the EU. Not parallel spines, but a broadening of the view through the Kompas expansion storyline.
The three principles the course stands on
- Compliance-by-design, not bolt-on. The regulatory class is determined at the concept stage and enters the requirements, rather than being discovered at a review before release. It is cheaper, and it is the only thing that scales.
- The law is a reading skill, not an outsource. Classifying a system, determining your role in the supply chain and deriving from that a list of obligations — that is something the product and engineering team must be able to do itself. An external lawyer reviews and certifies; but a team that doesn't understand its own regime can neither design against it nor argue with it.
- An honest boundary. Regulation has gray zones: disputed classifications, moving entry-into-force dates, readings for which there is not yet any practice. The "Where it breaks" section is in every chapter. A product person who knows where the rule is ambiguous is more reliable than one who believes "the law says everything unambiguously."
Provocation
Most "AI compliance" on the market is compliance theater in reverse: not building control, but building the *appearance* that the question is under control. Companies hire a consultant, get a folder of policies and consider the matter closed — until the moment a corporate client in an RFP asks for proof of conformity, and there is none, because the policies were never connected to the product. The regulator and the market have already figured this out: the EU AI Act requires not declarations but classification, documentation, logs and risk management systems; corporate procurement in the EU requires ISO/IEC 42001. A company whose compliance lives apart from the product learns about the gap at the worst moment — during a deal or an inspection.
The course is about learning earlier and designing differently.
The running case — Kompas
So that the regulatory regime assembles into one picture, rather than a scatter of disconnected requirements, the whole course runs on a single fictional product — Kompas. It is an HR-tech SaaS: it takes in a stream of resumes and applications, screens them and ranks candidates for recruiters on top of someone else's foundation model, and talks to candidates through a chatbot (application status, clarifying questions). It is sold internationally — EU, US, UK. The name is fictional so as not to confuse it with real products.
Kompas was chosen so that a single product touches every node of the EU AI Act:
- Scoring and ranking of candidates in hiring are directly named in Annex III as a high-risk use. That moves Kompas into the strictest class and pulls in almost the entire list of obligations (chapters 3–4). Hiring is a clean, undisputed example of high-risk.
- The product is built on someone else's foundation model, not its own. That raises the supply-chain question: Kompas is the provider of its own system, but the deployer of someone else's GPAI model; part of the liability is shared with the model provider (chapters 5, 7).
- The chatbot with the candidate — an AI-to-human interaction, falling under the transparency requirement (Art. 50): a person must understand they're talking to a machine (ch. 6).
- International sales — on entering the US, Kompas meets NYC Local Law 144 (a mandatory bias audit of hiring tools) and the Colorado AI Act; in the UK, a different, principles-based approach. That pulls in chapters 9–10 through the story, not as an appendix.
Kompas is a deliberately demanding example: high-risk, someone else's model under the hood, direct contact with people whose careers it affects, and three jurisdictions at once. If the compliance model works on it, it works all the more on a less risky product. Every chapter shows its node of the regime on Kompas; ch. 11 assembles them into a single operating model.
How to read the course
Chapters 1–8 — the EU AI Act along the product's storyline: from "are we in scope" to "we've proven it and we live with it." Chapters 9–10 — the world beyond the EU as a broadening of the view. Ch. 11 assembles everything into an operating model and Kompas's cross- jurisdictional matrix. The recommended order: if you need to quickly understand your risk class — read chapters 1–2; if you already know you're high-risk and preparation is urgent — chapters 3–4 and 8; if you're building on someone else's model — chapters 5 and 7. The running case Kompas runs through every chapter so the regime assembles into one picture.
Read next
Shipping an AI product under regulatory risk?
A read of your product against the EU AI Act: risk class, role in the value chain, obligations and dossier — as a design constraint on the way in, not a lawyer's check at the end.
Email meThe transition engine
Next Move Engine — the system that takes a team to an autonomous delivery loop.
Next Move Engine →