Yapay Zeka Projesinde Kurum İçi Veri Nasıl Korunur?

Kurum içi veriler, bir yapay zeka projesini genel bir araçtan şirkete özgü bir çalışma sistemine dönüştürür. Dokümanlar, CRM kayıtları, destek talepleri, e-postalar ve operasyon verileri doğru bağlamı sağlar. Aynı veriler kontrolsüz kullanıldığında ise gereksiz erişim, kişisel veri ifşası, belirsiz saklama süreleri ve denetlenemeyen kararlar gibi riskler doğurur.

Bu nedenle güvenlik, model seçildikten sonra eklenecek bir katman değildir. Veri kaynağından kullanıcı ekranına kadar bütün akışın tasarım ölçütüdür. Bu yazı, sistemin teknik olarak nasıl kurulacağından çok, kurum içi verinin hangi kontrollerle korunacağına odaklanır. Mimari ve entegrasyon adımlarını ayrıca görmek isterseniz Kurum İçi Veriyle Çalışan Yapay Zeka Sistemi Nasıl Kurulur? yazısına geçebilirsiniz.

Aşağıdaki kontrol listesi bir hukuk görüşü değildir. KVKK ve kurumunuza uygulanan diğer düzenlemeler bakımından kapsamı, hukuki sebebi, aydınlatma yükümlülüklerini ve sözleşmeleri hukuk ekibinizle doğrulayın.

Güvenli başlangıç için hangi sorular cevaplanmalı?

İlk toplantıda yalnızca “hangi modeli kullanalım?” sorusunu sormak eksik kalır. Önce şu altı soruya kısa ve doğrulanabilir cevaplar üretin:

• Hangi veri kaynakları sisteme bağlanacak?
• Her kaynağın sahibi ve iş amacı kim tarafından onaylandı?
• Hangi kullanıcı, hangi belgeyi veya kaydı görebilir?
• Kişisel, hassas ya da ticari açıdan kritik alanlar nasıl ayıklanacak veya maskelenecek?
• Veri ve model hangi altyapıda çalışacak, hangi ülke veya bölgelerde işlenecek?
• İstekler, erişimler, çıktılar ve yönetici işlemleri nasıl kaydedilecek; kayıtlar ne kadar saklanacak?

Bu soruların cevabı yoksa pilot küçük görünse bile belirsizlik büyüktür. Güvenli pilotun ölçüsü kullanıcı sayısı değil, veri akışının sınırlarının açık olmasıdır.

1. Veri envanteri nasıl çıkarılır?

“Şirket verisi” tek bir sınıf değildir. Aynı projede herkese açık ürün kataloğu, iç prosedür, müşteri iletişim bilgisi, çalışan özlük belgesi ve ticari sır bulunabilir. Bunların aynı depoya aynı kuralla aktarılması güvenlik tasarımını zayıflatır.

Her kaynak için en az şu alanları kaydedin:

• Kaynağın adı ve teknik konumu
• İş sahibi ve teknik sahibi
• Verinin kullanım amacı
• İçerdiği veri türleri
• Gizlilik veya kritiklik sınıfı
• Güncellenme sıklığı
• Yetkili kullanıcı grupları
• Saklama ve silme kuralı
• Başka bir sisteme aktarım olup olmadığı

Envanter yalnızca bir elektronik tablo olarak kalmamalıdır. Bağlantı kurulmadan önce onay kapısı olarak kullanılmalı, yeni alanlar eklendiğinde güncellenmeli ve kullanım amacı değiştiğinde yeniden değerlendirilmelidir.

Pratik bir yöntem, kaynakları “kullanıma hazır”, “maskeleme sonrası kullanılabilir”, “ek onay gerektirir” ve “bu senaryoda kullanılmayacak” şeklinde ayırmaktır. Böylece ekip, her şeyi modele taşımak yerine iş hedefi için gereken en küçük veri kümesiyle başlar.

2. Erişim yetkileri modele nasıl yansıtılır?

Bir çalışanın CRM ekranında göremediği müşteri kaydını yapay zeka asistanından alabilmesi kabul edilebilir değildir. Modelin doğal dille cevap vermesi, kaynak sistemdeki yetki sınırlarını ortadan kaldırmaz.

Erişim tasarımında şu ilkeleri uygulayın:

