Datenschutz by Design: Wie man eine KI-Plattform baut die DSGVO nicht nachrüstet

Artikel 25 der DSGVO trägt den sperrigen Titel „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen". In der englischen Fassung klingt es eingängiger: Data Protection by Design and by Default. Der Kern der Vorschrift ist revolutionär in seiner Einfachheit: Datenschutz darf kein nachträglicher Gedanke sein, sondern muss von Anfang an in die technische Architektur eingebaut werden.

Konkret verlangt Art. 25 Abs. 1, dass der Verantwortliche „sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung geeignete technische und organisatorische Maßnahmen" trifft. Das bedeutet: Wenn Sie eine Software-Plattform planen, müssen Sie den Datenschutz in den Entwurf integrieren — nicht nach dem Launch als Patch drauflegen.

Art. 25 Abs. 2 ergänzt das Prinzip der datenschutzfreundlichen Voreinstellungen (Privacy by Default): Standardmäßig dürfen nur die personenbezogenen Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind. Der Nutzer soll nicht aktiv werden müssen, um seinen Datenschutz zu verbessern — die sichere Einstellung muss der Standard sein.

Für KI-Plattformen ist Art. 25 besonders relevant, weil KI-Systeme naturgemäß große Datenmengen verarbeiten — Dokumente, Chatverläufe, Suchanfragen, Nutzungsmuster. Ohne konsequentes Privacy by Design wird eine KI-Plattform zum Datenschutzrisiko. Mit konsequentem Privacy by Design wird sie zum sichersten Ort für Unternehmensdaten.

Die folgenden Abschnitte zeigen, wie wir dieses Prinzip bei Nexoria in jede Schicht der Architektur umgesetzt haben — nicht als Marketing-Feature, sondern als unveränderbare technische Eigenschaft. Datenschutz, den man nicht ausschalten kann.

Die fundamentalste Datenschutzentscheidung einer Multi-Tenant-Plattform ist die Frage: Wie werden die Daten verschiedener Kunden voneinander isoliert? Bei vielen SaaS-Anbietern lautet die Antwort: Shared Database mit Tenant-ID-Filter. Alle Kunden teilen sich eine Datenbank, und ein WHERE-Filter in jeder SQL-Abfrage soll sicherstellen, dass Kunde A nicht die Daten von Kunde B sieht.

Dieses Modell hat eine inhärente Schwäche: Ein einziger vergessener Filter in einer einzigen Abfrage reicht aus, um Daten tenant-übergreifend zu leaken. Bei einer Plattform mit hunderten Endpoints und tausenden Abfragen ist das eine Frage der Zeit, nicht des Obs.

Nexoria geht einen anderen Weg: vollständige Mandantentrennung auf Datenbankebene.

• Separate Datenbank-Schemas pro Tenant — Jeder Mandant operiert in seinem eigenen isolierten Schema. Es gibt keine gemeinsame Tabelle, aus der man Daten anderer Kunden abfragen könnte
• Separate Vektor-Collections — Die KI-Suche basiert auf Vektordatenbanken (Qdrant). Jeder Mandant hat seine eigene Collection mit eigenen Vektoren. Eine Suchanfrage in Tenant A kann physisch nicht auf Vektoren von Tenant B zugreifen
• JWT-erzwungene Isolation — Jeder API-Request enthält ein signiertes JSON Web Token mit der Tenant-ID. Der Backend-Service extrahiert die Tenant-ID aus dem Token — nicht aus dem Request-Body oder URL-Parametern. Da das Token serverseitig signiert und verifiziert wird, kann ein Client seine Tenant-ID nicht manipulieren
• Connection Pooling pro Tenant — PgBouncer verwaltet Datenbankverbindungen im Transaction-Mode und stellt sicher, dass Verbindungen korrekt dem jeweiligen Tenant-Schema zugewiesen werden

Das Ergebnis: Selbst wenn ein gravierender Softwarefehler auftreten sollte — ein vergessener Filter, eine fehlerhafte JOIN-Bedingung — kann er keine tenant-übergreifende Datenlücke verursachen, weil die Trennung nicht auf Anwendungslogik basiert, sondern auf Infrastrukturebene erzwungen wird.

Gemäß Art. 32 DSGVO müssen technische Maßnahmen dem „Stand der Technik" entsprechen. Separate Schemas und JWT-basierte Isolation gehen über das Minimum hinaus — sie setzen den Standard, an dem sich andere messen lassen müssen.

Verschlüsselung ist kein Feature, das man ein- oder ausschalten kann — es ist eine Eigenschaft jeder Kommunikation und Speicherung in der Plattform. Art. 32 DSGVO nennt „Verschlüsselung" explizit als technische Maßnahme zur Gewährleistung der Datensicherheit. Bei Nexoria ist Verschlüsselung in vier Ebenen implementiert:

1. Transportverschlüsselung (TLS 1.3)

Jede Verbindung zwischen Client und Server ist mit TLS 1.3 verschlüsselt — dem aktuellen Stand der Technik. Das gilt für die Website, die Dashboard-Anwendung, die API-Endpunkte und die WebSocket-Verbindungen der Chatbots und VoiceBots. Unverschlüsselte HTTP-Verbindungen werden automatisch auf HTTPS umgeleitet. Zwischen den Servern im internen Netzwerk läuft der Datenverkehr über ein verschlüsseltes WireGuard-VPN — ein modernes, schlankes VPN-Protokoll, das auf dem Noise-Framework basiert und in unabhängigen Audits als sicher bewertet wurde.

2. Konfigurationsverschlüsselung (AES/Fernet)

Sensible Konfigurationsdaten — API-Schlüssel für externe Dienste, OAuth-Tokens, SMTP-Zugangsdaten — werden nicht im Klartext in der Datenbank gespeichert. Stattdessen kommt Fernet-Verschlüsselung (basierend auf AES-128-CBC mit HMAC-SHA256) zum Einsatz. Der Verschlüsselungsschlüssel wird separat verwaltet und ist nicht in der Datenbank abgelegt. Selbst bei einem hypothetischen Datenbank-Dump wären die sensiblen Konfigurationen nicht lesbar.

3. Passwort-Hashing (Argon2id)

Nutzerpasswörter werden nicht verschlüsselt — sie werden gehasht, und zwar mit Argon2id. Argon2 gewann 2015 den Password Hashing Competition und ist vom BSI (Bundesamt für Sicherheit in der Informationstechnik) als empfohlener Algorithmus gelistet. Argon2id ist sowohl gegen GPU-basierte Brute-Force-Angriffe als auch gegen Side-Channel-Angriffe gehärtet. Die Parametrisierung (Memory Cost, Time Cost, Parallelismus) ist so gewählt, dass selbst mit dedizierter Hardware ein Angriff auf ein einzelnes Passwort unverhältnismäßig lange dauert.

4. Backup-Verschlüsselung (age)

Alle Server-Backups werden mit age verschlüsselt — einem modernen, auditierten Verschlüsselungstool, das als Nachfolger von GPG konzipiert wurde. age verwendet X25519 für den Schlüsselaustausch und ChaCha20-Poly1305 für die symmetrische Verschlüsselung. Die Backups werden nach der Erstellung lokal verschlüsselt und erst dann auf den Backup-Server übertragen. Der private Schlüssel liegt ausschließlich beim Backup-Verantwortlichen und wird nicht auf dem Backup-Server gespeichert.

Diese vier Ebenen bilden zusammen eine Defense-in-Depth-Strategie, wie sie die ENISA (European Union Agency for Cybersecurity) in ihren Leitlinien zur Datenverschlüsselung empfiehlt: Keine einzelne Schicht ist allein verantwortlich, und ein Versagen einer Ebene wird durch die nächste aufgefangen.

