Article 6(3) Annex III systems that are not high-risk

When can an Annex III AI system skip high-risk status under Article 6(3)?

A provider holding an AI system listed in Annex III has to decide whether the Article 6(3) exemption takes it out of high-risk status. The exemption is available only if the system poses no significant risk of harm to health, safety or fundamental rights, and if it also fits one of four narrow roles: it performs a narrow procedural task, it improves the result of a human activity that is already complete, it detects decision patterns without replacing or influencing the human assessment in a way that would be harmful, or it performs a preparatory task. All four limbs must be read together with the risk test. A system that fits a narrow role but still materially affects people's rights or access to services does not qualify. The main risk this section addresses is under-classification: a provider labels a credit, hiring or education tool as low impact to avoid the high-risk duties, and the conclusion is later challenged.

The profiling override matters more than most teams expect. Under Article 6(3), an Annex III system that performs profiling of natural persons is always high-risk, whatever the other conditions show. Before relying on the exemption, the provider should check whether the system scores, ranks, classifies or predicts aspects of individuals, including as an intermediate step. Confirm this against the Commission's draft classification guidelines of 19 May 2026 and the Article 6 text on EUR-Lex rather than relying on a summary.

Relying on the exemption creates duties that have to be done before launch. Article 6(4) requires the provider to document its assessment before placing the system on the market or putting it into service, to provide that documentation to authorities on request, and to register the system under Article 49(2). The registration data is listed in Annex VIII Section B, which Regulation (EU) 2026/1744 changed by deleting the summary of grounds and the list of Member States. Ask legal counsel to confirm how the amended Annex applies to your filing. A written assessment, dated and version-controlled, with the reasoning for each limb, is what lets you defend the conclusion if a market surveillance authority evaluates the system under Article 80.

Which Annex III systems and teams fall under the Article 6(3) decision

Before an Annex III system can be treated as not high-risk, the organization has to settle several scoping questions: which use case it touches, whether it profiles people, whether it sits inside a regulated product, and who owns each input. The cards below cover the decisions that change the work and the teams that must sign off on them.

Map the Annex III use case

Start by naming the Annex III area the system touches, such as employment, credit scoring, education or access to essential services. The exemption only applies to systems within those areas, so a tool that looks generic can still fall inside one. Write down the specific use the system serves, not the product category. Confirm the exact wording of each Annex III point against the consolidated text before you rely on it.

Check for profiling of people

Article 6(3) states that an Annex III system that performs profiling of natural persons is always high-risk. Profiling covers automated evaluation of personal aspects such as work performance, economic situation, behavior or preferences. A system can use a narrow procedural step and still profile, for example when it scores applicants or ranks employees. Document how the system processes personal data and whether any output evaluates individuals before you test the other conditions.

Test for a product component

An AI system can be a safety component of a product covered by Annex I harmonisation legislation, or be a product itself. That route to high-risk status runs through Article 6(1), not Article 6(3), and it moves the timeline to the Annex I date. Ask the product or engineering owner whether the AI output feeds a regulated product's safety function. If it does, the Annex III exemption analysis may not be the right route at all.

Assign owners for intended purpose

The intended purpose is set by the provider in its documentation, but deployers can change it in practice. Name one accountable owner for the intended purpose statement, usually the product or business owner, and a second owner who reviews changes. A deployer who repurposes a tool for hiring or lending may take on provider duties, so the purpose statement needs a change-control step. Record who approved each version.

Trace the data and model sources

Data owners decide which inputs the system uses, and that choice can move a system into profiling or into a sensitive Annex III area. A vendor's model sitting inside your system still counts toward your assessment, because the system you place on the market includes it. Obtain written documentation from the vendor on training data, intended purpose and known limits, and record which of your teams confirmed each input.

Confirm the market placement role

The team that places the system on the EU market or puts it into service holds the provider duties for the Article 6(4) documentation and registration. If a third party builds the system and you sell it under your name, you are likely the provider. Clarify in contracts which party documents the assessment, keeps it available on request and handles registration under Article 49(2). Check the Commission's draft classification guidelines of 19 May 2026, which give examples of systems that should and should not be classified as high-risk. Use them to test your reasoning, and confirm the final version before relying on it.

