AI Act — When Does a Polish SME Become a High-Risk AI System Provider?

High-Risk Is Not a Label — It Is a Legal Status

In the AI Act, the term “high-risk system” is not an opinion, a marketing claim, or an internal vendor classification. It is a legal status that imposes specific obligations — from technical documentation, through logging, to conformity assessment. And what matters: this status does not depend on how the vendor describes its product. It depends on the intended purpose of the system within the meaning of Article 3(12) of the Regulation.

If your SaaS product is sold as “AI candidate screening for employment” — it is a high-risk system, regardless of whether you use the word “AI” in the marketing copy or not. This distinction matters for every Polish SME that builds or resells solutions with an AI component.

In this article we walk through the full list in Annex III, add concrete SME examples for each category, and close with the operational obligations under Articles 8–22.

Two Classification Paths — Article 6

Article 6 of the AI Act defines two routes by which an AI system enters the high-risk category:

Path A — regulated product (Art. 6(1)): the AI system is a safety component of a product covered by the EU harmonisation legislation listed in Annex I (machinery, medical devices, toys, aviation, rail, pressure equipment and others) and that product is subject to third-party conformity assessment.
Path B — Annex III area (Art. 6(2)): the AI system is intended for use in one of the eight areas listed in Annex III.

Most Polish SMEs, if they fall within the high-risk scope, will do so through Path B. That is why we break down all eight Annex III categories below.

The Eight Categories of Annex III

1. Biometrics

Annex III, point 1 covers systems for:

remote biometric identification (beyond identification used solely to confirm a person’s identity);
biometric categorisation according to sensitive attributes or characteristics;
emotion recognition.

Some of these applications are prohibited under Article 5 — in particular biometric categorisation by sensitive characteristics (e.g. race, religion) and emotion recognition in the workplace and in education. Others — such as emotion recognition in an out-of-EU call centre used for quality assessment — fall into high-risk with the full set of obligations.

2. Critical Infrastructure

Annex III, point 2 covers AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity.

For SMEs, this becomes relevant when the company provides a SCADA solution with a predictive AI layer for a distribution network operator. The energy demand forecasting algorithm itself may not be high-risk — but the module that controls load switching already is.

3. Education and Vocational Training

Annex III, point 3 lists AI systems used:

to determine access to or assign persons to educational institutions;
to assess learning outcomes, including exams;
to assess the level of education a person is entitled to;
to monitor and detect prohibited behaviour during tests.

For Polish ed-tech SMEs — online proctoring, AI-grading, recommendation engines directing students to learning tracks — this is a direct indication. Selling such products to universities or schools after August 2026 requires the full compliance stack.

4. Employment and HR

Annex III, point 4 covers AI systems used:

for recruitment or selection of persons — in particular for advertising jobs, analysing applications, assessing candidates;
for decisions on employment conditions, promotions, termination of employment, task allocation based on employee behaviour, and monitoring and assessment of performance.

This is the category that Polish SMEs most frequently fall into — by purchasing off-the-shelf HR-tech tools with AI CV screening, AI-driven workforce planning, or performance assessment algorithms. The HR-tech provider is itself a high-risk provider; the company buying and deploying it becomes a high-risk deployer — with a separate but narrower set of obligations (Arts. 26–27).

5. Access to Essential Public and Private Services

Annex III, point 5 lists:

assessment of eligibility for public benefits and services;
assessment of creditworthiness or credit scoring of natural persons (with the exception of AI for detecting financial fraud);
risk assessment and pricing in life and health insurance;
classification and prioritisation of emergency calls (112, ambulance, fire brigade).

For fintech SMEs, AI credit scoring is a direct indication. For insurtech companies — health or life pricing. Point (b) has an important carve-out for AI detecting financial fraud — worth distinguishing from creditworthiness scoring.

6. Law Enforcement

Annex III, point 6 covers AI systems used by law enforcement authorities — including to assess the risk of an individual committing a crime, as a polygraph, to assess the reliability of evidence, and for profiling during detection and prosecution of offences.

Polish SMEs are rarely providers in this category — since the only customers are public authorities. But if a company builds a “risk scoring for compliance officers in a bank” solution intended for reporting to the GIIF (Polish Financial Intelligence Unit), the boundary between Art. 5(1)(d) (prohibition on risk of crime assessment based solely on profiling) and point 6 (law enforcement) requires separate analysis.

7. Migration, Asylum and Border Control

