Es gibt keinen Stack von der Stange für regulierte KI
Der Markt möchte Ihnen einen Stack verkaufen. Anbieter wählen, dessen Modelle übernehmen, in dessen Region deployen, und Sie betreiben bis Quartalsende Agenten. Für viele Unternehmen ist das eine völlig gute Antwort.
Nur ist es in einem regulierten Unternehmen eine Falle, und der Grund ist nicht kommerziell. Welche Modelle Sie verwenden dürfen und wo sie physisch laufen dürfen, entscheidet Ihr Regulierungsregime und Ihre eigene Sicherheitsfreigabe, nicht die Voreinstellung eines Anbieters. Ein Stack von der Stange kodiert die Antwort eines anderen auf eine Frage, die nur Ihre Compliance-Funktion beantworten kann. Deshalb besteht er nie das Review.
Eine Bank unter DORA und Datenresidenzpflichten braucht ein grundlegend anderes Deployment als ein Krankenhaus, und beide brauchen etwas anderes als die Referenzarchitektur eines Anbieters. Der Stack ist kein Produkt, das man kauft. Er ist eine Menge Entscheidungen, die Ihnen gehören müssen.
Lock-in ist ein Konzentrationsrisiko, nicht nur ein kommerzielles
Sich auf einen einzigen Modellanbieter zu standardisieren fühlt sich wie kluge Vereinfachung an. Im regulierten Kontext erzeugt es still ein Risiko, für das sich Ihre Aufsicht aktiv interessiert.
Die Modellschicht ist der schnellste Teil des ganzen Stacks. Binden Sie Ihre Architektur an einen Anbieter, altert sie im Tempo dieses Anbieters, erbt dessen Ausfälle und hängt von dessen fortgesetzter Bereitschaft ab, Sie zu akzeptablen Bedingungen zu bedienen. In einem unregulierten Geschäft ist das ein kommerzielles Ärgernis. Unter einem Regime operationeller Resilienz ist die Abhängigkeit von einem einzigen unersetzbaren Dritten ein Konzentrationsrisiko, und nachzuweisen, dass Sie ihm nicht ausgesetzt sind, kommt einer Pflicht nahe.
Anbieterunabhängigkeit ist also kein Komfort, den Sie für Verhandlungsmacht hinzufügen. Sie ist ein Nachweis, den Ihre Compliance-Funktion erbringen können muss: so routen wir um jeden einzelnen Anbieter herum, und das ist der getestete Weg, den wir gingen, würde einer davon morgen unbrauchbar.
Das Modell-Gateway macht Anbieter austauschbar
Die Antwort auf Lock-in ist eine einzige interne Schnittstelle, die jeder Agent aufruft und hinter der die Modelle austauschbar sind. Anthropic, Mistral oder ein Open-Source-Modell auf Ihren eigenen GPUs sitzen alle hinter derselben Tür. Der Agent weiß nicht und kümmert sich nicht darum, wer geantwortet hat.
Drei Eigenschaften trennen ein echtes Gateway von einem dekorativen.
Ein dokumentiertes, getestetes Fallback. Ist ein Anbieter nicht verfügbar oder fällt bei einer Policy-Prüfung durch, routet das Gateway automatisch auf eine Alternative. Portabilität, die nicht getestet wurde, bevor Sie davon abhängen, ist ein Slogan, kein Control. Unter einem Resilienzregime kommt ein automatisches, getestetes Fallback einer Anforderung nahe.
Mindestens drei portable Optionen, dokumentiert vor Go-live. Nicht danach. Der Zeitpunkt, den Umzug zu beweisen, ist, solange Sie noch die Wahl haben, ihn nicht zu machen. Drei dokumentierte, austauschbare Optionen, bevor Sie von einer abhängen, machen aus "wir könnten wechseln" ein "wir haben gewechselt, hier ist das Runbook".
Routing nach Sensitivität, nicht nach Bequemlichkeit. Das Gateway entscheidet anhand der getragenen Daten, wo eine Last laufen darf, nicht anhand des heute günstigsten oder schnellsten Anbieters. Diese Entscheidung gehört in den nächsten Abschnitt, denn sie wird von Aufsichten am schärfsten geprüft.
Die Deployment-Topologie ist eine Datensouveränitätsentscheidung, geroutet pro Klasse
Hier irren die meisten Referenzarchitekturen: Sie wählen eine Topologie für alles. So überzwängt man entweder günstige, unsensible Arbeit oder lässt, weit schlimmer, regulierte Daten an einen Ort gelangen, an den sie nie gehört hätten.
Topologie ist keine Entscheidung. Sie ist eine Routing-Regel. Daten werden nach Sensitivität klassifiziert, und die Klassifizierung entscheidet die Topologie.
| Ihre Randbedingung | Topologie | Was Sie gewinnen | Was Sie in Kauf nehmen |
|---|---|---|---|
| Cloud erlaubt, unsensible Lasten | Cloud (eigenes Konto) | Elastizität, geringste Betriebslast | Daten verlassen Ihr Konto Richtung Modellregion, falls erlaubt |
| Regulierte Daten, Cloud erlaubt mit Residenzregeln | VPC, regionsgebunden | Daten bleiben in Ihrem Cloud-Perimeter und Ihrer Region | Sie betreiben Grenze und Routing |
| Regeln verbieten externe Verarbeitung | On-premises | Volle physische Kontrolle | Kapazitätsplanung und GPU-Betrieb gehören Ihnen |
| Höchste Sensitivität, Isolation vorgeschrieben | Air-gapped | Überhaupt kein Egress-Pfad | Modell-Updates und Betrieb sind manuell und bewusst |
Die Regel steht über der Tabelle: Klassifizieren Sie die Daten, dann sagt Ihnen die Tabelle, wo diese Klasse laufen darf. Ein einzelner Geschäftsprozess kann selbst sensible und unsensible Schritte enthalten, das Routing geschieht also pro Schritt, nicht einmal für das ganze System.
Die Haltung, die das verteidigbar macht, ist Souveränitäts-Routing, das geschlossen fehlschlägt. Regulierte und personenbezogene Daten bleiben standardmäßig in Ihrem Perimeter. Nur ausdrücklich unsensible Lasten dürfen ein Modell in einer externen Region erreichen, und nur, wenn Sie es erlaubt haben. Ist eine Klassifizierung unsicher, behandelt das System die Daten als sensibel und behält sie drinnen. Die Voreinstellung schützt Sie, und es braucht eine bewusste, protokollierte Entscheidung, sie zu lockern. "Ihre Daten verlassen nie Ihre Mauern" ist dann keine Marketingzeile. Es ist eine Architektur, in der Egress standardmäßig verweigert und nur per Policy erlaubt wird.
Den Stack zu besitzen heißt, den Ausstieg zu besitzen
Anbieterunabhängig und überall deploybar halten nur, wenn Sie es unter Druck beweisen können, und das heißt, der Ausstieg muss real sein, nicht rhetorisch.
Zwei Dinge verhindern, dass eine geerbte Plattform still zu dem Lock-in wird, den Sie vermeiden wollten. Beide gehören schriftlich in den Vertrag.
Escrow und ein getesteter Ausstieg. Quellcode und Gewichte im Escrow und ein dokumentierter, getesteter Ausstiegsplan. Ein nie geprobter Migrationspfad ist ein Wunsch, keine Garantie.
Das Asset gehört Ihnen. Die governte Laufzeit und die Agenten sind Ihre, um sie zu betreiben. Ihre Roadmap läuft weiter, wenn der Umsetzungspartner geht. Ein ernsthafter Partner hält sich daran, ein ersetzbarer Dritter nach den Regeln Ihrer Aufsicht zu sein, weil genau das diese Regeln von Ihren kritischen Lieferanten verlangen.
Es geht nicht darum, dass Sie jede Schicht selbst bauen müssen. Ein Modell-Gateway, eine Policy-Engine und ein Deployment-Gewebe von null zu bauen ist rund ein Jahr harte Installationsarbeit, das meiste davon in den Sicherheits- und Compliance-Details, die eine Aufsicht prüft. Es geht darum, dass die Entscheidungen Ihre bleiben, wer immer baut: welche Modelle, wo betrieben, wie verschoben. Das sind Compliance-Entscheidungen in Engineering-Kleidung.
Die Frage lautet also nicht "welchen Stack sollen wir übernehmen?". Sie lautet: würde unser primärer Modellanbieter morgen unbrauchbar, aus kommerziellem, regulatorischem oder Ausfallgrund, was ist der getestete Weg zum nächsten, und ist er vor Go-live dokumentiert? Können Sie das nicht pro Modell und pro Datenklasse beantworten, haben Sie noch keine Deployment-Entscheidung. Sie haben eine Deployment-Hoffnung.
Wenn Sie Ihre Datenklassen an einem echten Prozess auf erlaubte Topologien abbilden wollen, buchen Sie einen Termin.