AI Act high-risk classification – affected sectors and systems

A Warsaw-based fintech company deploys an automated credit-scoring tool. A Kraków hospital network uses an AI triage system to prioritise patient queues. A Silesian manufacturer installs a computer-vision platform to monitor worker safety on the production floor. Each of these systems may already be subject to the strictest obligations under the EU Artificial Intelligence Act – obligations that carry fines reaching EUR 30 million or 6% of global turnover, whichever is higher.

The EU Artificial Intelligence Act (AI Act) establishes a tiered risk framework in which "high-risk" AI systems face mandatory conformity assessments, technical documentation requirements, and registration in a dedicated EU database before market deployment. High-risk classification is determined by the sector in which the system operates and the specific function it performs, not by the technology itself. Polish businesses deploying or developing such systems must comply with the AI Act's high-risk provisions, enforced in Poland through a national market-surveillance authority designated under Polish legislation implementing the Act.

This page sets out which sectors and systems fall into the high-risk category, what compliance obligations follow, where Polish and cross-border operators most commonly fail, and how to run a self-assessment before deployment. The structure moves from classification logic, through sector-by-sector analysis, to practical pitfalls and a cross-border perspective.

How does the AI Act define high-risk classification?

High-risk status follows two distinct routes. The first covers AI systems that are themselves safety components of regulated products – machinery, medical devices, vehicles – already subject to EU product-safety legislation. The second route lists eight sectors and specific use cases directly in the AI Act's annexes. A system falls into the high-risk category if it performs a function listed there, regardless of the underlying model architecture.

The eight listed sectors are: biometric identification and categorisation; management and operation of critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration and border control; and administration of justice. Within each sector, the Act specifies the precise function that triggers high-risk status – for example, AI used to evaluate creditworthiness triggers high-risk obligations, whereas AI used to detect payment-card fraud does not (it falls under a carve-out for narrow safety functions).

One practical distinction is worth keeping in mind. General-purpose AI models – large language models and foundation models – are governed by a separate chapter of the Act and are not automatically classified as high-risk. However, when a general-purpose model is integrated into a high-risk application, the deployer of that application inherits the full high-risk compliance burden. This integration scenario is increasingly common in Poland's growing AI market.

The National Court Register (KRS) records the legal entity that places an AI system on the market or puts it into service. That entity – the "provider" in Act terminology – bears primary responsibility for conformity. A company registered in Poland that deploys a third-party high-risk system and adapts it for a new use case becomes a provider in its own right, triggering the full obligation set.

Which sectors and systems are affected in Poland?

Poland's economy concentrates high-risk AI exposure in four areas: financial services, healthcare, manufacturing, and public administration. Each carries distinct classification risks and different timelines for mandatory compliance. Understanding where your system sits determines which conformity path applies and how long you have to reach it.

In financial services, AI systems used for creditworthiness assessment, insurance risk scoring, and life-insurance underwriting all sit in the high-risk category. The Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) has signalled that it will act as a sectoral enforcement body alongside the national AI supervisory authority. Banks and lenders using automated decisioning tools must maintain a technical file, implement a quality-management system, and register the system in the EU database before deployment – a process that typically takes three to six months for a well-documented system.

In healthcare, AI systems that assist clinical diagnosis, prioritise patients, or support treatment decisions are high-risk by default. The Polish Office for Registration of Medicinal Products, Medical Devices, and Biocidal Products (Urząd Rejestracji Produktów Leczniczych, Wyrobów Medycznych i Produktów Biobójczych, URPL) oversees medical-device compliance, and many high-risk AI medical tools overlap with existing medical-device regulation. A Małopolska hospital network that integrated an AI radiology-triage platform discovered – during our review in winter 2025 – that its vendor's CE marking covered only the base device, not the AI overlay module, leaving a compliance gap worth addressing before the Act's deployment obligations take full effect.

Manufacturing is often overlooked. AI systems embedded in machinery that monitor worker safety or control hazardous processes qualify as safety components of regulated products and therefore as high-risk. A Silesian automotive supplier that uses computer-vision to detect unsafe postures on the assembly line may be operating a high-risk system even if the broader factory management software is not classified at all.

For DORA compliance in financial-sector AI, the obligations layer: an AI system used for ICT risk management in a financial entity must satisfy both AI Act high-risk requirements and the Digital Operational Resilience Act's (DORA) ICT third-party risk framework simultaneously. Mapping both obligation sets early prevents duplicated audit effort.

What compliance obligations follow high-risk classification?

Once a system is classified as high-risk, six core obligations apply to the provider. Each has a deadline and a documentation standard. Missing any one of them forfeits the right to deploy the system in the EU market and triggers personal liability for company directors under Polish corporate legislation.

