Souveräne KI-Architektur: Anbieterwechsel planen, bevor er nötig wird

Eine souveräne KI-Architektur sorgt dafür, dass ein Sprachmodell, ein Cloud-Anbieter oder ein einzelner API-Vertrag nicht über die Handlungsfähigkeit Ihres Unternehmens entscheidet. Das ist für regulierte Branchen relevant, weil Modellabschaltungen, Preisänderungen und regionale Datenvorgaben nicht erst im Krisenfall sichtbar werden dürfen.

Die Vorstellung, ein KI-Anbieter lasse sich in vier Wochen austauschen, hält sich erstaunlich hartnäckig. Auf einer Folie stimmt sie sogar: API-URL ändern, neuen Schlüssel eintragen, fertig. Im Betrieb hängt an dieser URL aber weit mehr. Prompts sind auf ein Modell trainiert, Dokumente liegen im Dateispeicher des Anbieters, Fehlerfälle wurden für dessen Eigenheiten behandelt. Wenn dann ein Modell abgekündigt wird oder die Rechtsabteilung eine neue Datenresidenz verlangt, beginnt kein geplanter Wechsel. Es beginnt eine hektische Fehlersuche.

Eine souveräne KI-Architektur trennt Fachlogik und Modellanbieter

Der wichtigste Architekturentscheid ist banal und wird trotzdem oft übersprungen: Die Fachanwendung darf keine direkte Abhängigkeit von der API eines Modellanbieters haben. Zwischen Anwendung und Modell gehört eine eigene KI-Gateway-Schicht. Diese Schicht nimmt einen fachlichen Auftrag entgegen, wählt ein Modell aus, übersetzt das Anfrageformat und protokolliert das Ergebnis.

Ein Beispiel aus der Schadenbearbeitung: Die Fachanwendung fordert nicht „rufe Modell X mit dieser Funktion auf“, sondern „extrahiere Schadennummer, Vertragsnummer und fehlende Unterlagen aus diesem Dokument; liefere das Ergebnis als JSON nach Schema Y“. Ob dahinter ein kommerzielles API-Modell, ein europäisch gehostetes Modell oder ein internes Open-Weights-Modell läuft, bleibt außerhalb der Fachanwendung. Open Weights bedeutet: Die Modellgewichte sind verfügbar und können auf einer kontrollierten Infrastruktur betrieben werden. Das ist keine Garantie für Unabhängigkeit, aber eine belastbare zusätzliche Option.

Die KI-Gateway-Schicht darf kein aufgeblähter Plattformbau werden. Sie braucht eine überschaubare Aufgabe: ein einheitliches Auftragsformat, Adapter für zugelassene Modellanbieter, Authentifizierung, Limits und nachvollziehbare Protokolle. Wer dort schon sämtliche Geschäftsregeln versteckt, baut nur den nächsten schwer austauschbaren Monolithen.

Anbieterneutrale Prompts vermeiden versteckte Modellbindung

Prompts sind Code, auch wenn sie häufig in einem Ordner namens „Experimente“ landen. Ein Prompt, der über Monate auf das Antwortverhalten eines bestimmten Modells optimiert wurde, lässt sich nicht verlässlich kopieren. Das Nachfolgemodell interpretiert Rollen, Beispiele und Formatvorgaben anders. Gerade lange Systemprompts mit zehn Ausnahmen sind ein Warnsignal: Sie dokumentieren meist, dass die Fachlogik an der falschen Stelle gelandet ist.

Formulieren Sie Prompts deshalb als fachliche Aufträge mit klarer Ausgabe. Die Regel „Vertragsnummern ohne Leerzeichen zurückgeben“ gehört in ein maschinenlesbares Ausgabeschema und in eine Validierung, nicht als siebter Absatz eines Systemprompts. Die modellspezifische Feinabstimmung liegt im jeweiligen Adapter des KI-Gateways.

