Chapter 2. The verdict: risk classification and prohibited practices | Grigoriy Dobryakov

Grigoriy Dobryakov

Course · AI Compliance

The situation at Kompas

Ch. 1 ended with an admission: we're in scope of the AI Act. The Kompas team moves to the next question hoping for an easy answer — "how strict?" Intuition suggests something reassuring: "We're not biometrics, not facial recognition, not weapons, and not social scoring. So — minimal risk, we'll get by with a notice."

Classification gives the opposite answer. Scoring and ranking candidates in hiring is exactly the example the legislator put on the list of high-risk uses as a separate line item. Kompas turns out to be in the strictest regulated class (stricter still — only outright bans). This is the moment when a product feature stops being a feature and becomes a legal class with a multi-year tail of obligations. This chapter is about how the class is determined and why the exceptions you'd like to grab onto don't work here.

What the rule says

The risk-based approach: four tiers. The AI Act does not regulate "AI in general" — it sorts systems by risk level and assigns the regime by level. There are four tiers:

Hiring is directly named. Annex III classifies as high-risk systems intended for recruitment — in particular, for placing targeted job ads, filtering applications and evaluating candidates. Kompas's ranking of candidates falls here literally, not by an expansive reading.

The Art. 6(3) filter exception. Here hides the only hope of falling out of high-risk: a system from Annex III is not deemed high-risk if it performs a narrow procedural task, improves the result of an already completed human activity, detects deviations from prior decisions (without replacing the human) or does preparatory work — and does not significantly influence the final decision. A provider applying this exemption must document the assessment and still register. The temptation "we just sort a list" shatters against the word "significantly": a system that ranks candidates and thereby determines whom the recruiter sees first at all influences the decision significantly.

Dates (current as of September 2026). The Art. 5 bans and the GPAI regime — from 02.08.2025; Art. 50 transparency and supervisory structures — from 02.08.2026; obligations for stand-alone high-risk (Annex III) were shifted by the "Digital Omnibus" (Regulation (EU) 2026/1744) to 02.12.2027, and for embedded high-risk (Annex I) — to 02.08.2028. The shift does not cancel the class — it cancels the illusion that there's no time; on the trap of this shift — ch. 8.

How it lands on the product

Kompas is classified as high-risk. Ranking candidates influences the hiring decision, so the saving exception of Art. 6(3) does not apply — however much you'd like to re-describe the product as "auxiliary sorting."

The chapter's artifact is a risk classification record: a written justification of the class with a reference to the specific Annex III item and a separate analysis of why Art. 6(3) doesn't fire. This is the core of the dossier: it is the first document the auditor and the corporate client will ask for. You need to classify each AI function from the ch. 1 inventory separately — for Kompas that is at least scoring (high-risk), the chatbot (transparency, Art. 50) and email generation (transparency).

Where it breaks

Art. 6(3) is the most disputed zone in the whole law. The boundary of "significantly influences the decision" is read ambiguously, and there is little settled practice or guidance. Companies will try to squeeze everything under the exemption; the regulator will resist. Building a product strategy on the premise that you'll slip through this exception is risky.

Proximity to an outright ban. High-risk and unacceptable lie closer than they seem. If Kompas adds analysis of the candidate's emotions from a video interview, it risks touching not the high-risk regime but the ban of Art. 5 (emotion recognition in the employment context). That is not "more obligations" but a stop-line for the feature.

Multi-class within one product. A single product has several classes at once: scoring — high-risk, chatbot — transparency. Treating "the product as a whole is high-risk" and calming down at that is a mistake: part of the obligations (transparency) applies earlier by date and by a different logic.

What to do as engineer/product

Classify each AI function separately and record the justification in writing — not "the product is high-risk," but function by function with a reference to the rule. That is exactly what the classification record is.

Separately, run the product and the roadmap against Art. 5: does any current or planned feature (emotions, biometric categorization) creep into the prohibited zone. There you need not compliance but a decision — "we don't do it."

Provocation

Classification is not a bureaucratic formality at the entrance, but the point at which a product feature turns into a legal class with obligations for years ahead. Teams spend months on how the system ranks candidates and ten minutes on the question of which risk class that lands them in — even though it's the class, not the quality of the ranking, that will determine their architecture, documentation, processes and cost for the next several years.

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 →