.png)
Back to home
Back to home
Artificial intelligence is already part of day-to-day clinical work. It reviews medical images, supports clinical decisions, transcribes consultations, drafts documents, manages appointments and powers patient-facing chatbots.
That does not mean every AI tool used by a clinic is automatically high-risk. It does mean that clinics need to know which systems they use, what data those systems process, how they affect people and who remains accountable for the outcome.
Official requirement: the EU AI Act sets different obligations for different AI systems and for the organisations that develop, sell or use them.
In simple terms: start by making a list of every AI tool used in the clinic. Write down what it does, whose data it receives, whether it can affect a medical or employment decision and who checks its work. Only then can you understand which rules apply.
The deadline depends on the type of system. Transparency rules began applying on 2 August 2026. After the AI Omnibus, the main requirements for high-risk systems listed in Annex III apply from 2 December 2027. The corresponding requirements for high-risk AI built into regulated products listed in Annex I apply from 2 August 2028.
In simple terms: a chatbot, recruitment tool and AI-enabled medical device may follow different timelines. Do not apply one checklist to every product.
These dates reflect the AI Omnibus that entered into force on 27 July 2026. They should not be treated as a reason to postpone preparation. Mapping systems, reviewing contracts and setting up governance can take months, especially when several departments and external suppliers are involved.
An AI audit should cover clinical tools and ordinary software with embedded AI features. Common examples include:
For each system, record the supplier, intended purpose, users, data categories, affected individuals and influence on clinical or administrative decisions. Also note whether the system is used exactly as the supplier intended. That detail can change the clinic’s legal role.
Official term: most clinics will be deployers. This means they use an AI system in their professional work but did not create or place that system on the market.
In simple terms: if the clinic buys a ready-made imaging tool and uses it as instructed, it is usually a user of that system.
Official term: a clinic may become a provider if it develops a system, markets one under its own name, makes a substantial modification or changes its intended purpose in a way covered by the AI Act.
In simple terms: if the clinic rebuilds a purchased tool, changes what it is supposed to do or sells it under its own brand, it may no longer be treated as an ordinary user. Its responsibilities can increase significantly.
The same organisation may hold different roles for different products. A clinic can be a deployer of an imaging tool, for example, while acting as a provider of a separately developed patient-triage system.
Official answer: no. Classification depends on the system’s intended purpose, function and regulatory context.
An AI system may be high-risk when it is a safety component of a regulated product, or is itself such a product, and that product must be assessed by an independent conformity-assessment body. This can include certain AI-enabled medical devices under the Medical Devices Regulation (MDR) or the In Vitro Diagnostic Medical Devices Regulation (IVDR).
In simple terms: the presence of AI is not enough. What matters is what the system is designed to do, how much its output can affect a person and whether it is part of a regulated medical product.
Other healthcare tools may fall outside the high-risk category but still trigger transparency, privacy, consumer-protection, medical-device or professional requirements. “Not high-risk under the AI Act” does not mean “unregulated”.
Marketing labels such as “AI-powered”, “clinically validated” or “EU compliant” are not evidence of compliance on their own.
Before procurement or deployment, ask the supplier for:
Contracts should allocate responsibility for updates, performance monitoring, security incidents and regulatory changes. A supplier questionnaire is useful, but it should be supported by documents that the clinic can retain and review.
Official requirement: for high-risk AI, the clinic must assign oversight to people with the necessary competence, training, authority and support.
In simple terms: putting a doctor’s name under an AI-generated result is not enough. That person must understand the system, be able to question its output and have the authority to stop or override it.
The clinic should define:
Staff also need to understand automation bias: the tendency to trust an automated result simply because it appears precise or comes from software. The person reviewing the output must know the system’s intended use and limitations, not merely how to operate the interface.
Official position: the AI Act does not replace the GDPR, medical-confidentiality rules, the MDR, the IVDR or national healthcare law. These rules apply alongside one another.
In simple terms: passing an AI Act check does not automatically make a product safe to use with patient data.
Health data receive additional protection under the GDPR. Before sending patient information to an AI service, the clinic must confirm why it is legally allowed to process that data.
It should also ask a few practical questions: does the service need all this information, where is it stored, how long is it kept, is it used to train the model, does it leave the European Economic Area and is a formal privacy-risk assessment required?
Employees should not paste clinical notes, photographs, consultation recordings or other identifiable patient information into an unapproved public AI tool.
Removing a name may not be sufficient: a rare diagnosis, date, location and treatment history can still identify someone when combined.
Official requirement: when a patient interacts directly with a covered AI chatbot or another interactive AI system, they should be told that they are dealing with AI unless this is already obvious. Article 50 also contains disclosure rules for certain deepfakes and other AI-generated or manipulated content.
In simple terms: do not let a patient believe that a chatbot, synthetic voice or virtual doctor is a real member of staff.
A practical chatbot notice could read:
You are communicating with an AI virtual assistant. It provides general information and does not replace a medical consultation. If you need urgent medical help, contact the emergency services.
The notice should be visible at the point of interaction. Patients should also have a straightforward way to reach a human when the issue cannot be handled safely by automation.
High-risk systems under Annex III that make or support decisions about individuals may trigger additional information duties for deployers. The exact notice should therefore reflect the system, the decision and the applicable national rules.
Official requirement: organisations using high-risk AI must monitor it according to the instructions. If the automatically generated activity logs are under the clinic’s control, Article 26 requires them to be kept for an appropriate period of at least six months, unless another EU or national rule says otherwise.
In simple terms: the clinic should be able to reconstruct what happened. Which version of the system was used? What result did it produce? Who reviewed it? Was the recommendation accepted, rejected or overridden?
The clinic needs a documented response when:
Depending on the circumstances, the clinic may need to suspend use and notify the provider, distributor or relevant authority. These decisions should not be improvised after an incident.
☐ Appoint an owner for AI governance.
☐ Build a register of approved and unapproved AI tools.
☐ Map data flows and prohibit uncontrolled use of patient data in public AI services.
☐ Classify systems and document the reasoning.
☐ Review chatbots and AI-content disclosures.
☐ Create a concise internal AI policy.
☐ Train relevant staff for the systems and decisions they oversee.
☐ Add AI due diligence to procurement.
☐ Review supplier contracts and documentation.
☐ Define human-oversight and escalation procedures.
☐ Create an error and incident log.
☐ Separate potential Annex III systems from AI embedded in Annex I products.
☐ Review AI functions in medical devices under the MDR or IVDR.
☐ Ask suppliers for a dated compliance roadmap.
☐ Update Data Protection Impact Assessments where necessary.
☐ Test whether logs, monitoring and override controls work in practice.
☐ Check the national rules in every EU country where the clinic operates.
Yes. A clinic’s size does not automatically place it outside the AI Act. Its obligations depend on its role, the system’s classification and how the system is used. Some simplified measures may apply to smaller organisations, but size is not a general exemption.
Potentially, but only within the clinic’s approved governance, privacy and security rules. Identifiable patient data should not be entered into an unassessed public service. AI-generated medical content must also be checked by a qualified person before it influences care or patient communication.
The answer depends on the product’s intended purpose, medical-device status, conformity assessment and applicable healthcare law. A clinic should not treat an AI output as an autonomous diagnosis merely because the software can generate one. The final workflow must match the product’s authorised use and provide the required professional oversight.
No. Disclosure depends on the type of system and how it affects or interacts with the person. Direct interaction with a covered chatbot, certain synthetic or manipulated content, and some high-risk AI-assisted decisions can trigger specific information duties.
No. The two frameworks operate together. A system may comply with an AI Act requirement and still create a GDPR issue if patient data lack a valid legal basis, are excessive, are retained too long or are transferred without adequate safeguards.
AI Act readiness does not start with buying a “certified” product or downloading a policy template. It starts with visibility: which tools are in use, what they do, which data they receive and who can challenge their output.
Once that map exists, the clinic can prioritise the systems that affect clinical decisions, process sensitive data or interact directly with patients. That produces a workable compliance plan rather than a folder of documents detached from everyday practice.
Adore Digital works at the intersection of healthcare expertise, AI tools and Baltic/EU regulatory awareness. We also examine the local requirements relevant to each market and recommend specialist legal or regulatory review where the question goes beyond marketing and operational guidance.
This article is for general information and does not constitute legal advice. Requirements depend on the system, the organisation’s role, the country of operation and the applicable healthcare, medical-device and data-protection rules.
