Cover of the Healthcare Poland analysis “Trust is not yet deployment” — AI Act, EHDS, Living Lab, HeliX

Trust Is Not Yet Deployment: A Polish Survey on AI in Medicine Through the Lens of the Healthcare Poland Living Lab

An analysis by the Living Lab and operational sandbox of the Healthcare Poland Foundation. Legal status as of 12 November 2026.

The report “Poles on AI in Medicine. 2026 Edition”, prepared by UCE RESEARCH in substantive cooperation with the Medigent Foundation, portrays a cautiously open society: artificial intelligence, yes — but as support for the physician, not as a substitute. The authors read the results as evidence of rationality. Patients, in their view, intuitively pointed to the areas where technology relieves the system without encroaching on clinical competence.

From the perspective of the Healthcare Poland Living Lab and operational sandbox, this reading is right in principle but wrong on the map of risk. And it is the map of risk, not the map of sympathy, that determines what a hospital can safely deploy — and on what data.

Regulatory compliance tells us whether a solution may be deployed. Public opinion tells us whether people are willing to accept it. Only an operational test in a real clinical environment tells us whether it can be deployed: whether staff will actually use it, whether it fits the patient pathway, and whether it shifts risk somewhere else.

1. What the data say — and what they do not

The survey was conducted using the CAWI method on a sample of 1,017 people aged 18–80. 46.7% of respondents support the use of AI as support for physicians, 30.6% oppose it and 22.7% are undecided. Among supporters, the most frequently indicated uses were patient monitoring (37.9%), medical documentation (36.4%) and appointment scheduling (21.3%). Far fewer indicated medical imaging analysis (7.5%), diagnostics (6.1%) and treatment selection (4.7%).

A rigorous reading of these figures requires four caveats.

  1. Use-case shares were calculated only among supporters. Relative to the whole sample, monitoring was indicated by approx. 17.7% of respondents, documentation by approx. 17.0%, scheduling by approx. 9.9%, imaging analysis by approx. 3.5%, diagnostics by approx. 2.8% and treatment selection by approx. 2.2% (HCPL calculation).
  2. Not selecting an option is not opposition. The question was multiple-choice. The claim that Poles do not want AI in clinical decisions is an interpretation: the survey asked about areas of support. A co-author of the report, Dr Wojciech Francuzik, MD, notes that framing the question as supporting rather than replacing the physician may have raised acceptance.
  3. An online survey reaches digitally active people. Acceptance of remote tools is therefore likely to be overstated, while digitally excluded older adults — the main target group of remote monitoring — are under-represented.
  4. A declaration is not behaviour. The survey measures attitudes towards AI in the abstract, without a specific tool or a specific benefit, and only on the patient side. It says nothing about staff, whose acceptance determines whether a deployment survives its first quarter.

The survey is thus a valuable signal for the social layer of assessment. It is not evidence that any given solution can be deployed.

2. The map of acceptance versus the map of risk

In the HCPL Living Lab every solution is assessed in three layers. Technological: does it work, and with what quality against an agreed baseline. Operational: does it fit the patient pathway and the workflow, how much time does it add and how much does it save. Social: do staff and patients accept it, and do they understand how responsibility shifts. Set against these layers, the survey results paint a less obvious picture than the headlines.

Chart: share of respondents per AI use area in medicine versus regulatory scrutiny
Map of acceptance versus map of risk. Data: UCE RESEARCH / Medigent Foundation; recalculation and assessment: Healthcare Poland.
AreaIndications (whole sample)Regulatory statusMain deployment riskHCPL assessment
Patient monitoringapprox. 17.7%Software that interprets signals and generates alerts is, as a rule, a medical device (MDR Rule 11: class IIa; IIb where variations of vital parameters could result in immediate danger) and a high-risk AI system.Alarm fatigue; no response pathway for night-time alerts; missed cases; maintenance costs once project funding ends.Right direction, wrong classification. An algorithm that decides which signal is an alarm sets priority. That is triage — only continuous.
Medical documentationapprox. 17.0%Transcription and summarisation tools usually fall outside the MDR, and therefore carry no obligation to provide clinical evidence. They process special-category data and often record the patient conversation (a data protection impact assessment is required).Erroneously generated content enters a legally binding record and propagates into subsequent decisions; “approval without reading”.Risk underestimated. It is low-visibility, not low.
Appointment schedulingapprox. 9.9%Outside the MDR as long as the system does not prioritise by symptoms — at which point it becomes triage. Systems interacting with patients must disclose that the interlocutor is AI.Exclusion of older adults; integration with e-registration. AI does not create new appointment slots.Risk correctly assessed, effect overestimated. If the bottleneck is service capacity, the queue will not shrink.
Medical imaging analysisapprox. 3.5%A class IIa or IIb medical device subject to conformity assessment involving a notified body. Radiology dominates authorisations of AI-enabled medical devices (FDA list).Automation bias; gradual deskilling; an unclear role in the worklist — second reader or prioritisation of reports.Wrong. This is the area with the strongest evidence base, already working as supervised support — exactly what respondents expect.
Diagnostics and treatment selectionapprox. 2.8% / approx. 2.2%A medical device of class IIa–III, often with a clinical investigation; a high-risk AI system.A model that performs in one hospital may fail in another; need for real-world validation; allocation of responsibility.Right. Caution proportionate to the impact on the patient’s health and life.

