Klinik-KI ohne GPU: Was die CPU-Studie belegt und was ein Pilot prüfen muss

Inhalt

1. 1. Die Ausgangsstudie belegt Ausführbarkeit
2. 2. Speicher, Quantisierung und Kontext bestimmen Qualität und Last
3. 3. Klinischer Nutzen hängt an Aufgabe und Anwender
4. 4. Latenz begrenzt den Durchsatz, die Nachprüfung bestimmt die Kosten
5. 5. Lokaler Betrieb ist kein Datenschutznachweis
6. 6. Zweckbestimmung, Regulierung und Ausstiegspfad
7. 7. Bewertung: Optionen, Risiken, Gegenargumente
8. 8. Handlungscheckliste

Gegenstand sind die Bedingungen, unter denen ein großes Sprachmodell ausschließlich auf dem Hauptprozessor (CPU) in einer Klinik sinnvoll betrieben werden könnte. „Ohne GPU“ heißt hier, dass die Modellinferenz keine GPU-Beschleunigung nutzt. Systeme mit einer Neural Processing Unit gelten als eigene Alternative, weil auch eine NPU spezialisierte Rechenhardware ist. Grundlage ist eine Quellenanalyse des Verfassers mit Rechercheabschluss am 15.10.2026. Eigene Messungen, Patientendaten oder Hardwareangebote enthält sie nicht. Alle Rechenbeispiele beruhen auf ausdrücklich angenommenen Werten.

1. Die Ausgangsstudie belegt Ausführbarkeit

Anlass ist die Arbeit „Capacity over TFLOPS“ von Yune, Majeed und Balan, eingereicht als arXiv-Version 1 am 13.10.2026 [1]. Nach Angabe der Autoren ist sie für die IEEE-Konferenz ICCE-Berlin angenommen. Begutachtung und Verlagsfassung konnte der Verfasser nicht verifizieren. Die Autoren betrieben ein quantisiertes Gemma-2-27B-it als Stellvertreter für klinische Modelle auf zwei Rechnern und bearbeiteten synthetische, FHIR-nahe Aufgaben. Sie berichten höchstens 25,0 beziehungsweise 20,4 GB Prozessspeicher, 2,36 beziehungsweise 0,62 Token pro Sekunde und 18,4 beziehungsweise 84,7 Sekunden bis zum ersten Token [1].

Mehrere Aussagen der Arbeit beruhen nicht auf Messungen. Dass der GPU-Speicher für das Modell nicht ausreiche, leiten die Autoren analytisch ab, einen GPU-Vergleich haben sie nicht ausgeführt. Den Energiebedarf schätzen sie über die thermische Verlustleistung der Prozessoren, Adaptergrößen sind berechnet, ein föderiertes Training fand nicht statt [1]. Die Autoren haben ein Repositorium veröffentlicht, das einen Messrahmen für Speicher und Laufzeit enthält [5]. Der Verfasser hat den Code nicht ausgeführt und wertet das Repositorium deshalb als Angebot zur Reproduktion. Eine unabhängige Bestätigung liegt nicht vor.

CPU-Inferenz ist bereits heute verfügbar. Die Laufzeitumgebung llama.cpp unterstützt Prozessoren, verschiedene Quantisierungen und eine hybride Verarbeitung auf CPU und GPU [6]. Ein zu kleiner GPU-Speicher verhindert daher nur die vollständige Auslagerung auf die GPU. Teilbeschleunigung und kleinere Modelle bleiben möglich und gehören in jeden Architekturvergleich. Der Verfasser liest die Studie als Machbarkeitsbefund für zwei Konfigurationen. Eine allgemeine Hardwareunabhängigkeit oder eine Überlegenheit gegenüber passend dimensionierter GPU-Inferenz folgt aus ihr nicht.

2. Speicher, Quantisierung und Kontext bestimmen Qualität und Last

