Thema 8.4 — Governance von KI und aufkommenden Technologien

In einem Satz: Künstliche Intelligenz in Gesundheit und Pflege ist eine lernende, datenabhängige und oft undurchsichtige Technologie, die Nutzen wie Schaden schneller skalieren kann als jedes System, das Sie bisher gesteuert haben; Sie müssen sie daher über ihren gesamten Lebenszyklus als Angelegenheit der klinischen Sicherheit, der Gleichstellung und des öffentlichen Vertrauens steuern – nicht als gewöhnliche Software behandeln, die man einmal kauft und vergisst.

Warum das in Gesundheit und Pflege wichtig ist#

Die meiste Software, die Sie eingesetzt haben, verhält sich morgen so wie heute: Ihre Logik ist aufgeschrieben, ihr Verhalten ist testbar, und wenn sie falsch liegt, liegt sie meist auf sichtbare, wiederholbare Weise falsch. Künstliche Intelligenz bricht alle drei Bequemlichkeiten. Sie lernt statistische Muster aus Daten, statt Regeln zu befolgen, die ein Mensch schrieb; ihr Verhalten hängt ganz von den Daten ab, mit denen sie trainiert wurde, und den Daten, denen sie nun begegnet; und ihr Schlussfolgern ist häufig selbst für die undurchsichtig, die sie gebaut haben. Diese Kombination ist der Grund, warum KI eine eigene Governance-Disziplin braucht, statt in eine generische Software-Checkliste gefaltet zu werden.

In Gesundheit und Pflege sind die Folgen nicht abstrakt. Ein Modell, das Krankheit bei einer Gruppe untererkennt, die in seinen Trainingsdaten unterrepräsentiert war, macht keinen isolierten Fehler – es macht denselben Fehler, still, tausendfach und verfestigt und skaliert gesundheitliche Ungleichheit. Ein generatives Modell, das ein plausibel klingendes klinisches Detail erfindet, kann eine überlastete Klinikerin genau im falschen Moment in die Irre führen. Ein Werkzeug, das in der Population, an der es validiert wurde, wunderbar funktioniert, kann still verfallen, wenn sich die Population, der Versorgungspfad oder die vorgelagerten Daten ändern. KI kann gute Entscheidungen skalieren, und sie kann Voreingenommenheit, Fehler und Schaden mit gleicher Effizienz skalieren.

Dieses Thema handelt davon, dieses Risiko zu steuern, ohne dem Hype zu verfallen oder die Technologie zu verbieten. Es wiederholt bewusst nicht die anderswo gelegten Grundlagen: klinische Sicherheit (siehe Thema 1.6 — Klinische Sicherheit und Risikomanagement), Informationsgovernance, Datenschutz und Cybersicherheit (siehe Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit) und evidenzbasierte Entscheidungsfindung (siehe Thema 1.3 — Evidenzbasierte Entscheidungen). Es verankert sich in ihnen und fügt hinzu, was für lernende Systeme spezifisch ist. Behandeln Sie es als die KI-förmige Erweiterung Ihrer bestehenden Assurance und als das gesteuerte Geschwister der phasenweisen Einführung von Innovation (siehe Thema 8.0 — Innovation phasenweise einführen).

Kernkonzepte#

Künstliche Intelligenz und maschinelles Lernen. Für eine Führungskraft ist die praktische Unterscheidung diese: Die meiste KI in Gesundheit und Pflege ist heute maschinelles Lernen – Systeme, die Muster aus Beispielen ableiten, statt handgeschriebene Regeln auszuführen. Deshalb sind die Daten ebenso das Produkt wie der Code: Ändern Sie die Trainingsdaten, ändern Sie das Verhalten. Es bedeutet auch, dass ein Modell nichts „weiß“; es schätzt und kann selbstsicher falsch liegen. Das auf konzeptioneller Ebene zu verstehen genügt, um die richtigen Governance-Fragen zu stellen; Sie müssen die Mathematik nicht lesen.

Software as a Medical Device (SaMD) und die MHRA. Wenn Software einen medizinischen Zweck hat – diagnostizieren, screenen, triagieren, eine Dosis berechnen, eine Verschlechterung vorhersagen –, ist sie sehr oft rechtlich ein Medizinprodukt, unabhängig davon, ob sie auf einem Telefon oder einem Server läuft. Medizinische Software dieser Art, bekannt als Software as a Medical Device (SaMD), wird im Vereinigten Königreich von der Medicines and Healthcare products Regulatory Agency (MHRA) reguliert. Wenn Sie ein KI-Werkzeug mit klinischem Zweck beauftragen oder bauen, ist die erste Governance-Frage, ob es ein reguliertes Produkt ist und, wenn ja, ob es eine gültige Konformitätskennzeichnung hält. Das falsch zu machen ist keine Formalität; ein nicht registriertes Medizinprodukt einzusetzen ist rechtswidrig und unsicher.

