nDSG-konformes RAG für Schweizer KMU: Was es konkret heisst

Retrieval-Augmented Generation (RAG) ist die mit Abstand häufigste AI-Architektur in produktiven KMU-Projekten. Statt ein Sprachmodell mit dem ganzen Internet zu trainieren, hängt man ihm die eigene Wissensbasis an: Vertragsdokumente, Produkthandbücher, Helpdesk-Tickets, Wiki-Einträge. Das Modell beantwortet Fragen mit Bezug auf diese Dokumente — und genau in diesem Schritt entstehen Datenschutz-Fragen, die viele Schweizer KMU bisher unterschätzen.

Was RAG technisch tut — in zwei Absätzen für Nicht-Engineers

Stark vereinfacht: Ihre Dokumente werden in kleine Stücke (Chunks) zerlegt, jedes Stück wird mit einem zweiten KI-Modell (Embedding-Modell) in eine numerische Repräsentation (Vektor) übersetzt und in einer Vektor-Datenbank abgelegt. Wenn jemand eine Frage stellt, wird die Frage ebenfalls in einen Vektor übersetzt, die mathematisch nächstgelegenen Dokument-Chunks werden geholt und zusammen mit der ursprünglichen Frage an ein Sprachmodell (z.B. Claude oder GPT-4) geschickt. Das Modell antwortet auf Basis dieser Chunks.

Bedeutung für die Praxis: Bei jeder Anfrage verlassen auszugsweise Inhalte aus Ihren Originaldokumenten Ihre Infrastruktur — mindestens dann, wenn das Sprachmodell ein Cloud-Provider ist. Das ist der Moment, in dem nDSG, Auftragsverarbeitung und Datenresidenz konkret werden.

Die vier Datenflüsse, die nDSG-relevant sind

In einem typischen RAG-Setup für ein Schweizer KMU entstehen vier Datenflüsse. Jeder davon ist datenschutzrechtlich anders zu beurteilen:

1. Indexierung: Beim einmaligen oder periodischen Befüllen der Vektor-Datenbank werden Dokument-Chunks an ein Embedding-Modell geschickt. Wenn das Embedding-Modell in der Cloud läuft (z.B. OpenAI text-embedding-3), verlassen die Chunks Ihre Infrastruktur — auch wenn sie dort nicht gespeichert werden, müssen sie kurz verarbeitet werden.
2. Persistenz: Die Vektor-Datenbank selbst (z.B. Postgres mit pgvector, Qdrant, Pinecone) speichert die Chunks, oft im Klartext mitsamt Vektor. Wo läuft diese Datenbank? In der Schweiz, in der EU, in den USA?
3. Anfrage zur Laufzeit: Die Frage des Nutzers + die abgerufenen Chunks gehen an das Sprachmodell. Auch hier: Wo läuft das Modell, und unter welcher Auftragsverarbeitung?
4. Logging und Audit: Jede Anfrage erzeugt Log-Daten: Wer hat gefragt, was wurde abgerufen, was war die Antwort. Diese Logs sind für Compliance unerlässlich — und müssen ihrerseits geschützt werden.

Was „nDSG-konform" konkret bedeutet

Das revidierte Schweizer Datenschutzgesetz ist seit September 2023 in Kraft. Für ein RAG-Projekt sind vor allem fünf Punkte relevant:

• Bearbeitungsverzeichnis (Art. 12 nDSG): Sie müssen dokumentieren, welche Personendaten Sie zu welchem Zweck bearbeiten. Bei RAG heisst das: Sie wissen, welche Dokument-Typen indexiert sind und ob und welche Personendaten darin enthalten sind.
• Auftragsverarbeitung (Art. 9 nDSG): Jeder Drittanbieter, der Personendaten verarbeitet (Embedding-Modell, LLM, Vektor-DB-Hoster), ist Auftragsverarbeiter und braucht eine schriftliche Vereinbarung — analog zu DPAs unter EU-DSGVO.
• Bekanntgabe ins Ausland (Art. 16 nDSG): Übermittlung in Drittländer ohne angemessenes Schutzniveau braucht zusätzliche Garantien — Standardvertragsklauseln (EDÖB-anerkannt) oder Swiss-US Data Privacy Framework.
• Datenschutz durch Technikgestaltung (Art. 7 nDSG): „Privacy by Design" ist Pflicht. Konkret: sensible Felder maskieren, Zugriffe protokollieren, Pseudonymisierung wo möglich.
• Datenschutz-Folgenabschätzung (Art. 22 nDSG): Bei Verarbeitungen mit hohem Risiko zwingend. RAG mit Personendaten in einem Cloud-LLM fällt typischerweise darunter.