Note: in December 2025 the European Commission proposed an amendment to MDR Rule 11 (COM(2025) 1023, procedure 2025/0404(COD)). The proposal has not been adopted. Its final wording may change the classification of some medical software and, indirectly, its status under the AI Act.

A paradox emerges. We most readily accept what the regulator sees least, and approach most cautiously what undergoes the fullest assessment. A note-generation tool can reach the consulting room without clinical evidence, even though its errors end up in the medical record. An algorithm supporting CT reporting undergoes third-party conformity assessment, yet attracts the greatest reservation. Public acceptance therefore cannot substitute for risk assessment — neither in a hospital’s procurement decision nor in public policy.

3. Human oversight: a principle that must be measured

Respondents and the European legislator agree: the final decision belongs to a human. Formal oversight, however, is not real oversight. A physician without the time, competence or information about model uncertainty does not oversee — they approve. Automation bias is well documented in research on automation.

In a Just Culture, responsibility goes hand in hand with a real ability to object. A person cannot be held accountable for a decision that the work system did not allow them to challenge. This is why, in HCPL pilots, human oversight is a metric, not a declaration. We measure:

  • how often staff correct the system’s suggestions, and in which situations;
  • how long verification takes and who performs it;
  • how staff respond to erroneous suggestions — studied on retrospective data, with no risk to patients;
  • how many minutes a day the solution adds and how many it saves, and at whose expense.

We treat the promise of “physician time regained” the same way. It is a hypothesis, not a fact. It requires measuring working time before deployment and answering where that time goes: to the conversation with the patient, or to more appointments. The time consumed by checking AI output must also be counted.

4. A hospital’s compliance calendar: the AI Act and the EHDS

The AI Act (Regulation (EU) 2024/1689) determines how a hospital may use AI systems. The European Health Data Space — EHDS (Regulation (EU) 2025/327) — determines on what data those systems can be developed and evaluated. The two calendars converge in 2027–2029. A hospital using an AI system is a deployer under the AI Act, and the scope of its obligations depends on the class of the system and on the date. The AI Act calendar was amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), in force since 27 July 2026.

Timeline of AI Act and EHDS obligations for hospitals, 2025–2031
AI Act and EHDS calendar for hospitals — as of 12 November 2026.
  • From 2 February 2025 — AI literacy (Article 4 AI Act). As amended by Regulation 2026/1744, providers and deployers take measures to support the AI literacy of staff operating AI systems on their behalf.
  • 26 March 2025 — the EHDS Regulation entered into force, opening the transition period.
  • From 2 August 2026 — transparency obligations (Article 50 AI Act). Systems intended to interact directly with people must disclose that the interlocutor is AI. Hospitals should verify this with the provider of their registration chatbot or voicebot.
  • Polish Act of 3 July 2026 on artificial intelligence systems — establishes the Commission for the Development and Security of Artificial Intelligence (KRiBSI) as the national supervisory authority, responsible among others for regulatory sandboxes, free of charge for micro, small and medium-sized enterprises. The Commission begins operating in November 2026.
  • March 2027 — deadline for the European Commission to adopt key EHDS implementing acts.
  • By 2 August 2027 — deadline for establishing national AI regulatory sandboxes (postponed by Regulation 2026/1744).
  • From 2 December 2027 — obligations for high-risk systems listed in Annex III to the AI Act. In healthcare this includes emergency healthcare patient triage systems (point 5(d)) and systems assessing eligibility for essential public services, including healthcare services (point 5(a)). Bodies governed by public law and private entities providing public services must carry out a fundamental rights impact assessment before deploying such a system (Article 27) and notify the market surveillance authority of its results.
  • From 2 August 2028 — obligations for AI that is a medical device or a safety component of one, where the device is subject to third-party conformity assessment (Article 6(1) AI Act). Market surveillance is, as a rule, exercised by the authority competent for medical devices (Article 74(3)).
  • March 2029 — EHDS: patient summaries, ePrescriptions and eDispensations are exchanged in all Member States; secondary-use rules begin to apply to most data categories, including data from electronic health records. Access to data for research and innovation requires a permit issued by a health data access body.
  • March 2031 — EHDS: medical images, laboratory results and hospital discharge reports; secondary-use rules extend to the remaining categories, such as genomic data.

