← auditaisdk.com · All articles
If you read the EU AI Act top-down, you reach Annex III, see eight categories of "high-risk" AI, recognise your own product somewhere in the list, and start panicking. Hiring, education, biometrics, critical infrastructure, employment monitoring, law enforcement triage — most B2B SaaS products touch at least one.
That first reading is wrong by design. Article 6(3) was added precisely so that not every Annex III use case is high-risk. The Commission drafted the filter because regulators understood that a product which classifies incoming support tickets is not the same risk profile as a product which decides whether someone gets fired. Both can theoretically fall under "employment, workers management" if you read Annex III #4 in isolation. Article 6(3) makes the legal distinction explicit.
The practical effect is dramatic. A correctly drafted Article 6(3) assessment converts a 4–8 week Annex IV file, a CE marking process, a conformity assessment and an EU database registration into a one-page memo plus a much lighter database entry. It is the difference between treating compliance as a product blocker and treating it as a paperwork exercise your back office handles in a week.
This article is a deep dive on the four sub-paragraphs. If you have not read the high-risk classification decision tree yet, start there — Article 6(3) only matters after you have determined that your use case is in Annex III. The tree gets you to that decision.
Article 6(3) of Regulation (EU) 2024/1689, as amended by the May 2026 Omnibus, reads (paraphrased for clarity — the legal binding text is the Official Journal version):
However, an AI system referred to in Annex III shall always be considered high-risk where it performs profiling of natural persons.
That last sentence is the trap. We will come back to it. First, the four sub-paragraphs.
Plain meaning: the system performs a single, well-defined operation that is purely procedural — it sorts, routes, labels, normalises, deduplicates, formats. The output is not a judgement about a person; it is a step in a workflow.
The test: ask "if I removed this AI tomorrow, would the underlying assessment still happen?" If yes, and the AI was doing pre-organisation work, you are in (a) territory.
Your product ingests incoming employee documents (sick leaves, vacation requests, expense claims) and routes each to the right HR specialist. The routing model classifies the document into one of twelve folders. No decision about the employee is taken; a human always reads the document and decides next steps.
Annex III check: #4 (employment, workers management). Routing is part of "workers management" in a broad reading. So Annex III may apply.
6(3)(a) analysis: the model performs a narrow procedural task — classification into folders. It does not influence the outcome of any assessment regarding the worker. Filter applies.
Law firms upload contracts to your platform. Your model detects duplicate clauses across thousands of NDAs and tags them, so lawyers do not redraft the same boilerplate twice. The model never recommends a clause; it only flags repetition.
Annex III check: #8 (administration of justice and democratic processes) is sometimes raised by enterprise legal teams for legal-tech, but Annex III #8 is narrowly about "assisting a judicial authority in researching and interpreting facts and the law and in applying the law to a concrete set of facts". A private-sector contract dedup tool is not assisting a judicial authority. Annex III does not apply at all. Filter analysis becomes moot.
Same HR-tech SaaS, but the model also assigns a priority score to each incoming document (1 to 5) based on content. The score is shown in the HR specialist's queue. Now the model is influencing the order in which workers' issues are handled. That is not a "narrow procedural task" anymore — the score is a substantive judgement that shapes managerial decisions.
Result: 6(3)(a) does not apply. You either move to another sub-paragraph or accept high-risk classification.
Plain meaning: the human did the actual work first; the AI polishes, rephrases, formats, summarises, translates or augments the output. The substantive judgement was made by a person before the AI saw it.
The test: ask "could the human ship the output without the AI?" If yes, and the AI is making the existing output better/clearer/shorter/translated, you are in (b) territory.
A recruiter writes a 200-word interview feedback note. Your AI polishes the prose, fixes grammar, suggests a clearer phrasing for the hiring committee. The recruiter accepts or rejects each suggestion. The recruiter's substantive judgement on the candidate was made first.
Annex III check: #4 (employment) is in play because feedback notes influence hiring decisions.
6(3)(b) analysis: the AI is improving the result of a previously completed human activity (writing the feedback). The judgement was the recruiter's. Filter applies.
A lawyer writes a clause; your AI suggests three reformulations for clarity. The lawyer picks one. The clause's substantive content (what protection it gives, what risk it allocates) was the lawyer's call.
Annex III check: #8 is again sometimes raised; same answer — not assisting a judicial authority, so Annex III does not apply directly. Even if a customer argues it does (some procurement teams will), 6(3)(b) applies cleanly.
The recruiter writes "I am leaning toward candidate A, but want a second opinion." Your AI returns "Based on the candidate profiles you uploaded, I recommend candidate B because…" Now the AI is making the substantive judgement, not improving a completed one. The recruiter's "previously completed activity" was an open question, not a decision the AI is polishing.
Result: 6(3)(b) does not apply. The system is influencing the hiring outcome, which is exactly what Annex III #4 is meant to capture.
Plain meaning: the system looks at past human decisions and flags inconsistencies, outliers or new patterns — but a human reviews each flag before any action is taken. The AI is a quality-control layer over human judgement, not a replacement for it.
The test: ask "does the AI's output trigger any change without a human review step?" If no, and the AI is highlighting patterns in prior human decisions for human consideration, you are in (c) territory.
A finance SaaS reviews historical expense approvals across a company. The model flags expense claims that look unusual compared to prior approval patterns (amount, category, frequency). A finance manager reviews each flag. No claim is automatically rejected; the AI never communicates with the employee.
Annex III check: #4 (workers monitoring) can be argued by a cautious legal team.
6(3)(c) analysis: the model detects deviations from prior human decision-making patterns (which expenses were historically approved) and surfaces them for human review. The previous human assessments are not replaced or influenced without that review step. Filter applies.
Same finance SaaS, but the model now auto-rejects any expense flagged as anomalous and only escalates to a human if the employee disputes. The previous human pattern is being replaced — the rejection is automatic, not subject to proper human review before it affects the worker.
Result: 6(3)(c) does not apply because the system replaces the human assessment without proper review. High-risk under Annex III #4.
Plain meaning: the AI prepares material that a human will subsequently evaluate. Transcription, summarisation, translation, OCR, indexing — work that has to happen before someone can sit down and assess the case.
The test: ask "does my output go directly to a decision, or does it go to a human who then makes the decision?" If the latter, you are in (d) territory.
Your AI transcribes recorded job interviews and produces a clean transcript with speaker labels. A recruiter reads the transcript and decides on the candidate. The AI never scores the candidate, never produces a recommendation.
Annex III check: #4 (employment) is in play. The transcript informs hiring decisions.
6(3)(d) analysis: the model performs a preparatory task — making the recording readable — before the relevant assessment by the recruiter. Filter applies.
A recruiter dashboard summarises each CV into a four-bullet overview. The recruiter reads the bullets, then opens the full CV before deciding. The summary does not rank or score candidates.
6(3)(d) analysis: preparatory task — making 200 CVs scannable. The recruiter still does the substantive review. Filter applies.
Same CV product, but the dashboard sorts the 200 CVs by an AI-generated "fit score" before the recruiter sees them. Practically, recruiters look at the top 20 and never reach the rest. The AI is no longer preparatory — it is making a de facto first-round selection.
Result: 6(3)(d) does not apply. The system is influencing which candidates get human attention. High-risk under Annex III #4.
Profiling has a specific GDPR definition (Article 4(4)): "any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements."
Three lessons for B2B AI startups:
The profiling rule is why "AI ranks candidates" almost always ends up high-risk regardless of how the vendor describes the workflow. Ranking is, by definition, a per-person evaluation of personal aspects.
The filter is not a "do nothing" outcome. It is a "do less" outcome with two specific obligations.
You must keep, for ten years from placing the system on the market, a written record of why the filter applies. The record must be available to national competent authorities on request and must be updated on any substantial change. The format is not prescribed, but it should answer five questions:
Even with the filter applied, you must register the system in the EU database for high-risk AI systems before placing it on the market. The entry is shorter than a full high-risk registration but still public. Required fields include the provider identification, the system name, a description of the intended purpose, the Annex III use case the system relates to, the Member States where the system is placed on the market, and a reference to the 6(3) assessment.
The Commission has clarified that 6(3) registrations are subject to a confidentiality regime for information whose disclosure would be against public security or commercial interest (Article 49(4))— but the existence of the entry itself is public.
The memo is what enterprise procurement actually wants. It is short, signed, and dated. Below is a structure that has worked for every managed audit we have shipped.
EU AI ACT — ARTICLE 6(3) FILTER ASSESSMENT
System: [product name]
Provider: [legal entity, EU representative if applicable]
Intended purpose: [one paragraph — what the system does, who deploys it,
what decision it informs, where the human sits in the workflow]
1. ANNEX III SCOPE
- Annex III category matched: [#1–#8, with citation]
- Reason for superficial match: [one paragraph]
2. ARTICLE 6(3) SUB-PARAGRAPH(S) RELIED ON
- Sub-paragraph: [a / b / c / d, citing the regulation]
- Workflow description: [where the AI sits, what it outputs, where the
human reviews or completes the assessment]
- Why the system does not pose a significant risk of harm to health,
safety or fundamental rights: [one paragraph, evidence-anchored]
3. PROFILING ASSESSMENT
- Does the system profile natural persons (GDPR Art. 4(4))? [Y / N]
- Reasoning: [one paragraph — what personal data is processed, what
outputs are generated per person, why these outputs do not amount
to profiling within the meaning of GDPR Art. 4(4)]
4. SUBSTANTIAL CHANGE TRIGGER
- This assessment will be reviewed if any of the following changes:
(i) the AI's output transitions from preparatory to substantive
(ii) automated decisions begin to affect natural persons without
proper human review
(iii) per-person scoring is introduced
(iv) the Annex III category in scope is amended by EU legislation
5. RETENTION
- This memo will be kept for ten years from the date the system is
placed on the market, in accordance with Article 6(4).
6. REGISTRATION
- The system has been / will be registered in the EU database for
high-risk AI systems under Article 49(2). Registration ID:
[insert when available]
Signed: [name, role]
Date: [YYYY-MM-DD]
Counsel reviewed: [name, firm, date — if applicable]
The auditai managed audit produces exactly this memo, reviewed against the consolidated Regulation text and your actual product behaviour. The output is a PDF your customer's legal team can attach to their own file without modification.
The €199 managed classification audit walks your product through the decision tree, drafts the 6(3) analysis if relevant, and returns a signed memo your enterprise customer's legal team can accept directly. Includes the registration data you need for Article 49(2).
Get the 6(3) memo →These are the patterns we see most often where founders incorrectly believe 6(3) applies. Each is a high-risk classification disguised as a filter case.
| Pattern | Why the filter fails | What to do |
|---|---|---|
| "Our AI ranks candidates but a human picks." | Ranking is per-person evaluation — profiling. Plus, the top of the rank gets human attention, the bottom does not, so the AI is the de facto first-round selector. | High-risk Annex III #4. Treat as such. |
| "Our AI auto-approves below €X and escalates above." | Auto-approval is an automated decision, not a preparatory or polishing task. The "previously completed human activity" does not exist. | High-risk (Annex III depends on domain). |
| "Our chatbot answers HR questions, that's procedural." | Procedural until the chatbot starts giving advice on disciplinary, grievance, or termination matters. Then it is shaping outcomes. | Scope the chatbot or accept high-risk for the relevant flows. |
| "We score creditworthiness for businesses — that's not consumer credit." | This is not a 6(3) issue. Annex III #5 only covers natural persons. B2B credit is outside #5 entirely; filter analysis is unnecessary. | Document that Annex III does not apply and move on. |
| "Our anomaly detector auto-blocks transactions." | Auto-block bypasses human review. 6(3)(c) requires "proper human review" before action. | Either add a human-review step or accept high-risk. |
| "Our copilot suggests salary bands." | Salary recommendation is a substantive judgement that materially influences worker compensation outcomes. | High-risk Annex III #4. |
| "Our AI does facial recognition, but only as preparation." | Biometric identification is governed by Annex III #1 and largely cannot be carved out by 6(3) because the categorisation itself is the substantive output. | High-risk — and possibly prohibited (Article 5) in some uses. |
From the managed audits we have shipped in the last twelve months, enterprise procurement reactions cluster into three patterns:
The one pattern that never works: handing procurement a vague statement like "we believe we are not high-risk." Legal teams will ask you to prove it, and without the structured memo, the burden of proof falls on you each time. The memo industrialises the answer.
Article 6(3) decides whether you need the full Annex IV technical file. If the filter applies, you do not need to produce the Article 11 / Annex IV documentation, you do not need Article 9 risk-management documentation, you do not need to obtain CE marking via conformity assessment, and you do not need to wait for the December 2027 high-risk applicability date to ship anything.
What you still need:
The auditai SDK is built so that even systems carved out by 6(3) have logged inference records on hand. Procurement asking "show me a sample of how decisions are logged" is the modal request after the memo is accepted — and you cannot retroactively produce Article 12-style logs you did not capture.
No. Article 6(4) only requires the provider to document and keep the assessment. Counsel review is recommended for borderline cases (especially around the profiling rule) but not required. The managed audit ships the memo signed by the auditai team; many customers then have their own counsel countersign or simply file it as is.
You can comply contractually with whatever they ask. Many enterprise customers default to "treat as high-risk" in their internal policies regardless of the regulation's classification. In that case you ship them an Annex IV-light file (SDK logs + data governance summary + classification memo) and let the customer's risk register decide their own treatment. The filter analysis is still legally accurate; the customer's internal policy is a separate question.
It does not. Article 6(3) is about whether your application is high-risk under Annex III. GPAI obligations (Article 53) apply to providers of general-purpose AI models, and the obligations sit upstream with the model provider. If you use a third-party GPAI in your product, your obligations relate to your application's classification under Article 6, not to the GPAI rules.
You must re-classify under Article 6 and treat the system as high-risk going forward. The change is a "substantial change" under Article 3(23) and triggers obligations from the date of the change. Practically, document the trigger date in your assessment memo and start the Annex IV file immediately.
National competent authorities can request the documentation and re-classify the system if they disagree. The Commission has issued guidance (most recently the May 2026 Omnibus accompanying guidelines) that clarify the boundaries of each sub-paragraph but does not pre-approve individual filter assessments. The defensibility of your memo is therefore based on (i) the regulation text, (ii) the Commission guidance, and (iii) the factual accuracy of your workflow description.
No. The Act treats SMEs and start-ups with several proportionality measures (Article 62 simplified procedures, regulatory sandbox access, lower fees) but does not exempt them from Article 6 classification. Whether you are high-risk depends only on Annex III and the 6(3) filter, regardless of company size.
The Commission published the May 2026 Omnibus accompanying guidelines alongside the delay of the Annex III applicability date to December 2027. The guidelines include specific clarifications on each 6(3) sub-paragraph. We track each guidance update in the 2026 deadlines post and update this article on substantial change.
Disclaimer: this article is informational and does not constitute legal advice. The Article 6(3) memo produced by the auditai managed audit is reviewed against the consolidated text of Regulation (EU) 2024/1689 as amended by the May 2026 Omnibus and the accompanying Commission guidance. For binding legal interpretation in your jurisdiction, consult qualified counsel.