Der AI Airlock. Die MHRA hat eine regulatorische Sandbox namens AI Airlock eingerichtet, um in einem kontrollierten, überwachten Umfeld durchzuarbeiten, wie KI als Medizinprodukt reguliert werden sollte. Eine regulatorische Sandbox lässt einen Regulierer und eine kleine Zahl von Entwicklern schwierige, neuartige Fragen – zum Beispiel wie ein Modell zu validieren ist, das sich über die Zeit aktualisiert – unter Aufsicht untersuchen, bevor allgemeine Regeln gesetzt werden. Seien Sie nüchtern, was das ist: Der Airlock ist ein Lernumfeld für den Regulierer und eine Handvoll Teilnehmender, kein Schnellzulassungsweg, und die Verbindung mit ihm bedeutet nicht, dass ein Produkt für den allgemeinen klinischen Einsatz zugelassen ist.

Algorithmische Voreingenommenheit und Fairness. Algorithmische Voreingenommenheit (Algorithmic Bias) ist die Neigung eines Systems, systematisch unfaire Ergebnisse für bestimmte Gruppen zu erzeugen. In Gesundheit und Pflege ist ihre häufigste Quelle die Trainingsdaten: Wenn eine Gruppe unterrepräsentiert, falsch etikettiert oder mit einem voreingenommenen Instrument gemessen ist, lernt das Modell, diese Gruppe schlechter zu bedienen. Weil das Modell dies dann im großen Maßstab und mit dem Anschein von Objektivität anwendet, kann voreingenommene KI genau die Ungleichheiten vergrößern, die Ihre Organisation gesetzlich zu verringern verpflichtet ist.

Erklärbarkeit und die Blackbox. Erklärbare künstliche Intelligenz betrifft die Frage, ob ein Mensch verstehen kann, warum ein Modell eine bestimmte Ausgabe erzeugte. Viele hochleistungsfähige Modelle sind faktisch „Blackboxes“: im Aggregat genau, aber unfähig, einer Klinikerin einen vertrauenswürdigen Grund für eine Einzelentscheidung zu geben. Im klinischen Umfeld zählt das für Rechenschaft, informierte Einwilligung und die Pflicht der Klinikerin, Urteil auszuüben – eine Ärztin kann für einen Rat, den sie nicht befragen kann, nicht sinnvoll Verantwortung übernehmen.

Modelldrift und Überwachung nach dem Inverkehrbringen. Die Genauigkeit eines Modells ist nicht fest. Concept Drift – eine Veränderung über die Zeit in der Beziehung zwischen Eingaben und dem Vorhergesagten – bedeutet, dass ein im letzten Jahr validiertes Modell dieses Jahr still verfallen kann, wenn sich Populationen, Pfade oder vorgelagerte Daten ändern. Deshalb braucht KI fortlaufende Überwachung nach dem Inverkehrbringen (Post-Market Surveillance) und Monitoring, nicht nur einmalige Validierung beim Go-live.

MLOps und der Modelllebenszyklus. MLOps ist die operative Disziplin, Modelle zuverlässig in der Produktion einzusetzen, zu überwachen, zu versionieren und neu zu trainieren. Es ist die Maschinerie, die Lebenszyklus-Governance real macht: zu wissen, welche Modellversion live ist, auf welchen Daten, mit welcher Leistung, und zurückrollen zu können.

Human-in-the-Loop. Ein Human-in-the-Loop-Design hält einen Menschen – meist eine Klinikerin – sinnvoll in der Entscheidung, mit der Befugnis und den Informationen, das Modell zu übersteuern. Gut gemacht bewahrt es Rechenschaft; als Gummistempel gemacht bietet es nur die Illusion von Aufsicht.

Generative KI und große Sprachmodelle. Generative künstliche Intelligenz, einschließlich großer Sprachmodelle (LLMs), erzeugt flüssigen Text und andere Inhalte. Ihr realistischer kurzfristiger Wert in Gesundheit und Pflege ist weitgehend administrativ – Dokumentation entwerfen, zusammenfassen, Papierkram erleichtern. Ihr bestimmendes Risiko ist die Halluzination: das selbstsichere Erzeugen falscher, aber plausibler Inhalte, verschärft durch Vertraulichkeitsrisiken, wenn Patientendaten in Dienste Dritter eingegeben werden.

Digitale Therapeutika und Gesundheits-Apps. Digitale Therapeutika (DTx) sind softwaregetriebene, evidenzbasierte Interventionen, die eine Erkrankung verhüten, managen oder behandeln – gerade deshalb von allgemeinen Wellness-Apps verschieden, weil sie einen klinischen Anspruch erheben, was bedeutet, dass viele Software as a Medical Device sind und dieselbe Evidenz und Assurance verlangen wie jede andere Intervention, die Sie verschreiben oder empfehlen.

Bewährte Praktiken#

1. Klassifizieren Sie das Werkzeug, bevor Sie irgendetwas anderes tun. Stellen Sie schriftlich und mit klinischem und regulatorischem Input fest, ob die KI einen medizinischen Zweck hat und daher ein reguliertes Medizinprodukt ist und ob sie eine gültige MHRA-Konformitätskennzeichnung hält. Diese einzelne Bestimmung regelt alles Nachgelagerte – den Assurance-Weg, die Haftungen, die Rechtmäßigkeit des Einsatzes. Im Zweifel holen Sie regulatorischen Rat ein, statt anzunehmen, ein administratives Werkzeug liege außerhalb des Umfangs.

2. Führen Sie KI durch Ihre bestehende Maschinerie von klinischer Sicherheit und IG, erweitert, nicht umgangen. Jeder klinische KI-Einsatz braucht das klinische Risikomanagement nach DCB0129/DCB0160 (siehe Thema 1.6) und eine Datenschutz-Folgenabschätzung (DPIA) unter Ihrem Rahmen der Informationsgovernance (siehe Thema 1.7). Lassen Sie nicht zu, dass Neuheit oder Begeisterung des Lieferanten einen parallelen, leichteren Prozess erzeugt. KI-spezifische Gefährdungen – Voreingenommenheit, Drift, Undurchsichtigkeit, Automationsbias – sollten dem Gefährdungsprotokoll hinzugefügt werden, nicht an seine Stelle treten.

3. Befragen Sie die Trainingsdaten auf Repräsentativität und Voreingenommenheit. Fragen Sie, wer in den Daten ist und wer fehlt, wie Ergebnisse etikettiert wurden und ob die Messinstrumente selbst über Gruppen hinweg voreingenommen waren. Verlangen Sie vom Lieferanten, die Leistung aufgeschlüsselt nach relevanten Untergruppen – Alter, Geschlecht, Ethnizität, Benachteiligung – zu berichten, nicht nur die Schlagzeilengenauigkeit. Ein Werkzeug, das keine gerechte Leistung belegen kann, ist ein Risiko gesundheitlicher Ungleichheit, wie beeindruckend sein Durchschnitt auch sei.

4. Verlangen Sie klinische Validierung, die zum Risiko passt, und bevorzugen Sie prospektive Evidenz. Retrospektive Genauigkeit an kuratierten Daten ist die schwächste Form von Evidenz. Suchen Sie für alles, was klinische Entscheidungen beeinflusst, Validierung in einer Population und einem Arbeitsablauf wie Ihrem, idealerweise prospektiv, und leiten Sie den Anspruch durch das passende Assurance-Framework – das NICE Evidence Standards Framework für digitale Gesundheitstechnologien und die Digital Technology Assessment Criteria (DTAC) als Basis-Assurance. Passen Sie die Stärke der Evidenz an das Ausmaß des potenziellen Schadens an.

5. Bestehen Sie auf sinnvollem Human-in-the-Loop und klarer Rechenschaft. Definieren Sie, wer für eine von der KI informierte Entscheidung rechenschaftspflichtig ist, und stellen Sie sicher, dass der Mensch sowohl die Befugnis zu übersteuern als auch die Information dazu hat. Hüten Sie sich aktiv vor Automationsbias – der Neigung, der Maschine nachzugeben – durch Schulung, Schnittstellendesign und Audit der Übersteuerungsraten. Wenn Übersteuerungen nie geschehen, ist Ihr „Human in the Loop“ dekorativ.

6. Behandeln Sie den Go-live als Beginn des Monitorings, nicht als Ende der Assurance. Richten Sie Überwachung nach dem Inverkehrbringen von Tag eins ein: Überwachen Sie die reale Leistung, achten Sie auf Concept Drift und definieren Sie die Schwellen und den Prozess für Neutraining, Pausieren oder Rückzug des Modells. Etablieren Sie Modellversionierung und Rollback durch solides MLOps, damit Sie immer wissen, was live ist, und sicher zurückkehren können. Ein Modell, das nie erneut geprüft wird, ist eine langsam versagende Sicherheitskontrolle.

7. Steuern Sie generative KI nach ihren realistischen Verwendungen und gegen ihre realen Risiken. Erlauben Sie LLMs dort, wo der Wert echt und das Risiko begrenzt ist – administratives Entwerfen, Zusammenfassen, Dokumentationsunterstützung mit menschlicher Prüfung – und untersagen Sie die ungemanagte Eingabe personenidentifizierbarer Patientendaten in Dienste Dritter. Nehmen Sie an, dass jede generative Ausgabe erfunden sein kann, bis ein Mensch sie verifiziert, und lassen Sie nie unverifizierten generierten Inhalt in die klinische Akte gelangen. Klare, durchgesetzte Richtlinie schlägt sowohl ein pauschales Verbot, das Schattennutzung treibt, als auch einen Freibrief, der Daten leckt.

8. Wenden Sie Informationsgovernance auf den ganzen Datenlebenszyklus an, einschließlich Training. Die Daten, die zum Trainieren, Feinabstimmen und Evaluieren eines Modells genutzt werden, unterliegen denselben Pflichten zu Rechtsgrundlage, Minimierung und Transparenz wie jede andere Nutzung (siehe Thema 1.7). Seien Sie ausdrücklich zur Grundlage für das Training an Patientendaten, ob sie ausreichend de-identifiziert sind und was der Lieferant damit tun darf. Verträge sollten die Wiederverwendung Ihrer Daten zum Trainieren von Produkten für andere ohne Rechtsgrundlage und Ihre Zustimmung verbieten.

9. Führen Sie ein menschenlesbares Modellregister und verlangen Sie Transparenz von Lieferanten. Pflegen Sie ein Inventar der genutzten KI: Zweck, regulatorischer Status, Herkunft der Trainingsdaten, Validierungsevidenz, Monitoringplan und rechenschaftspflichtige Verantwortliche. Verlangen Sie von Lieferanten Transparenz dazu, wie ein Modell funktioniert, welche Grenzen und Fehlermodi es hat; Undurchsichtigkeit eines Herstellers ist selbst ein Risikosignal. Sie können nicht steuern, was Sie nicht aufgeschrieben haben.

10. Scannen Sie den Horizont bewusst und führen Sie durch kontrollierte Evaluation stufenweise ein. Beobachten Sie über die heutige KI hinaus aufkommende Technologien – ambiente Dokumentation, Foundation Models und weiter entfernt Quanten und neuartige Sensorik – mit strukturiertem Horizon-Scanning statt reaktiver Beschaffung. Führen Sie alles wirklich Neuartige über den kontrollierten, umkehrbaren, evaluierten Ansatz der phasenweisen Einführung von Innovation (siehe Thema 8.0) ein, klein beginnend, ehrlich messend und mit der Fähigkeit zu stoppen.

11. Behandeln Sie digitale Therapeutika und Gesundheits-Apps als Interventionen, nicht als Verbraucher-Downloads. Wenn eine App einen klinischen Anspruch erhebt – eine Erkrankung zu behandeln, zu managen oder zu verhüten –, ist sie eine Intervention, nach der Patientinnen handeln werden, und verdient vor dem Verschreiben oder Empfehlen dieselbe Prüfung wie ein Arzneimittel oder Produkt. Stellen Sie fest, ob sie Software as a Medical Device mit gültiger Konformitätskennzeichnung ist, verlangen Sie Evidenz, die ihrem Anspruch entspricht, und schließen Sie eine Bewertung der klinischen Sicherheit ab (siehe Thema 1.6), statt einer App-Store-Bewertung oder der Begeisterung eines Lieferanten zu vertrauen. Eine nicht abgesicherte App, die eine Klinikerin befürwortet, trägt den Namen Ihrer Organisation und Ihre Rechenschaft, wenn sie schadet.

12. Leiten Sie Gesundheits-Apps durch bestehende Assurance und halten Sie eine kuratierte, sichere Bibliothek. Bewerten Sie digitale Therapeutika durch dieselbe Maschinerie, die Sie ohnehin betreiben – DTAC als Basis, das NICE Evidence Standards Framework passend zum klinischen Anspruch und Überprüfung von klinischer Sicherheit und IG –, und bauen Sie die Evidenz der Evaluation unter realen Bedingungen über die Zeit auf (siehe Thema 8.6). Pflegen Sie eine kuratierte Bibliothek von Apps, die Sie abgesichert haben und hinter denen Sie stehen, mit regulatorischem Status, Evidenz und Verantwortlicher jeder App festgehalten, damit Klinikpersonal aus einer sicheren, gesteuerten Shortlist empfiehlt. Die Alternative – ein unkontrollierter Wildwuchs nicht bewerteter Apps, informell über Teams hinweg empfohlen – ist unmanagebar und unsicher.

Fragen zur Diskussion im Team#

1. Wissen wir für jedes KI-Werkzeug, das wir erwägen oder bereits nutzen, tatsächlich, ob es ein reguliertes Medizinprodukt ist – und können wir die Evidenz vorlegen? Das klingt nach einer Compliance-Formalität, ist aber die tragende Frage, denn die Antwort bestimmt, was rechtmäßig ist, wer haftet und welche Assurance Sie der Öffentlichkeit schulden. Es ist leicht anzunehmen, ein Werkzeug, das „nur bei der Triage hilft“ oder „nur Notizen zusammenfasst“, sei harmlose administrative Software, obwohl sein medizinischer Zweck es tatsächlich zu einem regulierten Produkt macht, das eine MHRA-Konformitätskennzeichnung verlangt. Die Diskussion sollte Sie zwingen, jedes genutzte oder in der Pipeline befindliche KI-Werkzeug zu benennen, seinen beabsichtigten Zweck in schlichten klinischen Begriffen zu nennen und zu identifizieren, wer die Entscheidung zur Produktklassifikation traf und auf welcher Grundlage. Sie sollte die unbequemen Fälle ans Licht bringen, in denen ein Werkzeug über einen gewöhnlichen IT-Weg ganz ohne regulatorische Prüfung beschafft wurde. Seien Sie ehrlich, ob Sie heute die Konformitätsdokumentation und Validierungsevidenz vorlegen könnten, wenn ein Regulierer oder ein Coroner danach fragte. Der Wert des Gesprächs ist, dass es ein vages Gefühl, „jemand muss es geprüft haben“, in eine dokumentierte, verantwortete Position verwandelt – und die Werkzeuge offenlegt, bei denen niemand es tat.

2. Haben wir verlangt zu sehen, wie dieses Modell für die Gruppen abschneidet, die am ehesten geschädigt werden, oder haben wir eine Schlagzeilengenauigkeit akzeptiert? Durchschnittliche Genauigkeit ist die Zahl, mit der Lieferanten führen, und die Zahl, die algorithmische Voreingenommenheit verbirgt, denn ein Modell kann insgesamt hochgenau sein und dabei für eine unterrepräsentierte Gruppe deutlich schlechter abschneiden. In Gesundheit und Pflege ist das keine statistische Kuriosität; es ist ein Mechanismus, die Ungleichheiten zu vergrößern, die zu verringern Sie rechtlich und moralisch verpflichtet sind, still und im großen Maßstab angewandt. Das Team sollte besprechen, welche Untergruppenevidenz Sie tatsächlich gesehen haben – Leistung aufgeschlüsselt nach Alter, Geschlecht, Ethnizität und Benachteiligung – und ob Sie wissen, wer in den Trainingsdaten war und wer fehlte. Es lohnt sich, das Unbehagen hier zu benennen: Einen Lieferanten zur Fairness zu drängen kann sich anfühlen wie das Behindern einer aufregenden Innovation, und die ehrliche Frage ist, ob Sie bereit sind, Nein zu einem Werkzeug zu sagen, das keine gerechte Leistung belegen kann. Bedenken Sie auch, wie Sie ungerechte Ergebnisse nach dem Einsatz überhaupt erkennen würden, denn Voreingenommenheit, die bei der Beschaffung unsichtbar war, wird in der Produktion unsichtbar sein, sofern Sie sie nicht überwachen. Eine gute Diskussion endet mit einer konkreten Evidenzlatte für Fairness, die vor jedem Live-Gang klinischer KI gilt, und einem Plan, danach weiter hinzusehen.

3. Wenn dieses Modell falsch liegt – und das wird es –, wer ist rechenschaftspflichtig, wird ein Mensch es wirklich fangen und woran würden wir es überhaupt merken? Jedes Modell versagt manchmal, und lernende Systeme können mit der Zeit in häufigeres Versagen driften; die reife Frage ist daher nicht, ob Fehler auftreten, sondern ob Ihre Sicherungen real sind. Das Team sollte testen, ob der Human-in-the-Loop sinnvoll oder dekorativ ist: Hat die Klinikerin die Befugnis und die Information zu übersteuern, und würden Sie, schauten Sie auf Übersteuerungsraten, feststellen, dass sie je tatsächlich übersteuert, oder hat sich Automationsbias eingestellt? Besprechen Sie, wer als rechenschaftspflichtig für eine von der KI informierte Entscheidung benannt ist – die Klinikerin, die Organisation, der Lieferant –, denn „der Algorithmus hat es getan“ ist gegenüber einer Patientin oder einem Coroner keine vertretbare Position. Stellen Sie sich Ihrem Monitoring ehrlich: Haben Sie Überwachung nach dem Inverkehrbringen, die Concept Drift erkennen würde, definierte Schwellen für Pausieren oder Rückzug des Modells und die MLOps-Maschinerie, um zu wissen, welche Version live ist, und sie zurückzurollen? Für generative Werkzeuge fügen Sie die Halluzinationsfrage hinzu – was hindert erfundenen Inhalt daran, in die klinische Akte zu gelangen, und wer verifiziert Ausgaben, bevor ihnen vertraut wird? Die nützlichste Version dieses Gesprächs legt die Lücke zwischen dem beruhigenden Diagramm „menschlicher Aufsicht“ und dem offen, was um 3 Uhr nachts auf einer geschäftigen Station tatsächlich geschähe.

4. Was geschieht mit den Daten unserer Patientinnen, wenn wir diese Modelle trainieren, feinabstimmen und betreiben – und was hat sich der Lieferant vorbehalten, damit zu tun? KI konzentriert Datengovernance-Risiko gerade deshalb, weil die Daten das Produkt sind: Ein Modell ist nur so vertrauenswürdig wie die Rechtsgrundlage, Minimierung und Transparenz hinter jedem Datensatz, den es berührte, einschließlich der Trainings- und Evaluationsdaten, die dem Go-live vorausgehen. Das Team sollte für jedes Werkzeug die Rechtsgrundlage für jede Nutzung von Patientendaten nennen können, ob die De-Identifikation angemessen statt bloß behauptet ist und wohin die Daten physisch fließen, sobald sie Ihre Kontrolle verlassen. Eine wiederkehrende Falle ist der Vertrag, der dem Lieferanten still erlaubt, Ihre Daten zur Verbesserung von Produkten wiederzuverwenden, die er an andere verkaufen wird; besprechen Sie, ob Ihre Vereinbarungen das ohne Rechtsgrundlage und Ihre ausdrückliche Zustimmung verbieten und ob jemand diese Klauseln tatsächlich gelesen hat. Das verbindet sich direkt mit Ihrem Rahmen der Informationsgovernance (siehe Thema 1.7), und hier überholt die Begeisterung für ein leistungsfähiges Werkzeug am häufigsten die Sorgfaltspflicht. Eine ehrliche Antwort benennt, wem die DPIA gehört, was der Lieferant tun darf und was nicht und wo Sie derzeit exponiert sind – statt anzunehmen, weil die Demo beeindruckend war, müsse der Papierkram solide sein.

5. Wie entscheiden wir, was wir NICHT übernehmen, und können wir dem Druck widerstehen, das Ding zu kaufen, auf das alle gespannt sind? Die schwerste Governance-Disziplin bei einer sich schnell bewegenden Technologie ist, „noch nicht“ oder „nicht das“ zu sagen, und ein Team, das seine Kriterien zum Ablehnen nicht artikulieren kann, wird per Drift und Hype statt per Evidenz übernehmen. Besprechen Sie, was Sie von einem sonst attraktiven Werkzeug abbringen würde – schwache Untergruppenevidenz, ein unklarer regulatorischer Status, ein Anwendungsfall, in dem der realistische Nutzen gegenüber dem Risiko dünn ist – und ob diese roten Linien aufgeschrieben oder nur gefühlt sind. Hier besteht eine echte Spannung zwischen den Kosten, eine echte Verbesserung zu verpassen, und den Kosten eines skalierten Scheiterns, das das öffentliche Vertrauen beschädigt, und vernünftige Menschen werden sie unterschiedlich gewichten. Es lohnt sich, die politische Realität zu benennen, dass der Druck zur Übernahme oft von einem Vorstand, einer Lieferantenbeziehung oder einem nationalen Mandat kommt, nicht vom klinischen Bedarf selbst. Die Haltung des Themas ist, den Horizont bewusst zu scannen und durch kontrollierte, umkehrbare Evaluation stufenweise einzuführen (siehe Thema 8.0); eine ehrliche Antwort beschreibt daher, wie ein vielversprechendes, aber unbewiesenes Werkzeug als kleiner, gemessener, stoppbarer Pilot statt als Rollout im Ganzen eintritt – und wer die Befugnis hat, ihn zu stoppen.

6. Können wir den Klinikerinnen, die ihm vertrauen müssen, und den Patientinnen, die davon betroffen sind, erklären, was dieses Modell tut – und waren wir ehrlich zu seinen Grenzen? Ein Modell, das eine Klinikerin nicht befragen und eine Patientin nicht verstehen kann, zersetzt das informierte Urteil und die informierte Einwilligung, von denen klinische Versorgung abhängt, wie genau es im Aggregat auch sei. Das Team sollte besprechen, wie viel Erklärbarkeit diese konkrete Verwendung tatsächlich verlangt: Eine Hilfe zur Priorisierung von Warteschlangen verlangt weniger als ein Werkzeug, das eine Diagnose oder Behandlungsentscheidung beeinflusst, und die Erklärung auf den Einsatz abzustimmen ist eine Governance-Entscheidung, kein technischer Nachgedanke. Bedenken Sie, was Sie dem Klinikpersonal sagen, das es nutzen soll – seinen Zweck, seine bekannten Fehlermodi, die Gruppen, für die es weniger verlässlich ist – und ob dieses Briefing offen oder eine Marketingzusammenfassung ist. Ehrlichkeit gegenüber Patientinnen zählt ebenfalls: Wird Menschen gesagt, wenn KI an ihrer Versorgung beteiligt ist, und in einer Sprache, nach der sie handeln können? Das ist auch eine Personalfrage, denn zu geringes Vertrauen bedeutet, dass ein nützliches Werkzeug ignoriert wird, während zu hohes Vertrauen den Automationsbias erzeugt, der Aufsicht aushöhlt. Eine ehrliche Antwort stellt sich der Frage, ob Ihre Schulung und Kommunikation kalibriertes Vertrauen aufbauen oder nur das Werkzeug verkaufen.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Einem Integrated Care System wird ein KI-Werkzeug angeboten, das Röntgenaufnahmen des Brustkorbs liest und wahrscheinliche Auffälligkeiten markiert, um die Warteschlange der Radiologiebefundung zu priorisieren. Die klinische Sicherheitsbeauftragte und der Ärztliche Direktor widerstehen dem Druck, es rasch zu beschaffen, und führen es stattdessen durch ordentliche Governance.

Zuerst die Klassifikation: Das Werkzeug hat einen klaren medizinischen Zweck, daher wird es als Software as a Medical Device bestätigt, und seine MHRA-Konformitätskennzeichnung und Aussage zur bestimmungsgemäßen Verwendung werden geprüft – die bestimmungsgemäße Verwendung ist Triage-Unterstützung, nicht autonome Diagnose, was alles Folgende prägt. Dann die Assurance: Das Werkzeug durchläuft DTAC als Basis, seine klinischen Ansprüche werden gegen das NICE Evidence Standards Framework geprüft, eine DCB0160-Risikobewertung wird abgeschlossen, und eine DPIA deckt die Bilddaten ab (siehe Themen 1.6 und 1.7). Das Team bittet um Untergruppenleistung und entdeckt, dass die Validierungspopulation eine lokale Demografie unterrepräsentierte; es verlangt zusätzliche lokale Validierung, bevor es fortfährt, und behandelt potenzielle Voreingenommenheit als Risiko gesundheitlicher Ungleichheit statt als Fußnote.

