Daten-Governance für KI: Klassifizierung, Zugriff, Aufbewahrung und Lineage

Wir sehen das regelmäßig: Ein Team baut einen firmeneigenen Assistenten, indexiert „alles, was geht“, und dann stellt sich heraus, dass in der Vektordatenbank Verträge mit Vertraulichkeitsklauseln, Personaldaten und die Historie der Kundenkorrespondenz gelandet sind — zugänglich für jeden Mitarbeiter, der die richtige Frage stellt. Das Modell funktioniert korrekt. Das Problem ist das Fehlen einer Ordnung darüber, was es überhaupt zeigen darf. Daten-Governance ist Arbeit, die erledigt werden muss, bevor das erste Dokument in den Index gelangt, und kein Audit, das nach einem Vorfall durchgeführt wird.

Jedes Dokument, das du als Quelle für KI in Betracht ziehst, muss eine Sensitivitätsklasse zugewiesen bekommen. Das ist die Grundlage — von ihr hängen alle weiteren Entscheidungen über Zugriff, Aufbewahrung und Hosting ab. Ohne Klassifizierung lässt sich die Frage „Darf diese Datei in ein Cloud-Modell“ nicht sinnvoll beantworten.

Wir arbeiten normalerweise mit vier Ebenen. Je höher die Ebene, desto strenger sind die Verarbeitungsregeln und desto wahrscheinlicher ist es, dass die Daten lokal bleiben müssen.

Die Klassifizierung muss nicht vom ersten Tag an perfekt sein. Es reicht, wenn sie eindeutig ist und dort automatisch zugewiesen wird, wo es möglich ist — nach dem Speicherort im Quellsystem, dem Label in SharePoint oder einer Regel auf Ordnerebene. Ein Dokument ohne Klasse behandeln wir standardmäßig als vertraulich, nie als öffentlich. Das ist ein sichererer Fallback.

Der häufigste Fehler bei RAG-Implementierungen ist ein „flacher“ Index — eine Vektorsammlung, auf die jeder identischen Zugriff hat. Der Assistent erbt dann den größtmöglichen Umfang: Es reicht eine geschickt formulierte Frage, um einen Dokumentenausschnitt zu extrahieren, den der Fragende nie sehen sollte.

Das korrekte Muster ist die Übertragung der Berechtigungen aus dem Quellsystem in die Suchschicht. Jeder Ausschnitt enthält Metadaten darüber, wer ihn sehen darf (Abteilung, Rolle, Zugriffsebene), und die Abfrage filtert die Ergebnisse nach der Identität des Nutzers bevor sie an das Modell übergeben werden. Das Modell erhält nie Kontext, auf den der Fragende kein Recht hat — daher kann es ihn auch nicht unter dem Druck eines cleveren Prompts preisgeben.

In der Praxis bedeutet das drei Dinge: separate Sammlungen oder Metadatenfilter für verschiedene Sensitivitätsklassen, die Abbildung von Unternehmensrollen auf Berechtigungen im Index und das Prinzip „Verweigern, wenn unbekannt“. Wenn das System die Berechtigungen des Nutzers nicht feststellen kann, zeigt es keinen sensiblen Ausschnitt. Mehr darüber, wie wir solche Einschränkungen direkt in die Modellschicht einbauen, beschreiben wir im Text über Sicherheit von KI-Agenten.

Die Aufbewahrung ist eine Frage, auf die die meisten Unternehmen im Kontext von KI keine fertige Antwort haben. Eingabedaten (Dokumente im Index) und operative Daten (Chat-Logs, Abfragen, generierte Antworten) unterliegen separaten Richtlinien — und separaten Risiken.

Eingabedaten sollten so lange leben, wie sie aktuell und benötigt werden. Eine veraltete Prozedur von vor drei Jahren im Index ist nicht nur eine schlechtere Antwortqualität, sondern auch ein rechtliches Risiko, wenn sie personenbezogene Daten enthält, deren Verarbeitungsgrundlage bereits erloschen ist. Chat-Logs sind ein separates Thema: Standardmäßig wenden wir eine Null- oder minimale Aufbewahrungsdauer für den Inhalt von Abfragen an, da Nutzer Daten in den Assistenten einfügen, die niemand vorhergesehen hat.

Eine gute Aufbewahrungsrichtlinie beantwortet vier Fragen für jeden Datentyp:

• Wozu bewahren wir das auf? Der Verarbeitungszweck muss konkret sein — „weil es vielleicht nützlich ist“ ist kein mit der Minimierung vereinbarer Zweck.
• Wie lange? Ein konkreter Zeitraum mit Ablaufdatum, nicht „unbefristet“.
• Was passiert nach Ablauf? Automatische Löschung aus dem Index und der Vektordatenbank, nicht nur aus dem Quellsystem.
• Wie setzen wir das Recht auf Löschung um? Selektives Löschen von Ausschnitten einer bestimmten Person — auch die Vektoren müssen gelöscht werden, nicht nur die Quelldatei.

Das Letztere ist eine überraschend häufige Unterlassung. Das Löschen einer Datei aus SharePoint entfernt nicht ihre Embeddings aus der Vektordatenbank. Wenn die Pipeline kein selektives Löschen unterstützt, bleibt das Löschungsersuchen gemäß RODO technisch unerfüllt.

Lineage (Datenherkunft) ist die Fähigkeit, nachzuvollziehen, aus welchem Dokument, in welcher Version und aus welcher Quelle jeder Ausschnitt im Index stammt — und letztlich jeder Satz in der Antwort des Assistenten. Ohne dies lassen sich zwei kritische Fragen nicht beantworten: „Warum hat das Modell das gesagt?“ und „Ist diese Information noch aktuell?“.

In der Praxis sollte jeder Ausschnitt in der Vektordatenbank Metadaten zur Herkunft tragen: Identifikator des Quelldokuments, Version, Datum, Ursprungssystem und Sensitivitätsklasse. Wenn der Assistent einen Ausschnitt zitiert, kann er die konkrete Quelle angeben — das ist die Grundlage für das Vertrauen des Nutzers und die Voraussetzung für Auditierbarkeit. Lineage ist auch die Basis für die Einhaltung des Rechenschaftsprinzips in RODO: Du musst nachweisen können, welche personenbezogenen Daten vom System verarbeitet werden und woher sie stammen.

Solide Lineage zahlt sich auch operativ aus: Wenn sich das Quelldokument ändert, weißt du genau, welche Ausschnitte neu indexiert werden müssen, statt den gesamten Korpus neu zu berechnen. Die Grundlage für saubere Eingabedaten, auf denen Lineage überhaupt funktioniert, beschreiben wir im Text wie man Firmendaten für KI vorbereitet.

Minimierung ist das Prinzip, das die meisten Projekte rettet: In die KI gelangt nur, was für den Zweck unerlässlich ist. Ein Assistent, der Fragen zu internen Verfahren beantwortet, braucht nicht die gesamte CRM-Datenbank mit Kundenhistorie. Je weniger personenbezogene Daten in der Pipeline sind, desto geringer ist das Risiko und desto einfacher ist die Compliance.

Praktisch funktioniert die Minimierung von PII auf zwei Ebenen. Erstens — Selektion am Eingang: Wir indexieren keine Daten, die für die Aufgabe des Assistenten nicht benötigt werden. Zweitens — Maskierung in Echtzeit: Bevor ein Ausschnitt an ein externes generatives Modell gesendet wird, erkennen und ersetzen wir automatisch Namen, Telefonnummern, PESEL und E-Mail-Adressen. Bei Daten, die dem Berufsgeheimnis unterliegen, kann die gesamte Pipeline lokal laufen, was das Problem des Datenversands nach außen eliminiert — mehr dazu im Text über self-hosted LLM und RODO.

DPIA, also die Datenschutz-Folgenabschätzung, ist erforderlich, wenn die Verarbeitung ein hohes Risiko für die Rechte von Personen darstellen kann — und KI-Implementierungen mit Personaldaten, Gesundheitsdaten oder Finanzdaten fallen normalerweise in diese Kategorie. DPIA ist keine Formalität: Es ist eine Übung, die Antworten auf Fragen zu Zweck, Rechtsgrundlage, data residency und Sicherheitsmaßnahmen erzwingt, bevor das System startet. Gut gemacht, deckt sie oft Lücken auf, die im Projektstadium günstiger zu beheben sind als nach der Implementierung. Den vollständigen Kontext der Pflichten finden Sie im Text AI Act und RODO 2026.