In der Praxis sieht das so aus: Ein Modell antwortet bei unklaren Belegen lieber mit einem plausibel klingenden Wert, ein anderes liefert ein leeres Feld. Beide Antworten können für eine Bank oder einen Logistiker problematisch sein. Die Anwendung muss daher nicht auf das Modell vertrauen, sondern Pflichtfelder prüfen und unklare Fälle an eine menschliche Prüfung geben. Diese Schutzlogik bleibt gleich, selbst wenn das Modell wechselt.

Ein Evaluations-Harness macht Modellwechsel messbar

Ohne eigene Evaluation ist ein Modellwechsel eine Glaubensfrage. Ein Evaluations-Harness ist ein automatisierter Testablauf, der reale, bereinigte Geschäftsfälle gegen festgelegte Erwartungen prüft. Er beantwortet nicht, welches Modell in einer Demo überzeugender klingt. Er zeigt, ob ein Modell Ihre konkrete Aufgabe innerhalb Ihrer Qualitäts- und Kostenlimits erledigt.

Nehmen wir eine KI-Anwendung, die Lieferantendokumente klassifiziert. Ein brauchbarer Testsatz enthält beispielsweise 200 repräsentative Dokumente: saubere Rechnungen, Scans mit schlechter Qualität, mehrsprachige Lieferscheine und Fälle, die bewusst keiner Kategorie zugeordnet werden dürfen. Für jeden Fall legen Sie die erwartete Kategorie, Pflichtfelder und zulässige Unsicherheit fest. Messen Sie zusätzlich Antwortzeit, Kosten pro Vorgang und die Quote der Fälle, die an einen Menschen eskalieren.

Diese Daten gehören versioniert in Ihr Repository, einschließlich Prompt-Version, Modellversion und Adapter-Konfiguration. Wenn sich die Trefferquote plötzlich verschlechtert, brauchen Sie einen Audit-Trail: Welcher Test lief wann gegen welches Modell mit welcher Konfiguration? Für regulierte Unternehmen ist das keine akademische Disziplin. Ohne diesen Nachweis lässt sich gegenüber Revision, Datenschutz und Fachbereich kaum erklären, warum eine Entscheidung der KI gestern anders ausfiel als heute.

Ein ehrlicher Punkt: Ein vollständiger Testsatz entsteht nicht an einem Nachmittag. Die Auswahl und fachliche Bewertung echter Fälle kostet Zeit. Diese Arbeit ist aber kein Zusatzprojekt, sondern der Preis dafür, Qualität künftig steuern zu können. Wer sie spart, bezahlt später mit manuellen Stichproben im laufenden Betrieb.

Datenflüsse und Zuständigkeiten entscheiden über echte Souveränität

Ein europäisches Rechenzentrum allein macht keine souveräne KI-Architektur. Entscheidend ist, welche Daten wohin fließen, wer sie lesen kann und ob sie für Training oder Supportzwecke verwendet werden dürfen. Bei personenbezogenen Daten, Konstruktionsplänen oder Kreditentscheidungen muss diese Kette technisch nachvollziehbar sein, nicht nur in einer Vertragsanlage stehen.

Klassifizieren Sie Daten vor der Modellanfrage. Ein interner Wissenschatbot darf beispielsweise Betriebsanweisungen abrufen, aber keine vollständigen Personalakten in einen externen Kontext laden. Für besonders schützenswerte Inhalte kann die Architektur eine lokale Verarbeitung oder eine isolierte europäische Instanz vorsehen. Weniger kritische Standardtexte dürfen unter klaren Regeln über einen externen Dienst laufen. Diese Differenzierung ist sinnvoller als das pauschale Verbot jeder externen KI, das Fachbereiche regelmäßig in Schatten-IT treibt.

Auch Retrieval-Augmented Generation, kurz RAG, braucht klare Grenzen. RAG ergänzt eine Modellanfrage um passende Inhalte aus einem eigenen Dokumentenbestand. Das Modell muss dabei nicht das gesamte Archiv sehen. Ein Berechtigungsfilter muss vor der Suche greifen, damit ein Mitarbeiter aus dem Einkauf nicht versehentlich Vertragsdokumente der Personalabteilung als Kontext erhält. Solche Fehler entstehen selten durch spektakuläre Angriffe. Häufig fehlt einfach eine saubere Verknüpfung zwischen Identität, Berechtigung und Dokumentenindex.

