Article 6(3)(d) explained: the preparatory-task carve-out

Article 6(3) of the EU AI Act is one of the most consequential clauses for SaaS startups that ship AI features. It lets a system that would be high-risk under Annex III escape the classification — and the full Chapter III provider obligations — if it does not pose a significant risk of harm. Path (d) of the four exceptions is the one most SaaS products end up under.

Misreading this clause is expensive in both directions. Read it too generously and you under-classify a system that should carry the full Article 9–15 obligations. Read it too conservatively and you spend two quarters meeting requirements that don’t apply. This guide walks through what Article 6(3)(d) actually says, when it applies, and what to write down.

What Article 6(3) says — the four paths

Article 6(3) reads (lightly paraphrased): an AI system referred to in Annex III shall not be considered high-risk where it does not pose a significant risk of harm to health, safety, or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making. Specifically:

• (a) the AI system is intended to perform a narrow procedural task
• (b) the AI system is intended to improve the result of a previously completed human activity
• (c) the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review
• (d) the AI system is intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III

If any of these is true, the system falls out of high-risk — assuming the additional condition below is met.

The hard backstop — profiling persons

Paragraph 3 of Article 6 includes a sharp limitation:

The exceptions referred to in the first subparagraph shall not apply where the AI system performs profiling of natural persons.

This is the line that disqualifies most B2B HR tools, credit-decisioning models, and education-grading systems from using the carve-out. If your system produces a profile of an individual — scores them, ranks them, categorises them — Article 6(3) does not save you.

When path (d) applies — the preparatory-task test

The “preparatory task” path is meant for AI systems that prepare information that a human then uses to make the substantive Annex III decision. The Recital text (Recital 53) gives the example of a tool that does file management, document drafting, or translation that supports a human assessment.

The key elements of a valid (d) claim:

1. The Annex III decision is made by a named human, not the AI
2. The AI’s output is a draft, recommendation, or summary — not the final answer
3. The human’s review is substantive, not rubber-stamping
4. The system does not profile individuals

This is exactly the architectural posture Maditon itself adopts: the AI drafts a risk classification, a named human in the customer’s organisation explicitly accepts it with a timestamp. The accepting human is on the hook; the AI prepared.

Worked examples

| System | Article 6(3)(d) applies? | Why | |---|---|---| | A SaaS that drafts EU AI Act risk classifications for a human to review and accept | Yes | Preparatory; named human accepts the final classification; no profiling of natural persons | | A SaaS that drafts interview summaries from candidate calls, for a hiring manager to read | Yes — likely | Preparatory; summary supports human decision; not profiling (no scoring) | | A SaaS that ranks job candidates by predicted fit score | No | Profiles natural persons; rank is the substantive output | | A copilot that drafts loan-decision rationale for a credit officer | Borderline | If the draft includes a score or recommendation, the credit officer’s review must be substantive enough to actually reach a different outcome — and the system shouldn’t profile applicants | | A document-management AI that tags HR files | Yes | Narrow procedural task (a) and preparatory (d) both apply; no influence on hiring outcome |

What you must document if you’re using (d)

The Act expects providers who rely on the Article 6(3) exceptions to document the assessment and register it (Article 6(4)) — they must keep the documentation available for supervisory authorities for 10 years.

For your written justification, capture:

• The intended use of the system (concrete, specific)
• Which Annex III category it would otherwise fall under
• Which of (a)–(d) applies
• Why the system does not profile natural persons
• The human acceptance design — who reviews, what they see, how acceptance is recorded
• The reviewer notes mechanism — how human judgement is captured and stored

This is your defence if a supervisory authority later challenges the classification.

What Maditon does specifically

Maditon is itself an AI-enabled tool. We rely on Article 6(3)(d). The Service prepares draft risk classifications. The classification is bound to a named user of your organisation who explicitly accepts each draft inside the Service. Acceptance is recorded with a timestamp. We do not profile your employees, your customers, or any other natural persons. The substantive determination is yours — the Service supports it but does not make it.

This is also the architecture we recommend for any SaaS product whose AI surface touches an Annex III use case. “Drafts that humans accept” is the cleanest path to staying out of the high-risk chapter and keeping your audit trail defensible.