Die fünf Kostenposten, die im Klinik-KI-TCO-Vergleich oft fehlen
Lizenz, Setup, Schulung — drei Spalten, in denen jede Klinik-KI-Ausschreibung die ersten zwölf Monate vergleicht. Die folgenden vier Jahre entscheiden sich an fünf Posten, die in Standard-Vorlagen selten erscheinen.

Dr. Sven Jungmann
CEO

Eine deutsche Klinik gibt rund 2,2 Prozent ihres Umsatzes für Informationstechnik (IT) aus — laut dem Krankenhaus-IT-Monitor 2024 von Roland Berger weiterhin deutlich unter dem Mittel der Organisation für wirtschaftliche Zusammenarbeit und Entwicklung (OECD) von etwa vier Prozent. Innerhalb der 2,2 Prozent entfällt der größte Block — rund 40 Prozent — auf Lizenzen und externe Dienstleister. Wenn auf dieser Grundlage eine Klinik-KI-Ausschreibung läuft, vergleicht die Vergabematrix in der Regel drei Spalten: Lizenz, Setup, Schulung. Über fünf Jahre entscheidet sich die tatsächliche Klinik-KI-Bilanz an fünf anderen Posten — und genau die fehlen in den meisten Standard-Vorlagen.
Die Frage nach der Total Cost of Ownership (TCO) ist in einer KI-Ausschreibung anders gelagert als bei einem klassischen Wechsel des Krankenhausinformationssystems (KIS). Bei einem KIS-Wechsel sind die Posten vergleichsweise stabil: einmalige Migration, Schulungsbedarf, jährliche Wartung. Eine klinische KI lebt dagegen vom kontinuierlichen Datenstrom — und ihre Wartungs- und Anpassungslast verteilt sich auf die gesamte Vertragslaufzeit, nicht auf das erste Quartal nach dem Go-Live. Engineering-Aufwand und Betriebs-Aufwand verteilen sich anders als bei einer klassischen Software-Anschaffung: Was am Tag der Inbetriebnahme funktioniert, ist nicht zwangsläufig auch am Tag eintausendachthundert noch in derselben Qualität funktionsfähig. Wer das in der Vergabematrix nicht ausdrücklich aufruft, vergleicht die ersten zwölf Monate. Die übrigen vier Jahre werden nach Vertragsschluss verhandelt, oder eben nicht.
Fünf Kostenposten, die selten in der Vergabematrix erscheinen
Der erste Posten ist der Schnittstellen-Aufbau. Eine klinische KI bezieht Eingangsdaten aus dem KIS, aus dem Diktat-Frontend, aus dem Befund-Archiv, aus dem Labor-System und aus externen Vorbefunden im Portable-Document-Format (PDF). Anders als bei einer einmaligen KIS-Migration verlangt eine KI-Anbindung, dass jede Datenquelle auch in der Inferenz-Phase live ansprechbar bleibt — die Anbindung ist Dauerzustand, nicht Migrationsereignis. Manche Anbieter:innen rechnen Schnittstellen pro Stück, manche pauschal, manche „nach Aufwand“. Die Frage, die den Posten in der Vergabematrix sichtbar macht: Was kostet jede zusätzliche Schnittstelle nach Vertragsschluss, und gilt der Preis auch für Quellen, die heute noch nicht im Lastenheft genannt sind?
Der zweite Posten ist die Modell-Wartung. Ein klinisches Modell verändert nicht die Welt um sich herum, aber die Welt um es herum verändert sich: neue Behandlungspfade, neue Codier-Versionen, neue Diktat-Vokabularien, schleichend abweichende Eingangsdatenmuster. Sculley und Kolleg:innen (NeurIPS, 2015) haben in einem oft zitierten Diagramm gezeigt, dass der Modell-Code in einem realen Lernsystem nur ein kleiner Teil ist; den weit größeren Anteil tragen Daten-Pipelines, Feature-Verifikation, Konfigurations-Management und Drift-Monitoring. Das Paper ist nicht aus einem klinischen Setting, sondern branchenneutral — die Mechanismen der Wartungs-Last sind dieselben. Übersetzt in eine Klinik-KI-Bilanz: Modell-Wartung ist kein einmaliger Posten, sondern eine laufende Last, deren Tagessätze in der Lizenz selten enthalten sind. Die sichtbar machende Frage: Wer verantwortet Drift-Monitoring und Modell-Updates über die fünf Jahre — Anbieter:innen im Festpreis, oder die Klinik im Stundensatz?

