Ana sayfa ›
Güvenlik, Kalite & Yönetişim ›
Ek D - Olay Senaryoları
🚨Ek D - Üretken Yapay Zeka Kaynaklı Olay Senaryoları
📑 Bu sayfada
⚠️ BGYS Eki
Bu ek, Acil Durum ve Olay Yönetim Prosedürü'nün üretken yapay zeka kaynaklı olaylara ilişkin ekidir ve o prosedürle birlikte uygulanır. Prosedürün genel bildirim, kayıt ve eskalasyon kuralları geçerliliğini korur; bu ek yalnızca yapay zeka araçlarına özgü olay tiplerini, tespit yollarını ve müdahale adımlarını tanımlar. Framework içindeki karşılıkları: 11.0 AI Yönetişim Komitesi, 13.1 Shadow AI Önleme, 5.4 Halüsinasyon Kontrolü.
D.1 - Olay Tipleri
Aşağıdaki altı tip, üretken yapay zeka kullanımından doğabilecek olayları kapsar. Her olay kaydında tip kodu zorunludur; kod, olayın hangi müdahale akışına gireceğini belirler.
| Kod | Olay Tipi | Tanım ve Örnek Senaryo | Tespit Yolu | İlk Müdahale Adımı | Sorumlu Rol |
|---|---|---|---|---|---|
| ÜZ-01 | Prompt yoluyla veri sızıntısı | Sınıflandırma kuralına aykırı verinin bir yapay zeka aracına girdi olarak verilmesi. Örnek: Çalışan, müşteri sözleşmesinin tam metnini onaysız bir web arayüzüne yapıştırıp özet istiyor. |
Çalışanın kendi bildirimi, ekip içi gözden geçirme, yönetici gözlemi, araç yönetici panelindeki kullanım ve paylaşım kayıtları | Girdinin hangi araca, hangi hesapla ve hangi veri sınıfıyla verildiğini tespit et; varsa sohbet kaydını ve paylaşım bağlantısını sil; hesabın ilgili araçtaki erişimini gözden geçir | Bilgi güvenliği sorumlusu |
| ÜZ-02 | Kişisel veri ihlali | Kişisel verinin yetkisiz kişilerce erişilebilir hale gelmesi veya amaç dışı işlenmesi. Örnek: Aday değerlendirme notları kişi adlarıyla birlikte üçüncü taraf bir araca girilmiş. |
İlgili kişi başvurusu, iş birimi bildirimi, Microsoft Defender uyarısı, Entra oturum açma kayıtlarının incelenmesi | İşlemeyi durdur; etkilenen veri kategorilerini ve ilgili kişi sayısını belirle; veri koruma sorumlusunu gecikmeksizin bilgilendir ve D.3 akışını başlat | Veri koruma sorumlusu (DPO) |
| ÜZ-03 | Fikri mülkiyet veya kaynak kod kaybı | Kuruma veya müşteriye ait özgün içerik, yöntem ya da kaynak kodun onaysız bir modele aktarılması. Örnek: Müşteri projesine ait özel veri modeli betiği, kurumsal olmayan bir hesapla açılan araca yüklenmiş. |
Depo erişim ve indirme kayıtları, geliştirme aracı oturum kayıtları, kod gözden geçirme, çalışan bildirimi | Aktarılan içeriğin kapsamını ve müşteri sözleşmesine etkisini belirle; ilgili hesabın depo erişimini askıya al; hukuk birimini bilgilendir | Yazılım geliştirme yöneticisi |
| ÜZ-04 | Hatalı çıktıya dayalı karar zararı | Doğrulanmamış yapay zeka çıktısının karara, teslimata veya resmi yazışmaya girdi olması sonucu oluşan zarar. Örnek: Halüsinasyon içeren bir mevzuat yorumu, müşteriye gönderilen teklife olduğu gibi aktarılmış. |
Müşteri şikayeti veya itirazı, iç kalite kontrol, teslimat gözden geçirmesi, ikinci göz kontrolünde yakalanma | Hatalı çıktının nerelere yayıldığını çıkar; etkilenen teslimatları geri çağır veya düzelt; müşteri iletişimini tek elden yürüt | İlgili iş birimi yöneticisi |
| ÜZ-05 | Onaysız araç kullanımı (Shadow AI) | Onaylı araç listesinde yer almayan bir yapay zeka aracının iş amaçlı kullanılması. Örnek: Bir ekip, kurumsal hesap yerine kişisel hesapla açılmış bir araç üzerinden toplantı kaydı özetletiyor. |
Entra uygulama oturum açma kayıtları, Intune uç nokta uygulama envanteri, lisans envanteri ile fiili kullanım arasındaki uyuşmazlık, yönetici gözlemi, çalışan bildirimi | Kullanımı durdur; araca girilmiş veri sınıfını belirle; kullanım gerekçesini dinle ve onaylı bir muadil öner; tekrar eden kullanımda 13.1 eskalasyonunu uygula | Bilgi güvenliği sorumlusu |
| ÜZ-06 | Model veya sağlayıcı kaynaklı kesinti | Kullanılan modelin veya sağlayıcının erişilemez olması, davranışının habersiz değişmesi ya da sürümün kullanımdan kaldırılması. Örnek: Sağlayıcı bir model sürümünü emekliye ayırınca bağlı ajan akışları hata vermeye başlıyor. |
Sağlayıcı durum sayfası ve duyuruları, izleme uyarıları, kullanıcı bildirimleri, hata oranındaki ani artış | Etkilenen servisleri ve iş akışlarını listele; varsa yedek modele geç; etkilenen birimleri ve beklenen süreyi duyur | Platform ve altyapı sorumlusu |
ℹ️ Tespit Yönteminin Sınırı
Kurumda veri kaybı önleme (DLP), bulut erişim güvenlik aracısı (CASB), güvenli web geçidi veya SaaS keşif çözümü bulunmamaktadır. Bu nedenle ÜZ-01, ÜZ-03 ve ÜZ-05 tipleri otomatik olarak engellenmez; tespit, yukarıdaki tabloda sayılan idari ve kimlik katmanı kayıtlarına ve çalışan bildirimine dayanır. Bu sınır, eğitim ve bildirim kültürünün neden birincil kontrol olduğunu açıklar (bkz. Ek C).
D.2 - Şiddet Sınıflandırması ve Yanıt Süreleri
| Şiddet | Tanım | Tipik Örnek | İlk Yanıt | Bildirim | Kapanış Hedefi |
|---|---|---|---|---|---|
| P0 | Kişisel veri ihlali gerçekleşmiş veya müşteriye ait gizli veri kurum dışına çıkmış; yasal bildirim yükümlülüğü doğmuş olabilir | ÜZ-02 doğrulanmış ihlal, ÜZ-01 ile müşteri sözleşmesinin tamamının dış araca aktarılması | 1 saat | TIO, DPO, ilgili iş birimi yöneticisi; 24 saat içinde AI Yönetişim Komitesi olağanüstü toplantısı (bkz. 11.0) | 5 iş günü |
| P1 | Gizli veya dahili veri onaysız bir araca girilmiş, dışarı yayılma doğrulanmamış; ya da hatalı çıktı müşteriye ulaşmış | ÜZ-04 müşteriye giden hatalı çıktı, ÜZ-03 kaynak kod aktarımı, tekrar eden ÜZ-05 | 4 saat | TIO, bilgi güvenliği sorumlusu, ilgili yönetici | 10 iş günü |
| P2 | Politikaya aykırılık var ancak veri sınıfı dahili veya genel; dış etki yok | İlk kez görülen ÜZ-05, dahili belgeyle yapılan onaysız deneme | 1 iş günü | Bilgi güvenliği sorumlusu, ilgili yönetici | 20 iş günü |
| P3 | Servis kesintisi veya kalite düşüşü; veri güvenliği etkisi yok | ÜZ-06 sağlayıcı kesintisi, model sürüm değişikliği kaynaklı kalite düşüşü | 2 iş günü | Platform sorumlusu | Bir sonraki çeyrek gözden geçirmesi |
Şiddet, olayın açılışında atanır ve inceleme sırasında yükseltilebilir. Şiddet düşürme yalnızca TIO onayıyla ve gerekçesi kayda geçirilerek yapılır. Süreler, olayın kayda alındığı andan itibaren işler.
D.3 - KVKK İhlal Bildirim Akışı
ÜZ-02 tipi bir olayda veya başka bir tipin kişisel veri içerdiğinin anlaşıldığı her durumda bu akış işletilir. Akış, Komtaş KVKK Politikası ve kişisel veri saklama ve imha politikasıyla birlikte uygulanır.
| # | Adım | Sorumlu | Süre | Tutulacak Kayıt |
|---|---|---|---|---|
| 1 | Olayın veri koruma sorumlusuna iletilmesi | Olayı tespit eden veya olay sahibi | Gecikmeksizin, en geç aynı iş günü | Olay kaydı, tespit zamanı, tespit eden |
| 2 | İhlal değerlendirmesi: kişisel veri var mı, hangi kategoriler, kaç ilgili kişi, olası sonuçlar | Veri koruma sorumlusu, bilgi güvenliği sorumlusu | Bildirimden sonra en kısa sürede | Değerlendirme notu ve gerekçe |
| 3 | Kişisel Verileri Koruma Kurulu'na bildirim | Veri koruma sorumlusu | İhlalin öğrenildiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde | Kurul bildirim formu ve gönderim kaydı |
| 4 | İlgili kişilere bildirim | Veri koruma sorumlusu, ilgili iş birimi | Makul olan en kısa sürede; ilgili kişinin iletişim adresi biliniyorsa doğrudan, bilinmiyorsa uygun yöntemle | Bildirim metni, gönderim listesi ve tarihi |
| 5 | Veri ihlali kayıt defterine işleme | Veri koruma sorumlusu | Bildirimlerin tamamlanmasının ardından | İhlalin etkileri, alınan tedbirler, karar gerekçeleri |
| 6 | Düzeltici ve önleyici aksiyonların açılması | Olay sahibi | Kapanıştan önce | D.5 tablosu |
⚠️ Bildirim Kararı Teknik Ekibe Bırakılmaz
Kurul'a ve ilgili kişiye bildirim yapılıp yapılmayacağına dair karar, yalnızca veri koruma sorumlusu koordinasyonunda verilir. Olayı tespit eden ekip, değerlendirmeyi beklemeden 1. adımı işletir. Şüphe durumunda bildirim yapılır.
D.4 - Kök Neden Analizi Şablonu
P0 ve P1 olaylarında kök neden analizi zorunludur; P2'de olay sahibinin takdirindedir. Analiz kişiyi değil süreci hedefler.
Bölüm 1 - Olay Zaman Çizelgesi
| Zaman | Ne oldu | Kaynak ve kanıt |
|---|---|---|
| [tarih ve saat] | Olayın başladığı an | [oturum kaydı, ekran görüntüsü, bildirim e-postası] |
| [tarih ve saat] | Fark edilme anı | [kim, nasıl fark etti] |
| [tarih ve saat] | İlk müdahale | [yapılan işlem ve yapan] |
| [tarih ve saat] | Kontrol altına alınma | [doğrulama yöntemi] |
Bölüm 2 - Beş Neden
| Sıra | Soru | Cevap |
|---|---|---|
| 1. Neden | Olay neden oluştu? | [doldurulacak] |
| 2. Neden | Bu durum neden mümkün oldu? | [doldurulacak] |
| 3. Neden | Mevcut kontrol neden yakalamadı? | [doldurulacak] |
| 4. Neden | Kontrol neden bu şekilde tasarlanmıştı? | [doldurulacak] |
| 5. Neden | Bu tasarım kararı neden gözden kaçtı? | [doldurulacak] |
| Kök neden | Yukarıdakilerin işaret ettiği yapısal neden | [doldurulacak] |
Bölüm 3 - Katkıda Bulunan Faktörler
İşaretlenen her faktör için D.5'te en az bir aksiyon açılır.
- Politika boşluğu: kural yoktu veya belirsizdi
- Farkındalık eksiği: kural vardı, bilinmiyordu (bkz. Ek C)
- Araç uygunluğu: onaylı araç ihtiyacı karşılamıyordu, kullanıcı alternatif aradı
- Süreç tasarımı: doğru davranış zor, yanlış davranış kolaydı
- Erişim yetkisi: kullanıcının erişimi görevinin gerektirdiğinden genişti
- Zaman baskısı: teslim baskısı kontrol adımının atlanmasına yol açtı
- Çıktı doğrulama: ikinci göz kontrolü yapılmadı (bkz. 5.4.1)
- Tedarikçi veya model davranışı: sağlayıcı kaynaklı değişiklik
D.5 - Düzeltici ve Önleyici Aksiyon Takibi
Aksiyonlar, Zararlı Yazılım, Zafiyet ve Yama Yönetim Prosedürü'ndeki kapanış mantığıyla aynı şekilde yürütülür: bir aksiyon, sorumlusu tamamladığını beyan ettiği için değil, doğrulaması yapıldığı için kapanır. Doğrulamayı aksiyonun sorumlusundan başka biri yapar.
| Aksiyon No | Aksiyon | Tip | Sorumlu | Termin | Doğrulama Yöntemi | Durum ve Kapanış |
|---|---|---|---|---|---|---|
| [OLAY-NO]-01 | [yapılacak iş] | Düzeltici | [ad, rol] | [tarih] | [kayıt incelemesi, ekran görüntüsü, test koşusu, politika yayını] | [Açık / Doğrulamada / Kapalı + tarih + doğrulayan] |
| [OLAY-NO]-02 | [yapılacak iş] | Önleyici | [ad, rol] | [tarih] | [doğrulama yöntemi] | [durum] |
✅ Kapanış Kuralları
- Her P0 ve P1 olayı en az bir önleyici aksiyon üretir; yalnızca düzeltici aksiyonla kapatılamaz.
- Termini geçen aksiyonlar aylık AI Yönetişim Komitesi operasyonel gözden geçirmesinde gündeme alınır.
- Politika değişikliği gerektiren aksiyonlar, Framework Değişiklik Yönetimi bölümündeki akışa aktarılır; P0 sonrası değişiklikler acil düzeltme olarak işlenir.
- Olay dosyası, tüm aksiyonlar doğrulanmadan kapatılmaz.
D.6 - Masa Başı Tatbikat Şablonu
Yılda en az bir kez, D.1'deki tiplerden biri seçilerek masa başı tatbikat yapılır. Tatbikat gerçek sistemlere dokunmaz; amaç akışın ve rollerin sınanmasıdır. Tutanak, denetim kanıtı olarak saklanır.
| Alan | İçerik |
|---|---|
| Tatbikat tarihi ve süresi | [tarih girilecek] |
| Senaryo | [olay tipi kodu ve senaryo özeti] |
| Moderatör | [ad, rol] |
| Katılımcılar | [ad, rol, birim listesi] |
| Beklenen akış | Tespit, şiddet ataması, bildirim, müdahale, kök neden, aksiyon |
| Gözlem notları | [adım adım ne yapıldı, nerede duraksandı, hangi bilgi eksikti] |
| Ölçülen süreler | Tespitten bildirime: [ ] · Bildirimden müdahaleye: [ ] |
| Bulgular | [tespit edilen boşluklar] |
| Açılan aksiyonlar | [D.5 tablosuna aktarılan aksiyon numaraları] |
| Onay | Moderatör imza: ____________ · Bilgi güvenliği sorumlusu imza: ____________ · Tarih: ____________ |
D.7 - Olay Bildirim Kanalı ve Bildirim Kültürü
| Kanal | Ne zaman kullanılır | Not |
|---|---|---|
| Hizmet masası kaydı | Tüm olay tipleri için birincil kanal | Olay kaydı burada açılır ve izlenir |
| Doğrudan yönetici | Acil ve P0 şüphesi olan durumlar | Yönetici aynı gün hizmet masası kaydını açtırır |
| Bilgi güvenliği sorumlusu | Kişisel veri veya müşteri verisi şüphesi | Veri koruma sorumlusuna eşzamanlı iletilir |
✅ Bildirene Yaptırım Uygulanmaz
Kendi hatasını kendisi bildiren çalışana, bildirimi nedeniyle disiplin işlemi uygulanmaz. Otomatik tespit katmanı bulunmadığı için kurumun ÜZ-01, ÜZ-03 ve ÜZ-05 tiplerini görebilmesi doğrudan bildirim kültürüne bağlıdır. Kasıtlı ve tekrar eden ihlaller bu ilkenin dışındadır.