Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/guardrails.md

@@ -0,0 +1,719 @@
+---
+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.
+
+# 24. Migrierte Architekturverweise
+
+<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemaliger Abschnitt 2.13 Privacy Gateway und External-AI-Guardrails. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 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.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: ehemaliger Abschnitt Guardrails und externe KI. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 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.
+

docs/architecture/functional/integrations.md

@@ -0,0 +1,184 @@
+---
+    title: "Kanshō – Integrationen und Produktgrenzen"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Jinkendo Integrations / Product Boundaries"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Integrationen und Produktgrenzen
+
+Dieses Dokument ist das kanonische Home für die Rollen der bestehenden Jinkendo-Komponenten, Integrationsgrenzen und fachlichen Übergaben.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 2 Ausgangslage. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 2. Ausgangslage
+
+Innerhalb der Jinkendo-Produktfamilie existieren bereits mehrere Anwendungen mit klar abgegrenzten Aufgabenbereichen.
+
+Die neue Anwendung entsteht daher **nicht als isoliertes Einzelprodukt**, sondern als weitere Komponente eines bereits vorhandenen persönlichen digitalen Ökosystems.
+
+Bereits vorhandene Systeme übernehmen insbesondere folgende Aufgaben:
+
+### 2.1 Kairo
+
+Kairo ist primär für Planung, Steuerung und persönliche Entwicklung zuständig.
+
+Dazu gehören unter anderem:
+
+- Ziele,
+- Vorhaben,
+- Initiativen,
+- Projekte,
+- persönliche Entwicklungspfade,
+- Rituale,
+- Roadmaps,
+- Meilensteine,
+- Aufgaben und Next Best Actions.
+
+Für die neue Anwendung bedeutet dies:
+
+**Planung ist nicht ihre Kernaufgabe.**
+
+Erkenntnisse aus Reflexionen können später an Kairo übergeben werden, wenn daraus eine Absicht, ein Ziel, ein Ritual oder eine konkrete Maßnahme entsteht.
+
+---
+
+### 2.2 mindnet
+
+mindnet bildet das persönliche Wissensnetz.
+
+Der derzeitige Schwerpunkt liegt auf:
+
+- Obsidian als menschenlesbarer Wissens- und Notizbasis,
+- Qdrant als semantischer Retrieval-Schicht,
+- semantischer Suche,
+- Beziehungen zwischen Wissenselementen,
+- Edges wie beispielsweise `belongs_to`, `next`, `prev`, `references` und `backlink`,
+- perspektivisch der Abbildung tieferer Bedeutungs- und Zusammenhangsstrukturen.
+
+mindnet ist für die neue Anwendung besonders relevant, weil dort langfristig unter anderem folgende Informationen liegen oder liegen können:
+
+- Erfahrungen,
+- Erlebnisse,
+- Entscheidungen,
+- Erkenntnisse,
+- Werte,
+- Leitbild,
+- persönliche Prinzipien,
+- autobiografische Zusammenhänge,
+- noch ungeklärte oder unvollständige Beziehungsketten.
+
+Die neue Anwendung soll Informationen aus mindnet für Reflexionen nutzen und umgekehrt relevante Ergebnisse wieder in das langfristige Wissenssystem überführen.
+
+---
+
+### 2.3 Shinkan
+
+Shinkan ist für Training und Trainingsorganisation zuständig.
+
+Dazu gehören unter anderem:
+
+- Übungen,
+- Trainingsvorlagen,
+- Trainingsplanung,
+- Programme,
+- Medien,
+- Trainingsmethodik.
+
+Für die neue Anwendung bedeutet dies:
+
+**Trainingsplanung und Übungsverwaltung werden nicht dupliziert.**
+
+Reflexionen zu Training, Lernen, Kampfkunst oder persönlichen Erfahrungen im Training können jedoch Bestandteil eines Reflexionsdialogs sein.
+
+---
+
+### 2.4 Mitai
+
+Mitai bildet körperliche Entwicklung und Gesundheitskontext ab.
+
+Dazu gehören unter anderem:
+
+- körperliche Entwicklung,
+- Fitness,
+- Ernährung,
+- Essverhalten,
+- Vitalwerte,
+- gesundheitsbezogene Verläufe.
+
+Für die neue Anwendung bedeutet dies:
+
+**Körper- und Gesundheitsdaten werden nicht nochmals als eigenes Tracking-System aufgebaut.**
+
+Kanshō kann solche Informationen jedoch – abhängig von Berechtigungen und Kontext – in Reflexionen einbeziehen.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 20 Integrationsprinzipien. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 20. Integrationsprinzipien
+
+### 20.1 Kairo
+
+Kanshō kann:
+
+- relevante Ziele oder Entwicklungskontexte lesen,
+- Handlungsabsichten erkennen,
+- Action Candidates erzeugen,
+- Übergabe an Kairo anbieten.
+
+Kanshō übernimmt keine dauerhafte Aufgaben- oder Zielverwaltung.
+
+---
+
+### 20.2 mindnet
+
+Kanshō kann:
+
+- relevantes persönliches Wissen abrufen,
+- Werte und Leitbild einbeziehen,
+- frühere Erfahrungen finden,
+- ähnliche Themen erkennen,
+- offene Zusammenhänge aufnehmen,
+- neue Reflection Memories erzeugen,
+- Knowledge Deltas vorschlagen.
+
+---
+
+### 20.3 Obsidian
+
+Obsidian soll weiterhin eine zentrale menschenlesbare Wissens- und Tagebuchbasis darstellen.
+
+Kanshō soll insbesondere:
+
+- Tagebucheinträge erzeugen,
+- strukturierte Reflexionen ablegen,
+- bestehende Inhalte referenzieren,
+- kein proprietäres geschlossenes Archiv erzeugen.
+
+Der genaue Ablage- und Synchronisationsmechanismus ist noch zu bestimmen.
+
+---
+
+### 20.4 Shinkan
+
+Shinkan kann Kontext liefern, wenn Reflexionen mit Training oder persönlicher Entwicklung im Training zusammenhängen.
+
+Kanshō übernimmt keine Trainingsplanung.
+
+---
+
+### 20.5 Mitai
+
+Mitai kann – bei entsprechendem Kontext und Berechtigung – körperliche oder gesundheitsbezogene Informationen liefern.
+
+Kanshō übernimmt kein Vital-, Ernährungs- oder Gesundheitstracking.
+
+---
+
+
+## Querverweis auf Action Candidates
+
+Die fachliche Definition von `Action Candidate` und die Übergabe aus Reflexionen wird in `reflection_outputs.md` geführt; Kairo bleibt für die Operationalisierung zuständig.

docs/architecture/functional/manifest.json

@@ -0,0 +1,125 @@
+{
+  "generated": "2026-08-18",
+  "files": [
+    {
+      "file": "context_fidelity_and_regrounding.md",
+      "bytes": 10578,
+      "lines": 228,
+      "sha256": "befab673fce876d916698c3627c1aeff507044045fa54e09950e104554945ac0"
+    },
+    {
+      "file": "dialogue_model.md",
+      "bytes": 8894,
+      "lines": 230,
+      "sha256": "e7117b411f23c141756020a33eb3991344ba3c7751547642dca1c070d8f042b3"
+    },
+    {
+      "file": "documentation_index.md",
+      "bytes": 3083,
+      "lines": 82,
+      "sha256": "0075d73bd4eceb5abe435208c76919d0c518c28971e6512c17523ab4874a8cb5"
+    },
+    {
+      "file": "fachliche_zielarchitektur.md",
+      "bytes": 11310,
+      "lines": 268,
+      "sha256": "86a002ec71f98c422c8c39815ad168b0de89a4e8cbdcae67fbf04c50a220ad0b"
+    },
+    {
+      "file": "guardrails.md",
+      "bytes": 24882,
+      "lines": 719,
+      "sha256": "c2686cfb2954e33b0f9a812e56d7c78434083c8d227b59e3d61635d6f58ff260"
+    },
+    {
+      "file": "integrations.md",
+      "bytes": 5222,
+      "lines": 184,
+      "sha256": "40921765f383d86734c59b34b8fb6d0ee229362f4c31fbba7413d8465e025b27"
+    },
+    {
+      "file": "interview_plan.md",
+      "bytes": 25791,
+      "lines": 1014,
+      "sha256": "430eac10284061dd8a48e579d38d753d816eaa3cd23f1c65d54461fc174190ce"
+    },
+    {
+      "file": "memory_and_context.md",
+      "bytes": 4080,
+      "lines": 140,
+      "sha256": "d8b0b01380b2bdba44d10e8eab7cb07ec8656c9e5fc8b465c7f3a1c34c1fcfe6"
+    },
+    {
+      "file": "migration_mapping.md",
+      "bytes": 5656,
+      "lines": 75,
+      "sha256": "c1a1887cef9383221bf80bfd1b35232acb1cfce391043f5e7788c5d07edc1dda"
+    },
+    {
+      "file": "produktvision_und_produktidentitaet.md",
+      "bytes": 22403,
+      "lines": 514,
+      "sha256": "e1367c0388a32e54c2ee5c0dd8e0bd940cbd057d2d7793c97f1592e4e30bdfd8"
+    },
+    {
+      "file": "reflection_intelligence.md",
+      "bytes": 2564,
+      "lines": 72,
+      "sha256": "f840eed92dcc29395e980eb547caef6baa3b0645311482230ecb198a40beedca"
+    },
+    {
+      "file": "reflection_outputs.md",
+      "bytes": 2712,
+      "lines": 99,
+      "sha256": "63520b1642b239dc43c52ef4fcf7c7a041b309db9688426b287effc0f25cef55"
+    },
+    {
+      "file": "reflection_spaces.md",
+      "bytes": 10307,
+      "lines": 224,
+      "sha256": "c81feaa50df70c96e87f7ad4a65c0b2df36c6df13a258f1de072f2664e84f779"
+    },
+    {
+      "file": "resurfacing_and_saturation.md",
+      "bytes": 7236,
+      "lines": 175,
+      "sha256": "555df7855c498bb136d6012b2fae5584897641f20a1d7455e8a037099b967d9e"
+    },
+    {
+      "file": "self_model_and_lived_experience.md",
+      "bytes": 9859,
+      "lines": 247,
+      "sha256": "5df74eb5c3ab6d98c250c3b339aed0bf5da26c394d3704b72ecf0d63c3f552ec"
+    },
+    {
+      "file": "usage_situations.md",
+      "bytes": 25559,
+      "lines": 706,
+      "sha256": "485fe3a8848d4ef0892614998c48cc311f23bd9624fbb24e69d93770c424a26d"
+    },
+    {
+      "file": "writing_profile_and_journaling.md",
+      "bytes": 3488,
+      "lines": 103,
+      "sha256": "e043c1d212de249127ba4b8e41bb58e846aab27c92f165e2e032b00ec65712ee"
+    }
+  ],
+  "source_checkpoint": {
+    "fachliche_zielarchitektur.md": {
+      "sha256": "711317032724e46ac545d213b6e246f962662a547731ec7949dc61d146d59fb6",
+      "bytes": 51488
+    },
+    "produktvision_und_produktidentitaet.md": {
+      "sha256": "f46358a730ac46eb817cb61a3afa7d0dfb83f4cfffd04484332939826300d216",
+      "bytes": 63647
+    },
+    "usage_situations.md": {
+      "sha256": "92007021fdd6feccdf2db3bf534f2c3909f971d2a6036e43d03cc2ac90154d34",
+      "bytes": 24883
+    },
+    "guardrails.md": {
+      "sha256": "8f4732f0ab309c551740c0135ca9cc92a8032323e5becf81adb1845d8e292dde",
+      "bytes": 22198
+    }
+  }
+}