KI im Unternehmen

Warum Datenzugriff die eigentliche Architektur-Herausforderung ist

Ein Architektur-Leitfaden für CTOs und Compliance-Verantwortliche

Andre Jahn - Solution Architect - Februar 2026

Das Versprechen und die Realität

Jedes Unternehmen, das Retrieval Augmented Generation (RAG) einsetzt oder plant, steht vor einem Versprechen: Die KI durchsucht den gesamten Wissensbestand und liefert präzise Antworten. Das Versprechen ist technisch einlösbar. Die Herausforderung, die dabei systematisch unterschätzt wird, ist keine Frage der Intelligenz des Modells - es ist eine Frage der Architektur.

Denn die KI sieht alles. Sie muss alles sehen, um arbeiten zu können. Aber der Mitarbeiter, der die Frage stellt, darf nicht alles sehen. Zwischen dem, was die KI weiß, und dem, was sie antworten darf, liegt ein architektonisches Niemandsland, das die meisten Implementierungen nicht adressieren.

Dieser Beitrag beschreibt die Architektur, die dieses Niemandsland strukturiert. Er richtet sich an Entscheider, die verstehen wollen, warum KI-Projekte auf Unternehmensdaten ohne eine durchdachte Zugriffskontrolle scheitern werden - nicht an der Technologie, sondern an Compliance und Vertrauen.

Die KI ist der Broker, nicht das Subject

In klassischen IT-Architekturen ist die Zugriffskontrolle klar strukturiert: Ein Benutzer (Subject) greift auf eine Ressource (Object) zu, und ein Regelwerk entscheidet, ob der Zugriff erlaubt ist. Identity and Access Management (IAM) und Attribute-Based Access Control (ABAC) sind etablierte Muster dafür.

Bei KI auf Unternehmensdaten verschiebt sich dieses Muster fundamental. Die KI ist kein Benutzer im klassischen Sinne. Sie ist generell berechtigt - sonst könnte sie nicht auf die Daten zugreifen, die im Vector Store liegen. Die eigentliche Zugriffskontrolle findet nicht zwischen KI und Daten statt, sondern zwischen KI und dem anfragenden Benutzer.

Die Frage ist nicht: Darf die KI diesen Chunk lesen? Die Frage ist: Darf die KI diesen Chunk in die Antwort an diesen Benutzer einfließen lassen?

Das bedeutet: Die KI agiert als Broker. Sie vermittelt zwischen dem Wissensbestand des Unternehmens und dem einzelnen Mitarbeiter. Und wie jeder Broker braucht sie klare Regeln, was sie an wen weitergeben darf.

Eine dreischichtige Architektur

Die Lösung erfordert drei getrennte Schichten, die jeweils einen eigenständigen Concern adressieren. Diese Trennung ist architektonisch entscheidend: Vermischt man die Schichten, erhält man ein System, das weder auditierbar noch wartbar ist.

Schicht 1: Ingestion - Klassifikation bei der Datenaufnahme

Beim Einlesen von Dokumenten in den Vector Store müssen die entstehenden Chunks mit Metadaten versehen werden. Nicht mit Berechtigungsinformationen - denn Berechtigungen ändern sich - sondern mit Klassifikationsattributen: Vertraulichkeitsstufe, Organisationseinheit, Datentyp, regulatorische Kategorie, Quellsystem.

Diese Trennung ist der Schlüssel: Die Frage „Welche Eigenschaften hat dieses Dokument?“ ist stabil. Die Frage „Wer darf es sehen?“ ändert sich mit jedem Personalwechsel.

Für die Herkunft dieser Attribute gibt es drei Ansätze:

Quellsystem-Übernahme. Metadaten werden aus den bestehenden Systemen übernommen - SharePoint-Klassifikationen, DMS-Kategorien, SAP-Berechtigungsgruppen. Das ist der kostengünstigste Ansatz, aber nur so zuverlässig wie die Datenpflege im Quellsystem. In der Praxis ist diese Zuverlässigkeit oft begrenzt.

