Veri gizliliği hassas kurumlar için on-premise ve hibrit kurulum yaklaşımı.

Problem: kritik iletişim verisi nerede duruyor?

Kritik iletişim sıradan bir mesajlaşma değildir. Bir SLA ihlali uyarısı, bir eskalasyon kaydı veya "okudum-onayladım" onayı; kimin neyi ne zaman gördüğünü gösteren operasyonel veridir. Bu veri çoğu zaman kişisel veri, müşteri bilgisi, işlem detayı veya kurum içi hassas süreçle iç içe geçer.

Veri gizliliği hassas kurumlarda asıl gerilim buradadır: kuruma kritik bildirim, onay ve denetim disiplini lazımdır, ama bu disiplin için kullanılan aracın bu verileri kurum dışındaki bir buluta taşıması çoğu zaman kabul edilemez. Mevzuat, iç güvenlik politikaları veya sektörel düzenlemeler verinin nerede tutulduğunu ve kimin eriştiğini açıkça sınırlar.

Klasik yöntemler neden yetersiz kalır?

Pek çok kurum bu boşluğu eldeki araçlarla kapatmaya çalışır ve sınırlara çarpar:

• Genel mesajlaşma uygulamaları verinin nerede tutulduğunu kurumun kontrolüne bırakmaz; çoğu kapalı kaynaktır ve denetim kaydı çıkarmaz.
• E-posta dağıtım sağlar ama "bu mesaj okundu ve anlaşıldı" onayını, SLA süresini ve eskalasyon zincirini yapısal olarak tutmaz.
• Yalnızca bulutta sunulan SaaS araçları veri yerelleştirme veya kapalı ağ gereksinimi olan kurumlar için baştan elenir; teknik ekip değerlendirmeye bile başlayamadan reddetmek zorunda kalır.
• Kurum içi geliştirilen ad hoc çözümler kısa vadede çalışır ama görünürlük, denetlenebilirlik ve bakım sürdürülebilirliği açısından zamanla yük haline gelir.

Sonuç olarak teknik ekip ikilemde kalır: ya gizlilik gereksiniminden ya da operasyonel disiplinden ödün verir.

Notivex yaklaşımı

Notivex kritik iletişimi tek bir mesajlaşma kanalı olarak değil; görünürlük + onay + SLA + eskalasyon + denetim kaydı olarak ele alır. Kurulum mimarisi de bu yapı taşlarının kurumun kontrol sınırı içinde çalışabilmesi üzerine konumlanır:

• Zorunlu görünürlük — kritik bildirim, görmezden gelinemeyecek şekilde alıcıya ulaşır; bu akışın ürettiği veri ise kurumun belirlediği konumda işlenecek şekilde değerlendirilir.
• Acknowledge / okudum-onayladım — alıcının onayı yapısal olarak kaydedilir; bu kayıt kurum içinde tutulabilir ve dışarı taşınmaz biçimde tasarlanabilir.
• SLA takibi — kritik konuların süre sınırı içinde ele alınıp alınmadığı izlenir; süre verisi de aynı gizlilik sınırına tabidir.
• Eskalasyon — onay gelmediğinde veya süre aşıldığında bildirim üst kademeye taşınır; eskalasyon zinciri denetlenebilir biçimde tutulur.
• Denetlenebilir operasyon kaydı (audit trail) — kim, neyi, ne zaman gördü ve onayladı bilgisi yapısal olarak kayıt altına alınır. Bu, KVKK gereksinimlerine göre yapılandırılabilen denetlenebilir bir operasyon kaydı sağlar.
• Raporlama — yanıt süreleri, açık kalan kritik konular ve eskalasyon yoğunluğu kurum içinde raporlanabilir.

Kurulum tarafında üç temel senaryo değerlendirilir:

• On-premise — uygulama ve veri katmanı tamamen kurumun kendi veri merkezinde çalışır. Veri kurum sınırından çıkmaz.
• Hibrit — bazı bileşenler kurum içinde, bazıları kontrollü dış bağlantıyla çalışır; hassas veri kurum içinde kalırken belirli işlevler dış katmanla desteklenebilir.
• Kapalı ağ / air-gapped — internet erişimi olmayan izole ağlarda çalışacak şekilde değerlendirilir. Yapay zekâ destekli karar fonksiyonları için, dışa veri göndermeyen kurum içi (local LLM) modeller bu senaryoda teknik olarak ele alınabilir.

Notivex burada mevcut e-posta, EBYS, kimlik yönetimi (LDAP/AD) veya iç sistemlerin yerine geçmeyi değil, bunları kritik iletişim görünürlüğü, onay ve denetim kaydıyla tamamlamayı hedefler.

Örnek senaryo

Bir kamu kuruluşunun bilgi işlem birimi, kritik sistem kesintilerinde nöbetçi ekiplere ulaşan bildirimlerin hem zamanında görüldüğünü hem de kayda alındığını göstermek istiyor; ancak kurum politikası gereği hiçbir operasyonel veri kurum dışına çıkamıyor.

On-premise senaryoda Notivex kurum veri merkezinde çalışacak şekilde değerlendiriliyor. Bir kesinti anında sisteme şu bildirim düşüyor:

> "KRİTİK: Çekirdek veritabanı sunucusu yanıt vermiyor. Nöbetçi sistem yöneticisinin 10 dakika içinde acknowledge vermesi bekleniyor. Onay gelmezse bildirim birim müdürüne eskale edilecektir."

Bu akışta üretilen tüm veri — bildirimin gönderildiği an, kimin gördüğü, kimin onayladığı, SLA süresi ve eskalasyon kaydı — kurumun kendi altyapısında tutulur. Teknik ekip, denetim talebi geldiğinde "bu kritik bildirim ne zaman görüldü ve kim üstlendi" sorusuna kayıt üzerinden cevap verebilir; bu sırada hiçbir veri kurum sınırını terk etmez.

Kullanılabilecek modüller

• On-Premise / Kurum İçi Kurulum — uygulama ve veri katmanının kurumun kendi altyapısında, hibrit veya kapalı ağ senaryolarına göre değerlendirildiği kurulum modeli.
• Entegrasyonlar — e-posta, dizin servisleri (LDAP/AD), izleme sistemleri ve iç uygulamalarla bağlantı; mevcut yığının yerine geçmeden tamamlama amacıyla.
• AI Karar Destek — kritik bildirimlerin önceliklendirilmesi ve eskalasyon önerilerinde, kapalı ağ ihtiyacı olan kurumlar için dışa veri göndermeyen kurum içi model seçeneğiyle değerlendirilebilen karar destek katmanı.
• Audit Trail — kim neyi ne zaman gördü ve onayladı bilgisinin denetlenebilir biçimde tutulduğu operasyon kaydı.
• SLA ve Eskalasyon — kritik konuların süre sınırı içinde ele alınmasını izleyen ve gecikmede üst kademeye taşıyan yapı.