Most SaaS AI features are not high-risk under the AI Act. Hiring and credit tools need a check.

Picture an applicant-tracking product that adds a button turning a candidate's application into five bullets for the hiring manager. A prompt, an API call, a card in the UI. Then a customer's procurement team asks a question the deal now waits on: is that system high-risk under the EU AI Act? If the answer is yes, the company owes a formal safety and documentation regime before it can sell the feature in Europe. Most AI features never get near that, and I picked a hiring example because it is one of the harder calls.

That question has two plausible answers and no obvious one. This cannot be high-risk, because it writes summaries. Or anything touching hiring must be. I think both instincts are worth ignoring, because the AI Act does not decide this by weighing how consequential a feature feels. It decides it with a closed list of eight areas, so the way to settle the argument in that room is to read the list rather than keep arguing.

What makes an AI system high-risk under the AI Act?

There are two routes in, and a system has to arrive by one of them.

The first is Article 6(1), which catches regulated products rather than features. It covers a system that is either built into a product covered by the EU product-safety laws listed in Annex I, or that is such a product in its own right, where that product must be assessed by an independent body before sale 1. Lifts, machinery, toys. It also catches software that is itself a regulated medical device, so if you sell clinical software this route is yours and it needs proper advice. Everyone else can move on to the second one.

One thing to settle before either route. These duties land on the provider, meaning whoever puts the system on the market under their own name. If you ship the feature inside your own product, that is you, even when the model underneath belongs to somebody else. If you merely use a vendor's hiring AI inside your company, you are a deployer, your obligations are a different and lighter set under Article 26, and the rest of this post is not addressed to you.

That second route is Article 6(2): the system falls in one of the eight areas listed in Annex III 1. Those eight are the whole list, and they are worth reading once rather than paraphrasing from memory:

Everything outside those eight areas and outside Annex I product law is not high-risk. That is not the same as unregulated. Article 5 bans a short list of uses outright at any tier, among them social scoring and inferring emotions in a workplace or a school, and the Article 50 duties below apply broadly too. What falls away is Chapter III, the heavy regime of conformity assessment, risk management and post-market monitoring that procurement questionnaires are really asking about. The Commission's own timeline page puts the vast majority of AI systems used in the EU in a minimal-risk tier it introduces no rules for at all 4.

Which of the eight areas catch an ordinary SaaS product?

In my reading, four of them. Employment reaches recruitment and workforce tools. Essential services reaches credit scoring and life and health insurance pricing. Education reaches admission and grading. And critical infrastructure is the one I would not skip on the strength of its name, because its first words are "critical digital infrastructure" 2. It is not only water and electricity: if your software helps run a data centre, a telecoms network or a utility, read that entry properly rather than assume it means pipelines. The remaining four cover policing, migration, courts and biometric surveillance, and a normal B2B product does not wander into those by accident.

The test is what the system is intended to be used for, not which industry sells it. Annex III point 4(a) covers systems intended for "the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates" 2. A summariser aimed at hiring managers reading applications is pointed squarely at that sentence. The identical model summarising support tickets is pointed nowhere near it. The technique is the same in both products, and the classification still differs, because Annex III asks what the system is for rather than how it was built.

The borderline cases are genuinely hard, and the Commission knows it: in May 2026 it published draft guidelines on classifying high-risk AI systems with worked examples on both sides of the line. They are still in draft, so if your feature sits close to an Annex III area, read the examples rather than the summaries.

Your feature is in one of the eight areas. Is it automatically high-risk?

No. Article 6(3) is a way back out: a system named in Annex III is not high-risk where it "does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons" 1. To use it, the system has to meet at least one of four conditions 1:

• (a) it performs a narrow procedural task
• (b) it improves the result of a previously completed human activity
• (c) it spots patterns in past decisions, or departures from them, and is not there to replace or sway the human decision that was already made
• (d) it performs a preparatory task to an assessment

Condition (c) carries a catch: it only holds if a person properly reviews what the system flagged. A tool that feeds "three of your last ten hires look like outliers" straight into a decision nobody re-checks has failed it.

