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. Für regulierte Branchen ist das relevant, weil Modellabschaltungen, Preisänderungen und neue Vorgaben zum Speicherort der Daten nicht erst im Krisenfall sichtbar werden dürfen.

Die Vorstellung, ein KI-Anbieter lasse sich in wenigen Wochen austauschen, hält sich erstaunlich hartnäckig. Auf dem Papier stimmt sie sogar: API-Adresse ändern, neuen Schlüssel eintragen, fertig. Im Betrieb hängt an dieser Adresse aber weit mehr. Prompts sind auf ein Modell eingeschliffen, Dokumente liegen im Dateispeicher des Anbieters, Fehlerfälle wurden für dessen Eigenheiten behandelt. Wird dann ein Modell abgekündigt oder verlangt die Rechtsabteilung eine neue Datenresidenz, 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. Sie 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 vielen 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 weiterer 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 darf deshalb nicht auf das Modell vertrauen. Sie prüft Pflichtfelder und gibt unklare Fälle an eine menschliche Prüfung. 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 einige hundert 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. Verschlechtert sich die Trefferquote plötzlich, 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. Was die Revision typischerweise sehen will, ist genau dieses Paket: Datenflussbeschreibung, dokumentierte Berechtigungen, Modell- und Prompt-Versionen, Protokolle der fachlichen Evaluation und bei automatisierten Entscheidungen zusätzlich Freigaben, Eskalationswege und Aufbewahrungsfristen.

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.

Wann Sie mit KI Daten in der EU verarbeiten müssen: Datenflüsse und Zuständigkeiten

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 und darf nicht allein in einer Vertragsanlage stehen.

Klassifizieren Sie Daten vor der Modellanfrage. Ein interner Wissenschatbot darf Betriebsanweisungen abrufen, aber keine vollständigen Personalakten in einen externen Kontext laden. Für besonders schützenswerte Inhalte sieht die Architektur eine lokale Verarbeitung oder eine isolierte europäische Instanz vor. 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 die 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 greift vor der Suche, 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 knappe Notiz reicht. Fehlt sie, wird die spätere Ablösung fast sicher teurer als erwartet.

Wir raten nicht dazu, jede Komponente selbst zu betreiben. Der Eigenbetrieb großer Modelle verlangt GPU-Kapazität, Betriebserfahrung und laufende Sicherheitsarbeit; für viele Mittelständler wäre das 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. Die Kosten dafür hängen weniger am KI-Gateway als an Integration und Testdaten. Teuer wird es, wenn mehrere Altsysteme unklare Datenhoheiten haben oder niemand fachlich verantworten kann, welche Antwort als korrekt gilt. Dort liegt meist die technische Schuld, nicht beim Modell.

Setzen Sie für jede produktive KI-Anwendung einen Wechseltest an: 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 einen Potenzial-Check: eine halbe Stunde, kostenlos, und Sie sehen, wo Ihre tatsächliche Anbieterbindung liegt, bevor der Notfall sie Ihnen zeigt.