Mehrere Fachsysteme an ein lokales Sprachmodell anschließen

Die System­landschaft des Hauses ist stark aufgeteilt: mehrere Datensilos, verschachtelte Schnittstellen, unterschiedliche Zuständigkeiten. Für eine Frage, die zwei Systeme berührt, gibt es keinen gemeinsamen Ort — man öffnet beide und führt die Antwort selbst zusammen. Der übliche Ausweg wären Einzel­integrationen, für jedes Systempaar eine, jede mit eigener Pflege. Gefragt ist deshalb der Nachweis, dass es auch anders geht: über eine offene Werkzeug­schnittstelle, die den Zugriff auf verschiedene Systeme vereinheitlicht, sodass ein Sprachmodell sie in natürlicher Sprache abfragen kann. Zwei Bedingungen stehen fest. Cloud-Lösungen für das Sprachmodell sind aus Daten­schutz­gründen ausgeschlossen — das Modell muss im eigenen Haus laufen und vollständig kontrollierbar sein. Und die angebundenen Bestände umfassen rund hunderttausend Datensätze, also deutlich mehr, als sich einem Modell vorlegen lässt.

Eine Schnittstelle statt vieler Integrationen. Für jedes Systempaar eine eigene Anbindung zu entwickeln, erzeugt eine Pflegelast, die mit jedem weiteren System quadratisch wächst. Eine offene Werkzeug­schnittstelle vereinheitlicht stattdessen den Zugriff: Jedes System bekommt Werkzeuge, das Modell kennt die Werkzeuge, und ein neues System bedeutet neue Werkzeuge statt einer neuen Integration. Das ist der Unterschied zwischen einem Machbarkeits­nachweis, der sich ausbauen lässt, und einem, den man später wegwirft.

Nicht die Daten ins Modell, sondern die Frage an die Datenbank. Hunderttausend Datensätze passen in kein Kontextfenster, und der Versuch, es trotzdem zu tun, ist die häufigste Ursache für teure und schlechte Antworten. Stattdessen filtern, aggregieren und rechnen die Werkzeuge dort, wo die Daten liegen; das Modell bekommt nur, was für die Antwort gebraucht wird. Damit ist die Größe des Bestands kein Problem mehr, sondern eine Frage des Zuschnitts.

Das Modell bleibt im Haus, und das schränkt die Auswahl ein. Weil Cloud-Betrieb ausgeschlossen war, kommen nur offen verfügbare Modelle in Frage. Das ist keine Einschränkung, die man beklagt, sondern eine Anforderung, die man durchrechnet: welches Modell die Analyse­aufgaben bewältigt, wie groß das Kontextfenster sein muss und welche Hardware das kostet. Diese Rechnung gehört in den Machbarkeits­nachweis und nicht in die Beschaffung danach — sonst steht am Ende ein funktionierender Nachweis, für den niemand die Anlage bezahlen will.

Entwickelt wird spezifikations­getrieben, und der Code entsteht KI-gestützt. Am Anfang jeder Umsetzung steht eine Spezifikation: ein versioniertes Dokument, das wie Code geprüft wird, für Technik und Fachbereich gleichermaßen lesbar, in dem Entscheidungen, Sonderfälle und Abwägungen geklärt sind, bevor eine Zeile entsteht. Die Architektur wird nach einem etablierten Rahmenwerk dokumentiert. Der Grund für diese Reihenfolge ist nicht Ordnungsliebe, sondern Prüfbarkeit: Erzeugter Code wächst schneller, als die Zeit reicht, ihn zu lesen. Wer einem Modell nur beschreibt, was er ungefähr will, bekommt schnell Code und bei jedem Durchlauf einen anderen. Die Spezifikation ist zugleich die Dokumentation, die sonst am Ende fehlt — und wo ein Modell auf mehrere Fachsysteme zugreift, wird dort festgelegt, welches Werkzeug welche Rechte mitführt.

Ein Nachweis mit Ausbaupfad, nicht ohne. Am Ende steht nicht die Frage, ob es funktioniert hat, sondern eine Entscheidungs­vorlage. Der Test mit ausgewählten Anwendern ist deshalb Bestandteil des Nachweises und nicht ein späteres Nachfassen: Sie haben das System im eigenen Einsatz­kontext bewertet, und aus ihren Rückmeldungen entscheidet sich der Ausbau — weitere Datenquellen, ein abgestuftes Berechtigungs­konzept, ein größerer Nutzerkreis. Ein Machbarkeits­nachweis ohne diesen Schritt endet als Video.

Berechtigungen sind der eigentliche Prüfstein. Solange ein Nachweis mit wenigen Anwendern läuft, ist die Frage nachrangig; sobald das Haus mitliest, ist sie die Hauptsache. Wer über eine gemeinsame Schnittstelle auf mehrere Fachsysteme zugreift, muss die Rechte dieser Systeme mitführen und nicht umgehen. Deshalb ist das abgestufte Berechtigungs­konzept ausdrücklich als Bestandteil des Ausbaus benannt und nicht als Selbstverständlichkeit vorausgesetzt.