Claude und Copilot sind in Ihrem Dateisystem. Wer entscheidet, was sie sehen dürfen?

Irgendwann in den letzten zwölf Monaten sind KI-Assistenten in die Dateisysteme Ihres Unternehmens eingezogen. Vielleicht hat die IT dies genehmigt. Vielleicht hat eine Fachabteilung Microsoft Copilot im Rahmen einer M365-Einführung bereitgestellt. Vielleicht haben Mitarbeitende Claude oder ein anderes KI-Tool eigenständig mit ihren Arbeitslaufwerken verbunden.

Wie auch immer es geschah, das Ergebnis ist dasselbe: KI-Systeme rufen nun Unternehmensdateien im Auftrag von Mitarbeitenden ab – und in den meisten Unternehmen hat niemand explizit festgelegt, was diese KI-Systeme sehen dürfen. Die Zugriffssteuerungen, die den Zugriff von Menschen auf Dateien regeln, wurden nicht für KI-Akteure entwickelt. Die Prüfprotokolle, die menschlichen Dateizugriff erfassen, sind nicht so konfiguriert, dass sie KI-Abrufe mit dem für Compliance erforderlichen Attributionsdetail erfassen. Die Richtlinien, die festlegen, wer worauf zugreifen darf, wurden für Mitarbeitende geschrieben – nicht für KI-Systeme, die im Auftrag von Mitarbeitenden handeln.

Dieser Beitrag richtet sich an CISOs und Compliance-Beauftragte, die eine inzwischen operativ dringende Frage beantworten müssen: Wer entscheidet eigentlich, was KI-Assistenten in Ihrem Dateisystem sehen dürfen?

Executive Summary

Kernaussage: KI-Assistenten greifen auf Unternehmensdateisysteme zu, basierend auf Autorisierungsmodellen, die für menschliche Anwender entwickelt wurden – mit Zugriffsrechten, Sitzungsgrenzen und Audit-Trails, die für KI-Akteure strukturell unzureichend sind. Die Lücke zwischen dem, was Unternehmen glauben, dass ihre KI-Zugriffssteuerungen abdecken, und dem, was sie tatsächlich abdecken, ist erheblich, weitgehend unsichtbar und birgt direktes Compliance-Risiko.

Warum das relevant ist: Wenn eine Aufsichtsbehörde oder ein Auditor fragt, auf welche Dateien Ihre KI zugegriffen hat, wer jeden Abruf autorisiert hat und wie Sie nachweisen können, dass Sensitivitätsklassifizierungen durchgesetzt wurden – dann gibt es darauf nur Antworten, wenn Ihre KI-Integration so konzipiert wurde, dass sie diese liefert. Die meisten sind es nicht. Die Zeit, diese Lücke zu entdecken, ist vor einer Anfrage – nicht währenddessen.

5 Wichtige Erkenntnisse

1. KI-Assistenten, die auf Unternehmensdateisysteme zugreifen, laufen typischerweise unter Servicekonten mit Berechtigungen, die die Autorisierung jedes einzelnen Anwenders übersteigen – das bedeutet, die KI kann Dokumente abrufen, die der Mitarbeitende, der die Anfrage stellt, auf anderem Wege nicht einsehen dürfte.
2. Sitzungsbasierte Autorisierung ist nicht gleichzusetzen mit einer durchgängigen RBAC- und ABAC-Prüfung pro Anfrage. Es handelt sich um einen einzigen Kontrollpunkt, gefolgt von unüberwachtem Zugriff mit Maschinengeschwindigkeit.
3. Die meisten KI-Dateizugriffsprotokolle erfassen die Identität des Servicekontos, nicht den menschlichen Anwender, dessen Anfrage den Abruf ausgelöst hat. Das ist nicht nur eine Lücke im Logging – es ist eine HIPAA-Compliance-Lücke, eine DSGVO-Compliance-Lücke und eine Lücke bei forensischen Untersuchungen.
4. Datenklassifizierungen und Sensitivitätslabels, die auf Dateien angewendet werden, haben keinen Einfluss auf KI-Abrufe, sofern die KI-Integration sie nicht explizit auf der Abrufebene prüft. Ein KI-Assistent kann ein als Vertraulich oder Restriktiv markiertes Dokument genauso anzeigen wie ein unklassifiziertes.
5. Die Governance-Frage ist nicht, ob KI-Dateizugriff erlaubt werden soll – Mitarbeitende arbeiten damit produktiver, und eine Blockade fördert Schatten-KI. Die Frage ist, ob KI-Dateizugriff denselben Richtlinien, derselben Durchsetzung und demselben Audit-Trail unterliegt wie jeder andere Datenzugriff im Unternehmen.