KI-gestützte Klassifikation. Ein spezialisiertes Modell klassifiziert jeden Chunk bei der Ingestion. Das skaliert, wirft aber ein Vertrauensproblem auf: Man sichert Daten mit einem System, das selbst Fehler machen kann. Ein falsch klassifizierter Chunk ist ein stilles Datenleck.

Hybridansatz. Quellsystem-Attribute als Baseline, KI-Nachklassifikation mit menschlichem Review für hohe Vertraulichkeitsstufen. Realistisch, aber aufwändig.

Schicht 2: Berechtigungsprüfung zur Laufzeit

Wenn ein Benutzer eine Frage stellt, liefert der Vector Store die relevantesten Chunks. Bevor diese in den Prompt des Sprachmodells gelangen, prüft ein Policy Decision Point (PDP) für jeden Chunk: Darf dieser Benutzer mit diesen Rollen auf einen Chunk mit diesen Attributen zugreifen?

Ein vielversprechender Kandidat für diese Rolle ist der Open Policy Agent (OPA). OPA ermöglicht Policy-as-Code in der deklarativen Sprache Rego. Policies lassen sich versionieren, testen und auditieren - alles Anforderungen, die im Enterprise-Umfeld nicht verhandelbar sind.

Die Architektur sieht dabei folgendermaßen aus: Der Benutzer stellt eine Frage. Das Retrieval-System holt die Top-K relevanten Chunks aus dem Vector Store. Ein Policy Enforcement Point (PEP) übergibt für jeden Chunk die Chunk-Metadaten und den Benutzerkontext an OPA. OPA entscheidet pro Chunk: freigegeben oder gesperrt. Nur freigegebene Chunks fließen in den Prompt.

OPA entscheidet nicht, ob der Benutzer ein Dokument öffnen darf. OPA entscheidet, ob ein Informationsfragment in eine KI-generierte Antwort einfließen darf. Das ist IAM auf einer neuen Granularitätsebene.

Der entscheidende Vorteil dieses Ansatzes: Berechtigungen werden dynamisch zur Laufzeit geprüft. Wenn ein Mitarbeiter die Abteilung wechselt oder das Unternehmen verlässt, ändern sich die Policy-Inputs - nicht die Chunk-Metadaten. Die Daten im Vector Store bleiben unverändert.

Exkurs: Integration mit bestehenden Berechtigungssystemen

Besonders elegant wird dieses Muster bei der Anbindung von Systemen wie Notion, Confluence oder SharePoint. Diese Systeme haben bereits ein gepflegtes Berechtigungssystem. Statt diese Berechtigungen zu replizieren, kann der PEP das Quellsystem direkt abfragen: Darf dieser Benutzer diese Seite sehen?

Das eliminiert das Synchronisierungsproblem - die Berechtigungen sind immer aktuell, weil sie nicht kopiert, sondern live abgefragt werden. OPA fungiert dabei als Abstraktionsschicht, die unterschiedliche Berechtigungsmodelle auf ein einheitliches Attribut-Schema normalisiert. Ein PEP, viele Quellsysteme, eine Policy-Sprache.

Der Tradeoff ist Latenz und Kopplung: Jede Anfrage erfordert einen Roundtrip zum Quellsystem. Für Szenarien mit hohen Anforderungen an Aktualität ist das akzeptabel. Für Szenarien mit hohen Performance-Anforderungen kann ein periodischer Sync mit definiertem Zeitfenster die bessere Wahl sein.

Schicht 3: DSGVO-Maskierung - Das Henne-Ei-Problem

Unabhängig von der Berechtigungsprüfung gibt es einen zweiten, orthogonalen Concern: personenbezogene Daten. Ein Mitarbeiter kann berechtigt sein, ein Dokument zu sehen, und trotzdem dürfen bestimmte personenbezogene Daten darin nicht an ein Sprachmodell übergeben werden.

