Datenschutz & Datenzugriff
KI mit Unternehmensdaten: Datenschutz und sicherer Datenbankzugriff.
Die erste ernsthafte Frage bei KI auf Unternehmensdaten lautet nicht, was das System kann. Sie lautet: Was kann es nicht – und liegt diese Grenze in einer Anweisung oder in der Architektur?
Die Ausgangsfrage
Würden Sie einem Sprachmodell die Zugangsdaten Ihrer Datenbank geben?
Der schnellste Weg zu einer KI, die Unternehmensdaten auswertet, ist auch der riskanteste: dem Modell einen Datenbankzugang geben, es SQL erzeugen lassen und dieses SQL ausführen. Das ist in einem Nachmittag aufgesetzt und beantwortet die erste Frage überzeugend.
Problematisch wird es bei der zweiten. Ein Sprachmodell ist ein statistisches System – es liefert plausible Ausgaben, keine garantierten. Alles, was es tun darf, muss es also nicht dürfen, weil es sich richtig verhält, sondern weil es technisch nicht anders kann.
Eine Anweisung an ein Sprachmodell ist eine Bitte. Eine Prüfschicht, die nur Lesepläne übersetzt, ist eine Regel.
Risiko
Vier Probleme des direkten Datenbankzugriffs.
Die ersten beiden kosten Vertrauen in Zahlen. Die letzten beiden sind Sicherheitsprobleme.
Das Modell muss Bedeutung erraten
Es kennt Ihre Regel für „offene Rechnung“ nicht, erkennt Soft Deletes und Historisierung nicht als solche und wählt aus fünf Datumsspalten eine aus. Das Ergebnis ist keine Fehlermeldung, sondern eine plausible falsche Zahl.
Es gibt keine prüfbare Absicht
Nachvollziehbar ist nur die abgesetzte Abfrage, nicht die fachliche Annahme dahinter. Wer die Zahl anzweifelt, kann sie nicht widerlegen – es fehlt die Definition, gegen die man prüfen würde.
Die einzige Grenze sind Datenbankrechte
Ein lesender Benutzer verhindert Schäden am Datenbestand. Er verhindert nicht, dass jemand über eine geschickt formulierte Frage Daten zu sehen bekommt, die er fachlich nicht sehen darf – die Datenbank kennt Ihre Rollen nicht.
Schreibende Anweisungen bleiben technisch möglich
Solange das Modell Abfragen formuliert, entscheidet die Rechtevergabe allein darüber, was durchkommt. Eine Fehlkonfiguration auf dieser einen Ebene hat dann unmittelbar Wirkung auf Ihre Daten.
Die Architektur
Zwischen Modell und Datenbank liegt immer eine Vermittlungsschicht.
Das Sprachmodell erhält keine Zugangsdaten, keine Netzwerkverbindung zur Datenbank und keine Kenntnis Ihrer Tabellenstruktur. Es erzeugt kein SQL. Stattdessen formuliert es einen Abfrageplan in den Begriffen des semantischen Modells.
Dieser Plan geht durch eine Prüfschicht in Ihrer Infrastruktur. Enthält er Begriffe, Beziehungen oder Berechtigungen, die im Modell nicht existieren oder die die Rolle des Anwenders nicht haben darf, wird er abgelehnt. Erst danach übersetzt das System den Plan in eine lesende Datenbankabfrage.
Das Modell denkt. Es greift nicht selbst zu – und es kann den Punkt nicht beeinflussen, an dem die Grenze gezogen wird.
Der praktische Unterschied zeigt sich im Fehlerfall: Ein Modell mit SQL-Zugang, das etwas missversteht, setzt eine falsche Abfrage ab. Ein Modell mit Planzugang, das etwas missversteht, produziert einen Plan, der die Prüfung nicht besteht.
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.
Strukturelle Grenzen
Was das System nicht kann – unabhängig davon, was man es bittet.
Diese Punkte hängen nicht am Verhalten des Sprachmodells, sondern daran, was die Prüfschicht übersetzt.
- Daten ändern oder löschen
- Nicht möglich. Es werden ausschließlich lesende Abfragen ausgeführt; ein Plan, der etwas anderes beschreibt, wird nicht übersetzt.
- Unbekannte Strukturen abfragen
- Nicht möglich. Was nicht im semantischen Modell beschrieben ist, kann in keinem Plan vorkommen, der die Prüfung besteht.
- Rollenrechte umgehen
- Die Rolle wird bei der Prüfung des Plans ausgewertet, nicht beim Anzeigen des Ergebnisses. Was eine Rolle nicht sehen darf, wird nicht abgefragt.
- Den Datenbestand kopieren
- Es gibt keine Replikation, keine Synchronisation und keinen Import. Einzelne Abfrageergebnisse werden dagegen verarbeitet und – abhängig von der vereinbarten Protokollierung – gespeichert.
- Unbemerkt arbeiten
- Die Protokollierung erfasst Frage, geprüften Plan und ausgeführte Abfrage. Sie liegt auf Ihrer Seite und ist Teil der Betriebsvereinbarung.
- In ein Training bei Gerling Solutions einfließen
- Gerling Solutions trainiert kein Modell – weder mit Ihren Daten noch mit Ihrem Sourcecode. Was wächst, ist die Beschreibung Ihres Fachmodells: eine lesbare Definition, kein Modellgewicht. Für das angebundene Sprachmodell gilt die Vertragslage seines Anbieters; sie wird vor der Einführung geprüft und festgelegt.
Datenschutz
Die entscheidende Frage ist, was das Unternehmen verlässt.
Es gibt zwei Betriebsmodi, und sie unterscheiden sich genau in diesem Punkt. Bei der eigenen Oberfläche sieht das Sprachmodell nur die Beschreibung des semantischen Modells – Begriffe, Beziehungen, Regeln – und die Abfrageergebnisse bleiben im Haus.
Wird eine externe KI-Anwendung angebunden, übernimmt deren Modell das Reasoning und sieht dabei auch Abfrageergebnisse, weil es sie bewerten muss. Was der jeweilige Anbieter mit übermittelten Daten vertraglich darf, steht in dessen Bedingungen – dazu wird hier bewusst keine Zusage gemacht.
Wenn Abfrageergebnisse das Unternehmen nicht verlassen dürfen, ist die eigene Oberfläche der Weg.
Diese Website enthält bewusst keine Compliance-Aussagen, die nicht belegt werden können: keine Zertifizierungen, die nicht vorliegen, und keine pauschale Konformitätserklärung. Die Datenschutzfolgenabschätzung für den Einsatz in Ihrem Haus bleibt Ihre – die Architektur ist darauf ausgelegt, sie beantwortbar zu machen.
Weiterlesen
Diese Seite ist der Einstieg. Die Prüfliste steht auf der Sicherheitsseite.
Hier stand die architektonische Begründung. Für eine technische Freigabe braucht Ihre IT-Sicherheit mehr: wo die Daten laufen, welche Rechte der Dienst benötigt, was in welchem Modus hinausgeht, wie protokolliert wird und was zum Thema Modelltraining gilt.
Diese Fragen sind auf einer eigenen Seite einzeln beantwortet – mit dem ausdrücklichen Hinweis, welche Punkte pro Projekt festgelegt werden und nicht standardisiert zugesagt sind.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Reicht nicht ein lesender Datenbankbenutzer als Schutz?
Gegen Schäden am Datenbestand: ja. Gegen falsche Zahlen und gegen Einsicht in Daten, die jemand fachlich nicht sehen darf: nein. Die Datenbank kennt Ihre Rollen und Ihre fachlichen Regeln nicht – sie kennt nur Tabellen und Rechte.
Der lesende Benutzer ist deshalb die untere Schranke, nicht die Sicherheitsarchitektur. Darüber liegen das semantische Modell, das die abfragbaren Strukturen begrenzt, und die Rollenprüfung im Abfrageplan.
- Was passiert, wenn die Prüfschicht selbst einen Fehler hat?
Dann greift die darunterliegende Schranke weiter: Der Datenbankbenutzer ist ausschließlich lesend und auf die fachlich benötigten Bereiche begrenzbar. Ein Fehler in der Prüfung kann damit keine Schreiboperation und keinen Zugriff auf nicht freigegebene Bereiche ermöglichen.
Das ist der Grund für die Schichtung: Keine der Ebenen ist alleine ausreichend, und keine ist alleine verantwortlich. Für eine Bewertung im Detail gehört das in die technische Prüfung – nicht in eine Zusicherung auf einer Website.
- Wie können wir überprüfen, dass das System sich so verhält?
Über die Protokollierung und über die Herleitung jeder Antwort. Protokolliert werden Frage, geprüfter Plan und ausgeführte Abfrage; jede Antwort führt zusätzlich das vollständige Regelset und die Abfrage im Wortlaut mit.
Damit ist nicht nur das Ergebnis prüfbar, sondern auch der Weg dorthin. Wer eine Zahl anzweifelt, kann die Regel benennen, die er für falsch hält – und wer den Zugriff prüfen will, sieht, welche Abfrage tatsächlich gelaufen ist.
- Wie beenden wir den Zugriff im Zweifelsfall sofort?
Indem Sie den lesenden Datenbankbenutzer entziehen. Er wird auf Ihrer Seite angelegt und gehört Ihnen; ohne ihn gibt es keine Verbindung zu Ihren Daten.
Weil in Ihren Anwendungen nichts geändert wurde, ist damit kein Rückbau verbunden. Das ist der Vorteil eines Ansatzes, der ausschließlich liest und neben Ihren Systemen liegt.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
Self-hosted KI für Unternehmensdaten
Welche Komponente wo läuft – und welcher Teil heute noch extern ist.
MCP für Unternehmensdaten
Warum ein MCP-Server für Unternehmensdaten mehr können muss, als eine Datenbank durchzureichen.
Datenbank mit KI abfragen
Der Weg einer Frage bis zur belegten Zahl – und warum geprüft wird, bevor gelesen wird.
Wenn Ihre IT-Sicherheit eine Aussage schriftlich braucht: Fragen Sie konkret nach, statt eine allgemeine Broschüre zu lesen.