For both groups of high-risk systems, a hospital as deployer must (Article 26 AI Act): use the system in accordance with the provider’s instructions; assign oversight to people with the necessary competence, training and authority; ensure input data are relevant where it controls them; monitor the system’s operation and report risks and serious incidents; keep logs for at least six months; inform workers and their representatives before deployment; and, for Annex III systems, inform patients that the system supports decisions concerning them.

Postponed deadlines are not an exemption. They are a window. For hospitals and providers they mean two years to gather real-world evidence, put data governance in order and build procedures before the obligations apply. A hospital that starts preparing in 2028 will start too late.

5. The Healthcare Poland validation infrastructure

An operational test requires infrastructure: a place where a solution meets a real clinical process, an environment in which it can be safely tested on data, and an independent assessment of the result. Healthcare Poland builds these layers as a single sequence — from the qualification of a submission to a report that the director of another hospital can use for their own decision.

Diagram of the Healthcare Poland validation infrastructure: from qualification to conformity assessment readiness
Healthcare Poland validation infrastructure — each module can be commissioned separately.
  • Living Lab Healthcare — validation and pilots of MedTech and AI solutions in a real clinical environment, with operational and social assessment. Pilot terms, confidentiality and liability are agreed before the start.
  • Operational sandbox — an isolated validation environment working on synthetic or anonymised data, in development, scientific, regulatory and commercial modes. It complements, rather than replaces, the regulatory sandboxes run by KRiBSI.
  • HeliX — Health Ecosystem for Learning and Innovation Across Sovereign Data Space — a European federated learning platform for health data: data stay at the source, and the algorithm travels to the data. A consortium of 14 partners from Portugal, Italy, Hungary, Germany and Poland is coordinated by Health Cluster Portugal; the project runs from September 2025 to September 2028 under the Interregional Innovation Investments (I3) instrument. Healthcare Poland is the only Polish partner: it leads the platform’s regulatory and policy alignment task (GDPR, AI Act, cybersecurity, EHDS) and is responsible for regional coordination in Poland. This is direct preparation for the EHDS world, in which secondary use of data will require permits, and federated architectures will require evidence that data never leave the institution.
  • Open HCPL HIS — a Polish distribution of the open-source OpenEMR system with native FHIR R4 and SMART on FHIR (GPLv3 licence), designed for NIS2 requirements; in preparation for piloting as a reference environment for integration testing of AI solutions.
  • Quality, Audit and Certification Centre — assessment of results independent of validation. The AICACT SDAI standard developed here (currently in public consultation) assesses the AI provider, its processes and the completeness of the documentation disclosed to buyers. It is not a conformity assessment under the MDR or the AI Act and does not replace CE marking.
  • HCPL Academy — competence programmes for clinical staff and management.

The HeliX project (Grant Agreement No. 101228287) is co-funded by the European Union. Views and opinions expressed are however those of the author only and do not necessarily reflect those of the European Union or the European Innovation Council and SMEs Executive Agency (EISMEA). Neither the European Union nor the granting authority can be held responsible for them.

6. What Healthcare Poland can deliver

The Healthcare Poland Foundation does not replace the KRiBSI regulatory sandbox or the conformity assessment carried out by a notified body. We prepare for them and provide evidence from practice. Each module can be commissioned separately — there is no need to take the whole package.

