docs: Add BYOEH system documentation to Developer Portal and MKDocs

Adds comprehensive BYOEH (Bring-Your-Own-Expectation-Horizon) architecture
documentation explaining the privacy-first KI exam correction workflow
including pseudonymization, client-side encryption, and namespace isolation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs-src/services/klausur-service/byoeh-system-erklaerung.md

@@ -0,0 +1,456 @@
+# Wie funktioniert das Klausur-Namespace-System?
+
+Eine umfassende Erklaerung des BYOEH-Systems -- von der Anonymisierung bis zur sicheren KI-Korrektur.
+
+---
+
+## 1. Was ist das Namespace-System?
+
+Das **BYOEH-System** (Bring Your Own Expectation Horizon) ist eine Datenschutz-Architektur, die es Lehrern ermoeglicht, Klausuren **anonym und verschluesselt** von einer KI korrigieren zu lassen -- ohne dass jemals der Name eines Schuelers den Rechner des Lehrers verlaesst.
+
+> *"Die Klausuren gehen anonym in die Cloud, werden dort von KI korrigiert, und kommen korrigiert zurueck. Nur der Lehrer kann die Ergebnisse wieder den Schuelern zuordnen -- denn nur seine Hardware hat den Schluessel dafuer."*
+
+Das System loest ein grundlegendes Problem: Klausurkorrektur mit KI-Unterstuetzung **ohne Datenschutzrisiko**. Die Loesung besteht aus vier Bausteinen:
+
+1. **Pseudonymisierung:** Namen werden durch zufaellige Codes ersetzt. Niemand ausser dem Lehrer kennt die Zuordnung.
+2. **Verschluesselung:** Alles wird *im Browser des Lehrers* verschluesselt, bevor es den Rechner verlaesst. Der Server sieht nur unlesbaren Datensalat.
+3. **Namespace-Isolation:** Jeder Lehrer hat einen eigenen, abgeschotteten Bereich (Namespace). Kein Lehrer kann auf die Daten eines anderen zugreifen.
+4. **KI-Korrektur:** Die KI arbeitet mit den verschluesselten Daten und dem Erwartungshorizont (EH) des Lehrers. Korrekturvorschlaege gehen zurueck an den Lehrer.
+
+!!! info "Kern-Designprinzip: Operator Blindness"
+    **Breakpilot kann die Klausuren nicht lesen.** Der Server sieht nur verschluesselte Daten und einen Schluessel-Hash (nicht den Schluessel selbst). Die Passphrase zum Entschluesseln existiert *nur* im Browser des Lehrers und wird niemals uebertragen. Selbst ein Angriff auf den Server wuerde keine Klausurtexte preisgeben.
+
+---
+
+## 2. Der komplette Ablauf im Ueberblick
+
+Der Prozess laesst sich in sieben Schritte unterteilen. Stellen Sie sich vor, der Lehrer sitzt an seinem Rechner und hat einen Stapel gescannter Klausuren:
+
+```text title="Der komplette Workflow: Von der Klausur zur KI-Korrektur"
+SCHRITT 1: KLAUSUREN SCANNEN & HOCHLADEN
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Lehrer scannt Klausuren ein (PDF oder Bild)
+  → System erkennt automatisch den Kopfbereich mit Namen
+  → Kopfbereich wird permanent entfernt (Header-Redaction)
+  → Jede Klausur erhaelt einen zufaelligen Code (doc_token)
+
+SCHRITT 2: VERSCHLUESSELUNG IM BROWSER
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Lehrer gibt eine Passphrase ein (z.B. "MeinGeheimesPasswort2025!")
+  → Browser leitet daraus einen 256-Bit-Schluessel ab (PBKDF2)
+  → Klausur wird mit AES-256-GCM verschluesselt
+  → Nur der Hash des Schluessels wird an den Server gesendet
+  → Passphrase und Schluessel verlassen NIEMALS den Browser
+
+SCHRITT 3: IDENTITAETS-MAP SICHERN
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Die Zuordnung "doc_token → Schuelername" wird verschluesselt:
+  → Tabelle: "a7f3c2d1... = Max Mustermann, b9e4a1f8... = Anna Schmidt"
+  → Diese Tabelle wird mit dem gleichen Schluessel verschluesselt
+  → Ohne Passphrase kann niemand die Zuordnung wiederherstellen
+
+SCHRITT 4: UPLOAD IN DEN NAMESPACE
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Die verschluesselten Dateien gehen in den persoenlichen Namespace:
+  → Jeder Lehrer hat eine eigene tenant_id
+  → Daten werden in MinIO (verschluesselt) + Qdrant (Vektoren) gespeichert
+  → Server sieht: verschluesselter Blob + Schluessel-Hash + Salt
+
+SCHRITT 5: KI-KORREKTUR
+━━━━━━━━━━━━━━━━━━━━━━━
+Der Lehrer startet die KI-Korrektur:
+  → RAG-System durchsucht den Erwartungshorizont (EH)
+  → KI generiert Korrekturvorschlaege pro Kriterium
+  → Vorschlaege basieren auf dem EH, nicht auf Halluzinationen
+
+SCHRITT 6: ERGEBNISSE ZURUECK
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Korrekturvorschlaege gehen an den Lehrer:
+  → Lehrer gibt Passphrase ein
+  → Browser entschluesselt die Ergebnisse
+  → Lehrer sieht: Vorschlaege pro Kriterium + Gesamtnote
+
+SCHRITT 7: ZUORDNUNG & FINALISIERUNG
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Lehrer ordnet Ergebnisse den Schuelern zu:
+  → Identitaets-Map wird entschluesselt
+  → doc_token wird wieder dem echten Namen zugeordnet
+  → Lehrer ueberprueft/korrigiert KI-Vorschlaege
+  → Fertige Korrektur + Gutachten koennen exportiert werden
+```
+
+---
+
+## 3. Pseudonymisierung: Wie Namen verschwinden
+
+Pseudonymisierung bedeutet: personenbezogene Daten werden durch **zufaellige Codes** ersetzt, sodass ohne Zusatzinformation kein Rueckschluss auf die Person moeglich ist. Im BYOEH-System passiert das auf zwei Ebenen:
+
+### 3.1 Der doc_token: Ein zufaelliger Ausweis
+
+Jede Klausur erhaelt einen **doc_token** -- einen 128-Bit-Zufallscode im UUID4-Format (z.B. `a7f3c2d1-4e9b-4a5f-8c7d-6b2e1f0a9d3c`). Dieser Code:
+
+- Ist **kryptographisch zufaellig** -- es gibt keinen Zusammenhang zwischen Token und Schueler
+- Kann **nicht zurueckgerechnet** werden -- auch mit Kenntnis des Algorithmus ist kein Rueckschluss moeglich
+- Wird **auf der Klausur aufgedruckt** (als QR-Code), damit die physische Klausur spaeter wieder zugeordnet werden kann
+
+### 3.2 Header-Redaction: Der Name wird entfernt
+
+Bevor eine Klausur verarbeitet wird, entfernt das System den **Kopfbereich** der gescannten Seite -- dort, wo typischerweise Name, Klasse und Datum stehen. Diese Entfernung ist **permanent**: Die Originaldaten werden nicht gespeichert.
+
+| Methode | Wie es funktioniert | Wann verwendet |
+|---------|---------------------|----------------|
+| **Einfache Redaction** | Obere ~2,5 cm der Seite werden weiss ueberschrieben | Standard bei allen Uploads |
+| **Smarte Redaction** | OpenCV erkennt Textbereiche und entfernt gezielt den Kopf, verschont aber QR-Codes | Wenn QR-Codes auf der Klausur sind |
+
+### 3.3 Die Identitaets-Map: Nur der Lehrer kennt die Zuordnung
+
+Die Zuordnung *doc_token → Schuelername* wird als **verschluesselte Tabelle** gespeichert:
+
+```text title="Datenbank: ExamSession (vereinfacht)"
+ExamSession
+├── teacher_id            = "lehrer-uuid-123"     ← Pflichtfeld (Isolation)
+├── encrypted_identity_map = [verschluesselte Bytes]  ← Nur mit Passphrase lesbar
+├── identity_map_iv       = "a3f2c1..."           ← Initialisierungsvektor (fuer AES)
+│
+└── PseudonymizedDocument (pro Klausur)
+    ├── doc_token          = "a7f3c2d1-..."       ← Zufaelliger Code (Primary Key)
+    ├── exam_session_id    = [Referenz]
+    └── (Kein Name, keine Klasse, kein persoenliches Datum)
+```
+
+!!! success "DSGVO Art. 4 Nr. 5 konform"
+    Die Pseudonymisierung erfuellt die Definition aus der DSGVO: Die personenbezogenen Daten (Schuelernamen) koennen **ohne Hinzuziehung zusaetzlicher Informationen** (der verschluesselten Identitaets-Map + der Passphrase des Lehrers) nicht mehr einer bestimmten Person zugeordnet werden.
+
+---
+
+## 4. Verschluesselung: Wie Daten geschuetzt werden
+
+Die Verschluesselung ist das Herzstueck des Datenschutzes. Sie findet **vollstaendig im Browser** statt -- der Server bekommt nur verschluesselte Daten zu sehen.
+
+### 4.1 Der Verschluesselungsvorgang
+
+Wenn der Lehrer eine Klausur oder einen Erwartungshorizont hochlaedt, passiert im Browser folgendes:
+
+```text title="Client-seitige Verschluesselung (im Browser)"
+┌─────────────────────────────────────────────────────────────────┐
+│                    Browser des Lehrers                           │
+├─────────────────────────────────────────────────────────────────┤
+│                                                                 │
+│  1. Lehrer gibt Passphrase ein (z.B. "MeinGeheimesPasswort!")   │
+│     │           ↑                                               │
+│     │           │ Passphrase bleibt hier -- wird NIE gesendet   │
+│     ▼                                                           │
+│  2. Schluessel-Ableitung:                                       │
+│     PBKDF2-SHA256(Passphrase, zufaelliger Salt, 100.000 Runden) │
+│     │                                                           │
+│     │  → Ergebnis: 256-Bit-Schluessel (32 Bytes)                │
+│     │  → Selbst bei Kenntnis des Salts sind 100.000 Runden      │
+│     │    noetig, um den Schluessel zu erraten                    │
+│     ▼                                                           │
+│  3. Verschluesselung:                                           │
+│     AES-256-GCM(Schluessel, zufaelliger IV, Datei-Inhalt)       │
+│     │                                                           │
+│     │  → AES-256: Militaerstandard, 2^256 moegliche Schluessel  │
+│     │  → GCM: Garantiert Integritaet (Manipulation erkennbar)   │
+│     ▼                                                           │
+│  4. Schluessel-Hash:                                            │
+│     SHA-256(abgeleiteter Schluessel) → Hash fuer Verifikation   │
+│     │                                                           │
+│     │  → Der Server speichert nur diesen Hash                   │
+│     │  → Damit kann geprueft werden ob die Passphrase stimmt    │
+│     │  → Vom Hash kann der Schluessel NICHT zurueckgerechnet    │
+│     │    werden                                                 │
+│     ▼                                                           │
+│  5. Upload: Nur diese Daten gehen an den 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                               │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### 4.2 Warum ist das sicher?
+
+| Angriffsszenario | Was der Angreifer sieht | Ergebnis |
+|------------------|-------------------------|----------|
+| **Server wird gehackt** | Verschluesselte Blobs + Hashes | Keine lesbaren Klausuren |
+| **Datenbank wird geleakt** | encrypted_identity_map (verschluesselt) | Keine Schuelernamen |
+| **Netzwerkverkehr abgefangen** | Verschluesselte Daten (HTTPS + AES) | Doppelt verschluesselt |
+| **Betreiber will mitlesen** | Verschluesselte Blobs, kein Schluessel | Operator Blindness |
+| **Anderer Lehrer versucht Zugriff** | Nichts (Tenant-Isolation) | Namespace blockiert |
+
+---
+
+## 5. Namespace-Isolation: Jeder Lehrer hat seinen eigenen Bereich
+
+Ein **Namespace** (auch "Tenant" genannt) ist ein abgeschotteter Bereich im System. Man kann es sich wie **separate Schliessfaecher** in einer Bank vorstellen: Jeder Lehrer hat sein eigenes Fach, und kein Schluessel passt in ein anderes Fach.
+
+### 5.1 Wie die Isolation funktioniert
+
+Jeder Lehrer erhaelt beim ersten Login eine eindeutige `tenant_id`. Diese ID wird bei **jeder einzelnen Datenbankabfrage** als Pflichtfilter mitgefuehrt:
+
+```text title="Tenant-Isolation in der Vektordatenbank (Qdrant)"
+Lehrer A (tenant_id: "school-A-lehrer-1")
+├── Klausur 1 (verschluesselt)
+├── Klausur 2 (verschluesselt)
+└── Erwartungshorizont Deutsch LK 2025
+
+Lehrer B (tenant_id: "school-B-lehrer-2")
+├── Klausur 1 (verschluesselt)
+└── Erwartungshorizont Mathe GK 2025
+
+Suchanfrage von Lehrer A:
+  "Wie soll die Einleitung strukturiert sein?"
+  → Suche NUR in tenant_id = "school-A-lehrer-1"
+  → Lehrer B's Daten sind UNSICHTBAR
+
+Es gibt KEINE Abfrage ohne tenant_id-Filter.
+```
+
+### 5.2 Drei Ebenen der Isolation
+
+| Ebene | System | Isolation |
+|-------|--------|-----------|
+| **Dateisystem** | MinIO (S3-Storage) | Eigener Ordner pro Lehrer: `/tenant-id/eh-id/encrypted.bin` |
+| **Vektordatenbank** | Qdrant | Pflichtfilter `tenant_id` bei jeder Suche |
+| **Metadaten-DB** | PostgreSQL | Jede Tabelle hat `teacher_id` als Pflichtfeld |
+
+!!! warning "Kein Training mit Lehrerdaten"
+    Auf allen Vektoren in Qdrant ist das Flag `training_allowed: false` gesetzt. Das bedeutet: Die Inhalte der Lehrer werden **ausschliesslich fuer RAG-Suchen** (Abruf relevanter Textpassagen) verwendet und **niemals zum Trainieren** eines KI-Modells eingesetzt.
+
+---
+
+## 6. Der Erwartungshorizont: Die Grundlage fuer KI-Korrektur
+
+Ein **Erwartungshorizont** (EH) ist das Dokument, das beschreibt, was in einer Klausur erwartet wird: welche Inhalte in welcher Qualitaet vorkommen sollen. Im BYOEH-System laedt der Lehrer seinen eigenen EH hoch, und die KI nutzt ihn als Referenz fuer Korrekturvorschlaege.
+
+### 6.1 Upload-Wizard (5 Schritte)
+
+| Schritt | Was passiert | Warum |
+|---------|--------------|-------|
+| **1. Datei waehlen** | PDF per Drag & Drop hochladen | Der EH als digitales Dokument |
+| **2. Metadaten** | Titel, Fach, Niveau (eA/gA), Jahr | Fuer Filterung und Organisation |
+| **3. Rechtebestaetigung** | Checkbox: "Ich bin berechtigt" | Rechtliche Absicherung (Urheberrecht) |
+| **4. Verschluesselung** | Passphrase eingeben (2x bestaetigen) | Schluessel fuer Ende-zu-Ende-Verschluesselung |
+| **5. Zusammenfassung** | Pruefen und bestaetigen | Letzte Kontrolle vor dem Upload |
+
+### 6.2 RAG-Pipeline: Wie der EH fuer die KI nutzbar wird
+
+Nach dem Upload wird der EH fuer die KI-Suche vorbereitet. Dieser Vorgang heisst **Indexierung** und funktioniert wie das Erstellen eines Stichwortverzeichnisses fuer ein Buch:
+
+```text title="Indexierung: Vom PDF zum durchsuchbaren EH"
+Erwartungshorizont (verschluesselt auf Server)
+     |
+     v
+┌────────────────────────────────┐
+│  1. Passphrase-Verifikation    │  ← Lehrer gibt Passphrase ein
+│     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 erkennen  │
+└──────────┬─────────────────────┘
+           |
+           v
+┌────────────────────────────────┐
+│  4. Chunking                   │  ← Text in 1.000-Zeichen-Abschnitte zerlegen
+│     Ueberlappung: 200 Zeichen  │     (mit Ueberlappung fuer Kontext)
+└──────────┬─────────────────────┘
+           |
+           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: "lehrer-123"    │     werden mit Tenant-Filter gespeichert
+│     training_allowed: false    │
+└────────────────────────────────┘
+```
+
+### 6.3 Wie die KI den EH nutzt (RAG-Query)
+
+Wenn der Lehrer bei der Korrektur einen Vorschlag anfordert, passiert folgendes:
+
+1. **Frage formulieren:** Das System erstellt eine Suchanfrage aus dem Klausurtext und dem aktuellen Bewertungskriterium.
+2. **Semantische Suche:** Die Anfrage wird in einen Vektor umgewandelt und gegen die EH-Vektoren in Qdrant gesucht -- *nur im Namespace des Lehrers*.
+3. **Entschluesselung:** Die gefundenen Chunks werden mit der Passphrase des Lehrers entschluesselt.
+4. **KI-Antwort:** Die entschluesselten EH-Passagen werden als Kontext an die KI uebergeben, die daraus einen Korrekturvorschlag generiert.
+
+---
+
+## 7. Key Sharing: Zweitkorrektur ermoeglichen
+
+Bei Abiturklausuren muss eine **Zweitkorrektur** durch einen anderen Lehrer erfolgen. Das Key-Sharing-System ermoeglicht es dem Erstpruefer, seinen Erwartungshorizont sicher mit dem Zweitpruefer zu teilen -- ohne die Verschluesselung aufzugeben.
+
+### 7.1 Einladungs-Workflow
+
+```text title="Key Sharing: Sicheres Teilen zwischen Pruefern"
+Erstpruefer                        Server                     Zweitpruefer
+     │                                │                             │
+     │  1. Einladung senden            │                             │
+     │     (E-Mail + Rolle + Klausur)  │                             │
+     │─────────────────────────────────▶                             │
+     │                                │                             │
+     │                                │  2. Einladung erstellt       │
+     │                                │     (14 Tage gueltig)        │
+     │                                │                             │
+     │                                │  3. Benachrichtigung ──────▶│
+     │                                │                             │
+     │                                │                      4. Annehmen
+     │                                │◀─────────────────────────────│
+     │                                │                             │
+     │                                │  5. Key-Share erstellt       │
+     │                                │                             │
+     │                                │  6. Zweitpruefer kann ──────▶│
+     │                                │     RAG-Queries ausfuehren   │
+     │                                │                             │
+     │  7. Zugriff widerrufen          │                             │
+     │     (jederzeit moeglich)       │                             │
+     │─────────────────────────────────▶                             │
+```
+
+### 7.2 Rollen beim Key-Sharing
+
+| Rolle | Wer | Rechte |
+|-------|-----|--------|
+| **Erstpruefer (EK)** | Kurslehrer | Vollzugriff, kann teilen & widerrufen |
+| **Zweitpruefer (ZK)** | Anderer Fachlehrer | Nur Lesen, RAG-Queries, eigene Annotations |
+| **Drittpruefer (DK)** | Bei Differenz ≥ 4 Punkte | Nur Lesen, RAG-Queries |
+| **Fachvorsitz** | Fachbereichsleitung | Nur Lesen (Aufsichtsfunktion) |
+
+---
+
+## 8. KI-gestuetzte Bewertung: Wie die Korrektur funktioniert
+
+Die KI bewertet jede Klausur anhand von **fuenf Kriterien**, die zusammen 100% ergeben:
+
+| Kriterium | Gewichtung | Was geprueft wird |
+|-----------|------------|-------------------|
+| Rechtschreibung | 15% | Orthographie, Zeichensetzung |
+| Grammatik | 15% | Satzbau, Kongruenz, Tempus |
+| **Inhalt** | **40%** | Bezug zum EH, Vollstaendigkeit, Argumentation |
+| Struktur | 15% | Gliederung, Einleitung/Schluss, roter Faden |
+| Stil | 15% | Ausdruck, Wortwahl, Fachsprache |
+
+Die Bewertung folgt dem **15-Punkte-System** (0-15 Notenpunkte) der gymnasialen Oberstufe.
+
+!!! info "KI schlaegt vor, Lehrer entscheidet"
+    Alle KI-Bewertungen sind **Vorschlaege**. Der Lehrer hat bei jedem Kriterium die volle Kontrolle: Er kann den Vorschlag annehmen, aendern oder komplett ueberschreiben. Die finale Note setzt immer der Lehrer.
+
+---
+
+## 9. Audit-Trail: Alles wird protokolliert
+
+Jede Aktion im System wird revisionssicher im **Audit-Log** gespeichert. Das ist wichtig fuer die Nachvollziehbarkeit und fuer den Fall, dass Schueler oder Eltern eine Korrektur anfechten.
+
+| Aktion | Was protokolliert wird |
+|--------|------------------------|
+| `upload` | EH hochgeladen (Dateigroesse, Metadaten, Zeitstempel) |
+| `index` | EH fuer RAG indexiert (Anzahl Chunks, Dauer) |
+| `rag_query` | RAG-Suchanfrage ausgefuehrt (Query-Hash, Anzahl Ergebnisse, Score) |
+| `share` | EH mit anderem Pruefer geteilt (Empfaenger, Rolle) |
+| `revoke_share` | Zugriff widerrufen (wer, wann) |
+| `link_klausur` | EH mit Klausur verknuepft |
+| `delete` | EH geloescht (Soft Delete, bleibt in Logs) |
+
+---
+
+## 10. API-Endpunkte (Technische Referenz)
+
+Alle Endpunkte laufen ueber den **klausur-service** auf Port 8086.
+
+### 10.1 Erwartungshorizont-Verwaltung
+
+| Methode | Endpunkt | Beschreibung |
+|---------|----------|--------------|
+| `POST` | `/api/v1/eh/upload` | Verschluesselten EH hochladen |
+| `GET` | `/api/v1/eh` | Eigene EHs auflisten |
+| `GET` | `/api/v1/eh/{id}` | Einzelnen EH abrufen |
+| `DELETE` | `/api/v1/eh/{id}` | EH loeschen (Soft Delete) |
+| `POST` | `/api/v1/eh/{id}/index` | EH fuer RAG indexieren |
+| `POST` | `/api/v1/eh/rag-query` | RAG-Suchanfrage ausfuehren |
+
+### 10.2 Key Sharing
+
+| Methode | Endpunkt | Beschreibung |
+|---------|----------|--------------|
+| `POST` | `/api/v1/eh/{id}/share` | EH mit Pruefer teilen |
+| `GET` | `/api/v1/eh/{id}/shares` | Geteilte Zugriffe auflisten |
+| `DELETE` | `/api/v1/eh/{id}/shares/{shareId}` | Zugriff widerrufen |
+| `GET` | `/api/v1/eh/shared-with-me` | Mit mir geteilte EHs |
+
+### 10.3 Klausur-Integration
+
+| Methode | Endpunkt | Beschreibung |
+|---------|----------|--------------|
+| `POST` | `/api/v1/eh/{id}/link-klausur` | EH mit Klausur verknuepfen |
+| `DELETE` | `/api/v1/eh/{id}/link-klausur/{klausurId}` | Verknuepfung loesen |
+| `GET` | `/api/v1/klausuren/{id}/linked-eh` | Verknuepften EH abrufen |
+
+---
+
+## 11. Dateistruktur im Code
+
+```text title="Relevante Dateien im Repository"
+klausur-service/
+├── backend/
+│   ├── main.py                 # API-Endpunkte + Datenmodelle
+│   ├── qdrant_service.py       # Vektordatenbank-Operationen (Tenant-Filter)
+│   └── eh_pipeline.py          # Chunking, Embedding, Verschluesselung
+│
+├── frontend/
+│   └── src/
+│       ├── components/
+│       │   └── EHUploadWizard.tsx    # 5-Schritt-Upload-Wizard
+│       └── services/
+│           ├── api.ts                # API-Client
+│           └── encryption.ts         # Client-seitige Kryptographie
+│
+└── docs/
+    ├── BYOEH-Architecture.md         # Technische Architektur
+    └── BYOEH-Developer-Guide.md      # Entwickler-Handbuch
+
+backend/klausur/
+├── db_models.py                # ExamSession, PseudonymizedDocument
+└── services/
+    └── pseudonymizer.py        # QR-Codes, Header-Redaction, doc_tokens
+```
+
+---
+
+## 12. Zusammenfassung: Die Sicherheitsgarantien
+
+| Garantie | Wie umgesetzt | Regelwerk |
+|----------|---------------|-----------|
+| **Kein Name verlaesst den Rechner** | 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 Lehrer** | Tenant-Isolation (Namespace) auf allen 3 Ebenen | DSGVO Art. 25 |
+| **Kein KI-Training mit Schuelerdaten** | `training_allowed: false` auf allen Vektoren | AI Act Art. 10 |
+| **Alles nachvollziehbar** | Vollstaendiger Audit-Trail aller Aktionen | DSGVO Art. 5 Abs. 2 |
+| **Lehrer behaelt volle Kontrolle** | KI-Vorschlaege, keine KI-Entscheidungen + jederzeitiger Widerruf | DSGVO Art. 22 |
+
+!!! success "Das Wichtigste in einem Satz"
+    Das BYOEH-System ermoeglicht KI-gestuetzte Klausurkorrektur, bei der **kein Schuelername den Rechner des Lehrers verlaesst**, alle Daten **Ende-zu-Ende verschluesselt** sind, jeder Lehrer seinen **eigenen abgeschotteten Namespace** hat, und die KI **nur Vorschlaege macht** -- die finale Bewertung trifft immer der Lehrer.