import { DevPortalLayout, CodeBlock, InfoBox } from '@/components/DevPortalLayout' export default function BYOEHDocsPage() { return ( {/* ============================================================ */} {/* 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:

  1. Pseudonymisierung: Personenbezogene Daten werden durch zufaellige Tokens ersetzt. Nur der Kunde kennt die Zuordnung.
  2. Client-seitige Verschluesselung: Alle Daten werden auf dem System des Kunden verschluesselt, bevor sie die Infrastruktur verlassen. Der Cloud-Server sieht nur verschluesselte Blobs.
  3. Namespace-Isolation: Jeder Kunde erhaelt einen eigenen, vollstaendig abgeschotteten Namespace. Kein Kunde kann auf Daten eines anderen zugreifen.
  4. 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 */} {/* ============================================================ */}

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:

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 / TENANT-ISOLATION */} {/* ============================================================ */}

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
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 */} {/* ============================================================ */}

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)

  1. Anfrage formulieren: Das SDK sendet eine Suchanfrage mit dem zu verarbeitenden Dokument und den gewuenschten Kriterien.
  2. Semantische Suche: Die Anfrage wird in einen Vektor umgewandelt und gegen die Referenz-Vektoren in Qdrant gesucht -- nur im Namespace des Kunden.
  3. Entschluesselung: Die gefundenen Chunks werden mit der Passphrase des Kunden entschluesselt.
  4. 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
OwnerProjektverantwortlicherVollzugriff, kann teilen & widerrufen
ReviewerQualitaetssicherungLesen, RAG-Queries, eigene Anmerkungen
AuditorExterner PrueferNur Lesen (Aufsichtsfunktion)
{/* ============================================================ */} {/* 10. AUDIT-TRAIL */} {/* ============================================================ */}

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
uploadDokument hochgeladen (Dateigroesse, Metadaten, Zeitstempel)
indexReferenzdokument indexiert (Anzahl Chunks, Dauer)
rag_queryRAG-Suchanfrage ausgefuehrt (Query-Hash, Anzahl Ergebnisse)
analyzeKI-Verarbeitung gestartet (Dokument-Token, Modell, Dauer)
shareNamespace mit anderem Nutzer geteilt (Empfaenger, Rolle)
revoke_shareZugriff widerrufen (wer, wann)
decryptErgebnis entschluesselt (durch wen, Zeitstempel)
deleteDokument geloescht (Soft Delete, bleibt in Logs)
{/* ============================================================ */} {/* 11. API-ENDPUNKTE */} {/* ============================================================ */}

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/uploadVerschluesseltes Dokument hochladen
GET/api/v1/namespace/documentsEigene 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/uploadReferenzdokument hochladen
POST/api/v1/namespace/references/{'{id}'}/indexReferenz fuer RAG indexieren
POST/api/v1/namespace/rag-queryRAG-Suchanfrage ausfuehren
POST/api/v1/namespace/analyzeKI-Verarbeitung anstossen

11.3 Key Sharing

Methode Endpunkt Beschreibung
POST/api/v1/namespace/shareNamespace mit anderem Nutzer teilen
GET/api/v1/namespace/sharesAktive Shares auflisten
DELETE/api/v1/namespace/shares/{'{shareId}'}Zugriff widerrufen
GET/api/v1/namespace/shared-with-meMit mir geteilte Namespaces
{/* ============================================================ */} {/* 12. ZUSAMMENFASSUNG */} {/* ============================================================ */}

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
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.
) }