Praktische Checkliste, die wir vor jeder Indexierung durchgehen. Wenn du einen Punkt nicht abhaken kannst, kommen die Daten nicht in den Index, bis die Lücke geschlossen ist.

• Klassifizierung — Jede Quelle hat eine zugewiesene Sensitivitätsklasse; keine Klasse = als vertraulich behandelt.
• Rechtsgrundlage — Existiert und ist für jeden Verarbeitungszweck dokumentiert.
• Rollenbasierter Zugriff — Berechtigungen aus dem Quellsystem in den Indexfiltern abgebildet; Prinzip „Verweigern, wenn unbekannt“.
• Minimierung — Nur für die Aufgabe des Assistenten notwendige Daten werden indexiert.
• Maskierung von PII — Automatisch vor dem Versand an ein externes Modell; an einer Stichprobe verifiziert.
• Aufbewahrung — Aufbewahrungsdauer und automatische Löschung für Eingabedaten und Logs definiert.
• Recht auf Löschung — Pipeline unterstützt selektives Löschen von Ausschnitten, einschließlich Vektoren.
• Lineage — Jeder Ausschnitt trägt Metadaten zur Herkunft; Antworten können auf die Quelle zurückgeführt werden.
• DPIA — Für Bereiche mit hohem Risiko vor der Implementierung durchgeführt.
• Hosting — Die Sensitivitätsklasse entscheidet, ob Daten die Infrastruktur verlassen dürfen.

Das ist keine Liste, die man einmal abhakt. Wir kehren bei jeder Änderung des Datenumfangs zu ihr zurück, denn eine neue Quelle bedeutet ein neues Risiko. Governance, die lebt, ist günstiger als ein Vorfall, der nicht lebt.

Eine klassische Informationssicherheitsrichtlinie konzentriert sich auf den Schutz von Daten im Ruhezustand und während der Übertragung — Verschlüsselung, Zugriffe, Backups. Daten-Governance für KI fügt eine schichtspezifische Ebene für Modelle hinzu: Kontrolle darüber, was das Modell durch RAG „sehen“ darf, Maskierung von PII vor dem Versand an das Modell sowie Lineage der Antworten. Das ist eine Erweiterung der bestehenden Richtlinie, kein Ersatz.

Nicht für jede. DPIA ist erforderlich, wenn die Verarbeitung ein hohes Risiko für die Rechte von Personen darstellen kann — typischerweise bei Personaldaten, Gesundheitsdaten, Finanzdaten oder großflächigem Profiling. Ein Assistent für öffentliche FAQs benötigt sie nicht. Im Zweifelsfall ist es besser, eine vereinfachte Bewertung durchzuführen und die Entscheidung zu dokumentieren, denn das ist selbst ein Nachweis der Rechenschaftspflicht gemäß RODO.

Der Schlüssel ist, dass das Löschen der Quelldatei nicht die Embeddings aus der Vektordatenbank entfernt. Die Pipeline muss das selektive Löschen von Ausschnitten unterstützen, die mit einer bestimmten Person oder einem Dokument verknüpft sind — und genau das ermöglicht Lineage. Ohne Herkunftsmetadaten ist das Löschungsersuchen technisch nicht umsetzbar, was eine direkte Verletzung der Pflichten aus RODO darstellt.

Das hängt von der Datenklasse und der Rechtsgrundlage ab, aber die Maskierung allein reicht normalerweise nicht für Daten besonderer Kategorien aus. Maskierung reduziert das Risiko für interne Daten, aber bei Personaldaten, rechtlichen oder Gesundheitsdaten empfehlen wir vollständiges Self-Hosting und data residency in der Unternehmensinfrastruktur. Dann verlässt kein Inhalt eure Umgebung — Details im Text über self-hosted LLM und RODO.

Beginne mit einem Bereich, den du in die KI einbinden möchtest, und klassifiziere nur diesen — nicht das ganze Unternehmen auf einmal. Gehe Ordner für Ordner durch, weise jeder Quelle eine der vier Klassen zu und wende das Prinzip an, dass ein Dokument ohne Klasse standardmäßig als vertraulich gilt. Ein Pilot in einem sauberen, gut klassifizierten Bereich ist sicherer und schneller als der Versuch, alles auf einmal zu ordnen — das gleiche schrittweise Vorgehen, das wir bei der Vorbereitung von Firmendaten für KI empfehlen.