Manifesto: compliance is a design constraint, not a check at the end | Grigoriy Dobryakov

Grigoriy Dobryakov

Course · AI Compliance

ManifestoAI Compliance course

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.

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:

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

  1. 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.
  1. 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.
  1. 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:

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 me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →