# 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.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/eu-ai-act-healthcare-compliance

Updated: 2026-10-05

## 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](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) 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](https://alabenaicha.me/insights/eu-mdr-software-medical-device-guide) 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](https://alabenaicha.me/contact?intent=project) for the architecture, integration and evidence pipeline. Legal classification and clinical authorization remain with the appropriately qualified decision-makers.