Beim Einsatz hält das Design einen Human in the Loop: Jedes Bild wird weiter von einer Radiologin befundet, und die KI ordnet nur die Warteschlange neu, sodass eine verpasste Markierung nicht allein eine verpasste Diagnose verursachen kann. Überwachung nach dem Inverkehrbringen wird von Tag eins eingerichtet – Überwachung von Erkennungsraten, Diskordanz zwischen Modell und befundenden Radiologen und jeder Drift, wenn sich Scanner-Hardware und Fallmix ändern – mit vorab vereinbarten Schwellen, das Werkzeug zu pausieren, und einem Rollback-Weg über den versionierten Einsatz des Lieferanten. Getrennt davon sagt dasselbe Governance-Forum Nein zu diesem ungemanagten Weg, als eine Station darum bittet, Patientenhistorien in ein öffentliches LLM einzufügen, um Entlassbriefe zu entwerfen, und beauftragt stattdessen ein zugelassenes, abgeschottetes Werkzeug mit menschlicher Verifizierung. Ein Jahr später hat das Werkzeug zur Priorisierung der Warteschlange die Durchlaufzeit der Befundung bescheiden verbessert, sein Monitoring hat nach einem Scanner-Upgrade eine Drift-Episode gefangen, und – entscheidend – die Organisation kann genau zeigen, wie es gesteuert wird.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit ist oft die KI, seine Governance-Reife ist daher sein Marktzugang. Gründer sollten regulatorische Klassifikation, klinische Validierung und Evidenz zu Voreingenommenheit als Kernproduktarbeit behandeln, nicht als eine vor einem Verkauf aufgesetzte Compliance-Steuer, denn die klinische Sicherheitsbeauftragte eines Käufers wird genau danach fragen, und ein „Nein“ beendet das Geschäft. Früh mit der MHRA zusammenzuarbeiten – potenziell über Mechanismen wie den AI Airlock für wirklich neuartige Fragen – und von Anfang an für DTAC und das NICE Evidence Standards Framework zu gestalten, verwandelt Assurance in einen Wettbewerbsvorteil. Das charakteristische Startup-Risiko ist Überziehen: Marketing, das der Evidenz vorauseilt, oder eine Demo mit durchschnittlicher Genauigkeit, die schwache Untergruppenleistung verbirgt. Die disziplinierte Gründerin baut Monitoring und Überwachung nach dem Inverkehrbringen früh ins Produkt ein, denn ein einzelnes skaliertes Versagen an einem Referenzstandort ist für ein kleines Unternehmen ein existenzielles Ereignis.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, eine Einzelstandort-Klinik – ist meist Käufer von KI statt Erbauer, trägt aber dieselben Pflichten wie ein großer Trust, ohne das dedizierte Personal für klinische Sicherheit, IG oder Informatik, sie zu erfüllen. Das praktische Risiko ist, ein Werkzeug auf die Zusicherungen eines Lieferanten hin zu übernehmen, weil es keine hauseigene Kapazität gibt, Produktklassifikation, Untergruppenevidenz oder eine DPIA zu verlangen, und niemanden, der bemerkt, wenn ein Modell driftet. Stützen Sie sich stark auf die Assurance, die andere bereits geleistet haben: Bevorzugen Sie Werkzeuge, die klar eine MHRA-Konformitätskennzeichnung halten und DTAC bestanden haben, kaufen Sie bei Lieferanten, die ihre Evidenz veröffentlichen, und empfehlen Sie Gesundheits-Apps nur aus einer kuratierten Bibliothek, die Ihr ICS oder eine nationale Stelle abgesichert hat, statt jede selbst zu bewerten. Wo Sie die Sicherheit eines Werkzeugs nicht persönlich verifizieren können, ist das ein Grund, sich der gemeinsamen Assurance Ihres Systems zu beugen, nicht die Prüfung zu überspringen. Selbst ein leichtgewichtiges Register, welche KI-Werkzeuge Sie wofür nutzen und wem sie gehören, macht eine unmanagebare Pflicht zu einer verhältnismäßigen.

Großunternehmen#

Ein großer Trust oder ein ICS hat den Apparat, KI ordentlich zu steuern, und den Umfang, der ein Fehlgehen ernst macht. Seine Aufgabe ist, bestehende Funktionen von klinischer Sicherheit, IG und Assurance auf KI auszuweiten – ein Modellregister, Fairness-Latten für Untergruppen, Monitoring nach dem Inverkehrbringen, MLOps für Versionierung und Rollback –, statt KI über ungeprüfte IT- oder Forschungswege eintreffen zu lassen. Die reale Gefahr des Großunternehmens ist Fragmentierung: Dutzende Piloten, Ambient-Scribe-Erprobungen und abteilungsweite LLM-Experimente vermehren sich ohne zentrales Inventar, ohne einheitliche DPIA und ohne jemanden, der rechenschaftspflichtig ist, wenn ein Werkzeug driftet. Veränderungsmüdigkeit und Lieferantendruck drängen zu schneller Übernahme, sodass die Führung die Linie halten muss, dass Neuheit keinen leichteren Prozess verdient. Gut gemacht, kann das Großunternehmen auch die prospektive, lokale Validierungsevidenz erzeugen, die kleinere Akteure nicht können, und sie über das System teilen.

Regierung#