• Tek bir ortak yönetici hesabıyla bütün kaynakları açmayın.
• Kimlik doğrulamayı kurumun mevcut kimlik sistemiyle birleştirin.
• Rol tabanlı yetkiyi mümkün olduğunda belge veya kayıt seviyesinde uygulayın.
• Arama ve getirme katmanında yetki filtresini, sonuç modele gönderilmeden önce çalıştırın.
• Yönetici, geliştirici ve son kullanıcı yetkilerini ayırın.
• İşten ayrılma veya görev değişikliği süreçlerinin yapay zeka sistemindeki erişimi de kapattığını test edin.
• Periyodik erişim gözden geçirmeleri yapın.

En kritik nokta, yetki kontrolünün yalnızca kullanıcı arayüzünde olmamasıdır. Arka uç servisi, arama dizini, vektör veritabanı ve dışa aktarma uçları aynı kimlik ve yetki bağlamını korumalıdır. Aksi hâlde kullanıcı ekranı doğru görünürken API üzerinden daha geniş veri sızabilir.

3. Kişisel veri ayıklama ve maskeleme ne zaman gerekir?

Her veri alanının modele gönderilmesi gerekmez. Bir talebi sınıflandırmak için müşteri adı, telefon numarası veya açık adres gerekli değilse bu alanları daha erken aşamada kaldırmak riski azaltır.

Veri minimizasyonunu üç aşamada ele alın:

1. Kaynakta azaltma: İş amacı için gereksiz tablo, klasör ve alanları hiç bağlamayın.
2. İşleme öncesi dönüşüm: Kimlik numarası, iletişim bilgisi, hesap numarası veya serbest metindeki kişisel unsurları silin, maskeleyin ya da uygun olduğunda takma adla değiştirin.
3. Çıktı kontrolü: Model yanıtında kaynak metindeki gereksiz kişisel bilgilerin tekrarlanmasını engelleyen kurallar ve testler uygulayın.

Maskeleme, her durumda geri döndürülemez anonimleştirme anlamına gelmez. Takma adlandırılmış veya maskelenmiş veri, başka bilgilerle yeniden ilişkilendirilebiliyorsa hâlâ koruma gerektirebilir. Hangi yöntemin yeterli olduğunu veri türüne ve kullanım amacına göre güvenlik ve hukuk ekiplerinizle belirleyin.

Serbest metin özellikle dikkat ister. E-posta gövdeleri ve destek notları, yapılandırılmış alanlarda görünmeyen sağlık, kimlik, finans veya çalışan bilgileri içerebilir. Otomatik tespit yararlıdır; ancak örneklem üzerinden insan kontrolü, kaçırılan ve yanlış işaretlenen alanları görmenizi sağlar.

4. Model ve veri nerede çalışmalı?

“Bulut mu, kendi sunucumuz mu?” sorusunun tek doğru cevabı yoktur. Karar, verinin sınıfına, ölçek ihtiyacına, kurumun operasyon kapasitesine, sözleşmelere ve kabul edilen risk düzeyine bağlıdır.

Bulut hizmetini değerlendirirken şunları netleştirin:

• İstek ve yanıtlar hangi bölgelerde işleniyor?
• Sağlayıcı girdileri model eğitimi veya hizmet geliştirme amacıyla kullanıyor mu?
• Veriler aktarım sırasında ve depoda şifreleniyor mu?
• Saklama kapatılabiliyor veya süre sınırı belirlenebiliyor mu?
• Alt hizmet sağlayıcılar kimler?
• Silme talebi hangi kopyaları ve yedekleri kapsıyor?
• Kurumsal sözleşme ile tüketici ürünü arasında veri kullanımı farkı var mı?

Kendi sunucunuzda çalıştırmak üçüncü tarafa aktarımı azaltabilir; fakat otomatik olarak daha güvenli değildir. Yama yönetimi, anahtar saklama, ağ ayrımı, kapasite, yedekleme, izleme ve olay müdahalesi kurumun sorumluluğunda kalır. Yönetilemeyen bir yerel kurulum, iyi yönetilen kurumsal bulut ortamından daha riskli olabilir.

Kararı ürün adı üzerinden değil, veri akış şeması üzerinden verin. Kaynağın, geçici dosyaların, arama dizininin, model çağrısının, günlüklerin ve yedeklerin nerede bulunduğunu ayrı ayrı gösterin.

5. Kayıt ve denetim izi nasıl tasarlanır?

Bir olay olduğunda “kim, ne zaman, hangi kaynağa erişti?” sorusu cevaplanamıyorsa sistem denetlenebilir değildir. Bununla birlikte günlüklerin kendisi de hassas veri deposuna dönüşmemelidir.

