EU AI Act and Healthcare: A Developer's Guide to High-Risk AI Compliance
Classify the intended use, verify the applicable AI Act timeline and translate requirements into engineering evidence.
Ala Ben Aicha
Classify the intended use before choosing a deadline
Not every healthcare AI system is high-risk. Document the intended purpose, the product's role and the relevant classification route before building a compliance plan. A documentation assistant and a regulated diagnostic component need different assessments.
The European Commission's current AI Act overview distinguishes general application from the transition periods for high-risk systems. As checked on 5 October 2026, it lists 2 December 2027 for the relevant Annex III high-risk uses and 2 August 2028 for high-risk AI embedded in regulated products. Do not use the old blanket August 2026 high-risk deadline. Verify the consolidated legislation and the exact obligations applying to the product with its regulatory owner.
Turn the assessment into an engineering register
| Record | Engineering question | Evidence to maintain |
|---|---|---|
| Intended use | What decision does the system support, for whom and in which setting? | Approved scope and exclusions |
| Data | Are the sources authorized and appropriate for the population? | Provenance, dataset versions and quality checks |
| Evaluation | Which failures matter and how are they detected? | Test cases, review protocol and acceptance criteria |
| Human oversight | Can the responsible user understand, reject or stop the output? | Interface tests and operating procedures |
| Change control | What invalidates a previous evaluation? | Model, prompt, software and configuration history |
| Operations | Who handles incidents and changes in performance? | Monitoring, escalation and rollback records |
These records are a practical project structure, not a declaration that a product is legally compliant. Assign an owner and review date to each requirement. Trace it to a test or operational control and retain the unresolved questions.
Keep model output separate from clinical action
Define where a result appears and what it can trigger. A clinician reviewing a draft, a rule routing an administrative request and an automatic change to an order carry different consequences. Specify the permitted action and test an incorrect, stale or unavailable output.
Keep a recovery route that remains usable during a model or integration outage. Avoid placing unnecessary sensitive content in logs. Capture versions and review outcomes sufficient to investigate a failure.
Verify product-specific obligations
If the intended purpose may make the software a medical device, review the medical-device software framework alongside the AI assessment. Data-protection duties, clinical governance and procurement requirements remain separate workstreams.
Use a requirements workshop to resolve applicability before estimating delivery. Discuss a project for the architecture, integration and evidence pipeline. Legal classification and clinical authorization remain with the appropriately qualified decision-makers.