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.

Nein. Ihre bestehenden Systeme bleiben unverändert. Es wird keine Software umgebaut, keine Datenbank migriert und kein Schema geändert.

Analysiert werden Sourcecode und Datenmodell; das Ergebnis ist ein zusätzliches, daneben liegendes Modell.

Ja – das ist der Unterschied zwischen den beiden Betriebsmodi, und er betrifft genau den Punkt, der in einer technischen Prüfung zuerst geklärt wird.

Modus 1 – eigene Oberfläche: Die Frage wird im System selbst gestellt. Ein Sprachmodell erstellt den Abfrageplan, bekommt dafür aber nur die Beschreibung des semantischen Modells zu sehen: Begriffe, Beziehungen, Regeln. Ihre Datensätze bleiben davon unberührt – Abfrageergebnisse werden ausgelesen, verarbeitet und angezeigt, ohne an ein Modell übermittelt zu werden.

Modus 2 – Anbindung einer externen KI-Anwendung über MCP: Hier übernimmt das Modell des jeweiligen Anbieters die Arbeit, im getesteten Fall aus Claude Desktop heraus. Damit sieht dieses Modell auch die Abfrageergebnisse, denn es muss sie bewerten, um weiterzuarbeiten.

Die Wahl liegt bei Ihnen. Wenn Abfrageergebnisse Ihr Netz nicht verlassen dürfen, ist Modus 1 der Weg; wenn Ihre Fachabteilung in ihrer gewohnten KI-Anwendung arbeiten soll, Modus 2.

Nein. Das Sprachmodell erzeugt kein SQL und benötigt keine Kenntnis Ihrer Tabellenstruktur.

Es formuliert einen Abfrageplan in den Begriffen des semantischen Modells. Dieser Plan wird gegen das Modell geprüft und erst dann vom System selbst in eine lesende Datenbankabfrage übersetzt.

Das gilt auch für mehrschrittige Fragen: Auch wenn das Modell mehrere Abfragen hintereinander stellt und Zwischenergebnisse auswertet, durchläuft jeder einzelne Plan dieselbe Prüfung.

Nein, und das ist das tragende Prinzip der Architektur. Zwischen Sprachmodell und Datenbank liegt immer eine Vermittlungsschicht in Ihrer Infrastruktur. Es gibt keinen Kanal, auf dem das Modell selbst mit Ihrer Datenbank spricht – weder Zugangsdaten noch Netzwerkverbindung noch Treiber.

Jede Anfrage und jede Antwort läuft durch diese Schicht. Genau deshalb lassen sich die Zusagen auf dieser Seite überhaupt machen: Der lesende Zugriff, die Rollenrechte, die Protokollierung und die Herkunftsangabe zu jeder Antwort sind dort durchgesetzt – nicht als Anweisung an ein Sprachmodell formuliert, die es befolgen kann oder auch nicht.

Das ist der Unterschied zwischen einer Regel und einer Bitte. Ein Sprachmodell, das direkten Datenbankzugang hat, muss man um korrektes Verhalten bitten. Eines ohne diesen Zugang kann nur das tun, was die Vermittlungsschicht zulässt.

Über MCP (Model Context Protocol), einen offenen Standard zur Anbindung externer Werkzeuge und Datenquellen an KI-Anwendungen. Das semantische Modell wird als MCP-Server bereitgestellt; die KI-Anwendung ist der Client.

Der Client erhält dabei keinen Datenbankzugang, sondern ausschließlich die Möglichkeit, Abfragepläne gegen das semantische Modell zu stellen. Prüfung, Übersetzung und der Datenbankzugriff selbst bleiben auf der Serverseite und damit in Ihrer Infrastruktur.

Erprobt ist derzeit die Anbindung von Claude Desktop. Weil MCP ein offener Standard ist, sind weitere Clients grundsätzlich möglich; belastbar zugesagt wird hier nur, was auch geprüft wurde.

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.

Nicht eingeschlossen ist das Sprachmodell: Es wird über eine Schnittstelle angebunden, nicht mitgeliefert, und läuft heute beim jeweiligen Anbieter. Ein vollständig lokal betriebenes Modell ist bislang nicht erprobt – hier wird deshalb nichts zugesagt, was nicht getestet ist.

„Self-hosted“ heißt in diesem Zusammenhang also: alle Komponenten außer dem Sprachmodell. Ein Betrieb ganz ohne ausgehenden Modellaufruf ist derzeit nicht möglich.

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, weil ein lokal betriebenes Modell dafür nicht Teil des Leistungsstands ist. Diese Seite sagt das ausdrücklich, weil es der Punkt ist, an dem eine IT-Sicherheit sonst zu Recht nachfragt.