İyi bir denetim izi şu olayları kapsar:

• Kullanıcı ve oturum kimliği
• İstek zamanı ve kullanılan uygulama
• Erişilen veri kaynağı veya belge kimliği
• Uygulanan yetki politikasının sonucu
• Kullanılan model ve önemli yapılandırma sürümü
• Yönetici değişiklikleri
• Dışa aktarma, paylaşma ve toplu indirme işlemleri
• Güvenlik filtresi veya politika ihlali uyarıları

Tam istem ve yanıtı her zaman kaydetmek yerine ihtiyaca göre kimlik, özet, sınıflandırma veya güvenli bir referans saklamak daha doğru olabilir. Günlüklere erişimi sınırlandırın, bütünlük kontrolleri uygulayın ve olağan dışı toplu sorgu, farklı departman verisine erişim ya da mesai dışı indirme gibi davranışlar için uyarı üretin.

NIST AI Risk Management Framework, yapay zeka risklerini yönetişim, ölçüm ve izleme boyutlarıyla ele almak için yararlı bir çerçeve sunar. Uygulama güvenliği kontrollerini gözden geçirirken OWASP GenAI Security Project kaynakları da teknik ekiplere başlangıç noktası sağlayabilir.

6. Saklama süresi ve silme nasıl yönetilir?

“Sınırsız saklayalım, ileride lazım olabilir” yaklaşımı hem risk alanını hem olay anındaki etkiyi büyütür. Her veri kopyası için amaçla uyumlu bir süre tanımlayın.

Ayrı ayrı değerlendirilmesi gereken katmanlar şunlardır:

• Kaynak sistemdeki asıl kayıt
• Aktarım için oluşan geçici dosya
• Belge parçaları ve arama dizini
• Vektör gösterimleri
• İstem ve yanıt günlükleri
• Kullanıcı geri bildirimleri
• Hata kayıtları
• Yedekler

Silme işlemini yalnızca ana veritabanındaki satırın kaldırılması olarak görmeyin. Arama indeksleri, önbellekler, dosya depoları ve yedek politikaları da sürece dahil olmalıdır. Süre dolduğunda otomatik işleyen bir mekanizma kurun; istisnaları gerekçesi ve onaylayan kişiyle kaydedin. Silme işlemini örnek kayıtlar üzerinden düzenli olarak test edin.

KVKK bakımından veri işleme şartları, amaçla sınırlılık, saklama ve aktarım gibi başlıkların somut duruma göre değerlendirilmesi gerekir. Güncel rehberler için Kişisel Verileri Koruma Kurumu kaynaklarını izleyin; projenize özgü yorum ve yükümlülükleri hukuk ekibinizle doğrulayın.

Sahadan bir senaryo: satış asistanı güvenli biçimde nasıl sınırlandırılır?

Bir şirketin satış ekibi için CRM notlarını, teklif dokümanlarını ve ortak e-posta kutusunu tarayan bir asistan düşündüğünü varsayalım. Amaç, müşteri görüşmesi öncesinde kısa bir hazırlık özeti üretmek olsun.

Kontrolsüz yaklaşımda bütün CRM dışa aktarılır, e-postalar tek bir depoya kopyalanır ve tüm satış ekibi aynı arama yetkisini kullanır. Bu tasarımda farklı bölgelere ait müşteri kayıtları, çalışan yazışmaları veya artık kullanılmaması gereken eski ekler gereksiz biçimde erişilebilir hâle gelebilir.

Daha güvenli yaklaşım şu sırayı izler:

1. Yalnızca hazırlık özeti için gereken CRM alanları belirlenir.
2. Kişisel telefon, özel not ve gereksiz serbest metin alanları kapsam dışı bırakılır veya maskelenir.
3. Kullanıcının CRM bölgesi ve hesap yetkisi, arama katmanında filtre olarak uygulanır.
4. E-posta kutusunda yalnızca onaylanmış klasörler ve güncel dönem işlenir.
5. Her özette kullanılan kaynak kimlikleri kaydedilir; kullanıcı kaynağa yalnızca mevcut yetkisi varsa ulaşabilir.
6. İstem ve yanıtlar için kısa ve gerekçeli bir saklama süresi tanımlanır.
7. Yanlış kişiye ait bilgi, talimat enjeksiyonu içeren belge ve toplu veri istemi gibi durumlar test edilir.

