Warum medizinische Software anderen Regeln folgt

„Move fast and break things“ ist als Motto schon in normaler Produktentwicklung fragwürdig. Im medizinischen Kontext ist es schlicht keine Option – selbst dann nicht, wenn die Software wie bei uns „nur“ in der Ausbildung eingesetzt wird und nie einen echten Patienten berührt. Drei Gründe, warum diese Domäne anders tickt, und was das konkret für die Entwicklung bedeutet.

1. Fehler haben hier eine zweite Wirkungsebene

In den meisten Produkten ist ein Fehler ein Ärgernis: falsche Anzeige, abgebrochener Vorgang, verlorene Zeit. In der medizinischen Ausbildung hat ein Fehler eine zweite, unsichtbare Wirkungsebene: Was Studierende in der Simulation lernen, nehmen sie mit ans Krankenbett.

Eine Simulation, die auf eine falsche Behandlungsentscheidung mit einer plausiblen, aber medizinisch falschen Reaktion antwortet, produziert keinen Bug-Report – sie produziert ein falsch gelerntes Muster. Das ist der Grund, warum „die KI halluziniert halt manchmal“ für uns kein akzeptabler Restfehler ist, sondern die zentrale technische Herausforderung. Generative Modelle dürfen bei uns Gesprächsverhalten erzeugen, aber keine medizinischen Fakten erfinden; die kommen aus geprüften, deterministischen Quellen.

Praktisch heißt das: mehr Aufwand in Validierung als in Features. Fachliche Reviews durch Mediziner:innen sind bei uns kein „nice to have“ am Ende, sondern Teil der Definition of Done.

2. Datenschutz ist Architektur, nicht Anhang

Wer im HealthTech-Umfeld baut, arbeitet früher oder später mit besonders geschützten Datenkategorien – und selbst wo keine echten Patientendaten fließen, sind die Erwartungen der Institutionen entsprechend: Universitäten und Kliniken fragen nicht, ob man DSGVO-konform ist, sondern lassen sich zeigen, wie.

Die wichtigste Lektion dabei: Datenschutz lässt sich nicht nachrüsten. Wo Daten verarbeitet werden, welche Anbieter im Spiel sind, was protokolliert wird, wie lange etwas gespeichert bleibt – das sind Architekturentscheidungen. Wer sie am Anfang bewusst trifft (Datensparsamkeit als Default, EU-Hosting wo möglich, klare Auftragsverarbeitungsketten), beantwortet später Fragebögen. Wer sie schleifen lässt, baut später um.

3. Regulatorik belohnt Nachvollziehbarkeit

Der dritte Unterschied ist kultureller Natur. Klassische Produktentwicklung optimiert auf Geschwindigkeit der Iteration; regulierte Umgebungen optimieren auf Nachvollziehbarkeit: Warum verhält sich das System so? Wer hat das wann entschieden? Lässt sich das reproduzieren?

Das klingt nach Bürokratie, ist aber – richtig umgesetzt – einfach gutes Engineering: versionierte Inhalte, reproduzierbare Builds, protokollierte Modell- und Prompt-Änderungen, Tests, die medizinische Kernaussagen absichern. Gerade bei KI-Komponenten zahlt sich das doppelt aus. „Das Modell war gestern noch anders drauf“ ist keine Antwort, die man einer medizinischen Fakultät geben möchte.

Langsam ist schnell

Zusammengenommen führen diese drei Punkte zu einer Arbeitsweise, die von außen konservativ wirken kann: weniger experimentelle Abhängigkeiten, deterministische Kerne statt End-to-End-Magie, mehr Zeit für Validierung. Meine Erfahrung ist: Diese vermeintliche Langsamkeit ist eine Investition mit sehr realer Rendite. Vertrauen ist im medizinischen Umfeld die eigentliche Währung – und Vertrauen entsteht nicht durch das Feature, das eine Woche früher fertig war, sondern durch das System, das sich auch im zwanzigsten Durchlauf exakt so verhält, wie es soll.