AI Act high-risk classification – affected sectors

A Warsaw-based fintech company deploys an AI-powered credit-scoring tool. A Kraków hospital integrates machine-learning diagnostics. A Silesian manufacturer installs computer-vision safety monitoring on its production line. Each situation looks different. Under the EU AI Act, each may trigger the same legal consequence: high-risk classification, with obligations that attach immediately and carry penalties of up to EUR 30 million or 6% of global annual turnover.

The EU AI Act establishes a tiered classification framework in which certain AI systems are designated as high-risk based on their sector of deployment or functional role. High-risk systems must meet conformity requirements – including risk management, data governance, transparency, and human oversight – before being placed on the market or put into service. Polish operators and importers of such systems are subject to these obligations under EU law as directly applicable regulation, enforceable from August 2026 for most high-risk categories.

This guide walks through the classification logic step by step: which sectors and system types fall under the high-risk label, how the self-assessment procedure works, what the compliance timeline looks like, and where operators most commonly go wrong. Three business scenarios – manufacturing, healthcare IT, and a foreign investor entering Poland – illustrate how the rules apply in practice.

How does the AI Act define high-risk classification?

High-risk status is not a matter of opinion or internal risk appetite. The AI Act defines it structurally: a system is high-risk if it falls within one of the regulated sectors listed in its annexes, or if it performs a function that the regulation identifies as posing significant risk to health, safety, or fundamental rights. The classification is binary. Either a system qualifies or it does not – and the consequences of misclassification run in both directions.

Two distinct pathways lead to high-risk status. The first covers AI systems that are themselves safety components of products already regulated under existing EU product-safety legislation – think machinery, medical devices, or civil aviation equipment. The second covers stand-alone AI systems deployed in eight specific sectors: biometric identification, critical infrastructure, education, employment, access to essential services, law enforcement, migration management, and administration of justice. A credit-scoring model used by a Polish bank to determine loan eligibility falls squarely into the "access to essential services" category.

The classification assessment must be conducted by the provider – the entity that develops or places the system on the market. Deployers (organisations that put the system into use) carry separate but related obligations. Under Polish commercial practice, the line between provider and deployer is often blurred: a Polish company that fine-tunes a third-party foundation model for its own internal HR screening may qualify as a provider rather than a mere deployer, triggering the full compliance burden. This distinction matters enormously for liability allocation in contracts.

Safety-component AI in regulated products (machinery, medical devices, vehicles)
Biometric identification and categorisation systems
AI used in critical infrastructure management
AI for employment decisions – recruitment, promotion, performance monitoring
AI determining access to education, credit, social benefits, or essential services

One concrete figure anchors the stakes: providers of high-risk systems who place a non-compliant product on the EU market face administrative fines of up to EUR 30 million. For SMEs operating in Poland, that ceiling is not theoretical – it is the starting point for enforcement negotiations with the national supervisory authority.

Which sectors and systems are most affected in Poland?

Poland's economic profile means certain sectors face disproportionate exposure. Financial services, manufacturing, healthcare, and HR technology are the four areas where the high-risk classification intersects most directly with existing Polish commercial activity. Each sector carries its own compliance pressure – and its own interaction with parallel regulatory frameworks such as Rozporządzenie o Ochronie Danych Osobowych (General Data Protection Regulation, GDPR) and the Digital Operational Resilience Act (DORA).

In financial services, AI systems used for creditworthiness assessment, insurance risk scoring, or fraud detection face dual scrutiny. The Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) oversees financial institutions and is expected to act as a co-enforcer alongside the designated national AI supervisory body. DORA compliance – mandatory for financial entities from January 2025 – already requires ICT risk management frameworks. High-risk AI obligations layer on top: risk management documentation, logging requirements, and human oversight protocols must now be embedded into systems that KNF-regulated entities deploy. For a practical reference on how IP protection intersects with tech deployments in cross-border contexts, see our analysis of IP protection strategy for Luxembourg tech companies in Poland.

Manufacturing presents a different challenge. Computer-vision systems monitoring worker safety on production lines, AI-driven quality control that can halt machinery, and predictive maintenance tools integrated into safety-critical equipment all potentially qualify as safety components of regulated machinery. A Silesian automotive supplier using AI to inspect weld integrity in real time may not have considered itself an AI provider at all. Under the AI Act, it may be exactly that.

We advised a manufacturing client in the Mazowieckie region to restructure its vendor contracts after an internal audit revealed that its AI-assisted production monitoring system met the definition of a high-risk safety component under machinery regulation – a classification the vendor had not disclosed (autumn 2025). Realigning contractual liability and initiating the conformity process took approximately three months.

What does the step-by-step compliance procedure look like?

The compliance pathway for a high-risk AI system has five identifiable stages, each with its own documentation burden. Operators entering the process for the first time consistently underestimate stage two and stage five – internal risk management and post-market monitoring respectively. Both require ongoing resource commitment, not a one-time exercise.

Stage 1 – Classification assessment. The provider determines whether the system falls within a regulated sector or function. This is a legal analysis, not a technical one. It requires mapping the system's actual use case against the sector definitions. A 30-day internal review is a realistic minimum for a mid-sized organisation with limited AI governance infrastructure.

Stage 2 – Risk management system. High-risk providers must establish a documented risk management process covering the entire system lifecycle. This is not a static document. It must be updated continuously as the system evolves or as deployment context changes. Under EU AI governance doctrine, a risk management system that is not maintained is treated as absent.

Stage 3 – Technical documentation and data governance. Providers must compile technical documentation before placing the system on the market. Data governance obligations require that training datasets meet accuracy, representativeness, and bias-minimisation standards. For Polish operators handling personal data, this intersects directly with GDPR Poland obligations – data minimisation and purpose limitation principles apply simultaneously.

Stage 4 – Conformity assessment and CE marking. Most high-risk systems can self-certify through an internal conformity assessment. Systems in certain sensitive categories – biometrics, law enforcement – require third-party notified body involvement. Self-certification does not mean informal: the technical file must be audit-ready and retained for 10 years after the system is withdrawn from the market.

Stage 5 – Registration and post-market monitoring. Providers must register high-risk systems in the EU database maintained by the European Commission before deployment. Post-market monitoring must be active: providers collect and analyse performance data, report serious incidents to the national supervisory authority within 15 days, and update their risk documentation accordingly.

How do three business scenarios illustrate the compliance burden?

Abstract rules become tangible through concrete situations. Three scenarios common in Poland's commercial environment show how the classification and compliance obligations translate into operational decisions.

Scenario 1 – Manufacturing (automotive supplier, Silesia). A mid-sized Polish manufacturer integrates an AI vision system to detect defects in safety-critical components. The system controls whether parts proceed to assembly or are rejected. This is a safety-component AI embedded in a regulated product. The manufacturer is the provider. Compliance requires a full technical file, a risk management system covering the AI component specifically, and registration before the system goes live. Timeline from classification decision to deployment: approximately 6 months for a first-time compliance exercise.

Scenario 2 – Healthcare IT (hospital group, Małopolska). A hospital group deploys a third-party AI diagnostic tool for radiology image analysis. The tool is provided by an EU-based vendor with CE marking under the Medical Devices Regulation. The hospital is the deployer. Deployer obligations are lighter – but not absent. The hospital must ensure the system is used within its intended purpose, maintain human oversight protocols, and log decisions for audit. Staff must be trained to understand AI output limitations. If the hospital modifies the tool's configuration materially, it may shift into provider status.

Scenario 3 – Foreign investor (IT company, Warsaw). A German software company enters the Polish market with an AI-powered HR screening platform used by Polish employers to rank job applicants. The German company is the provider. Its Polish clients are deployers. The platform falls squarely within the employment category of high-risk systems. The German provider must register the system in the EU database before Polish deployers can lawfully use it. Polish deployers must verify registration and maintain their own human oversight documentation. For the German investor's Polish subsidiary structure, the interaction between AI Act obligations and corporate setup is worth examining alongside questions of legal entity continuity – including, at the other end of the corporate lifecycle, the liquidation of sp. z o.o. process and timeline.

We assisted a technology client in Pomerania to navigate dual obligations as both deployer of a third-party AI tool and provider of its own customised adaptation of that tool, securing a compliant structure before the August 2026 deadline (spring 2026). The key was early classification analysis rather than waiting for regulatory pressure.

