RAG und DSGVO: Datenschutz bei internen KI-Wissenssystemen

Eine interne KI-Wissensdatenbank ist einer der ersten Use Cases, den Unternehmen mit RAG umsetzen wollen: Verträge, Handbücher, E-Mails, Personalrichtlinien rein, Fragen in natürlicher Sprache raus. Genau da beginnt das Datenschutzthema – denn in diesen Dokumenten stehen fast immer personenbezogene Daten. Die deutschen Datenschutzaufsichtsbehörden haben dafür im Oktober 2025 eine eigene Orientierungshilfe veröffentlicht („Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode”, DSK, Version 1.0). Dieser Artikel übersetzt sie in die Praxis von kleinen und mittleren Unternehmen.

Vorab zur Einordnung: Dieser Artikel ist eine allgemeine Information, Stand Juli 2026, und keine Rechtsberatung. Für die konkrete Bewertung deines Systems gehören Datenschutzbeauftragte oder spezialisierte Kanzleien an den Tisch. Was ich hier leisten kann: dir die richtigen Fragen mitgeben, damit dieses Gespräch kurz und produktiv wird statt lang und teuer.

Warum RAG und DSGVO zusammengehören

Die Kernaussage vorweg, weil sie in vielen Anbieter-Präsentationen untergeht: RAG beseitigt weder die Pflicht zur Rechtsgrundlage noch die Zweckbindung noch die Betroffenenrechte. RAG ist eine Architekturentscheidung, keine Compliance-Lösung.

Gleichzeitig ist das Gegenteil genauso falsch. RAG ist datenschutzrechtlich kein Problemfall, sondern in vielen Szenarien die bessere Architektur: Die DSK stellt fest, dass sich Informationen in der Vektordatenbank – anders als antrainiertes Wissen im Sprachmodell – „einfach aktualisieren, löschen und beauskunften” lassen. Das kommt der Umsetzung von Betroffenenrechten direkt entgegen. Wer die Wahl hat, Firmenwissen per Fine-Tuning ins Modell zu trainieren oder per RAG danebenzulegen, hat aus Datenschutzsicht meist ein klares Argument für RAG.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die ein RAG-System planen oder bereits pilotieren – und wissen wollen, wo die echten Risiken liegen und was dagegen hilft. Er gehört zu unserem Themen-Cluster RAG und Wissensdatenbanken.

Begriffe kurz geklärt

Damit wir über dasselbe reden:

• RAG (Retrieval-Augmented Generation) kombiniert ein Sprachmodell mit einer durchsuchbaren Wissensbasis. Die Frage der Nutzenden wird um passende Textausschnitte aus deinen Dokumenten ergänzt, bevor sie ans Modell geht. Das Modell soll idealerweise nur die Sprache liefern, die Fakten kommen aus deinen Dokumenten.
• Referenzdokumente sind die Quelldokumente deiner Wissensbasis – Verträge, Wikis, Richtlinien, Tickets.
• Chunks sind die Textabschnitte, in die diese Dokumente zerlegt werden.
• Embeddings sind Zahlenvektoren, die die Bedeutung eines Chunks repräsentieren. Sie ermöglichen die semantische Suche.
• Vektordatenbank speichert Embeddings samt Chunks und wird bei jeder Anfrage durchsucht.
• Ein RAG-System ist im Sinne der KI-Verordnung ein KI-System (Art. 3 Nr. 1 KI-VO) – die Pflichten aus dem AI Act kommen also zusätzlich zur DSGVO ins Spiel.

Wichtig für die rechtliche Bewertung: Ein RAG-System ändert nichts daran, wie das verwendete Sprachmodell trainiert wurde. Die DSK formuliert es unmissverständlich: Ein rechtswidrig trainiertes KI-Modell bleibt auch in einem RAG-System ein rechtswidrig trainiertes KI-Modell. RAG kann Risiken mindern, aber keine Trainings-Altlasten heilen.

Welche personenbezogenen Daten werden verarbeitet?

Die wichtigste Übung zu Beginn: einmal sauber durchgehen, wo überall in deinem RAG-System personenbezogene Daten auftauchen. Es sind mehr Stellen, als die meisten erwarten – fünf, um genau zu sein:

1. Referenzdokumente. Der offensichtlichste Ort. In internen Dokumenten stehen Namen von Mitarbeitenden, Kunden, Lieferanten, Bewerbenden – oft auch sensible Angaben wie Gesundheitsdaten in Personalakten (besondere Kategorien nach Art. 9 DSGVO).
2. Vektordatenbank: Chunks und Embeddings. Die Chunks enthalten die Textinhalte im Klartext oder verknüpft. Und die Embeddings selbst: Da sie die Bedeutung der Chunks repräsentieren, behalten sie in der Regel den Personenbezug. Ein Embedding ist keine Anonymisierung – dazu unten mehr.
3. Eingaben der Nutzenden. Wer fragt „Was steht im Arbeitsvertrag von Frau Müller?”, verarbeitet personenbezogene Daten schon im Prompt. Auch Logging und Auswertung dieser Eingaben sind eine eigene Verarbeitung.
4. Ausgaben des Systems. Die generierten Antworten enthalten personenbezogene Daten aus den Referenzdokumenten – und unterliegen dem Grundsatz der Richtigkeit (Art. 5 Abs. 1 lit. d DSGVO). RAG reduziert Halluzinationen, schließt unrichtige personenbezogene Ausgaben laut DSK aber nicht vollständig aus.
5. Das Sprachmodell selbst. LLMs werden typischerweise mit Daten trainiert, zu denen auch personenbezogene gehören. Verantwortliche wissen regelmäßig nicht, welche das sind. Dieses Risiko bringt jedes eingebundene Modell mit – unabhängig vom RAG-Aufbau.

Praktische Konsequenz: Erstelle vor dem Aufbau ein kurzes Datenflussdiagramm mit genau diesen fünf Stationen und beantworte pro Station: Welche Datenkategorien? Welche Betroffenengruppen? Wer hat Zugriff? Wo läuft die Komponente (eigenes Rechenzentrum, EU-Cloud, US-Anbieter)? Dieses eine Blatt Papier ist die Grundlage für alles Weitere – Verarbeitungsverzeichnis, Rechtsgrundlagen-Prüfung und die Frage, ob eine Datenschutz-Folgenabschätzung nötig ist.

Und die wirksamste Einzelmaßnahme steht schon in der Datenaufbereitung: Die DSK empfiehlt, personenbezogene Daten, die für den Zweck nicht erforderlich sind, vor dem Embedding zu entfernen oder zu anonymisieren. Jeder Name, der gar nicht erst in die Vektordatenbank gelangt, erzeugt später kein Lösch-, Auskunfts- oder Zugriffproblem.

Welche Rechtsgrundlagen sind zu prüfen?

Für jede Verarbeitung personenbezogener Daten – insbesondere die Verarbeitung der Referenzdokumente durch das Embedding-Modell und die Speicherung in der Vektordatenbank – braucht es eine Rechtsgrundlage. Das betont die DSK ausdrücklich. Welche in Frage kommt, hängt vom Szenario ab; typische Kandidaten in KMU:

• Berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO) – der häufigste Fall bei internen Wissenssystemen. Erfordert eine dokumentierte Abwägung: Dein Interesse an effizienter Wissensnutzung gegen die Rechte der Betroffenen (Mitarbeitende, Kunden, Dritte in den Dokumenten). Die Abwägung fällt umso eher zu deinen Gunsten aus, je stärker deine risikomindernden Maßnahmen sind – Datenminimierung, Zugriffskonzept, On-Premise-Betrieb. Interessant ist hier ein Punkt aus der DSK-Orientierungshilfe: Der Einsatz der RAG-Methode kann selbst als risikomindernde Maßnahme in die Abwägung eingehen, wenn er über das gesetzlich ohnehin Geschuldete hinausgeht.
• Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO) – wenn das System unmittelbar der Erfüllung von Verträgen dient, etwa im Kundenservice.
• Beschäftigtendatenschutz (§ 26 BDSG) – sobald Personaldaten in der Wissensbasis landen. Hier wird es schnell eng: Für eine allgemeine Wissensdatenbank sind Personalakten praktisch nie erforderlich. Meine klare Empfehlung: Personalunterlagen im ersten Schritt komplett aus dem Scope nehmen.
• Art. 9 DSGVO bei besonderen Kategorien (Gesundheit, Religion, Gewerkschaftszugehörigkeit …). Die DSK hält fest, dass solche Daten in einem RAG-System verarbeitet werden können, wenn die datenschutzrechtlichen Anforderungen erfüllt sind – gerade weil sie separat in Referenzdokumenten und Vektordatenbank liegen und nicht dauerhaft im Modell. Das ist aber die Kür, nicht der Einstieg.
• Einwilligung ist bei internen Systemen meist die schwächste Option – im Beschäftigungsverhältnis wegen der Freiwilligkeitsfrage heikel und jederzeit widerrufbar, was deine Wissensbasis unplanbar macht.

