diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md
index 0497283..f7f473d 100644
--- a/docs/architecture/functional/fachliche_zielarchitektur.md
+++ b/docs/architecture/functional/fachliche_zielarchitektur.md
@@ -491,6 +491,34 @@ Dieses Prinzip muss später insbesondere berücksichtigt werden in:
 Bei diesen Kapiteln ist jeweils zu prüfen, ob die Point-in-Time-Rekonstruktion der ursprünglichen Innenperspektive erhalten bleibt.
 
 
+
+## 2.13 Privacy Gateway und External-AI-Guardrails
+
+Für leistungsfähige Kanshō-Funktionen ist externe KI-Inferenz grundsätzlich zulässig und aufgrund der aktuell begrenzten lokalen Modellleistung voraussichtlich notwendig.
+
+Gleichzeitig verarbeitet Kanshō besonders sensible, langfristige autobiografische und dialogische Daten.
+
+Daraus folgt die verbindliche Architektur-Invariante:
+
+> **Identität bleibt lokal. Externe Intelligenz erhält nur den notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.**
+
+Persönliche externe AI-Aufrufe müssen deshalb über eine lokale Privacy-Gateway-/Egress-Schicht laufen.
+
+Diese Schicht muss mindestens berücksichtigen:
+
+- Datenminimierung,
+- Pseudonymisierung und symbolische Platzhalter,
+- ausschließlich lokale Identity-Mappings,
+- getrennten Internal und External Model Context,
+- Provider-/ZDR-Policy,
+- Fail-Closed-Verhalten,
+- getrennte Policies für LLM-, Tool- und Web-Egress,
+- lokale Response-Validation und Rehydration,
+- Auditierbarkeit ohne vollständige Prompt-Logs.
+
+Die vollständige fachliche Herleitung und Guardrail-Spezifikation wird in `guardrails.md` geführt. Spätere Kapitel zu AI Architecture, Data Architecture, Privacy, Security, Voice, Web/Tool-Nutzung, Memory und Integrationen müssen damit konsistent bleiben.
+
+
 # 3. Vorgeschlagene Repository-Struktur
 
 ```text
@@ -498,6 +526,7 @@ kansho/
 │
 ├── fachliche_zielarchitektur.md
 ├── produktvision_und_produktidentitaet.md
+├── guardrails.md
 ├── README.md
 ├── docs/
 │   ├── governance/
diff --git a/docs/architecture/functional/guardrails.md b/docs/architecture/functional/guardrails.md
new file mode 100644
index 0000000..68934dd
--- /dev/null
+++ b/docs/architecture/functional/guardrails.md
@@ -0,0 +1,674 @@
+---
+title: "Kanshō – Guardrails, Privacy Gateway und externe KI"
+version: "0.1"
+status: "In Bearbeitung"
+date: "2026-08-18"
+document_role: "Querschnittliches Fachkapitel / Privacy / AI Egress / Guardrails"
+parent_document: "fachliche_zielarchitektur.md"
+---
+
+# Kanshō – Guardrails, Privacy Gateway und externe KI
+
+## 1. Zweck dieses Dokuments
+
+Dieses Dokument beschreibt die fachlichen Guardrails für den Umgang mit besonders sensiblen persönlichen Daten in Kanshō, insbesondere bei Nutzung externer KI-Dienste.
+
+Kanshō soll langfristig vollständige Dialoge, zeitgebundene Innenperspektiven, Gedanken, beschriebene Gefühle, Zweifel, biografische Zusammenhänge und daraus abgeleitete persönliche Modelle speichern können.
+
+Diese Daten bilden eine besonders sensible Ebene des persönlichen digitalen Zwillings.
+
+Gleichzeitig ist vorgesehen, für leistungsfähige KI-Funktionen weitgehend externe Dienste beziehungsweise Modellprovider, beispielsweise über OpenRouter, zu verwenden, weil die derzeitige lokale Infrastruktur große Modelle nicht in ausreichender Qualität und Geschwindigkeit betreiben kann.
+
+Daraus entsteht eine zentrale Architekturaufgabe:
+
+> **Externe KI soll hohe semantische Leistungsfähigkeit liefern können, ohne dass die externe Seite die reale Identität des Nutzers oder unnötig viele identifizierende Merkmale erhält.**
+
+Dieses Dokument definiert dafür fachliche Schutzprinzipien. Die konkrete technische Implementierung wird später in Security-, Privacy-, AI- und Data-Architecture-Kapiteln spezifiziert.
+
+---
+
+# 2. Root-Cause-Herleitung
+
+## 2.1 Root Cause
+
+Kanshō benötigt für hochwertige, kontextreiche und langfristige Reflexionsdialoge leistungsfähige Sprachmodelle.
+
+Die aktuell verfügbare lokale Infrastruktur ist dafür nicht ausreichend leistungsfähig. Eine weitgehend lokale Ausführung großer Modelle ist deshalb derzeit keine tragfähige Grundannahme.
+
+Gleichzeitig verarbeitet Kanshō potenziell besonders sensible autobiografische Informationen, darunter:
+
+- vollständige persönliche Dialoge,
+- Gedanken und beschriebene Gefühle,
+- Zweifel und Ambivalenzen,
+- Beziehungen und Familienkontexte,
+- berufliche Situationen,
+- Gesundheitsbezüge,
+- Werte und Weltanschauungen,
+- biografische Ereignisse,
+- zeitgebundene Innenperspektiven,
+- Self-Model-Informationen,
+- möglicherweise besondere Kategorien personenbezogener Daten.
+
+Eine direkte Übertragung vollständiger, identifizierbarer Kanshō-Kontexte an externe KI-Dienste würde daher eine sehr große und langfristig schwer kontrollierbare Vertrauensgrenze erzeugen.
+
+## 2.2 Risiko
+
+Ohne Schutzschicht könnten externe Dienste oder deren nachgelagerte Provider:
+
+- den realen Namen oder andere direkte Identifikatoren erhalten,
+- Personen aus dem privaten Umfeld identifizieren,
+- genaue Orte, Arbeitgeber oder Adressen erhalten,
+- über Kombination mehrerer Merkmale eine Person indirekt wiedererkennen,
+- langfristige autobiografische Profile mit einer realen Identität verknüpfen,
+- sensible Informationen unnötig speichern oder protokollieren,
+- Daten über Tool- oder Providerketten an weitere Systeme weiterreichen.
+
+Besonders kritisch ist, dass Kanshō-Kontexte mit zunehmender Nutzungsdauer immer reichhaltiger werden. Selbst ein Text ohne Namen kann durch seltene Kombinationen aus Beruf, Ort, Familie, Ereignissen und Zeitpunkten identifizierbar werden.
+
+## 2.3 Fachliche Konsequenz
+
+Die Architektur darf externe Inferenz nicht mit direktem Zugriff auf den vollständigen internen Personenkontext gleichsetzen.
+
+Es wird eine lokale Vertrauensgrenze benötigt, die:
+
+- interne Identität und externe Modellrepräsentation trennt,
+- den Kontext vor jeder externen Anfrage minimiert,
+- direkte Identifikatoren pseudonymisiert,
+- besonders sensible Daten gegebenenfalls vollständig zurückhält,
+- externe Antworten vor lokaler Weiterverarbeitung prüft,
+- Identitäten ausschließlich lokal wiederherstellt.
+
+## 2.4 Abgeleitete Architektur-Invariante
+
+> **Identität bleibt lokal. Externe Intelligenz erhält nur den für die Aufgabe notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.**
+
+Diese Invariante gilt unabhängig davon, welcher externe Modellprovider später verwendet wird.
+
+---
+
+# 3. Grundbegriffe
+
+## 3.1 Pseudonymisierung ist nicht Anonymisierung
+
+Das Maskieren eines Namens durch einen symbolischen Platzhalter macht einen Dialog nicht automatisch anonym.
+
+Pseudonymisierung reduziert die direkte Verknüpfbarkeit mit einer Person. Solange die Zuordnung mit zusätzlichen Informationen wiederhergestellt werden kann, bleiben die Daten grundsätzlich personenbezogen.
+
+Daher gilt:
+
+> Kanshō soll gegenüber externen KI-Diensten **pseudonymisierte und datenminimierte Kontexte** erzeugen. Eine vollständige Anonymität wird nicht behauptet.
+
+## 3.2 Direkte Identifikatoren
+
+Beispiele:
+
+- Name,
+- E-Mail-Adresse,
+- Telefonnummer,
+- postalische Adresse,
+- Benutzername,
+- Kundennummer,
+- Fahrzeugkennzeichen,
+- Vertragsnummer,
+- Kontodaten,
+- eindeutige technische IDs.
+
+## 3.3 Quasi-Identifikatoren
+
+Auch ohne Namen können Kombinationen identifizierend wirken, beispielsweise:
+
+- seltene berufliche Rolle,
+- konkrete Organisation,
+- genauer Wohnort,
+- exaktes Alter,
+- Familienstruktur,
+- seltenes Ereignis,
+- konkrete Zeit-/Ortskombination,
+- Kombination aus mehreren biografischen Merkmalen.
+
+Diese Merkmale müssen kontextabhängig bewertet werden.
+
+---
+
+# 4. Vertrauensgrenzen
+
+Kanshō unterscheidet mindestens folgende Vertrauenszonen.
+
+## 4.1 Local Trusted Zone
+
+Darf vollständige Identität und Primärquellen enthalten.
+
+Dazu gehören insbesondere:
+
+- Identity Mapping,
+- vollständige Dialogquellen,
+- echte Namen,
+- private Adressen,
+- originale Obsidian-/mindnet-Referenzen,
+- vollständiger digitaler Zwilling,
+- lokale API-Secrets,
+- Demasking-Tabellen,
+- Privacy- und Routing-Konfiguration.
+
+## 4.2 External AI Zone
+
+Erhält ausschließlich einen für die jeweilige Inferenz erzeugten External Model Context.
+
+Dieser Kontext soll:
+
+- minimiert,
+- pseudonymisiert,
+- aufgabenspezifisch,
+- provenance-aware,
+- zeitlich begrenzt
+
+sein.
+
+## 4.3 Tool-/Plugin-Zone
+
+Externe Tools, Websuche, Plugins oder nachgelagerte Dienste bilden eine eigene Vertrauenszone.
+
+Eine Freigabe für externe LLM-Inferenz bedeutet **nicht automatisch**, dass derselbe Kontext an Tools oder Suchdienste weitergegeben werden darf.
+
+---
+
+# 5. Datenklassen
+
+## 5.1 Klasse A – Local Only
+
+Diese Daten sollen die lokale Vertrauenszone grundsätzlich nicht verlassen.
+
+Beispiele:
+
+- Mapping echter Namen zu Pseudonymen,
+- API-Secrets,
+- vollständige Adressen,
+- vollständiges Identitätsprofil,
+- interne Berechtigungsinformationen,
+- technische Security-Secrets,
+- Rohdaten, deren externe Verarbeitung nicht erforderlich ist.
+
+Abhängig vom späteren Schutzbedarf können weitere Datenarten als Local Only klassifiziert werden.
+
+## 5.2 Klasse B – Pseudonymized AI Context
+
+Dies ist der erwartete Normalfall für persönliche KI-Dialoge.
+
+Beispiele:
+
+- relevante Dialogauszüge,
+- Reflection Memories,
+- relevante Self-Model-Informationen,
+- Reflection-Space-Kontext,
+- autobiografische Episoden,
+- ausgewählte mindnet-Kontexte.
+
+Vor externem Versand werden diese Inhalte lokal minimiert und pseudonymisiert.
+
+## 5.3 Klasse C – Low-Identity / Non-identifying Context
+
+Inhalte mit keinem oder sehr geringem Personenbezug.
+
+Beispiele:
+
+- allgemeine Meditationsmethoden,
+- generische Schreibfragen,
+- allgemeine Wissensfragen,
+- nicht-personalisierte Hilfstexte.
+
+Hier kann eine weniger starke Transformation ausreichend sein.
+
+---
+
+# 6. Local Privacy Gateway
+
+Zwischen Kanshō und jeder externen KI-Inferenz soll fachlich eine lokale Privacy-Gateway-Schicht liegen.
+
+## 6.1 Aufgaben
+
+Das Gateway soll mindestens folgende Verantwortlichkeiten besitzen:
+
+1. Context Minimization
+2. Entity Detection
+3. Pseudonymization
+4. Policy Check
+5. Provider/Endpoint Eligibility Check
+6. Egress Validation
+7. Response Validation
+8. Local Rehydration / Demasking
+9. Audit Metadata
+10. Fail-Closed Handling
+
+## 6.2 Keine direkte externe Modellanbindung
+
+Fachliche Invariante:
+
+> **Kanshō-Komponenten senden persönlichen Kontext nicht direkt an externe Modellprovider.**
+
+Alle persönlichen External-AI-Aufrufe laufen über die Privacy- und Routing-Schicht.
+
+---
+
+# 7. External Model Context
+
+Der interne Context Builder kann mit der realen Identität und vollständigen lokalen Referenzen arbeiten.
+
+Vor einem externen Modellaufruf entsteht daraus eine zweite Repräsentation:
+
+## 7.1 Internal Context
+
+Beispiel:
+
+- reale Personennamen,
+- reale Orte,
+- vollständige Provenance,
+- interne IDs,
+- vollständige Verbindungen.
+
+## 7.2 External Model Context
+
+Beispiel:
+
+- `[[SELF]]`
+- `[[PERSON:PARTNER]]`
+- `[[PERSON:CHILD_01]]`
+- `[[PERSON:COLLEAGUE_03]]`
+- `[[ORG:EMPLOYER]]`
+- `[[PLACE:HOME_CITY]]`
+- `[[PLACE:VACATION_01]]`
+
+Der External Model Context enthält nur Informationen, die für die konkrete Aufgabe erforderlich sind.
+
+---
+
+# 8. Pseudonymisierung und symbolische Platzhalter
+
+## 8.1 Stabile Pseudonyme
+
+Pseudonyme sollen innerhalb sinnvoller Kontexte stabil sein.
+
+Dies ermöglicht dem externen Modell, Beziehungen zwischen Personen oder Orten korrekt zu verstehen, ohne die reale Identität zu kennen.
+
+Beispiel:
+
+`[[PERSON:PARTNER]]`
+
+soll in zusammengehörenden Modellkontexten dieselbe Person bezeichnen.
+
+## 8.2 Keine unnötig sprechenden Aliase
+
+Pseudonyme sollen nicht mehr Information transportieren als fachlich erforderlich.
+
+Zu vermeiden wären beispielsweise:
+
+- `[[PERSON:INDIAN_WIFE]]`
+- `[[PERSON:SON_WITH_MEDICAL_CONDITION]]`
+- `[[ORG:GERMAN_RESEARCH_EMPLOYER]]`
+
+wenn diese zusätzlichen Informationen für die Aufgabe nicht notwendig sind.
+
+## 8.3 Lokale Mapping-Tabelle
+
+Die Zuordnung:
+
+`Pseudonym → reale Identität`
+
+bleibt ausschließlich lokal.
+
+Sie wird nicht Bestandteil:
+
+- externer Prompts,
+- Modellmetadaten,
+- Logdaten,
+- Provider-Konfigurationen.
+
+## 8.4 Demasking
+
+Nach Rückkehr einer Modellantwort erfolgt die Wiederherstellung realer Namen beziehungsweise lokaler Begriffe ausschließlich innerhalb der Trusted Zone.
+
+---
+
+# 9. Kontextabhängige Datenminimierung
+
+Nicht jede personenbezogene Information muss pauschal maskiert werden.
+
+Ziel ist:
+
+> **So wenig Identifizierbarkeit wie möglich, so viel semantischer Kontext wie für eine hochwertige Antwort notwendig.**
+
+Beispiele:
+
+### Möglicherweise entbehrlich
+
+Für eine Reflexionsfrage zur eigenen Erholung ist die konkrete private Adresse vermutlich irrelevant.
+
+### Möglicherweise relevant
+
+Der Unterschied zwischen:
+
+- Urlaubsort,
+- Arbeitsplatz,
+- Zuhause,
+- Trainingsumfeld
+
+kann für eine Reflexion sehr relevant sein.
+
+Dann kann statt des echten Ortsnamens ein semantisch sinnvoller Platzhalter verwendet werden.
+
+---
+
+# 10. Indirekte Re-Identifikation
+
+Das Privacy Gateway soll nicht nur Klarnamen erkennen.
+
+Es soll perspektivisch auch das Re-Identifikationsrisiko eines External Model Context bewerten.
+
+Mögliche Risikofaktoren:
+
+- genaue Kombination aus Alter + Beruf + Ort,
+- seltene Rollen,
+- konkrete Arbeitgeber,
+- exakte Ereignisdaten,
+- ungewöhnliche Familienkonstellationen,
+- seltene biografische Ereignisse,
+- wiederkehrende Kombination mehrerer Quasi-Identifikatoren.
+
+Die konkrete Bewertung wird später technisch spezifiziert.
+
+Fachliches Ziel ist nicht mathematisch garantierte Anonymität, sondern eine deutliche Reduzierung unnötiger Identifizierbarkeit.
+
+---
+
+# 11. Externe Provider-Policy
+
+Externe KI-Dienste dürfen nicht allein aufgrund von Modellqualität ausgewählt werden.
+
+Privacy-Eigenschaften sind Teil der Routing-Policy.
+
+## 11.1 Zero Data Retention
+
+Für persönliche Kanshō-Kontexte soll grundsätzlich ein Zero-Data-Retention-Modus beziehungsweise ein funktional gleichwertiger Providerzustand verlangt werden.
+
+Für OpenRouter ist aktuell dokumentiert, dass ZDR auf unterschiedlichen Ebenen erzwungen werden kann und nur entsprechend gekennzeichnete Endpoints verwendet werden.
+
+## 11.2 Kein Training mit Kanshō-Inhalten
+
+Provider beziehungsweise Routen, bei denen Input/Output für Training oder Produktverbesserung genutzt werden dürfen, sollen für persönliche Kanshō-Kontexte nicht zugelassen werden.
+
+## 11.3 Kein freiwilliges Prompt Logging
+
+OpenRouter dokumentiert aktuell, dass eigene Prompt-/Response-Speicherung opt-in ist.
+
+Für Kanshō soll diese freiwillige Speicherung nicht aktiviert werden.
+
+## 11.4 EU-/Region-Routing
+
+Wenn ein geeigneter Provider und ein geeignetes Modell verfügbar sind, soll regionale Verarbeitung innerhalb der EU bevorzugt beziehungsweise – abhängig vom späteren Policy-Level – erzwungen werden können.
+
+Modellqualität, Verfügbarkeit und Datenschutzanforderung müssen dabei transparent gegeneinander abgewogen werden.
+
+## 11.5 Fail Closed
+
+Für sensitive oder persönliche Kontexte gilt als bevorzugtes Prinzip:
+
+> **Ist kein Endpoint verfügbar, der die erforderliche Privacy Policy erfüllt, wird die Anfrage nicht stillschweigend an einen weniger geschützten Provider weitergereicht.**
+
+Stattdessen:
+
+- lokale Fallback-Funktion,
+- weniger leistungsfähige lokale Verarbeitung,
+- spätere Wiederholung,
+- oder transparente Meldung an den Nutzer.
+
+Die konkrete Fallback-Strategie wird später definiert.
+
+---
+
+# 12. OpenRouter als möglicher Routing-Dienst
+
+OpenRouter ist derzeit ein naheliegender Kandidat, weil es:
+
+- unterschiedliche Modellprovider bündeln kann,
+- Zero Data Retention unterstützen kann,
+- Provider- und Privacy-Routing ermöglicht,
+- Daten- und Provider-Policies konfigurierbar macht.
+
+Wichtig:
+
+OpenRouter ist **kein fixer Architekturzwang**.
+
+Guardrails werden providerunabhängig formuliert, damit später:
+
+- OpenRouter,
+- direkter Providerzugriff,
+- EU-basierte Inferenz,
+- eigene GPU-Infrastruktur,
+- oder lokale Modelle
+
+austauschbar bleiben.
+
+---
+
+# 13. Tool- und Web-Egress
+
+LLM-Inferenz und externe Tools werden getrennt betrachtet.
+
+Ein persönlicher Kontext, der für einen ZDR-LLM-Endpunkt freigegeben wurde, darf nicht automatisch an:
+
+- Web Search,
+- Plugins,
+- externe Agenten,
+- Analytics,
+- Speech-Dienste,
+- Transkriptionsdienste
+
+weitergereicht werden.
+
+Jeder Egress-Typ benötigt eine eigene Policy.
+
+Dies gilt insbesondere, weil Provider-ZDR-Regeln nicht automatisch auf externe Tools oder weitere Dienste übertragbar sind.
+
+---
+
+# 14. Response Validation und Rehydration
+
+Die Antwort eines externen Modells wird nicht unmittelbar als vertrauenswürdiger lokaler Inhalt behandelt.
+
+Vor Demasking sollte die lokale Schicht mindestens prüfen können:
+
+- Sind bekannte Platzhalter korrekt erhalten?
+- Wurden Platzhalter verwechselt?
+- Sind neue, unbekannte Pseudonyme entstanden?
+- Hat das Modell versucht, reale Identitäten zu erraten?
+- Enthält die Antwort unerwartete identifizierende Informationen?
+- Enthält sie Inhalte, die gegen die Egress-/Privacy-Policy verstoßen?
+
+Erst danach erfolgt:
+
+1. lokale Rehydration,
+2. fachliche Weiterverarbeitung,
+3. Anzeige beziehungsweise Speicherung.
+
+---
+
+# 15. Beziehung zu Lived Experience / Digital Twin
+
+Die Privacy-Architektur muss mit dem Lived-Experience-Layer konsistent bleiben.
+
+Insbesondere gilt:
+
+- vollständige Dialoge bleiben Primärquellen,
+- externe Modelle benötigen nicht automatisch vollständige Primärquellen,
+- Context Builder und Privacy Gateway wählen nur notwendige Ausschnitte,
+- Pseudonymisierung verändert nicht die lokale Originalquelle,
+- Demasking findet ausschließlich lokal statt,
+- Re-Grounding arbeitet lokal mit Originalquellen und erzeugt für externe Inferenz erneut einen minimierten External Model Context.
+
+Damit kann ein reicher digitaler Zwilling lokal erhalten bleiben, ohne vollständig an externe Dienste übertragen zu werden.
+
+---
+
+# 16. Beziehung zu Thread Resurfacing und Reflection Saturation
+
+Resurfacing und Saturation dürfen Privacy Guardrails nicht umgehen.
+
+Beispiele:
+
+- Ein wieder auftauchender Thread darf nur den dafür notwendigen historischen Kontext extern verfügbar machen.
+- Eine hohe Reflection Saturation rechtfertigt keine umfassendere Datenweitergabe.
+- Bei Re-Grounding muss anschließend erneut minimiert und pseudonymisiert werden.
+- Explizite Nutzeranfragen ändern nicht automatisch die Egress-Klasse sensibler Daten.
+
+---
+
+# 17. Rollen und Transparenz
+
+Die Admin-/Developer View soll perspektivisch Privacy-Entscheidungen inspizierbar machen.
+
+Mögliche Informationen:
+
+- welche Entitäten maskiert wurden,
+- welche Datenklasse angewendet wurde,
+- welcher Provider beziehungsweise Endpoint gewählt wurde,
+- ob ZDR erzwungen wurde,
+- welche Policy einen Request zugelassen oder blockiert hat,
+- welche Informationen vor Egress entfernt wurden,
+- ob Output-Validation Auffälligkeiten gefunden hat.
+
+Die echte Mapping-Tabelle soll auch in dieser Ansicht nur soweit sichtbar sein, wie dies für eine besonders berechtigte Rolle tatsächlich erforderlich ist.
+
+---
+
+# 18. Logging und Audit
+
+Privacy- und Security-Audit benötigen Metadaten, ohne selbst neue sensible Langzeitlogs zu erzeugen.
+
+Bevorzugt gespeichert werden:
+
+- Request-ID,
+- Zeitpunkt,
+- verwendete Policy,
+- Provider-/Modellkennung,
+- ZDR-/Region-Status,
+- Anzahl beziehungsweise Typ maskierter Entitäten,
+- Ergebnis der Egress-Prüfung,
+- Ergebnis der Response-Prüfung,
+- Fehler-/Fallback-Status.
+
+Nicht automatisch in Audit Logs gespeichert werden sollen:
+
+- vollständige externe Prompts,
+- vollständige Modellantworten,
+- echte Namen,
+- Identity Mapping.
+
+---
+
+# 19. Guardrail-Priorität
+
+Guardrails haben Vorrang vor:
+
+- Modellqualität,
+- Kostenoptimierung,
+- Latenz,
+- Komfort,
+- automatischem Provider-Fallback.
+
+Ein Modellaufruf darf abgelehnt oder degradiert werden, wenn die Privacy Policy nicht erfüllt werden kann.
+
+---
+
+# 20. Konfigurierbarkeit
+
+Nicht jede Art von Inhalt benötigt identische Schutzstufen.
+
+Perspektivisch kann es konfigurierbare Privacy Profiles geben, beispielsweise:
+
+- **Strict**
+- **Balanced**
+- **Low-Identity / Generic**
+
+Die konkrete Ausprägung ist offen.
+
+Wichtig:
+
+Der Nutzer soll nicht bei jeder Anfrage technische Provider-Parameter entscheiden müssen.
+
+Die Konfiguration soll weitgehend als Policy hinterlegt sein.
+
+---
+
+# 21. Noch offene Fragen
+
+1. Welche Entitätstypen werden standardmäßig pseudonymisiert?
+2. Welche Daten sind zwingend Local Only?
+3. Wie werden Quasi-Identifikatoren erkannt?
+4. Wie wird ein Re-Identifikationsrisiko bewertet?
+5. Wie stabil beziehungsweise kontextgebunden sind Pseudonyme?
+6. Wie werden mehrere Nutzer und Mandanten getrennt?
+7. Welche Provider sind für welche Privacy-Profile zugelassen?
+8. Wird EU-Routing verpflichtend oder bevorzugt?
+9. Welche lokale Fallback-Funktion wird benötigt?
+10. Wie wird Voice/Transcription in dieselbe Trust-Architektur integriert?
+11. Welche Policies gelten für Web Search und Plugins?
+12. Wie werden Retention und vollständiges Löschen umgesetzt?
+13. Wie wird das Identity Mapping verschlüsselt und gesichert?
+14. Welche Funktionen benötigt die Admin-/Developer View?
+15. Welche Guardrails müssen deterministisch sein und welche dürfen KI-gestützt arbeiten?
+16. Wie wird verhindert, dass eine KI über den pseudonymisierten Kontext reale Identitäten erschließt?
+17. Wie wird Egress bei besonders sensiblen Kategorien zusätzlich eingeschränkt?
+18. Welche rechtliche Bewertung beziehungsweise Datenschutz-Folgenabschätzung ist bei einer späteren Mehrbenutzer-/Produktnutzung erforderlich?
+
+---
+
+# 22. Entscheidungsstand
+
+| Thema | Entscheidung / Arbeitsstand |
+|---|---|
+| Externe KI | für leistungsfähige Kanshō-Funktionen grundsätzlich vorgesehen | entschieden |
+| Lokale Modelle | aktuell nicht als alleinige leistungsfähige Basis vorausgesetzt | entschieden |
+| Privacy Gateway | zwingende lokale Vertrauensgrenze vor persönlichem externem AI-Egress | entschieden |
+| Identität | bleibt lokal | entschieden |
+| Klarnamen | vor externem AI-Egress symbolisch pseudonymisieren, soweit relevant | entschieden |
+| Identity Mapping | ausschließlich lokal | entschieden |
+| Datenminimierung | zusätzlich zur Pseudonymisierung erforderlich | entschieden |
+| Pseudonymisierung vs. Anonymität | keine Behauptung vollständiger Anonymität | entschieden |
+| External Model Context | getrennte, minimierte Repräsentation des internen Kontextes | entschieden |
+| ZDR | für persönliche externe KI-Kontexte grundsätzlich erforderlich | bevorzugte verbindliche Policy |
+| Prompt Logging | für persönliche Kanshō-Kontexte nicht aktivieren | entschieden |
+| Provider-Training | persönliche Kanshō-Kontexte nicht für Training freigeben | entschieden |
+| Fail Closed | kein stillschweigender Fallback auf weniger geschützte Provider | bevorzugte Richtung |
+| EU Routing | bevorzugt / mögliche strengere Policy später | offen in Ausprägung |
+| Tool Egress | getrennte Policy von LLM Egress | entschieden |
+| Response Validation | lokale Prüfung vor Demasking | entschieden |
+| Rehydration | ausschließlich lokal | entschieden |
+| Guardrails | providerunabhängig definieren | entschieden |
+
+---
+
+# 23. Externe Referenzquellen
+
+Für die weitere technische und rechtliche Ausarbeitung wurden unter anderem folgende Primärquellen als Ausgangspunkt verwendet:
+
+- OpenRouter – Data Collection / Privacy  
+  https://openrouter.ai/docs/guides/privacy/data-collection
+
+- OpenRouter – Zero Data Retention  
+  https://openrouter.ai/docs/guides/features/zdr
+
+- OpenRouter – Provider Logging / Data Retention Policies  
+  https://openrouter.ai/docs/guides/privacy/provider-logging
+
+- OpenRouter – Guardrails  
+  https://openrouter.ai/docs/guides/features/guardrails
+
+- OpenRouter – Sovereign AI / EU Routing  
+  https://openrouter.ai/docs/guides/features/sovereign-ai
+
+- European Data Protection Board – Guidelines 01/2025 on Pseudonymisation  
+  https://www.edpb.europa.eu/public-consultations/guidelines-012025-on-pseudonymisation_en
+
+- Regulation (EU) 2016/679 (GDPR) – EUR-Lex  
+  https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
+
+Diese Quellen dienen als fachlicher Ausgangspunkt. Vor einer späteren produktiven Mehrbenutzer- oder kommerziellen Nutzung sind die dann gültigen Providerbedingungen und rechtlichen Anforderungen erneut zu prüfen.
diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md
index 0ccd79a..3bc4d07 100644
--- a/docs/architecture/functional/produktvision_und_produktidentitaet.md
+++ b/docs/architecture/functional/produktvision_und_produktidentitaet.md
@@ -1283,6 +1283,20 @@ Diese Architektur ermöglicht perspektivisch Fragen wie:
 Damit wird Kanshō zu einer wesentlichen Daten- und Reflexionsquelle für einen langfristig wachsenden persönlichen digitalen Zwilling.
 
 
+
+## Guardrails und externe KI
+
+Kanshō soll leistungsfähige externe KI-Dienste nutzen können, ohne deshalb die vollständige reale Identität und den lokalen digitalen Zwilling ungefiltert nach außen zu übertragen.
+
+Dafür gilt als querschnittliche Produkt- und Architektur-Invariante:
+
+> **Identität bleibt lokal. Externe Intelligenz erhält nur den für die Aufgabe notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.**
+
+Klarnamen und andere identifizierende Informationen sollen vor persönlichem externem AI-Egress durch eine lokale Privacy-Gateway-Schicht erkannt, minimiert beziehungsweise durch symbolische Platzhalter ersetzt und nach Rückkehr der Antwort ausschließlich lokal wiederhergestellt werden.
+
+Die vollständige Herleitung, Datenklassen, Provider-Policies, ZDR-Anforderungen, Tool-Egress-Regeln und offenen Fragen werden im eigenständigen Fachkapitel `guardrails.md` geführt.
+
+
 # 18. Geplanter Funktionsumfang
 
 Der bisher genannte Funktionsumfang umfasst mindestens folgende Bereiche.
diff --git a/docs/architecture/functional/usage_situations.md b/docs/architecture/functional/usage_situations.md
index dcca50e..a460b87 100644
--- a/docs/architecture/functional/usage_situations.md
+++ b/docs/architecture/functional/usage_situations.md
@@ -604,6 +604,86 @@ Noch zu klären:
 - Wann ist eine Tagesreflexion fachlich abgeschlossen?
 - Welche Outputs entstehen standardmäßig am Ende?
 
+
+## 7.2 Thread Resurfacing und Reflection Saturation
+
+Aus der Ausarbeitung der Tagesreflexion ergeben sich zwei querschnittliche fachliche Konzepte, die nicht nur für diese Nutzungssituation gelten.
+
+### Thread Resurfacing
+
+Thread Resurfacing beantwortet die Frage:
+
+> **Wann soll ein früheres oder offenes Thema wieder aktiv relevant werden?**
+
+Mögliche Trigger sind insbesondere:
+
+1. **Explizite Nutzeranfrage**  
+   Beispiele: „Was ist noch offen?“ oder „Wo stehen wir bei Thema X?“
+
+2. **Zeitlicher oder örtlicher Kontext**  
+   Beispiel: Urlaubsthemen sind während des Urlaubs besonders relevant und können noch in einer definierten Rückschauphase danach aktiv angeboten werden.
+
+3. **Situations- oder kontextgebundene Reaktivierung**  
+   Beispiel: Ein neues Erlebnis beim Sport, in der Familie oder bei einer Meditation steht in erkennbarem Zusammenhang mit einem früheren Thread.
+
+4. **Explizit gesetzter Anker im Dialog**  
+   Beispiel: „Lass uns morgen daran weiterarbeiten.“
+
+5. **Semantische Reaktivierung**  
+   Ein aktuelles Erlebnis steht in starker inhaltlicher Beziehung zu einem früheren Thema, auch wenn der Nutzer es nicht ausdrücklich nennt.
+
+Wichtig ist die Trennung zwischen:
+
+- **Memory:** Ein Thema bleibt langfristig erhalten.
+- **Current Relevance:** Ein Thema ist aktuell geeignet, wieder aktiv angeboten zu werden.
+
+Ein Thema darf historisch vollständig verfügbar bleiben, ohne regelmäßig ungefragt in den Vordergrund zu treten.
+
+### Reflection Saturation
+
+Reflection Saturation beantwortet die Frage:
+
+> **Ist für die aktuelle Reflexionssitzung wahrscheinlich ausreichend gesagt beziehungsweise verstanden worden?**
+
+Dabei können fachlich unter anderem berücksichtigt werden:
+
+- aktueller Reflection Intent,
+- expliziter Nutzerwunsch,
+- typische persönliche Dialogtiefe,
+- Umfang und Tiefe vergleichbarer früherer Reflexionen,
+- Abdeckung aktuell relevanter Themen,
+- offene Randthemen,
+- sinkender zusätzlicher Erkenntnisgewinn,
+- erkennbare Gesprächssignale.
+
+Reflection Saturation ist **kein automatischer Gesprächsabbruch**.
+
+Kanshō darf erkennen, dass eine Reflexion für den Moment ausreichend rund wirkt, soll den Abschluss aber als Möglichkeit anbieten.
+
+Die letzte Entscheidung über Weiterführen, Vertiefen, Wiedervorlage oder Abschluss liegt beim Nutzer.
+
+### Fachliche Thread-Zustände
+
+Für die weitere Architektur sind mindestens folgende fachlichen Zustände beziehungsweise Bedeutungen relevant:
+
+- **Active** – wird aktuell bearbeitet,
+- **Open** – noch nicht ausgeschöpft,
+- **Anchored / Resurface** – ausdrücklich für eine spätere Wiederaufnahme markiert,
+- **Dormant** – nicht abgeschlossen, aber aktuell nicht relevant,
+- **Resolved** – für den derzeitigen Erkenntnisstand ausreichend bearbeitet.
+
+Diese Begriffe sind noch **kein festes technisches State Model**. Sie dienen zunächst dazu, spätere Architekturentscheidungen konsistent auszurichten.
+
+### Architekturweite Gültigkeit
+
+Thread Resurfacing und Reflection Saturation sind querschnittliche Konzepte.
+
+Spätere Kapitel zu Dialogmodell, Memory, Context Builder, AI-Architektur, Reflection Spaces, UX, Notifications, Kairo-Integration und Admin-/Developer View müssen mit diesen Konzepten konsistent bleiben.
+
+Die konkrete Berechnung von Relevanz, Saturation, Scores oder Zustandsübergängen wird erst in den jeweiligen technischen Architekturkapiteln festgelegt.
+
+---
+
 # 8. Entscheidungsstand
 
 | Thema | Stand |