What are the most common compliance mistakes – and how do you avoid them?

The complexity trigger in AI Act compliance does not come from any single obligation. It comes from the interaction of multiple simultaneous requirements: classification, documentation, data governance, human oversight, registration, and post-market monitoring must all function together. Operators who address them sequentially rather than in parallel routinely miss the August 2026 deadline.

The most common mistake is misidentifying the provider. A Polish company that customises, retrains, or substantially modifies an off-the-shelf AI system becomes a provider under the AI Act. Contracts that assign all compliance obligations to the original software vendor do not relieve the Polish operator of its legal status. This misallocation of responsibility is the single largest source of enforcement exposure for Polish deployers in the SME segment.

A second frequent error involves GDPR Poland interaction. High-risk AI systems processing personal data must satisfy both AI Act data governance requirements and GDPR obligations simultaneously. The Urząd Ochrony Danych Osobowych (Personal Data Protection Office, UODO) has enforcement authority over GDPR breaches. An AI Act compliance programme that ignores GDPR alignment risks triggering two parallel enforcement actions. Cross-border data flows add further complexity – for example, Polish companies transferring AI training data to non-EEA processors must address transfer mechanisms, as examined in our guide on data transfer from Poland to Switzerland: legal mechanisms.

A third mistake is treating the conformity assessment as a one-time event. Post-market monitoring obligations mean that a system compliant at launch may become non-compliant if its performance degrades, its deployment context changes, or its training data becomes outdated. Providers must build review cycles into their operational calendar – at minimum, annually, and after any significant system update.

Misidentifying deployer status when customisation creates provider obligations
Failing to align AI Act documentation with GDPR data governance requirements
Treating conformity assessment as a project rather than an ongoing process
Omitting EU database registration before deployment
Insufficient human oversight protocols for decisions affecting individuals

What to prepare before beginning the compliance process:

Inventory of all AI systems in use and their deployment context
Contractual documentation identifying provider and deployer roles
Data governance records including training data sources and quality controls
Existing risk management frameworks that can be extended to AI systems
Human oversight procedures and staff training records

Your organisation's specific AI deployment profile determines which obligations are most urgent. Non-compliance with registration requirements alone can preclude lawful deployment – an irreversible consequence if the August 2026 deadline passes without action. To receive an expert assessment of your AI Act classification status, contact info@kordeckipartners.com.

Frequently asked questions

Q: If we use a third-party AI tool and do not modify it, are we fully covered by the vendor's compliance?

A: Not entirely. As a deployer, you retain independent obligations: verifying that the system is registered in the EU database, maintaining human oversight protocols, ensuring the system is used within its intended purpose, and keeping logs of decisions made with AI assistance. The vendor's CE marking covers the product itself. Your deployment practices remain your responsibility. If you adapt the system's configuration materially – even through prompt engineering or fine-tuning – you may shift from deployer to provider status under EU AI regulation.

Q: How long does the conformity assessment process realistically take for a Polish SME?

A: For a self-certification pathway (which applies to most high-risk categories outside biometrics and law enforcement), a realistic timeline is 3 to 6 months from the start of the classification assessment to registration in the EU database. This assumes that technical documentation does not already exist and that internal risk management processes need to be built. Companies with existing ISO 9001 or ISO 27001 frameworks can compress this to approximately 2 to 3 months by extending existing documentation structures. Third-party notified body procedures add a further 3 to 6 months.

Q: Does the AI Act affect AI systems we have already deployed before August 2026?

A: General-purpose AI model obligations and some prohibitions apply from earlier dates. For high-risk systems already in service, EU AI regulation provides a transitional period: systems placed on the market before the application date and not substantially modified may benefit from a grace period running to August 2027 or August 2029, depending on the product category. However, "substantial modification" is defined broadly. Any update that changes the system's intended purpose, affects its performance on safety parameters, or alters the data it processes may reset the clock and trigger immediate compliance obligations. Early legal analysis of your existing deployments is the only way to confirm which transitional provisions apply.

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to AI Act compliance, IP protection, and technology regulation. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating EU digital regulation. To discuss your situation, contact info@kordeckipartners.com.