KI-Readiness für Bestandssysteme: Systeme für den Modellwechsel bauen

Ein Bestandssystem ist KI-bereit, wenn es das KI-Modell oder den Anbieter wechseln kann, ohne dass Geschäftsbetrieb, Datenhoheit oder Ergebnisqualität daran hängen. In der Praxis scheitert der angeblich schnelle Anbieterwechsel meist an gewachsenen Prompts, herstellereigenen Schnittstellenfunktionen und fehlenden Qualitätstests.

Der schnelle Anbieterwechsel ist meist eine Illusion

Viele Entscheider trauen ihrer Organisation zu, einen KI-Anbieter in wenigen Wochen auszutauschen. Diese Einschätzung hält selten stand, sobald jemand den Ablauf aufschreibt: Welche Anwendungen rufen das Modell auf? Wo liegen die Prompts? Welche Dokumente werden hochgeladen? Wer prüft, ob die Antworten nach dem Wechsel fachlich noch brauchbar sind?

Ein typisches Bild aus dem Mittelstand: Ein Serviceteam nutzt einen KI-Assistenten, um E-Mails zu klassifizieren und Antwortentwürfe zu schreiben. Anfangs wird die Schnittstelle direkt aus dem CRM angesprochen. Ein halbes Jahr später gibt es Dutzende Prompts, Sonderbehandlungen für bestimmte Kunden, eine herstellereigene Funktion für den Dateiupload und eine Handvoll Fehlercodes, die im Code abgefangen werden. Der Anbieterwechsel ist dann kein Konfigurationseintrag. Er ist ein Umbauprojekt, dessen Umfang niemand geschätzt hat.

Das Problem ist nicht, dass ein Anbieter Funktionen anbietet. Problematisch wird es, wenn diese Funktionen unbemerkt Teil der Geschäftslogik werden. Dann besitzt das Unternehmen den Vertrag, aber nicht mehr die technische Handlungsfreiheit.

Die Bestandsaufnahme findet die Abhängigkeiten

KI-Bereitschaft lässt sich nicht durch einen neuen Chatbot herstellen. Der erste Schritt ist ein Architektur-Inventar, das zeigt, wo Abhängigkeiten bereits bestehen und welche davon geschäftskritisch sind.

Suchen Sie nicht zuerst nach Servern, sondern nach den Stellen, an denen Entscheidungen vorbereitet oder automatisiert werden: die Angebotsprüfung im Vertrieb, die Schadensbewertung im Versicherungsumfeld, die Dokumentenextraktion in der Logistik. Erfassen Sie je Anwendungsfall den Datenfluss. Welche Daten gehen an das Modell, in welchem Land werden sie verarbeitet, welches Ergebnis kommt zurück, und welche Anwendung verarbeitet es weiter?

Danach folgt die unangenehme Frage: Was passiert bei einer falschen Antwort? Ein falsch formulierter Entwurf für eine interne E-Mail ist ärgerlich. Eine falsch extrahierte Kontonummer in einem Zahlungsprozess ist ein Kontrollversagen. Diese Unterschiede müssen in der Architektur stehen und nicht allein in der Vorlage für den Lenkungskreis.

Einen weiteren blinden Fleck sehen wir bei fast jeder Modernisierung: Zugangsdaten und Modellnamen sind über Anwendungen, Skripte und Auslieferungspipelines verteilt. Wenn ein Modellname an einem Dutzend Stellen hinterlegt ist, wird jeder Wechsel unnötig riskant. Ein belastbares Inventar findet solche Stellen vor dem ersten Umbau.

KI-Insellösungen zusammenführen: Plattform oder schlanker Adapter?

Eine eigene KI-Schnittstelle, ein Gateway zwischen Ihren Anwendungen und den Schnittstellen der Anbieter, ist der wirksamste technische Hebel gegen Abhängigkeit. Die Fachanwendung fordert dort beispielsweise eine strukturierte Vertragszusammenfassung an; sie kennt weder die Eigenheiten eines konkreten Modells noch dessen Antwortformat.

