The C5 gate is for clouds. Your own box answers to § 391.
Hospitals already run language models on patient data, on servers they own. Kernwall OS is built for that: the model runs on an appliance inside the hospital's network, opens no connection, and keeps every log on its own disks, where the AI Act wants the deployer to hold them.
Already in hospitals
University hospitals run their own models already.
Two have published how, with numbers. Neither is a Kernwall deployment.
Cliniques universitaires Saint-Luc, Brussels
Qwen3-235B on one eight-GPU H200 server inside the hospital's own network, embedded in Epic. 1,028 staff used it hospital-wide, over half of them each week, mostly to find and summarise records.
Universitätsmedizin Magdeburg
A self-hosted platform on one H100 running Llama 3.2-Vision-90B for 322 registered staff. Of 91 who answered the survey, 44% said it saves them at least 30 minutes a week.
Germany · SGB V
Two routes to a model on patient data, two different rules.
A hosted service has to clear the cloud gate before the first prompt. A box the hospital runs falls under the IT-security duties the hospital already has.
SaaS or a managed private cloud
Health data may go to a cloud service only with a current C5 Type 2 attestation of the provider that processes it, not just of the hyperscaler underneath, and only in Germany, the EU or an adequate country, from a German branch.
A box the hospital owns and runs
§ 384 defines a cloud service as on-demand, remote access to a shared, elastic pool. An appliance the hospital racks and runs, with no vendor access, is not one, so the C5 gate does not apply. The hospital's own IT-security duties under § 391 do.
The second route is our reading of § 384, not legal advice. A vendor-managed stack with remote administration could be argued into the definition. Kernwall OS is designed with no vendor access at all, so there is nothing to argue about.
Above 30,000 inpatient cases a year a hospital is a critical facility and carries the BSI Act's duties instead of § 391.
Why now
The AI Act dates differ by what the model does.
A clinical assistant that finds, summarises and drafts is not high-risk on its own. Triage and device AI are, on two different dates.
- Jul 2025Hosted AI on health data needs C5 Type 2.
- Dec 2027AI Act high-risk duties reach emergency patient triage.
- Jan 2028Notified bodies must apply for AI Act designation.
- Aug 2028AI that is itself a medical device becomes high-risk.
First job
Find, summarise, draft. A physician signs.
Finding and summarising records is most of what Saint-Luc's staff used their model for. A letter drafted from the record, cited to its notes and signed by a doctor, is the job the appliance is built for first. The window runs one.
Used like this, a clinical assistant is not high-risk on its own under the AI Act. Using it to triage emergency patients, or placing it as a medical device, would make it high-risk, from the dates above.
§ 391 SGB V · AI Act Art. 26 · GDPR
What a hospital's security and data-protection teams will ask of the box.
Each row maps a duty to the control designed for it, who carries it, and the evidence it leaves for your B3S documentation.
- § 391 SGB V · IT security
State-of-the-art precautions for the availability, integrity and confidentiality of the hospital's IT. The BSI-approved B3S is the presumed route.
SharedA signed, read-only image with measured boot, one documented service on the hospital network, and updates that roll back. It enters the B3S scope as one more system the hospital documents.
Evidence you take awayListening-services manifest and boot measurements per release; egress audit report (planned)
- AI Act Art. 26(6) · Logs
Deployers keep the system's automatically generated logs, as far as they control them, for at least six months.
SharedPrompts, answers, user and model version are logged append-only on the appliance's own disks, kept as long as the hospital sets. No copy sits with a vendor.
Evidence you take awayHash-chained log export; retention setting per appliance
- AI Act Art. 26(5) · Monitoring
Deployers monitor the system in use and report serious incidents.
Your site owns itEach answer records the model and policy version behind it, so the hospital can rebuild what a clinician saw. Reporting stays with the hospital.
Evidence you take awayModel and policy version per answer; release ledger
- AI Act Art. 26(7) · Staff
Workers' representatives are informed before a high-risk system is used at the workplace.
Your site owns itA plain description of what the appliance logs about staff, written for the works council.
Evidence you take awayData-flow and logging description per release (planned)
- GDPR Art. 9 and 32 · Patient data
Health data is special-category data: processed only under an Art. 9 condition, with security appropriate to the risk.
SharedPatient data never leaves the box: no outbound connection, no telemetry, and encrypted drives that stay with the hospital when a unit goes back.
Evidence you take awayEgress audit report; drive-retention repair policy (planned)
- § 393 SGB V · Cloud use
Cloud processing of health data needs the processing provider's own current C5 Type 2 attestation.
Your site owns itIn our reading this row does not apply: the hospital owns and runs the box, and the vendor has no access to it. Ask your data-protection officer.
Evidence you take awayStatement of no vendor access; egress audit report
Hospital IT-security, deployer, patient-data and cloud rules mapped to appliance controls.
Art. 26(6) asks deployers to keep the logs that are under their control. On a hosted service they sit with the vendor. On the appliance they never leave the hospital's disks.
Test it
Bring your B3S scope to a pilot.
Tell us which wards and records the model should reach, and what your data-protection officer checks. The pilot runs on your hardware, inside your wall, against that list.