Eine der häufigsten Bedenken bei KI-Plattformen lautet: „Werden meine Dokumente an OpenAI oder Google geschickt?" Die Sorge ist berechtigt — viele KI-Anbieter leiten Nutzerdaten an US-amerikanische Modelle weiter, wo sie unter den CLOUD Act fallen und potenziell für das Training zukünftiger Modelle verwendet werden.

Bei Nexoria ist die Antwort differenziert und transparent. Die Datenverarbeitung folgt einem klaren Prinzip: So viel wie möglich lokal, so wenig wie nötig extern — und wenn extern, dann europäisch.

Was vollständig lokal verarbeitet wird:

• Dokumenten-Embeddings — Wenn Sie ein Dokument hochladen, wird es auf unserem eigenen Server in Vektoren umgewandelt. Dafür nutzen wir das Modell BGE-M3, das lokal auf unserer GPU (NVIDIA RTX 4000 Ada, 20 GB VRAM) läuft. Ihr Dokument verlässt niemals den Server
• Dokumentenanalyse und -extraktion — Text wird mit PyMuPDF extrahiert, Tabellen mit eigenen Algorithmen erkannt, Daten mit lokaler Verarbeitung strukturiert. Kein externer Dienst sieht Ihre Rechnungen oder Verträge
• Semantische Suche — Die Vektordatenbank (Qdrant) läuft lokal. Suchanfragen werden lokal in Vektoren umgewandelt und lokal gegen Ihre Dokument-Vektoren abgeglichen. Die gesamte RAG-Pipeline (Retrieval Augmented Generation) bis zur Chunk-Auswahl findet auf dem eigenen Server statt
• Query-Erweiterung und HyDE — Um bessere Suchergebnisse zu liefern, generiert die KI zusätzliche Suchbegriffe und hypothetische Antworten. Auch das passiert lokal mit dem Modell Qwen3-8B auf unserer GPU, über den Hochleistungs-Inference-Server SGLang
• Semantic Cache — Häufig gestellte Fragen werden mit ihren Antworten in einem lokalen Vektor-Cache gespeichert, sodass wiederholte oder ähnliche Anfragen direkt beantwortet werden, ohne ein externes Modell zu kontaktieren

Was extern verarbeitet wird — und warum:

• Finale Antwortgenerierung — Für die Erzeugung der eigentlichen Antwort auf Ihre Frage wird Mistral Large verwendet, ein europäisches KI-Modell von Mistral AI (Hauptsitz: Paris, Frankreich). Mistral unterliegt europäischem Recht, nicht dem CLOUD Act. Die Daten werden gemäß Art. 28 DSGVO im Rahmen einer Auftragsverarbeitung behandelt

Entscheidend ist, was an Mistral gesendet wird: Nicht Ihre gesamten Dokumente, sondern nur die relevanten Text-Chunks (typischerweise 5–25 kurze Absätze), die die lokale Suche als relevant identifiziert hat, plus Ihre Frage. Ihre vollständigen Dokumente, Ihre Dateistruktur, Ihre Metadaten — all das verlässt den Server nie.

Das BSI empfiehlt in seinen Grundschutz-Bausteinen die Datenminimierung bei Cloud-Diensten (APP.5.3) — genau dieses Prinzip setzen wir um: Nur das absolute Minimum an Daten verlässt die lokale Infrastruktur, und auch nur an einen europäischen Dienstleister.

Art. 5 Abs. 2 DSGVO formuliert das Rechenschaftsprinzip (Accountability): Der Verantwortliche muss die Einhaltung der DSGVO-Grundsätze nachweisen können. Kein Datenschutzbeauftragter und kein Auditor gibt sich mit „Vertrauen Sie uns" zufrieden. Sie brauchen Belege — und zwar lückenlose.