Proprietäre Komfortfunktionen nur mit bewusster Exit-Entscheidung nutzen

Proprietäre Funktionen sind nicht grundsätzlich falsch. Ein verwalteter Dokumentenspeicher oder ein anbieterspezifisches Agenten-Framework kann ein Projekt deutlich beschleunigen. Problematisch wird es, wenn die Entscheidung als technische Kleinigkeit durchrutscht und später zentrale Geschäftsprozesse davon abhängen.

Führen Sie deshalb für jede solche Funktion eine Exit-Notiz. Sie beantwortet vier Fragen: Welche Daten liegen dort? Welche Anwendung nutzt die Funktion? Welche offene oder selbst betriebene Alternative gibt es? Wie lange dauert die Ablösung realistisch? Eine Notiz von einer Seite reicht. Fehlt sie, wird die spätere Ablösung fast sicher teurer als erwartet.

Wir raten nicht dazu, jede Komponente selbst zu betreiben. Das wäre für viele Mittelständler wirtschaftlich unsinnig. Souveränität heißt Wahlfreiheit unter realen Bedingungen: Daten exportieren können, Schnittstellen austauschen können und die Qualität beim Wechsel nachweisen können. Ein Anbieter darf Teil der Architektur sein. Er darf nur nicht ihre unsichtbare Voraussetzung werden.

FAQ

Wie schnell ist ein KI-Anbieterwechsel bei einer souveränen KI-Architektur möglich?

Ein einfacher Modelltausch kann innerhalb weniger Tage erfolgen, wenn Adapter, Zugriffsrechte und Kapazitäten vorbereitet sind. Die fachliche Freigabe dauert länger, weil der Evaluations-Harness mit repräsentativen Fällen laufen muss. Für geschäftskritische KI-Anwendungen ist ein Wechsel in vier Wochen nur dann realistisch, wenn diese Vorbereitung bereits vor dem Anlass erfolgt ist.

Muss ein Unternehmen für digitale Souveränität alle Modelle selbst betreiben?

Nein. Der Eigenbetrieb großer Modelle verlangt GPU-Kapazität, Betriebserfahrung und laufende Sicherheitsarbeit. Für viele Aufgaben ist ein externer Dienst wirtschaftlicher. Eine souveräne KI-Architektur hält jedoch mindestens eine geprüfte Ausweichoption bereit und verhindert, dass proprietäre Datenspeicher oder Spezial-APIs den Wechsel blockieren.

Welche Unterlagen verlangt die Revision für KI-Anwendungen typischerweise?

Die konkrete Anforderung hängt von Branche und Risiko ab. In der Praxis brauchen Sie mindestens eine Beschreibung des Datenflusses, dokumentierte Berechtigungen, Modell- und Prompt-Versionen sowie Protokolle der fachlichen Evaluation. Bei automatisierten Entscheidungen kommen Freigaben, Eskalationswege und Aufbewahrungsfristen hinzu.

Was kostet der Aufbau einer anbieterunabhängigen KI-Infrastruktur?

Die Kosten hängen stärker an Integration und Testdaten als am KI-Gateway selbst. Eine isolierte Pilotanwendung lässt sich mit klarer Schnittstelle zügig aufsetzen. Teuer wird es, wenn mehrere Altsysteme unklare Datenhoheiten haben oder niemand fachlich verantworten kann, welche Antwort als korrekt gilt. Genau dort liegt meist die technische Schuld, nicht beim Modell.

Fazit

CTOs und IT-Architekten im Rhein-Main-Gebiet sollten für jede produktive KI-Anwendung jetzt einen Wechseltest ansetzen: zweites Modell anbinden, den eigenen Evaluations-Harness ausführen und Aufwand, Qualitätsabweichung sowie Datenrisiken dokumentieren. Wenn Ihr Team diesen Test nicht aus eigener Kraft planen kann, buchen Sie ein Gespräch, um die KI-Potenziale für Ihr Unternehmen zu besprechen und den tatsächlichen Lock-in vor dem nächsten Notfall sichtbar zu machen.