How to document an Article 6(3) assessment before the system goes live

This sequence takes an Annex III system from a fixed intended purpose to a filed, documented not-high-risk assessment and a registration record, with each step producing evidence the provider can show on request.

Fix the intended purpose and inventory the system
The provider writes down the intended purpose in one precise statement: the task the system performs, the people or data it touches, the decisions it informs, and the Annex III area it falls under. Engineering, product and compliance sign off on the same wording. The output is a dated system record in the AI inventory that names the version, the owner and the Annex III entry being tested. The step is complete when another reviewer can read the record and reach the same understanding of what the system is for.
Run the profiling check first
Before considering any exemption, the provider determines whether the system performs profiling of natural persons, meaning automated processing of personal data to evaluate or predict aspects of a person's life. Under Article 6(3), an Annex III system that profiles is always high-risk, so the exemption cannot apply and the assessment stops here. The output is a profiling determination with the reasoning and the data flows that support it. Legal and data protection staff should review it, since profiling has a specific meaning and borderline features are common in HR and credit tools.
Map the system to one of the four conditions
The provider selects the condition the system relies on: a narrow procedural task, improving a completed human activity, detecting decision patterns without replacing human assessment, or a preparatory task. It records why the chosen condition describes the system's actual function, and why the other conditions do not fit. Each claim should point to a feature, workflow step or configuration that a reviewer can verify. The output is a condition mapping section in the assessment record, reviewed against the intended purpose from the first step.
Record why significant risk is absent
The provider documents why the system poses no significant risk of harm to health, safety or fundamental rights. The record should cover the affected persons, the possible failure modes, the consequences of an error, the human oversight in place, and the controls that limit harm. Testing evidence, such as evaluation results or red team findings where they exist, belongs here. The output is a risk reasoning section that a market surveillance authority could read without further context. Where the reasoning depends on assumptions, the record should state them.
Obtain internal sign-off
An accountable role outside the product team approves the assessment, typically a compliance or legal lead together with a senior owner of the use case. The approver checks the profiling determination, the condition mapping and the risk reasoning, and records any open items. The output is a signed and dated approval with the version of the system it covers. If the system later changes in a way that affects its purpose or function, the sign-off must be repeated against the new version.
Hold the documented assessment before market entry
Article 6(4) requires the provider to document the assessment before placing the system on the market or putting it into service, and to provide that documentation on request. The provider stores the signed assessment in a version-controlled repository with restricted write access, so the record cannot be altered after approval without a trace. The output is a retrievable archive entry linked to the system inventory. Teams should confirm that the archive is retrievable quickly, because a supervisory authority may ask for it at any time after launch.
Register the system under Article 49(2)
The provider registers the system in the EU database under Article 49(2), supplying the registration data listed in Annex VIII Section B. Regulation (EU) 2026/1744 deleted two items from this data: the summary of grounds for the not-high-risk conclusion and the list of Member States where the system is available. The registration record, with its submission date and identifier, should be stored alongside the assessment. Teams should check the current Annex VIII text in the consolidated Regulation before submitting, since the registration fields changed in 2026.

How an assessor tests the not-high-risk conclusion

This table compares each test point an assessor applies to an Article 6(3) conclusion, the evidence it requests and the findings that most often weaken the case. Read it as a checklist: a conclusion holds only if every row can be answered from documents that match how the system actually behaves.

