Is every AI system in a sensitive industry high-risk?

No. The particular function and applicable classification rules matter, rather than the industry name alone.

Does adding human approval remove the classification?

Not automatically. The system's influence and the specific conditions must still be examined.

Can an organization use a broader internal risk category?

Yes. It should clearly distinguish that management category from the legal classification being discussed.

AI Glossary / Governance, ethics and safety / Intermediate

High-risk artificial intelligence system

Definition

A high-risk artificial intelligence system is an AI system placed in a category requiring stronger safeguards because of its intended use and potential consequences for people. Under the European Union's AI Act, “high-risk” has a specific legal meaning determined by classification rules. This entry explains that EU meaning while distinguishing it from an organization's broader internal assessment of AI risk.

What it means

Calling a system high-risk does not mean it has already harmed someone. It identifies a class of uses for which preventive controls and responsibilities matter especially strongly. Nor does the label mean the use is automatically prohibited: prohibited practices form a separate legal category.

The application matters. A language model drafting an internal meeting agenda and a system evaluating job applicants may share underlying technology while serving very different purposes. Model size, sophistication, price, and popularity do not settle classification.

An internal risk register can also call a project high-risk for operational reasons. Teams should state which meaning they intend. A business label, a supplier's marketing description, and an assessment under a particular law are different pieces of information.

How it works

The EU classification includes certain regulated products or safety components subject to third-party conformity assessment, and specified uses listed in Annex III. Both conditions in the product route matter. Annex III also has qualified exceptions under Article 6; an exception cannot be assumed merely because a task includes a human reviewer.

For an initial review, describe the intended function, users, affected people, and decisions influenced. Identify the applicable route, then examine its conditions and exceptions using current legal material.

High-risk requirements address matters including risk management, data governance, documentation, oversight, and technical performance. Responsibilities vary with an organization's role. Classification, role allocation, and applicable commencement dates therefore need to be recorded together.

Three practical examples

1. A recruitment platform that evaluates candidates raises the Annex III employment classification question. Its exact functions and applicable conditions must be assessed.

2. An educational application used to determine admission raises a different listed-use question from a general tool that helps staff draft ordinary correspondence.

3. An AI safety component in a regulated product requires examination of the product route, including the relevant conformity-assessment conditions. Simply being installed in a product does not settle the answer.

Think of it this way

Think of classifying a building by its intended occupancy. A warehouse and a school can use similar materials, but the activities and people inside influence the safeguards that need attention.

The analogy has limits. AI classification follows its own detailed rules, and software can be repurposed much faster than a building. A label from the first project description may become misleading when the actual function changes. The useful lesson is to inspect the purpose and consequences rather than judge the system only by its technical components.

Worked example

Consider an invented purchasing review involving two functions in one supplier's product. Function A arranges interview appointments. Function B scores applicants and recommends a shortlist.

The review team creates separate descriptions: A changes scheduling; B influences who progresses. It records what information each function consumes, what outputs reach hiring staff, and whether either output profiles individuals. It then maps each function to the relevant legal criteria.

Suppose the supplier describes both as “administrative support.” That phrase does not establish that both qualify for the same treatment. Function B's candidate evaluation is substantively different from booking an appointment.

The result of this exercise is a set of classification questions and supporting evidence, not an automatic legal determination. The team still needs to evaluate the complete system and applicable rules. Separating functions prevents a harmless-sounding description from hiding a consequential purpose.

Illustrative case study

Fictional case: Cedar Learning plans to buy software for an education program. Its first proposal describes help with document organization. During a demonstration, the supplier also shows a score that staff could use to decide which applicants receive places.

The project owner updates the use description and asks the responsible reviewers to assess the admission-related function before approving that workflow. Procurement requests documentation covering the proposed use rather than accepting assurances about the underlying model alone.

The case illustrates a governance improvement, not a finding that any real product complies with the Act. Recognizing a changed purpose early gives the organization a clearer basis for deciding what evidence, controls, and specialist review are needed.

Common misconceptions and mistakes

“A person makes the final decision, so classification cannot apply” is unreliable. AI can materially influence a decision even when someone later approves it.

“High-risk means forbidden” confuses different categories. Equally, absence from a high-risk category does not establish that a system is harmless or exempt from every obligation.

Another mistake is treating accuracy as the sole criterion. A highly accurate system can still serve a legally classified purpose. Finally, do not copy a deadline from an old presentation: amendments and transitional provisions can change implementation planning.

Business use

For business teams, classification connects product design, procurement, and accountability. Record the actual workflow and the organization's role before deciding which supplier statements answer the relevant questions.

A practical project file can link the use description to the classification rationale, responsible reviewer, required evidence, and change triggers. Revisit it when a feature begins influencing different decisions or reaches a new population. This supports consistent review without pretending that a short checklist replaces a complete assessment.

Check your understanding

Two tools use the same model, but one schedules interviews and the other ranks candidates. Does their shared model establish the same classification?

Answer: No. Their intended functions and decision effects differ. Each proposed use needs assessment against the applicable rules; shared technology is insufficient evidence.

Related terms

Impact assessment
AI Act
intended purpose
risk management
human oversight
conformity assessment
provider
deployer

Learn next

Study intended purpose and human oversight next. Practice describing a proposed system without brand names: identify its input, output, affected people, and influence on decisions. Then compare that description with the current classification criteria and record uncertainties for review.

Sources

European Commission, AI regulatory framework: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

European Commission AI Act Service Desk, Article 6: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6

European Commission AI Act Service Desk, Annex III: https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3

Official explanations and displayed legal provisions were read. Examples are original teaching illustrations. This introductory EU scope requires legal editorial review and current commencement checks before publication; it does not provide a project-specific legal determination.

Previous: High-performance fuzzy computing Next: High-throughput computing