Annex III, point 7 covers AI systems used by public authorities in the context of migration, asylum and border control — including polygraphs, migrant risk assessment, travel document authenticity verification, and examination of asylum applications.

For most Polish SMEs — a marginal area, unless the company provides document verification systems to the Border Guard or the Office for Foreigners.

8. Administration of Justice and Democratic Processes

Annex III, point 8 covers:

AI systems assisting a judicial authority in researching and applying the law to a specific set of facts;
AI systems intended to influence election or referendum outcomes, or the electoral behaviour of individuals (excluding purely organisational campaign tools).

This category is relevant for legal-tech SMEs building AI legal research tools for courts or law firms representing a party before a court. Research tools for law firms are typically outside the scope — as they do not directly support the court itself.

Three Concrete Polish SME Scenarios

HR-tech SME with AI CV screening. You sell a SaaS product that analyses CVs and assigns candidates a match score for a job opening. This is Annex III, category 4. As a provider you are subject to the full package of Arts. 8–22. This requires a risk management system (Art. 9), data governance (Art. 10) — including validation of training data for bias — technical documentation in accordance with Annex IV (Art. 11), conformity assessment per Art. 43 (for most Annex III high-risk systems — internal, without a notified body), CE marking, and registration in the EU database per Art. 71.

Fintech SME with AI credit scoring. Annex III, category 5(b). The full package as above, with additional sectoral requirements (KNF, ESMA — through linkage with the Consumer Credit Directive). This raises the question of whether existing KNF supervisory requirements are sufficient for the AI Act conformity assessment, or whether a separate procedure is required.

Edu-tech SME with AI grading. Annex III, category 3. Full package — with additional burden on training data quality validation (bias testing for Polish language, regional variation, school profiles). The deployer FRIA under Art. 27 (the school or university) becomes part of the B2B sales cycle.

Provider Obligations for High-Risk Systems — What Actually Needs to Be Built

Arts. 8–22 of the AI Act form a coherent package of requirements. The most important from a CTO perspective:

Risk management system (Art. 9): a continuous process — identifying, estimating, evaluating and mitigating risk throughout the entire lifecycle. Not a one-off document but a live process with responsibilities and reviews.
Data governance (Art. 10): training, validation and test datasets must meet quality and representativeness criteria — and where relevant be free of errors and complete. This directly affects how you build and document your dataset.
Technical documentation (Art. 11) + Annex IV: a comprehensive system description — architecture, data, validation, monitoring, risks. Annex IV provides the minimum field list.
Logging (Art. 12): automatic logging of events throughout the operational lifecycle — with retention proportionate to the intended purpose.
Transparency towards the deployer (Art. 13): instructions for use, description of limitations, requirements for human oversight.
Human oversight (Art. 14): the system must be designed so that a human can effectively oversee its operation — with concrete intervention mechanisms.
Accuracy, robustness, cybersecurity (Art. 15): the level required must be appropriate to the intended purpose — with robustness against errors, inconsistencies and adversarial attacks.

Conformity Assessment — Article 43

Most high-risk systems from Annex III undergo conformity assessment internally — without the involvement of a notified body. The exception applies to biometrics (Annex III, point 1), where in certain configurations a third-party audit is required. After a successful assessment the system receives CE marking and is registered in the EU database per Art. 71.

For an SME provider this means an internal procedure, documentation and — in practice — external legal-technical support for the first cycle. The second cycle, for the next product version, is significantly less costly operationally.

What to Do in 2026 — Three Steps

Step 1: AI system inventory. A list of all AI systems in production, in the procurement stack and on the roadmap. Per system: vendor, intended purpose, inputs, outputs, end population.

Step 2: Classification per Annex III. Each AI system on the list mapped to one of three categories — prohibited, high-risk (with the Annex III point number), or other. Classification is worth doing with a lawyer — because the boundaries are precise, but their interpretation in specific cases is non-trivial.

Step 3: Compliance plan for August 2026. For each high-risk system — a gap map: what is missing (documentation, logging, deployer FRIA, instructions), who is responsible for what, by when. With a buffer of at least three months before the deadline — because a conformity assessment is not a one-day task.

QA10 — Where We Verify This

Within our Engineering Lab we carry out classification of the client’s AI stack against Annex III and Annex I, and assess documentation readiness — including data governance and logging layers — ahead of August 2026. For clients who are deployers, we also carry out FRIAs per Art. 27.