Speicherkapazität und Geschwindigkeit beantworten verschiedene Fragen. Ein Modell mit 27 Milliarden Parametern belegt bei idealisierten vier Bit je Parameter 27.000.000.000 × 4 ÷ 8 = 13,5 GB, bei 16 Bit sind es 54,0 GB. Diese Rechnung des Verfassers erfasst nur die Parameter. Quantisierungstabellen, Kontextspeicher, Betriebssystem und weitere Programme fehlen. Der Wert ist deshalb eine Untergrenze und eignet sich nicht als Beschaffungsgrundlage. Testberichte sollten die Dateigröße, den höchsten Prozessspeicher (Spitzenbedarf des laufenden Modells) und die verbleibende Reserve des Arbeitsspeichers getrennt ausweisen.

Quantisierung senkt die numerische Präzision der gespeicherten Gewichte. Das Verfahren AWQ berücksichtigt besonders empfindliche Gewichtskanäle und macht niedrige Genauigkeiten für lokale Ausführung nutzbar [7]. Seine Ergebnisse gelten für die untersuchten Modelle und Aufgaben. Ob medizinisch relevante Einzelheiten in einer bestimmten Vier-Bit-Variante erhalten bleiben, muss an dieser Variante geprüft werden. Der Verfasser schlägt Referenzfälle mit Negationen, Zahlen, Einheiten, Zeitbezügen und ausdrücklich fehlenden Angaben vor. Ein flüssiger Satz besteht diese Prüfung nicht, wenn aus „kein Hinweis auf“ eine positive Feststellung wird.

Der Kontextspeicher wächst mit Eingabelänge und Zahl gleichzeitiger Sitzungen. Die Arbeit zu PagedAttention zeigt, wie Fragmentierung dieses Speichers die nutzbare Kapazität begrenzt [8]. Ihre Leistungsgewinne lassen sich nicht auf einen beliebigen CPU-Rechner übertragen, das Prinzip begründet aber Tests mit kurzen, mittleren und überlangen Akten. Der Verfasser empfiehlt, jede Kombination aus Modell, Quantisierung und Laufzeit als eigene Prüffassung zu behandeln, deren Freigabe sich nicht auf eine Nachfolgeversion überträgt. Wie stark sich Modelle auf Effizienz trimmen lassen, hat der Verfasser am Beispiel BitNet b1.58 beschrieben.

3. Klinischer Nutzen hängt an Aufgabe und Anwender

Google schreibt in der Modellkarte von MedGemma, die Modelle seien ohne angemessene Validierung und Anpassung für den konkreten Zweck nicht einzusetzen und ihre Ausgaben sollten Diagnosen und andere klinische Entscheidungen nicht unmittelbar informieren [9]. MedGemma beruht auf Gemma 3. Das in der Ausgangsstudie verwendete Gemma-2-Modell ist deshalb auch bei ähnlicher Parameterzahl kein funktional gleichwertiger klinischer Ersatz.

Medizinische Sprachmodelle können leistungsfähig sein. In einer randomisierten, verblindeten Studie mit simulierten Patienten schnitt das spezialisierte System AMIE auf mehreren Bewertungsdimensionen besser ab als die verglichenen Hausärztinnen und Hausärzte [10]. Die Studie von Goh und Kollegen beantwortet eine andere Frage: Ärztinnen und Ärzte mit Zugang zu einem Sprachmodell erreichten bei klinischen Vignetten im Median 76 %, die Vergleichsgruppe mit konventionellen Hilfsmitteln 74 % [2]. Die isolierte Leistung eines Systems sagt also wenig darüber, ob es die ärztliche Arbeit verbessert. Eine Beschaffungsentscheidung muss die Kombination aus Anwender, Oberfläche und Aufgabe untersuchen. Weitere Befunde zur Lücke zwischen Studienleistung und Versorgungsalltag ordnet der Beitrag KI in der Medizin: Zwischen Durchbruch und Ernüchterung ein.

Die WHO nennt unter den Risiken großer multimodaler Modelle falsche oder unvollständige Aussagen, Verzerrungen und Automation Bias, also die Neigung, fehlerhafte Ausgaben zu übersehen oder Entscheidungen an das System abzugeben [11]. Die lokale Rechenarchitektur ändert an diesen Risiken nichts. Die Berichtsleitlinie DECIDE-AI verlangt, die frühe klinische Erprobung im realen Nutzungskontext und mit Blick auf menschliche Faktoren zu berichten [12].

