Classification under the Act is a self-assessment in the sense that the provider and, where relevant, the deployer must carry it out and document it, subject to authority oversight and to the formal duties that follow reliance on the Article 6(3) filter or a conformity route. A good record names the system and version, the intended purpose, the facts tested against Articles 5 and 6, the annex points considered, the evidence examined, the conclusion for each provision, the reviewer, and the trigger for revisiting the conclusion. A conclusion without that record is difficult to defend, difficult to review, and difficult to update when the system changes.
What is self-assessment under the Act?
Self-assessment means the responsible actor assesses its own system against the Act's tests and records the conclusion, rather than waiting for an authority to classify the system. For most Annex III systems, the provider carries out the conformity assessment through internal control or, where required, with a notified body, and the deployer assesses its own use. For Article 6(3) filter reliance, the provider must document the assessment and register the system. Self-assessment is therefore not informal: it is a documented decision that an authority can request, review and challenge. The record should be written as if a competent authority, a customer, or a successor reviewer will read it without the author present to explain it.
What should the record contain, step by step?
The record should contain the system name and version, the model and components, the intended purpose with context and conditions, the operator roles, the Article 5 screen with each point considered, the Article 6(1) test with the Annex I analysis, the Article 6(2) test with each Annex III point considered, the Article 6(3) filter analysis where relied on, the Article 50 check, the Chapter V check where a model is involved, the application date analysis, the conclusion for each provision, the evidence examined, the reviewer and date, and the revisit trigger. Each step should state the conclusion and the reasoning, including where a point was considered and found not to apply, so that the record shows the work, not only the outcome.
For the broader regulatory framework, see high-risk AI systems.
What evidence supports each element?
Evidence should match the element being tested. Intended purpose is evidenced by instructions for use, promotional material, technical documentation and the actual deployment. Safety component status is evidenced by safety analysis and failure effects. Annex III matching is evidenced by the function description, the decision affected, and the user group. The Article 6(3) filter is evidenced by the no significant risk reasoning, the condition relied on, and the profiling analysis. Article 5 screening is evidenced by the technique, the target, the data and the workflow. Supplier claims should be treated as claims until verified against documentation, testing or observed behaviour, and gaps should be recorded as gaps, not filled by assumption.
Who should review a classification?
The reviewer should have the competence to test the legal and technical elements, and should be independent enough from the product team to challenge the conclusion. For routine, clearly non-high-risk systems, a trained internal reviewer with a checklist can be sufficient, provided the record is complete. For borderline, consequential or novel systems, qualified legal review is appropriate, and the reviewer's advice should be recorded. The reviewer should be named, the date of review recorded, and any disagreement or open question kept visible. A classification signed off only by the team that built the system, without independent challenge, is weaker than one that shows a reviewer tested the reasoning.
How should the record be kept current?
The record should be versioned with the system, retained for the period the applicable provisions require, and reviewed on a defined trigger: purpose change, model update, new user group, new geography, new guidance, or a fixed review date. Each review should state whether the conclusion stands, what changed, and what evidence was re-examined. Superseded classifications should be retained, not overwritten, so that the history of decisions is traceable. Where a system is supplied to others, the deployer-facing summary of the classification should be updated at the same time as the internal record, so that deployers do not act on an outdated conclusion.
Continue with Article 6 classification routes.
What can a record not do?
A record cannot make a wrong classification right, and it cannot replace the conformity assessment, documentation and oversight that follow a high-risk conclusion. It can only show that the tests were applied, the evidence was examined, and the reasoning was recorded. This guide does not classify any system and does not certify any record. A record that is complete, honest about gaps, and reviewed by a competent person is the best foundation for a later authority discussion, but the underlying classification still needs to be correct on the facts and the consolidated text, confirmed with a competent authority or legal adviser where the conclusion is contested.
Frequently asked questions
Is classification a one-off exercise?
No. Classification must be revisited when purpose, users, data, integration, model version or review design change, when new guidance is published, and on a fixed review date. The record should state its revisit trigger.
Does self-assessment mean no authority is involved?
No. Self-assessment is subject to authority oversight, to documentation and registration duties, and to market surveillance. An authority can request the assessment, challenge it, and take corrective action where it is wrong.
What if supplier information is missing?
The gap should be recorded, the classification should stay open or be made on a precautionary basis, and the supplier should be asked for the missing information. A conclusion built on an assumed supplier fact should be marked as provisional and given a closing date.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