Article 6 and Annex III — Classification
Whether a function here is high-risk turns on its intended purpose. Two routes matter in healthcare: Annex I, where the AI is a safety component of a product already regulated as a medical device, and Annex III point 5(d), emergency patient triage.
Where a function is used only to draft documentation from a consultation the clinician then edits, the platform's position is that it is a typing aid rather than a decision system. That position is stated so you can challenge it, not so you can inherit it.
Article 9 — Risk management system
A continuous, documented risk-management process across the lifecycle is a manufacturer's process obligation, not a system behaviour.
What the platform contributes is that the failure modes are explicit: when no model is available for a task in a zone, the router fails loudly rather than quietly substituting one.
Article 10 — Data and data governance
Personal data reaching a model is stripped of identifying detail first, and that happens in-zone rather than on the way to somewhere else.
Training-data governance — provenance, representativeness, bias examination — applies to whoever trains a model. Where you bring your own model, it is yours; where the platform routes to one, the governing record is the model's.
Article 11 and Annex IV — Technical documentation
The technical file describing the system, its purpose, its architecture and its validation is a document set.
Article 12 — Record-keeping
Every model invocation is recorded: which tool was called, how long it took, and whether it succeeded. The trail is append-only and queryable, so a reconstruction after the fact is a query rather than an archaeology project.
Every clinical proposal carries the chain that produced it — the observations it rested on, the knowledge-base edges it traversed, and the versions of both — and that chain is reproducible.
Article 13 — Transparency and information for deployers
A proposal states what it is and cites what it rests on; a chain that cannot cite its source is rejected at the output boundary rather than shown with a caveat.
Which model answered a given task, in which zone, is determined by declared routing rather than by whatever happened to be available.
Instructions for use, intended purpose, known limitations and expected accuracy are documentation you receive.
Article 14 — Human oversight
The clinician is the decision-maker: an AI-produced clinical artefact passes a review checkpoint — accept, modify or reject — before it becomes part of the record.
Oversight is only real if the person can act on it. The platform's contribution is the proposal stance and the evidence chain; whether your clinicians are given the time and standing to exercise it is an organisational matter.
Article 15 — Accuracy, robustness and cybersecurity
Model responses are constrained to a structured form with byte-stable prompts, so the same input does not become a different shape of answer between releases. A model may invoke only tools from a curated catalogue with typed arguments. Where a model drifts from the expected label set, the system corrects rather than propagates.
The security measures the article requires are the same ones GDPR Article 32 asks for.
Declared accuracy metrics against a defined benchmark are documentation, and the benchmark methodology is ours to publish.
Article 17 — Quality management system
A QMS covering design, development, testing and post-market change is an organisational system.
Article 26 — Deployer obligations
Using the system according to its instructions, assigning competent people to oversight, monitoring operation, and informing workers are yours. What we owe you is the record that makes monitoring possible.
Article 50 — Transparency for certain systems
Where a person interacts with an AI system, or content is machine-generated, that must be evident. Within the platform the clinician always knows: the proposal stance is the interface, not a disclaimer under it.
Telling a patient that AI was used in their care is a decision the provider makes.
Article 72 — Post-market monitoring
Monitoring the system in the field, and acting on what it shows, is a manufacturer's process. The platform supplies the material: the audit trail, the failure signals, and the version of every component that produced a given proposal.
Timing
The Regulation entered into force on 1 August 2024 and applies in stages. The obligations for high-risk systems are the ones that matter here, and their dates have moved: the Commission's Digital Omnibus package defers Annex III high-risk obligations and, separately, those for AI in regulated products. Treat any date on this page as subject to that package's final form, and the classification question above as the one to settle first.