Test point	Evidence requested	Common findings
Intended purpose and scope check	Written intended purpose, the Annex III area it falls under, the user population and the markets where it is used	Purpose statement is broader in marketing or contracts than in the technical file, or the Annex III area is not identified
Profiling determination	Description of every processing step that evaluates personal aspects, with a clear statement of whether profiling occurs	Profiling is present in a scoring or ranking step but the file says it is not, which removes the exemption entirely
Narrow procedural task condition	Task description, inputs and outputs, and proof that the output does not decide outcomes for individuals	Output is a score or ranking that staff rarely override, so the system is in practice making the decision
Improves a completed human activity condition	Process maps showing the human step that comes before and after the system, and the change the system makes to it	Human review happens after the system has already determined the result, so the system shapes the decision
Detects decision patterns without replacing human assessment condition	Method for pattern detection, records of how flagged patterns are reviewed, and reviewer authority	Flags trigger automatic actions, or reviewers lack the time, data or training to assess them independently
Preparatory task condition	Description of the output as input to a later assessment, and records of that later assessment	Preparatory output is used as the final result in production, or the downstream step has no real review
Risk-of-harm reasoning	Written analysis of harm to health, safety and fundamental rights, the affected groups and the failure modes considered	Analysis covers accuracy only, ignores bias and affected groups, or reaches the conclusion without testing any failure case
Timing of the assessment	Dated assessment completed before market placement or entry into service, with version history	Assessment written after launch, or not updated after a material change to the model, data or use
Registration completeness	Registration record showing the Annex VIII Section B data for the system, with the date of filing	Registration missing for a system relied on as exempt, or fields left incomplete or outdated
Consistency with real behavior	Logs, test results and sampled outputs compared against the documented purpose and conditions	Logs show the system used for purposes outside the documented scope, or behavior has drifted from the assessment

Evidence that holds up an Article 6(3) assessment over time

An Article 6(3) exemption is only as strong as the record behind it. The cards below cover the artifacts a provider should hold, how each one stays current between reviews, and which tools can keep the record versioned and controlled.

Dated assessment document

This is the written assessment that explains why the system poses no significant risk of harm to health, safety or fundamental rights and which Article 6(3) condition it meets. Article 6(4) requires it to be documented before the system is placed on the market or put into service, and provided on request. Check that it names the system version, the reviewer, the date and the evidence it relies on. Each change to the conclusion should create a new dated version, not overwrite the old one. XWiki keeps page history with what changed, when and by whom, and can compare or roll back versions, which suits this document.

Profiling determination

Article 6(3) states that an Annex III system performing profiling of natural persons is always high-risk, so the exemption cannot apply to it. Keep a separate, signed record showing that the team tested whether the system profiles people, including what it infers, scores or ranks about individuals. Re-run this determination whenever features, data sources or outputs change, because a small functional change can move a system into profiling. Confirm the legal reading with counsel, and check the Commission's draft classification guidelines for examples.

Intended purpose statement

The intended purpose statement fixes the narrow task the system is allowed to perform, such as a preparatory task or a check on a completed human decision. Every other part of the assessment depends on it, so the wording should be specific enough that a reviewer can tell when the system is used outside it. Store the statement with the assessment, give it a version number, and link each version to the deployments that relied on it. Any new use case should trigger a fresh assessment before deployment.

Registration record

Article 6(4) requires a provider relying on the exemption to register the system under Article 49(2), using the data set out in Annex VIII Section B. Keep a copy of what was submitted, the date, and the registration identifier, and reconcile it against the current assessment at each review. Regulation (EU) 2026/1744 removed the summary of grounds and the list of Member States from the registration data, so older internal templates may be out of date. Confirm the current fields with the authority before you file any update.

Change log for purpose and functionality

A change log ties each model update, new data source, new output or new user group to a decision about whether the intended purpose still holds. Record what changed, why, who approved it and whether the assessment was re-run. Without this trail, a provider cannot show that the system still performs only the stated function when an authority asks. Use BookStack to control who can edit or approve these pages: its roles can be overridden per shelf, book, chapter or page, so the approver group can differ from the editing group.

Test and operational log data

Test results and operating logs show whether the system behaves as the assessment says. For a narrow procedural or preparatory tool, keep test cases tied to the stated function and results that show it does not generate decisions beyond it. If the system is an LLM-based application whose behavior must be shown, Langfuse traces record inputs, outputs, tool executions, token usage and metadata for each request, which can serve as operational evidence. Confirm that trace capture, retention and access controls fit your data protection obligations before you rely on them.