Der dritte Posten ist die Vendor-Lock-in-Wechselkosten-Frage. Klassische Software speichert Daten in Datei-Formaten, die mehr oder weniger portierbar sind. Eine klinische KI dagegen hinterlegt strukturierte Modell-Outputs (Befund-Aggregationen, Indikations-Vorschläge, Codier-Hinweise), die häufig in proprietären Schemata liegen — und die in der Klinik-Akte produktiv weitergenutzt werden. Wer in fünf Jahren auf eine Folgelösung wechselt, muss diese Outputs entweder migrieren, neu erzeugen oder verwerfen. Die Migrations-Last beim Ausgang kann die ursprünglichen Lizenzkosten der gesamten Vertragslaufzeit übersteigen, wenn das Format nicht portierbar dokumentiert ist. Vertraglich adressierbar wird der Posten über eine Datenexport-Garantie mit definiertem Format am Vertragsschluss. Die sichtbar machende Frage: In welchem Format liegen die Modell-Outputs, und welche Datenexport-Klausel gilt für den Wechsel im Jahr drei?
Der vierte Posten ist die Personal-Bindung an spezifische Tools. Klinik-Mitarbeitende, die mit einer bestimmten KI-Oberfläche zwei Jahre arbeiten, verlieren bei einem späteren Wechsel nicht nur das Werkzeug, sondern die produktive Routine. Die Switching-Cost auf der Nutzer:innen-Seite ist ein eigener Posten, den die Klinik trägt — nicht die Anbieter:innen. Eine grobe Schätzung: ein bis zwei Wochen reduzierte Produktivität pro betroffener Stelle, multipliziert mit der Anzahl betroffener Ärzt:innen, Therapeut:innen und Pflegekräfte. In einem Haus mit zweihundert Betten und entsprechend vielen klinischen Stellen wird daraus schnell ein sechsstelliger Posten — der in Standard-Vorlagen nicht auftaucht, weil er nicht beim Anbieter anfällt. Adoption ist erwünscht und kostbar; sie ist gleichzeitig der Mechanismus, der die Switching-Cost wachsen lässt. Wer Adoption fördert, baut implizit Bindung auf — die Frage in der Vergabe ist, ob die Bindung an die Oberfläche oder an die zugrunde liegenden klinischen Daten entsteht. Sichtbar machen lässt sich der Posten, indem die Vergabematrix die Schulungs- und Adoptions-Tiefe einer Lösung explizit als eigene Spalte führt — nicht als Unterpunkt der Schulungspauschale.
Der fünfte Posten ist der Anpassungsaufwand bei Workflow-Änderungen. Eine Klinik-KI lebt nicht in einem statischen Klinikprozess. Aufnahme-Routinen ändern sich, Codier-Vorgaben werden überarbeitet, Stationsorganisation verschiebt sich, neue Indikationen kommen hinzu. Implementation-Science-Forschung — etwa Damschroders Consolidated Framework for Implementation Research (CFIR, 2009) und Greenhalghs NASSS-Rahmen (2017) für Non-adoption, Abandonment, Scale-up, Spread, Sustainability — beschreibt die kontinuierliche Anpassung als eigene Domäne, die in Standard-TCO-Modellen kaum abgebildet wird. Beide Frameworks sind Synthese-Arbeiten aus über achtzig Fallstudien; sie liefern keine Punktschätzung, aber eine strukturelle Sicht. Konkret heißt das: eine neue ICD-Codier-Version, eine geänderte Klassifikation therapeutischer Leistungen (KTL), eine umorganisierte Aufnahme-Routine nach einer Stations-Fusion, ein zusätzlicher Indikations-Bereich nach einem Versorgungsauftrag — jede dieser Änderungen kann das Verhalten der KI an einer oder mehreren Stellen verschieben, weil das Modell auf Annahmen über die Eingangsdatenstruktur trainiert wurde. Übersetzt in den Vergabe-Kontext: Welche Klassen von Workflow-Änderungen sind im Standard-Vertrag enthalten — und welche werden nachgelagert berechnet?