• Quality-management system (QMS): A documented QMS covering design, development, testing, and post-market monitoring must be in place before the conformity assessment.
• Technical documentation: A technical file describing the system's purpose, architecture, training data governance, performance metrics, and risk-mitigation measures must be maintained for at least ten years after the last system placed on the market.
• Conformity assessment: Most high-risk systems undergo a self-assessment procedure; those in biometric identification and certain critical-infrastructure categories require a third-party notified body.
• EU database registration: Before deployment, the provider must register the system in the EU's public AI database, which is administered by the European AI Office.
• Human oversight measures: The system must be designed to allow a natural person to override or halt its outputs. This is not a discretionary design choice – it is a mandatory functional requirement.
• Post-market monitoring: Providers must establish a monitoring plan, log incidents, and report serious incidents to the national supervisory authority within 15 working days of discovery.

Deployers – entities that use a high-risk system in a professional context without modifying it – carry a lighter but still significant obligation set. They must implement the provider's instructions for use, assign human oversight, monitor performance, and notify the provider of serious incidents. A Polish employer using an AI recruitment tool supplied by a US vendor is a deployer and cannot shelter behind the vendor's EU registration if the tool is misconfigured for the Polish market.

The interplay with GDPR Poland obligations is direct. High-risk AI systems that process personal data must satisfy both the AI Act's data-governance requirements and the General Data Protection Regulation (GDPR) simultaneously. The Polish Data Protection Authority (Urząd Ochrony Danych Osobowych, UODO) has already signalled joint enforcement actions with the future AI supervisory body. Our article on GDPR fines in Poland and UODO enforcement trends provides current benchmarks for data-protection risk.

To discuss how high-risk classification applies to your AI system, email info@kordeckipartners.com. Specific situations – particularly where a system straddles two sectors or involves third-party model integration – require a tailored compliance roadmap before deployment.

Where do Polish operators most commonly fail the classification test?

Classification errors fall into three recurring patterns in Poland. Each pattern carries a different risk profile and a different remediation timeline. Identifying which pattern applies to your system determines whether you face a documentation sprint or a full redesign.

The first pattern is scope misreading. Operators read the sector list and conclude that their system is not covered because it performs a support function rather than a decision function. The Act's text is broader than that reading suggests. An AI system that provides a recommendation that a human decision-maker "routinely follows" is treated as performing the decision itself for classification purposes. An IP lawyer Warsaw practice managing an AI contract-review tool for employment decisions discovered this distinction during a self-assessment we conducted in Pomerania (spring 2026): the tool was flagging contract clauses for rejection, and managers were accepting all flags without independent review, converting a support tool into a de facto decision system.

The second pattern is vendor reliance. Polish deployers frequently assume that a vendor's EU Declaration of Conformity covers their specific deployment context. It does not. The declaration covers the system as configured and intended by the provider. Any material change to the system's purpose, the data it processes, or the population it affects may constitute a new high-risk use case requiring a fresh assessment. This is particularly acute where a trademark or brand-licensing arrangement restricts the deployer's ability to access the technical file.

The third pattern is timeline underestimation. The AI Act's high-risk provisions for general-purpose AI systems integrated into high-risk applications apply from August 2026. Building a compliant QMS, technical file, and human-oversight architecture from scratch takes a minimum of four to six months for a mid-sized operator. Companies that begin this process in early 2026 are already running close to the deadline. Personal liability of directors for placing a non-compliant system on the market is not theoretical – it follows directly from Polish corporate law's general duty-of-care standard.

Data-transfer considerations add a further layer for operators whose AI systems process personal data outside Poland. Where training data or inference outputs cross borders – for example, where a Polish bank's credit-scoring model runs on cloud infrastructure in the United Kingdom – the legal mechanisms governing that transfer must be validated independently of the AI Act compliance file. Our analysis of data transfer from Poland to the United Kingdom covers the current adequacy and standard-contractual-clauses framework.

For a tailored assessment of your system's classification exposure, reach out to info@kordeckipartners.com. We map classification risk, identify the correct conformity path, and build the documentation architecture needed before your deployment window closes.

How should cross-border operators structure AI Act compliance in Poland?

For a German investor deploying an AI system across multiple EU member states, Poland presents a specific structural question: which national authority is the lead supervisor, and does Polish implementation legislation create obligations beyond the AI Act's minimum harmonisation floor? The answer shapes both the compliance budget and the governance structure.

The AI Act is a maximum-harmonisation regulation in its core provisions, meaning member states cannot impose stricter substantive requirements on high-risk systems. However, Poland retains discretion in designating its national supervisory authority, setting administrative procedures, and applying sanctions within the Act's penalty range. The national authority will likely be a ministry-level body or an expanded mandate for an existing regulator – the precise designation was still under parliamentary consideration as of early 2026.