What the Article 6(3) assessment costs in money and effort

This table compares the cost components of documenting an Article 6(3) not-high-risk conclusion, who is paid for each, whether it is one-time or recurring, and what drives it up. No fee or duration has been published for this work, so use the table to scope a quote, not to budget from a number.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal legal and compliance review time	One-time at first classification, then recurring at each review	Number of Annex III areas the system touches, how many of the four Article 6(3) conditions need argument, and how many stakeholders must sign off	Write the assessment against the four conditions in a fixed template, and reuse prior reasoning for systems with the same intended purpose
Engineering time to document functions and data flows	One-time, plus updates whenever the system changes	Complexity of the pipeline, number of data sources, and whether the system's output feeds a decision or only supports one	Keep architecture diagrams and data-flow records in version-controlled wiki pages so updates are small and traceable
Registration effort under Article 49(2)	One-time per system, with updates to registered data	Completeness of the Annex VIII Section B data already on hand, and whether the system is placed in several Member States	Maintain a single inventory record per system that maps directly to the registration fields, and confirm current field requirements in the Official Journal text
Periodic reassessment after changes	Recurring	Frequency of model updates, new intended purposes, new user groups, and any drift in output that affects the exemption reasoning	Tie reassessment to change management, so a change request triggers a review rather than a separate project
External review or legal opinion	Optional, usually one-time per system or per material change	Ambiguity in the case, the provider's appetite for risk, and whether the market surveillance authority is likely to scrutinize the system	Ask counsel for a written scope limited to the disputed conditions, rather than a full review of the file
External classification advice	One-time, sometimes recurring for portfolios	Number of systems, sector overlap with Annex I, and the depth of comparison against the Commission's draft guidelines of 19 May 2026	Start with an internal inventory so advisers review a short list of borderline cases instead of the full portfolio
Tooling and evidence storage	Recurring, mostly internal staff time	Choice of wiki, logging and access control tools, and how long records must be retained	Open-source documentation and version control tools can reduce license spend, but they do not reduce the time needed to reason through each condition

Who does the Article 6(3) work: your team, a partner and the authority

Your organization is the provider for an Annex III system that you place on the market or put into service under your name, so the Article 6(3) decision is yours to make and defend. Your team decides whether each of the four conditions is met, checks whether the system performs profiling of natural persons (which removes the exemption), writes the documented assessment before the system goes live, and keeps that record available for a regulator. Legal, product, data protection and security owners usually need to sign off together, because the reasoning touches intended purpose, affected people and fundamental rights.

Owning the classification decision: Name an accountable owner and record who reviewed the reasoning and when.
Testing the profiling override: Confirm early whether the system profiles natural persons, since that finding alone keeps it high-risk.
Keeping the assessment current: Re-run the reasoning when the intended purpose, data or user population changes.
Registering the system: Complete the Article 49(2) registration with the data listed in Annex VIII Section B.
Answering challenges: Be ready to produce the documentation when a market surveillance authority asks under Article 80.

Before relying on the exemption, confirm with your legal team how the 2026 amendments and the draft classification guidelines of 19 May 2026 apply to your use case.

What happens when a market surveillance authority challenges the conclusion

Under Article 80, a market surveillance authority that suspects an Annex III system has been misclassified will evaluate the system itself. If the evaluation finds that the system is high-risk, the provider must bring it into compliance with the high-risk obligations. If the provider classified the system as not high-risk in order to avoid those obligations, the provider also faces fines under Article 99. The practical question for the provider is therefore what it can produce, and how quickly, once an authority asks. The answer should be a file that was prepared before the system went to market, not one assembled after the request arrives.

