Appearance
Zero-Knowledge Çıkarım ve Kimlik Körlüğü (Zero-Knowledge Architecture)
Bu doküman, Humindx platformunun yapay zeka modelleriyle etkileşim kurarken kullanıcı kimliği (PII) ile psikometrik veriyi nasıl birbirinden kopardığını ve "Kimlik Körü" (Identity-Blind) veri işleme protokollerini tanımlar.
Kapsam Uyarısı: Bu doküman, işlem anındaki (In-Memory / In-Transit) veri anonimleştirme ve dış LLM sağlayıcılarına veri gönderim ilkelerini kapsar. Vektörel saklama şifrelemesi için
vector-privacy.md, veritabanı şema izolasyonu için../architecture/context-rooms-design.mddosyasına bakınız.
1. Temel Problem: LLM Sağlayıcılarına Veri Sızıntısı
Humindx, Cold Path (Çıkarım) aşamasında Claude 3.5 Sonnet veya GPT-4o gibi harici (External) LLM sağlayıcılarını kullanır. Eğer bir kullanıcının sohbet transkripti doğrudan dış API'ye gönderilirse, şu güvenlik açıkları doğar:
- PII Sızıntısı: Kullanıcı sohbette "Benim adım Can, X şirketinde çalışıyorum" diyebilir. Dış LLM sağlayıcısı bu veriyi görebilir.
- Yanlılık (Bias) Riski: LLM, kullanıcının cinsiyetini veya demografik bilgisini transkriptten anlarsa, çıkarım yaparken (Big Five) önyargılı (biased) davranabilir.
Çözüm: Zero-Knowledge Çıkarım (Kimlik Körü Mimari) ve PII Maskeleme (Data Sanitization).
2. Kimlik ve Veri Ayrıştırması (Identity Decoupling)
Humindx sisteminde "Kullanıcı" (User) ve "Genom" (Genome) iki farklı dünyada, iki farklı veritabanında yaşar.
| Veritabanı / Servis | İçerik | Anahtar (Key) | Erişen Katman |
|---|---|---|---|
| Identity DB | Ad, Soyad, E-posta, Şifre Hash'i | user_id: 101 | Sadece API Gateway (Auth) |
| Psychometric DB | Big Five Skorları, Bağlam Odaları | genome_id: hash_xyz | Sadece Core Engine (Backend) |
İzolasyon Kuralı: Core Engine (Psikometrik Motor), işlediği transkriptin kime ait olduğunu (Ad, E-posta) asla bilmez. Sadece genome_id üzerinden gelen anonim bir metni okur ve o genome_id'nin skorlarını günceller. İki veritabanı arasındaki eşleştirme (Mapping) yalnızca API Gateway seviyesinde anlık olarak yapılır ve RAM'de tutulur, diske yazılmaz.
3. PII Maskeleme (Data Sanitization Pipeline)
Ham metin, dış bir LLM sağlayıcısına (Inference için) gönderilmeden önce özel bir Sanitization (Temizleme) ara katmanından geçer.
3.1. Akış Adımları:
- Event Tüketimi: Event Bus'tan
SCENARIO_COMPLETEDolayı alınır. Metin anonimdir (genome_idile bağlıdır). - NER (Named Entity Recognition) Filtresi: Hafif ve lokal bir NLP modeli (Örn: spaCy veya lokal Llama-3-8B), metnin içindeki Özel İsimleri (Kişi, Şirket, Lokasyon, Telefon) tespit eder.
- Redaksiyon (Redaction): Tespit edilen PII verileri deterministik olmayan token'larla değiştirilir.
- Orijinal Metin: "Bugün yöneticim Ali Bey beni çok zorladı, Microsoft'taki kariyerim bitiyor."
- Sanitized Metin: "Bugün yöneticim
[PERSON_1]beni çok zorladı,[COMPANY_1]'daki kariyerim bitiyor."
- LLM Çıkarımı: Claude/GPT-4 API'sine sadece redakte edilmiş bu metin gider. AI, "Ali" veya "Microsoft" isimlerini bilmeden, sadece anlamsal stres ve iletişim yapısı üzerinden (Zero-Knowledge)
shift_valuehesaplar.
4. Kara Kutu İmha Protokolü (Black Box Immolation)
Kullanıcının yazdığı ham cümlelerin (PII içeren orijinal metinlerin) maksimum 24 saat yaşadığını (vector-privacy.md) belirtmiştik. Bu imha işleminin teknik ispatı şu şekildedir:
4.1. Bellek İçi Saklama (In-Memory Only)
Kullanıcının Hot Path'te (Chat Engine) yaptığı konuşmanın transkripti, ilişkisel veritabanına (PostgreSQL) kesinlikle yazılmaz. Transkript, sadece geçici olarak Redis üzerinde saklanır.
4.2. TTL ve Asenkron İmha
- Redis üzerindeki her
chat_sessionanahtarına katı birEXPIRE 86400(24 saat) komutu atanır. Sistem çökse dahi Redis motoru bu veriyi süresi dolduğunda otonom olarak yok eder. - Eğer Cold Path (Inference) başarılı bir şekilde çalışıp psikometrik delta'ları (shift_value) çıkarırsa ve
pgvector'e gürültülü (noise-injected) aktarım yapılırsa, sistem 24 saati beklemeden Redis key'ini anında siler (DEL chat_session_{id}). - Sonuç: Sunucularımız polis veya regülatörler tarafından fiziksel olarak kopyalansa (Snapshot alınsa) bile, kullanıcının ne yazdığı (Plain Text) diskte fiziksel olarak var olmadığı için bulunamaz.
5. Sağlayıcı (Vendor) Veri Sözleşmeleri
Dış LLM API'lerinin kullanımı, Zero-Knowledge felsefesinin en zayıf halkasıdır. Bunu hukuki ve teknik olarak güvence altına almak için:
- Zero-Retention API (Sıfır Veri Tutma): OpenAI ve Anthropic'in "Enterprise" veya "API" katmanları kullanılır. Bu sözleşmelere göre, API üzerinden gönderilen veriler (Sanitize edilmiş olsa bile) sağlayıcıların modellerini eğitmek (training) için kullanılamaz ve sunucularında kalıcı olarak saklanamaz (Zero Data Retention Policy).
- Kendi Modelimize Geçiş (Future-Proofing): Altyapı, HuggingFace/vLLM tabanlı yerel modellere (On-Premise LLM) geçiş yapabilecek şekilde "LLM Agnostic" (Modele Bağımsız) olarak tasarlanmıştır.
Son Güncelleme: 2026-04-15 — Identity Decoupling, PII Sanitization pipeline, Redis In-Memory Immolation ve Vendor sözleşme ilkeleri tanımlandı.