Zwei Punkte, die in der Praxis gern übersehen werden: Erstens die Zweckbindung – die DSK weist darauf hin, dass bei der Übergabe von Daten aus der Vektordatenbank an das LLM eine Verkettung mit personenbezogenen Daten im Modell entstehen kann, die in der Ausgabe nicht erkennbar ist. Dagegen helfen konzeptionelle Maßnahmen: getrennte Wissensbereiche (Mandantentrennung), Rollen pro Verarbeitungszweck, restriktiver Systemprompt. Zweitens die Auftragsverarbeitung: Sobald Embedding-Modell, Vektordatenbank oder LLM bei externen Anbietern laufen, brauchst du AV-Verträge und musst bei Nicht-EU-Anbietern die Drittlandsübermittlung sauber lösen.

Und parallel zur DSGVO läuft der AI Act: Er ist seit August 2024 in Kraft, die Verbote bestimmter Praktiken gelten seit Februar 2025, die Pflichten für Anbieter von Modellen mit allgemeinem Verwendungszweck seit August 2025; die Regeln für Hochrisiko-Systeme folgen gestaffelt ab Ende 2027. Eine interne Wissensdatenbank ist typischerweise kein Hochrisiko-System – prüfen (und dokumentieren) solltest du die Einstufung trotzdem, spätestens wenn das System Personalentscheidungen berührt.

Wie funktionieren Löschung und Berichtigung?

Hier spielt RAG seine größte datenschutzrechtliche Stärke aus – und hat zugleich seine härteste Grenze.

Die Stärke: Einträge in der Vektordatenbank sind direkt adressierbar. Kommt ein Löschverlangen nach Art. 17 DSGVO oder ein Berichtigungsverlangen nach Art. 16 DSGVO, löschst oder korrigierst du das Referenzdokument und die zugehörigen Chunks samt Embeddings – fertig. Die DSK bestätigt ausdrücklich, dass sich dafür auch klassische Mechanismen zur Löschung nach Ablauf von Aufbewahrungsfristen nutzen lassen, sowohl für die Vektordatenbank als auch für die Referenzdokumente. Auskunft nach Art. 15 DSGVO ist ebenfalls machbar, weil du weißt, welche Dokumente in der Wissensbasis liegen.

Damit das in der Praxis funktioniert, brauchst du drei Dinge:

1. Rückverfolgbarkeit: Jeder Chunk muss seinem Quelldokument zugeordnet bleiben. Löschen heißt immer: Quelle und alle abgeleiteten Chunks und Embeddings.
2. Einen Re-Indexierungsprozess: Wenn Dokumente korrigiert werden, müssen die alten Embeddings ersetzt werden – sonst antwortet das System weiter mit dem alten Stand.
3. Lösch-Hygiene bei Kopien: Caches, Logs der erweiterten Prompts und Antwort-Archive enthalten dieselben Daten. Wer nur die Vektordatenbank löscht, hat nicht gelöscht.

Die Grenze: Für das Sprachmodell selbst gilt all das nicht. Die DSK stellt nüchtern fest, dass die Umsetzung von Betroffenenrechten in KI-Modellen, insbesondere LLMs, „weitgehend ungelöst” ist – und dass die Probleme bei der Datenlöschung im Sprachmodell trotz aller RAG-Vorteile bestehen bleiben. Die praktische Schlussfolgerung daraus ist die wichtigste Architekturregel dieses Artikels: Personenbezogene Daten gehören in die Wissensbasis, niemals ins Modell. Kein Fine-Tuning mit Kundendaten, kein Nachtraining mit internen Dokumenten, die Personenbezug enthalten. Dann bleibt alles Löschbare an der Stelle, an der du löschen kannst.

