Regulation & Governance

Prohibited practices

A small, specific list of uses banned outright since February 2025 — including certain manipulative techniques, social scoring, and inferring emotions in the workplace or in education, subject to defined exceptions such as medical or safety purposes.

In healthcare: Rarely relevant to clinical software, and occasionally very relevant to workforce and facilities proposals. Emotion inference on staff is the example that most often surfaces in a healthcare organisation, usually attached to a wellbeing or productivity pitch.

Transparency obligations

Duties that attach to certain uses regardless of risk classification: telling people they are interacting with an AI system unless it is obvious, and marking synthetic or manipulated content.

In healthcare: Directly relevant to patient-facing chatbots, automated messaging and synthetic media in patient information. Applies from 2 August 2026 and is usually straightforward to satisfy if it is designed in rather than bolted on.

High-risk — Annex III

Listed use cases in defined areas such as employment and worker management, education, essential public and private services — including emergency services and, under point 5(d), AI systems used for triage of patients in emergency healthcare — and certain uses by public authorities.

In healthcare: Recruitment screening, workforce allocation and some access-to-service decisions can land here. Most of this route is unrelated to whether the tool is clinical — but Annex III point 5(d) specifically covers AI systems used for emergency healthcare patient triage.

High-risk — regulated products (Article 6(1))

Two conditions must both be met: the AI system is a safety component of, or is itself, a product covered by the Annex I harmonisation legislation; and that product is subject to third-party conformity assessment under that legislation.

In healthcare: This is the route by which many medical-device AI systems become high-risk — but only when the third-party assessment condition is also met. A self-certified class I device does not satisfy the second condition through that route.

None of these

A system that is not prohibited, not in Annex III, not high-risk through the product route, and not caught by a transparency duty.

In healthcare: Common, and worth saying out loud. Many operational and administrative tools sit here. General AI-literacy duties and every other regime — data protection, professional standards, clinical safety — still apply.

Provider

The actor that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark.

Carries: The bulk of the obligations for high-risk systems: risk management, data governance, technical documentation, logging, transparency to deployers, human-oversight design, accuracy and robustness, quality management and conformity assessment.

Deployer

The actor using an AI system under its own authority in a professional capacity. Most healthcare organisations, most of the time.

Carries: A narrower, operational set: use the system in accordance with the instructions, assign competent human oversight with the authority to act, ensure input data is relevant for the intended purpose where you control it, keep logs where applicable, inform affected workers and people where required, and cooperate with authorities.

Becoming a provider without meaning to

An organisation that puts its own name on a system, changes its intended purpose, or substantially modifies a high-risk system.

Carries: Provider obligations for the system as changed. Teaching guidance: treat 'we fine-tuned it on our own data and rebranded it' as a governance trigger requiring specialist advice, not as a configuration detail.

1. Wellbeing dashboard inferring staff emotional state

A supplier offers a tool that analyses tone of voice in recorded handover calls to infer stress and fatigue in ward staff, presenting an anonymised team-level 'wellbeing index' to line managers. It is pitched as a workforce retention aid, not as a clinical or occupational-health instrument, and no medical or safety purpose is claimed for it.

2. Shortlisting tool for nursing recruitment

HR proposes software that scores and ranks applications for nursing posts against the job description, producing a shortlist that recruiting managers review before interview. No patient data is involved and the tool has nothing to do with clinical care.

3. CT triage software, class IIa with notified-body certification

The imaging triage system described earlier: CE-marked under MDR as a class IIa device with a notified body involved in the conformity assessment, intended to prioritise studies with suspected time-critical findings on the reporting worklist.

4. Patient-facing information chatbot on the website

A conversational assistant on the public website answers questions about visiting hours, preparation for common procedures and how to contact a department. It is explicitly not intended to give clinical advice, and clinical questions are routed to a human contact route.

5. Theatre-list sequencing optimiser

An internal tool that proposes an order for elective theatre lists to reduce turnaround gaps, taking account of equipment and staffing constraints. A scheduling coordinator reviews and adjusts the proposal, which does not determine whether or when any individual patient receives treatment.

6. Sepsis alerting module, self-certified class I

A supplier offers an early-warning module for suspected sepsis, CE-marked as a class I medical device under a self-certification route with no notified body involved in the conformity assessment.