KI-Features in Bestandssysteme integrieren: Muster für gewachsenen Code

Die Ausgangslage ist in vielen Unternehmen dieselbe: Es gibt eine Anwendung, die seit zehn oder fünfzehn Jahren das Geschäft trägt. Gewachsen, stellenweise undokumentiert, mit einem Datenmodell, das mehrere Generationen von Entwicklern und Anforderungen überlebt hat. Und es gibt den berechtigten Wunsch, KI-Features in dieses Bestandssystem zu integrieren: eine Zusammenfassung hier, eine automatische Zuordnung dort, ein Assistent für die Sachbearbeitung.

Der erste Reflex ist oft einer von zwei Fehlern. Entweder der große Wurf: Wir modernisieren das System ohnehin, dann bauen wir die KI gleich mit ein. Das koppelt ein überschaubares Feature an ein mehrjähriges Umbauprojekt und begräbt es meistens darunter. Oder der kurze Dienstweg: ein API-Aufruf mitten in den alten Code, direkt neben die Geschäftslogik, mit Direktzugriff auf die Tabellen. Das funktioniert drei Monate lang und wird dann zur unwartbaren Sonderlocke. Zwischen beiden Extremen liegen erprobte Integrationsmuster, die das Altsystem in Ruhe lassen und trotzdem echte KI-Funktionalität liefern.

Sidecar statt Big Bang

Das tragfähigste Grundmuster ist das Sidecar: Die KI-Funktionalität lebt in einem eigenen, kleinen Dienst neben dem Bestandssystem, nicht in ihm. Dieser Dienst kapselt alles, was neu und beweglich ist: Prompts, Modellaufrufe, Retrieval, Evals, Kostenkontrolle. Im Altsystem selbst entsteht nur ein dünner Adapter: eine klar umrissene Stelle, die den Dienst aufruft, dessen Antwort entgegennimmt und in die bestehende Oberfläche oder den bestehenden Ablauf einfügt.

Die Vorteile sind handfest. Der KI-Dienst hat einen eigenen Release-Zyklus, denn Prompts und Modelle ändern sich wöchentlich, das Altsystem vielleicht quartalsweise. Er darf einen modernen Stack verwenden, unabhängig davon, in welcher Sprache und auf welchem Framework der Bestand läuft. Und der Schadensradius bleibt begrenzt: Fällt der Dienst aus oder liefert Unsinn, ist ein Feature betroffen, nicht das Kernsystem. Der Adapter im Bestand sollte dafür von Anfang an mit Zeitlimit, Fehlerbehandlung und einem definierten Verhalten bei Nichtverfügbarkeit gebaut sein. Die Regel lautet: Das Altsystem muss ohne den KI-Dienst genauso weiterlaufen wie vor dessen Einführung.

Die Grenze zwischen deterministischem Kern und KI-Schicht

Die wichtigste Architekturentscheidung ist keine technische, sondern eine konzeptionelle: Wo verläuft die Grenze zwischen dem deterministischen Kern und der probabilistischen KI-Schicht. Der Kern, also Buchungen, Statuswechsel, Fristen, Berechnungen, verhält sich heute vorhersagbar, und das muss so bleiben. Die KI-Schicht liefert Vorschläge, Zusammenfassungen, Zuordnungen und Entwürfe, also Ergebnisse mit Restunsicherheit.

Daraus folgt eine harte Regel: Die KI-Schicht schreibt nie direkt in den Zustand des Kernsystems. Ihre Ausgaben sind Daten, keine Befehle. Sie werden validiert wie jede externe Eingabe, gegen das Schema geprüft, auf Plausibilität kontrolliert und erst dann über die vorhandenen, abgesicherten Wege des Kernsystems verarbeitet, im Zweifel mit menschlicher Freigabe dazwischen. Wer eine Modellantwort ungeprüft in ein Update-Statement übersetzt, hat die Grenze verwischt und holt sich die Unsicherheit des Modells in den Teil des Systems, dessen Verlässlichkeit das Geschäft trägt. Sinnvoll ist außerdem, jede KI-Ausgabe als solche zu kennzeichnen und ihre Herkunft zu protokollieren: welches Modell, welcher Prompt-Stand, welche Quelldaten. Spätestens bei der ersten Reklamation zahlt sich das aus.

Datenzugriff über Verträge statt Direktverdrahtung

Die zweite Versuchung beim kurzen Dienstweg ist der Datenzugriff: Der KI-Dienst bekommt einen Lesezugang zur alten Datenbank und bedient sich direkt. Das rächt sich gleich mehrfach. Historische Schemata sind voller impliziter Semantik, die nur der Code des Altsystems kennt. Das Schema ändert sich mit dem nächsten Release des Bestands, und niemand denkt an den stillen Mitleser. Und Berechtigungen, die das Altsystem in seiner Anwendungslogik durchsetzt, existieren auf Tabellenebene oft gar nicht, sodass der KI-Dienst mehr sieht, als der jeweilige Nutzer sehen dürfte.

Der saubere Weg ist ein definierter Datenvertrag: eine explizite Schnittstelle, über die der KI-Dienst genau die Daten erhält, die er braucht, in einer dokumentierten Struktur mit geklärter Bedeutung. Technisch kann das eine kleine Lese-API auf dem Bestand sein, eine dedizierte Sicht oder ein regelmäßiger Export in einen eigenen Lesebestand. Entscheidend ist nicht die Technik, sondern das Prinzip: Es gibt eine benannte Stelle, an der die Datenübergabe stattfindet, mit einem Schema, das beide Seiten kennen und das bei Änderungen bewusst angepasst wird. Der Nebeneffekt ist wertvoll: Beim Formulieren des Vertrags muss das Team die Semantik der Altdaten einmal explizit machen, und genau diese Dokumentation braucht später auch das Modell im Kontext.

Schrittweise Einführung: lesen, vorschlagen, handeln

Auch mit sauberer Architektur sollte die Funktionalität in Stufen wachsen, entlang des Risikos:

• Stufe eins, nur lesen: Das KI-Feature fasst zusammen, ordnet ein, beantwortet Fragen über vorhandene Daten. Es verändert nichts. Fehler kosten hier nur Vertrauen, keine Datenintegrität.
• Stufe zwei, vorschlagen: Das Feature erzeugt Entwürfe und vorausgefüllte Felder, ein Mensch prüft und bestätigt. Die Übernahmequote der Vorschläge ist dabei gleich die wichtigste Qualitätskennzahl.
• Stufe drei, begrenzt handeln: Erst wenn die Vorschlagsqualität über längere Zeit belegt ist, übernimmt das System einzelne, klar umrissene Aktionen selbst, weiterhin über die validierten Wege des Kerns und mit Protokoll.

Diese Reihenfolge hat einen doppelten Nutzen. Sie begrenzt das Risiko, und sie erzeugt in den frühen Stufen genau die Daten, mit denen sich die späteren rechtfertigen lassen.

Stolperfallen historischer Datenmodelle

Ein eigenes Kapitel verdienen die Altdaten selbst, denn gewachsene Datenmodelle haben Eigenheiten, die einem Sprachmodell nicht anzusehen sind. Felder, die im Lauf der Jahre umgewidmet wurden und je nach Datensatzalter Verschiedenes bedeuten. Magische Werte wie eine Neun-Neun-Neun, die intern für unbekannt steht, die das Modell aber als echten Wert liest. Freitextfelder, in denen Generationen von Sachbearbeitern strukturierte Information nach Hausbrauch abgelegt haben. Statuscodes, deren Bedeutung nur mündlich überliefert ist. Inkonsistente Historie aus alten Migrationen.

Das Tückische: Ein Sprachmodell scheitert an solchen Daten nicht sichtbar, es interpretiert sie plausibel und falsch. Die Gegenmittel sind unspektakulär. Die Semantik der übergebenen Felder gehört dokumentiert und dem Modell als Kontext mitgegeben, einschließlich der magischen Werte und Umwidmungen. Bekannte Datenqualitätsprobleme werden im Datenvertrag bereinigt oder markiert, bevor sie das Modell erreichen. Und ins Eval-Set gehören gezielt Fälle mit genau diesen Altlasten, denn dort entscheidet sich, ob das Feature mit der echten Datenlage zurechtkommt oder nur mit der gedachten.

Fazit

KI-Features gehören neben das Bestandssystem, nicht hinein. Das Sidecar-Muster mit einem dünnen Adapter hält den Bestand stabil und die KI-Schicht beweglich. Die Grenze zwischen deterministischem Kern und probabilistischer Schicht bleibt hart: KI-Ausgaben sind zu validierende Daten, keine Befehle, und der Datenzugriff läuft über einen dokumentierten Vertrag statt über Direktzugriff auf alte Tabellen. Eingeführt wird in Stufen, vom Lesen über das Vorschlagen zum begrenzten Handeln, und die Eigenheiten des historischen Datenmodells kommen explizit in Dokumentation, Datenvertrag und Eval-Set. So entsteht KI-Funktionalität in gewachsenem Code ohne Big Bang, und das Altsystem tut weiter das, was es am besten kann: zuverlässig laufen.