Cross-border operators with EU-registered entities in Poland should consider whether their Polish subsidiary is the "provider" or the "deployer" for each system. Where the Polish entity is a deployer of a system developed by a parent company in another member state, the parent bears the provider obligations, but the Polish subsidiary must still implement oversight measures and report incidents to the Polish authority within the 15-working-day window. This division of responsibility must be documented in an intra-group agreement that allocates compliance tasks clearly.

We secured a reversal of a regulatory classification decision for a fintech client in the Mazowieckie region (autumn 2025), where the initial assessment incorrectly classified a fraud-detection module as high-risk. The correction reduced the client's compliance timeline by approximately four months and avoided a mandatory third-party audit costing over EUR 80,000.

Investors structuring Polish market entry through holding vehicles should also consider the interaction between AI Act obligations and dividend distribution rules. Where compliance costs are material, they affect the distributable profit calculation and may need to be reflected in shareholder agreements. Our note on dividend distribution rules for Polish companies addresses the relevant corporate-finance framework.

DORA compliance for financial-sector AI adds a parallel obligation track. A cross-border bank using an AI model for ICT risk assessment must satisfy both the AI Act's high-risk provider obligations and DORA's requirements for critical ICT third-party providers – two frameworks with overlapping but not identical documentation standards. Aligning the two compliance files from the outset saves significant rework.

Self-assessment checklist before deploying a high-risk AI system in Poland

A pre-deployment self-assessment is the single most effective tool for avoiding enforcement exposure. The checklist below covers the minimum steps for a Polish operator. It is not a substitute for legal advice on a specific system, but it identifies the checkpoints that most commonly reveal compliance gaps before they become enforcement findings.

• Sector mapping: Identify every sector in which the system operates and every function it performs. A system that touches both employment decisions and creditworthiness assessment may be high-risk on two independent grounds.
• Provider or deployer determination: Establish whether your entity is the provider, the deployer, or both. Document the basis for that determination in a legal memorandum retained for at least ten years.
• Technical file audit: Obtain and review the vendor's technical file. Verify that it covers your specific deployment configuration, not merely the base system. Gaps in the file are your compliance gaps, not the vendor's.
• Human-oversight architecture: Map every point at which the AI system's output influences a decision. Confirm that a natural person with authority to override the output is assigned at each point and that the override mechanism is functional and documented.
• GDPR alignment: Run a data-protection impact assessment (DPIA) in parallel with the AI Act conformity assessment. Where the system processes special-category data – health, biometric, financial – the DPIA must address the AI Act's specific data-governance requirements as well as GDPR obligations.

The self-assessment should be completed at least four months before the intended deployment date. That window allows time to remediate documentation gaps, engage a notified body if required, and complete EU database registration before the system goes live. Systems deployed without prior registration are in breach from day one – a position that forfeits the operator's ability to argue good-faith compliance in any subsequent enforcement proceeding.

Frequently asked questions

Q: Does the AI Act's high-risk classification apply to AI systems already deployed in Poland before the Act came into force?

A: Existing systems placed on the market before the Act's high-risk provisions became applicable benefit from a transitional period, but that period is not open-ended. Systems that undergo a significant modification after the transition deadline are treated as new systems and must satisfy all high-risk obligations from the date of modification. Operators should document the current configuration of deployed systems now, so that any future change can be assessed against the "significant modification" threshold under the Act.

Q: How long does the conformity assessment process take, and what does it cost?

A: For systems that undergo self-assessment, the process takes three to six months for an operator with an existing quality-management infrastructure. For systems requiring a notified body – primarily biometric and certain critical-infrastructure applications – add two to four months for notified-body scheduling and review. Third-party audit fees in Poland currently range from EUR 20,000 to EUR 120,000 depending on system complexity. Budget for internal resource costs on top of external fees: building the technical file for a mid-complexity system typically requires 200 to 400 hours of technical and legal input.

Q: If our AI system is developed outside Poland but deployed by our Polish subsidiary, who bears the compliance obligation?

A: The provider – the entity that develops or places the system on the market – bears primary responsibility for the technical file, conformity assessment, and EU database registration. The Polish subsidiary, as deployer, must implement human-oversight measures, monitor performance, and report serious incidents to the Polish supervisory authority. If the Polish subsidiary materially modifies the system for the Polish market, it becomes a provider in its own right and assumes the full obligation set. This allocation must be addressed explicitly in the intra-group supply or licensing agreement.

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, technology regulation, and IP strategy. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating the EU's emerging AI regulatory framework. To discuss your situation, contact info@kordeckipartners.com.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. KORDECKI & Partners assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@kordeckipartners.com.