Vertrauliche Patientendaten dürfen unter keinen Umständen einfach in eine fremde Cloud geladen werden — trotzdem wollen viele Einrichtungen KI nutzen, um Dokumente zu analysieren, Zusammenfassungen zu erstellen oder Entscheidungsunterstützung bereitzustellen. In diesem Artikel beschreibe ich einen praktikablen, lokalen AI‑Workflow, der ganz ohne Cloud‑Upload auskommt und dabei Sicherheit, Nachvollziehbarkeit und Praxisnutzen in den Vordergrund stellt.

Grundprinzipien vorab

Bevor ich ins Detail gehe: für mich stehen drei Prinzipien immer obenan

  • Datenschutz by Design — Daten bleiben lokal, verschlüsselt und nur für autorisierte Prozesse zugänglich.
  • Transparenz — Nachvollziehbare Schritte, Protokollierung und reproduzierbare Modelle.
  • Praktische Umsetzbarkeit — Der Workflow soll mit Standard‑Hardware (oder klar spezifizierter Serverhardware) laufen und für klinische Teams bedienbar sein.

    • Überblick über den Workflow

    Mein Vorschlag gliedert sich in fünf Stufen: Ingestion & Preprocessing, De‑Identification, Speicherung & Indexierung, Lokale Modellinferenz (oder Fine‑Tuning) und Governance & Audit. Ich erläutere jede Stufe und nenne konkrete Tools, die sich in Projekten bewährt haben.

    Ingestion & Preprocessing

    Dokumente kommen in sehr unterschiedlichen Formaten: Arztbriefe (PDF), EKG‑Reports (Text), Bilder (Röntgen), Scans (OCR erforderlich). Die erste Aufgabe ist zuverlässiges Parsen:

  • PDF/Text: pdfminer.six, Apache Tika oder pdfplumber für strukturierte Extraktion.
  • Scans & Bilder: Tesseract OCR (lokal) oder kommerzielle Engines, solange sie on‑premise bleiben.
  • Medizinische Formate: DICOM für Bildgebung — Tools wie pydicom helfen beim Extrahieren von Metadaten.

    • Wichtig ist, dass Metadaten (z. B. in PDF oder DICOM) gezielt geprüft und nicht automatisch übernommen werden — viele sensible Angaben stecken dort.

    De‑Identification (Pseudonymisierung / Anonymisierung)

    Bevor Inhalte einem Modell zugeführt werden, empfehle ich eine klare Zweiteilung: statistische Anonymisierung für Forschungszwecke vs. pseudonymisierte Daten für klinische Workflows. Werkzeuge, die ich nutze:

  • Philter – ein regelbasierter PHI‑Filter, der Namen, Adressen, IDs identifiziert und entfernt oder ersetzt.
  • spaCy mit medizinischen NER‑Modellen (z. B. med7) für angepasste Erkennung von Entitäten.
  • Eigene Regex‑Regeln und Whitelists — medizinische Texte enthalten oft Lokalismen, deshalb kombiniere ich ML‑Erkennung mit deterministischen Regeln.

    • Bei hoher Sensitivität kann man zusätzlich Differential Privacy‑Techniken (z. B. noise injection bei Statistikexporten) oder k‑Anonymität prüfen. Vollständige Anonymisierung ist nicht trivial — ich protokolliere stets, welche Felder verändert wurden.

    Speicherung & Indexierung (ohne Cloud)

    Die anonymisierten/pseudonymisierten Texte müssen effizient durchsuchbar sein für RAG‑Workflows (Retrieval‑Augmented Generation). Ich verwende grundsätzlich selbstgehostete Vektor‑Datenbanken:

    ToolVorteileNachteile
    FAISS (lokal)Sehr schnell, ideal für GPU/CPU, kein Server nötigKeine native HTTP‑API, Entwicklerintegration nötig
    Qdrant (self‑hosted)Einfacher Betrieb, HTTP/API, guter Community‑SupportRessourcenaufwand für große Datenmengen
    Chroma (self‑hosted)Einfach integrierbar mit Python, gut für PrototypenNoch jung, Production‑Care nötig
    Weaviate (on‑prem)Reiche Features, Graph‑FunktionenKomplexere Installation

    Die Embeddings erzeuge ich mit lokalen Modellen (siehe nächster Abschnitt) — niemals mit Cloud‑APIs, wenn Daten sensibel sind.

    Lokale Modellinferenz: Modelle und Inferenz‑Engines

    Für meine Zwecke unterscheide ich zwei Ansätze:

  • Leichte lokale Modelle (z. B. GPT‑J, Llama‑2 klein, Mistral oder GPT4All) mit llama.cpp oder gptq quantisiert für CPU‑Nutzung.
  • Leistungsfähige On‑Prem GPUs (NVIDIA A10/A40/RTX) für größere Modelle mit transformers + accelerate oder ONNX Runtime / TorchServe.

    • Für viele klinische Aufgaben ist ein RAG‑Ansatz sinnvoll: die Anfrage des Nutzers wird mit top‑k Dokumenten aus der Vektor‑DB kombiniert und dann lokal an das LLM zur Generierung übergeben. Das reduziert die benötigte Modellgröße und erhöht Nachvollziehbarkeit.

    Für Inferenz und Deployment setze ich auf:

  • llama.cpp (ausgezeichnet für lokale CPU‑Inference und kleine Server).
  • GPTQ‑quantisierte Modelle für geringeren Speicherverbrauch (z. B. GPTQ‑Versionen von Llama‑2 oder Alpaca‑Forks).
  • ONNX Runtime oder Triton Inference Server für GPU‑Beschleunigung in produktiven Umgebungen.

    • Fine‑Tuning vs. Prompt‑Engineering

    Ich empfehle, soweit möglich, auf Full‑Fine‑Tuning sensibler Daten zu verzichten. Stattdessen bevorzuge ich:

  • RAG mit präzisen Prompt‑Templates und Systemprompts.
  • Low‑rank adapters (LoRA) — diese können lokal angewandt werden und sind einfacher zu kontrollieren als komplette Modelle.

    • Wenn Fine‑Tuning notwendig ist, dokumentiere ich Datenquellen, halte das Training on‑prem lokal und sichere Modelle und Checkpoints verschlüsselt.

    Sicherheit, Zugriffskontrolle & Audit

    Der beste Workflow nützt nichts ohne ordentliche Governance:

  • Verschlüsselung at rest (LUKS, BitLocker) und in transit (TLS innerhalb des Netzwerks).
  • Strenge Zugriffskontrollen: RBAC, MFA für Admins und Protokollierung aller Zugriffe.
  • Audit‑Logs: Wer hat welche Anfrage gestellt, welche Dokumente wurden gezogen, welche Antworten generiert? Diese Logs sollten manipulationssicher (append‑only) gespeichert werden.
  • Containerisierung (Docker/Kubernetes) mit Netzwerkisolierung für Modelle und Datenbanken — so lassen sich Updates und Security‑Patches kontrolliert ausrollen.

    • Hardware‑Empfehlungen

    Für kleine Pilotprojekte genügt oft ein starker CPU‑Server oder ein Apple Silicon‑Mac mit M‑Serie. Für produktive, skalierende Anwendungen empfehle ich GPUs (z. B. NVIDIA A10/A40 oder 80GB‑Hopper/RTX in dedizierten Servern). Wichtig sind außerdem:

  • Schneller NVMe‑Storage für Vektor‑DBs und Modelle.
  • Genügend RAM (je nach Modell 32–512 GB).

    • Regulatorische Hinweise

    Ich bin keine Rechtsberatung, aber ich weise deutlich darauf hin: in der EU greifen DSGVO‑Regeln, in den USA häufig HIPAA. Für jeden produktiven Einsatz muss eine datenschutzrechtliche Bewertung erfolgen — oft sind Auftragsverarbeitungsverträge (AV‑Verträge) und Datenschutzfolgeabschätzungen Pflicht. Technisch bin ich dafür, alle Belege für Entscheidungen und Datenflüsse leicht zugänglich vorzuhalten.

    Praxisbeispiel: Klinisches Summaries‑Tool, lokal

    Konkreter Aufbau, wie ich ihn oft teste:

  • Ingestion: PDFs per SFTP in einen Intake‑Ordner.
  • Preprocessing & OCR: Tesseract + pdfplumber.
  • De‑Identification: Philter + spaCy‑Med7, Pseudonymisierung via deterministische Hashes.
  • Indexierung: Embeddings lokal mit einer quantisierten Llama‑Variante, FAISS für schnellen nearest‑neighbor.
  • Inference: RAG mit llama.cpp (CPU) oder einer kleinen GPU‑instanz; Ausgabe wird nochmals auf PHI geprüft bevor sie angezeigt wird.
  • Governance: Audit‑Log, RBAC, regelmäßige Sicherheits‑Scans.

    • Wenn Sie möchten, kann ich Ihnen auf Basis Ihrer Infrastruktur (Server, OS, erwartetes Datenvolumen) einen konkreten, anpassbaren Architekturvorschlag erstellen — inklusive Docker‑Compose/Helm‑Skizze und einer Liste kompatibler Modellgewichte, die sich gut lokal betreiben lassen.