Welche Risiken haben Embeddings?

Embeddings wirken auf den ersten Blick harmlos – Zahlenkolonnen statt Klartext. Genau dieser Eindruck ist das Risiko, denn er verleitet zu drei Fehlschlüssen:

Fehlschluss 1: „Embeddings sind anonym.” Sind sie in der Regel nicht. Embeddings repräsentieren die Bedeutung der Textabschnitte, und in den meisten RAG-Architekturen werden die Klartext-Chunks ohnehin mit den Vektoren gespeichert oder verknüpft – der Personenbezug bleibt vollständig erhalten. Behandle die Vektordatenbank deshalb mit demselben Schutzniveau wie die Quelldokumente selbst.

Fehlschluss 2: „Embeddings sind nachvollziehbar.” Die DSK hält fest: Es kann weder nachvollzogen werden, warum den jeweiligen Chunks die entsprechenden Embeddings zugeordnet werden, noch welche genaue Bedeutung sie haben. Die Transparenz eines RAG-Systems beschränkt sich darauf, die erweiterte Anfrage ans Modell zu dokumentieren – welche Chunks für eine Antwort verwendet wurden. Das solltest du auch tun (Quellenangaben in den Antworten), aber Erklärbarkeit auf Vektorebene gibt es nicht.

Fehlschluss 3: „Die Vektordatenbank ist kein Angriffsziel.” Doch. Die DSK nennt für das RAG-Subsystem ausdrücklich Angriffsvektoren wie Membership-Inference-Angriffe und Data-Poisoning – bei Letzterem werden manipulierte Inhalte in die Wissensbasis eingeschleust, um Antworten gezielt zu verfälschen. Dagegen helfen etablierte Maßnahmen: Zugriffskontrolle darauf, wer Dokumente in die Wissensbasis einstellen darf, Kontrolle der Dokumentquellen (keine Dokumente aus unbekannten oder nicht vertrauenswürdigen Quellen), Rechte- und Rollenkonzept für Abfragen, Mandantentrennung zwischen Wissensbereichen.

Der letzte Punkt ist zugleich der größte Vorteil gegenüber reinem LLM-Einsatz: Im Sprachmodell selbst lässt sich nicht steuern, wer auf welche Information Zugriff hat – in der Vektordatenbank schon. Berechtigungen sind bei RAG also nicht nur möglich, sondern der zentrale Hebel für Vertraulichkeit und Zweckbindung.

Wann hilft On-Premise?

On-Premise – oder allgemeiner: der Betrieb in einer selbst kontrollierten Umgebung – wird oft als Pauschallösung für „RAG und Datenschutz” verkauft. Die ehrliche Antwort ist differenzierter.

Was On-Premise löst: Es verhindert, dass personenbezogene Daten an externe Betreiber großer Sprachmodelle übertragen werden. Die DSK hebt genau diesen Punkt hervor: Weil bei RAG das Faktenwissen aus den Referenzdokumenten kommt, muss das Modell selbst weniger wissen – es kommen also auch kleinere Sprachmodelle (SLMs) in Frage, die sich realistisch auf eigener Hardware oder in einer dedizierten EU-Umgebung betreiben lassen. Kleinere Modelle memorieren unter Umständen auch weniger personenbezogene Daten aus dem Training. Damit entfallen Drittlandsübermittlung, ein Großteil der Auftragsverarbeitungs-Komplexität und das Risiko, dass Eingaben beim Anbieter für andere Zwecke landen.

Was On-Premise nicht löst: Rechtsgrundlage, Zweckbindung, Betroffenenrechte, Zugriffskonzept, Datenminimierung – die komplette Hausaufgabenliste dieses Artikels bleibt identisch. Ein lokal betriebenes System mit Personalakten für alle Mitarbeitenden abfragbar ist ein Datenschutzproblem im eigenen Keller.