Für einen ersten Pilot hält der Verfasser eine eng begrenzte Entwurfsaufgabe für geeignet: Das System fasst einen freigegebenen Dokumentbestand zusammen, jeder Entwurf wird vor der Übernahme kontrolliert, und fehlende Angaben darf das Modell nicht ergänzen. Für die Kennzeichnung abweichender Laborwerte ist zuerst eine deterministische Regelprüfung zu testen, weil Referenzbereiche und Einheiten strukturiert vorliegen. Eine Triage- oder Therapieempfehlung durch ein allgemeines lokales Sprachmodell empfiehlt der Verfasser nicht, solange kein zweckspezifischer Nachweis vorliegt.

4. Latenz begrenzt den Durchsatz, die Nachprüfung bestimmt die Kosten

Ob eine CPU-Lösung bedienbar ist, lässt sich vor jedem Test eingrenzen. Angenommen sind 500 Token Ausgabe, 10 Sekunden bis zum ersten Token und 2 Token pro Sekunde. Ein Auftrag dauert dann 500 ÷ 2 + 10 = 260 Sekunden. 100 Aufträge benötigen bei serieller Abarbeitung 26.000 Sekunden oder rund 7,22 Stunden und füllen ein Nachtfenster von 8 Stunden zu rund 90,3 %. Wiederholungen und Ausfälle sind nicht eingerechnet. Mit den Messwerten der Ausgangsstudie gerechnet, benötigt der schnellere Rechner 500 ÷ 2,36 + 18,4 ≈ 230 Sekunden je Auftrag und rund 6,40 Stunden für 100 Aufträge, der langsamere 500 ÷ 0,62 + 84,7 ≈ 891 Sekunden und rund 24,75 Stunden [1]. Die Annahme von 10 Sekunden ist also optimistisch. Die Zeit bis zum ersten Token wächst mit der Eingabelänge, bei der Zusammenfassung umfangreicher Akten ist sie gesondert zu messen. Mehrere parallele Prozesse beschleunigen nicht proportional, weil sie Rechenwerk und Speicher teilen [8].

Die Energiekosten sind im Vergleich gering. Ein Rechner mit angenommenen 100 Watt verbraucht in 8 Stunden 0,8 Kilowattstunden, bei angenommenen 0,30 Euro je Kilowattstunde sind das 0,24 Euro am Tag und 60,00 Euro in 250 Arbeitstagen. Ein schnelleres Gerät mit höherer Leistungsaufnahme kann für dieselbe Auftragsmenge weniger Energie benötigen, weil die Laufzeit kürzer ist. Ein Energievergleich setzt deshalb Messungen an derselben Systemgrenze voraus.

Den größten Kostenanteil verursacht die menschliche Nachprüfung. Werden täglich 100 Entwürfe je 2 Minuten kontrolliert, entstehen 200 Minuten oder rund 3,33 Stunden Prüfzeit. Bei einem angenommenen kalkulatorischen Stundensatz von 60,00 Euro sind das 200,00 Euro am Tag und bei 250 Arbeitstagen 50.000,00 Euro im Jahr. Dieser Bruttowert ist den Kosten der bisherigen manuellen Erstellung gegenüberzustellen. Spart ein Entwurf 1 Minute, verlangt aber 2 Minuten zusätzliche Kontrolle, entsteht netto eine Mehrbelastung. Daraus ergibt sich ein Zielkonflikt: Eine gründliche Prüfung wirkt dem Automation Bias entgegen und verringert den wirtschaftlichen Vorteil, eine flüchtige Prüfung verhält sich umgekehrt. Die Mindestprüftiefe ist deshalb fachlich festzulegen, bevor Ergebnisse vorliegen. Der Verfasser schlägt als Kennzahl die Gesamtkosten je fachlich freigegebenem Ergebnis vor, ausgewiesen zusammen mit Fehlerrate und Verfügbarkeit. Ein finanzieller oder klimatischer Vorteil der CPU-Architektur ist ohne diese Messung nicht belegt.

5. Lokaler Betrieb ist kein Datenschutznachweis

