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`
|