Nationale und lokale Regierungsstellen – die MHRA, NHS England, DHSC, NICE, dezentrale Verwaltungen und Kommunalbehörden – setzen die Bedingungen, unter denen alle anderen KI einsetzen. Ihre Instrumente sind Regulierung, Standards, Assurance-Frameworks (DTAC, das Evidence Standards Framework), Safe-Harbour-Mechanismen wie der AI Airlock und die Finanzierung und Leitlinien, die sichere Annahme über ein föderiertes System lenken, das sie nicht direkt anleiten. Rechenschaft läuft zu Ministern, Parlament und Öffentlichkeit, sodass ein skaliertes KI-Versagen oder eine nachweisbare Voreingenommenheit in einem nationalen Werkzeug ein Ereignis des öffentlichen Vertrauens mit langem Schatten ist. Die eigentliche Rolle der Regierung ist, den sicheren Weg zum leichten zu machen – klare Regeln, wiederverwendbare Assurance, ehrliche öffentliche Kommunikation darüber, was KI kann und nicht kann –, während sie sowohl hypegetriebenen Vorgaben als auch reflexhaftem Verbot widersteht. Die Balance in eine der beiden Richtungen falsch zu treffen kostet Jahre an Vertrauen.

Häufige Fehlermuster#

• Regulatorische Klassifikation überspringen. Eine klinische KI einsetzen, als wäre sie gewöhnliche Software. Vermeiden durch zuerst Produktstatus und Konformitätskennzeichnung mit regulatorischem Input bestimmen.
• Blindheit für Schlagzeilengenauigkeit. Eine Durchschnittszahl akzeptieren, die schwache Leistung für unterrepräsentierte Gruppen verbirgt. Vermeiden durch Untergruppenevidenz vor dem Go-live verlangen und nach dem Einsatz auf Ungleichheit überwachen.
• Einmal validieren, ewig vergessen. Den Go-live als Ende der Assurance behandeln, während das Modell still driftet. Vermeiden durch Überwachung nach dem Inverkehrbringen mit Schwellen und Rollback.
• Dekorative menschliche Aufsicht. Ein „Human in the Loop“, der unter Automationsbias abstempelt. Vermeiden durch Audit der Übersteuerungsraten und Gestaltung echter Eingriffsbefugnis.
• Ungesteuerte generative KI. Personal fügt Patientendaten in öffentliche LLMs ein und vertraut erfundener Ausgabe. Vermeiden durch klare Richtlinie plus ein zugelassenes, abgeschottetes Werkzeug mit menschlicher Verifizierung.
• Paralleler leichter Prozess. KI klinische Sicherheit und IG umgehen lassen, weil sie „Innovation“ ist. Vermeiden durch Ausweitung der bestehenden DCB- und DPIA-Maschinerie auf KI.
• Kein Inventar. Niemand weiß, welche Modelle live sind, auf welchen Daten, wem gehörend. Vermeiden durch Pflege eines Modellregisters.

Reifegradmodell#

Checkliste#

• Der Medizinproduktstatus und die MHRA-Konformitätskennzeichnung jedes KI-Werkzeugs sind bestimmt und dokumentiert.
• Klinische KI hat DTAC bestanden, wurde gegen das NICE Evidence Standards Framework geprüft und hat eine klinische Risikobewertung nach DCB und eine DPIA.
• Untergruppenleistung (Alter, Geschlecht, Ethnizität, Benachteiligung) wurde gesehen und erfüllt eine vereinbarte Fairness-Latte.
• Klinische Validierung passt zum Risikoniveau und bevorzugt prospektive, lokale Evidenz.
• Ein sinnvoller Human-in-the-Loop ist gestaltet, mit Befugnis und Information zum Übersteuern.
• Benannte Rechenschaft für von KI informierte Entscheidungen ist aufgeschrieben.
• Überwachung nach dem Inverkehrbringen, Drift-Schwellen und ein Pausier-/Rollback-Plan sind ab dem Go-live aktiv.
• MLOps gibt Modellversionierung und sicheres Rollback; die Live-Version ist immer bekannt.
• Die Richtlinie zu generativer KI erlaubt realistische Verwendungen, verbietet Patientendaten in ungemanagten Diensten und verlangt menschliche Verifizierung.
• Informationsgovernance deckt Trainings-, Feinabstimmungs- und Evaluationsdaten ab, mit vertraglichen Grenzen für die Wiederverwendung durch Lieferanten.
• Ein menschenlesbares Modellregister hält Zweck, Herkunft, Evidenz, Monitoring und Verantwortliche fest.
• Aufkommende Technologien werden per Horizon-Scanning beobachtet und durch kontrollierte, umkehrbare Evaluation stufenweise eingeführt.

Zentrale Quellen#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device und die regulatorische Sandbox AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) für digitale Gesundheitstechnologien (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) für die Basis-Assurance digitaler Gesundheitstechnologien.
• NHS England / ehemaliger NHSX — A Buyer's Guide to AI in Health and Care und die AI Ethics Initiative.
• DCB0129 und DCB0160 — Standards des klinischen Risikomanagements für Gesundheits-IT (siehe Thema 1.6).
• MHRA / IMDRF — Framework Software as a Medical Device (SaMD) und gute Praxis des maschinellen Lernens.
• The King's Fund und die Health Foundation — Analysen zu KI, Daten und Ungleichheiten in Gesundheit und Pflege.
• Siehe auch Thema 1.3 — Evidenzbasierte Entscheidungen; Thema 1.6 — Klinische Sicherheit und Risikomanagement; Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit; Thema 8.0 — Innovation phasenweise einführen.

Referenzen#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics