Reguliert, vernetzt, ausgebremst: Was KI-Projekte in fünf Branchen blockiert

In regulierten Branchen scheitert KI 2026 selten an fehlender Technik. Die härteren Blocker liegen davor: Es fehlt eine gemeinsame Sprache zwischen Engineering und Compliance, ein verbindlicher Maßstab für „gut genug" und ein Mandat, das diese Fragen funktionsübergreifend entscheiden darf.

20 Praktiker aus fünf regulierten Branchen (Banking, Pharma, medizinische Produktentwicklung, IT-Provider für das Gesundheitswesen, kritische Infrastruktur) sprachen eine Stunde unter Chatham House Rule. Nicht für die Bühne, nicht für eine Aufzeichnung, nicht für Folien. Sondern über die Punkte, an denen ihre Programme tatsächlich hängen. Gerade diese Vertraulichkeit war entscheidend: Ohne sie wären viele Aussagen in der üblichen Konferenzsprache geblieben. So aber ging es nicht um kuratierte Erfolgsgeschichten, sondern um die operativen Engpässe hinter den Programmen.

Die Kernbeobachtung war eindeutig: Die Branchen unterscheiden sich im Regelwerk, aber nicht im Muster der Blockaden. Über alle fünf Themenfelder hinweg lag der dominante Blocker fast nie im Tooling selbst, sondern in einer Kombination aus drei organisatorischen Engpässen: fehlender gemeinsamer Sprache zwischen Engineering und Compliance, fehlendem verbindlichen Maßstab für „gut genug" und fehlendem Mandat, das funktionsübergreifend entscheiden darf.

Auf einen Blick

• Drei Engpässe dominierten branchenübergreifend: Sprache (Engineering und Compliance reden aneinander vorbei), Maßstab (niemand benennt verbindlich, was „gut genug" heißt) und Mandat (es fehlt eine Rolle, die zwischen den Funktionen verhandeln darf).
• Fünf Themenfelder kehrten in fast jeder Branche wieder: SBOM und Sub-Dependencies, Modell-Validierung, Open-Source-Wahrnehmung, Engineering-zu-QA-Kommunikation, KI-generierter Code im Review.
• Die ungelöste Frage, die niemand im Raum gelöst hatte: LLM-Validation in produktiven, lebensnahen Systemen unter regulatorischer Aufsicht.
• Die praktische Folge: Wer in einer Branche Sprache, Maßstab und Mandat löst, hat die Blaupause für die anderen vier fast schon mitgebaut.

Sprache: Engineering und Compliance reden aneinander vorbei

In nahezu jeder Schilderung tauchte derselbe Bruchpunkt auf: Engineering versteht das Vokabular von Compliance nicht, Compliance versteht das Vokabular von Engineering nicht, und niemand übersetzt. Das ist keine Soft-Skill-Frage, sondern eine geteilte Fachsprache, die in der Mehrzahl der Häuser nicht existiert. In der Folge werden Anforderungen aneinander vorbei formuliert, Akzeptanzkriterien bleiben vage, und beide Seiten erleben den jeweils anderen als Bremse statt als Partner.

Eine zweite Beobachtung dazu, ebenfalls aus der Runde: In fast keiner Tech-Konferenz gibt es einen Communication Track. Es gibt Tracks für Architektur, für ML, für Security, für Cloud, für DevOps. Aber nicht für die eine Disziplin, an der viele regulierte Programme im Alltag tatsächlich scheitern.

Was das in der Praxis heißt: Solange in einem regulierten KI-Programm keine geteilte Sprache zwischen Engineering und Compliance existiert, ist jede Architekturdebatte ein Stellvertreterkonflikt, und jede Verzögerung kostet mehr als das eigentliche Problem.

Maßstab: „Was wäre eigentlich gut genug?"

Eine Stimme aus der Runde brachte das auf eine Frage, die seither nicht mehr aus dem Kopf will: „Was wäre eigentlich gut genug?" In vielen Konzernen hat diese Frage kein klares Gegenüber. Wenn Compliance den Maßstab nicht operativ benennen kann und Engineering ihn nicht abfragen darf, wird jede Architekturentscheidung zur Verhandlung ohne Skala. Die Folge ist nicht ein zu hoher oder zu niedriger Standard, sondern Beliebigkeit: Was heute akzeptiert wird, ist morgen unzureichend, und niemand kann sagen, warum.

Das Problem liegt selten darin, dass niemand Qualität will. Das Problem liegt darin, dass Qualität nicht in entscheidbare Kriterien übersetzt wird. „Sicher", „robust", „auditierbar" oder „regelkonform" sind als Ziele richtig, aber für ein Entwicklungsteam nicht ausreichend. Ein Team braucht die Antwort auf die operative Frage: Woran erkennen wir, dass diese Lösung für diesen Kontext gut genug ist?

Was das in der Praxis heißt: Ohne ein operativ formuliertes „gut genug" (gemessen, geteilt, dokumentiert) kann auch der beste Stack nicht freigegeben werden. Der Engpass liegt vor dem Code, nicht in ihm.

Mandat: Wer darf verbindlich zwischen den Funktionen verhandeln?

Mehrfach genannt wurde im Raum derselbe Lösungsanker: Innovation Teams als institutionalisierter Brückenkopf in regulierten Konzernen. Sie sind weder reines Engineering noch reine Strategie. Entscheidend ist nicht ihr Name, sondern ihr Mandat: Sie dürfen zwischen Engineering, Compliance, QA, Security und Geschäftsleitung verbindlich übersetzen, verhandeln und eskalieren.

Wo solche Strukturen existieren, kommen neue Stacks durch konservative IT-Setups. Wo sie fehlen, bleibt Python im Sandkasten (nicht aus technischen, sondern aus organisatorischen Gründen). Dann kann jedes Team lokal gute Arbeit leisten und trotzdem am Übergang in produktive Verantwortung scheitern, weil niemand die Entscheidung über Funktionsgrenzen hinweg tragen darf.

Was das in der Praxis heißt: Eine mandatierte Brückenfunktion ist die Vorbedingung dafür, dass Sprache und Maßstab überhaupt verhandelt werden können. Ohne sie bleiben beide Engpässe strukturell unauflösbar.

SBOM und Sub-Dependencies: wer trägt die Lieferkette?

Eine SBOM (Software Bill of Materials) ist die Zutatenliste eines Softwareprodukts: jede Bibliothek, jedes Modul, jede Drittkomponente, die im fertigen System steckt. Sub-Dependencies sind die Zutaten dieser Zutaten: Software baut auf Software, oft fünf oder zehn Schichten tief. Wer in regulierten Branchen unterschreibt, dass ein System sicher und auditfähig ist, muss nicht nur wissen, was direkt eingebunden ist, sondern auch, was die eingebundenen Komponenten ihrerseits mitbringen. Eine Schwachstelle in der dritten Schicht ist keine Randnotiz, sondern Teil derselben Verantwortung.

Die Diskussion drehte sich nicht um die Tools (die existieren), sondern um Verantwortung und Lieferkette. Wer pflegt die SBOM? Wer eskaliert eine kritische Schwachstelle in einer Sub-Sub-Dependency? Wer trägt das Risiko, wenn ein Lieferant eine Komponente still aufgibt, eine Übernahme die Roadmap umwirft oder Lizenzbedingungen mitten im Lebenszyklus verschärft werden?

Was das in der Praxis heißt: Solange die SBOM-Pflege als Tooling-Frage behandelt wird statt als Verantwortungs- und Eskalations-Frage, ist jede Audit-Sicherheit nur formal, nicht operativ.

Open Source: die Pharma-Frage

Eine der eindrücklichsten Stellen der Diskussion kam aus dem Pharmaumfeld: die Wahrnehmung, kostenlos heiße, dass jemand für uns klaut. Es wäre verlockend, das als isolierte Anekdote abzutun. Es ist tatsächlich ein verbreitetes Bild. In regulierten Konzernen ist es folgenreich, weil es Open Source als Defizit framed, nicht als strukturellen Vorteil.

Zwei Punkte werden dabei systematisch übersehen. Erstens: Open-Source-Lizenzen wie MIT, Apache 2.0 oder BSD sind unwiderruflich. Eine Version, die heute unter dieser Lizenz steht, steht morgen unter dieser Lizenz. Kein Lieferant kann sie zurückziehen, keine Akquisition kann sie ändern, kein „strategischer Pivot" kann sie entwerten. Bei proprietären Komponenten ist genau das ein Standardrisiko. Zweitens: Open Source kann nicht im Preis steigen. Bei proprietären Stacks ist die nächste Lizenzrunde, die nächste Übernahme, die nächste „Neuausrichtung der Preisliste" fester Bestandteil der TCO-Realität. Bei offener Software gibt es diesen Hebel schlicht nicht.

Auditierbarkeit, Souveränität, Lieferanten-Unabhängigkeit, Total Cost of Ownership: Auf jeder dieser Achsen ist offene Software in regulierten Konzernen das tragfähigere Fundament, nicht die Sparvariante. Die längere Argumentation dazu trägt der Open-Stack-Beitrag dieser Serie, Stop Waiting, Start Shipping.

Was das in der Praxis heißt: Open Source ist 2026 für den überwiegenden Teil der Enterprise-Workloads die regulatorisch und ökonomisch erwachsenere Wahl. Wer dieses Bild in regulierten Branchen geradezieht, korrigiert eine Fehlannahme, die in Investitions- und Compliance-Entscheidungen reale Kosten erzeugt.

LLM-Validation: die ungelöste Frage

LLM-Validation meint im Kern: nachweisen, dass ein Sprachmodell in einem produktiven, regulierten Prozess verlässlich genug arbeitet, um die Verantwortung zu tragen, die jede andere kausale Software in diesem Kontext tragen muss. Klassische Validierung erwartet kausales Verhalten, deterministische Antworten, reproduzierbare Tests. Ein LLM liefert keines davon im strengen Sinn. Genau dort beginnt die Evaluation als operative Disziplin.

Bemerkenswert war eine Stille im Raum. Auf die Frage, ob jemand ein LLM als Kernkomponente eines produktiven Systems unter GxP- oder vergleichbarer Validierung betreibt, kam keine ernsthafte Bestätigung. Punktuelle LLM-Nutzung ja: Dokumentenextraktion, Vorklassifikation, Hilfsfunktionen. Als Kernkomponente eines lebensnahen oder finanzkritischen Prozesses, validiert nach dem Maßstab, der für jede andere kausale Software gelten würde: nein.

Das ist kein Versagen der Praktiker. Es ist die regulatorische Lücke. Die Übergangsfrage ist, ob bestehende Risikoframeworks aus der Pharma-Welt (Hit-Rate-Modelle, statistische Akzeptanz unter Aufsicht, kontinuierliche Post-Market-Surveillance) auf Software-Komponenten übertragen werden können. Dort gibt es Vorbilder. Auf die Software-Seite sind sie 2026 nicht systematisch übersetzt.

Was das in der Praxis heißt: Wer ein LLM in produktiver Verantwortung einsetzt, braucht eine Eval-Pipeline, die täglich misst, nicht zur Freigabe einmal greift. Die Verschiebung von Validierung als Phase zu Evaluation als Architektur ist die einzige Brücke, die im Moment trägt.

Für Entscheider

Erstens: Brückenfunktion mandatieren

Meine Empfehlung: Bauen Sie eine mandatierte Brückenfunktion auf, bevor das nächste KI-Programm beginnt: eine Innovationseinheit mit eigenem Mandat, eigenem Budget und direktem Zugang zur Geschäftsleitung. Geben Sie ihr drei explizite Rechte: Zielkonflikte eskalieren, Freigabekriterien dokumentieren, Entscheidungen bis zur Geschäftsleitung vorbereiten.

Zweitens: „Vielleicht" ist keine Antwort

Meine Empfehlung: Machen Sie „Was wäre gut genug?" zum Standardinstrument jeder Compliance-Eskalation, in zwei Stufen: welcher Maßstab gilt heute formal, und woran wäre er für dieses System operativ gemessen. „Vielleicht", „kommt darauf an" oder „prüfen wir noch" sind keine Antworten auf diese Frage; sie sind das Signal, dass die Anforderung nicht entscheidungsfähig ist.

Drittens: Übersetzung als Hiring- und Trainingsdisziplin

Meine Empfehlung: Behandeln Sie die Übersetzung zwischen technischer und regulatorischer Sprache als eigene Disziplin in Hiring und Entwicklung, nicht als Soft Skill, sondern als operative Voraussetzung für Lieferfähigkeit. Konkret: Stellenprofile, die Übersetzungskompetenz benennen; ein gemeinsames Glossar für die Begriffe, an denen Entscheidungen hängen; und in jedem größeren Programm eine benannte Person, die diese Übersetzung verantwortet.