Integration in bestehende Systeme
KI in bestehende Unternehmenssoftware integrieren – ohne sie umzubauen.
Der Reflex bei KI-Vorhaben ist ein Projekt: Schnittstellen bauen, Daten exportieren, eine Plattform daneben stellen. Genau das ist hier nicht nötig – die Schicht liegt über Ihren Systemen und lässt sie unverändert.
Ausgangspunkt
Die teuerste Annahme ist, dass die Daten erst umziehen müssen.
Der klassische Weg zu Auswertungen führt über eine zweite Datenhaltung: Daten werden exportiert, transformiert und in ein Zielsystem geladen. Ab dann existieren zwei Wahrheiten, ein Ladeprozess, der nachts durchlaufen muss, und ein Zeitversatz, den niemand mehr erklären kann.
Für eine KI, die operative Fragen beantworten soll, ist dieser Umweg nicht nötig. Was fehlt, ist keine zweite Datenhaltung, sondern eine Beschreibung dessen, was die vorhandenen Daten fachlich bedeuten.
Die semantische Schicht liegt neben Ihrem System, nicht darin – und sie liest, statt zu übernehmen.
Auswirkung
Was sich in Ihrer Systemlandschaft ändert – und was nicht.
Diese Aufstellung ist der Kern der Integrationsfrage. Sie ist auch der Teil, der in einer technischen Prüfung zuerst geklärt wird.
- Ihre Anwendungen
- Unverändert. Es wird kein Code Ihrer Software angepasst, kein Deployment geändert und keine Bibliothek eingebunden.
- Ihr Datenbankschema
- Unverändert. Es werden keine Tabellen, Spalten, Trigger oder Views angelegt, die Ihr System betreffen.
- Ihr Datenbestand
- Bleibt an seinem Platz. Keine Replikation, keine Synchronisation, kein Import. Einzelne Abfrageergebnisse werden dagegen verarbeitet und – abhängig von der vereinbarten Protokollierung – gespeichert.
- Neu hinzu
- Das semantische Modell samt Vermittlungs- und Prüfschicht. Diese Komponenten laufen als eigener Dienst; auf Wunsch vollständig in Ihrer Infrastruktur.
- Benötigte Zugänge
- Ein ausschließlich lesender Datenbankbenutzer und lesender Zugriff auf den Sourcecode, üblicherweise per Git.
- Betroffene Nutzerkonten
- Keine. Rollen und Rechte für die Abfrage werden im semantischen Modell abgebildet; Ihre bestehende Benutzerverwaltung bleibt unberührt.
Passende Systeme
Woran sich sinnvoll anbinden lässt.
Gemeinsames Merkmal: Die Fachlogik gehört Ihnen, und Sie kommen an Datenbank und Sourcecode.
Eigenentwickelte Unternehmenssoftware
Der klarste Fall. Datenmodell und Regeln liegen vollständig in Ihrer Hand, der Sourcecode ist verfügbar – damit lässt sich das semantische Modell breit erschließen.
Stark angepasste Standardsoftware und ERP-Systeme
Wenn über die Jahre eigene Felder, eigene Tabellen und eigene Auswertungslogik dazugekommen sind, steckt genau dort das Wissen, das ein Hersteller-Assistent nicht kennt. Voraussetzung ist ein lesender Zugang zur Datenbank.
Fachliche Zusatzsysteme rund um den Kern
Konfiguratoren, Planungswerkzeuge, Zeiterfassung, selbst gebaute Portale: oft klein, oft entscheidend für die interessanten Fragen – und meist ohne eigenes Berichtswesen.
Mehrere Systeme mit gemeinsamen Begriffen
Begriffe aus verschiedenen Systemen lassen sich im semantischen Modell aufeinander beziehen, sodass Fragen über Systemgrenzen hinweg beantwortbar werden. Umgesetzt ist dies derzeit für relationale Datenbanken; weitere Datenquellen sind in Arbeit.
Grenzen
Wo der Ansatz heute nicht greift.
Bei einer unveränderten SaaS-Standardinstallation ohne Zugriff auf Datenbank und Sourcecode. Ohne diese beiden Quellen gibt es nichts, woraus sich ein fachliches Modell erschließen ließe – und ohne lesenden Datenbankzugang keine Möglichkeit, eine Frage zu beantworten.
Bei Systemen ohne eigene relationale Datenbank. Umgesetzt und im Einsatz sind derzeit PostgreSQL und MySQL. Andere Datenbanksysteme werden pro Projekt bewertet, statt sie hier pauschal zuzusagen.
Und bei Fragen, die vor allem in Dokumenten stehen statt in Datensätzen. Die Anbindung von Dokumenten ist in Arbeit und heute nicht Teil des Leistungsstands.
Ablauf
Was bei einer Anbindung tatsächlich passiert.
Kein Migrationsprojekt, sondern eine Analyse, ein Modell und ein Dienst daneben.
- 1
Technische Sichtung
Blick auf Datenmodell und Sourcecode. Ergebnis ist eine ehrliche Einschätzung von Aufwand und Grenzen – und die Antwort, ob der Ansatz für Ihr System überhaupt passt.
- 2
Lesender Zugang wird eingerichtet
Ein eigener Datenbankbenutzer mit ausschließlich lesenden Rechten, auf Ihrer Seite eingerichtet und jederzeit von Ihnen entziehbar.
- 3
Semantisches Modell wird erschlossen
Sourcecode und Datenmodell werden KI-gestützt analysiert. Daraus entsteht in wenigen Stunden eine breite fachliche Basis statt eines leeren Modells.
- 4
Der Dienst wird bereitgestellt
Als MCP-Server für eine angebundene KI-Anwendung, über eine eigene Oberfläche oder beides. Erprobt ist derzeit der Weg über Claude Desktop.
- 5
Validierung im Betrieb
Ihre Fachanwender stellen echte Fragen, die Antworten werden gemeinsam geprüft und das Modell nachgeschärft. Das ist der eigentliche Aufwand – und der Teil, der über die Qualität entscheidet.
Warum ohne Umbau
Weil Lesen keine Änderung an Ihrem System verlangt.
Alles, was das System tut, ist: Struktur und Sourcecode verstehen, daraus ein Modell bilden und zur Laufzeit lesende Abfragen stellen. Keiner dieser Schritte verlangt eine Änderung an Ihrer Software.
Der Nebeneffekt ist ein praktischer: Weil nichts in Ihre Systeme eingreift, ist die Anbindung reversibel. Wird der Datenbankbenutzer entzogen, ist der Zugang beendet – ohne Rückbau und ohne Spuren in Ihrer Anwendung.
Ein Vorhaben, das Ihre Systeme nicht anfasst, kann sie auch nicht destabilisieren.
Damit ändert sich die Risikofrage: Es geht nicht mehr darum, ob ein KI-Projekt den Betrieb gefährdet, sondern nur noch darum, wer welche Daten lesen darf. Diese Frage ist beantwortbar – über Rollen und Rechte im semantischen Modell.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Funktioniert das auch mit unserem ERP-System?
Entscheidend ist nicht der Produktname, sondern der Zugang: Gibt es eine relationale Datenbank, auf die ein lesender Benutzer eingerichtet werden kann, und kommen Sie an den Sourcecode Ihrer Anpassungen?
Bei über Jahre angepassten ERP-Installationen ist das häufig gegeben – und dort liegt meist auch der interessante Teil, weil Ihre eigenen Felder und Regeln von keinem Hersteller-Assistenten abgedeckt werden. Bei einer reinen SaaS-Instanz ohne Datenbankzugriff greift der Ansatz nicht.
- Warum wird Zugriff auf den Sourcecode benötigt?
Weil die wichtigsten Begriffe nicht in der Datenbank stehen. Ob ein Kunde als aktiv gilt, wie ein Status berechnet wird oder wie ein Storno behandelt wird, steht im Code – nicht als Spalte.
Ohne diese Quelle müsste jede Regel im Gespräch rekonstruiert werden. Das ist der Aufwand, an dem solche Vorhaben üblicherweise scheitern, bevor sie etwas zeigen.
- Beeinträchtigt das den laufenden Betrieb?
Der Zugriff ist lesend und erfolgt über einen eigenen Datenbankbenutzer. Damit lässt sich die Last auf Ihrer Seite mit den üblichen Mitteln begrenzen – bis dahin, den Zugriff auf eine Replik statt auf das Produktivsystem zu legen.
Wie das im konkreten Fall gelöst wird, gehört in die technische Sichtung. Eine pauschale Zusage zur Auswirkung auf Ihre Systemlast wäre an dieser Stelle nicht seriös.
- Wie kommen wir wieder heraus, wenn es nicht passt?
Indem Sie den lesenden Datenbankbenutzer und den Zugriff auf das Repository entziehen. Danach hat das System keinen Zugang mehr.
Weil in Ihren Anwendungen nichts geändert wurde, gibt es keinen Rückbau. Das semantische Modell ist eine Beschreibung Ihres Systems – es lässt sich löschen, ohne dass Ihre Software davon berührt wird.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
KI für Legacy- und Individualsoftware
Wenn das Fachwissen im Sourcecode steckt und die Dokumentation veraltet ist.
PostgreSQL & MySQL mit KI abfragen
Wie der lesende Datenbankzugang aussieht und was mit gewachsenen Schemata passiert.
MCP für Unternehmensdaten
Warum ein MCP-Server für Unternehmensdaten mehr können muss, als eine Datenbank durchzureichen.
Ob Ihr System passt, lässt sich in einem Gespräch und einem Blick auf das Datenmodell klären – nicht durch ein Vorprojekt.