Poland’s HealthAI agreement: what it means for healthcare AI governance

What has been agreed

HealthAI describes the agreement as a one-year cooperation framework. Poland’s accession pathway includes participation in the Leadership Group of HealthAI’s Community of Practice, peer exchange with governments and work towards possible membership of the Global Regulatory Network.

Reuters reported on 22 October that there is no fixed timetable for Poland’s potential accession. Poland would become the network’s second EU Member State after Portugal if the process is completed.

These are reported and announced governance arrangements. The agreement is not an EU legislative act, a Commission decision or evidence that Poland has already completed the network’s qualification process.

What the network can and cannot establish

HealthAI says its network supports regulatory cooperation, access to information about reviewed healthcare AI tools and a real-time warning system for harmful incidents. Those functions could improve early detection and help authorities compare how risks emerge across health systems.

Network participation should not be presented as regulatory approval. A HealthAI review or directory entry does not, without a specific legal basis, replace CE marking, conformity assessment, clinical evaluation, data-protection compliance or procurement due diligence. It also does not determine whether a system is high-risk under the AI Act.

For suppliers, the safe commercial description is therefore factual: identify the relevant programme, review or participation status and explain what it covered. Avoid broader claims such as EU approved, regulator certified or clinically safe unless a defined authority and process support them.

Healthcare AI is not automatically high-risk under the AI Act

Article 6(1) of the EU AI Act classifies an AI system as high-risk where it is a safety component of, or is itself, a product covered by Annex I legislation and the product must undergo third-party conformity assessment. Annex I includes the Medical Devices Regulation and the In Vitro Diagnostic Medical Devices Regulation.

The conditions are cumulative. An appointment-booking tool, administrative assistant or general wellness application is not automatically high-risk merely because it is used in healthcare. Classification depends on the system’s intended purpose, whether it is medical-device software or a safety component, the applicable device class and whether third-party conformity assessment is required.

Annex III separately covers specified uses, including emergency healthcare patient triage. Businesses should classify the actual use case rather than relying on the broad label healthcare AI.

Existing product and data rules remain separate

Where software has a medical purpose, the Medical Devices Regulation or In Vitro Diagnostic Medical Devices Regulation may require clinical or performance evidence, risk management, technical documentation, post-market surveillance and incident reporting. The Commission’s medical-device software guidance stresses that qualification and classification turn on intended purpose and functionality.

Healthcare deployments also commonly involve health data, which is special-category personal data under the GDPR. Controllers need an Article 6 lawful basis and an applicable Article 9 condition, together with transparency, security, minimisation, retention and rights arrangements. Participation in an international network does not supply those legal grounds.

If incident information is shared across organisations or borders, the parties should define what data is necessary, who is responsible, how confidential and personal information is protected and which statutory reporting channels remain mandatory. A voluntary warning network should complement, not displace, notifications required by data-protection, medical-device or cybersecurity law.

Practical actions for healthcare AI businesses

1. Write a precise intended-purpose statement covering users, patients, decisions and the role of the AI output.
2. Assess separately whether the software is a medical device, whether Article 6(1) or Annex III of the AI Act applies and which entity is the provider or deployer.
3. Map the evidence required across clinical evaluation, performance, bias, cybersecurity, human oversight and post-market monitoring.
4. Create one incident taxonomy linking product-safety, data-breach, cyber and contractual reporting thresholds without treating them as interchangeable.
5. Set rules for sharing incident data with networks, regulators and customers, including minimisation, confidentiality, privilege and international transfers.
6. Verify what any external review or directory entry actually assessed before using it in sales, tenders or investor materials.
7. Record material model, data, workflow and intended-purpose changes and decide when they require revalidation or renewed conformity analysis.
8. Give clinical and operational users clear limitations, escalation routes and the ability to challenge or override outputs where appropriate.

The governance significance

Poland’s agreement is best understood as a step towards shared regulatory learning. Healthcare AI incidents can reveal recurring weaknesses in data quality, human oversight, security and post-market monitoring across jurisdictions. Faster and more structured information exchange may help authorities and health systems respond earlier.

For businesses, however, international participation is an additional governance layer rather than a compliance passport. The defensible position remains product-specific: classify the system, identify the applicable law, retain evidence and explain accurately what each external review proves.