The core of that file is the dated Article 6(4) assessment, showing which of the four conditions in Article 6(3) the provider relied on and why. Alongside it, keep the profiling determination, which records whether the system performs profiling of natural persons, because that finding overrides the exemption entirely. Add the registration record under Article 49(2), with the Annex VIII Section B data as it was submitted, and the version history showing any change to the system after registration. Most important is evidence of actual functions: logs, test results and product documentation that show what the system does in operation, not only what the intended purpose says. An authority will compare the claimed narrow task against observed behavior, so the file must match the system as deployed. Confirm with counsel which national authority would receive such a request for each market where the system is available.

When an information request arrives, the provider should confirm its scope and deadline, assign one accountable owner, and answer from the existing file without reconstructing history. Responses that explain a classification that was written down at the time carry far more weight than conclusions drafted under pressure. A timely, documented assessment also protects the provider if its reasoning later proves wrong, because it shows a good-faith process rather than an attempt to avoid the requirements. The conclusion alone is a claim. The dated reasoning, the evidence of functions and the change history are what an authority can test, and they are what distinguish an honest misjudgment from circumvention. Where the classification is contested, an independent legal or assessment adviser can review the file, but the decision and the response remain the provider's.

Where Article 6(3) conclusions usually fail and how to close each gap

An Article 6(3) conclusion is only as strong as its documentation, its match to the system's actual behavior, and the people who keep it current. The gaps below recur across providers, and each one has a specific closing action that an assessor or market surveillance authority can check.

Assessment written after launch

Article 6(4) requires the provider to document the not-high-risk assessment before the system is placed on the market or put into service. A file created after go-live, or reconstructed for an inquiry, weakens the position even when the reasoning is sound. Check that the assessment carries a date earlier than the first release. Close the gap by making the assessment a release gate, so the build cannot ship until the signed record exists.

Profiling overlooked in analytics features

Under Article 6(3), an Annex III system that performs profiling of natural persons is always high-risk, whatever the other conditions say. Teams often miss this when a dashboard score, churn flag or ranking feature evaluates individuals using personal attributes. Inventory every feature that infers traits, behavior or preferences about a person, and record whether it qualifies as profiling before relying on any exemption. If profiling is present, the exemption is closed and the system follows the high-risk route.

Conclusion drifts from actual behavior

An assessment describes the system as it was designed. A new model version, retrained weights, an added data source or a changed decision threshold can move the system into a different Article 6(3) category, or out of it. Treat each material change as a trigger to re-run the four-condition test against the new behavior. Keep version history of the assessment next to the model and configuration versions so the two can be compared during review.

Vague significant-risk argument

Stating that a system poses no significant risk is not enough. The assessment should name the harms to health, safety and fundamental rights, explain why the system's output is limited to one of the four listed tasks, and show why those harms are unlikely in the deployment context. Vague wording such as "low impact" with no reasoning is the first thing an authority will challenge. Write the argument per use case, cite the test data or evaluation that supports it, and have a reviewer outside the build team challenge each step.

Registration missed or incomplete

Article 6(4) requires a provider relying on the exemption to register the system under Article 49(2), and Annex VIII Section B lists the data to submit. Regulation (EU) 2026/1744 deleted the summary of grounds and the list of Member States where the system is available from that registration data, which changes what the record must hold. Confirm the current Annex VIII fields against the consolidated text, register before placing the system on the market, and keep a copy of the submission with the assessment file.

No owner for reassessment

An exemption that nobody is responsible for reviewing will drift out of date, and the file will still say what it said at launch. Name one accountable owner for each Article 6(3) conclusion, set a review trigger list that includes model changes, new features and new deployment contexts, and schedule a periodic review even when nothing has changed. Record the owner, the review date and the outcome in the same system that holds the assessment, so an authority asking under Article 80 receives a current file.

Questions buyers ask about Article 6(3) cost, timing and outsourcing

How much effort does an Article 6(3) assessment take, and what drives it?

The effort depends on how many Annex III systems you are assessing, how well each system's purpose and outputs are documented, and how many of the four exemption routes you must argue. No researched figure is available for the effort, so ask for one in writing. The work scales with the number of systems, the number of people who must review each conclusion, and whether the system performs profiling of natural persons. Profiling is always high-risk under Article 6(3), so a profiling system usually ends the analysis quickly. Systems with clear narrow-task or preparatory roles and a well-documented human review step usually take less work to document. Ask any partner to break its quote into system discovery, risk reasoning, documentation and registration support.

