Datenschutz by Design: Eine KI-Plattform bauen, die DSGVO nicht nachrüstet

Art. 25 DSGVO: Datenschutz als Architekturprinzip

Art. 25 DSGVO verlangt Datenschutz durch Technikgestaltung. Wie Mandantentrennung, Verschlüsselung und lokale Verarbeitung das in der Praxis umsetzen.

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.

Mandantentrennung: Jeder Kunde in seiner eigenen Welt

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. 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: Ein dedizierter Connection-Pooler 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 auf jeder Ebene

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

Jede Verbindung zwischen Client und Server ist nach aktuellem Stand der Technik transportverschlüsselt. 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 VPN, ein modernes, schlankes Protokoll, das in unabhängigen Audits als sicher bewertet wurde.

2. Konfigurationsverschlüsselung

Sensible Konfigurationsdaten (API-Schlüssel für externe Dienste, OAuth-Tokens, SMTP-Zugangsdaten) werden nicht im Klartext in der Datenbank gespeichert. Stattdessen kommt eine symmetrische Verschlüsselung auf AES-Basis mit Integritätsschutz 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

Nutzerpasswörter werden nicht verschlüsselt. Sie werden gehasht, und zwar mit einem vom BSI (Bundesamt für Sicherheit in der Informationstechnik) empfohlenen, speicher- und zeitintensiven Verfahren, das gegen moderne Brute-Force- und Side-Channel-Angriffe gehärtet ist. Die Parametrisierung ist so gewählt, dass selbst mit dedizierter Hardware ein Angriff auf ein einzelnes Passwort unverhältnismäßig lange dauert.

4. Backup-Verschlüsselung

Alle Server-Backups werden mit einem modernen, auditierten Verschlüsselungstool verschlüsselt, das starke asymmetrische Schlüsselaustausch-Verfahren mit authentifizierter symmetrischer Verschlüsselung kombiniert. 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.

Dateiablage und Suche in Deutschland, Antworten aus Frankreich

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 unterscheiden wir Dateiablage, Wissensindex und semantische Suche in Deutschland von der KI-Antwortgenerierung durch Mistral AI in Frankreich. Zusätzliche Dienste und aktivierte Integrationen sind unter [Sicherheit](/security) separat beschrieben.

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 ein spezialisiertes Embedding-Modell, das lokal auf unserer dedizierten GPU läuft. Diese Angabe betrifft die Indexierung; für eine anschließende KI-Antwort können relevante Inhalte an Mistral AI in Frankreich übermittelt werden
• Lokale Textextraktion für den Index: Text wird mit PyMuPDF extrahiert, Tabellen mit eigenen Algorithmen erkannt und Daten lokal strukturiert. Davon zu unterscheiden sind Funktionen wie OCR und die KI-Antwortgenerierung, bei denen Inhalte an Mistral AI in Frankreich übermittelt werden
• Semantische Suche: Die Vektordatenbank 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 einem lokalen Sprachmodell auf unserer GPU
• 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: Mistral AI verarbeitet die für die Antwort benötigten Inhalte in Frankreich. Die von Nexoria übermittelten Daten werden nach dem individuellen Auftragsverarbeitungsvertrag nicht für Modelltraining verwendet

Welche Inhalte an Mistral AI übermittelt werden, hängt von der Funktion ab: Bei Antworten aus der Wissenssuche können es relevante Textausschnitte sein, bei Dokumentenfunktionen wie OCR auch Dokumentinhalte. Für die Nexoria-Konfiguration ist Frankreich als Verarbeitungsort bestätigt. Weitere Dienste, darunter die technische Fehlerüberwachung über Sentry, sowie aktivierte Integrationen sind unter [Sicherheit](/security) getrennt aufgeführt. Die Angaben zur Kernplattform sind keine pauschale Zusage für sämtliche zusätzlichen Datenwege.

Das BSI empfiehlt in seinen Grundschutz-Bausteinen die Datenminimierung bei Cloud-Diensten (APP.5.3). Bei Nexoria sind die für die jeweilige Funktion übermittelten Inhalte und die beteiligten Dienste getrennt zu betrachten; die [Komponentenübersicht](/security) beschreibt die Datenwege.

Audit-Logs: Wer hat wann was gemacht

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

Automatische Datenlöschung nach Kündigung

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 der Vektordatenbank 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.

Rollen und Berechtigungen

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.