Meine Faustregel für die Entscheidung, ohne Anspruch auf Vollständigkeit: Je sensibler die Daten in der Wissensbasis (Beschäftigtendaten, Gesundheitsdaten, Mandanteninformationen) und je schwächer deine vertragliche Position gegenüber dem Modellanbieter, desto stärker spricht es für On-Premise oder eine EU-Cloud mit klarem AV-Vertrag. Für einen Piloten mit unkritischen Dokumenten (öffentliche Handbücher, Produktdoku ohne Personenbezug) ist ein API-basierter Aufbau mit AV-Vertrag oft der pragmatischere Start – und der Wechsel des Modells ist bei sauberer RAG-Architektur später eine überschaubare Übung, weil die Wissensbasis bei dir bleibt.

Umsetzung: in fünf Schritten zum DSGVO-tauglichen RAG-Pilot

So gehe ich vor, wenn ein RAG-Vorhaben datenschutzlich sauber aufgesetzt werden soll:

1. Scope klein schneiden. Starte mit einem Dokumentenkorpus, der wenig oder keinen Personenbezug hat. Personalunterlagen, Bewerbungsdaten und Gesundheitsdaten bleiben im Piloten draußen. Das reduziert die rechtliche Prüfung auf ein handhabbares Maß.
2. Datenfluss dokumentieren. Das Fünf-Stationen-Diagramm von oben erstellen, Verarbeitungsverzeichnis ergänzen, mit DSB oder externer Beratung klären, ob eine Datenschutz-Folgenabschätzung nötig ist (bei umfangreicher Verarbeitung sensibler Daten oder Beschäftigtendaten: wahrscheinlich ja).
3. Datenaufbereitung mit Minimierung. Vor dem Embedding: irrelevante personenbezogene Daten entfernen oder anonymisieren, Dokumentquellen prüfen, Chunks so schneiden, dass die spätere Mandantentrennung funktioniert.
4. Zugriff und Rollen konfigurieren. Rechte- und Rollenkonzept auf der Vektordatenbank, Mandantentrennung zwischen Wissensbereichen, Systemprompt, der Antworten auf die referenzierten Quellen beschränkt, Quellenangaben in jeder Antwort.
5. Lösch- und Aktualisierungsprozess testen, bevor jemand ihn braucht. Ein Testdokument einstellen, löschen, prüfen: Ist es aus Referenzablage, Vektordatenbank, Cache und Logs verschwunden? Antwortet das System noch mit den alten Inhalten? Erst wenn dieser Test besteht, ist das System betriebsbereit.

Wenn du dabei Unterstützung willst: Im Rahmen der KI-Beratung prüfe ich RAG-Vorhaben genau entlang dieser Schritte – und in den Schulungen lernt dein Team, das System danach selbst sauber zu betreiben. Für eine erste Einschätzung deines RAG-Pilots reicht ein kurzes Erstgespräch.

Risikomatrix: Datenschutzrisiken und Gegenmaßnahmen

Die folgende Matrix ist mein Arbeitswerkzeug für RAG-Projekte in KMU. Die Einstufungen sind bewusst qualitativ – sie ersetzen keine Einzelfallprüfung, sortieren aber die Diskussion mit DSB und IT:

Risiko	Wo es entsteht	Typische Eintrittswahrscheinlichkeit	Schadenspotenzial	Wichtigste Gegenmaßnahmen
Unnötiger Personenbezug in der Wissensbasis	Datenaufbereitung	Hoch (Standardfehler)	Mittel	Datenminimierung vor dem Embedding; Personalunterlagen aus dem Scope nehmen
Fehlende/wackelige Rechtsgrundlage	Konzeption	Mittel	Hoch	Interessenabwägung dokumentieren; RAG-Maßnahmen als Risikominderung einbringen; DSB früh einbinden
Unbefugter Zugriff auf fremde Wissensbereiche	Vektordatenbank / Retriever	Mittel	Hoch	Rechte- und Rollenkonzept, Mandantentrennung, Rolle-pro-Zweck-Zuweisung
Löschverlangen nicht umsetzbar	Architektur	Niedrig bei RAG – wenn Prozess existiert	Hoch	Chunk-zu-Dokument-Rückverfolgung, Re-Indexierung, Löschtest inkl. Caches und Logs
Personenbezug im Modell (Fine-Tuning-Falle)	Modellwahl / Training	Niedrig, aber irreversibel	Hoch	Kein Training/Nachtraining mit personenbezogenen Daten; Wissen nur über die Wissensbasis
Unrichtige personenbezogene Ausgaben	LLM-Komponente	Mittel	Mittel	Restriktiver Systemprompt, Quellenangaben, Aktualität der Referenzdokumente, menschliche Prüfung bei kritischen Antworten
Datenabfluss an externe Modellanbieter	API-Anbindung	Mittel	Hoch	On-Premise/EU-Betrieb prüfen, AV-Vertrag, Drittlandsprüfung, kein sensibler Korpus bei schwacher Vertragslage
Data Poisoning / manipulierte Wissensbasis	Dokumenteneinspeisung	Niedrig	Mittel	Nur vertrauenswürdige Quellen, kontrollierter Einspeiseprozess, Änderungsprotokoll
Zweckverkettung mit Modellwissen	Übergabe Vektordaten → LLM	Schwer messbar	Mittel	Getrennte Wissensbereiche, restriktiver Systemprompt, Ausgabenkontrolle im Piloten

Lies die Matrix von oben nach unten als Priorisierung für den Einstieg: Die ersten vier Zeilen entscheiden in den meisten KMU-Projekten darüber, ob das System tragfähig ist.

Grenzen und offene Punkte

Zur ehrlichen Einordnung gehören auch die Punkte, die weder RAG noch dieser Artikel lösen:

• Das Trainings-Erbe des Modells. Ob das eingesetzte LLM rechtmäßig trainiert wurde, kannst du als Anwender kaum prüfen. RAG kann laut DSK Risiken mindern, die rechtliche Bewertung des Trainings bleibt davon unberührt. Bleibende Unsicherheit, die du nur über Modellwahl und Vertragsgestaltung adressieren kannst.
• Restrisiko unrichtiger Ausgaben. RAG reduziert Halluzinationen, eliminiert sie aber nicht – auch Modellwissen kann ungewollt in Antworten einfließen. Bei Aussagen über Personen ist das ein Richtigkeitsproblem nach Art. 5 DSGVO, nicht nur ein Qualitätsproblem.
• Bewegliche Rechtslage. Die DSK-Orientierungshilfe ist Version 1.0 vom Oktober 2025, die Anwendungsfristen des AI Acts laufen gestaffelt bis mindestens 2028, und zur Frage, wann LLMs selbst personenbezogene Daten „enthalten”, ist das letzte Wort nicht gesprochen. Plane eine regelmäßige Überprüfung deiner Bewertung ein – bei diesem Artikel steht der nächste Review-Termin nach drei Monaten im Kalender.

Checkliste: RAG datenschutzkonform aufsetzen

Zum Abhaken vor dem Start und vor dem Go-Live:

Vor dem Aufbau

• Datenflussdiagramm mit den fünf Stationen (Dokumente, Vektordatenbank, Eingaben, Ausgaben, Modell) erstellt
• Dokumentenkorpus für den Piloten bewusst klein und arm an Personenbezug geschnitten
• Rechtsgrundlage je Verarbeitung benannt und Interessenabwägung dokumentiert
• DSB/Beratung einbezogen, DSFA-Erforderlichkeit geprüft
• Bei externen Komponenten: AV-Verträge und Drittlandsfrage geklärt

Beim Aufbau

• Nicht erforderliche personenbezogene Daten vor dem Embedding entfernt oder anonymisiert
• Rechte- und Rollenkonzept auf Vektordatenbank und Referenzablage umgesetzt
• Mandanten-/Bereichstrennung der Wissensbasis eingerichtet
• Systemprompt beschränkt Antworten auf referenzierte Quellen, Quellenangaben aktiviert
• Kein Fine-Tuning/Nachtraining mit personenbezogenen Daten

Vor dem Go-Live

• Löschtest bestanden: Dokument entfernt aus Ablage, Vektordatenbank, Caches, Logs
• Berichtigungsprozess (Korrektur + Re-Indexierung) getestet
• Auskunftsprozess definiert: Wer beantwortet Art.-15-Anfragen, mit welchen Daten?
• Verarbeitungsverzeichnis aktualisiert, Informationspflichten umgesetzt
• Review-Termin für die datenschutzrechtliche Bewertung eingeplant

Wenn du deinen RAG-Piloten vor dem Start einmal strukturiert prüfen lassen willst – genau dafür ist der Erstcheck da.