Ü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.

Ihre operativen Daten bleiben dort, wo sie heute liegen – auf Ihren Datenbankservern. Es wird keine Kopie oder Synchronisation Ihres Datenbestands angelegt und keine Cloud-Ablage zwischengeschaltet.

Das semantische Modell beschreibt Struktur und Bedeutung dieser Daten, enthält sie aber nicht.

Davon zu unterscheiden ist der einzelne Abfragevorgang: Abfrageergebnisse werden verarbeitet, um die jeweilige Frage zu beantworten, und können abhängig von der vereinbarten Protokollierung in Ihrer Infrastruktur gespeichert werden. Das betrifft einzelne Ergebnisse einzelner Abfragen, nicht den Datenbestand – eine Replikation Ihrer Datenbank entsteht dadurch nicht.

Wie weit diese Protokollierung im aktuellen Stand geht und was davor projektspezifisch festgelegt wird, steht weiter unten unter „Werden Abfragen protokolliert?“.

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.

Jede Antwort führt ihre vollständige Herleitung mit: das komplette Regelset, das in sie eingegangen ist – jede beteiligte Regel mit ihrer fachlichen Definition –, die aufgelösten Begriffe und Stichtage sowie die tatsächlich ausgeführte Abfrage im Wortlaut.

Bewusst vollständig und nicht als Auszug: Solange eine beteiligte Regel unsichtbar bliebe, ließe sich das Ergebnis nicht beurteilen. Eine Prüfung, die nur einen Teil der Herleitung sieht, ist keine Prüfung.

Damit steht eine Zahl nicht allein da. Wer sie anzweifelt, kann die Regel benennen, die er für falsch hält – etwa die Definition, ab wann eine Rechnung als offen gilt. Ist sie falsch, wird sie korrigiert; das Ergebnis ändert sich danach überall gleichermaßen.

Möglich ist das, weil die Vermittlungsschicht diese Angaben erzeugt und nicht das Sprachmodell. Es handelt sich um eine Aufzeichnung des tatsächlich ausgeführten Vorgehens, nicht um eine nachträgliche Begründung durch ein Modell – der Unterschied ist bei einer Revision der entscheidende.

Dann soll es das sagen – und in der Regel tut es das. Weil jede Frage gegen ein explizit beschriebenes Modell geprüft wird, lässt sich feststellen, ob die benötigten Begriffe und Regeln darin vorkommen. Fehlen sie, wird die Lücke benannt statt mit einer plausibel klingenden Antwort überdeckt.

Diese Lücke wird als Pflegeauftrag ausgegeben: Für die gestellte Frage fehlt ein Begriff, eine Beziehung oder eine Regel. Wird sie einmal fachlich beschrieben, ist die Frage anschließend beantwortbar – und mit ihr jede gleichartige Frage danach.

Zur Ehrlichkeit gehört die Abgrenzung: Zuverlässig erkennbar ist der Fall, dass ein Begriff im Modell fehlt. Nicht erkennbar ist der Fall, dass ein Begriff zwar beschrieben, aber fachlich falsch beschrieben ist – dann kommt eine Antwort heraus, die dieser Beschreibung entspricht. Genau deshalb führt jede Antwort ihr Regelset mit, und genau deshalb ist die fachliche Validierung Teil der Einführung.

Für eine technische Prüfung ist das der wichtigere Teil der Aussage: Nicht dass das System viel kann, sondern dass die Grenze seines Wissens sichtbar gemacht wird, statt sie zu überdecken. Wie belastbar das in echten Tests war, steht mit allen Fehlfällen auf der Praxisseite.

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.

Das System ist nicht an ein einzelnes Sprachmodell gebunden. Vorausgesetzt wird ein Modell, das mehrschrittig arbeiten kann: Es muss eine Frage in Schritte zerlegen, das semantische Modell erkunden, Zwischenergebnisse bewerten und den Abfrageplan gegebenenfalls korrigieren.

Genau daran hängt die Antwortqualität, und der Unterschied ist deutlich: Kleinere Reasoning-Modelle liefern brauchbare, aber merklich schwächere Ergebnisse. Belastbar wurde es erst mit aktuellen Spitzenmodellen – dort tragen auch Fragen, die über mehrere Fachbereiche hinweg gehen.

Konkrete Modellversionen werden hier absichtlich nicht genannt: Sie wechseln in kurzen Abständen, und eine veraltete Angabe auf dieser Seite wäre irreführend. Welches Modell in Ihrem Fall angebunden wird, gehört in die Einführung – zusammen mit der Frage nach Vertrag und Datenverwendung.

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.