Binode yaklaşımında bu tür bir senaryo, önce dar kapsamlı ve gözlemlenebilir bir akış olarak ele alınır. Amaç ilk günden bütün kurumsal hafızayı modele açmak değil, iş değerini gösterecek en küçük veri kümesini doğru kimlik, yetki ve kayıt kontrolleriyle çalıştırmaktır. Pilot sonucu yalnızca yanıt kalitesiyle değil, reddedilmesi gereken isteğin reddedilmesi ve erişimin izlenebilmesiyle de değerlendirilir.

Canlıya geçmeden önce pratik kontrol listesi

Aşağıdaki maddelerin her biri için bir sorumlu, kanıt ve gözden geçirme tarihi belirleyin:

• Veri kaynakları, sahipleri ve kullanım amaçları envanterde kayıtlı.
• Gereksiz klasör, tablo ve alanlar kapsam dışında.
• Veri sınıfları ve kritik alanlar tanımlı.
• Kişisel veri için ayıklama, maskeleme veya başka bir koruma kararı verilmiş.
• Kullanıcı yetkileri kaynak sistemle tutarlı ve kayıt seviyesinde uygulanıyor.
• Yönetici, geliştirici ve son kullanıcı rolleri ayrılmış.
• Model sağlayıcısının veri kullanımı, bölgesi ve saklama koşulları incelenmiş.
• Aktarım ve depolama şifrelemesi doğrulanmış.
• Anahtarlar ve sırlar koddan ayrılmış, erişimleri sınırlandırılmış.
• Günlüklerin kapsamı belirlenmiş; günlüklerde gereksiz hassas veri tutulmuyor.
• Olağan dışı erişimler için uyarı ve olay müdahale yolu hazır.
• Her veri kopyası için saklama ve silme süresi tanımlı.
• Yedek, indeks, önbellek ve geçici dosya silme sürecine dahil.
• Yetki aşımı, veri sızıntısı ve kötü niyetli belge senaryoları test edilmiş.
• Hukuk, bilgi güvenliği, veri sahibi ve iş birimi onayları kayıtlı.

Sonuç

Kurum içi veriyi yapay zeka sisteminde güvenle kullanmak, tek bir güvenlik ürünü satın almakla çözülmez. Veri envanteri, en az yetki, veri minimizasyonu, doğru barındırma kararı, denetim izi ve süreli saklama birlikte çalışmalıdır.

En iyi başlangıç, tüm veriyi bir araya getirmek değil, belirli bir iş senaryosu için gereken en küçük veri kümesini görünür kontrollerle işletmektir. Bu yaklaşım hem pilotun daha hızlı öğrenmesini sağlar hem de kapsam büyürken hangi riskin neden kabul edildiğini gösterir.

Sık sorulan sorular

Kurum içi veri genel amaçlı bir yapay zeka aracına yüklenebilir mi?

Aracın kurumsal sözleşmesini, veriyi hangi amaçla kullandığını, saklama süresini, işleme bölgelerini ve erişim kontrollerini incelemeden yükleme yapılmamalıdır. Veri sınıfınıza uygunluğu güvenlik ve hukuk ekiplerinizle doğrulayın.

Veriyi maskelemek tek başına yeterli midir?

Hayır. Maskeleme önemli bir kontroldür; ancak erişim yetkisi, aktarım güvenliği, günlükler, saklama süresi ve çıktı kontrolleriyle birlikte uygulanmalıdır.

Kendi sunucumuzda model çalıştırmak her zaman daha mı güvenlidir?

Hayır. Yerel çalışma bazı aktarım risklerini azaltabilir, fakat yama, ağ güvenliği, izleme, anahtar yönetimi ve olay müdahalesi sorumluluğunu kuruma taşır. Kararı operasyon kapasitesi ve veri akışı üzerinden verin.

Vektör veritabanındaki kayıtlar kişisel veri içerebilir mi?

Belge parçaları ve bunlardan üretilen gösterimler kaynak içerikle ilişkilendirilebilir. Bu katmanı otomatik olarak anonim kabul etmeyin; erişim, saklama ve silme kurallarına dahil edin.

Güvenlik testinde yalnızca doğru cevapları mı ölçmeliyiz?

Hayır. Sistem, kullanıcının yetkisi olmayan kaynağı vermemeli, zararlı talimat içeren belgelerden etkilenmemeli ve toplu veri çıkarma girişimlerini sınırlandırmalıdır. Reddetme davranışı da kabul kriteridir.