Diese Trennung klingt banal und wird aus Zeitdruck trotzdem übersprungen. Genau dann entstehen direkte Aufrufe in Java, .NET, Python oder im Frontend. Jede einzelne Integration wirkt klein. Zusammen machen sie den späteren Wechsel teuer.

Ein brauchbares Gateway übernimmt mindestens die Auswahl des Modells, die Authentifizierung, die Protokollierung und die Übersetzung von Ein- und Ausgabeformaten. Es speichert außerdem, welche Modellversion für welchen Vorgang eingesetzt wurde. Wenn ein Kunde oder ein Auditor Monate später fragt, wie eine Entscheidung zustande kam, reicht „Das Modell hat das so geliefert“ nicht aus.

Wichtig ist die Grenze: Ein Gateway darf nicht zur zweiten, unwartbaren Plattform werden. Für einen einzelnen, risikoarmen Assistenten ist ein schlanker Adapter oft genug. Wer sofort eine universelle KI-Fabrik baut, verschiebt Nutzen und Kosten in eine ungewisse Zukunft. Es geht um die kleinste Struktur, die einen späteren Wechsel realistisch macht, nicht um möglichst viel Architektur.

Prompts und Daten brauchen eine klare Eigentumsordnung

Prompts sind Unternehmenswissen, sobald sie Abläufe, Fachbegriffe und Entscheidungsregeln abbilden. Trotzdem liegen sie häufig als Textbausteine in Quellcodedateien oder direkt im Portal eines Anbieters. Das ist bequem, bis ein Modell ersetzt, ein Dienstleister gewechselt oder ein Audit verlangt wird.

Legen Sie Prompts versioniert in Ihrem eigenen Code-Repository ab und trennen Sie den fachlichen Auftrag von der modellspezifischen Formulierung. Der fachliche Auftrag lautet etwa: „Prüfe diese Rechnung gegen die Bestelldaten und liefere Abweichungen in strukturierter Form.“ Die Anpassung an Längenlimits oder Rollenformate eines Modells gehört ins Gateway.

Strukturierte Ausgaben, etwa im Datenformat JSON, sind keine technische Eleganz, sondern Betriebssicherheit. Eine Fachanwendung kann ein klar definiertes Feld wie den Abweichungsbetrag prüfen, statt aus freiem Fließtext zu raten. Lassen Sie ein Modell ohne Strukturvorgabe direkt in einen Folgeprozess schreiben, wird aus einem Sprachmodell ein schwer kontrollierbares Automatisierungsrisiko.

Bei vertraulichen Daten gilt eine einfache Regel: Der Datenfluss muss vor dem Produkt entschieden sein. Für Personalakten, Vertragsdokumente oder Produktionsdaten kann ein europäischer Cloud-Betrieb, ein abgeschotteter Mandant oder ein Modell mit offenen Gewichten in eigener Umgebung sinnvoll sein. Das ist nicht automatisch günstiger und verlangt Betriebskompetenz. Es kann die richtige Entscheidung sein, wenn Speicherort und Kontrolle wichtiger sind als der schnellste Zugriff auf das nächste Modell.

Ohne Evaluation ist ein Modellwechsel eine Bauchentscheidung

Ein Anbieterwechsel gelingt nur dann in Tagen, wenn die Qualität bereits messbar ist. Dafür brauchen Sie einen Evaluationssatz aus echten, anonymisierten Fällen: reale Rechnungen, typische Supportanfragen, schwierige Vertragsklauseln. Künstliche Vorführbeispiele decken die Fehler aus dem Arbeitsalltag kaum auf.