A. Technology validation — for providers and hospitals testing a solution

  1. Qualification of the submission. Evaluation under MedTechID (25 qualifying questions), assessment of the technology readiness level (TRL), and reduction of the submission to a specific use case for a specific user. Output: an assessment card with a decision and rationale — including when it is too early for a pilot.
  2. Triage Sprint (2–3 weeks). A map of the applicable rules (MDR/IVDR, AI Act, GDPR, EHDS, medical records law), a preliminary risk classification and a recommended pathway: operational sandbox, regulatory sandbox, or both in sequence.
  3. Living Lab pilot / 90-day validation sprint. A protocol with a baseline, metrics and a stopping criterion agreed before the start. Assessment in three layers: technological, operational and social, covering staff and patients. A report with a recommendation: deploy, deploy conditionally, repeat, or do not deploy. Negative results are reported as carefully as positive ones.
  4. Federated validation on data — design of a test in which the algorithm travels to the data and the data never leave the institution, with the legal layer (legal basis for processing, controller roles) prepared before the start.
  5. Preparation for conformity assessment. Gap analysis and documentation for the MDR/IVDR and the AI Act. HCPL is not a notified body and does not issue CE marking — we prepare for an assessment carried out by an authorised body.
  6. Ongoing governance support. Regulatory monitoring and maintenance of readiness after deployment.

B. Hospital readiness for the AI Act and the EHDS

  1. Inventory and classification of AI systems used in the institution — including functions embedded in HIS, PACS or registration systems that are not always recorded in any register.
  2. Compliance audit of tools already in use — gap analysis against deployer obligations: the human oversight model, log retention, incident reporting procedure, information for staff and patients.
  3. Fundamental rights impact assessment (FRIA) and a consistent data protection impact assessment (DPIA) — for systems that require them.
  4. Data governance and EHDS readiness — data mapping, interoperability and preparation for making data available under health data access body permits.
  5. AI literacy programme for staff and management, delivered through the HCPL Academy.
  6. Pre-procurement assessment of AI solutions — based on the ten questions of the AI Buyer’s Guide: requirements for tender specifications, questions for the provider and acceptance criteria, including the safety assessment of medical documentation tools.
  7. NIS2 cybersecurity — audit and maturity plan where an AI deployment touches the hospital’s critical infrastructure.

7. Five principles for hospitals for the next two years

  1. Inventory first, procurement second. AI functions are often embedded in systems a hospital already uses — and are not always recorded.
  2. No pilot without a baseline and a stopping criterion. A pilot that cannot fail is not a test.
  3. In monitoring, design the response first. Who responds to an alert at three in the morning, within what time and on what basis?
  4. Treat documentation tools as systems with clinical impact — with an assessment of note quality and a data protection impact assessment before deployment.
  5. Measure staff acceptance before the start. Lack of acceptance and an unplanned workload are a frequent cause of the quiet death of pilots.

In lieu of a conclusion

Public trust in AI in medicine is capital — and like all capital, it is easily squandered. One deployment is enough: one that promised physician time regained and delivered unstaffed night-time alarms and notes nobody read. Responsibility for technology does not end with regulatory compliance or a survey result. It is tested where the patient lies: in the hospital, at the bedside, at three in the morning. That is where we run our tests.

Frequently asked questions

When must hospitals apply AI Act obligations for high-risk systems?

Following the amendments introduced by Regulation (EU) 2026/1744: from 2 December 2027 for Annex III systems (including emergency healthcare patient triage) and from 2 August 2028 for AI that is a medical device subject to third-party conformity assessment. The AI literacy obligation has applied since 2 February 2025 and transparency obligations since 2 August 2026.

What does the EHDS change for AI development in hospitals?

From March 2029, secondary-use rules begin to apply to most categories of health data, including data from electronic health records. Access to data for research and innovation will require a permit from a health data access body. A hospital that puts its data governance in order early will be ready both to make data available and to take part in federated projects.

What is the Healthcare Poland Living Lab?

It is a model for validating MedTech and AI solutions in a real clinical environment. Every pilot has a baseline, metrics and a stopping criterion agreed before the start, and the result is assessed in three layers: technological, operational and social.

What is the HeliX project?

HeliX (Health Ecosystem for Learning and Innovation Across Sovereign Data Space) is a European project building a federated learning platform for health data, delivered by a consortium of 14 partners in 2025–2028. The Healthcare Poland Foundation is the only Polish partner and leads the platform’s regulatory and policy alignment task, including with respect to the EHDS and the AI Act.

Does Healthcare Poland issue CE marking?

No. HCPL is not a notified body. We carry out readiness audits, gap analyses and preparation for conformity assessment, as well as certification against our own standards, such as AICACT SDAI, which does not replace the conformity assessment required by the MDR and the AI Act.


Hospitals and technology providers interested in Living Lab qualification, a validation sprint or an AI Act and EHDS readiness audit: innowacje@healthcarepoland.pl. Each module can be commissioned separately. More: HCPL Innovation Center · HeliX project · AICACT SDAI · Project map.

Author: Michał P. Dybowski — President and Co-founder of the Healthcare Poland Foundation.

Sources

Healthcare Poland Logo