GenAI & Daten
Wie GenAI mit Daten arbeitet
Bevor man über Datenschutz oder Governance spricht, braucht man die Landkarte: Welche Datenwege gibt es überhaupt — und welche Abstufungen sind jeweils relevant?
Diese Seite ist die Brücke zwischen AI Data Strategy, RAG, Agenten und den Fragen: Was ist erlaubt, was ist riskant, und was ist noch offen?
Erst was es ist, dann wie es mit Daten umgeht
Die Seite ist bewusst nicht als Technik-Katalog gebaut. Sie ordnet die wichtigsten GenAI-Wege über ihren Datenfluss: Was geht hinein, was kommt heraus, was wird angereichert, was gespeichert, was protokolliert und was verändert ein Modell dauerhaft?
Die fünf relevanten Datenwege
LLM-Aufrufe
Was es ist: Ein Mensch oder ein System gibt einem Sprachmodell Eingaben. Das Modell antwortet direkt oder nutzt den Kontext für eine weitere Verarbeitung.
Daten: Prompts, Dateien, Chat-Verläufe, Kontext und je nach System auch gespeicherte Historie, Logs oder Memory.
Ausprägungen
Lokal / self-hosted
Das Modell läuft auf eigener Infrastruktur. Das gibt mehr Kontrolle über Betrieb, Zugriffe und Datenpfad. Trotzdem bleiben Eingaberegeln, Protokollierung und Speicherlogik relevant.
Tenant-intern
Das Modell läuft in einem geschlossenen Unternehmensrahmen, zum Beispiel in M365 oder einer privaten Cloud-Umgebung. Das reduziert Drittanbieter-Risiken, aber Berechtigungen, Retention und interne Sichtbarkeit bleiben wichtig.
Enterprise-API mit Kontrollen
Ein externer Anbieter läuft unter klaren Kontrollen wie No-Training, konfigurierbarer Retention oder Zero Data Retention. Das ist leistungsfähig, braucht aber klare Datenminimierung und Freigaben.
Public / Consumer API
Am wenigsten kontrollierte Form. Hier gilt der strengste Maßstab für Datenminimierung, weil Hosting, Speicherung und Nutzungslogik am wenigsten steuerbar sind.
Beispiele
Mistral
Laut offizieller Doku werden API-Daten standardmäßig nicht fürs Training genutzt; Zero Data Retention ist möglich; Labs-Modelle sind die Ausnahme; Enterprise-Deployments können auch private Cloud oder On-Premises sein.
Claude / Anthropic
API und Claude Enterprise werden standardmäßig nicht fürs Training genutzt; Retention ist konfigurierbar; Bedrock ist ein eigener Pfad mit eigenen Retention-Regeln.
DeepSeek
Laut offizieller Disclosure kann User Input zur Optimierung oder zum Training genutzt werden, wenn man nicht opt-outet; zusätzlich gibt es offiziell selbst hostbare Modelle.
Erste Einordnung
Je stärker ein Anbieter Eingaben speichert oder für Modellverbesserung nutzt, desto wichtiger werden Datenminimierung, klare Freigaben und die Frage, ob der Anwendungsfall überhaupt so viel Datenfluss braucht.
Fragen: Welche Daten dürfen rein? · Wer sieht Prompt, Kontext und Antwort? · Was wird gespeichert oder fürs Training genutzt? · Was bleibt nur in der Session?
RAG / GraphRAG
Was es ist: Das LLM bekommt Kontext aus Dokumenten, Wissensdatenbanken oder Graphen dazu.
Daten: Quellen, Metadaten, Embeddings, Vektor-Datenbanken und ggf. Zitier- oder Quellenprotokolle.
Ausprägungen
Chunk-RAG
Das Modell sucht über Textabschnitte in Dokumenten. Das ist der einfachste Einstieg, aber auch der anfälligste für falsche Treffer, veraltete Quellen und schlecht gesteuerten Zugriff.
GraphRAG
Das Modell nutzt Beziehungen zwischen Entitäten und Themen. Das hilft bei komplexen Zusammenhängen, macht aber Herkunft, Modellierung und Governance der Wissensstruktur wichtiger.
Semantic / Ontology-RAG
Kontext wird über Fachbegriffe, Ontologien und semantische Ebenen organisiert. Das erhöht Konsistenz und Fachpräzision, braucht aber saubere Begriffsarbeit und Ownership.
Interne Quellen versus externe Quellen
Ob SharePoint, DMS, CRM oder Web-Quellen: Je sensibler und breiter die Quellen, desto wichtiger werden Zugriffsregeln, Protokollierung und Quellenqualität.
Beispiele
RAG auf SharePoint / DMS
Typisch für interne Wissensarbeit. Datenschutz hängt hier stark von Berechtigungen, Dokumentenklassifikation und Trefferqualität ab.
GraphRAG auf Beziehungswissen
Sinnvoll, wenn Personen, Projekte und Begriffe zusammen gedacht werden müssen. Dann wird die Modellierung selbst zum Governance-Thema.
Erste Einordnung
Je sensibler und vernetzter die Quellen sind, desto wichtiger werden Zugriff, Quellenqualität und Nachvollziehbarkeit.
Fragen: Welche Quellen sind erlaubt? · Darf das System sensible Dokumente ziehen? · Wer kontrolliert die Trefferqualität?
Training / Fine-Tuning
Was es ist: Das Modell wird mit eigenen Daten angepasst oder weiter trainiert.
Daten: Trainingsdaten, Labeling-Daten, Evaluationssets, synthetische Daten und Modellartefakte.
Ausprägungen
Fine-Tuning
Mit Beispielen wird das Verhalten eines Modells angepasst. Das ist wirksam, aber die Trainingsdaten prägen das Modell über den einzelnen Use Case hinaus.
PEFT / parameter-effiziente Anpassung
Nur ein kleiner Teil der Parameter wird verändert. Das spart Ressourcen, ändert aber nichts an der Frage, ob die zugrunde liegenden Daten überhaupt dafür geeignet sind.
Continued Pretraining / Post-Training
Das Modell lernt stärker aus zusätzlichen Korpora oder Nachtrainingsschritten. Hier steigen Sensitivität, Analyseaufwand und die Schwierigkeit späterer Löschung.
Synthetische Daten
Künstlich erzeugte Daten können helfen, Mengenprobleme zu lösen. Sie entlasten aber nicht von der Prüfung, aus welchen echten Daten sie abgeleitet wurden.
Beispiele
Kundendaten zum Nachtrainieren
Hohe Hürde, weil sich Zweckbindung, Einwilligung oder Vertrag und Löschbarkeit schnell stellen.
Synthetische Trainingssets
Hilfreich für Skalierung, aber nur dann sauber, wenn Herkunft und Re-Identifizierungsrisiken geprüft sind.
Erste Einordnung
Je stärker Daten ins Modell hineingelernt werden, desto schwieriger werden spätere Löschung, Zweckbegrenzung und Re-Use-Kontrolle.
Fragen: Dürfen diese Daten in ein Training? · Wie löscht man etwas wieder? · Was heißt das für das Recht auf Vergessenwerden?
Agenten / MCP / Tool Calling
Was es ist: Das Modell darf nicht nur antworten, sondern Tools und Systeme aufrufen.
Daten: Tool-Zugriffe, Aktionen, Berechtigungen, Systemkontexte und Entscheidungspfade.
Ausprägungen
Read-only Copilot
Das System liest nur und formuliert Vorschläge. Das ist die sicherste Form, weil noch kein externer Vorgang ausgelöst wird.
Draft mit menschlicher Freigabe
Der Agent erzeugt einen Entwurf oder einen Vorschlag, aber ein Mensch gibt frei. Das ist oft der pragmatische Zwischenweg.
Write-enabled Agent
Das System kann Tickets anlegen, E-Mails vorbereiten oder Daten schreiben. Dann werden Rechte, Logging und Fehlermanagement kritisch.
MCP / Multi-step Workflows
Der Agent nutzt standardisierte Tools oder mehrere Schritte hintereinander. Je mehr Schritte und Systeme, desto höher die Anforderungen an Least Privilege und Kontrolle.
Beispiele
MCP als Tool-Schicht
Gut für kontrollierte, standardisierte Anbindungen. Datenschutz und Security hängen hier stark an den freigegebenen Tools und Scopes.
Agent mit Schreibrechten
Sobald ein Agent aktiv arbeitet, braucht es klare Freigaben, Rollentrennung und einen belastbaren Incident- und Audit-Pfad.
Erste Einordnung
Je mehr Rechte ein Agent bekommt, desto wichtiger werden Least Privilege, menschliche Freigaben und Auditierbarkeit.
Fragen: Darf das System nur lesen oder auch handeln? · Welche Rechte bekommt es? · Wann braucht es menschliche Freigabe?
Logging / Memory / Kontrolle
Was es ist: Was das System gesehen, gespeichert oder gelernt hat, bleibt für Betrieb und Nachvollziehbarkeit relevant.
Daten: Chat-Historie, Telemetry, Audit-Trails, Memory, Reviews und Aufbewahrungsfristen.
Ausprägungen
Session-only
Der Kontext lebt nur für die laufende Interaktion. Das reduziert Speicherprobleme, aber nicht die Pflicht, Eingaben sauber zu prüfen.
Kurzzeit-Memory / Chat-Historie
Das System merkt sich Verlauf über die Session hinaus. Dann werden Aufbewahrung, Zugriff und Löschregeln wichtig.
Operative Logs / Telemetry
Für Betrieb, Fehleranalyse und Monitoring werden technische Spuren gespeichert. Diese Daten sind oft nützlich, aber datenschutz- und sicherheitsrelevant.
Audit-Trails / Langzeit-Memory
Wenn Inhalte für Nachvollziehbarkeit oder organisatorisches Lernen länger bleiben, wird daraus eine Governance-Frage mit klaren Verantwortlichkeiten.
Beispiele
Observability im Betrieb
Nützlich für Qualität und Sicherheit, aber es muss geklärt sein, wer die Logs sehen darf und wie lange sie bleiben.
Memory über mehrere Sessions
Praktisch für bessere Assistenz, aber heikel, wenn sensible Informationen langfristig konserviert werden.
Erste Einordnung
Je länger das System speichert, desto wichtiger werden Aufbewahrung, Zugriff, Löschbarkeit und organisatorische Kontrolle.
Fragen: Was wird protokolliert? · Wer darf Logs lesen? · Wie lange bleibt was erhalten?
Was hier schon klar ist
- Lokal betrieben heißt nicht automatisch: alles ist erlaubt. Die EU-Kommission und der EDPB stellen klar, dass die DSGVO für die Verarbeitung personenbezogener Daten unabhängig vom Hosting gilt.
- RAG ist kein Training; Kontextzugriff und Modellanpassung sind zwei verschiedene Datenwege.
- Agenten verschieben die Frage von 'was wird gesagt?' zu 'was darf getan werden?'.
- Logs, Memory und Audit-Trails sind kein Nebenthema, sondern Teil des Datenwegs.
Was wir noch offenhalten
- Welche Datentypen dürfen in welchem Weg eingesetzt werden?
- Welche Abstufungen gelten bei externen, tenant-internen und lokalen LLMs?
- Wann reichen Pseudonymisierung oder Filter nicht mehr aus?
- Was gilt für Löschung, Erinnerung und Modellanpassung bei eigenen oder Kundendaten?
- Welche Freigaben, Rollen und Kontrollen braucht jeder Weg?
Womit es weitergeht
AI Data Platforms
Wie Daten, Semantik, Zugriff und AI-Betrieb organisationsübergreifend zusammenfinden.
Weiterlesen →AI Data Strategy
Die Architekturfrage: Datenbasis, Katalog, Lifecycle und Runtime Governance.
Weiterlesen →AI Governance
Der Steuerungsrahmen für Verantwortung, Regeln und Freigaben.
Weiterlesen →AI Security & Compliance
Regulatorische Security-Anforderungen an KI-Systeme.
Weiterlesen →RAG & Semantic Layer
Chunk-, Graph- und Ontology-RAG als technische Vertiefung.
Weiterlesen →MCP
Wie Agenten Tools und Systeme kontrolliert anbinden.
Weiterlesen →AI Observability
Logs, Traces und Monitoring als Betriebsschicht für KI.
Weiterlesen →