Definieren Sie je Anwendungsfall eine akzeptierte Leistung, etwa eine Mindestgenauigkeit für Rechnungsnummer und Betrag oder eine Liste von Kriterien, die Fachanwender an einer Zusammenfassung bewerten: Vollständigkeit, korrekte Fristen, keine erfundenen Aussagen. Läuft ein neues Modell gegen denselben Bestand abgeschlossener Fälle, sehen Sie nach einem Nachmittag, ob es mehr Fälle richtig bearbeitet, ob es langsamer ist und was es pro Vorgang kostet. Erst diese Zahlen erlauben eine sachliche Entscheidung. Alles andere ist Modellgeschmack. Wie Sie einen solchen Evaluationssatz aufbauen, beschreibt der Beitrag Eigenes Evaluations-Set in fünf Schritten aufbauen.

Bauen Sie den Evaluationslauf in Ihre Release-Prozesse ein. Wenn ein Anbieter eine Modellversion still aktualisiert, fällt die Veränderung auf, bevor sie im Kundenservice oder in der Disposition landet. Das schützt auch vor dem Gegenteil der Abhängigkeit: dem hektischen Wechsel auf jedes neue Modell, weil es in einem Benchmark gerade glänzt.

Die Migration erfolgt schrittweise

Bestandssysteme werden selten an einem Wochenende modern. Das ist die Realität von Software, die Umsätze verarbeitet, Lager steuert oder gesetzliche Fristen einhält. Beginnen Sie mit einem klar begrenzten Anwendungsfall, dessen Nutzen messbar und dessen Schadenspotenzial beherrschbar ist.

In der Praxis bewährt sich ein paralleler Betrieb: Die alte Integration bleibt aktiv, während das Gateway dieselben Eingaben an den neuen Pfad sendet. Die Ergebnisse werden verglichen, aber noch nicht automatisch weiterverarbeitet. Das kostet für einige Wochen doppelte Modellaufrufe. Es ist trotzdem günstiger als ein fehlerhafter Produktivstart, bei dem tausende Vorgänge nachbearbeitet werden müssen.

Erst wenn Qualität, Laufzeit, Kosten und Datenschutzprüfung dokumentiert sind, wird der neue Pfad führend. Halten Sie einen Rückweg bereit. Ein Rollback muss eine Betriebsfunktion sein, keine nächtliche Codeänderung.

Häufige Fragen zur KI-Bereitschaft von Bestandssystemen

Müssen Sie auf herstellereigene Funktionen verzichten? Nein. Eine solche Funktion kann wirtschaftlich sinnvoll sein, etwa bei sehr guter Dokumentenverarbeitung. Die Entscheidung muss bewusst sein: Dokumentieren Sie Abhängigkeit, Ausstiegskosten und einen Ersatzweg. Herstellereigene Funktionen sind kein Fehler; unbemerkte Abhängigkeiten sind einer.

Reicht ein Multi-Cloud-Ansatz für Anbieterunabhängigkeit? Nein. Mehrere Clouds lösen keine Abhängigkeit von Modellschnittstellen, Prompt-Formaten oder fehlenden Tests. Unabhängigkeit entsteht in der Anwendungsschicht: Gateway, eigene Testdaten, klare Datenflüsse.

Welche Rolle spielt der Datenschutz beim Modellwechsel? Er entscheidet, welche Modelle und Betriebsformen überhaupt zulässig sind. Prüfen Sie Auftragsverarbeitung, Speicherorte, Trainingsnutzung und Löschkonzepte vor dem Pilotbetrieb. Ein späterer Wechsel wird einfacher, wenn Datenklassifizierung und Freigaben nicht an einen Anbieterprozess gebunden sind.

Der nächste Schritt: den Wechsel einmal auf Papier durchspielen

Wählen Sie einen produktiven KI-Anwendungsfall und spielen Sie den Wechselaufwand schriftlich durch: Schnittstellen, Prompts, Daten, Tests, Rückweg. Wo Sie ins Stocken geraten, liegt Ihre Abhängigkeit. Bringen Sie dieses Blatt mit, und wir gehen in eine halbe Stunde gemeinsam durch, welche Struktur für Ihren Fall die kleinste ausreichende ist: Potenzial-Check buchen.