Lokale Inferenz vermeidet den Datenfluss zu einem externen Modelldienst nur dann, wenn alle beteiligten Komponenten entsprechend eingerichtet sind. Auch Protokolle und Sicherungskopien können Eingaben enthalten, ebenso Dateien, die für den Herstellersupport bereitgestellt werden. Die Europäische Kommission erläutert, dass Gesundheitsdaten besonderen Verarbeitungsvoraussetzungen unterliegen [13]. Sie beschreibt unter anderem Datenschutz durch Technikgestaltung und die Datenschutz-Folgenabschätzung bei voraussichtlich hohem Risiko [14]. Geprüft wird der gesamte Verarbeitungsvorgang. Die Hardwarewahl schafft keine Rechtsgrundlage, und aus der Zulässigkeit der Behandlung folgt nicht die Zulässigkeit eines Entwicklungsvorhabens mit denselben Daten. Der Verfasser empfiehlt eine Stufenfolge: synthetische Testfälle, danach echte Behandlungsfälle erst mit eigener Rechtsgrundlage, abgeschlossener Folgenabschätzung und Freigabe, zuletzt ein Schattenbetrieb, in dem das System Ergebnisse erzeugt, ohne den regulären Prozess zu steuern.

Der Verfasser schlägt einen begrenzten Dienst im Kliniknetz vor, der die vorhandenen Rollen nutzt und vor dem Zusammenstellen des Modellkontexts prüft, welche Dokumente der Benutzer für den konkreten Fall lesen darf. Ein Filter auf die fertige Antwort genügt nicht, weil unzulässige Inhalte dann bereits im Kontext stehen. Negative Zugriffstests belegen die Wirksamkeit, etwa zwei Fälle mit ähnlich benannten Personen, bei denen das System den falschen Fallbezug verweigern muss. Ein Nachtlauf steht dazu in Spannung, weil dann kein Benutzer angemeldet ist. Ein Dienstkonto mit Lesezugriff auf viele Fälle würde die Prüfung aushebeln. Vertretbar ist ein Auftrag, den ein berechtigter Benutzer am Tag fallgebunden anstößt und dessen Berechtigung der Nachtlauf übernimmt. Für trainierte Modelle hält der Europäische Datenschutzausschuss eine Einzelfallprüfung für erforderlich, ob personenbezogene Informationen extrahierbar sind [3]. Das betrifft auch ein fremdes Basismodell, dessen Herkunft, Trainingsdaten und Lizenz vor dem Einsatz zu bewerten sind. Anpassung und föderiertes Lernen auf eigenen Daten sind eigene Vorhaben mit eigenem Bedrohungsmodell.

Ein lokaler Rechner schützt auch nicht vor manipulierten Dokumenten. OWASP beschreibt direkte und indirekte Prompt Injection und hält fest, dass Retrieval und Feinabstimmung die Schwachstelle nicht vollständig beheben [15]. Im vorgeschlagenen Entwurfsdienst erhält das Modell deshalb keine Werkzeuge zum Abrufen oder Schreiben von Daten, und die Anwendung behandelt jede Ausgabe als unvertrauenswürdigen Entwurf. Ein manipuliertes Dokument kann den Inhalt des Entwurfs trotzdem verfälschen. Die Nachprüfung muss deshalb Testfälle mit eingeschleusten Anweisungen enthalten. Das Profil des NIST für generative KI empfiehlt, Fähigkeitsbehauptungen empirisch zu prüfen und nicht aus engen Bewertungen zu extrapolieren [16]. Für die Anbindung an das Krankenhausinformationssystem gilt, dass FHIR nach eigener Spezifikation kein Sicherheitsprotokoll ist [17]. Zugriffsschutz und Protokollierung muss die Klinik selbst gestalten. Ein synthetischer, FHIR-naher Datensatz wie in der Ausgangsstudie belegt keine Integration in ein bestehendes System. Wie sich vertrauliche Daten nach Schutzklassen auf lokale und externe Modelle verteilen lassen, zeigt der Beitrag Second Brain.

6. Zweckbestimmung, Regulierung und Ausstiegspfad

