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

KI-Readiness Legacy bedeutet: Ihre bestehenden Systeme können ein KI-Modell oder einen KI-Anbieter wechseln, ohne dass der Geschäftsbetrieb, die Datenhoheit oder die Ergebnisqualität daran hängen. Das ist relevant, weil ein vermeintlich schneller Anbieterwechsel in der Praxis meist an gewachsenen Prompts, proprietären API-Funktionen und fehlenden Qualitätstests scheitert.

Der Vier-Wochen-Wechsel ist meist eine Illusion

Rund 90 Prozent der Entscheider trauen ihrer Organisation zu, einen KI-Anbieter binnen etwa vier Wochen auszutauschen. Diese Einschätzung hält selten stand, sobald jemand den konkreten 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 noch fachlich brauchbar sind?

Ein typisches Bild aus dem Mittelstand: Ein Service-Team nutzt einen KI-Assistenten, um E-Mails zu klassifizieren und Antwortentwürfe zu schreiben. Anfangs wird die API direkt aus dem CRM angesprochen. Nach sechs Monaten gibt es 40 Prompts, Sonderbehandlungen für bestimmte Kunden, ein proprietäres Datei-Upload-Feature und eine Handvoll Fehlercodes, die im Code abgefangen werden. Der Anbieterwechsel ist dann kein Konfigurationseintrag. Er ist ein Umbauprojekt, dessen Umfang niemand sauber 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 zwar den Vertrag, aber nicht mehr die technische Handlungsfreiheit.

KI-Readiness Legacy beginnt mit einer ehrlichen Bestandsaufnahme

KI-Readiness Legacy lässt sich nicht durch einen neuen Chatbot herstellen. Der erste Schritt ist ein Architektur-Inventar, das sichtbar macht, 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. Dazu zählen etwa die Angebotsprüfung im Vertrieb, die Schadensbewertung im Versicherungsumfeld oder die Dokumentenextraktion in der Logistik. Erfassen Sie für jeden Anwendungsfall den Datenfluss: Welche Daten gehen an das KI-Modell, in welchem Land werden sie verarbeitet, welches Ergebnis kommt zurück und welche Anwendung verarbeitet dieses Ergebnis 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, nicht nur in einer Präsentation für den Lenkungskreis.

Wir sehen bei Legacy-Transformationen oft einen weiteren blinden Fleck: Zugangsdaten und Modellnamen sind in Anwendungen, Skripten oder CI/CD-Pipelines verteilt. CI/CD steht für Continuous Integration und Continuous Delivery, also den automatisierten Weg vom Code bis zum Betrieb. Wenn ein Modellname an zwölf Stellen hinterlegt ist, wird jeder Wechsel unnötig riskant. Ein belastbares Inventar findet solche Stellen vor dem ersten Umbau.

Eine eigene KI-Schnittstelle trennt Fachlogik und Anbieter

Eine KI-Gateway-Schicht ist der wirksamste technische Hebel gegen Lock-in. Das Gateway ist eine eigene, kontrollierte Schnittstelle zwischen Ihren Anwendungen und den APIs der KI-Anbieter. Die Fachanwendung fordert dort beispielsweise eine strukturierte Vertragszusammenfassung an; sie kennt weder die Eigenheiten eines konkreten Modells noch dessen Antwortformat.

Diese Trennung klingt banal, wird aber oft aus Zeitdruck ü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 KI-Gateway übernimmt mindestens die Auswahl des Modells, die Authentifizierung, Protokollierung und die Übersetzung von Ein- und Ausgabeformaten. Es speichert außerdem, welche Modellversion für welchen Vorgang eingesetzt wurde. Dieser Audit-Trail, also die nachvollziehbare Spur jeder Verarbeitung, ist in regulierten Branchen kein Luxus. Wenn ein Kunde oder ein Auditor nach drei Monaten fragt, wie eine Entscheidung zustande kam, reicht die Aussage „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. Architecture First heißt nicht, möglichst viel Architektur zu verkaufen. Es heißt, die kleinste Struktur zu bauen, die einen späteren Wechsel realistisch macht.

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 Quellcode-Dateien oder direkt in einem Anbieter-Portal. Das ist bequem, bis ein Modell ersetzt, ein Dienstleister gewechselt oder ein Audit verlangt wird.

Legen Sie Prompts versioniert in Ihrem eigenen Repository ab und trennen Sie den fachlichen Auftrag von der modellspezifischen Formulierung. Der fachliche Auftrag könnte lauten: „Prüfe diese Rechnung gegen die Bestelldaten und liefere Abweichungen im JSON-Format.“ Die Anpassung an Token-Limits, spezielle Rollenformate oder Besonderheiten eines Modells gehört in das KI-Gateway.

JSON ist ein maschinenlesbares Datenformat. Sein Vorteil liegt nicht in technischer Eleganz, sondern in Betriebssicherheit: Eine Fachanwendung kann ein klar definiertes Feld wie abweichungsbetrag prüfen, statt aus einem freien Fließtext zu raten. Lassen Sie ein Modell ohne Strukturvorgabe direkt in einen Folgeprozess schreiben, wird aus einem Sprachmodell schnell 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 Open Weights sinnvoll sein. Open Weights bedeutet, dass die Modellgewichte verfügbar sind und innerhalb einer kontrollierten Umgebung betrieben werden können. Das ist nicht automatisch günstiger und verlangt Betriebskompetenz. Es kann aber die richtige Entscheidung sein, wenn Datenresidenz 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 Support-Anfragen, schwierige Vertragsklauseln. Synthetische Demo-Beispiele helfen bei Präsentationen, decken aber die Fehler aus dem Arbeitsalltag kaum auf.

