Eine Wissens-KI, die Fragen aus Handbüchern, Verträgen und Projektordnern beantwortet, ist für viele Mittelständler der naheliegendste KI-Anwendungsfall überhaupt. Und fast immer fällt im ersten Gespräch derselbe Satz: „Dürfen wir das überhaupt — mit der DSGVO?“
Die ehrliche Antwort: Es kommt darauf an, wie du das System baust. Eine KI-Wissensdatenbank ist nicht per se konform oder nicht konform. Die Entscheidung fällt bei einer Handvoll Architektur-Fragen: Welche Daten kommen in den Index? Wo läuft das Embedding-Modell, wo das Sprachmodell? Wer darf was abfragen? Und wie bekommst du Daten wieder heraus, wenn jemand Löschung verlangt?
Wie die Technik dahinter funktioniert — Chunks, Embeddings, Vektordatenbank, Retriever — haben wir im Artikel RAG-Systeme: Firmenwissen in die KI bringen ausführlich erklärt. Das wiederholen wir hier nicht. Hier geht es um die andere Ebene: die fünf Architektur-Entscheidungen, die über DSGVO-Konformität entscheiden.
Die gute Nachricht: RAG ist der datenschutzfreundliche Weg
Bevor wir in die Entscheidungen einsteigen, ein wichtiger Kontext: Die deutschen Aufsichtsbehörden haben sich mit genau dieser Systemklasse bereits beschäftigt. Die Datenschutzkonferenz (DSK) — das Gremium der deutschen Datenschutz-Aufsichtsbehörden — hat im Oktober 2025 eine eigene Orientierungshilfe zu generativen KI-Systemen mit RAG-Methode veröffentlicht.
Der Grundtenor ist für dich als Anwender positiv. Der entscheidende Vorteil von RAG gegenüber dem Trainieren oder Feintunen eines Modells: deine Daten bleiben in einer Datenbank, die du kontrollierst. Sie lassen sich dort korrigieren und löschen. Aus einem einmal trainierten Modell lassen sich einzelne Informationen dagegen praktisch nicht mehr entfernen. Betroffenenrechte wie Auskunft, Berichtigung und Löschung sind bei RAG also technisch umsetzbar — genau das, was die DSGVO verlangt.
„Datenschutzfreundlich“ heißt aber nicht „automatisch konform“. Die DSK macht deutlich: Auch für die Verarbeitung personenbezogener Daten in Referenzdokumenten und Vektordatenbank brauchst du eine Rechtsgrundlage, ein Rechte- und Rollenkonzept und ein Löschkonzept. Genau daraus ergeben sich die folgenden fünf Entscheidungen.
Entscheidung 1: Welche Daten dürfen in welchen Index?
Der häufigste Fehler in Projekten ist der bequemste: „Wir indexieren einfach das ganze Laufwerk.“ In gewachsenen Dateiablagen steckt aber fast immer mehr Personenbezug, als man denkt — E-Mail-Verläufe, Bewerbungsunterlagen, Zeugnisse, Krankmeldungen, Kundendaten, alte Vertragsentwürfe. Wer das alles ungefiltert in einen Index schiebt, hat ab Tag eins ein Problem.
Deshalb steht vor der Indexierung eine Datenklassifizierung. In der Praxis reichen drei Klassen:
- Unkritisch: Produktdokumentation, Prozessbeschreibungen, öffentliche Inhalte — kein Personenbezug, darf in den allgemeinen Index für alle Mitarbeiter.
- Intern mit Personenbezug: Protokolle, Projektunterlagen, Korrespondenz — nur mit definiertem Zweck und Zugriffskontrolle indexieren.
- Hochsensibel: Personalakten, Gesundheitsdaten, Gehaltsdaten — im Zweifel gar nicht in die Wissens-KI, oder nur in einen strikt getrennten Index mit engem Nutzerkreis.
Die DSK-Orientierungshilfe fordert genau das: eine klare Zweckdefinition für jede eingebundene Datenquelle und nur geprüfte, aktuelle Referenzdokumente im System. Das deckt sich mit einer Erfahrung, die wir in KI-Wissensmanagement im Mittelstand beschrieben haben: Kuratieren vor Indexieren verbessert nicht nur die Compliance, sondern auch die Antwortqualität.
Entscheidung 2: Wo laufen Embedding-Modell und LLM?
Zwei Komponenten sehen deine Dokumente im Klartext: das Embedding-Modell bei der Indexierung — es verarbeitet einmal alle Inhalte — und das Sprachmodell bei jeder Antwort, das die gefundenen Textstellen als Kontext erhält. Wo diese beiden laufen, ist die zentrale Standort-Entscheidung. Drei Grundmodelle:
- US-Cloud-LLM: Größte Modellauswahl, wenig Betriebsaufwand — aber deine Dokumentinhalte fließen bei jeder Anfrage an einen US-Anbieter. Das ist ein Drittlandtransfer mit allen Konsequenzen (dazu gleich mehr).
- EU-Cloud-LLM: Anbieter wie der IONOS AI Model Hub (Rechenzentrum in Deutschland), STACKIT aus der Schwarz-Gruppe, T-Systems oder das französische Mistral AI stellen offene Modelle wie Llama und Mistral per API aus europäischen Rechenzentren bereit — mit AV-Vertrag nach EU-Recht und ohne Drittlandtransfer. Für die meisten Mittelständler der pragmatische Mittelweg.
- Lokal gehostetes Modell: Maximale Kontrolle, kein Datenabfluss — dafür eigene Hardware und Betrieb. Wann sich das lohnt und was es kostet, haben wir in Lokale KI im Mittelstand durchgerechnet.
Wichtig: du musst dich nicht für alle Komponenten gleich entscheiden. Ein bewährtes Hybrid-Muster: Embedding-Modell und Vektordatenbank laufen lokal oder beim EU-Anbieter — denn das Embedding sieht den kompletten Datenbestand. Beim Sprachmodell kannst du je nach Datenklasse routen: unkritische Anfragen an ein leistungsstarkes Cloud-Modell, sensible Anfragen an das EU- oder lokale Modell.
Entscheidung 3: Drittlandtransfer und AV-Vertrag sauber regeln
Wenn ein externer Anbieter Embedding, Vektordatenbank oder LLM betreibt, ist er Auftragsverarbeiter — Du brauchst einen AV-Vertrag nach Art. 28 DSGVO. Prüfe dabei mindestens:
- Verarbeitung nur auf deine Weisung — und ausdrücklich kein Training der Anbieter-Modelle mit deinen Daten,
- eine transparente Liste der Subunternehmer und der Speicherorte,
- Unterstützung bei Betroffenenrechten (Auskunft, Löschung),
- Löschung oder Rückgabe aller Daten nach Vertragsende.
Bei US-Anbietern kommt der Drittlandtransfer dazu. Aktuell ist er über das EU-US Data Privacy Framework möglich, den Angemessenheitsbeschluss der EU-Kommission vom Juli 2023. Nur: Diese Grundlage wackelt. Das Gericht der EU hat im September 2025 zwar eine Klage dagegen abgewiesen, doch das Rechtsmittel liegt inzwischen beim EuGH — und die beiden Vorgänger Safe Harbor (2015) und Privacy Shield (2020) wurden jeweils vom EuGH gekippt. Wer seine Architektur allein auf dieses Abkommen baut, baut auf eine Grundlage, die per Urteil wegfallen kann. Eine EU- oder lokale Architektur macht dich von diesem Risiko schlicht unabhängig.
Entscheidung 4: Zugriffskontrolle — der Index kennt deine Ordnerrechte nicht
Hier passieren die peinlichsten Pannen. Auf dem Dateiserver ist der HR-Ordner sauber berechtigt — aber die Vektordatenbank weiß davon nichts. Einmal indexiert, sind alle Inhalte für den Retriever erst einmal gleich. Ohne Gegenmaßnahme beantwortet die Wissens-KI dann auch dem Praktikanten die Frage nach der Gehaltsliste, wenn das Dokument versehentlich im Index gelandet ist.
Die DSK verlangt deshalb ausdrücklich ein Rechte- und Rollenkonzept für die Vektordatenbank und die Referenzdokumente. Praktisch heißt das:
- Jeder Chunk trägt Berechtigungs-Metadaten aus dem Quellsystem (wer darf das Ursprungsdokument sehen?),
- der Retriever filtert bei jeder Anfrage nach den Rechten des angemeldeten Nutzers — bevor Inhalte ans Sprachmodell gehen,
- besonders sensible Bereiche bekommen einen eigenen, getrennten Index statt nur eines Filters.
Entscheidung 5: Das Löschkonzept — Löschen heißt mehr als „Datei weg“
Das Recht auf Löschung aus Art. 17 DSGVO endet nicht beim Quelldokument. Dieselbe Information liegt in einem RAG-System mehrfach: als Originaldatei, als Text-Chunks, als Embeddings in der Vektordatenbank — und unter Umständen in Antwort-Logs. Ein Löschkonzept muss alle diese Orte erfassen.
Praktikabel wird das nur mit Automatik: Das Quellsystem ist das führende System, eine Synchronisations-Pipeline überträgt Änderungen und Löschungen regelmäßig in den Index. Die DSK empfiehlt in ihrer Orientierungshilfe entsprechend, bei Änderungen am Datenbestand die Embeddings neu zu berechnen. Wird ein Dokument an der Quelle gelöscht, verschwinden beim nächsten Lauf auch seine Chunks und Vektoren. Dazu gehört ein zweiter Baustein: Für das Auskunftsrecht aus Art. 15 DSGVO musst du sagen können, welche Quellen mit welchen Personendaten überhaupt indexiert sind — führe also ein Verzeichnis der eingebundenen Datenquellen und halte es aktuell.
Wie daraus eine Architektur für den Mittelstand wird
Setzt du die fünf Entscheidungen zusammen, ergibt sich fast von selbst ein Bauplan: klassifizierte Quellen statt Komplett-Indexierung, Embedding und Vektordatenbank in der EU oder im eigenen Haus, ein Retriever, der Berechtigungen durchsetzt, eine Lösch-Pipeline vom Quellsystem bis zum Vektor — und die LLM-Wahl je nach Sensibilität der Daten. Genau nach diesem Muster bauen wir unsere Wissens-KI für den Mittelstand.
Der vielleicht wichtigste Punkt zum Schluss: Die DSGVO ist kein Grund, auf eine Wissens-KI zu verzichten. Sie erzwingt nur Entscheidungen, die du ohnehin treffen solltest — denn ein kuratierter, berechtigter, aktueller Index liefert auch die besseren Antworten. Datenschutz-Architektur und Antwortqualität ziehen hier am selben Strang.
Häufige Fragen
Brauche ich eine Datenschutz-Folgenabschätzung (DSFA)?
Eine DSFA nach Art. 35 DSGVO ist nötig, wenn die Verarbeitung voraussichtlich ein hohes Risiko für Betroffene birgt. Bei einer Wissens-KI, die umfangreich Beschäftigten- oder Kundendaten indexiert, wirst du daran meist nicht vorbeikommen; bei einem Index rein aus Produkt- und Prozessdokumentation ohne Personenbezug in der Regel schon. Kläre die Frage früh mit deinem Datenschutzbeauftragten — die Klassifizierung aus Entscheidung 1 liefert dafür die Grundlage.
Reicht es, wenn ein US-Anbieter ein EU-Rechenzentrum nutzt?
Nur teilweise. Der Speicherort löst das Problem nicht vollständig, weil US-Anbieter über den US CLOUD Act grundsätzlich auch zur Herausgabe von Daten verpflichtet werden können, die außerhalb der USA liegen. Eine EU-Region bei einem US-Hyperscaler ist besser als keine — echte Unabhängigkeit von der Drittland-Diskussion bekommst du aber nur mit einem europäischen Anbieter oder lokalem Betrieb.
Muss ich Dokumente anonymisieren, bevor sie in den Index dürfen?
Nicht pauschal. Mit einer tragfähigen Rechtsgrundlage dürfen auch personenbezogene Inhalte indexiert werden. Anonymisierung oder Pseudonymisierung ist aber ein starkes Werkzeug überall dort, wo der Personenbezug für den Zweck gar nicht gebraucht wird — etwa wenn aus alten Projektberichten nur das Fachwissen interessiert, nicht die beteiligten Namen.
Was passiert bei einem Löschantrag, etwa von einem ehemaligen Mitarbeiter?
Zuerst prüfst du, ob gesetzliche Aufbewahrungspflichten der Löschung entgegenstehen — die gehen vor. Danach greift dein Löschkonzept: betroffene Dokumente an der Quelle löschen oder bereinigen, die Sync-Pipeline entfernt Chunks und Embeddings, und du dokumentierst den Vorgang. Mit der Architektur aus Entscheidung 5 ist das ein Routinevorgang statt einer Suchaktion durch alle Systeme.
Fazit
DSGVO-Konformität ist bei einer KI-Wissensdatenbank keine Frage des Ob, sondern der Architektur: Klassifiziere deine Daten, bevor sie in den Index gehen, lege bewusst fest, wo Embedding-Modell und LLM laufen, regle AV-Vertrag und Drittlandtransfer, setze Berechtigungen im Retriever durch und baue die Löschung von Anfang an ein. Wer diese fünf Entscheidungen sauber trifft, bekommt ein System, das Prüfungen standhält — und nebenbei besser antwortet.
Ein Hinweis der Fairness halber: Dieser Artikel gibt den aktuellen Stand von Aufsichtspraxis und Rechtsprechung wieder, ersetzt aber keine Rechtsberatung im Einzelfall — die gehört in die Hände Deines Datenschutzbeauftragten oder Anwalts.
Wenn du wissen willst, wie diese Architektur für deine Dokumente, deine Systeme und deine Branche konkret aussieht: In unserer KI-Beratung gehen wir genau diese fünf Entscheidungen mit dir durch. Melde dich einfach — das Erstgespräch klärt meist schon, welcher Weg für dich passt.