Die im Juni 2025 überarbeitete MDCG-Leitlinie 2019-11 ordnet Software nach ihrem vorgesehenen Zweck ein [4]. CPU-Ausführung und lokale Installation beantworten die medizinprodukterechtliche Frage deshalb nicht. Ein Dienst zur Textbearbeitung und eine Software zur Entscheidungsunterstützung können auf derselben Technik beruhen und dennoch unterschiedlich einzustufen sein. Ein Hinweis auf der Oberfläche ändert die Einstufung nicht. Medizinische Leitung, Datenschutz, Informationssicherheit und die für Softwarequalifikation zuständige Stelle sollten denselben dokumentierten Zweck bewerten.

Die KI-Verordnung unterscheidet ebenfalls nach Anwendung und Risiko. Die Europäische Kommission erläutert den Zusammenhang zwischen Produktbezug, erforderlicher Konformitätsbewertung und Hochrisikoeinstufung und bezeichnet ihre Leitlinien dazu als nicht rechtsverbindliche Auslegungshilfe [18]. Die medizinprodukterechtliche Einordnung entscheidet damit auch über die Einstufung nach der KI-Verordnung mit. Am 27.07.2026 trat der AI Omnibus in Kraft und verschob Anwendungsfristen [19]. Fristen und Rollen sind daher vor einer Umsetzung am konsolidierten Rechtstext zu prüfen. Die geänderten Termine hat der Verfasser im Beitrag KI-Angst und Konzernmacht zusammengestellt.

Lokaler Betrieb verringert die Abhängigkeit von einer externen Schnittstelle. Bindungen bestehen weiter über Modelllizenz, Dateiformat, unterstützte Hardware, Laufzeit und Integrationscode. Die Dokumentation von OpenVINO führt die Unterstützung des GGUF-Formats für bestimmte Modelltopologien als Vorschau [20]. Portabilität lässt sich also nicht an der Dateiendung ablesen. Der Verfasser schlägt einen praktischen Ausstiegstest vor: einen Datensatz exportieren, dieselbe Aufgabe in einer zweiten freigegebenen Umgebung ausführen und nach denselben Kriterien bewerten. Promptvorlagen, Quellmetadaten, Prüfergebnisse und freigegebene Ausgaben müssen außerhalb einer proprietären Oberfläche erreichbar bleiben. Die Grenzen freier Software im Krankenhaus behandelt der Beitrag Open Source im Krankenhaus.

7. Bewertung: Optionen, Risiken, Gegenargumente

Der begrenzbare Datenweg ist ein Vorteil jedes lokalen Betriebs, auch eines lokalen GPU-Servers. Spezifisch für die CPU kommen nur Hypothesen in Betracht: Die Klinik muss keine GPU beschaffen und kann vorhandene Rechner mit ihren bestehenden Betriebsroutinen nutzen. Ob diese Vorteile tragen, zeigt erst der Vergleich. Prüfenswert ist die CPU-Variante dort, wo eine Aufgabe wenig Parallelität verlangt und ihr Ergebnis unabhängig kontrolliert werden kann. Gegen sie spricht die Gesamtleistung des Dienstes: Lange Wartezeiten, aufwendige Kontrolle oder fehlende klinische Qualität können eine technisch mögliche Variante unbrauchbar machen. Beide Positionen sind an derselben Aufgabe zu prüfen. Verlangt ein Prozess viele gleichzeitige interaktive Antworten, kann eine zentrale GPU-Plattform vorteilhaft sein, auch wenn jedes Modell in den Arbeitsspeicher passt.

Das Gegenargument, Kliniken sollten vorhandene Rechner besser auslasten, beschreibt ein nachvollziehbares Ziel. Für eine Entscheidung genügt es nicht, denn vorhandene Hardware ist eine schlechte Wahl, wenn die Anwendung andere Arbeitsabläufe verdrängt oder Betriebspflichten erzeugt, die die Einrichtung nicht abdecken kann. Umgekehrt rechtfertigt eine schnellere GPU keine Anschaffung, wenn eine Regel- oder Suchlösung die Aufgabe erfüllt. Lokale Kontrolle verlangt, dass die Klinik ihre Schutzmaßnahmen selbst zuverlässig umsetzt und den Betrieb nicht von wenigen Einzelpersonen abhängig macht. Der Verfasser fordert für Cloud und Eigenbetrieb denselben Nachweis: zulässige Verarbeitung, fachliche Qualität, messbare Dienstgüte und Wiederherstellbarkeit.

