KI trifft Unternehmensdaten
Kontrollierte Anbindung eines KI-Agenten an Unternehmensdaten über MCP
Architektur, Datenzugriff und Sicherheitsaspekte am Beispiel von Claude Code und einem MCP-Server
Autor: Christian Drapatz
Disclaimer
Die Inhalte dieser Website basieren auf eigenen Erfahrungen sowie auf öffentlich zugänglichen Quellen wie Dokumentationen, Schulungen, Videos und Community-Beiträgen. Alle Inhalte wurden eigenständig aufbereitet, zusammengefasst und in eigenen Worten formuliert. Es erfolgt keine wörtliche Übernahme geschützter Inhalte. Die bereitgestellten Tutorials sind kostenlos und dienen ausschließlich der Wissensvermittlung. Trotz sorgfältiger Erstellung kann keine Gewähr für Vollständigkeit oder Aktualität übernommen werden. Alle genannten Marken, Produkte und Technologien gehören den jeweiligen Inhabern. Die verwendete Krankenkasse „Atomium" ist fiktiv und dient ausschließlich zu Demonstrationszwecken. Alle Personen- und Versichertendaten sind erfunden.
1 Vorwort
Künstliche Intelligenz hält zunehmend Einzug in betriebliche Abläufe. Mit KI-Agenten wie Claude Code entsteht der Wunsch, interne Unternehmensdaten nicht nur anzuzeigen, sondern gezielt abzufragen, fachlich einzuordnen und mit weiteren Informationen zu verknüpfen.
Gerade bei besonders schützenswerten Daten – etwa Gesundheits-, Sozial- oder Versicherungsdaten – darf ein solcher Zugriff jedoch niemals unkontrolliert erfolgen. Dieses Dokument zeigt am Beispiel eines MCP-Servers, wie sich ein KI-Agent kontrolliert an eine Unternehmensdatenbank anbinden lässt, welche Komponenten dabei zusammenwirken und welche Sicherheits- und Architekturüberlegungen maßgeblich sind.
Es richtet sich an Entwickler, Softwarearchitekten und technisch interessierte Leser, die einen praxisnahen Einstieg in die kontrollierte Datenanbindung von KI-Agenten suchen.
Wichtig: Um die Datenschutzanforderungen der DSGVO besser erfüllen zu können, kann der Einsatz eines lokalen KI-Modells sinnvoll sein, beispielsweise über Ollama mit einem Modell wie Gemma 4. In diesem Fall verbleiben die Daten innerhalb der eigenen Infrastruktur und müssen nicht an externe KI-Dienstleister übertragen werden.
Dieses Beispiel konzentriert sich ausschließlich auf den MCP-Server und dessen Anbindung an bestehende Unternehmenssysteme. Das Model Context Protocol (MCP) ist ein offener Standard und nicht an einen bestimmten KI-Anbieter gebunden. Daher kann derselbe MCP-Server sowohl mit Claude Code als auch mit anderen MCP-fähigen KI-Anwendungen oder lokalen Lösungen wie Ollama genutzt werden.
Weitere Tutorials: Wer lokale KI-Systeme einsetzen möchte, findet auf dieser Seite eigene Anleitungen dazu. Das Tutorial Ollama & Gemma 4 zeigt, wie ein lokales Sprachmodell auf dem eigenen Rechner eingerichtet wird. Das Tutorial Claude Code + Ollama + Gemma 4 erklärt, wie Claude Code mit einem lokalen Modell verbunden und genutzt werden kann.
2 Ausgangssituation
Für den Zugriff auf die Daten aus der Unternehmensdatenbank existiert bereits eine Softwarelösung. Diese Anwendung ermöglicht es, Versicherte anhand bestimmter Suchkriterien zu finden und die dazugehörigen Daten strukturiert anzuzeigen.
Die bestehende Software steht für den klassischen Ansatz: Daten werden fachlich aufbereitet und in einer Oberfläche für Anwender bereitgestellt. In einer produktiven Umgebung greift eine solche Anwendung üblicherweise nicht direkt auf die Datenbank zu, sondern über ein Backend-System, das Authentifizierung, Berechtigungsprüfung und Fachlogik kapselt. Für diese Demonstration wird der Zugriff bewusst vereinfacht und direkt auf der Datenbankebene betrachtet, um den Fokus auf die wesentlichen Funktionen und Abläufe zu legen.
Bestehende macOS-Anwendung mit direktem Datenbankzugriff
Der neue Ansatz mit einem KI-Agenten und einem MCP-Server ersetzt diese Software nicht, sondern erweitert das bestehende Prinzip um eine zusätzliche Zugriffsmöglichkeit: Daten lassen sich gezielt abfragen, fachlich einordnen und mit weiteren Informationen kombinieren. Der Zugriff bleibt dabei kontrolliert und erfolgt ausschließlich über definierte Schnittstellen.
Für die Demonstration wurde eine vollständige Beispielumgebung aufgebaut, die den Zugriff eines KI-Agenten auf Unternehmensdaten über das Model Context Protocol (MCP) zeigt. Folgende Komponenten wurden umgesetzt:
- Aufbau einer Krankenkassen-Datenbank
Erstellung eines Datenmodells mit Beispieltabellen und Testdaten. Ablage von Versicherten-, Vertrags- und Stammdaten zur Demonstration typischer Geschäftsprozesse. - Entwicklung eines Krankenkassensystems für macOS
Programmierung einer nativen macOS-Anwendung mit direkter Anbindung an die Datenbank. Umsetzung einer grafischen Benutzeroberfläche zur Anzeige und Verwaltung der Daten. - Implementierung typischer Fachfunktionen
Datensätze suchen, anlegen, bearbeiten und löschen. Stammdaten verwalten. Datenbankinhalte anzeigen und aktualisieren. - Entwicklung eines MCP-Servers
Implementierung eines eigenen MCP-Servers. Anbindung des MCP-Servers an die Krankenkassen-Datenbank. Bereitstellung definierter Werkzeuge (Tools) für Datenabfragen. Kapselung der Datenbankzugriffe über eine kontrollierte Schnittstelle. - Anbindung eines KI-Agenten (Claude Code)
Verbindung von Claude Code mit dem MCP-Server. Nutzung der vom MCP-Server bereitgestellten Werkzeuge durch den KI-Agenten. Durchführung von Datenabfragen und Geschäftsprozessen über natürliche Sprache.
Ziel der Demonstration ist es zu zeigen, wie bestehende Unternehmensanwendungen, Datenbanken und KI-Agenten über das Model Context Protocol miteinander verbunden werden können, ohne der KI einen direkten Zugriff auf die Datenbank gewähren zu müssen.
3 Herausforderungen und Risiken
Die größte Herausforderung besteht darin, einem KI-Agenten Zugriff auf Unternehmensdaten zu geben, ohne daraus einen unkontrollierten Datenzugang entstehen zu lassen. Gerade bei besonders schützenswerten Daten, zum Beispiel Gesundheits-, Sozial- oder Versicherungsdaten, reicht eine rein technische Anbindung nicht aus. Der Zugriff muss fachlich, rechtlich und technisch klar begrenzt werden.
Ein zentrales Risiko ist, dass der KI-Agent mehr Daten erhält, als für die konkrete Aufgabe notwendig sind. Deshalb muss strikt geregelt werden, welche Daten überhaupt verfügbar sind, welche Felder ausgeblendet oder maskiert werden und welche Abfragen erlaubt sind. Der Grundsatz sollte immer lauten: so wenig Daten wie möglich, so viele wie nötig.
Ein weiteres Risiko liegt in falschen oder zu weit gefassten Abfragen. Wenn ein Agent beliebige SQL-Abfragen ausführen könnte, wären Massenabfragen oder unbeabsichtigte Datenabflüsse möglich. Deshalb sollte der Zugriff nicht direkt auf Tabellen erfolgen, sondern nur über freigegebene Views, Stored Procedures oder klar definierte MCP-Funktionen.
Auch die Nachvollziehbarkeit ist eine wichtige Herausforderung. Es muss jederzeit erkennbar sein, welcher Nutzer welche Anfrage gestellt hat, welches Tool verwendet wurde und welche Daten abgerufen wurden. Ohne Audit-Logging lassen sich Fehler, Missbrauch oder Datenschutzvorfälle später kaum sauber bewerten.
Zusätzlich besteht das Risiko, dass sensible Daten in Prompts, Logs oder KI-Antworten landen. Deshalb müssen Eingaben und Ausgaben geprüft, sensible Inhalte maskiert und Protokolle datensparsam geführt werden. Besonders kritisch ist auch die Frage, ob Daten an externe KI-Anbieter übertragen werden oder ob die Verarbeitung vollständig in einer kontrollierten Umgebung erfolgt.
Ein KI-Agent kann sehr hilfreich sein, aber er darf nicht wie ein normaler Datenbanknutzer mit breiten Rechten behandelt werden. Er braucht eine eigene Sicherheitsschicht mit klaren Regeln, begrenzten Funktionen, Rollenprüfung, Protokollierung und technischer Zugriffsbeschränkung.
Kurz gesagt: Der Nutzen liegt in der intelligenten Verarbeitung und Verknüpfung von Unternehmensdaten. Das Risiko liegt darin, dass ohne klare Grenzen besonders schützenswerte Daten ungewollt offengelegt, falsch verarbeitet oder nicht mehr nachvollziehbar genutzt werden.
4 Anbindung eines KI-Agenten an Unternehmensdatenbanken über MCP
Im Folgenden wird betrachtet, wie ein KI-Agent, zum Beispiel Claude Code, kontrolliert mit Unternehmensdatenbanken verbunden werden kann, um interne Daten gezielt abzufragen und weiterzuverarbeiten.
Ein einfaches Beispiel wäre:
„Zeige mir die Adressen zur KVNR K145145875."
Damit ein KI-Agent solche Anfragen bearbeiten kann, benötigt er Zugriff auf die passenden Unternehmensdaten. Statt diese fest in den Kontext einzubetten, wird der Agent über eine standardisierte Schnittstelle an die Datenquelle angebunden. Dafür eignet sich das Model Context Protocol (MCP), ein offenes Protokoll, über das ein KI-Agent externe Werkzeuge und Datenquellen in einheitlicher Form ansprechen kann.
Der MCP-Server stellt dem Agenten eine Reihe klar definierter Funktionen (Tools) bereit. Der Agent ruft diese Funktionen auf, erhält aber zu keinem Zeitpunkt direkten Zugriff auf die zugrunde liegende Datenbankstruktur. Welche Daten gelesen werden und wie der Zugriff erfolgt, bestimmt allein der MCP-Server.
Architektur: KI-Agent → MCP-Server → Datenbank
5 Aktueller technischer Stand (Test-Szenario)
Aktuell existiert ein MCP-Server als Testaufbau. Er verbindet sich über einen Datenbankbenutzer mit ausschließlich lesenden Rechten (Read-only) mit der Datenbank. Schreibende Operationen sind damit bereits auf Berechtigungsebene ausgeschlossen.
Die Zugriffe erfolgen nicht direkt auf produktive Tabellen, sondern ausschließlich über freigegebene Datenbank-Views. Über die Definition dieser Views wird gesteuert, welche Spalten und Datensätze überhaupt sichtbar sind; sensible Felder lassen sich so ausblenden oder maskieren. Auf diese Weise bleiben Datenbankstruktur, Datenschutz und Zugriffsrechte kontrollierbar, ohne dass der Agent die darunterliegende Tabellenstruktur kennt.
Die vom MCP-Server bereitgestellten Funktionen sind bewusst eng zugeschnitten. Die Adressabfrage erwartet beispielsweise genau eine konkrete KVNR als Parameter; sie gibt nur die zu dieser einen Versichertennummer gehörenden Adressdaten zurück.
Technischer Aufbau: MCP-Server mit Read-only-Datenbankbenutzer und Views
Dadurch ist eine Massenabfrage wie:
„Gib mir alle Adressen zurück."
technisch nicht vorgesehen. Stattdessen sind nur gezielte Einzelabfragen möglich, zum Beispiel:
„Lade alle Adressen zur KVNR B000003310."
6 Beispiel für eine erweiterte KI-Abfrage
Durch die Kombination aus KI-Agent und MCP-Server können Unternehmensdaten mit weiteren Informationen verknüpft und fachlich bewertet werden.
Beispiel-Prompt:
Lade alle Adressen zur KVNR B000003310. Prüfe für jede Postleitzahl, ob dort am gestrigen Tag starke Windereignisse aufgetreten sind, und gib das Ergebnis je Adresse kurz aus.
Dieses Beispiel zeigt, dass der KI-Agent die über den MCP-Server abgerufenen Unternehmensdaten mit einer externen Wetterdatenquelle kombiniert und das Ergebnis fachlich aufbereitet – ohne jemals direkten Datenbankzugriff zu erhalten.
7 Beispielergebnis
Für die KVNR B000003310 wurde die versicherte Person Karin Bauer gefunden. Zur Person ist eine Hauptadresse hinterlegt: Lindenallee 142, 45879 Gelsenkirchen. Diese Adresse ist seit dem 24.10.2023 gültig.
Für die Postleitzahl 45879 in Gelsenkirchen, NRW wurde geprüft, ob am 13.05.2026 starke Windereignisse aufgetreten sind. Die Prüfung ergab Hinweise auf Windböen in der Region.
Bewertung:
- Am 13.05.2026 gab es Hinweise auf stärkere Windereignisse in der Region.
- Die Adresse liegt in einem potenziell betroffenen Gebiet.
- Das Ergebnis wurde je Adresse bewertet.
8 Fachliche Einordnung
Das Beispiel zeigt, dass ein KI-Agent nicht auf das reine Beantworten von Datenbankabfragen beschränkt ist. Er kann die über den MCP-Server abgerufenen Unternehmensdaten mit externen oder fachlichen Informationen verknüpfen und das Ergebnis aufbereiten.
Wichtig ist dabei, dass der Zugriff technisch begrenzt bleibt:
Jede Stufe dieser Kette schränkt den Zugriff weiter ein. Dadurch entsteht keine freie Datenbankschnittstelle für die KI, sondern eine kontrollierte Zugriffsschicht, deren Grenzen durch den MCP-Server und die Datenbankberechtigungen definiert sind.
Gesamte System-Architektur mit allen Schichten
MCP-Server Architektur im Detail
Datenbank-Architektur
Datenbank-Architektur mit Views und Berechtigungen
9 Fazit
Der aktuelle Prototyp zeigt, dass sich ein KI-Agent über einen MCP-Server kontrolliert an Unternehmensdaten anbinden lässt. Der Agent kann ausschließlich die definierten MCP-Funktionen aufrufen und die zurückgegebenen Ergebnisse fachlich weiterverarbeiten.
Gleichzeitig bleiben wichtige Schutzmechanismen erhalten:
- Kein direkter Tabellenzugriff
- Nur Read-only-Verbindung
- Zugriff ausschließlich über Views
- Maskierung sensibler Felder
- Keine Massenabfragen
- Nur definierte MCP-Funktionen
- Abfragen nur über konkrete KVNR
Damit lässt sich ein praxisnahes Szenario abbilden, bei dem KI Unternehmensdaten unterstützt verarbeitet, ohne der KI unbegrenzten Zugriff auf die Datenbank zu geben.
Ist keine direkte Datenbankanbindung vorgesehen, kann der MCP-Server stattdessen an bestehende Backend-Schnittstellen angebunden werden. Der KI-Agent spricht dann keine Datenbank an, sondern ruft MCP-Funktionen auf, die intern freigegebene Backend-Endpunkte (etwa REST-APIs) nutzen. Dieser Aufbau ist für den produktiven Einsatz in der Regel vorzuziehen, da die im Backend bereits vorhandenen Sicherheitsmechanismen – Authentifizierung, Rollenprüfung, Fachlogik, Logging und Maskierung – erhalten bleiben und wiederverwendet werden. Der MCP-Server wird in diesem Fall zu einer kontrollierten Brücke zwischen KI-Agent und bestehendem Backend.
Wichtig: In produktiven Umgebungen mit echten personenbezogenen Daten muss zwingend ein vollständiges Datenschutz- und Sicherheitskonzept (inkl. DSGVO-Prüfung, AVV mit KI-Anbietern und Rollenkonzept) vorliegen, bevor ein KI-Agent an Unternehmensdaten angebunden wird.