Das ist ein eigenständiges Risiko, das unabhängig vom Benutzer besteht. Selbst der Datenschutzbeauftragte persönlich hat dieses Risiko, wenn personenbezogene Daten im LLM-Prompt landen.

Die Maskierung erfolgt in Stufen:

Stufe 1 - Regelbasiert. Pattern-Matching für strukturierte personenbezogene Daten: E-Mail-Adressen, IBANs, Telefonnummern, Sozialversicherungsnummern. Deterministisch, auditierbar, performant.

Stufe 2 - Lokales NER-Modell. Ein spezialisiertes Named Entity Recognition-Modell, das on-premise läuft, erkennt Personennamen, Orte und Organisationen im Freitext. Keine Cloud, keine externe Verarbeitung - datenschutzrechtlich Eigenverarbeitung.

Stufe 3 - Semantisches Verständnis. Und hier beginnt das Dilemma.

Ein Satz wie „Der Kollege aus der Buchhaltung, der letzten Monat den Vorfall hatte“ enthält keine Named Entity. Im Kontext des Unternehmens ist er trotzdem eindeutig personenbezogen. Das erkennt nur, wer den Satz versteht - also ein Sprachmodell. Also genau das System, vor dem die Daten geschützt werden sollen.

Um Daten vor der KI zu schützen, braucht man eine KI, die die Daten sieht. Das ist kein technisches Versagen. Das ist ein struktureller Zielkonflikt.

Die ehrliche Antwort: Perfekte DSGVO-Konformität vor dem LLM-Zugriff ist mit vertretbarem Aufwand nicht erreichbar. Stufe 1 und 2 fangen einen Großteil ab. Für den Rest landet man bei einer Datenschutz-Folgenabschätzung, bei der Abwägung zwischen berechtigtem Interesse und Restrisiko, bei technischen und organisatorischen Maßnahmen.

Ein möglicher architektonischer Kompromiss: Ein schwächeres, lokal betriebenes Modell übernimmt die semantische Maskierung. Die bereits bereinigten Daten gehen dann an das leistungsfähigere externe Modell. Das ist datenschutzrechtlich vertretbar, setzt aber voraus, dass das lokale Modell gut genug ist, um kontextuelle Personenbezüge zu erkennen. Bei aktuellen europäischen Open-Source-Modellen ist das eine offene Frage.

Die Gesamtpipeline

Zusammengefasst ergibt sich eine Pipeline mit vier Filterschritten zwischen Benutzeranfrage und LLM-Antwort:

#	Schritt	Funktion	Technologie
1	Retrieval	Relevante Chunks aus Vector Store	Vector DB (Weaviate, Milvus, Qdrant)
2	Berechtigungsfilter	Prüfung: Darf dieser User diesen Chunk sehen?	OPA / Rego + PEP
3	DSGVO-Maskierung	Personenbezogene Daten entfernen oder pseudonymisieren	Regex + NER + lokales LLM
4	Prompt Assembly	Bereinigte Chunks in LLM-Kontext	Orchestrierung (LangChain, custom)

Nach der LLM-Generierung kann ein optionaler fünfter Schritt die erzeugte Antwort erneut prüfen - ein Response-Check, der sicherstellt, dass durch Kombination einzelner Informationen keine neuen, unzulässigen Erkenntnisse entstehen. Dieses Thema - Inference-Angriffe durch Kombination harmloser Einzelinformationen - verdient eine eigene Betrachtung.

Das regulatorische Dilemma

Diese Architektur ist technisch sauber. Sie ist auch komplex. Jede Schicht ist eine potenzielle Fehlerquelle. Und hier entsteht ein Spannungsfeld, das über die Technik hinausgeht.

In anderen Märkten - insbesondere den USA - erlaubt der regulatorische Rahmen, erst zu bauen und dann zu optimieren. Unternehmen gehen mit einfacheren Architekturen in Produktion, sammeln Erfahrung und verbessern iterativ.

In Europa entsteht die Komplexität der Infrastruktur überwiegend aus Compliance-Anforderungen. Und wenn der Maskierungsfilter einen Satz durchlässt, ist das kein technischer Bug - das ist ein Bußgeldrisiko.

Es entsteht eine paradoxe Situation: Wer es ignoriert, verstößt gegen geltendes Recht. Wer es halbherzig macht, hat das größte Risiko. Und wer es gewissenhaft macht, dokumentiert seine Restrisiken in der Datenschutz-Folgenabschätzung - und liefert der Aufsichtsbehörde damit die Prüfungsgrundlage gleich mit.

Das soll kein Argument gegen Datenschutz sein. Es ist ein Argument für eine regulatorische Praxis, die den Unterschied zwischen gewissenhafter Implementierung und Unterlassung anerkennt. Aktuell bestraft das System diejenigen, die es ernst nehmen, und belohnt diejenigen, die abwarten.

Empfehlungen für die Praxis

Trotz der Komplexität ist der Einsatz von KI auf Unternehmensdaten möglich - wenn die Architektur von Anfang an mitgedacht wird. Die folgenden Empfehlungen richten sich an Organisationen, die diesen Weg gehen wollen:

Trennen Sie Klassifikation von Berechtigung. Metadaten auf den Daten beschreiben Eigenschaften. Berechtigungen werden dynamisch zur Laufzeit geprüft. Diese Trennung ist die Grundlage für eine wartbare Architektur.

Nutzen Sie bestehende Berechtigungssysteme. Notion, Confluence, SharePoint haben bereits Zugriffskontrollen. Replizieren Sie diese nicht - integrieren Sie sie. OPA als Abstraktionsschicht normalisiert unterschiedliche Berechtigungsmodelle.

Akzeptieren Sie das Restrisiko bei der DSGVO-Maskierung - aber dokumentieren Sie es. Perfekte automatische Erkennung kontextueller Personenbezüge ist mit heutiger Technologie nicht erreichbar. Eine saubere Datenschutz-Folgenabschätzung, die dieses Restrisiko benennt und die getroffenen Maßnahmen beschreibt, ist der professionelle Umgang damit.

Beginnen Sie mit einem begrenzten Scope. Starten Sie nicht mit dem gesamten Dokumentenbestand. Wählen Sie eine Abteilung oder einen Dokumenttyp mit klaren Klassifikationsregeln und sauberen Quellsystem-Metadaten. Sammeln Sie Erfahrung, bevor Sie skalieren.

Investieren Sie in die Ingestion, nicht in das Modell. Die Qualität einer KI auf Unternehmensdaten wird nicht durch das Sprachmodell bestimmt, sondern durch die Qualität der Datenaufbereitung, Klassifikation und Zugriffskontrolle. Das ist weniger glamourös als Prompt-Engineering - aber es ist das, was über Erfolg oder Scheitern entscheidet.

Fazit

Enterprise AI ist kein Prompt-Engineering-Thema. Es ist ein Architekturthema. Und Architektur fängt bei den Daten an - bei ihrer Klassifikation, ihrer Zugriffskontrolle und dem ehrlichen Umgang mit den Grenzen dessen, was technisch sauber lösbar ist.

Die hier beschriebene Architektur ist kein theoretisches Konstrukt. Sie adressiert reale Anforderungen, die jedes Unternehmen mit regulatorischen Pflichten hat, das KI auf eigene Daten ansetzen will. Die Komplexität ist hoch. Aber die Alternative - KI ohne Zugriffskontrolle oder gar keine KI - ist keine Option.

Über den Autor

Andre Jahn ist freiberuflicher Solution Architect mit über 30 Jahren Erfahrung in der Enterprise-IT. Er berät Unternehmen bei der Modernisierung komplexer IT-Landschaften, mit besonderem Fokus auf Legacy-Systeme, Compliance-Architekturen und die sichere Integration von KI in bestehende Infrastrukturen.