Das Zugriffsmodell, das niemand genehmigt hat

Wenn ein Unternehmen einen KI-Assistenten mit Dateisystemzugriff bereitstellt, wird in der Regel ein Servicekonto konfiguriert, um die KI gegenüber dem Dateirepository zu authentifizieren. Dieses Servicekonto erhält Berechtigungen, die breit genug sind, um die gesamte Anwenderbasis zu bedienen – denn die KI muss jede Datei abrufen können, die ein Anwender legitim benötigt. Das Ergebnis ist ein einziges Zugangskonto mit Zugriff auf alles im Geltungsbereich, das von jedem Anwender genutzt wird, der mit der KI interagiert.

Kein Unternehmen würde absichtlich ein menschliches Nutzerkonto mit diesem Berechtigungsprofil anlegen. Ein geteiltes Konto mit Zugriff auf jede vertrauliche Datei im Repository, nutzbar durch jeden Mitarbeitenden, ohne individuelle Zugriffsbeschränkungen – das würde jede Identitäts- und Zugriffsmanagement-Prüfung, jede Risikoanalyse und jedes Compliance-Audit nicht bestehen.

Doch wenn dieselbe Berechtigungsstruktur für ein KI-Servicekonto umgesetzt wird, besteht sie häufig die Prüfung, weil sie wie Infrastruktur und nicht wie Zugriffspolitik aussieht. Die KI wird als System behandelt, nicht als Akteur, der im Auftrag von Anwendern Datenzugriffsentscheidungen trifft. Diese Unterscheidung hält keiner genaueren Prüfung stand – und schon gar nicht einer regulatorischen Anfrage.

Die praktische Folge: Ein KI-Assistent, der über ein Servicekonto mit einem Unternehmensdateisystem verbunden ist, kann Dokumente abrufen, die der Mitarbeitende, der die Anfrage stellt, nie hätte einsehen dürfen. Ein Junior-Analyst, der Claude bittet, das Wettbewerbsumfeld zusammenzufassen, erhält möglicherweise eine Antwort, die auf Dokumenten basiert, die über seine Freigabestufe hinausgehen. Ein Kundenservice-Mitarbeiter, der Copilot um die Kontohistorie bittet, kann versehentlich Dateien aus anderen Konten anzeigen. Die KI funktioniert dabei nicht fehlerhaft – sie tut genau das, wofür sie konfiguriert wurde. Das Zugriffsmodell wurde einfach nie dafür entwickelt, dies zu verhindern.

Sitzungsbasierte Autorisierung ist kein Zero-Trust. Es ist ein Perimeter mit nur einem Tor.

Die häufigste Governance-Reaktion auf Bedenken beim KI-Dateizugriff ist der Verweis auf Authentifizierung: Die KI wird authentifiziert, bevor sie sich verbindet, der Zugriff wird geprüft, die Sitzung wird innerhalb der Zero-Trust-Architektur des Unternehmens etabliert. Das stimmt – aber es reicht nicht aus.

Die Authentifizierung auf Sitzungsebene prüft, ob das KI-System zum Zeitpunkt des Sitzungsaufbaus auf das Dateirepository zugreifen darf. Sie prüft jedoch nicht, ob der konkrete Anwender, der die KI für eine bestimmte Anfrage steuert, tatsächlich berechtigt ist, auf die Datei zuzugreifen, die die KI abrufen soll. Ist die Sitzung einmal geöffnet, erben alle nachfolgenden Operationen die beim Verbindungsaufbau festgelegte Autorisierung – die KI kann alles abrufen, was das Servicekonto erreichen kann, für jeden Anwender, zu jedem Zweck, ohne eine weitere Autorisierungsprüfung.

Das ist so, als würde man am Gebäudeeingang die Identität eines Besuchers prüfen und ihm dann für die Dauer seines Aufenthalts uneingeschränkten Zugang zu allen Büros, Serverräumen und Vorstandsetagen gewähren. Die Erstprüfung fand statt. Alles danach ist implizites Vertrauen – genau das, was zero trust im Datenaustausch verhindern soll.

Für menschliche Anwender sind Sitzungssteuerungen eine akzeptable Annäherung an kontinuierliche Verifikation, weil menschliches Sitzungsverhalten durch das Arbeitstempo begrenzt ist. Ein KI-System kann jedoch in einer einzigen Sitzung Tausende Dateioperationen ausführen – Sitzungsautorisierung ist dann nur ein einzelner Kontrollpunkt, gefolgt von unüberwachtem Zugriff mit Maschinengeschwindigkeit. Das ist ein Perimetermodell. Es ist kein zero trust.

Per-Request-RBAC- und ABAC-Durchsetzung bedeutet, dass jede einzelne Dateioperation – jeder Abruf, jede Suche, jeder Download – zum Zeitpunkt der Anfrage gegen die tatsächlichen Zugriffsrechte des anfragenden Anwenders geprüft wird. Die KI übernimmt nicht die Sitzungsautorisierung, sondern die spezifischen Berechtigungen des Anwenders, dessen Anfrage sie ausführt – und zwar nur für diese Anfrage. Ist der Anwender nicht berechtigt, ein Dokument zu sehen, kann die KI es nicht abrufen – unabhängig davon, was das Servicekonto erreichen kann, unabhängig vom Sitzungsstatus, unabhängig von der Formulierung der Anfrage.

Ihre Sensitivitätslabels schützen Sie nicht vor KI – es sei denn, die KI prüft sie

Die meisten Unternehmen mit ausgereiften Data-Governance-Programmen haben in Datenklassifizierungs-Frameworks investiert – Sensitivitätslabels, die Dateien zugeordnet werden und festlegen, wie sie behandelt werden sollen, wer darauf zugreifen darf und was damit geschehen kann. Microsoft Information Protection, native Dateiklassifizierungssysteme, manuelle Klassifizierungsworkflows – all das sind echte Governance-Investitionen und funktionieren gut, um menschlichen Zugriff auf Dateien zu steuern.

Sie haben jedoch keinen Einfluss auf KI-Abrufe, sofern die KI-Integration sie nicht explizit prüft. Ein als Vertraulich markiertes Dokument ist für eine KI nicht schwerer abrufbar als ein unklassifiziertes. Das Sensitivitätslabel ist ein Metadatum, das der Datei zugeordnet ist. Ob dieses Metadatum vor der Rückgabe an eine KI geprüft – oder komplett ignoriert – wird, hängt allein von der Architektur der KI-Integration ab. In den meisten KI-Dateisystemintegrationen werden Sensitivitätslabels auf der Abrufebene nicht geprüft. Die KI ruft die relevantesten Dokumente zur Anfrage ab, und die Relevanzbewertung kennt keine Sensitivitätsklassifizierung.

