Namespace-Technologie fuer Geschaeftskunden
Wie das SDK sensible Daten anonymisiert, verschluesselt und sicher in der Cloud verarbeiten laesst -- ohne dass der Betreiber Zugriff auf Klartext hat.
1. Was ist die Namespace-Technologie?
Unsere Namespace-Technologie (intern BYOEH -- Bring Your Own Expectation Horizon) ist eine Privacy-First-Architektur, die es Geschaeftskunden ermoeglicht, sensible Daten anonym und verschluesselt von KI-Services in der Cloud verarbeiten zu lassen -- ohne dass personenbezogene Informationen jemals den Client verlassen.
“Daten gehen pseudonymisiert und verschluesselt in die Cloud, werden dort von KI verarbeitet, und kommen verarbeitet zurueck. Nur der Kunde kann die Ergebnisse wieder den Originaldaten zuordnen -- denn nur sein System hat den Schluessel dafuer.”
Das SDK loest ein grundlegendes Problem fuer Unternehmen: KI-gestuetzte Datenverarbeitung ohne Datenschutzrisiko. Die Architektur basiert auf vier Bausteinen:
- Pseudonymisierung: Personenbezogene Daten werden durch zufaellige Tokens ersetzt. Nur der Kunde kennt die Zuordnung.
- Client-seitige Verschluesselung: Alle Daten werden auf dem System des Kunden verschluesselt, bevor sie die Infrastruktur verlassen. Der Cloud-Server sieht nur verschluesselte Blobs.
- Namespace-Isolation: Jeder Kunde erhaelt einen eigenen, vollstaendig abgeschotteten Namespace. Kein Kunde kann auf Daten eines anderen zugreifen.
- KI-Verarbeitung in der Cloud: Die KI arbeitet mit den pseudonymisierten Daten und den vom Kunden bereitgestellten Referenzdokumenten. Ergebnisse gehen zurueck an den Kunden zur lokalen Entschluesselung und Re-Identifizierung.
Kern-Designprinzip: Operator Blindness
Breakpilot kann die Kundendaten nicht lesen. Der Server sieht nur verschluesselte Blobs und einen Schluessel-Hash (nicht den Schluessel selbst). Die Passphrase zum Entschluesseln existiert ausschliesslich auf dem System des Kunden und wird niemals uebertragen. Selbst ein Angriff auf die Cloud-Infrastruktur wuerde keine Klartextdaten preisgeben.
2. Typische Anwendungsfaelle
Die Namespace-Technologie ist ueberall einsetzbar, wo sensible Daten von einer KI verarbeitet werden sollen, ohne den Datenschutz zu gefaehrden:
| Branche | Anwendungsfall | Sensible Daten |
|---|---|---|
| Bildung | KI-gestuetzte Klausurkorrektur | Schuelernamen, Noten, Leistungsdaten |
| Gesundheitswesen | Medizinische Befundanalyse | Patientennamen, Diagnosen, Befunde |
| Recht | Vertragsanalyse, Due Diligence | Mandantendaten, Vertragsinhalte |
| Personalwesen | Bewerbungsscreening, Zeugnisanalyse | Bewerberdaten, Gehaltsinformationen |
| Finanzwesen | Dokumentenpruefung, Compliance-Checks | Kontodaten, Transaktionen, Identitaeten |
3. Der komplette Ablauf im Ueberblick
Der Prozess laesst sich in sieben Schritte unterteilen. Die gesamte Pseudonymisierung und Verschluesselung geschieht auf dem System des Kunden, bevor Daten in die Cloud gesendet werden:
Workflow: Vom Quelldokument zur KI-verarbeiteten Ausgabe
SCHRITT 1: DOKUMENTE ERFASSEN & PSEUDONYMISIEREN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SDK empfaengt Dokumente (PDF, Bild, Text)
→ Personenbezogene Daten werden erkannt (Header, Namen, IDs)
→ PII wird durch zufaellige Tokens ersetzt (doc_token, UUID4)
→ Zuordnung "Token → Originalname" wird lokal gesichert
SCHRITT 2: CLIENT-SEITIGE VERSCHLUESSELUNG
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kunde konfiguriert eine Passphrase im SDK
→ SDK leitet daraus einen 256-Bit-Schluessel ab (PBKDF2, 100k Runden)
→ Dokumente werden mit AES-256-GCM verschluesselt
→ Nur der Hash des Schluessels wird an den Server gesendet
→ Passphrase und Schluessel verlassen NIEMALS das Kundensystem
SCHRITT 3: IDENTITAETS-MAP SICHERN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Die Zuordnung "Token → Originaldaten" wird verschluesselt gespeichert:
→ Nur mit der Passphrase des Kunden rekonstruierbar
→ Ohne Passphrase ist keine Re-Identifizierung moeglich
SCHRITT 4: UPLOAD IN DEN KUNDEN-NAMESPACE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Verschluesselte Dateien gehen in den isolierten Namespace:
→ Jeder Kunde hat eine eigene tenant_id
→ Daten werden in MinIO (Storage) + Qdrant (Vektoren) gespeichert
→ Server sieht: verschluesselter Blob + Schluessel-Hash + Salt
SCHRITT 5: KI-VERARBEITUNG IN DER CLOUD
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KI verarbeitet die pseudonymisierten Daten:
→ RAG-System durchsucht Referenzdokumente des Kunden
→ KI generiert Ergebnisse basierend auf Kundenkontext
→ Ergebnisse sind an den Namespace gebunden
SCHRITT 6: ERGEBNISSE ZURUECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KI-Ergebnisse gehen an das Kundensystem:
→ SDK entschluesselt die Ergebnisse mit der Passphrase
→ Kunde sieht aufbereitete Ergebnisse im Klartext
SCHRITT 7: RE-IDENTIFIZIERUNG & FINALISIERUNG
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kunde ordnet Ergebnisse den Originaldaten zu:
→ Identitaets-Map wird entschluesselt
→ Tokens werden wieder den echten Datensaetzen zugeordnet
→ Fertige Ergebnisse stehen im Originalsystem bereit4. SDK-Integration
Die Integration in bestehende Systeme erfolgt ueber unser SDK. Nachfolgend ein vereinfachtes Beispiel, wie ein Kunde das SDK nutzt:
Beispiel: SDK-Integration (TypeScript)
import { BreakpilotSDK, NamespaceClient } from '@breakpilot/compliance-sdk'
// 1. SDK initialisieren mit API-Key
const sdk = new BreakpilotSDK({
apiKey: process.env.BREAKPILOT_API_KEY,
endpoint: 'https://api.breakpilot.de'
})
// 2. Namespace-Client erstellen (pro Mandant/Abteilung)
const namespace = sdk.createNamespace({
tenantId: 'kunde-firma-abc',
passphrase: process.env.ENCRYPTION_PASSPHRASE // Bleibt lokal!
})
// 3. Dokument pseudonymisieren & verschluesselt hochladen
const result = await namespace.upload({
file: documentBuffer,
metadata: { type: 'vertrag', category: 'due-diligence' },
pseudonymize: true, // PII automatisch ersetzen
headerRedaction: true // Kopfbereich entfernen
})
// result.docToken = "a7f3c2d1-4e9b-4a5f-8c7d-..."
// 4. Referenzdokument hochladen (z.B. Pruefkriterien)
await namespace.uploadReference({
file: referenceBuffer,
title: 'Pruefkriterien Vertrag Typ A'
})
// 5. KI-Verarbeitung anstossen
const analysis = await namespace.analyze({
docToken: result.docToken,
prompt: 'Pruefe den Vertrag gegen die Referenzkriterien',
useRAG: true
})
// 6. Ergebnisse entschluesseln (passiert automatisch im SDK)
console.log(analysis.findings) // Klartext-Ergebnisse
console.log(analysis.score) // Bewertung
// 7. Re-Identifizierung (Token → Originalname)
const identityMap = await namespace.getIdentityMap()
const originalName = identityMap[result.docToken]Zero-Knowledge-Architektur
Die Passphrase verlässt niemals das System des Kunden. Das SDK verschluesselt und entschluesselt ausschliesslich lokal. Breakpilot hat zu keinem Zeitpunkt Zugriff auf Klartextdaten oder den Verschluesselungsschluessel.
5. Pseudonymisierung: Wie personenbezogene Daten entfernt werden
Pseudonymisierung bedeutet: personenbezogene Daten werden durch zufaellige Tokens ersetzt, sodass ohne Zusatzinformation kein Rueckschluss auf die Person moeglich ist. Das SDK bietet zwei Mechanismen:
5.1 Der doc_token: Ein zufaelliger Identifikator
Jedes Dokument erhaelt einen doc_token -- einen 128-Bit-Zufallscode im UUID4-Format (z.B. a7f3c2d1-4e9b-4a5f-8c7d-6b2e1f0a9d3c). Dieser Token:
- Ist kryptographisch zufaellig -- es gibt keinen Zusammenhang zwischen Token und Originaldatensatz
- Kann nicht zurueckgerechnet werden -- auch mit Kenntnis des Algorithmus ist kein Rueckschluss moeglich
- Dient als eindeutiger Schluessel, um Ergebnisse spaeter dem Originaldokument zuzuordnen
5.2 Header-Redaction: PII wird entfernt
Bei Dokumenten mit erkennbarem Kopfbereich (Namen, Adressen, IDs) kann das SDK diesen Bereich automatisch entfernen. Die Entfernung ist permanent: Die Originaldaten werden nicht an den Server uebermittelt.
| Methode | Wie es funktioniert | Wann verwenden |
|---|---|---|
| Einfache Redaction | Definierter Bereich des Dokuments wird entfernt | Standardisierte Formulare mit festem Layout |
| Smarte Redaction | OpenCV/NER erkennt Textbereiche mit PII und entfernt gezielt | Freitext-Dokumente, variable Layouts |
5.3 Die Identitaets-Map: Nur der Kunde kennt die Zuordnung
Die Zuordnung doc_token → Originaldaten wird als verschluesselte Tabellegespeichert. Das Datenmodell sieht vereinfacht so aus:
Datenmodell: Namespace-Session (vereinfacht)
NamespaceSession
├── tenant_id = "kunde-firma-abc" ← Pflichtfeld (Isolation)
├── encrypted_identity_map = [verschluesselte Bytes] ← Nur mit Passphrase lesbar
├── identity_map_iv = "a3f2c1..." ← Initialisierungsvektor (fuer AES)
│
└── PseudonymizedDocument (pro Dokument)
├── doc_token = "a7f3c2d1-..." ← Zufaelliger Token (Primary Key)
├── session_id = [Referenz]
└── (Kein Name, keine personenbezogenen Daten)DSGVO Art. 4 Nr. 5 konform
Die Pseudonymisierung erfuellt die Definition der DSGVO: Personenbezogene Daten koennen ohne Hinzuziehung zusaetzlicher Informationen(der verschluesselten Identitaets-Map + der Passphrase des Kunden) nicht mehr einer bestimmten Person zugeordnet werden.
6. Ende-zu-Ende-Verschluesselung
Die Verschluesselung ist das Herzstueck des Datenschutzes. Sie findet vollstaendig auf dem System des Kunden statt -- der Cloud-Server bekommt nur verschluesselte Daten zu sehen.
6.1 Der Verschluesselungsvorgang
Client-seitige Verschluesselung (im SDK)
┌─────────────────────────────────────────────────────────────────┐
│ System des Kunden (SDK) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Kunde konfiguriert Passphrase im SDK │
│ │ ↑ │
│ │ │ Passphrase bleibt hier -- wird NIE gesendet │
│ ▼ │
│ 2. Schluessel-Ableitung: │
│ PBKDF2-SHA256(Passphrase, zufaelliger Salt, 100.000 Runden) │
│ │ │
│ │ → Ergebnis: 256-Bit-Schluessel (32 Bytes) │
│ │ → 100.000 Runden machen Brute-Force unpraktikabel │
│ ▼ │
│ 3. Verschluesselung: │
│ AES-256-GCM(Schluessel, zufaelliger IV, Dokument) │
│ │ │
│ │ → AES-256: Militaerstandard, 2^256 moegliche Schluessel │
│ │ → GCM: Garantiert Integritaet (Manipulation erkennbar) │
│ ▼ │
│ 4. Schluessel-Hash: │
│ SHA-256(abgeleiteter Schluessel) → Hash fuer Verifikation │
│ │ │
│ │ → Server speichert nur diesen Hash │
│ │ → Damit kann geprueft werden ob die Passphrase stimmt │
│ │ → Vom Hash kann der Schluessel NICHT zurueckberechnet │
│ │ werden │
│ ▼ │
│ 5. Upload: Nur diese Daten gehen an den Cloud-Server: │
│ • Verschluesselter Blob (unlesbar ohne Schluessel) │
│ • Salt (zufaellige Bytes, harmlos) │
│ • IV (Initialisierungsvektor, harmlos) │
│ • Schluessel-Hash (zur Verifikation, nicht umkehrbar) │
│ │
│ Was NICHT an den Server geht: │
│ ✗ Passphrase │
│ ✗ Abgeleiteter Schluessel │
│ ✗ Unverschluesselter Klartext │
└─────────────────────────────────────────────────────────────────┘6.2 Sicherheitsgarantien
| Angriffsszenario | Was der Angreifer sieht | Ergebnis |
|---|---|---|
| Cloud-Server wird gehackt | Verschluesselte Blobs + Hashes | Keine lesbaren Dokumente |
| Datenbank wird geleakt | encrypted_identity_map (verschluesselt) | Keine personenbezogenen Daten |
| Netzwerkverkehr abgefangen | Verschluesselte Daten (TLS + AES) | Doppelt verschluesselt |
| Betreiber (Breakpilot) will mitlesen | Verschluesselte Blobs, kein Schluessel | Operator Blindness |
| Anderer Kunde versucht Zugriff | Nichts (Tenant-Isolation) | Namespace blockiert |
7. Namespace-Isolation: Jeder Kunde hat seinen eigenen Bereich
Ein Namespace (auch “Tenant” genannt) ist ein vollstaendig abgeschotteter Bereich im System. Man kann es sich wie separate Tresorraeume in einer Bank vorstellen: Jeder Kunde hat seinen eigenen Raum, und kein Schluessel passt in einen anderen.
7.1 Wie die Isolation funktioniert
Jeder Kunde erhaelt eine eindeutige tenant_id. Diese ID wird bei jeder einzelnen Datenbankabfrage als Pflichtfilter verwendet:
Tenant-Isolation in der Vektordatenbank (Qdrant)
Kunde A (tenant_id: "firma-alpha-001")
├── Dokument 1 (verschluesselt)
├── Dokument 2 (verschluesselt)
└── Referenz: Pruefkriterien 2025
Kunde B (tenant_id: "firma-beta-002")
├── Dokument 1 (verschluesselt)
└── Referenz: Compliance-Vorgaben 2025
Suchanfrage von Kunde A:
"Welche Klauseln weichen von den Referenzkriterien ab?"
→ Suche NUR in tenant_id = "firma-alpha-001"
→ Kunde B's Daten sind UNSICHTBAR
Jede Qdrant-Query hat diesen Pflichtfilter:
must_conditions = [
FieldCondition(key="tenant_id", match="firma-alpha-001")
]
Es gibt KEINE Abfrage ohne tenant_id-Filter.7.2 Drei Ebenen der Isolation
| Ebene | System | Isolation |
|---|---|---|
| Dateisystem | MinIO (S3-Storage) | Eigener Bucket/Pfad pro Kunde: /tenant-id/doc-id/encrypted.bin |
| Vektordatenbank | Qdrant | Pflichtfilter tenant_id bei jeder Suche |
| Metadaten-DB | PostgreSQL | Jede Tabelle hat tenant_id als Pflichtfeld |
Kein Training mit Kundendaten
Auf allen Vektoren in Qdrant ist das Flag
training_allowed: false gesetzt. Kundeninhalte werden ausschliesslich fuer RAG-Suchen innerhalb des Kunden-Namespace verwendet und niemals zum Trainieren eines KI-Modells eingesetzt.8. RAG-Pipeline: KI-Verarbeitung mit Kundenkontext
Die KI nutzt die vom Kunden hochgeladenen Referenzdokumente als Wissensbasis. Dieser Prozess heisst RAG (Retrieval Augmented Generation): Die KI “liest” zuerst die relevanten Referenzen und generiert dann kontextbezogene Ergebnisse.
8.1 Indexierung der Referenzdokumente
Indexierung: Vom Upload zum durchsuchbaren Referenzdokument
Referenzdokument (verschluesselt auf Server)
|
v
┌────────────────────────────────────┐
│ 1. Passphrase-Verifikation │ ← SDK sendet Schluessel-Hash
│ Hash pruefen │ Server vergleicht mit gespeichertem Hash
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 2. Entschluesselung │ ← Temporaer im Arbeitsspeicher
│ AES-256-GCM Decrypt │ (wird nach Verarbeitung geloescht)
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 3. Text-Extraktion │ ← PDF → Klartext
│ Tabellen, Listen, Absaetze │
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 4. Chunking │ ← Text in ~1.000-Zeichen-Abschnitte
│ Ueberlappung: 200 Zeichen │ (mit Ueberlappung fuer Kontexterhalt)
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 5. Embedding │ ← Jeder Abschnitt wird in einen
│ Text → 1.536 Zahlen │ Bedeutungsvektor umgewandelt
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 6. Re-Encryption │ ← Jeder Chunk wird ERNEUT verschluesselt
│ AES-256-GCM pro Chunk │ bevor er gespeichert wird
└──────────┬─────────────────────────┘
|
v
┌────────────────────────────────────┐
│ 7. Qdrant-Indexierung │ ← Vektor + verschluesselter Chunk
│ tenant_id: "firma-alpha-001" │ werden mit Tenant-Filter gespeichert
│ training_allowed: false │
└────────────────────────────────────┘8.2 Wie die KI eine Anfrage bearbeitet (RAG-Query)
- Anfrage formulieren: Das SDK sendet eine Suchanfrage mit dem zu verarbeitenden Dokument und den gewuenschten Kriterien.
- Semantische Suche: Die Anfrage wird in einen Vektor umgewandelt und gegen die Referenz-Vektoren in Qdrant gesucht -- nur im Namespace des Kunden.
- Entschluesselung: Die gefundenen Chunks werden mit der Passphrase des Kunden entschluesselt.
- KI-Antwort: Die entschluesselten Referenzpassagen werden als Kontext an die KI uebergeben, die daraus ein Ergebnis generiert.
9. Key Sharing: Zusammenarbeit ermoeglichen
In vielen Geschaeftsprozessen muessen mehrere Personen oder Abteilungen auf die gleichen Daten zugreifen -- z.B. fuer Vier-Augen-Prinzip, Qualitaetskontrolle oder externe Audits. Das Key-Sharing-System ermoeglicht es dem Eigentuemer, seinen Namespace sicher mit anderen zu teilen.
9.1 Einladungs-Workflow
Key Sharing: Sicheres Teilen zwischen Bearbeitern
Eigentuemer Server Eingeladener
│ │ │
│ 1. Einladung senden │ │
│ (E-Mail + Rolle + Scope) │ │
│─────────────────────────────────▶ │
│ │ │
│ │ 2. Einladung erstellt │
│ │ (14 Tage gueltig) │
│ │ │
│ │ 3. Benachrichtigung ──────▶│
│ │ │
│ │ 4. Einladung annehmen
│ │◀─────────────────────────────│
│ │ │
│ │ 5. Key-Share erstellt │
│ │ (verschluesselte │
│ │ Passphrase) │
│ │ │
│ │ 6. Eingeladener kann ──────▶│
│ │ jetzt Daten im │
│ │ Namespace abfragen │
│ │ │
│ 7. Zugriff widerrufen │ │
│ (jederzeit moeglich) │ │
│─────────────────────────────────▶ │
│ │ Share deaktiviert │9.2 Rollen beim Key-Sharing
| Rolle | Typischer Nutzer | Rechte |
|---|---|---|
| Owner | Projektverantwortlicher | Vollzugriff, kann teilen & widerrufen |
| Reviewer | Qualitaetssicherung | Lesen, RAG-Queries, eigene Anmerkungen |
| Auditor | Externer Pruefer | Nur Lesen (Aufsichtsfunktion) |
10. Audit-Trail: Vollstaendige Nachvollziehbarkeit
Jede Aktion im Namespace wird revisionssicher im Audit-Log gespeichert. Das ist essenziell fuer Compliance-Anforderungen und externe Audits.
| Event | Was protokolliert wird |
|---|---|
| upload | Dokument hochgeladen (Dateigroesse, Metadaten, Zeitstempel) |
| index | Referenzdokument indexiert (Anzahl Chunks, Dauer) |
| rag_query | RAG-Suchanfrage ausgefuehrt (Query-Hash, Anzahl Ergebnisse) |
| analyze | KI-Verarbeitung gestartet (Dokument-Token, Modell, Dauer) |
| share | Namespace mit anderem Nutzer geteilt (Empfaenger, Rolle) |
| revoke_share | Zugriff widerrufen (wer, wann) |
| decrypt | Ergebnis entschluesselt (durch wen, Zeitstempel) |
| delete | Dokument geloescht (Soft Delete, bleibt in Logs) |
11. API-Endpunkte (SDK-Referenz)
Die folgenden Endpunkte sind ueber das SDK oder direkt via REST ansprechbar. Authentifizierung erfolgt ueber API-Key + JWT-Token.
11.1 Namespace-Verwaltung
| Methode | Endpunkt | Beschreibung |
|---|---|---|
| POST | /api/v1/namespace/upload | Verschluesseltes Dokument hochladen |
| GET | /api/v1/namespace/documents | Eigene Dokumente auflisten |
| GET | /api/v1/namespace/documents/{id} | Einzelnes Dokument abrufen |
| DELETE | /api/v1/namespace/documents/{id} | Dokument loeschen (Soft Delete) |
11.2 Referenzdokumente & RAG
| Methode | Endpunkt | Beschreibung |
|---|---|---|
| POST | /api/v1/namespace/references/upload | Referenzdokument hochladen |
| POST | /api/v1/namespace/references/{id}/index | Referenz fuer RAG indexieren |
| POST | /api/v1/namespace/rag-query | RAG-Suchanfrage ausfuehren |
| POST | /api/v1/namespace/analyze | KI-Verarbeitung anstossen |
11.3 Key Sharing
| Methode | Endpunkt | Beschreibung |
|---|---|---|
| POST | /api/v1/namespace/share | Namespace mit anderem Nutzer teilen |
| GET | /api/v1/namespace/shares | Aktive Shares auflisten |
| DELETE | /api/v1/namespace/shares/{shareId} | Zugriff widerrufen |
| GET | /api/v1/namespace/shared-with-me | Mit mir geteilte Namespaces |
12. Zusammenfassung: Compliance-Garantien
| Garantie | Wie umgesetzt | Regelwerk |
|---|---|---|
| Keine PII verlaesst das Kundensystem | Header-Redaction + verschluesselte Identity-Map | DSGVO Art. 4 Nr. 5 |
| Betreiber kann nicht mitlesen | Client-seitige AES-256-GCM Verschluesselung | DSGVO Art. 32 |
| Kein Zugriff durch andere Kunden | Tenant-Isolation (Namespace) auf allen 3 Ebenen | DSGVO Art. 25 |
| Kein KI-Training mit Kundendaten | training_allowed: false auf allen Vektoren | AI Act Art. 10 |
| Alles nachvollziehbar | Vollstaendiger Audit-Trail aller Aktionen | DSGVO Art. 5 Abs. 2 |
| Kunde behaelt volle Kontrolle | Jederzeitiger Widerruf, Loeschung, Datenexport | DSGVO Art. 17, 20 |
Das Wichtigste in einem Satz
Die Namespace-Technologie ermoeglicht KI-gestuetzte Datenverarbeitung in der Cloud, bei der keine personenbezogenen Daten das Kundensystem verlassen, alle Daten Ende-zu-Ende verschluesselt sind, jeder Kunde seinen eigenen abgeschotteten Namespace hat, und ein vollstaendiger Audit-Trail jede Aktion dokumentiert.