KI & Unternehmensdaten
Fragen Sie Ihre Unternehmensdaten.
Nicht Ihre Tabellen.
Bestehende Unternehmenssoftware enthält enormes Wissen. Gerling Solutions macht Datenmodell, Sourcecode und fachliche Zusammenhänge für KI verständlich – ohne dass Anwender Tabellen, Spalten oder SQL kennen müssen.
| Kunde | Aufträge |
|---|---|
| Kunde A | 4 |
| Kunde B | 3 |
Das Problem
Ihr Unternehmen hat die Daten bereits. Die KI versteht sie nur nicht.
Ein Sprachmodell kennt die Welt, aber nicht Ihr Datenmodell: nicht die Bedeutung Ihrer Felder, nicht die Regeln hinter Ihren Begriffen, nicht die Zusammenhänge zwischen Ihren Systemen. Genau dieses Wissen steckt in Sourcecode und Datenbank – und wird hier nutzbar gemacht.
Fragen statt Reports
Fragen, die Ihre Daten heute schon beantworten könnten.
Schematische Darstellung an einem kaufmännischen Standardfall. Begriffe und Werte sind Beispiele; in Ihrem System stehen dort Ihre eigenen Fachbegriffe.
| Kunde | Aufträge |
|---|---|
| Kunde A | 4 |
| Kunde B | 3 |
| Kunde C | 2 |
| Kunde | Offen seit | Betrag |
|---|---|---|
| Kunde D | 62 Tage | 18.400 € |
| Kunde E | 41 Tage | 7.150 € |
Wie es funktioniert
Aus Sourcecode und Datenmodell wird ein fachliches Modell.
Datenbank und Sourcecode Ihres Systems werden analysiert. Aus Tabellen, Beziehungen, Berechnungen und Geschäftsregeln entsteht ein Modell, das beschreibt, was Ihre Daten fachlich bedeuten: welcher Begriff auf welche Struktur zeigt, welche Regeln gelten und wie Informationen zusammenhängen.
Dieses Modell ist die Schnittstelle für KI-Systeme – erreichbar über MCP oder eine Chat-Oberfläche. Ihre bestehenden Systeme bleiben unverändert; es wird nichts migriert und nichts umgebaut.
Beispiel: Claude Desktop
Ihre Fachabteilung fragt in Claude Desktop. Geantwortet wird aus Ihrer Datenbank.
MCP – das Model Context Protocol – ist ein offener Standard, über den KI-Anwendungen externe Werkzeuge und Datenquellen anbinden. Gerling Solutions stellt das semantische Modell Ihres Systems als MCP-Server bereit; erprobt ist derzeit die Anbindung von Claude Desktop, weitere Clients sind durch den offenen Standard möglich.
Für den Anwender bleibt es ein Chat. Neu ist, worüber er sprechen kann: nicht mehr nur über Allgemeinwissen, sondern über die Aufträge, Kunden und Rechnungen im eigenen Haus – ohne Tabelle, ohne SQL, ohne vorgebauten Report.
Zwei Betriebsmodi
Sie entscheiden, ob Abfrageergebnisse Ihr Netz überhaupt verlassen.
Eigene Oberfläche
Das Sprachmodell sieht nur die Beschreibung des semantischen Modells – Begriffe, Beziehungen, Regeln. Die Abfrageergebnisse bleiben im Haus.
Externe KI-Anwendung über MCP
Ihre Fachabteilung arbeitet in der gewohnten Anwendung. Deren Modell übernimmt das Reasoning und sieht dabei auch die Abfrageergebnisse, weil es sie bewerten muss.
Wenn Abfrageergebnisse das Unternehmen nicht verlassen dürfen, ist Modus 1 der Weg. Was genau in welchem Modus hinausgeht, steht vollständig aufgeschlüsselt auf der Sicherheitsseite.
Kontrollierter Datenzugriff
Das Sprachmodell denkt. Abfragen führt es nicht selbst aus.
Zwischen Modell und Datenbank liegt immer eine Vermittlungsschicht in Ihrer Infrastruktur.
Jede Anfrage und jede Antwort geht durch diese Schicht. Das Modell erhält keine Zugangsdaten, keine Netzwerkverbindung und keine Kenntnis Ihrer Tabellenstruktur – es erzeugt kein SQL.
Stattdessen formuliert es einen Abfrageplan in den Begriffen des semantischen Modells. Enthält dieser Plan Begriffe, Beziehungen oder Berechtigungen, die das Modell nicht kennt oder die Rolle nicht haben darf, wird er nicht ausgeführt. Erst danach übersetzt das System den Plan in eine lesende Datenbankabfrage.
Was das Modell dabei leistet
Aktuelle Modelle übersetzen eine Frage nicht in einem Zug, sondern arbeiten sie in Schritten ab. Erst das macht eine Frage wie diese beantwortbar – zwei Zeiträume, ein Vergleich, ein zweiter Fachbereich und eine Regel, die niemand als Spalte hinterlegt hat:
„Welche Kunden haben im letzten Quartal weniger bestellt als im Vorjahresquartal – und bei welchen davon sind Rechnungen offen?“
Entscheidend ist dabei, worauf das Modell zugreifen kann: auf die beschriebenen Begriffe, Beziehungen und Regeln – und nur auf diese. Es leitet die Bedeutung Ihrer Daten nicht aus Tabellen- und Spaltennamen ab.
Wer was beiträgt
Zerlegt die Frage in Schritte, wählt Begriffe, bewertet Zwischenergebnisse, korrigiert sich.
Weiß, was Ihre Begriffe bedeuten, welche Regeln gelten und wie Ihre Daten zusammenhängen.
Lässt nur zu, was im Modell beschrieben und für die Rolle freigegeben ist – und ausschließlich lesend.
Das Sprachmodell bringt Denkfähigkeit mit, aber kein Wissen über Ihr Unternehmen: Das Wissen liefert die semantische Schicht, die Grenzen zieht die Prüfschicht.
Herkunft jeder Antwort
Eine Zahl ohne prüfbare Herkunft ist keine Entscheidungsgrundlage.
Deshalb führt jede Antwort mit, wie sie zustande gekommen ist: das komplette Regelset – jede Regel mit ihrer fachlichen Definition –, die aufgelösten Begriffe und Stichtage und die ausgeführte Abfrage im Wortlaut. Nicht ausgewählte Auszüge, sondern das ganze Set: Solange eine beteiligte Regel unsichtbar bleibt, lässt sich das Ergebnis nicht beurteilen.
Damit ist eine Antwort nachrechenbar, statt geglaubt werden zu müssen. Wer das Ergebnis anzweifelt, kann die Regel benennen, die er für falsch hält, und sie korrigieren – danach ändert sich das Ergebnis überall gleichermaßen.
Das ist der praktische Unterschied zu einem Report: Ein Report zeigt eine Zahl. Hier steht daneben, wie sie definiert ist – und wer sie so definiert hat.
| Kennzahl | Wert |
|---|---|
| Offener Bestand | 412.900 € |
| Betroffene Rechnungen | 38 |
- Begriffe
- Rechnung, Zahlungseingang, Storno, Forderungsbestand – aufgelöst über das semantische Modell.
- Stichtag
- 30.06. – Quartalsende, aus der Frage abgeleitet.
- Rechnung gilt als offen
- Gestellt, nicht storniert, Zahlungseingang kleiner als Rechnungsbetrag – bewertet zum Stichtag.
- Teilzahlung
- Zählt als offener Restbetrag, nicht als offene Rechnung. Reduziert den Bestand, nicht die Anzahl.
- Stichtagsbewertung
- Zahlungseingänge nach dem Stichtag bleiben unberücksichtigt, auch wenn sie heute vorliegen.
- Forderungsbestand
- Summe der offenen Restbeträge ohne Mahngebühren und ohne Zinsen.
SELECT SUM(r.betrag - COALESCE(z.gezahlt, 0)) AS offen,
COUNT(*) AS anzahl
FROM rechnung r
LEFT JOIN zahlung_bis_stichtag z ON z.rechnung_id = r.id
WHERE r.gestellt_am <= DATE '2025-06-30'
AND r.storniert = false
AND r.betrag > COALESCE(z.gezahlt, 0)Wie das Modell entsteht
Das semantische Modell wird nicht von Hand geschrieben. Es wird KI-gestützt aus Ihrem System erschlossen.
Von Hand dauert das Wochen: Jede Tabelle, jede Beziehung, jede Regel müsste einzeln gelesen, verstanden und beschrieben werden. Genau daran scheitern solche Projekte üblicherweise, bevor sie etwas zeigen.
Deshalb wird KI hier nicht nur zum Abfragen eingesetzt, sondern schon beim Aufbau: Sourcecode und Datenmodell werden analysiert, um Fachbegriffe, Beziehungen und Regeln zu erschließen und die dazu passenden Abfrage- und Kontextdefinitionen zu erzeugen.
Ergebnis: Innerhalb weniger Stunden steht eine breite Basis, mit der sich echte Fragen stellen lassen.
Was das nicht heißt
Diese Basis ist ein Vorschlag, keine Wahrheit. Was KI aus Sourcecode erschließt, kann unvollständig oder fachlich falsch benannt sein.
Und es heißt nicht, dass der Sourcecode dabei im Haus bleibt: Für die Analyse werden Code- und Strukturausschnitte an ein Sprachmodell übermittelt – heute an einen externen Anbieter. Was dabei übertragen wird, steht auf der Sicherheitsseite.
Deshalb ist der zweite Schritt die Validierung: Ihre Fachanwender stellen echte Fragen, die Antworten werden gemeinsam geprüft und das Modell nachgeschärft. Genau das ist der Kern der Pilotphase.
Und wie es wächst
Fehlende Begriffe sollen als Lücke sichtbar werden – nicht als plausible Antwort.
Weil jede Frage gegen ein explizit beschriebenes Modell geprüft wird, lässt sich feststellen, ob die nötigen Begriffe und Regeln darin vorkommen. Fehlen sie, ist das Verhalten des Systems, die Lücke als Pflegeauftrag zu benennen statt sie zu überdecken – und ist sie einmal fachlich beschrieben, gilt das für jede gleichartige Frage danach.
Das System wird also im Betrieb besser, und zwar nachvollziehbar: Jeder Zugewinn geht auf eine benannte Lücke und eine dokumentierte fachliche Entscheidung zurück. Die Liste offener Lücken ist damit zugleich eine ehrliche Prioritätenliste.
Gerling Solutions trainiert kein Modell – weder mit Ihren Daten noch mit Ihrem Sourcecode.
Nicht das Sprachmodell lernt, sondern das Modell Ihres Unternehmens wächst – als beschriebene, lesbare, überprüfbare Fachdefinition. Was der Anbieter des angebundenen Sprachmodells mit übermittelten Inhalten tun darf, regelt dessen Vertrag; das wird vor der Einführung geprüft und festgelegt. Zur Frage nach Modelltraining.
Entwicklungsstand
Das Produkt befindet sich aktuell in der Pilot- und Validierungsphase.
Im Einsatz
- PostgreSQL
- MySQL
- Sourcecode-Analyse
- Semantisches Modell
- Rollen & Rechte
- Eigene Oberfläche
- MCP-Server
- Anbindung Claude Desktop
- Komplexe Aggregationen
- Vollständige Protokollierung
In Arbeit
- Dokumentenanbindung
- Weitere Datenquellen
- Automatisierte Validierung
- Vollständig lokal betriebenes Modell
Validierung
Geprüft an einem gewachsenen Produktivsystem und an drei fremden Systemen.
27 von 31 fachlich bewertbaren Testfragen verhielten sich wie vorgesehen – einschließlich der Fälle, in denen das System eine Antwort begründet verweigert hat. Zur Gegenprobe wurden 30 Abfrageszenarien an 3 unabhängigen Systemen mit MySQL und PostgreSQL geprüft.
verhielten sich im Referenztest fachlich wie vorgesehen.
Abfrageszenarien ohne offenen strukturellen Befund.
Einführung & Lizenz
Individuelle Einführung und monatliche Plattformlizenz.
Umfang und Aufwand der Einführung hängen von Datenmodell, Sourcecode und den Fragestellungen ab. Deshalb wird der Rahmen im Gespräch geklärt, statt ihn hier zu pauschalieren.
Vertiefende Themen
Einzelne Fragen, jeweils auf einer eigenen Seite beantwortet.
Diese Seite beschreibt das Produkt im Zusammenhang. Wer mit einer konkreten Frage gekommen ist – zur Datenbank, zum Betrieb, zum Datenschutz oder zur Anbindung –, findet sie hier einzeln beantwortet.
KI für Unternehmensdaten
Vier Wege, KI auf eigene Unternehmensdaten zu bringen – und woran sie in der Praxis scheitern.
Datenbank mit KI abfragen
Von der Frage zur belegten Zahl: Abfrageplan, Prüfung gegen das Fachmodell, lesende Abfrage.
Semantische Schicht
Begriffe, Beziehungen, Regeln: das Artefakt, das einer KI die Bedeutung Ihrer Daten erklärt.
Beantwortbare Fragen
Echte Fragen nach Fachbereich – und was jede davon an Definitionen voraussetzt.
KI in bestehende Software integrieren
Keine Migration, keine zweite Datenhaltung, kein Umbau: Was bei einer Anbindung tatsächlich passiert.
KI für Legacy-Software
Gewachsene Systeme sind nicht das Hindernis. Sie sind der Grund, warum es ohne semantische Schicht nicht geht.
PostgreSQL & MySQL mit KI abfragen
Lesender Zugang, gewachsene Schemata, Historisierung: die Datenbankseite der semantischen Schicht.
MCP für Unternehmensdaten
Warum ein MCP-Server über einem Fachmodell etwas anderes ist als ein SQL-Tool am Protokoll.
Claude mit Unternehmensdaten verbinden
Was in Claude Desktop passiert, was das Modell dabei sieht und was das Unternehmen nicht verlässt.
Sicherer KI-Datenbankzugriff
Warum das Sprachmodell keine Zugangsdaten erhält und die Grenze in der Architektur liegt, nicht im Prompt.
Self-hosted KI
Komponente für Komponente: was in Ihrer Infrastruktur läuft und was heute noch nicht.
Dienstleistung · IT-Architektur
Das Produkt entstand aus der Architekturarbeit an gewachsenen Systemen.
Unabhängig vom Produkt übernimmt Gerling Solutions Verantwortung für IT-Architektur, Systemklärung, Modernisierung und Umsetzung – häufig genau die Grundlage, auf der KI in einem Unternehmen überhaupt zuverlässig arbeiten kann.
Aktuell werden wenige Unternehmen als Pilotkunden aufgenommen. Lassen Sie uns prüfen, ob Ihr System dafür passt.