Nexoria führt einen umfassenden, unveränderlichen Audit-Trail, der jede relevante Aktion protokolliert. Nicht nur „User hat sich eingeloggt", sondern granular und kontextreich:

Was wird protokolliert:

• Authentifizierung — Jeder Login-Versuch (erfolgreich und fehlgeschlagen), Logout, Token-Erneuerung, MFA-Verifizierung, MFA-Reset durch Administratoren
• Datenzugriff — Jede Suchanfrage in der Wissensbasis, jeder Dokumentenzugriff, jede Chatbot-Interaktion mit Zeitstempel und User-ID
• Datenänderung — Jedes Erstellen, Ändern und Löschen von Dokumenten, Wissensdatenbanken, Chatbots, VoiceBots und Nutzern
• Administration — Rollenänderungen, Nutzerdeaktivierungen, Nutzer-Reaktivierungen, permanente Löschungen, Konfigurationsänderungen an Chatbots und VoiceBots
• Externe Kommunikation — E-Mail-Versand über die Plattform, VoiceBot-Anrufe mit Dauer und Ergebnisstatus, Chatbot-E-Mail-Benachrichtigungen

Wie wird protokolliert:

• Jeder Log-Eintrag enthält: Zeitstempel (UTC), User-ID, Tenant-ID, Aktion, betroffene Ressource, IP-Adresse und User-Agent
• Audit-Logs werden separat von den Anwendungsdaten gespeichert und sind für die Anwendungsschicht nur im Append-Modus zugänglich — bestehende Einträge können weder überschrieben noch gelöscht werden
• Rate-Limiting auf allen 289 konfigurierten API-Endpoints stellt sicher, dass auch die Zugriffsmuster selbst protokolliert und auf Anomalien überprüft werden können

Diese Audit-Logs erfüllen mehrere Zwecke gleichzeitig:

• DSGVO-Compliance — Nachweis, dass personenbezogene Daten nur zweckgebunden und durch berechtigte Personen verarbeitet werden (Art. 5 Abs. 1 lit. b und f)
• Auskunftsrecht — Bei einem Auskunftsersuchen nach Art. 15 DSGVO können Sie exakt belegen, welche Daten eines Betroffenen verarbeitet wurden und wer darauf zugegriffen hat
• Incident Response — Bei einem Sicherheitsvorfall (Art. 33 DSGVO) liefern die Logs die Informationen, die Sie für die 72-Stunden-Meldung an die Aufsichtsbehörde benötigen: Was ist passiert, wann, welche Daten betroffen, welcher Umfang
• EU AI Act — Art. 26 Abs. 5 AI Act verlangt von Deployern die Aufbewahrung automatisch erzeugter Protokolle bei Hochrisiko-KI. Die Nexoria Audit-Logs erfüllen diese Anforderung bereits jetzt — eine weitere Investition in Zukunftssicherheit

Art. 17 DSGVO — das Recht auf Löschung („Recht auf Vergessenwerden") — ist eine der am häufigsten angefragten Datenschutzmaßnahmen. Und eine der am häufigsten unzureichend umgesetzten. Viele Plattformen setzen ein „Gelöscht"-Flag in der Datenbank und nennen es Löschung. Die Daten sind weiterhin vorhanden, nur nicht mehr sichtbar. Bei einem Datenleck wären sie trotzdem kompromittiert.

Bei Nexoria ist Löschung irreversibel und vollständig. Der Prozess nach einer Kündigung folgt einem klar definierten Zwei-Phasen-Modell:

Phase 1: Export-Fenster (30 Tage)

• Nach der Kündigung hat der Kunde 30 Tage Zeit, seine Daten vollständig zu exportieren
• Alle Funktionen bleiben in dieser Phase nutzbar — die Plattform ist voll zugänglich
• Der Export umfasst: alle Dokumente im Originalformat, Chat-Historien als strukturierte Daten, Aufgaben, Kalendereinträge, Flowbook-Definitionen und Audit-Logs

Phase 2: Irreversible Löschung

Nach Ablauf der 30 Tage werden automatisch und unwiderruflich gelöscht:

• Alle Dokumente — Originaldateien und verarbeitete Versionen werden physisch vom Dateisystem entfernt, nicht nur aus der Datenbank dereferenziert
• Alle Vektoren — Die gesamte Vektor-Collection des Mandanten wird aus Qdrant gelöscht. Damit ist eine Wiederherstellung der semantischen Suche oder eine Rekonstruktion von Dokumentinhalten über Vektoren unmöglich
• Alle Chat-Historien — Chatbot-Gespräche, VoiceBot-Transkripte, NexCompanion-Chatverläufe, Feedback-Daten
• Alle Konfigurationen — Chatbot-Einstellungen, VoiceBot-Konfigurationen, Flowbook-Definitionen, Workspace-Strukturen, Kalendereinträge, Aufgaben
• Alle Nutzerkonten — Zugangsdaten, Profilinformationen, MFA-Secrets, Recovery Codes, Rolleneinstellungen
• Alle Backups — Auch die verschlüsselten Backup-Kopien auf dem Cross-Server-Backup werden identifiziert und gelöscht

Das Datenbank-Schema des Mandanten wird vollständig entfernt. Es gibt keinen „Papierkorb", keine Soft-Delete-Phase nach der Löschung und keine technische Möglichkeit der Wiederherstellung. Wenn ein ehemaliger Kunde nach Ablauf der 30 Tage anruft und seine Daten zurückhaben möchte, ist die ehrliche Antwort: Das ist technisch nicht möglich. Und genau das ist die Absicht.

Diese konsequente Löschung erfüllt Art. 17 Abs. 1 DSGVO nicht nur formal, sondern in seinem Geist: Das Recht auf Löschung bedeutet Löschung — nicht Unsichtbarmachung.

Art. 25 Abs. 2 DSGVO verlangt, dass standardmäßig nur die Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind. Das Prinzip der minimalen Berechtigung (Principle of Least Privilege) ist die technische Umsetzung dieses Grundsatzes: Jeder Nutzer erhält exakt die Rechte, die er für seine Aufgabe benötigt — nicht mehr.

Nexoria implementiert ein zweistufiges Rollenmodell, das organisationsweite Berechtigungen von bereichsspezifischen Zugriffsrechten trennt:

Stufe 1: Tenant-Rollen (organisationsübergreifend)

• Super-Admin — Vollzugriff auf alle Tenant-Einstellungen, Nutzerverwaltung, Abrechnungsdaten, Audit-Logs, Chatbot- und VoiceBot-Konfiguration. Typischerweise der IT-Verantwortliche oder Geschäftsführer. Kann andere Admins ernennen und MFA zurücksetzen
• Admin — Kann Nutzer einladen und verwalten, Workspaces erstellen, Chatbots konfigurieren. Kein Zugriff auf Abrechnungsdaten oder globale Tenant-Einstellungen
• Member — Standardrolle für reguläre Mitarbeiter. Zugriff auf zugewiesene Workspaces, KI-Assistent, eigene Aufgaben und Kalender. Kein Zugriff auf Nutzerverwaltung oder Konfiguration
• Guest — Eingeschränkter Zugriff auf explizit freigegebene Inhalte. Kein Zugriff auf Konfiguration, Administration oder andere Workspaces. Ideal für externe Partner oder befristete Projektmitarbeiter

Stufe 2: Workspace-Rollen (bereichsspezifisch)

• Workspace-Admin — Kann Mitglieder zum Workspace einladen, Wissensdatenbanken erstellen und konfigurieren, Workspace-Einstellungen ändern
• Workspace-Member — Kann Dokumente hochladen und durchsuchen, den KI-Assistenten nutzen, Aufgaben erstellen und bearbeiten
• Workspace-Viewer — Nur-Lese-Zugriff. Kann Dokumente ansehen und den KI-Assistenten für Fragen nutzen, aber keine Daten verändern, hochladen oder löschen

Die Kombination beider Stufen ermöglicht feinkörnige Zugriffssteuerung: Ein Mitarbeiter kann in seinem eigenen Team-Workspace Admin sein, im Finance-Workspace aber nur Viewer-Rechte haben. Die Personalabteilung kann auf HR-Dokumente zugreifen, aber nicht auf die technische Dokumentation der Entwicklungsabteilung — und umgekehrt.

Entscheidend ist, was ein Nutzer nicht sehen kann. Die Benutzeroberfläche zeigt ausschließlich die Funktionen und Daten, für die der Nutzer berechtigt ist — alles andere existiert aus seiner Perspektive nicht. Die Berechtigungsprüfung findet in der Backend-Middleware statt, nicht im Frontend. Selbst wenn jemand die API direkt anspricht und versucht, auf fremde Ressourcen zuzugreifen, wird der Request serverseitig abgelehnt.

Dieses Modell entspricht den Empfehlungen des BSI IT-Grundschutz (Baustein ORP.4 — Identitäts- und Berechtigungsmanagement), der explizit eine rollenbasierte Zugriffskontrolle mit dem Prinzip der minimalen Rechte und regelmäßiger Überprüfung der Berechtigungen fordert.

Die Maßnahmen, die in diesem Artikel beschrieben sind, teilen eine gemeinsame Eigenschaft: Sie sind keine Features. Sie sind die Architektur.

Sie können in Nexoria keine Mandantentrennung „ausschalten". Es gibt keinen Toggle für „Verschlüsselung deaktivieren". Sie können die Audit-Logs nicht löschen. Sie können einem Guest nicht versehentlich Admin-Rechte geben, weil die Rollenhierarchie serverseitig in der Middleware erzwungen wird, nicht in der Benutzeroberfläche. Sie können Dokumente nicht „irgendwie" an der lokalen Verarbeitung vorbeischleusen — der Datenfluss ist in der Architektur fest verdrahtet.

Das ist der entscheidende Unterschied zwischen „DSGVO-konform" als Marketing-Label und Privacy by Design als technischer Realität.

Viele Plattformen werben mit Datenschutz — aber ihr Datenschutz besteht aus Dokumenten, Verträgen und Absichtserklärungen. Bei Nexoria besteht Datenschutz aus Datenbankisolation, Verschlüsselungsalgorithmen, JWT-Validierung und automatisierten Löschprozessen. Sie müssen nicht darauf vertrauen, dass wir Ihre Daten schützen — die Architektur macht es technisch unmöglich, es nicht zu tun.

Art. 25 DSGVO verlangt Datenschutz durch Technikgestaltung. Nicht durch Technikgestaltung und vielleicht ein Vertrag obendrauf. Durch Technikgestaltung. Die Technik muss es erzwingen — unabhängig von menschlichem Verhalten, menschlichen Fehlern oder böswilliger Absicht.

Das ist der Standard, den wir ansetzen. Und der Standard, an dem sich jede KI-Plattform messen lassen sollte, die behauptet, DSGVO-konform zu sein.

Quellen: Art. 25 DSGVO (Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen), Art. 32 DSGVO (Sicherheit der Verarbeitung), Art. 17 DSGVO (Recht auf Löschung), BSI IT-Grundschutz Kompendium (ORP.4 Identitäts- und Berechtigungsmanagement, CON.1 Kryptokonzept), ENISA Leitlinien zur Datenverschlüsselung, Argon2 — Password Hashing Competition Winner 2015

Überzeugen Sie sich selbst von der Architektur — Nexoria Base und Pro bieten all diese Sicherheitsmerkmale ab 29€/Monat. Vereinbaren Sie eine persönliche Demo.