Für Compliance-Beauftragte ist die Konsequenz eindeutig: Die Data-Governance-Kontrollen, in die Sie investiert haben, gelten nicht für KI-Zugriffe, sofern Ihre KI-Integration nicht explizit darauf ausgelegt ist, diese durchzusetzen. Jede Klassifizierungsentscheidung, jedes Sensitivitätslabel, jede Zugriffsbeschränkung für eine Datei im Repository – nichts davon schränkt KI-Abrufe ein, wenn die KI-Integration dies nicht auf der Abrufebene prüft. Ein Unternehmen, das glaubt, sein Klassifizierungs-Framework schütze vertrauliche Dateien vor unbefugtem KI-Zugriff, wiegt sich in falscher Sicherheit, die einer Prüfung nicht standhält.

Fünf Fehler bei der Zugriffskontrolle – und wie sie sich in der Praxis auswirken

Die Fragen, die Sie nicht beantworten können – bis Sie es können

Für Compliance-Beauftragte verdichtet sich das Governance-Problem beim KI-Dateizugriff zu einer konkreten und unangenehmen Frage: Wenn eine Aufsichtsbehörde oder ein Auditor fragt, worauf Ihre KI-Assistenten zugegriffen haben, wer jeden Abruf autorisiert hat und wie Sie nachweisen können, dass Ihre Datenschutzpflichten eingehalten wurden – könnten Sie antworten?

Die Antwort hängt ausschließlich davon ab, was Ihre KI-Integration protokolliert und durchsetzt. Die meisten KI-Dateizugriffsprotokolle erfassen, dass ein Servicekonto eine Datei abgerufen hat. Sie erfassen nicht, welche Mitarbeitenden die Anfrage ausgelöst haben, ob der Abruf mit deren Zugriffsrechten übereinstimmte, ob die Sensitivitätsklassifizierung geprüft wurde oder was mit dem Inhalt geschah.

Das ist kein Logging-Konfigurationsproblem – es ist ein Architekturproblem. Die für Compliance-Fragen erforderlichen Attributionsdetails müssen zum Zeitpunkt des Abrufs erfasst werden; sie lassen sich nachträglich nicht rekonstruieren.

Die HIPAA-Minimum-Necessary-Regel verlangt, dass der Zugriff auf geschützte Gesundheitsdaten auf das notwendige Minimum beschränkt wird. Ruft eine KI PHI zur Beantwortung einer Anfrage ab, erfordert der Nachweis der Minimum-Necessary-Compliance die genaue Kenntnis, was abgerufen wurde, zu welcher Anfrage, von welchem Anwender.

Die DSGVO verlangt, dass die Verarbeitung personenbezogener Daten eine dokumentierte Rechtsgrundlage hat – was für KI-Abrufe bedeutet, dass bekannt sein muss, welcher Anwender den Abruf veranlasst hat und zu welchem Zweck. SOX verlangt vollständige Aufzeichnungen über den Zugriff auf Finanzdaten.

FedRAMP-Compliance verlangt Audit-Logging für alle Operationen innerhalb autorisierter Informationssysteme, einschließlich KI-Operationen, mit Attributionsdetails, die den verantwortlichen menschlichen Akteur identifizieren.

Was Auditoren fragen werden – und was zur Beantwortung nötig ist

KI zu blockieren ist keine Lösung. Governance ist es.

Die reflexhafte Reaktion auf Bedenken beim KI-Dateizugriff – KI-Tools blockieren, Zugriffe entziehen, abwarten, bis das Governance-Framework nachzieht – schafft ein anderes Problem. Mitarbeitende, die KI für ihre Arbeit als wirklich nützlich empfinden, greifen über andere Wege darauf zu. Persönliche Konten, browserbasierte KI-Tools, Consumer-Anwendungen, die keinerlei Verbindung zur Unternehmens-Governance und keinen Zugriff auf autoritative Unternehmensdaten haben.

Das ist keine Theorie: Schatten-KI ist in den meisten Unternehmen bereits Realität, und das Einschränken zugelassener KI-Tools beschleunigt unkontrollierte KI-Nutzung eher, als sie zu verringern.