One sentence overrides all four. A system in an Annex III area "shall always be considered to be high-risk where the AI system performs profiling of natural persons" 1. Profiling is worth pinning down, since it is what makes the exemption unavailable. Article 3(52) borrows the GDPR's definition 5: automated processing of personal data to evaluate personal aspects of someone, such as performance at work, reliability, interests or behaviour. Scoring a candidate on likely job performance is profiling. Counting how many applications arrived on Tuesday is not.

Take the applicant summariser through it. Condition (d) is the plausible route: the hiring manager makes the assessment, and the summary prepares them to make it. That reading survives as long as the feature only compresses text the human was going to read anyway. It stops surviving the moment the summary ranks candidates against each other, scores them, or highlights some applications and buries others, because at that point the feature is doing the evaluation rather than preparing it. Adding a ranked list moves the product from one side of that line to the other. A classification is a claim about what the feature does, so it stops being true when the feature changes.

What does claiming the exemption cost?

Two obligations a product outside the eight areas never acquires.

Article 6(4) requires a provider who concludes its Annex III system is not high-risk to document that assessment before the system goes on the market 1. Article 49(2) then requires that provider to register itself and that system in the EU database 3. The exemption is public: concluding you are out of scope is recorded in the same database as the systems that are in it.

The rules therefore produce three positions. Outside the eight areas, you owe nothing here. Inside an area but out under Article 6(3), you owe a written assessment and a database entry. Inside an area without it, you owe the full high-risk regime. I think the middle one gets overlooked because it feels like a negative result, and a negative result does not feel like something you file. It gets noticed when a customer asks for the registration number.

Do the deadlines that moved in 2026 change any of this?

They change when the obligations bite, not which tier you are in. In July 2026 the EU passed an amending law, the Digital Omnibus on AI, that pushed both high-risk start dates back: the Annex III areas now apply from 2 December 2027, and AI built into regulated products from 2 August 2028 4. So the delay bought time on the high-risk regime and none on the question of whether you are in it. I would not treat December 2027 as the date this starts mattering, because the assessment is cheapest to write while the people who built the feature still remember why, and procurement asks long before a regulator does.

The transparency rules run on a separate clock and are mostly behind us: Article 50 has applied at every risk tier since 2 August 2026, with one narrow extension to 2 December 2026 for marking AI-generated content in systems that were already on sale 6. I went through what Article 50 asks of a product team separately, along with the three disclosures an AI feature adds to your privacy policy.

What should you do with the feature you shipped last week?

Start by writing one sentence saying what the system is intended to be used for. Not what it is, which is a summariser, but what it is for, which is helping a hiring manager evaluate candidates. The second version is the one Annex III responds to.

Now read that sentence against the eight areas 2. Most features stop right here, and if yours is one of them your whole task is to write that down: one paragraph naming the feature, the purpose you just wrote, and the areas you checked it against. That paragraph answers what a procurement questionnaire is really asking, and having it ready is the difference between answering in the call and stalling the deal.

If you sell software with an AI feature that touches hiring, education, credit, insurance or biometrics, you have more to do: decide which side of Article 6(3) your feature sits on and write that reasoning down too, or the first enterprise customer to ask will get an answer somebody improvised on a call. Take it through the four conditions, check whether anything in the pipeline profiles people, and keep the reasoning next to the feature. The Commission's own AI Act Service Desk runs a free Compliance Checker over the same questions.

Then decide what catches the next change, because the note you just wrote has a shelf life. The summariser that qualified under condition (d) stops qualifying the week someone adds a ranked list, and nobody rereads Article 6(3) during that pull request. Lawcel is the product we build for that job: it reads each change in your GitHub, Linear or Jira against a record of what your product does with personal data, and tells you when the two have stopped agreeing, while the change is still a pull request. A ranked list added to a summariser is exactly the shape of change it is looking for, because a feature that starts scoring people changes what your documents have to say. It will not decide your risk tier for you, and software claiming to would be worth distrusting. It will tell you when the answer you wrote down last quarter no longer describes what you ship.