Was Begleitung im Vertragsstandard verschiebt
Drei der fünf Posten — Schnittstellen-Aufbau, Modell-Wartung, Anpassungsaufwand bei Workflow-Änderungen — sind im Aiomics-Vertragsstandard direkt adressiert. Konkret: 15 bis 20 Personentage Top-Experten-Begleitung für die Integration plus bis zu 10 Personentage Implementierungs-, Prozessanalyse- und Change-Management-Support sind im Grundvertrag enthalten. Bei marktüblichen Tagessätzen von 2.500 Euro entspricht das einem Wert zwischen 60.000 und 75.000 Euro pro Implementierung — ohne separate Berechnung. Die Konstellation kehrt eine Branchen-Üblichkeit um: bei klassischen KIS-Anbietern ist Implementation oft das eigentliche Profit-Center; bei Cloud-First-Startups wird Integrationsarbeit der Klinik überlassen. Die Förderlogik des Krankenhauszukunftsgesetzes (KHZG) deckt die Anschaffungsphase über das Bundesamt für Soziale Sicherung (BAS) mit Förderquoten bis zu 70 Prozent ab. Die laufende Modell-Wartung über die Förderperiode hinaus tragen die Häuser selbst. Zwei der fünf Posten — Vendor-Lock-in-Wechselkosten und Personal-Bindung — sind durch keinen Vertragsstandard direkt zu adressieren; sie entstehen aus Architektur- und Datenformat-Entscheidungen, die einmal getroffen für die nächsten fünf Jahre stehen, sowie aus der Tiefe der Adoption im Haus. Sie lassen sich nur in dem einen Gespräch verhandeln, das vor der Unterschrift liegt — danach ist die Verhandlungsposition verschoben. Wer die fünf Posten in der Vergabematrix nicht sichtbar macht, verschiebt sie nicht — er verlagert sie nur aus der Vergabe-Spalte in den späteren Stundensatz.
Beim Pricing-Modell trennt sich ein zweiter Bruch, der über die Vertragslaufzeit wichtig wird. Eine zweikomponentige Struktur — Grundpreis für Software, Datenhaltung, Compliance, Wartung sowie unbegrenzte User-Accounts, plus eine flexible KI-Nutzungs-Komponente nach tatsächlichem Verbrauch — verschiebt das Risiko anders als ein Pro-User-Modell. Pro-User-Modelle erzeugen einen ständigen Konflikt zwischen Adoption und Kostenkontrolle, weil jede zusätzliche Person, die das Werkzeug bekommt, zusätzlich kostet. Über fünf Jahre summiert sich das doppelt: einmal in der Lizenzsumme, einmal in der Höhe der oben beschriebenen Switching-Cost im eigenen Haus — eine breit adoptierte Lösung ist klinikseitig teurer wieder zu verlassen als eine, die nur die ärztliche Spitze erreicht. Beide Modelle sind legitim. Auf einer einzelnen Lizenzkosten-Zeile sehen sie gleich aus; in der Fünfjahres-Bilanz tun sie es nicht.

Wer eine Vergabematrix sauber aufstellt, holt diese fünf Antworten parallel von drei Anbieter:innen ein und legt sie auf eine einzige Tabelle. Allein das Sammeln der Antworten dauert ein bis zwei Wochen — und es ist eine der wenigen Investitionen in die Vergabevorbereitung, die sich in der Fünfjahres-Bilanz fast immer auszahlt. Die Differenz zwischen den Anbieter:innen steckt häufig nicht im Lizenzpreis, sondern in der Verteilung der Risiken: welche Anbieter:innen die Schnittstellen-Pflege tragen, welche das Drift-Monitoring, welche den Migrations-Aufwand am Vertrags-Ausgang. Die ausführliche Vertiefung über alle Klinik-IT-Posten — auch jenseits der KI-spezifischen — steht im Pilot-Artikel „TCO für Klinik-KI: Was eine fünfjährige Rechnung wirklich zeigt“ als breitere Klinik-IT-Rechnung. Der vorliegende Beitrag schneidet die KI-spezifische Spitzung heraus. Eine Klinik-KI-Ausschreibung, die nur Lizenz, Setup und Schulung vergleicht, vergleicht das erste Jahr — und überlässt die teuren vier Jahre dem Zufall des Stundensatzes.
Die im Artikel genannten Aiomics-Vertragsfakten — etwa der Standard-Vertragsumfang von 15 bis 20 Personentagen Top-Experten-Begleitung plus bis zu 10 Personentagen Implementierungs- und Change-Management-Support — beschreiben unsere Vertragsstruktur. Sie sind keine empirisch gemessenen Kund:innen-Befunde und keine Aussage über die Total-Cost-of-Ownership-Bilanz einzelner Klinik-Häuser.