Definieren Sie je Anwendungsfall eine akzeptierte Leistung. Bei einer Dokumentenextraktion kann das eine Feldgenauigkeit von 98 Prozent für Rechnungsnummer und Betrag sein. Bei einer Zusammenfassung können Fachanwender zehn Kriterien bewerten, etwa Vollständigkeit, korrekte Fristen und erfundene Aussagen. Es genügt nicht, dass eine Antwort „gut klingt“.

Ein mittelständischer Logistiker kann beispielsweise 200 abgeschlossene Schadensfälle als Testbestand nutzen. Läuft ein neues Modell gegen denselben Bestand, sehen Sie nach einem Nachmittag, ob es mehr Fälle richtig klassifiziert, ob es langsamer ist und welchen Preis es pro Vorgang verursacht. Erst diese Zahlen erlauben eine sachliche Entscheidung. Alles andere ist Modellgeschmack.

Bauen Sie den Evaluationslauf in Ihre Release-Prozesse ein. Wenn ein Anbieter eine Modellversion still aktualisiert, fällt die Veränderung dann auf, bevor sie im Kundenservice oder in der Disposition landet. Das schützt auch vor dem Gegenteil des Lock-ins: dem hektischen Wechsel auf jedes neue Modell, weil es in einer Benchmark gerade beeindruckende Werte erzielt.

Die Migration erfolgt schrittweise, nicht als Big Bang

Legacy-Systeme werden selten an einem Wochenende modern. Das ist keine Schwäche, sondern 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 zunächst aktiv, während das KI-Gateway dieselben Eingaben an den neuen Pfad sendet. Die Ergebnisse werden verglichen, aber noch nicht automatisch weiterverarbeitet. Dieses Verfahren kostet für einige Wochen doppelte Modellaufrufe. Es ist trotzdem günstiger als ein fehlerhafter Produktivstart, bei dem 3.000 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 durch zwei Entwickler. Gerade Unternehmen in Frankfurt und im Rhein-Main-Gebiet, die unter engen regulatorischen Vorgaben arbeiten, sollten diesen Punkt nicht als technische Nebensache behandeln.

FAQ

Wie lange dauert KI-Readiness Legacy bei bestehenden Altsystemen?

Ein erster belastbarer Anwendungsfall lässt sich häufig in sechs bis zwölf Wochen entkoppeln, wenn Schnittstellen dokumentiert sind und Fachanwender Zeit für Tests bereitstellen. Die umfassende Modernisierung einer Landschaft mit vielen Direktintegrationen dauert deutlich länger. Wer eine Woche für die Bestandsaufnahme einplant, obwohl niemand die Prompt- und Datenflüsse kennt, plant keinen Umbau, sondern hofft.

Müssen wir auf proprietäre Funktionen vollständig verzichten?

Nein. Ein proprietäres Feature kann wirtschaftlich sinnvoll sein, etwa bei einer sehr guten Dokumentenverarbeitung. Die Entscheidung muss bewusst sein: Dokumentieren Sie Abhängigkeit, Ausstiegskosten und einen Ersatzweg. Proprietäre Funktionen sind kein Fehler; unbemerkte Abhängigkeiten sind einer.

Reicht ein Multi-Cloud-Ansatz für Anbieterunabhängigkeit?

Nein. Mehrere Clouds lösen keine direkte Abhängigkeit von Modell-APIs, Prompt-Formaten oder Evaluationen. Anbieterunabhängigkeit entsteht in der Anwendungsschicht durch das KI-Gateway, eigene Testdaten und klare Datenflüsse.

Welche Rolle spielt Datenschutz beim Modellwechsel?

Datenschutz entscheidet, welche Modelle und Betriebsformen überhaupt zulässig sind. Prüfen Sie Auftragsverarbeitung, Speicherorte, Trainingsnutzung, Löschkonzepte und Zugriffskontrollen vor dem Pilotbetrieb. Ein späterer Wechsel wird erheblich einfacher, wenn Datenklassifizierung und Freigaben nicht an einen einzelnen Anbieterprozess gebunden sind.

Fazit

IT-Leiter in B2B-Unternehmen sollten innerhalb der nächsten 30 Tage einen produktiven KI-Anwendungsfall auswählen und den Wechselaufwand schriftlich durchspielen: Schnittstellen, Prompts, Daten, Tests und Rollback. Für Unternehmen in Darmstadt, Frankfurt und dem Rhein-Main-Gebiet ist das eine konkrete Resilienzaufgabe, keine KI-Strategieübung. Wenn Ihnen für diesen Wechselplan Architektur oder unabhängige Evaluation fehlt, buchen Sie ein Gespräch, um die KI-Potenziale für Ihr Unternehmen anhand eines realen Systems zu besprechen.