KI im Labor: Build, Buy oder Partner

KI in der Labormedizin wird in Laboren bereits auf sehr unterschiedliche Weise umgesetzt. Fragt man in einer Runde von Laborleitungen und IT-Verantwortlichen, wie sie KI heute einsetzen, fallen die Antworten erstaunlich unterschiedlich aus. Die einen haben in der Labor-IT eigene Skripte, Regelwerke und Auswertungen aufgebaut. Andere haben ein KI-Modul ihres LIS-Herstellers, einen Office-Copilot oder eine Transkriptionslösung eingekauft. Wieder andere entwickeln gemeinsam mit einem Partner. Und eine vierte Gruppe sagt offen: noch gar nicht – oder nur inoffiziell.

Diese vierte Antwort ist die aufschlussreichste. Denn „noch gar nicht“ bedeutet in den seltensten Fällen, dass im Haus keine KI genutzt wird. Es bedeutet meist, dass niemand entschieden hat, wie sie genutzt werden soll. Genau darum geht es in diesem Beitrag: um die Frage, die jedes Labor früher oder später beantworten muss – Build, Buy oder Partner?

Die Ausgangslage ist branchenübergreifend ernüchternd. Laut einer MIT-Studie („The GenAI Divide“, 2025) zeigen rund 95 Prozent der GenAI-Pilotprojekte in Unternehmen keine messbaren Auswirkungen auf die Ergebnisse. Im Januar 2026 hob Gartner seine Prognose für eingestellte GenAI-Projekte deutlich an: Mindestens die Hälfte wird nach dem Proof-of-Concept eingestellt.

Aufschlussreich sind die Ursachen, die Gartner dafür nennt: fehlender Business Value, Daten, die nicht bereit sind, unterschätzte Gesamtkosten, Responsible AI als Nachgedanke und schwaches Change Management. Keine dieser Ursachen ist ein Technologieproblem. Alle sind Fragen der Umsetzung – und damit genau die Fragen, die hinter der Entscheidung zwischen Build, Buy und Partner stehen.

Build bedeutet Eigenentwicklung – durch die Labor-IT, ein universitäres Institut oder beauftragte Entwickler. Die Stärken liegen auf der Hand: maximale Passung, Datenhoheit, Know-how im eigenen Haus. Die Risiken werden dagegen oft unterschätzt: Talente und Betrieb müssen dauerhaft gesichert werden, aus einzelnen Projekten werden schnell Skriptsammlungen ohne Lebenszyklus – und wer Software mit diagnostischer Zweckbestimmung selbst entwickelt, wird regulatorisch zum Hersteller.

Buy bedeutet, ein fertiges Produkt oder eine SaaS-Lösung einzukaufen. Das verspricht eine schnelle Time-to-Value, planbare Kosten und einen Anbieter, der Zertifizierung und Weiterentwicklung trägt. Der Preis dafür sind begrenzte Anpassbarkeit, mögliche Abhängigkeiten über proprietäre Formate und Schnittstellengebühren sowie offene Fragen zu Datenabfluss und Verarbeitungsort.

Partner bedeutet gemeinsame Entwicklung auf einer bestehenden Plattform – etwa als Co-Innovation, als gemanagtes Open-Source-Projekt oder als Pilot mit klarer Zielvereinbarung. Hier trifft das Domänenwissen des Labors auf die Technologie und regulatorische Erfahrung des Partners. Wichtig ist: Partnerschaft ist kein Euphemismus für Einkauf. Der Unterschied liegt in geteilter Verantwortung, einer gemeinsamen Roadmap und echter Risikoteilung. Dafür braucht es klare Governance – und eine Exit-Strategie.

In der Praxis sind die meisten erfolgreichen Umsetzungen Mischformen. Die eigentliche Frage lautet daher nicht „Welcher Weg?“, sondern „Welcher Weg für welchen Teil?“

Ein hilfreiches mentales Modell ordnet jeden Anwendungsfall entlang zweier Achsen: Wie stark differenziert die Fähigkeit das eigene Labor – und wie nahe liegt sie an der medizinischen Entscheidung und damit an MDR / IVDR und dem AI Act?

• Geringe Differenzierung, geringe Kritikalität: Transkription, Telefon-KI, Übersetzung, Office-Copilot. Austauschbar und schnell verfügbar – hier lohnt der Einkauf von Standardlösungen.

• Hohe Differenzierung, geringe Kritikalität: Einsender- und Portfoliosteuerung, eigene Regeln, Dashboards, Analytics. Hier lohnt es sich, selbst zu gestalten – idealerweise auf den Schnittstellen einer stabilen Plattform, mit Tests und Dokumentation.

• Geringe Differenzierung, hohe Kritikalität: zertifizierte Entscheidungsunterstützung, Validierungshilfen, Befundtexte als Medizinprodukt. Hier trägt idealerweise der Anbieter die Zertifizierung, das Labor konfiguriert lokal.

• Hohe Differenzierung, hohe Kritikalität: Hier können Labore am meisten gewinnen – und am meisten verlieren. Eine gemeinsame Innovation mit einem Partner, der die regulatorische Last trägt, ist in der Regel der realistischste Weg. Eine eigenständige Entwicklung erfordert spezielle Fachkenntnisse in den Bereichen Qualitätsmanagement und MDR.

Oder zugespitzt: Wer Commodity selbst baut, investiert in das Falsche. Wer Differenzierung nur einkauft, gibt sie aus der Hand.

Ein zweites Modell stammt von McKinsey und unterscheidet Taker, Shaper und Maker. Taker nutzen KI-Produkte, wie sie sind. Maker trainieren und betreiben eigene Modelle – mit maximaler Differenzierung, aber auch maximaler Verantwortung, Infrastruktur und Validierungsaufwand. Dazwischen liegen die Shaper: Sie bringen ihre eigene Fachlogik – SOPs, Regelwerke, Referenzbereiche, Einsenderlogik, eigene Wissensbestände – in eine bestehende Plattform ein, ohne ein eigenes Modell zu trainieren. Für die meisten Labore ist das der Sweet Spot: Taker bei Commodity, Shaper bei der eigenen Fachlogik, Maker nur mit Forschungsauftrag und eigenem Regulatorik-Setup. Dazu passt ein aktueller Trend: Unternehmen kaufen wieder häufiger fertige Anwendungen, nutzen aber parallel mehrere Modelle. Modelle werden austauschbar – die Fachlogik nicht.

Übersetzt in eine Architektur ergibt sich ein Schalenmodell mit drei Ebenen:

1. Ein stabiler Kern – ob erworben oder gemeinsam mit einem Partner betrieben: Kernlaborprozesse, zertifizierte Entscheidungshilfen und ein harmonisiertes Datenmodell auf der Grundlage von Standards wie LOINC und FHIR. Mit direktem Zugriff auf die eigenen Daten und ohne Gebühren für die Nutzung der Schnittstellen.

2. Eine geteilte Schicht für alles, was nicht differenziert – Gerätetreiber, Middleware, Parser, Mappings. Diese Komponenten gemeinsam als Open Source zu entwickeln, schafft Transparenz statt Blackbox und verhindert Lock-in. Betreiben kann man sie selbst – oder als Service einkaufen.

3. Flexible Erweiterungen für die eigene Differenzierung – Regelwerke, Workflows, Dashboards über offene APIs. Entscheidend ist, dass sie als echte Software entstehen: mit Lebenszyklus, Tests und Dokumentation, egal ob Labor, Partner oder Anbieter sie umsetzen.

Ebenso wichtig ist ein fließender Übergang zwischen Konfiguration und Code. Viele Labore stecken heute zwischen klassischer LIS-Parametrierung und einer inoffiziellen Ebene aus Excel-Makros und Skripten fest. Was fehlt, ist die Ebene dazwischen: Individualisierung durch Power-User und Medizininformatik – Regelwerke, Reflextestungen, Workflows –, abgesichert durch Simulation und automatisierte Tests, bevor eine Änderung produktiv geht.

KI verändert die Rechnung auch auf der Build-Seite. Mit KI-gestützter Programmierung, oft als „Vibe Coding“ bezeichnet, werden kleine, spezielle Use Cases plötzlich baubar. Eigenentwicklung wird damit verlockender. Doch die Kosten verschwinden nicht, sie verschieben sich: von der Entwicklung in Betrieb, Wartung und Verantwortung. Ein Workaround ohne Tests und Dokumentation bleibt ein Risiko – auch wenn er heute in Minuten generiert ist.

Nachhaltige Erweiterungen brauchen deshalb fünf Fundamente: saubere APIs und Erweiterungspunkte, stabile Kernprozesse, klare Governance und Ownership, Dokumentation als Voraussetzung für Wartbarkeit und Auditierbarkeit – und eine gute Prozessanalyse, die echte Differenzierung von unnötiger Komplexität unterscheidet. Der vielleicht wertvollste Einsatz von KI in der Entwicklung ist ohnehin ein anderer: als Denkpartner für Prozessvarianten, gemeinsam mit den Menschen, die die Arbeit kennen.

Hinzu kommen die gesetzlichen Vorschriften. Wer intern Software mit diagnostischem Verwendungszweck entwickelt, übernimmt die Pflichten eines Herstellers: ein Qualitätsmanagementsystem, technische Dokumentation, klinische Bewertung und Vigilanz. Die Ausnahmeregelung für die Eigenentwicklung im Rahmen der MDR unterliegt strengen Auflagen und ist kein Freifahrtschein. Die Käufer bleiben Betreiber – mit eigenen Verpflichtungen hinsichtlich Verwendungszweck, Schulung, Datenschutz-Folgenabschätzung und NIS2-Risikomanagement. Eine Partnerschaft erfordert eine klare Verantwortungsmatrix: Wer zertifiziert, wer validiert vor Ort, wer berichtet, wer haftet? Das KI-Gesetz räumt eine Frist ein, jedoch nicht auf unbestimmte Zeit: Transparenzpflichten gelten bereits, und die Verpflichtungen für KI in Medizinprodukten mit hohem Risiko treten – nach derzeitigem Stand – ab August 2028 in Kraft.

Zurück zur vierten Antwort vom Anfang. Laut MIT nutzen Mitarbeiter in mehr als 90 Prozent der Unternehmen private KI-Tools für ihre Arbeit – während nur etwa 40 Prozent über offizielle Lizenzen verfügen. Der „Cost of a Data Breach Report 2025“ von IBM beziffert die zusätzlichen Kosten einer Datenpanne im Zusammenhang mit „Shadow-KI“ auf etwa USD 670.000 USD; 63 Prozent der Unternehmen verfügen noch nicht über eine KI-Governance-Richtlinie.

Im Labor bedeutet das: Befundtexte, Arztbriefe oder Patientendaten landen in Consumer-Tools, wenn es kein freigegebenes Angebot gibt. Ein früher, sicherer Einkauf oder eine Partnerschaft ist deshalb oft die wirksamste Governance-Maßnahme. Security und Privacy sind Auswahlkriterium Nummer eins – nicht Bremse.

Die Risiken selbst gelten für alle drei Wege: Prompt Injection über eingelesene Dokumente und Befunde, Patientendaten in Prompts und Logs, die Nutzung eigener Daten zum Training fremder Modelle, Datenabfluss an Anbieter außerhalb der EU, Abhängigkeiten durch proprietäre Formate, unklare Verantwortlichkeiten und Blackbox-Ergebnisse, die weder Ärzt:innen noch Auditoren nachvollziehen können. Der Unterschied liegt darin, wer die Kontrolle nachweist: bei Build das Labor selbst, bei Buy der Anbieter – über Verträge, Zertifikate und Auditrechte –, bei Partner die gemeinsam vereinbarte Verantwortungsmatrix.

Auch beim Betriebsmodell lautet die Frage nicht „Cloud ja oder nein“, sondern: Welche Daten dürfen wohin? On-Premise bietet volle Kontrolle, verlangt aber GPU-Infrastruktur und Betriebs-Know-how. Reine Cloud-Lösungen sind schnell, erfordern aber einen genauen Blick auf Verarbeitungsort, Subprozessoren und die Kostenentwicklung über fünf Jahre. Für viele Häuser ist ein hybrider Ansatz der pragmatische Weg: Kernlogik und Patientendaten bleiben im Haus, nur anonymisierte Textaufgaben gehen an ein Sprachmodell in Deutschland oder der EU.

Ein Blick über das Labor hinaus macht die Muster sichtbar. Klarna ersetzte 2024 große Teile seines Kundenservice durch KI – und kehrte 2025 zu einem hybriden Modell zurück, weil Kosten, so der CEO, ein zu dominanter Bewertungsfaktor gewesen seien. Die Lehre: Erfolgsmetrik ist Qualität, nicht nur Kosten und Geschwindigkeit. IBM Watson Health wurde nach Milliardeninvestitionen verkauft – unter anderem, weil Daten- und Workflow-Passung fehlten. Domänenwissen lässt sich nicht einfach zukaufen.

Im Gesundheitswesen zeigt sich, dass Build und Partner kein Widerspruch sind. Die Mayo Clinic entwickelt gemeinsam mit Microsoft ein eigenes Modell aus de-identifizierten Daten – und behält das Eigentum daran. Am Universitätsklinikum Freiburg waren über 93 Prozent der mit einem nicht-kommerziellen Sprachmodell erstellten Arztbriefe mit minimalen Anpassungen nutzbar: Differenzierung durch lokale Anpassung eines offenen Modells, ganz ohne eigenes Modelltraining. Und große universitäre KI-Institute berichten offen, dass viel geforscht werde, aber zu wenig in der Versorgung ankomme – der Transfer scheitert oft an Regulatorik und Betrieb.

Auch Laborprojekte lassen Muster erkennen. Als eine weit verbreitete Integrations-Engine im Jahr 2025 von Open Source auf ein proprietäres Lizenzmodell umgestellt wurde, standen viele Labore plötzlich vor einer strategischen Entscheidung – und erlebten, wie schnell Abhängigkeiten teuer werden können. Offene, laborspezifische Middleware stellt hier eine Art vierten Weg dar: Die Ausstiegsmöglichkeit bleibt erhalten, während Betriebsleistungen weiterhin eingekauft werden können. Das Gleiche gilt für die LIS-Modernisierung: Anstelle eines riskanten „Big Bang“ lassen sich Module für die Auftragserfassung, Validierung oder Analytik über FHIR und LOINC an den bestehenden Kern anschließen. Und Vertragsmodelle, die Zahlungen an gemeinsam definierte Ziele knüpfen, machen aus einem Lieferanten einen Partner – denn beide Seiten arbeiten auf messbare Ergebnisse hin.

Verdichtet man diese Erfahrungen, zeichnen sich klare Muster ab. Es scheitern Proofs of Concept ohne Betriebs- und Finanzierungskonzept, Kosten oder Geschwindigkeit als einzige Erfolgsmetrik, Skriptsammlungen ohne Ownership, Lock-in durch proprietäre Middleware und Schnittstellengebühren sowie Blackbox-Ergebnisse, denen niemand vertraut. Und es scheitert KI, die vor der Datenbasis kommt: Wer nicht beantworten kann, welche Daten vorhanden sind, woher sie stammen und was sie bedeuten, wird auch mit dem besten Modell wenig erreichen – ein Thema, das wir im Beitrag zur intelligenten Metadaten-Verwaltung ausführlicher beleuchtet haben.

Was hingegen funktioniert: klein anfangen, mit klaren Vorteilen und messbaren Zielen. Die Wahl der richtigen Ebene – Standardkomponenten kaufen, die Domänenlogik gestalten, den Kern stabil halten. Die Zuständigkeit für jede Erweiterung festlegen. Offene Standards wie FHIR, LOINC und SNOMED CT sowie Datenportabilität vom ersten Tag an. Den Menschen im Prozess einbeziehen. Und eine Ausstiegsstrategie vertraglich verankern – die beste Absicherung gegen eine Bindung an einen Anbieter.

1. Auf welcher Ebene ist der Anwendungsfall angesiedelt – auf der Ebene des Werkzeugs, des Prozesses oder des Medizinprodukts?

2. Ist die Fähigkeit für uns Commodity oder Differenzierung?

3. Wer trägt die regulatorische Verantwortung – der Hersteller oder der Betreiber?

4. Welche Datenkategorie verarbeiten wir – und wo darf diese verarbeitet werden?

5. Sind unsere Daten strukturiert und beschrieben – mit LOINC, FHIR und Metadaten?

6. Wie hoch sind die Gesamtkosten über einen Zeitraum von fünf Jahren – Betrieb, Wertmarken, Personal, Zertifizierung?

7. Wer ist für den Lebenszyklus, die Tests, die Dokumentation und die Aktualisierungen der Erweiterung verantwortlich?

8. Woran messen wir Erfolg – an Qualität, Zeit, Kosten oder Akzeptanz?

9. Wie kommen wir da wieder heraus – Datenportabilität, offene Schnittstellen, Open Source?

10. Was passiert, wenn wir nichts tun?

Je mehr Antworten in Richtung „hohe Differenzierung, hohe Kritikalität, begrenzte eigene Kapazität“ zeigen, desto eher lohnt sich der Partner-Weg.

Build, Buy oder Partner ist keine Entweder-oder-Entscheidung. Die Ebene bestimmt die Antwort: Werkzeuge kauft man, Prozesse gestaltet man – allein oder mit einem Partner –, und bei Medizinprodukten kauft man zertifiziert ein oder entwickelt gemeinsam mit jemandem, der die regulatorische Verantwortung tragen kann. Security und Privacy sind dabei kein Hindernis, sondern das wichtigste Auswahlkriterium. Und schneller bauen heißt nicht besser bauen: Auch im Zeitalter KI-gestützter Entwicklung brauchen Erweiterungen Schnittstellen, Ownership, Tests und Dokumentation.

Die teuerste Option ist am Ende nicht die falsche Entscheidung zwischen Build, Buy und Partner – sondern gar keine Entscheidung. Wir freuen uns über den Austausch mit allen, die diese Fragen gerade für ihr Labor oder ihre Klinik bewegen – über gelungene Ansätze ebenso wie über Projekte, aus denen man lernen konnte.