AI the DPO can actually approve.
Patient data does not leave the building. Working papers stay in the institution. Clinical knowledge compounds. The data-protection officer signs. The clinicians use it because the tool is finally good enough.
Built for GDPR Article 9, MDR, the EU AI Act and the regulator that watches the next medical-device classification.
You.
A portrait of the institutionAn organisation that handles special-category data.
You are a university hospital, a regional clinical network, a medical-device manufacturer, a contract research organisation, or a pharmaceutical company. Article 9 of the GDPR governs almost everything you process. The Medical Device Regulation shapes which AI you can put inside a regulated workflow. Your data-protection officer reports to the board and your ethics committee reads every protocol.
You have watched two CIOs in succession try to put guardrails around clinicians' use of public AI. Bans do not work. Allow- lists do not survive the next major release. The way out is a tool the clinicians actually want to use — which is itself inside the institution from the first packet to the last.
What's on your desk today.
Three pressures · patient data, regulator, clinicianThe three constituencies — patients, regulators and clinicians — each demand something the public-cloud chatbot cannot deliver.
Patient data must not leave the institution.
GDPR Article 9 forbids the processing of health data except on a narrow set of bases — and even then, the institution remains the controller. Sending a discharge summary or a radiology report to an external LLM is, on the strict reading, a transfer to a third-party processor without the patient's informed consent. The DPO will not approve it, and the data-protection authority will not bless it.
Once it influences diagnosis or treatment, it's a medical device.
If an AI feature influences clinical decision-making it falls inside the Medical Device Regulation. The institution needs a clinical-evaluation file, post-market surveillance, a notified-body relationship and a quality-management system aligned with ISO 13485. A black-box cloud API cannot supply the technical documentation. Aethos can.
Clinicians are already using AI — they just haven't told you.
Survey after survey shows clinicians paste case material into public chatbots when documentation pressure mounts. The institution carries the liability for what the institution cannot see. The only durable answer is a sanctioned tool that is faster, safer and more accurate than the chatbot in their pocket — running inside the perimeter.
What Aethos changes.
Patient data stays · technical file ready · clinicians adoptThree answers, mapped one-to-one to the three pressures above.
The institution remains the only controller.
Aethos is installed on infrastructure the hospital owns or leases. Every prompt, every retrieval, every response stays inside the institution. No third-country transfer, no third-party processor, no Schrems II analysis required. The DPO can sign because the analysis converges with a purely internal IT system.
Documentation by construction.
Aethos ships per-release technical documentation aligned with MDR Annex II expectations — intended purpose, risk management, software life-cycle, verification and validation, post-market surveillance hooks. Where the institution declares an Aethos-powered workflow as a medical device, the documentation package supports the conformity assessment.
Adoption ends the shadow.
Clinicians stop pasting case material into public chatbots because the institution's tool finally answers faster, with the relevant local protocol, in their own language, citing the source. The liability moves from "untraceable shadow use" to "approved internal use with full audit trail."
The DPO does not say no to AI. She says no to AI that leaves the building.
The modules that matter most for you.
Where healthcare institutions startThree modules cover most clinical and life-sciences use cases. Coder follows in research-IT and bioinformatics deployments.
Clinical protocols, guidelines, internal precedent.
National clinical guidelines, the latest meta-analyses, the institution's own protocols, the multidisciplinary team's decisions on similar cases — answered with the paragraph cited and the date of the source. Access inherits the role the clinician already has in the hospital information system.
RAG module Module 02 · Aethos VoiceWard-round dictation, multilingual patient encounters.
Dictation for discharge summaries, ward-round transcription, multilingual patient interaction in 30+ languages — running on hardware the hospital owns. Not a second of audio reaches a third-party transcription service. The text lands in the electronic patient record at the speed of speech.
Voice module Module 03 · Aethos VRTraining, simulation, anatomy education.
Surgical simulation, anatomy training, scenario-based emergency-medicine drills, mental-health exposure therapy under clinician supervision. Built on the same engine that powers AAA production — but inside the institution, recordings retained under MDR Class I or higher as required.
VR moduleThe regulators that bind.
What the rule asks · what Aethos providesThe instruments that bear directly on AI in healthcare and life sciences — and where Aethos plugs into each.
| Framework | What it requires of AI use | What Aethos provides |
|---|---|---|
| GDPR Art. 9 (special categories) | Health data processed only on narrow Art. 9(2) bases. No third-party transfer without specific basis. Data minimisation. | No data egress · per-tenant DEKs wrapped by hospital KMS · audit log to demonstrate Art. 9(2)(h) basis · purpose-bound retrieval. |
| MDR (EU 2017/745) | Software that influences diagnosis or treatment is a medical device. Technical file, clinical evaluation, post-market surveillance, ISO 13485 quality system, notified-body involvement above Class I. | Per-release MDR-aligned technical documentation pack · risk management aligned with ISO 14971 · post-market surveillance hooks · change manifest signed per release · clinical evaluation support material. |
| IVDR (EU 2017/746) | Equivalent regime for in-vitro diagnostic software. | Same documentation pack adapted for IVDR Annex II. Independence of decision logic documented per release. |
| EU AI Act | Medical-device AI is high-risk when the underlying device is Class IIa or higher. Logging, oversight, transparency, technical documentation required. | Signed append-only audit log · per-skill human-in-the-loop policy · model card per deployed model · technical documentation shipped per release · high-risk vs limited-risk classifier per use case. |
| ISO 27001 / ISO 27799 | Information-security management; health-informatics-specific control set. | Hardening guide aligned with ISO 27799 · per-control evidence pack · audit-ready logging · supports the institution's existing ISMS. |
| ISO 13485 / 14971 | Quality management for medical-device manufacturers; risk management throughout the device life-cycle. | Verification and validation evidence per release · change-control discipline aligned with ISO 13485 expectations · risk file template aligned with ISO 14971. |
| National health-data legislation (e.g. DSG-GVO, BDSG §22, HIPAA-equivalent) | National supremacy over health data processing; supplementary local rules. | No transfer outside the national jurisdiction. National law applies exclusively because no processing happens elsewhere. |
The next step.
One day · on your premises · written outcomeBook a one-day Architecture Workshop.
One day at your institution with Kristijan Stojanović — founder of STK Engineering — and the architect assigned to health and life sciences. We work through the patient-data flow, the existing electronic patient record, the priority clinical use cases and the MDR posture, and produce a signed sizing & integration plan you can take to the DPO and the medical directorate.