Die Governance-Frage ist nicht, ob KI-Dateizugriff erlaubt werden soll. Sie lautet, ob KI-Dateizugriff denselben Richtlinien, derselben Durchsetzung und demselben Audit-Trail unterliegt wie jeder andere Datenzugriff im Unternehmen. Ein Mitarbeitender, der über eine Desktop-Anwendung auf eine Datei zugreift, unterliegt Zugriffskontrollen, Sitzungsüberwachung und Audit-Logging.

Der gleiche Mitarbeitende, der über einen KI-Assistenten auf dieselbe Datei zugreift, sollte denselben Kontrollen unterliegen – Autorisierung pro Anfrage, Durchsetzung von Sensitivitätslabels, Logging mit doppelter Attribution. Umgeht der KI-Weg eine dieser Kontrollen, entsteht eine Governance-Lücke, die früher oder später ausgenutzt, entdeckt oder beides wird.

Wie Kiteworks sicherstellt, dass KI nur sieht, was sie sehen soll

Die Unternehmen, die KI-Einführung ohne Compliance-Risiko managen, sind nicht diejenigen, die KI am längsten blockieren – sondern diejenigen, die Governance am schnellsten auf KI ausweiten. Dazu braucht es eine Architektur, bei der die Antwort auf „Wer entscheidet, was KI sehen darf?“ dieselbe ist wie für jeden anderen Akteur: Die Policy Engine, geprüft zum Zeitpunkt jeder einzelnen Anfrage, anhand der tatsächlichen Zugriffsrechte des jeweiligen Anwenders.

Kiteworks setzt dies durch RBAC- und ABAC-Prüfung pro Anfrage auf KI-Operationsebene um – nicht beim Sitzungsaufbau. Jeder Dateiabruf, jede Suche, jede Ordneroperation, die von Claude, Copilot oder einem beliebigen MCP-kompatiblen KI-Assistenten über das Kiteworks Private Data Network ausgeführt wird, wird vor der Datenrückgabe anhand der aktuellen Zugriffsrechte des authentifizierten Anwenders geprüft.

Die KI übernimmt für jede einzelne Operation die Berechtigungen des Anwenders – nicht die des Servicekontos. Kann der Anwender ein Dokument nicht sehen, kann die KI es nicht abrufen – unabhängig vom Sitzungsstatus, unabhängig von der Anfrageformulierung, unabhängig davon, was das Servicekonto erreichen kann.

Die Durchsetzung von Sensitivitätslabels erfolgt auf der Abrufebene: Microsoft Information Protection-Klassifizierungen und Kiteworks-Datenklassifizierungsrichtlinien werden geprüft, bevor Daten an die KI zurückgegeben werden. Vertrauliche Dokumente werden auf Anfragen von Anwendern ohne entsprechende Berechtigung nicht angezeigt – nicht, weil die KI angewiesen wird, sie nicht zu erwähnen, sondern weil die Governance-Schicht sie nicht ausliefert.

Jede KI-Dateioperation wird mit doppelter Attribution protokolliert – KI-Systemidentität und authentifizierter Anwender – und fließt in das Kiteworks-Prüfprotokoll ein und wird in Echtzeit mit SIEM integriert. Die Compliance-Fragen aus der obigen Tabelle sind beantwortbar – weil die Architektur darauf ausgelegt ist, diese Antworten zu liefern.

Für CISOs, die nachweisen müssen, dass KI-Dateizugriff mit der gleichen Sorgfalt wie menschlicher Zugriff gesteuert wird, und für Compliance-Beauftragte, die auditfähige Dokumentation darüber benötigen, worauf KI zugegriffen hat und wer dies autorisiert hat, bietet Kiteworks die Governance-Datenschicht, die beides ermöglicht. Erfahren Sie, wie es funktioniert, und vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen Beweise, dass sie funktioniert.