Ein ernstzunehmendes Risiko liegt in ungleicher Ergebnisqualität. Die Konsensleitlinie FUTURE-AI verlangt unter anderem Fairness über den gesamten Lebenszyklus [21]. Der Verfasser empfiehlt, Ergebnisse nach den für die Aufgabe relevanten Gruppen und mit Fallzahlen auszuweisen und den freigegebenen Zweck zu begrenzen, wenn die geforderte Qualität für eine Teilgruppe nicht gezeigt ist. Der Bewertungsbogen sollte korrekte Antwort, begründete Enthaltung, unvollständige Antwort und unbelegte Ergänzung unterscheiden, damit das System nicht für Vollständigkeit um jeden Preis belohnt wird.

Die Datenbasis hat Grenzen. Die Ausgangsstudie ist ein Vorabdruck mit zwei Konfigurationen, Begutachtung und Verlagsfassung sind nicht verifiziert, und ihre Messwerte sind nicht unabhängig reproduziert. Die klinischen Studien beruhen auf simulierten Patienten und Vignetten. Patientenendpunkte haben sie nicht erhoben. Kosten- und Latenzrechnungen beruhen auf Annahmen. Der Beitrag ist keine rechtliche Einzelfallbewertung. Auch ein gescheiterter Pilot liefert eine verwertbare Entscheidung, wenn seine Vergleichsbedingungen offenliegen.

8. Handlungscheckliste

• Zweck vor Hardware festlegen: Aufgabe, erwartetes Ergebnis, Prüfer, ausgeschlossene Nutzung und Abbruchgrenzen vor dem ersten Test dokumentieren.
• Einfache Alternative mitprüfen: Regelverarbeitung oder Suche an denselben Fällen bewerten, bevor ein generatives Modell den Zuschlag erhält.
• Prüffassung festschreiben: Modellversion, Quantisierung, Laufzeit, Hardware und Kontextgrenzen dokumentieren und jede Änderung neu bewerten.
• Referenzbestand unabhängig erstellen: Negationen, Zahlen, Einheiten, Zeitbezüge, fehlende Angaben und überlange Akten aufnehmen und nach Fehlerarten auswerten.
• Gesamtzeit messen: Zeit bis zum ersten Token, Zeit bis zum Ergebnis, Durchsatz, Wartezeit in der Auftragsliste und Zeitpunkt der fachlichen Freigabe erheben, nach Beteiligung der Personalvertretung und ohne personenbezogene Auswertung.
• Kosten auf freigegebene Ergebnisse beziehen: Beschaffung, Integration, Betrieb, Prüfarbeit und Fehlerkorrektur durch die Zahl akzeptierter Ergebnisse teilen.
• Zugriff vor dem Kontext prüfen: Berechtigung je Fall vor der Kontextbildung durchsetzen, Echtdaten erst nach dokumentierter Freigabe verarbeiten und beides mit negativen Zugriffstests belegen.
• Betrieb härten: dem Modell keine Werkzeuge für Datenabruf oder Schreibzugriff geben, Netzverbindungen begrenzen, nur freigegebene Modelldateien mit geprüfter Herkunft starten und jede Kontrolle mit einem Negativtest belegen.
• Berichtsstandard nutzen: Aufgabe, Daten, Modell und Evaluation nach TRIPOD-LLM beschreiben und Abweichungen begründen [22].
• Ausstieg erproben: Lizenzbedingungen prüfen, Daten und Ergebnisse exportieren, die Aufgabe in einer zweiten Umgebung ausführen und den Rückweg in den bisherigen Prozess mit dokumentierter Vertretung testen.

Quellen

Primärquellen zuerst. Herstellerdokumentation belegt Eigenangaben, keine unabhängige Evaluation. Rechenbeispiele im Text sind eigene Modellrechnungen mit angenommenen Werten.

