Kurumsal mühendislik ekipleri veriye dokunan her iş akışına AI ekleme baskısı altında. Gizlilik ve güvenlik ekipleri ise üretim bağlamını ağın içinde tutmak için aynı ölçüde baskı görüyor. Bu iki hedef en sert biçimde sessiz fakat önemli bir noktada çarpışıyor: PII sınıflandırma. Yani maskeleme, alt kümeleme veya test ortamına kopyalama başlamadan önce hangi kolonların, serbest metin alanlarının ve iç içe JSON anahtarlarının hassas olduğuna karar verme işi.
Tartışma çoğu zaman “AI kullanalım mı, kullanmayalım mı?” şeklinde kurulur. Bu yanlış çerçevedir. Kalıcı soru daha dar ve mimaridir:
Model nerede çalışmalı?
Inference sağlayıcı bulutunda çalışırsa sınıflandırma hızlanabilir; ancak korumaya çalıştığınız bağlam için yeni bir veri çıkış yolu yaratılır. Inference hiç çalışmazsa ekipler şema değiştiği anda eskiyen kırılgan kurallara ve kurumsal hafızaya geri döner. Ciddi yaklaşım bu iki uç arasındadır: belirsiz ve yüksek riskli kararlarda insanın yetkisini koruyan, güven sınırı içinde çalışan destekleyici AI.
Bu yazı klasik sınıflandırmanın modern veri mimarilerinde neden yetersiz kaldığını, bulut LLM desteğinin düzenlemeye tabi ortamlar için neden sahte bir rahatlık sunduğunu ve ağ içinde çalışan kalıcı modelin pratikte nasıl göründüğünü açıklıyor.
Sınıflandırma neden sessizce bozuldu?
Uzun süre “PII’yi bulmak”, kolon adlarını taramak ve kısa bir regex listesi çalıştırmak anlamına geldi: email, ssn, phone, national_id. Şemalar küçük, isimlendirme dürüst ve hassas değerler tipli kolonlarda düzenli biçimde tutulduğunda bu yöntem çalışıyordu.
Modern veritabanı mimarileri bu kadar düzenli değildir.
1. Kolon adları yanıltır ve değişir
user_ref adlı alan e-posta adresi tutabilir. meta içinde kimlik numarası bulunabilir. payload ödeme token’ı veya OAuth secret içerebilir. Dünün isimlendirme kurallarına göre ayarlanmış heuristics, yarının geliştirici kısaltmalarını veya mikroservis migration’larını kaçırır.
2. PII serbest metnin içine gizlenir
Destek notları, sohbet kayıtları, teslimat talimatları ve hata logları düzenli olarak ad, telefon numarası ve adres içerir. +1-555-0100 biçimini yakalayan regex, "Saat 18:00’den sonra Jane’i cep telefonundan ara" gibi bir cümlede hassas bağlamı göremez.
3. İç içe JSON saldırı yüzeyini büyütür
PostgreSQL’de sıradan bir JSONB audit kolonu veya MongoDB dokümanı düşünün:
{
"event": "checkout_completed",
"actor": {
"id": "usr_948102",
"contact": { "primary_email": "jane@example.com" }
},
"metadata": { "billing_country": "US", "tax_id": "12-3456789" }
}
JSONB kolonunun tamamını tek bir binary nesne gibi maskelemek yerel geliştirmedeki veri faydasını yok eder. İç yapıyı görmezden gelmek ise bu kopyayı alan her test ortamında tanımlayıcıların kalmasına yol açar.
4. Şema drift’i statik denetimleri geçersiz kılar
Mikroservisler sürekli şema migration’ı üretir. Statik sınıflandırma spreadsheet’i veya üç aylık güvenlik incelemesi, ticket kapandığında bile eskimiştir. Paylaşılan staging’e ve seyrek refresh’e güvenen ekipler aynı sorunla karşılaşır: hassas veri haritası her zaman üretimin gerisindedir.
Yanlış seçenekler: Yavaş, sızıntılı veya kırılgan
Ekipler bu baskı altında genellikle üç varsayılan mühendislik takasından birini seçer.
| Model | Kapasite ve gecikme | Ağ dışına veri çıkış riski | Drift ve bağlama uyum |
|---|---|---|---|
| Manuel inceleme ve spreadsheet | ❌ Düşük, backlog büyür | ✅ Veri çıkışı yok | ❌ Düşük, geriden gelir |
| Bulut LLM API inference | ⚠️ API gecikmesi ve maliyet | ❌ Yüksek çıkış riski | ✅ Yüksek bağlam farkındalığı |
| Statik regex ve sözlükler | ✅ Çok hızlı | ✅ Veri çıkışı yok | ❌ Drift karşısında kırılgan |
| Katmanlı, ağ içi yerel AI | ✅ Yüksek, saniye altı hedef | ✅ Veri çıkışı yok | ✅ Yüksek bağlam ve uyum |
1. Her şeyi manuel incelemek
Güvenlik operatörleri örnek satırları inceler, etiketleri onaylar ve kuralları elle günceller. Küçük şemalarda işe yarar; yüzlerce mikroserviste ölçeklenmez. İnceleme backlog’u temel güvenlik riskine dönüşür: sınıflandırılmayan kolonlar test ortamına “unknown” olarak gider; pratikte bu, maskelenmemiş demektir.
2. Bağlamı bulut LLM’ine göndermek
Şema parçalarını, örnek satırları veya serbest metin alıntılarını hosted model API’sine göndermek sınıflandırma doğruluğunu artırabilir. Ancak hassas bağlam için yeni bir işleme konumu ve veri çıkış yolu yaratır. Sağlayıcı koşulları, veri yerleşimi soruları ve prompt loglama riskleri de beraberinde gelir.
[!WARNING] Veri çıkışı paradoksu: Bir verinin hassas olup olmadığını belirlemek için sınıflandırılmamış ham veriyi genel internet üzerinden dış inference API’sine göndermek; SOC 2, GDPR ve HIPAA açısından döngüsel bir uyumluluk riski yaratır.
3. Regex ve sözlükleri büyütmek
Pattern kütüphaneleri kredi kartı veya kimlik numarası gibi yüksek kesinlikli biçimlerde hâlâ değerlidir. Fakat serbest metin, çok dilli alanlar ve iç içe doküman payload’ları için yeterli değildir. Yalnızca regex’e güvenen ekipler dashboard’da yüksek kapsam gösterirken pratikte hassas alanları sızdırabilir.
Ağ içi mimari: Güven sınırı içinde katmanlı zekâ
Kalıcı mimari sınıflandırmayı maliyet, gecikme ve bağlam derinliğine göre yürütme katmanlarına ayırır:
┌─────────────────────────────────────────┐
│ Veritabanı / Şema Drift'i │
└────────────────────┬────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Katman 1: Hızlı Heuristics ve Pattern │ (rutin alanların %80'i)
└────────────────────┬────────────────────┘
│ (belirsiz alan / serbest metin)
▼
┌─────────────────────────────────────────┐
│ Katman 2: Ağ İçi Yerel AI (SLM) │ (müşteri VPC / yerel Ollama)
└────────────────────┬────────────────────┘
│ (düşük güvenli edge case)
▼
┌─────────────────────────────────────────┐
│ Katman 3: İnsan Yönetişim Döngüsü │ (politika onayı)
└────────────────────┬────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Sonraki işlem: Maskele / Alt Kümele │
└─────────────────────────────────────────┘
Temel mimari ilkeleri
- Ham bağlamı ağ içinde tutun: Inference modeli veri kaynağına yakın, müşteri VPC’si veya özel ağ içinde çalışır. Müşteri verisi içeren outbound API çağrıları ortadan kalkar.
- Katmanlı yürütme: Micro-heuristics rutin tipli kolonların yaklaşık %80’ini token maliyeti olmadan anında işler. Ollama veya vLLM üzerinde çalışan Llama-3 8B ya da Phi-3 gibi küçük yerel modeller belirsiz kolon adlarını ve serbest metin örneklerini sınır içinde değerlendirir.
- Yönetişimli destekleyici AI: Model sınıflandırma ve güven skoru önerir. Güvenlik operatörleri her boolean kolonu incelemek yerine edge case’lere odaklanır.
- Kapalı döngü teslim: Sınıflandırma çıktıları doğrudan maskeleme, referans alt kümeleme ve ortam üretimini besler.
- Denetlenebilir karar lineage’ı: Her etiket hangi kuralın veya yerel modelin çalıştığını, güven skorunu ve operatör onay geçmişini kaydeder.
Ark ile pratik uygulama
Subsetra Ark bu mimariyi yalnızca outbound bağlantı kuran VPC agent’ı ile uygular.
Kontrol düzlemi işleri ve güvenlik politikalarını orkestre eder; agent ise sınıflandırma, maskeleme ve alt kümelemeyi doğrudan müşteri veri sınırı içinde çalıştırır. Inbound firewall portu gerekmez. Agent iş tanımlarını almak ve durum bildirmek için outbound TLS bağlantısı kurar.
┌───────────────────────────┐ ┌───────────────────────────────────────────┐
│ Ark Control Plane │ ◄── Outbound ───│ Müşteri VPC Agent │
│ Politika ve Yönetişim │ Yalnız TLS │ ┌──────────────┐ ┌───────────────┐ │
└───────────────────────────┘ │ │ Yerel Engine │ ────►│ Yerel SLM │ │
│ │ Mask/Subset │ │ Inference │ │
│ └──────┬───────┘ └───────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Kaynak DB │ │
│ └──────────────┘ │
└───────────────────────────────────────────┘
Ark bağlamsal sınıflandırma için Ollama veya yerel ONNX runtime gibi yerel model inference seçeneklerini kullanır. Pipeline kapalı döngüde çalışır:
$$\text{Sınıflandır (Yerel AI)} \longrightarrow \text{İncele (Yönetişim)} \longrightarrow \text{Maskele (Politika)} \longrightarrow \text{Alt Kümele ve Teslim Et}$$
Onaylanmış sınıflandırmalar; referans bütünlüğü korunmuş alt kümeler ile CI/CD ve geliştirme için geçici, üretime benzer veritabanları dahil olmak üzere maskeleme politikalarını ve ortam oluşturmayı doğrudan besler.
Otomatik ağ içi sınıflandırma olmadığında ekipler tam üretim replikalarına geri döner. Tam replikaların neden yanlış varsayılan olduğunu anlamak sınıflandırmayla başlar: hassas alanlar haritalanmamışsa güvenli alt küme oluşturulamaz.
Ağ içi sınıflandırma için operasyon metrikleri
Ağ içi sınıflandırma sistemini değerlendiren ekipler beş temel metriği ölçmelidir:
- Sıfır outbound veri çıkışı: Ham veri örneklerinin, kolon değerlerinin ve serbest metin parçalarının tamamı iç ağ sınırında kalır.
- Şema drift tespit SLA’i: Yeni kolon ve doküman anahtarları, migration’dan saniyeler sonra otomatik bulunur ve sınıflandırılır.
- İnceleme backlog’unda azalma: Operatör yalnızca düşük güvenli belirsizliği inceler; manuel iş yükü %90’dan fazla azalabilir.
- Uçtan uca pipeline gecikmesi: Sınıflandırmadan maskelenmiş ortam teslimine kadar süreç CI/CD ihtiyacını karşılayacak biçimde dakikalar içinde tamamlanır.
- Maskeleme doğruluğu ve residual kontrol: Maskelenmiş çıktı otomatik taranarak test ortamına teslimden önce kalan PII sızıntısı doğrulanır.
Özet
Gizlilik kontrollerini geliştirici hızının önündeki engel olarak görmek eski bir varsayımdır. Bulut LLM API’leri ağ çevresi güvenliğinden ödün vererek hız sunar.
Yerel, ağ içi AI desteği bu takası ortadan kaldırır. Inference ham verinin yanında çalıştığında organizasyonlar katı sıfır veri çıkışı sınırını korurken şema drift’i altında sürekli sınıflandırma sağlayabilir.
Ark’ın ağ içi sınıflandırmayı ve test verisi orkestrasyonunu altyapınızda nasıl yürüttüğünü incelemek için: