Was das System darf – und was es nicht darf.

Ja. Das System führt ausschließlich lesende Abfragen aus. Es schreibt, ändert oder löscht keine Daten in Ihren Systemen.

Diese Beschränkung liegt nicht im Sprachmodell, sondern in der Architektur: Ein Abfrageplan, der etwas anderes als eine Leseoperation beschreibt, wird von der Prüfschicht nicht übersetzt und nicht ausgeführt.

Zum Teil. Die Anwendung inklusive semantischem Modell, Prüfschicht, Datenbankzugang und Protokollierung ist für den Betrieb in Ihrer eigenen Infrastruktur ausgelegt und kann dort self-hosted betrieben werden. Ihr Datenbestand wird dabei nicht kopiert oder ausgelagert.

Außerhalb liegt heute allein das Sprachmodell: Es wird über eine Schnittstelle angebunden, nicht mitgeliefert, und läuft beim jeweiligen Anbieter. Ein vollständig lokal betriebenes Modell ist in Arbeit; zugesagt wird es, sobald es erprobt ist – und erprobt wird es gemeinsam mit dem Projekt, das es braucht.

„Self-hosted“ heißt in diesem Zusammenhang also: alle Komponenten außer dem Sprachmodell. Der Betrieb ganz ohne ausgehenden Modellaufruf ist der nächste Ausbauschritt – und ein gutes Thema für ein Pilotprojekt.

Das System verfügt über ein eigenes Benutzer- und Rollenkonzept. Darüber wird gesteuert, welche Bereiche des semantischen Modells eine Rolle abfragen darf.

Weil die Berechtigung am Modell und nicht an einzelnen SQL-Abfragen hängt, kann sie fachlich beschrieben werden – und ein Abfrageplan, der über die Rechte einer Rolle hinausgeht, wird abgelehnt.

Zwei Zugänge, beide lesend – das ist die vollständige Liste:

Erstens einen eigenen Datenbankbenutzer mit ausschließlich lesenden Rechten auf die fachlich relevanten Schemata. Zweitens lesenden Zugriff auf das Repository mit dem Sourcecode, üblicherweise per Git, weil das Datenmodell allein die fachliche Bedeutung der Felder nicht hergibt.

Mehr wird nicht benötigt: keine Schreibrechte, keine administrativen Rechte, kein Zugriff auf weitere Systeme.

Die Erschließung des semantischen Modells ist KI-gestützt – und das heißt konkret: Ausschnitte Ihres Sourcecodes und Ihres Datenmodells werden an ein Sprachmodell übermittelt. Heute geschieht das über die Schnittstelle eines externen Anbieters; ein lokal betriebenes Modell ist dafür in Arbeit. Das steht hier ausdrücklich, weil Ihre IT-Sicherheit genau an dieser Stelle nachfragen wird – und die Antwort vorher kennen soll.

Übermittelt werden dabei Code- und Strukturinformationen, nicht Ihre Produktivdaten: Die Analyse arbeitet auf Sourcecode und Schema, Datensätze aus Ihrer Datenbank braucht sie dafür nicht. Werden im Einzelfall Beispieldaten benötigt, wird das vorher benannt und gesondert vereinbart.

Die Analyse ist ein Vorgang der Einführung und läuft nicht dauerhaft im Betrieb mit. Sie wird wiederholt, wenn sich Ihr System wesentlich ändert. Ergebnis ist das semantische Modell – eine Beschreibung, die anschließend in Ihrer Infrastruktur liegt.

Gerling Solutions trainiert mit Ihrem Sourcecode kein Modell und legt außerhalb der vereinbarten Arbeitsumgebung keine dauerhafte Kopie Ihres Repositorys an. Was der Anbieter des eingesetzten Sprachmodells mit übermittelten Inhalten darf, regelt dessen Vertrag; kommerzielle API-Vereinbarungen schließen eine Verwendung zu Trainingszwecken üblicherweise aus, Endkundentarife nicht zwangsläufig.

Wenn Ihr Sourcecode selbst das Schutzgut ist, gehören vor die Analyse drei Festlegungen: welcher Anbieter und welche Vertragslage gelten, welche Repositorys und Bereiche einbezogen werden – und welche ausdrücklich nicht. Das wird schriftlich vereinbart, bevor gelesen wird. Ist eine Übermittlung von Code an einen externen Anbieter für Sie ausgeschlossen, ist das ein Ausschlusskriterium für den heutigen Stand und sollte im ersten Gespräch geklärt werden, nicht im letzten.

Das hängt am Betriebsmodus – und ist der Grund, warum es zwei gibt.

In der eigenen Oberfläche gehen die Beschreibung des semantischen Modells und die gestellte Frage an das Sprachmodell, nicht aber die Abfrageergebnisse. Zur Ehrlichkeit gehört der Zusatz: Die Frage selbst wird übermittelt. Wer nach einem namentlich genannten Kunden fragt, übermittelt diesen Namen.

Bei Anbindung einer externen KI-Anwendung über MCP gehen zusätzlich die Abfrageergebnisse an den Anbieter dieser Anwendung, weil dessen Modell sie auswerten muss, um mehrschrittig weiterzuarbeiten.

Nicht ausgelagert wird in beiden Fällen der Datenbestand selbst. Ihre Datenbank wird nicht als Ganzes kopiert, nicht synchronisiert und ist von außen nicht erreichbar; sie wird ausschließlich durch die Prüf- und Übersetzungsschicht in Ihrer Infrastruktur gelesen. Hinaus geht immer nur, was eine konkrete Frage erfordert – nie der Bestand.

Es wird besser, aber es lernt nicht im Sinne von Modelltraining. Die beiden Dinge werden gern verwechselt, und der Unterschied ist hier wesentlich.

Was wächst, ist das beschriebene Modell Ihres Unternehmens: eine lesbare, prüfbare Sammlung von Fachbegriffen und Regeln in Ihrer Infrastruktur. Jeder Zuwachs geht auf eine benannte Lücke und eine dokumentierte fachliche Entscheidung zurück – und ist damit auch jederzeit wieder korrigierbar. Kein Gewicht in einem Sprachmodell verändert sich dabei.

Gerling Solutions trainiert keine Modelle – weder mit Ihren Daten noch mit Ihrem Sourcecode. Es gibt an dieser Stelle keinen Trainingsprozess, der etwas mitlernen könnte.

Was der Anbieter des angebundenen Sprachmodells mit übermittelten Inhalten darf, regelt dessen Vertrag. Kommerzielle API-Vereinbarungen schließen eine Verwendung zu Trainingszwecken üblicherweise aus, Endkundentarife derselben Anbieter nicht zwangsläufig – deshalb wird das hier nicht pauschal zugesagt, sondern geprüft.

Der entscheidende Punkt: Diese Wahl liegt bei Ihnen. Sie entscheiden, welche Schnittstelle und welches Modell angebunden werden, und damit auch, welche Vertragslage gilt. Bei der Auswahl und beim Nachweis unterstütze ich; festgelegt wird sie vor der Einführung schriftlich.

Ja, und im aktuellen Stand vollständig: Fragen und Abfrageergebnisse werden mitgeschrieben. Das ist eine bewusste Entscheidung der Alpha-Phase, nicht ein Nebenprodukt – die Protokolle sind die Grundlage, um die Antworten anschließend gemeinsam mit dem Alphakunden fachlich zu validieren.

Damit ist auch die Frage nach der Datenhaltung genau zu beantworten: Was in einem Protokoll steht, ist eine gespeicherte Kopie einzelner Abfrageergebnisse. Sie liegt in Ihrer Infrastruktur, nicht in einer Ablage bei mir, und sie ersetzt oder repliziert Ihren Datenbestand nicht – aber sie ist vorhanden, und deshalb steht sie hier.

Für einen Regelbetrieb ist dieser Umfang bewusst zu weit gefasst. Was protokolliert wird, wo die Protokolle liegen und wie lange sie aufbewahrt werden, wird deshalb pro Projekt festgelegt, bevor das System an echten Daten arbeitet.

Unabhängig davon ist jede Antwort nachvollziehbar, weil sie auf einem geprüften Abfrageplan beruht: Zu jedem Ergebnis lässt sich sagen, welche Begriffe verwendet, welche Regeln angewandt und welche Daten gelesen wurden.