+ {/* ============================================================ */}
+ {/* 1. EINLEITUNG */}
+ {/* ============================================================ */}
+ 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.
+
+
+
+
+ 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. ANWENDUNGSFAELLE */}
+ {/* ============================================================ */}
+ 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:
+
+
+
+{`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 bereit`}
+
+
+ {/* ============================================================ */}
+ {/* 4. SDK-INTEGRATION */}
+ {/* ============================================================ */}
+ 4. SDK-Integration
+
+ Die Integration in bestehende Systeme erfolgt ueber unser SDK. Nachfolgend ein
+ vereinfachtes Beispiel, wie ein Kunde das SDK nutzt:
+
+
+
+{`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]`}
+
+
+
+ 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 */}
+ {/* ============================================================ */}
+ 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 Tabelle
+ gespeichert. Das Datenmodell sieht vereinfacht so aus:
+
+
+
+{`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)`}
+
+
+
+ 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. VERSCHLUESSELUNG */}
+ {/* ============================================================ */}
+ 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
+
+
+{`┌─────────────────────────────────────────────────────────────────┐
+│ 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:
+
+
+
+{`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 |
+
+
+
+
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 */}
+ {/* ============================================================ */}
+ 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
+
+{`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 */}
+ {/* ============================================================ */}
+ 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
+
+{`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 |
+
+
+
+