114 lines
6.1 KiB
Markdown
114 lines
6.1 KiB
Markdown
---
|
||
title: "Kanshō – Privacy Gateway und AI-Egress"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-19"
|
||
product_family: "Jinkendo"
|
||
document_role: "Technical Chapter / Privacy Gateway / Egress"
|
||
parent_document: "technische_zielarchitektur.md"
|
||
---
|
||
# Kanshō – Privacy Gateway und AI-Egress
|
||
|
||
Technische Abbildung der fachlichen Guardrails. Kanonisches Fachhome: `../functional/guardrails.md` (inkl. Root Cause §2, Datenklassen §5, Gateway §6, Entscheidungsstand §22). Dieses Kapitel dupliziert die Herleitung nicht.
|
||
|
||
**Rang:** Datenschutz und Guardrails sind im Fachkonzept **grundlegend und entschieden**. Sie stehen nicht auf derselben Ebene wie unfertige Dialog- oder MVP-Schnitte. Offene Punkte betreffen Verfahren und rechtliche Ausprägung (Entity Detection, Encryption at rest, DSFA), nicht die Invariante selbst.
|
||
|
||
## 1. Invariante
|
||
|
||
> Identität bleibt lokal. Externe Intelligenz erhält nur den für die Aufgabe notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.
|
||
|
||
Herkunft: `guardrails.md` §2.4; querschnittlich in der fachlichen Zielarchitektur. Providerunabhängig: OpenRouter ist Kandidat, kein Ersatz für das lokale Gateway. OpenRouter-eigene Guardrail-Features ergänzen höchstens, sie ersetzen die Kanshō-Schicht nicht.
|
||
|
||
Pseudonymisierung ist keine Anonymisierung. Kanshō behauptet keine vollständige Anonymität nach außen.
|
||
|
||
Persönlicher Kontext wird **nie** direkt aus UI, Dialog-Router, Prompt-Engine oder Admin-Preview an OpenRouter, Provider oder Tools gesendet. Die Engine darf den Provider nur über den Gateway-Callback erreichen (`platform_extensibility.md`).
|
||
|
||
### 1.1 Guardrail-Vorrang
|
||
|
||
Fachlich §19: Guardrails haben Vorrang vor Modellqualität, Kosten, Latenz, Komfort und automatischem Provider-Fallback. Eine Anfrage wird abgelehnt oder degradiert, wenn die Policy nicht erfüllbar ist. Administrierbare Prompts, Workflows oder Feature-Flags dürfen das Gateway nicht abschalten.
|
||
|
||
## 2. Trust Zones
|
||
|
||
| Zone | Inhalt | Egress |
|
||
|---|---|---|
|
||
| Local Trusted Zone | Identity Mapping, Klarnamen, Secrets, volle Primärquellen, Obsidian-Pfade | kein Roh-Egress |
|
||
| External AI Zone | External Model Context (Klasse B) | nur nach Policy-Check, ZDR |
|
||
| Tool-/Plugin-Zone | Suche, Plugins, Speech | eigene Policy, nicht implizit mit LLM-Freigabe |
|
||
|
||
## 3. Datenklassen
|
||
|
||
- **A Local Only:** Mapping, Secrets, vollständige Identität, interne IDs soweit identifizierend. Verlassen die Trusted Zone nicht.
|
||
- **B Pseudonymized AI Context:** Normalfall persönlicher Dialoge. Stabile, nicht sprechende Platzhalter (`[[SELF]]`, `[[PERSON:PARTNER]]`). Minimierung zusätzlich zur Maskierung.
|
||
- **C Low-Identity:** generische, nicht-personalisierte Inhalte; schwächere Transformation zulässig, eigene Policy bleibt nötig.
|
||
|
||
Quasi-Identifikatoren (Beruf+Ort+Familie) sind fachlich erkannt; die Bewertungsmethode ist offen, der Gateway-Auftrag „nicht nur Klarnamen“ gilt trotzdem.
|
||
|
||
## 4. Pflichtpipeline
|
||
|
||
Jeder persönliche Modellaufruf durchläuft lokal:
|
||
|
||
1. Context Minimization
|
||
2. Entity Detection
|
||
3. Pseudonymization
|
||
4. Policy Check
|
||
5. Provider/Endpoint Eligibility (ZDR, kein Training, kein Prompt-Logging)
|
||
6. Egress Validation
|
||
7. Response Validation
|
||
8. Local Rehydration / Demasking
|
||
9. Audit Metadata (ohne volle Prompts)
|
||
10. Fail Closed
|
||
|
||
Fail Closed: kein stillschweigender Fallback auf einen weniger geschützten Provider.
|
||
|
||
LLM-Egress und Tool-/Web-/Transkriptions-Egress sind getrennte Policies. Ein für ZDR-LLM freigegebener Kontext darf nicht automatisch an Web Search oder Speech-Cloud.
|
||
|
||
## 5. Internal vs. External Context
|
||
|
||
Der Context Builder darf intern mit Klaridentität arbeiten. Vor dem Socket nach außen existiert eine zweite Repräsentation ohne Mapping-Tabelle.
|
||
|
||
Demasking ausschließlich in der Trusted Zone, nach Validierung (Platzhalter erhalten, keine erratenen Klarnamen, keine Policy-Verstöße).
|
||
|
||
## 6. Audit
|
||
|
||
Speichern: Request-ID, Zeit, Policy, Provider-/Modellkennung, ZDR-/Region-Status, Typ maskierter Entitäten, Prüf- und Fallback-Status.
|
||
|
||
Nicht speichern: volle Prompts, volle Antworten, echte Namen, Mapping.
|
||
|
||
Admin-Sichtbarkeit der Mapping-Tabelle nur für besonders berechtigte Rollen (`admin_diagnostics.md`).
|
||
|
||
## 7. Beziehung zu anderen Kapiteln
|
||
|
||
- Resurfacing darf keinen breiteren Egress rechtfertigen als der aktuelle Task braucht.
|
||
- Re-Grounding läuft lokal und erzeugt danach erneut einen minimierten External Context.
|
||
- Voice/Transkription: eigener Egress-Typ (`voice_and_media.md`).
|
||
- Lived Experience / Re-Grounding: volle Primärquellen bleiben lokal; externes Modell bekommt erneut nur Klasse B.
|
||
- Prompt-Engine: Preview ohne LLM ist erlaubt; Debug-Ausgaben an den Admin ohne Klasse-A-Klartext und ohne Mapping.
|
||
|
||
## 8. Was Phase H noch offen lässt
|
||
|
||
Interview H1 (Encryption at rest, vollständiges Löschen, Portabilität, DSFA bei späterem Mehrbenutzerbetrieb) ergänzt diese Invariante, ersetzt sie nicht. Privacy Profiles (Strict / Balanced / Low-Identity) sind fachlich perspektivisch; Default muss die Invariante erfüllen.
|
||
|
||
## 9. Entscheidungsstand
|
||
|
||
| Thema | Stand | Status |
|
||
|---|---|---|
|
||
| Privacy Gateway vor persönlichem Egress | zwingend, nicht abschaltbar | entschieden |
|
||
| Guardrails vor Qualität/Kosten/Latenz | ja | entschieden (fachlich) |
|
||
| Providerunabhängige Guardrails | ja | entschieden (fachlich) |
|
||
| ZDR / kein Training / kein Prompt-Log | persönliche Kontexte | entschieden bzw. bevorzugte verbindliche Policy |
|
||
| Fail Closed | ja | bevorzugte Richtung |
|
||
| Keine Anonymitätsbehauptung | Pseudonymisierung | entschieden (fachlich) |
|
||
| OpenRouter | Kandidat, nicht Gateway-Ersatz | entschieden |
|
||
| EU-Routing | bevorzugt | offen in Ausprägung |
|
||
| Encryption at rest, Delete, DSFA | Phase H | offen |
|
||
| Implementierung Entity Detection | deterministisch vs. KI-gestützt | offen |
|
||
|
||
## 10. Offene Fragen
|
||
|
||
Übernommen aus `guardrails.md` §21, hier nicht vorentschieden: Entitätstypen, Quasi-Identifikatoren, Pseudonym-Stabilität, Mehrnutzer-Trennung der Mappings, Verschlüsselung der Mapping-Tabelle, rechtliche DSFA bei Mehrbenutzer-Produktbetrieb.
|
||
|
||
## 11. Querverweise
|
||
|
||
- Fachlich: `../functional/guardrails.md`
|
||
- Technisch: `ai_architecture.md`, `security.md`, `voice_and_media.md`, `platform_extensibility.md`
|