1. Yune, E.; Majeed, U.; Balan, M.: Capacity over TFLOPS: Memory-Centric Deployment of Large Clinical Language Models on Consumer CPUs. arXiv:2610.17551v1, 13.10.2026. Vorabdruck, Konferenzannahme nach Autorenangabe, Begutachtung und Verlagsfassung nicht verifiziert. Erneuter Abruf am 15.10.2026 wegen Ratenbegrenzung nicht möglich. arxiv.org (Abruf: 14.10.2026).
2. Goh, E. u. a.: Large Language Model Influence on Diagnostic Reasoning: A Randomized Clinical Trial. JAMA Network Open 7 (10), e2440969, 2024. jamanetwork.com (Abruf: 15.10.2026).
3. Europäischer Datenschutzausschuss: Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models. 17.12.2024. edpb.europa.eu (Abruf: 14.10.2026).
4. Medical Device Coordination Group: MDCG 2019-11 rev.1 – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Juni 2025, Abschnitt 3. health.ec.europa.eu (Abruf: 14.10.2026).
5. Balkeum Labs: LLM-on-CPU. Repositorium zur Studie [1], 2026. Nicht ausgeführt, keine Codeprüfung. github.com (Abruf: 14.10.2026).
6. ggml-org: llama.cpp. Offizielles Repositorium und Dokumentation, Stand 2026. github.com (Abruf: 14.10.2026).
7. Lin, J. u. a.: AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys 2024, arXiv-Version 6. arxiv.org (Abruf: 14.10.2026).
8. Kwon, W. u. a.: Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. arxiv.org (Abruf: 14.10.2026).
9. Google: MedGemma 27B IT – Model Card. Herstellerdokumentation, Stand 2026. huggingface.co (Abruf: 15.10.2026).
10. Tu, T. u. a.: Towards conversational diagnostic artificial intelligence. Nature, 2025. DOI 10.1038/s41586-025-08866-7. nature.com (Abruf: 14.10.2026).
11. Weltgesundheitsorganisation: WHO releases AI ethics and governance guidance for large multi-modal models. 18.01.2024. who.int (Abruf: 14.10.2026).
12. Vasey, B. u. a.: Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. Nature Medicine, 2022. DOI 10.1038/s41591-022-01772-9. nature.com (Abruf: 14.10.2026).
13. Europäische Kommission: Legal grounds for processing data. Offizielle Erläuterung, Abschnitt Special categories of personal data, Stand 2026. commission.europa.eu (Abruf: 14.10.2026).
14. Europäische Kommission: Obligations. Offizielle Erläuterung zu Datenschutz durch Technikgestaltung, Sicherheit und Folgenabschätzung, Stand 2026. commission.europa.eu (Abruf: 14.10.2026).
15. OWASP: LLM01:2025 Prompt Injection. OWASP Top 10 for LLM Applications, 2025. genai.owasp.org (Abruf: 14.10.2026).
16. NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. nvlpubs.nist.gov (Abruf: 14.10.2026).
17. HL7 International: FHIR R4 (4.0.1) – Security. 2019. hl7.org (Abruf: 14.10.2026).
18. Europäische Kommission: Guidelines for providers and deployers of AI high-risk systems. Orientierungsseite, 2026. digital-strategy.ec.europa.eu (Abruf: 14.10.2026).
19. Europäische Kommission: AI Omnibus enters into force. 27.07.2026. Mitteilung, ersetzt nicht den konsolidierten Rechtstext. digital-strategy.ec.europa.eu (Abruf: 14.10.2026).
20. Intel / OpenVINO: Inference with OpenVINO GenAI. Entwicklerdokumentation 2026. docs.openvino.ai (Abruf: 14.10.2026).
21. Lekadir, K. u. a.: FUTURE-AI: international consensus guideline for trustworthy and deployable artificial intelligence in healthcare. BMJ 388, e081554, 2025. DOI 10.1136/bmj-2024-081554. pmc.ncbi.nlm.nih.gov (Abruf: 14.10.2026).
22. TRIPOD: TRIPOD-LLM Checklist. Ergänzende Berichtscheckliste, 2025. tripod-statement.org (Abruf: 14.10.2026).

© 2026 Olaf Dunkel. Eigenständige Analyse der unter „Quellen“ aufgeführten Belege; KI-Unterstützung rein sprachlich, inhaltliche Verantwortung beim Autor.