The most compliant place for a patient’s record to meet a large language model might be a machine sitting under your own desk. That sounds like a provocation. It is closer to a legal observation.
In May and June 2026 the European Union rewrote part of its own AI rulebook, and most of the coverage got the healthcare consequence backwards. The headline everyone absorbed was simple: the EU delayed the AI Act. True, in part. Dangerous, if you stop reading there. Because the obligations that actually bind a clinician who pastes a discharge summary into a chatbot did not move a single day. This post is about that gap, and about why local inference is the pragmatic response to it.
The deadline moved. The obligations did not.
Here is what changed. The AI Act (Regulation (EU) 2024/1689) has applied in stages since it entered into force on 1 August 2024. The Commission then tabled a “Digital Omnibus on AI” in November 2025, negotiators reached political agreement in early May 2026, the Parliament endorsed it on 16 June and the Council gave its final green light on 29 June 2026. Publication in the Official Journal is imminent, and the text enters into force on the third day after that.
What it does is push the heavy dates. Obligations for stand-alone high-risk systems (Annex III) slip from 2 August 2026 to 2 December 2027. Obligations for AI embedded in regulated products (Annex I), which is where medical devices under the MDR and IVDR live, slip from 2 August 2027 to 2 August 2028. Sixteen months of breathing room for one bucket, a year for the other.
Now the part that got lost. The transparency duties under Article 50 still bite on 2 August 2026. The general-purpose AI obligations on foundation-model providers have applied since 2 August 2025 and were left untouched. And none of the deferral touches the two regimes that matter most when patient data is involved: data protection and professional liability. Both are live today. Whether the standards bodies finish their work by 2027 is, for a surgeon deciding what to do on Monday, beside the point.
Why the cloud API is the hard part under GDPR
Strip away the acronyms and the mechanism is almost physical. When you send clinical text to a hosted model, that text leaves your device and becomes a processing operation carried out by a third party, often on infrastructure outside the EU. Under the GDPR (Regulation (EU) 2016/679) that single act pulls a long chain of questions behind it. What is your lawful basis for processing special-category health data? Is there a data processing agreement with the vendor? Does the traffic constitute an international transfer, and on what safeguard? Have you honoured data minimisation, or did the whole letter go over the wire when three fields would have done?
Run the same model locally and most of that chain never forms. The data does not leave the machine, so there is no third-party processor to contract with, no transfer to justify, no vendor retention policy to audit. You have not satisfied the GDPR by paperwork. You have removed the exposure by architecture. That is a stronger position, and it is the reason “privacy” here is not a soft selling point but the core engineering decision.
Anyone who has actually filled in a data protection impact assessment knows the difference between mitigating a risk and eliminating its source. Local inference does the second thing.
GPAI, medical devices, and where a local model actually sits
A fair objection: does running a model locally simply move you into a different high-risk box? Mostly, no, and the distinction is worth getting right.
A general-purpose model you download and run to draft text is not, by that act, a medical device. It becomes a Software as a Medical Device only when it is intended by its manufacturer for a medical purpose and placed on the market as such, at which point the MDR and the Annex I timeline (now 2 August 2028) apply to whoever places it. Using an open-weight model on your own workstation to draft a report, summarise a guideline, or restructure your own notes is the act of a deployer working in a research or internal-support setting. It is not the same as putting a diagnostic product into clinical service. The Omnibus deferral, then, is relief for people building and certifying high-risk products. It is not a licence to pipe identifiable data into a cloud endpoint, because the thing that governs that act was never the high-risk timeline in the first place.
The caveat cuts the other way too. A local model that you quietly wire into a decision that affects a patient can drift toward high-risk territory regardless of where the weights sit. Location protects the data. It does not launder the use case.
The liability layer nobody deferred
For Italian clinicians there is a further layer the Brussels debate never touched. Law 24/2017, the Gelli-Bianco framework, still allocates professional and structural responsibility for harm exactly as it did last year. If a tool contributes to an error, the accountability lands on the clinician and the facility, not on the model. An AI Act deferral changes none of that.
Meanwhile the European Health Data Space (Regulation (EU) 2025/327) has been in force since 26 March 2025, with its general application date on 26 March 2027 and the first priority categories, patient summaries and ePrescriptions, becoming exchangeable across the Union by 26 March 2029. Imaging, laboratory results and discharge reports follow in 2031. The EHDS is reshaping how health data is governed, shared, and reused, with strict purpose limitation, secure processing environments, and an explicit prohibition on re-identification for secondary use. It rewards institutions that can demonstrate control over where their data lives and moves. A local-first posture is not a workaround to any of this. It is the same instinct expressed in code.
So the compliance calendar splits cleanly. The AI Act’s hardest requirements: later. Data protection, medical-device law, professional liability, health-data governance: now. Which set describes your Tuesday clinic?
Where local stops being a magic bullet
I would be selling you something if I stopped there. Local is a strong default, not an absolution, and the honest limits matter.
Running on-premise reduces the attack surface but does not zero it. Identifiers can still leak downstream, into temporary files, application logs, monitoring dashboards, or a poorly scoped export, and recent work on privacy in clinical documentation has shown that dataset-level anonymisation does not guarantee safety at the pipeline level. The contextual privacy problem is subtler than stripping names. Then there is the model itself: an open-weight clinical LLM is not validated for care simply because it runs offline, and the teams behind several of these models say plainly that their outputs are not fit for direct patient care without further testing. None of the setups I write about should touch real patient data outside a governed, ethically approved workflow. Synthetic and de-identified inputs are the right sandbox.
Early days, admittedly, for a lot of this tooling. But the direction is set, and the privacy argument is the part that does not depend on next year’s benchmark.
Key Takeaways
- The Digital Omnibus defers the AI Act’s high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I, including medical devices), after political agreement in May and formal adoption in June 2026.
- Article 50 transparency duties still apply from 2 August 2026, and GPAI obligations have applied since August 2025. The deferral is narrower than the headlines suggest.
- The GDPR, the MDR and IVDR, and Italian Law 24/2017 on clinical liability were not deferred. They govern what you do with patient data today.
- Sending clinical text to a hosted model triggers processor, transfer, and minimisation questions under the GDPR. Local inference removes the source of that exposure rather than merely mitigating it.
- Running an open-weight model locally to draft or summarise is a deployer activity, not the act of placing a medical device on the market.
- Local is not automatic compliance: pipeline-level leakage is real, the models are not validated for care, and real patient data belongs only in governed, approved workflows.
Looking Ahead
The interesting question for the next year is not whether the AI Act slips again. It is whether the infrastructure to run capable models privately keeps improving fast enough to make the cloud convenience unnecessary for most clinical text tasks. On current trends, a 24 GB consumer card already runs 27-billion-parameter models offline. If that curve holds, the privacy-versus-capability trade-off that justified cloud dependence starts to dissolve, and the local option stops being the cautious choice and becomes simply the obvious one. I will be testing exactly that in the next post, with an open-weight medical model benchmark run entirely on local hardware.
References
- EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions – Covington, Inside Privacy, May 2026
- EU legislators agree to delay for high-risk AI rules – Hogan Lovells, May 2026
- The Digital AI Omnibus: Proposed deferral of high-risk AI obligations under the AI Act – DLA Piper, 2026
- EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes – Gibson Dunn, May 2026
- European Health Data Space Regulation (EHDS) – European Commission, Directorate-General for Health
- The European Health Data Space is in force: implications for healthcare, MedTech and life sciences – Kennedys, March 2026
Primary legal instruments referenced: Regulation (EU) 2024/1689 (AI Act); Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2025/327 (EHDS); Regulation (EU) 2017/745 (MDR); Italian Law 24/2017 (Gelli-Bianco).
Disclaimer: This article is for information only and is not legal advice. Regulatory dates reflect the Digital Omnibus as adopted in June 2026,
Other local llm articles: