735 lines
26 KiB
Markdown
735 lines
26 KiB
Markdown
---
|
||
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.
|
||
|
||
## 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 | 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 |
|
||
| 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 |
|
||
|
||
---
|
||
|
||
# 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.
|
||
|