Lars/Kansho
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
07479f6a9f
Kansho/docs/architecture/functional/guardrails.md
Lars be11f82f84 MVP 0.95
2026-08-29 11:04:34 +02:00

30 KiB
Raw Blame History

title version status date document_role parent_document
Kanshō – Guardrails, Privacy Gateway und externe KI 0.1 In Bearbeitung 2026-08-18 Querschnittliches Fachkapitel / Privacy / AI Egress / Guardrails 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.

Additiv 2026-08-27: Diese Prüfung ist Inhaltsintegrität nach dem Generate, nicht nachträglicher Egress-Stopp. Privacy fail-closed gilt vor dem Socket. Ein Verwerfen der Antwort macht einen bereits erfolgten Egress nicht ungeschehen und löst keinen automatischen zweiten Generate-Call aus.

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.

18.1 Interne Quellbewahrung und Löschhoheit

Status: fachliche Baseline entschieden; technische Umsetzung offen

Die für Kanshō entschiedene Default-Quellbewahrung findet innerhalb der vertrauenswürdigen internen Datenhaltung statt und ist von externer Provider-Retention zu unterscheiden.

  • Inhaltliche Originalquellen werden standardmäßig bewahrt und nicht allein wegen Alter, Menge, geringer aktueller Relevanz oder vorhandener Verdichtungen automatisch gelöscht.
  • Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung.
  • Administrative Löschung ist keine automatische Speicherbereinigung und darf nicht mit dem Zurückstufen, Archivieren oder Ausblenden derzeit irrelevanter Inhalte verwechselt werden.
  • Die genaue Autorisierung, Nachvollziehbarkeit und Weitergabe einer Löschung an Ableitungen, Indizes, Backlinks und Integrationen bleibt auszuarbeiten.

Die vollständige fachliche Abgrenzung zwischen Quellbewahrung, aktiver Relevanz und skalierbarer Informationsorganisation wird in memory_and_context.md geführt.

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 die entschiedene Default-Quellbewahrung und ausdrückliche vollständige beziehungsweise selektive Löschungen technisch umgesetzt und auf Ableitungen, Indizes und Integrationen propagiert?
  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
Lokale Modelle aktuell nicht als alleinige leistungsfähige Basis vorausgesetzt
Privacy Gateway zwingende lokale Vertrauensgrenze vor persönlichem externem AI-Egress
Identität bleibt lokal
Klarnamen vor externem AI-Egress symbolisch pseudonymisieren, soweit relevant
Identity Mapping ausschließlich lokal
Datenminimierung zusätzlich zur Pseudonymisierung erforderlich
Pseudonymisierung vs. Anonymität keine Behauptung vollständiger Anonymität
External Model Context getrennte, minimierte Repräsentation des internen Kontextes
ZDR für persönliche externe KI-Kontexte grundsätzlich erforderlich
Prompt Logging für persönliche Kanshō-Kontexte nicht aktivieren
Provider-Training persönliche Kanshō-Kontexte nicht für Training freigeben
Fail Closed kein stillschweigender Fallback auf weniger geschützte Provider
EU Routing bevorzugt / mögliche strengere Policy später
Tool Egress getrennte Policy von LLM Egress
Response Validation lokale Prüfung vor Demasking
Rehydration ausschließlich lokal
Guardrails providerunabhängig definieren
Entity Detection semantisch, request-lokal; Detect-Ausgabe nicht automatisch aktive Identität
Entitätstypen im MVP PERSON, PLACE, ORG, PROJECT

Die konkrete Ausprägung von Quasi-Identifikatoren bleibt offen. | Interne Originalquellen | standardmäßig bewahren; keine automatische Löschung wegen Alter, Menge oder geringer Relevanz | entschieden | | Löschhoheit | konkrete Nutzeraufforderung oder berechtigte administrative Handlung; Ausprägung und Löschkaskade offen | fachliche Baseline entschieden |

22.1 Semantische Detection und bestätigte Identitäten (2026-08-26)

Additiv. Technische Umsetzung: ../technical/privacy_gateway.md §9.5.

Entschieden: Jeder persönliche externe Generate-Egress wird vor dem Versand vollständig und semantisch untersucht. Ergebnisse einer einzelnen Detection gelten zunächst nur für diesen Request. Ein Detect-Modell darf niemals allein durch seine Ausgabe eine dauerhaft aktive Identität erzeugen.

Schützenswert ist eine konkrete Bezeichnung, durch die eine natürliche Person, ein genauer persönlicher Ort, eine Organisation, ein privates Projekt oder ein anderer im Produktrahmen definierter Identifikator erkennbar wird. Allgemeine Gegenstände, Tätigkeiten, Lebensmittel, Räume und Beschreibungen sind keine Identitäten, sofern sie im Satz nicht als Eigenname verwendet werden. Großschreibung allein reicht nicht.

Entitätstypen im aktuellen Scope: PERSON, PLACE, ORG, PROJECT. PROJECT ist ausdrücklich für benannte private Vorhaben und Produktbezeichnungen aufgenommen, nicht als beliebige neue Kategorie.

Wortlisten einzelner Lebensmittel, Räume oder Wetterbegriffe sind überholt. Pattern-Heuristiken dürfen keine dauerhafte Identität behaupten und keinen semantischen Detect-Ausfall ersetzen.

Unbestätigte Request-Treffer werden in der beobachteten Schreibweise demaskiert. Bestätigte Registry-Einträge und bestätigte Aliase werden kanonisch demaskiert. Legacy-Auto-Mappings sind nicht bestätigt.

22.2 Diagnosegrenzen und Textintegrität (2026-08-28)

Additiv. Keine Wortlisten und keine textbezogenen Ausnahmen.

Entschieden: full_detection_coverage bedeutet nur, dass jeder Detect-Chunk technisch verarbeitet wurde. Das ist kein Beweis, dass semantisch alle Identitäten erkannt wurden. Compact- und Admin-Diagnose trennen deshalb: technische Chunk-Verarbeitung, Anwendung der bestätigten Registry, semantische Treffer des aktuellen Requests, tatsächlich verwendetes Detect-Modell und semantic_identity_guaranteed=false.

Entschieden: Bestätigte lokale Identitäten und bestätigte Aliase sind die lokale Autorität für Maskierung im gesamten Generate-Egress, unabhängig vom Detect-Modell. Semantische Detect-Treffer bleiben request-scoped und werden nicht automatisch bestätigt. Generische Gruppen, Rollenbeschreibungen und Herkunftsbezeichnungen werden ohne identifizierende Bedeutung nicht zu stabilen Identitäten.

Offen / Konflikt: Neue, dem Detect unbekannte und lokal nicht bestätigte Identitäten können mit span-genauer Detection plus Registry-Safety-Net nicht verlässlich maskiert werden, ohne entweder Generate fail-closed zu halten, Detect-Vorschläge vor dem Egress reviewen zu lassen oder Wörter global zu ersetzen (widerspricht Homonym-/Allgemeinbegriff-Vertrag). Keine zusätzliche Heuristik auf Verdacht.

Entschieden (Journaltext): Nach erfolgreicher Demaskierung darf akzeptierter Modelltext lokal nicht mehr semantisch oder grammatisch umgeschrieben werden. Zulässig bleiben Titel-/Texttrennung, Zeilenenden und äußerer Whitespace. Eine Namenswiederholung ist besser als ein falsch erratener Personenbezug.

Additiv 2026-08-28 (Prüffassung vs. Ausgabe): Die interne Klartext-zu-Token-Normalisierung der Modellantwort bleibt die Prüffassung. Die sichtbare und gespeicherte Fassung rehydriert nur tatsächlich ausgegebene Platzhalter; modellseitiger Klartext behält seine Oberflächenform.

23. Externe Referenzquellen

Für die weitere technische und rechtliche Ausarbeitung wurden unter anderem folgende Primärquellen als Ausgangspunkt verwendet:

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

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.

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.