Can a provider complete an Article 6(3) assessment without outside help?

Yes. The provider owns the classification and the documented assessment, and nothing in the Act requires an external firm to prepare them. Internal teams with knowledge of the system's intended purpose, data and decision flow are best placed to write the reasoning. Outside help is most useful for a second-line review of the four conditions, for mapping the system's real use against Annex III wording, and for setting up records that will stand up to a request. Check that the people signing off have authority over the product and the legal reading, and keep the documented assessment in a form you can produce on request.

What work does our team have to supply to a partner?

Your team supplies the facts a reviewer cannot infer from the code. Typical inputs include the intended purpose, the decision the system informs or makes, the users and affected people, the data sources, the outputs and how humans use them, and any profiling of individuals. You also need the product and deployment context, the change history of the model and its prompts, and the current registration status. Ask the partner to list these inputs in the written scope, with an owner on your side for each one. Missing inputs are the most common reason an assessment slows down.

When must the Article 6(3) assessment be ready relative to placing the system on the market?

Article 6(4) requires the provider to document the assessment before placing the system on the market or putting it into service, and to register it under Article 49(2). The documentation must be available to authorities on request, so it should exist as a finished record at launch, not as a retrospective note. For a system already in use, plan the assessment against the date it started operating in the EU. Application dates for the high-risk rules were changed by Regulation (EU) 2026/1744, so confirm the dates that apply to your system against the consolidated text before setting internal deadlines.

Can a consultant or partner make the classification decision for us?

No. The provider owns the classification decision and the documented assessment under Article 6(3). A partner can prepare the analysis, challenge assumptions, organize evidence and draft the documentation for your review, but the conclusion and its legal responsibility stay with your organization. Independent assessment bodies do not issue a classification certificate for this exemption. Ask any partner to state in writing that it prepares, and you approve, the classification and documentation.

What does a challenge by a market surveillance authority involve?

Under Article 80, a market surveillance authority that suspects a system has been misclassified evaluates the system. If it finds the system is high-risk, the provider must bring it into compliance with the high-risk requirements. If the provider misclassified the system to avoid those requirements, fines under Article 99 can apply. In practice, you should expect a request for your documented assessment, the registration record, a description of the system and its use, and evidence of how the four conditions were tested. Keep the assessment current when the system or its use changes, so the record matches what the authority finds.

How DeployOpen prepares Article 6(3) evidence for your systems

DeployOpen helps organizations prepare the systems, records and evidence behind an Article 6(3) assessment for Annex III systems that are not high-risk. We work inside your own infrastructure, and the decision and the documentation stay with your organization, with your legal and compliance owners.

How we scope

Engagements are fixed-scope, with the systems, deliverables and timelines agreed in writing before work starts.
We confirm which Annex III systems are in play and which of the four Article 6(3) conditions each one is being assessed against.
The written scope names who decides the not-high-risk conclusion, so the assessment and sign-off stay with your organization.

How we build

We set up self-hosted tooling in your cloud account, data center or air-gapped network to record each system's intended purpose and assessment inputs.
We configure version-controlled documentation so every change to the assessment, with its author and date, can be compared and rolled back.
Where a system performs profiling of natural persons, we flag it for high-risk treatment, because the Article 6(3) exemption does not apply to it.

How we hand over

We deliver the documented assessment in a form ready for the provider's file, to be provided on request to a market surveillance authority.
We prepare the registration data required under Annex VIII Section B, reviewed against the current text of Regulation (EU) 2026/1744.
We document access roles and permissions so your team can show who edited, approved and reviewed each classification record.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
We can review the assessment when a system changes materially, since a changed purpose may change its classification.
We recommend confirming current classification guidance, including the Commission's draft guidelines, with your legal counsel before relying on the exemption.