Architektur-Entscheidungen mit nDSG-Impact

Drei Entscheidungen treffen Sie früh in jedem RAG-Projekt — und jede hat datenschutzrechtliche Konsequenzen:

1. Welches Embedding-Modell?

Cloud-Embedding-Modelle (OpenAI, Voyage, Cohere) sind qualitativ exzellent und schnell. Sie verarbeiten aber jeden Chunk extern. Lokale Embedding-Modelle (z.B. nomic-embed-text, bge-m3 via Ollama oder Hugging Face TEI) sind 5–15% weniger präzise, laufen dafür auf Ihrer Hardware. Für sensible Domänen — Personalakte, Patientendaten, Mandatsdokumente — ist die lokale Variante oft die einzig vertretbare Wahl.

2. Wo läuft die Vektor-Datenbank?

Postgres mit pgvector auf einem Schweizer Hetzner- oder Infomaniak-Server bedeutet Datenresidenz Schweiz und ist nDSG-trivial. Pinecone oder Weaviate-Cloud bedeuten USA-Hosting und brauchen DPA + Drittlandstransfer-Begründung. Beide funktionieren — aber die Compliance-Story unterscheidet sich erheblich, und die monatlichen Kosten ebenfalls.

3. Welches LLM zur Laufzeit?

Die Tagesform-relevante Frage: Geht jede Antwort an Anthropic (USA, EU-Region wählbar), an OpenAI (USA, EU-Region wählbar), oder an ein lokal gehostetes Modell (Llama 3, Mistral via Ollama)? Lokale Modelle sind heute für viele KMU-Use-Cases ausreichend leistungsfähig, vor allem wenn der RAG-Kontext gut kuratiert ist. Für komplexe Reasoning-Aufgaben sind Cloud-LLMs noch immer überlegen — aber dann braucht es Datenmaskierung im Vorfeld.

Checkliste für Geschäftsführer vor einem RAG-Projekt

Wenn Ihr CIO oder ein externer Anbieter Ihnen ein RAG-Projekt vorschlägt, klären Sie vor der Unterschrift folgende sieben Punkte:

1. Welche Dokument-Typen werden indexiert, und enthalten sie Personendaten?
2. Welches Embedding-Modell wird genutzt — Cloud oder lokal?
3. Wo läuft die Vektor-Datenbank physisch, und wer hat Zugriff?
4. Welcher LLM-Provider zur Laufzeit, in welcher Region, mit welchem Auftragsverarbeitungsvertrag?
5. Wie werden sensible Felder maskiert, bevor sie das LLM erreichen?
6. Wie sieht das Audit-Log aus, und wie lange werden Anfragen aufbewahrt?
7. Wie funktioniert der Exit: bekommen Sie Index, Datenbank-Dump und Konfiguration zurück, wenn Sie den Anbieter wechseln?

Wenn der Anbieter auf eine dieser Fragen mit „darum kümmern wir uns dann später" antwortet — nehmen Sie das als Warnsignal. Datenschutz im RAG-Kontext ist keine Schicht, die man am Ende drüberzieht. Er ist eine architektonische Frühentscheidung.

Wo Turivus ansetzt

In jedem RAG-Projekt, das wir mit einem Schweizer KMU starten, ist die erste Woche eine reine Datenfluss-Analyse: Welche Dokumente, welche Personendaten, welche Maskierungs-Regeln, welcher Provider-Mix, welche Audit-Anforderungen. Erst danach wird die Architektur entworfen — und sie wird so dokumentiert, dass Ihr Datenschutzbeauftragter sie ohne Übersetzungsarbeit nutzen kann. Das ist langsamer als „wir installieren mal LangChain und schauen", aber es ist die einzige Variante, die ein KMU produktiv und compliance-fest in den Betrieb bringt.