No. The AI Act does not classify all AI as high risk. A system is high risk only where Article 6 classifies it as such, through the Annex I product route in Article 6(1) or the Annex III use case route in Article 6(2), subject to the filter in Article 6(3) for narrow procedural tasks and the profiling exception. Systems that are not high risk can still be subject to the prohibited practices in Article 5, to transparency duties in Article 50, to AI literacy duties, and, for general purpose models, to Chapter V duties. The correct question is not whether a system uses AI, but what the system is for, who provides and deploys it, and which Article 6 route, if any, applies to its intended purpose.
Where does the misconception come from?
The misconception that all AI is high risk comes from headlines, summaries and vendor material that describe the AI Act as a high risk regulation, without explaining that high risk is a defined category with defined routes. It also comes from the visibility of high risk examples, such as recruitment, credit scoring and biometric identification, which are frequently used to illustrate the Act, and from the understandable caution of organisations that do not want to miss a high risk duty. Caution is a good starting point, but it is not a classification. A cautious organisation that treats every system as high risk will build conformity files for systems that do not need them, will spend time and money on the wrong evidence, and will miss the duties that do apply to its non high risk systems, such as transparency and literacy. A careless organisation that treats no system as high risk will miss the high risk duties that do apply. The correct approach is neither caution nor carelessness as a general rule, but classification system by system, with the Article 6 test applied to the intended purpose and the facts. The misconception persists because classification takes work, and a slogan is easier than work. The work is nevertheless required, and the record of the work is the evidence that the classification was done properly.
How does Article 6 classification work in outline?
Article 6(1) classifies an AI system as high risk where it is intended to be used as a safety component of a product, or is itself a product, covered by Union harmonisation legislation listed in Annex I, and the product must undergo third party conformity assessment under that legislation. Article 6(2) classifies an AI system as high risk where it falls within a use case listed in Annex III, in areas including biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice and democratic processes. Article 6(3) provides a filter for Annex III systems that perform a narrow procedural task, improve the result of a previous human activity, detect decision making patterns without replacing human assessment, or perform a preparatory task, subject to the condition that the system does not profile natural persons. That filter must be checked in the consolidated text and in the Commission guidelines on high risk classification, because it is narrow and conditional, and profiling always takes the system outside the filter. A system that is not classified under either Article 6 route is not high risk, but the classification must be recorded with reasons, including the Annex I and Annex III categories considered and rejected, so that a reviewer can test the negative conclusion.
For the broader regulatory framework, see questions and misconceptions overview.
What systems are commonly not high risk?
Systems that are commonly not high risk, subject to the facts and to the other screens, include general productivity tools such as spelling and grammar checking, meeting transcription, document summarisation for general purposes, and website chatbots that answer general questions without making consequential decisions, provided that they are not used for a high risk purpose, are not safety components, and do not fall within a prohibited practice. A system that is not high risk in one use can become high risk in another use, where the intended purpose changes, where it is integrated into a high risk workflow, or where it is used as a safety component. For example, a general text generation tool used to draft product descriptions is different from the same tool used to screen job applications, and a general vision tool used to count products is different from the same tool used to guard a machine. The use, not the technology, drives the classification. A record that states that a technology is not high risk, without stating the use, is incomplete. A record that states the use, the Annex categories considered, and the reasons for rejecting each, is a classification record that can be tested. The examples in this cluster show that distinction in practice, with the same technology in different uses producing different screening outcomes.
What duties can apply to non high risk systems?
Non high risk systems can still be subject to important duties. Article 5 prohibited practices must be screened first, because a prohibited practice is unlawful whatever the risk category. Article 50 transparency duties can apply to systems that interact with natural persons, to emotion recognition and biometric categorisation systems, and to systems that generate or manipulate synthetic content, even where they are not high risk. Article 4 AI literacy duties, as amended, require the Commission and Member States to foster literacy, and providers and deployers should support literacy for the people who develop, operate and use their systems, in accordance with the amended provision and guidance. Data protection, consumer, employment and sector law can also apply, with their own duties for fairness, transparency, accuracy and human oversight. A system that is not high risk should therefore not be treated as unregulated. The record should show the prohibition screen, the transparency screen, the literacy arrangements and the other law screens, in addition to the high risk classification, so that a reviewer can see that the non high risk conclusion was not treated as a conclusion that no duties apply. A system with no duties at all is rare, and a record that claims no duties should be treated with scepticism.
How should a negative classification be recorded?
A negative classification, that a system is not high risk, should be recorded with the same care as a positive classification. The record should state the system, the version, the intended purpose, the Annex I categories considered, the Annex III categories considered, the Article 6(3) filter considered where relevant, the reasons for rejecting each category, the prohibition and transparency screens, and the reviewer and date. It should state the evidence relied on, including the instructions, the marketing, the data and the workflow, and should note the open questions and the confirmation sought. It should be updated when the intended purpose changes, when the system is integrated into a new workflow, when the law or guidance changes, or at a planned review interval. A negative classification that is recorded only as a single word, or that is not recorded at all, will be difficult to defend if an authority, a customer or a notified body asks how the classification was made. A negative classification that is recorded with reasons, evidence and review arrangements shows that the work was done, even where the conclusion is that the system is not high risk. The record should be kept with the system inventory, so that all systems, high risk and not high risk, can be seen together.
Continue with worked example: customer chatbot.
What does this correction not decide?
This correction does not decide whether any named system is high risk, does not reproduce Article 6 or Annex III in full, and does not state the position for any specific use case. Classification needs the intended purpose, the system description, the Annex I and III categories, the Article 6(3) filter and the Commission guidelines, checked against the facts of the system. A provider or deployer with a borderline classification should confirm the position with a competent authority or legal adviser, with the classification record in hand. This guide corrects the general misconception, not the classification of a particular system.
Frequently asked questions
Is a chatbot always high risk?
No. A chatbot that answers general questions is commonly not high risk, subject to the facts, but it can be subject to Article 50 transparency duties and to other law. A chatbot used to screen job applications, to assess credit, or to make a consequential decision can be high risk under Annex III. The use, not the chatbot technology, drives the classification.
Does using a large language model make a system high risk?
No, not by itself. A large language model is a general purpose model for Chapter V purposes, and a system built on it is classified under Article 6 by its intended purpose. A general purpose tool used for a non high risk purpose is not high risk on that ground, while the same tool used for an Annex III purpose can be high risk.
What if a system is not high risk but generates synthetic content?
Article 50 transparency and marking duties can still apply, including duties to disclose synthetic content and to mark output in a machine readable manner where Article 50(2) requires it. The transparency screen must be run separately from the high risk classification, with the Article 50 duties recorded.
Should every system have a conformity file?
No. A conformity file in the Article 43 sense is required for high risk systems. Non high risk systems should have a screening and evidence record, with the classification, prohibition and transparency screens, but they do not need a high risk conformity file. Building a high risk file for a non high risk system wastes effort and can obscure the duties that do apply.
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 ↗