Referenzarchitektur gegen Modell-Abhängigkeit

Die meisten Unternehmen haben heute kein KI-System. Sie haben eine direkte Leitung zu einem Anbieter. Fällt der weg, steht alles, was daran hängt.

Es geht anders. Wenn morgen Ihr wichtigstes Modell verschwindet, sollte niemand Ihren Anwendungscode anfassen müssen. So sieht die Architektur dafür aus, auf einer Seite.

Das Prinzip: eine Schicht zwischen Ihnen und dem Modell

Kein Prozess in Ihrem Haus spricht direkt mit der API eines Anbieters. Dazwischen sitzt eine Schicht, die entscheidet, routet und protokolliert. Genau diese Schicht macht Modelle zu austauschbaren Bauteilen.

Die Bausteine

1. Anwendungen und Agenten. Ihre Fachprozesse. Sie kennen kein Modell, nur das Gateway.

2. Das Gateway. Ein einziger Eingang. Es hält die Zugangsdaten, setzt Regeln durch und verteilt jede Anfrage. Fällt ein Modell weg, ändern Sie eine Regel, nicht Ihren Code.

3. Routing und Policies. Welche Anfrage geht an welches Modell, nach Aufgabe, nach Datensensibilität, nach Kosten. Vertrauliche Daten gehen an ein EU- oder lokales Modell, allgemeine Aufgaben an das stärkste verfügbare.

4. Der Modell-Pool. Mehrere Anbieter unterschiedlicher Herkunft mit klarer Fallback-Ordnung. Kein einzelnes Modell ist unersetzlich.

5. Open-Weight, selbst gehostet. Für geeignete Aufgaben und als Fallback, der nicht am Zugriff eines externen Anbieters hängt.

6. Der Workflow-Layer. Langlaufende Abläufe laufen in einer durable Engine, die den Zustand sichert und nach Ausfällen weiterläuft, statt von vorn zu beginnen.

7. Governance und Observability. Jede Anfrage wird protokolliert und auditierbar. Das ist die Ebene, auf der EU AI Act (Artikel 15, Robustheit) und ISO 42001 praktisch werden.

Was diese Architektur beantwortet

Sie ist die konkrete Antwort auf den 4-Fragen-Audit: das Modell wechseln (Gateway), in Stunden statt Wochen (Routing), ohne dass Governance bricht (Policies und Observability), und erprobt statt theoretisch (Fallback und Workflow-Layer). Auch McKinsey empfiehlt in „Rewired", die KI-Plattform so zu bauen, dass sich Modelle leicht austauschen lassen und Lock-in vermieden wird. (Quelle: McKinsey, Rewired.)

Kein Big-Bang

Sie müssen das nicht an einem Tag bauen. Der erste Schritt ist das Gateway, alles andere lässt sich dahinter ergänzen. Schon ein Gateway mit zwei Anbietern verändert Ihre Risikolage grundlegend: Aus „ein Ausfall legt uns lahm" wird „ein Ausfall kostet uns eine Umschaltung".

Kernaussagen dieses Beitrags

• Keine Anwendung spricht direkt mit einem Anbieter, alles läuft über ein Gateway.
• Routing nach Aufgabe, Datensensibilität und Kosten macht Modelle austauschbar.
• Open-Weight und ein Workflow-Layer schaffen eine Resilienzschicht, die nicht von einem einzelnen Anbieter abhängt.
• Governance und Observability machen Robustheit (EU AI Act Artikel 15) prüfbar.
• Der erste Schritt ist das Gateway, der Rest folgt.

Wie viele dieser Schichten haben Sie heute, und wo sprechen Ihre Anwendungen noch direkt mit einem einzelnen Anbieter?

Die Reihe im Überblick

• Teil 1: Über Nacht abgeschaltet. Wie ein abgeschaltetes Modell meinen Agenten stoppte und die Architektur ihn rettete.
• Teil 2: Die drei neuen Modell-Risiken. Verfügbarkeit, Nutzbarkeit, Datenhaltung als eigene Lieferketten-Ausfälle.
• Teil 3: Warum Verträge nicht reichen. Warum SLA und Auftragsverarbeitung gegen Hoheitsakte nicht schützen.
• Teil 4: Architektur-Souveränität ist real. Gateway, mehrere Anbieter, Fallbacks und der 4-Fragen-Audit.
• Teil 5: Was Europa daraus lernen sollte. Vom technischen Ausfall zur europäischen Souveränitätsdebatte.
• Teil 6: Überlebt Ihr Workflow den Modellwechsel?. Warum durable execution den laufenden Prozess vor dem nächsten Single Point of Failure schützt.

Klarheit. Verantwortung. Umsetzung.