Hangi yetki, hangi sınır vehangi eskalasyon disipliniyle yürütülmektedir?

1. Yazılı yetkilendirme ve sahiplik doğrulaması

Test sahibi olarak hareket eden tarafın varlık üzerindeki tasarruf yetkisini yazılı biçimde doğrulamadan hiçbir teknik adım atmıyoruz. Kapsamdaki her bileşen için yetki imzası arıyoruz.

• Yetki belgesi; yetkili imza, kapsam tanımı, geçerlilik süresi ve iptal koşulunu birlikte taşımaktadır.
• Üçüncü taraf bileşenler için ayrı yazılı izin alınmaktadır (CDN, dış API, ödeme sağlayıcı ve benzeri).
• Bulut sağlayıcıların izin politikalarına (AWS, Azure, GCP) uyumlu bir ön bilgilendirme yapıyoruz.
• Yetkilendirmeyi iptal etmek için tek aramalık bir çekme yolu bulunmaktadır; tek noktadan askıya alınmaktadır.

2. Kapsam beyanı: Web, API ve Mobil sınırı

Kapsam beyanı yalnızca neyin dahil olduğunu değil, neyin hariç tutulduğunu da göstermektedir. Web, API ve Mobil bileşenleri ayrı kalemler halinde tanımlanmakta; örtüşme indirimi kapsam beyanı netleştikten sonra hesaplanmaktadır.

• Web bileşeni: dinamik sayfa bandı, rol sayısı, kritik akış sayısı ve çok müşterili (multi-tenant) yapı.
• API bileşeni: uç nokta bandı, REST/GraphQL/gRPC ayrımı ve kimlik doğrulama paterni.
• Mobil bileşeni: platform sayısı, ikili dosyalar (APK/IPA) ve mutabık kalınan mobil-arka uç akışları.
• Hariç alanlar: kaynak kod incelemesi, hizmet engelleme, üçüncü taraf saldırısı, fiziksel test ve sosyal mühendislik.

3. Çalışma kuralları (RoE): yöntem, sınır ve yasaklar

Çalışma kuralları, testin nasıl yürüyeceğini ve hangi davranışların kapsam dışı olduğunu yazılı olarak sabitlemektedir. PTES Pre-engagement omurgası ile OWASP WSTG ve API Security Top 10 2023 hizalaması bu kuralların teknik yatağını oluşturmaktadır.

• Hizmet engelleme (DoS), yıkıcı stres, yük testi ve gerçek finansal işlem yasaktır.
• Sosyal mühendislik ve fiziksel test bu pakette kapsam dışıdır; bunun için ayrı bir hizmet hattı bulunmaktadır.
• Otomatik tarama tek başına yeterli sayılmamaktadır; manuel doğrulama ve güvenli kavram kanıtı (PoC) esastır.
• Tüm istek/yanıt izi ve PoC kayıtları kayıt altına alınmakta; yetkisiz paylaşım yasaklanmaktadır.
• Veri sızdırma denemeleri yalnızca niyet kanıtı düzeyinde yapılmakta; gerçek veri çıkışı uygulanmamaktadır.

4. Test penceresi ve erişim modeli

Test penceresi; mesai içi veya dışı tercihi, ortam tercihi (staging ya da üretime benzer) ve erişim modeli (white-box, gray-box, black-box) ile birlikte sabitlenmektedir. Üretim ortamında çalışılacaksa ek koruma kuralları yazılı olarak kalmaktadır.

• Erişim modeli kararı: white-box (tam doküman ve kod erişimi), gray-box (kısmi) veya black-box.
• Üretim ortamı tercih edildiğinde yedek planı, geri dönüş prosedürü ve ek izleme aranmaktadır.
• Mesai dışı pencere için iki taraflı nöbet listesi ve iletişim kanalı önceden netleşmektedir.
• IP beyaz listesi, rol bazlı test hesapları ve API anahtarları kapsamla birlikte verilmektedir.

5. Onay kapıları: hassas adımlarda tek tek onay

Bazı adımları otomatik geçmiyoruz. Veri tabanı düzeyinde yazma, kritik iş akışında durum değiştirme, ödeme uçlarında hareket veya kullanıcı bazında veri okuma denemesi öncesinde yazılı onay alıyoruz.

• Yazma ve güncelleme uçlarında PoC öncesinde bir onay kaydı tutulmaktadır.
• Yetki yükseltme (privilege escalation) zinciri tamamlanmadan kritik kayıt setine erişim denemesi yapılmamaktadır.
• Çok müşterili ortamda müşteri sınırını aşan denemelerde sahibi belirli bir onay zorunludur.

6. Eskalasyon hattı: kritik bulgu anında bildirilir

Kritik şiddetli bir bulguyu rapor sonuna bırakmıyoruz. Eskalasyon hattı, irtibat kişisi, yedek irtibat, ulaşma süresi ve yazılı bildirim kanalı önceden sabitlenmekte; bildirimle birlikte güvenli bir kavram kanıtı paylaşılmaktadır.

• Birincil irtibat: teknik karar verici (CTO/Mühendislik Lideri veya Ürün Güvenliği Lideri).
• Yedek irtibat: birincil kişiye ulaşılamadığında tek aramalık alternatif kişi.
• Kritik bulguda yazılı bildirim, mutabık kalınan kanal üzerinden hızla iletilmektedir.
• Aktif istismar belirtisi görülürse test askıya alınmakta ve durum birlikte değerlendirilmektedir.

7. Yan etki kontrolü: geri dönüşsüz değişiklik yasağı

Test geri dönüşsüz bir değişiklik üretmemektedir. Veri silme, durum bozma, gerçek müşteri verisine yazma veya gerçek finansal işlem yasaktır; üretilen tüm test verisi izlenebilir biçimde işaretlenmekte ve çalışma sonunda temizlenmektedir.

• Test verisi etiketi: tüm test kayıtları belirgin bir önek ile oluşturulmaktadır.
• Üretim verisine yazan uçlarda PoC düzeyinde duruyoruz; tam istismar uygulanmamaktadır.
• Loglama ve uyarı sistemleri test penceresinde önceden bilgilendirilmekte; yanlış alarmlar yönetilmektedir.
• Test sonu temizlik: oluşturulan kullanıcılar, kayıtlar ve oturumlar listelenmekte ve kapatılmaktadır.

1. Yazılı yetki ve sahiplik: sahibi belirlenmemiş varlık test edilmez

Her test çalışmasını yazılı yetkilendirme ve varlık sahipliği doğrulamasıyla başlatıyoruz. Üçüncü taraf varlıklar, yetkilendirme zinciri tamamlanmadan kapsama girmemektedir. Kapsam dışı bir varlık keşfedilirse testi durdurup eskalasyon kanalına bildirim yapıyoruz.

• Müşteri imzalı çalışma yetkisi (SoW) ve RoE eki teslim alınmaktadır.
• Varlık sahipliği listesi (IP, alan adı, SSID, segment) doğrulanmaktadır.
• Üçüncü taraf altyapı varsa ek yetkilendirme alınmakta; aksi halde kapsam dışında kalmaktadır.

2. Kapsam beyanı: modüller ayrı kalır

Dış Ağ, İç Ağ ve Kablosuz Ağ modülleri kapsam beyanında ayrı sütunlarda tanımlanmaktadır. Her modülün kapsam bandı, varlık türü, kapsam dışı bileşenleri ve modüle özgü kısıtları RoE ekinde sabittir; kapsam genişlemesi yazılı bir değişiklik talebiyle yönetilmektedir.

• Dış Ağ: IP, alan adı, alt alan ve VPN geçidi listesi.
• İç Ağ: ana bilgisayar bandı, segment sayısı ve AD/Entra dizin yapısı.
• Wi-Fi: lokasyon, SSID, kimlik doğrulama tipi ve misafir-kurumsal ayrımı.

3. RoE yasakları: hizmetin doğal sınırları

Ağ Güvenliği Sızma Testi, belirlenmiş kapsam ve tanımlı pencere içinde yürütülmektedir. Bazı eylemler hizmetin kapsamı dışındadır ve yapılmamaktadır; bunlar çalışma kurallarında açıkça yasaklı sayılmaktadır.

• DoS, stres testi ve yük testi yapılmamakta; servis erişilebilirliği bozulmamaktadır.
• Kalıcılık bırakılmamakta; arka kapı, zamanlanmış görev veya geri dönüşsüz yapılandırma eklenmemektedir.
• Veri silme, üretim verisinde değiştirme veya geri dönüşsüz değişiklik yapılmamaktadır.
• Uzun süreli gizlilik, SOC/EDR savunması atlatma ve görünmeden ilerleme bu hizmetin kapsamı değildir; gerektiğinde Modüler Red Team Simülasyonu çerçevesi açılmaktadır.

4. Test penceresi ve erişim modeli: modüle göre farklılaşır

Test penceresini; mesai içi veya dışı seçimi, üretim donma takvimi ve müşteri operasyon ritmiyle birlikte sabitliyoruz. Erişim modeli modüle göre değişmektedir; Wi-Fi modülü çoğu senaryoda yerinde yürütülmekte, uzaktan çalışma yalnızca hazırlık ve doküman incelemesini kapsamaktadır.

• Dış Ağ: uzaktan; black-box veya sınırlı gray-box.
• İç Ağ: uzaktan, VPN, jumpbox veya yerinde; gray-box hesap modeliyle.
• Wi-Fi: yerinde kontrollü değerlendirme; saha erişimi olmadan doğrulama yapılmamaktadır.

5. Onay kapıları: yüksek etkili adımda yazılı onay

Kontrollü ayrıcalık yükseltme, alan adı yöneticisi düzeyinde doğrulama, üretim sistemine yönelik istismar adımı veya kritik servise dokunan PoC adımları yazılı bir onay kapısından geçmektedir. Onay kapısı talebi; beklenen etkiyi, geri dönüş planını ve eskalasyon kanalını içermektedir.

• Ayrıcalık yükseltme onayı: hangi varlık, hangi yöntem ve hangi geri dönüş planı?
• Yatay geçiş onayı: hedef segment, beklenen iz ve durdurma kriteri.

6. Eskalasyon hattı: 24/7 acil durdurma kanalı

Müşteri ile test ekibi arasında 24/7 erişilebilir bir eskalasyon hattı sabittir. Beklenmedik etki, üretim hizmeti kesintisi, üçüncü taraf alarmı veya yasal bir çağrı durumunda testi anında durdurup müşteri irtibat kişisine yapılandırılmış bir bildirim iletiyoruz.

• Birincil ve yedek müşteri irtibat kişisi (telefon ve e-posta).
• Test ekibinin nöbet hattı; durdurma süresi hedefi RoE ekinde sabittir.

7. Yan etki kontrolü: üretim ortamı korunur

Üretim ortamına yönelik adımları minimum etki ilkesiyle planlıyoruz. EDR/AV istisna süreci yazılı bir talimatla yönetilmekte; istisnalar test sonunda kaldırılmaktadır. Tarama yoğunluğu, eşzamanlı bağlantı sayısı ve istismar testlerinin etkisi yan etki riski açısından önceden öngörülmektedir.

• EDR/AV istisna süreci: hangi makinede, hangi pencerede ve kim onayladı?
• Tarama yoğunluğu: eşzamanlılık ve hız limitleri RoE ekinde sabittir.
• Test sonrası temizlik: oluşturulan hesap, oturum ve artefakt kaldırılmaktadır.

1. Yazılı yetki ve sağlayıcı kuralı uyumu

Yürütümü yazılı yetki olmadan başlatmıyoruz. Sağlayıcı kuralı (AWS Customer Support Policy for Penetration Testing, Microsoft Cloud Unified Pentest RoE, GCP Acceptable Use Policy) yetki belgesinin ayrılmaz bir parçasıdır.

• AWS: izin verilen hizmetlerde ön onay aranmamakta; ancak komuta ve kontrol simülasyonu, sağlayıcı altyapısına yönelik test ve hizmet kesintisi yaratan aksiyon yazılı izin gerektirmektedir.
• Microsoft Azure: 2017 yılından beri ön onay zorunluluğu bulunmamakta; müşteri, Microsoft Cloud Unified Penetration Testing Rules of Engagement metnine ve eşgüdümlü bildirim ilkelerine uymaktadır.
• Google Cloud: Google bilgilendirmesi zorunlu değildir; müşteri, Cloud Platform Acceptable Use Policy ve Hizmet Şartlarına uymaktadır; testin başka müşterileri etkilememesi şarttır.
• Yetki belgesi kapsamı, hesap listesini, test penceresini, kaynak IP değerlerini ve acil durum temas kişisini sabitlemekte; sözleşme bir askıya alma kapısı taşımaktadır.

2. Kapsam beyanı

Kapsam beyanı yalnızca müşterinin sahip olduğu veya yetkili olduğu kaynakları içermekte; sağlayıcı altyapısı ile üçüncü taraf müşteri sınırı dışarıda kalmaktadır.

• Sağlayıcı (AWS, Azure, GCP veya çoklu bulut) ile hesap, abonelik ya da proje listesi yazılı olarak sabitlenmekte; sayı, sınır ve sahiplik birebir kayıt altına alınmaktadır.
• Bölge listesi, kontrol alanı seçimi (IAM, ağ, depolama, işlem, Kubernetes, sunucusuz, günlükleme, veri platformu) ve istisnalar açıkça yazılmaktadır.
• CI/CD ve IaC incelemesi çekirdek kapsam dışındadır; ayrı bir eklenti olarak alınmadıkça beyana girmemektedir. Bu ayrım sayfada da görünür kalmaktadır.

3. RoE: yasaklar ve sınırlar

Çalışma kuralları; yıkıcı aksiyonu, kontrol düzlemine ölçeklendirmeyi ve üçüncü taraf SaaS etkisini açıkça yasaklamakta; mutabakat dışı kalıcılık ve veri ifşası yasaklanmaktadır.

• Hizmet kesintisi (DoS, DDoS, flooding, stres testi) yapılmamakta; bulgu kanıtlama ilk doğrulamayla sınırlanmakta, istismarın ötesine geçen aksiyon yapılmamaktadır.
• Kontrol düzlemine ölçeklendirme yasaktır: tek bir hesabın kontrol düzlemini sağlayıcının genel altyapısına taşıyacak istismar denemesi yapılmamaktadır.
• Üçüncü taraf SaaS, müşteri sınırı, abonelik veya projeyi etkileyecek aksiyon yapılmamakta; kapsam dışı kaynaklar her aşamada kayıt altında izlenmektedir.
• Yıkıcı yapı değişikliği yapılmamakta; veri silme, yetki kaldırma, kayıt silme, kalıcı arka kapı bırakma ve faturalandırma istismarı yasaklanmaktadır.

4. Test penceresi ve erişim modeli

Test penceresini iş yoğunluğu ve operasyonel yükü dikkate alarak yazıyoruz; erişim modeli yetkiyi gerekli olanla sınırlamaktadır.

• Varsayılan yaklaşım gri kutudur. Salt okunur IAM rolü çoğu kapsam için yeterlidir; saldırı yolu kalitesi gerektiğinde kontrollü bir test rolü kullanılmaktadır.
• Test penceresi; başlangıç ve bitiş saati, bölge, MFA, VPN, geçiş sunucusu, PIM ve JIT kısıtlarıyla birlikte sabitlenmektedir.
• Yalnız üretim ortamı, dar pencere ve geri dönüş belirsizliği fiyat ve kapsam sürücüsüdür; geri dönüş hattı önceden tanımlanmaktadır.

5. Onay kapıları

Üretim hesabında kontrollü istismar her adımda bir onay kapısıyla ilerlemekte; kontrol düzlemine yakın aksiyon ve veri okuma denemeleri açık onay altında yürümektedir.

• Yüksek etkili aksiyon (özel veri okuma, üretim rolü üstlenme, müşteriler arası geçiş denemesi) müşterinin yetkili kişisinden açık onay alınmadan yapılmamaktadır.
• Onay zinciri yazılı kayıt altındadır; onay anı, kim onayladı ve ne onaylandı kayıt edilmekte; sözleşmenin askıya alma kapısı her aşamada açık kalmaktadır.

6. Eskalasyon

Saldırı yolu çalışmasında yan etki riski gözlenirse veya sağlayıcı kotalı API limitleri tetiklenirse işi hemen durdurup eskalasyon hattını çağırıyoruz.

• Acil durdurma temas kişisi (müşteri tarafı ve Red in Pulse tarafı) yetki belgesinde sabittir; mesai dışı erişim hattı tanımlıdır.
• Sağlayıcı kotalı API çağrı limitleri (örneğin AWS service quotas, Azure throttling, GCP quota) gözlenmekte; yaklaşma sinyalinde yürütüm hızı düşürülmekte ya da durdurulmaktadır.
• Sağlayıcıya kayıt iletilmesi gerekirse eşgüdümlü bildirim ilkeleri uygulanmaktadır (Microsoft için MSRC, Google için Vulnerability Reward Program, AWS için Security abuse hattı).

7. Yan etki kontrolü

CloudTrail, Activity Log ve Cloud Audit Logs kayıt zorunluluğu test boyunca açık kalmakta; faturalandırma ve kota uyarıları izlenmektedir.

• AWS CloudTrail, Azure Activity Log ve Google Cloud Audit Logs kayıt akışı kesintisiz açık tutulmakta; izleme kaybı tespit edilirse iş durdurulmaktadır.
• Faturalandırma uyarıları açık tutulmakta; istismar denemesi olağandışı kaynak tüketimine yol açarsa müşteri tarafına anında haber verilmektedir.
• Test sonrası temizlik adımı yazılıdır: oluşturulan test kullanıcıları, roller, anahtarlar ve geçici kaynaklar kayıt altında kapatılmaktadır.

1. Yazılı yetkilendirme ve üçlü onay

Kampanya öncesinde İK, hukuk ve Bilgi Güvenliği birimlerinin yazılı onayını alıyoruz. KVKK kapsamında çalışan kişisel verisinin işlenmesi, kampanya bütünlüğüyle dengeli bir aydınlatma yaklaşımı ve veri minimizasyonu bu adımda netleşmektedir. Onay zinciri tamamlanmadan kampanya başlatılmamaktadır.

• İK onayı: çalışan etkisi ve iletişim politikası.
• Hukuk onayı: KVKK uyumu ve aydınlatma yaklaşımı.
• Bilgi Güvenliği onayı: teknik kapsam ve eskalasyon hattı.

2. Kapsam beyanı: kanal, dalga ve senaryo ailesi

Kapsam beyanı; kanal seçimini, dalga sayısını ve senaryo ailesini netleştirmektedir. E-posta ve QR çekirdek kanallardır; SMS ile kimlik avı ve sesli kimlik avı, pilot ya da eklenti olarak ayrı bir onayla devreye alınmaktadır. Her kanalın hedef kitlesi, dili ve içerik onay akışı yazılı kapsam içinde kalmaktadır.

• Çekirdek kanal: e-posta ve QR.
• Pilot kanal: SMS ile kimlik avı, ayrı bir onay zinciri.
• Pilot kanal: sesli kimlik avı, ayrı bir onay zinciri.

3. Yürütüm kuralları ve adil kültür

Kampanya zararsız ve kontrollüdür. Gerçek finansal işlem, gerçek kimlik bilgisi kötüye kullanımı, kalıcılık, fiziksel sızma ve üçüncü taraf etkileşimi kapsam dışındadır. Taciz dili, utandırma çerçevesi ve çalışanı cezalandırma yasaktır. Çerçevemiz "kim kandı?" sorusuna değil, "süreç hangi noktada aksamaktadır?" sorusuna odaklanmaktadır.

• Gerçek finansal işlem yasaktır.
• Gerçek kimlik bilgisi kötüye kullanımı yasaktır.
• Taciz dili ve kişiyi cezalandırma yasaktır.
• Çerçeve süreç odaklıdır; suçlayıcı değildir.

4. Test penceresi ve dönem kısıtları

Test penceresini mesai içi veya dışı olarak yazılı belirliyoruz; yoğun dönemler kampanyaya kapalıdır. Dini bayramlar, resmi tatiller, finansal yıl sonu, kriz iletişimi dönemi, işten çıkarma süreci ve birleşme/devralma dönemleri otomatik olarak kapsam dışıdır; bu dönemlerde ayrı bir risk değerlendirmesi yapıyoruz.

• Dini bayram ve resmi tatil çakışması yasaktır.
• İşten çıkarma ve birleşme dönemi otomatik olarak kapalıdır.
• Kriz iletişimi dönemi: ayrı bir risk değerlendirmesi.

5. Onay kapıları ve yönetici kampanyaları

Üst yönetim, finans liderleri ve ayrıcalıklı kullanıcılara yönelik kampanyalar ek bir onay kapısından geçmektedir. Bu kitleler tek dalgada karma olarak hedeflenmemekte; kapsam, içerik ve dağıtım sırası ayrı bir onay zinciriyle netleşmektedir. Onay kapıları, kampanyanın her kritik adımında yazılı olarak korunmaktadır.

• Üst yönetim kampanyaları: ek bir onay kapısı.
• Finans, üst yönetim ve ayrıcalıklı kullanıcının tek dalgada karma hedeflenmesi yasaktır.

6. Eskalasyon ve acil durdurma

Kampanya sırasında gerçek bir güvenlik olayı tetiklenirse, bir çalışan psikolojik zarar belirtisi gösterirse veya operasyon bozulma riski belirirse kampanyayı derhal durduruyoruz. Eskalasyon hattı yazılı olarak tanımlıdır; iletişim kişisi, durdurma yetkisi ve yeniden başlatma koşulları RoE dosyasında sabittir.

• Gerçek bir olay tetiklenirse: anında durdurma.
• Çalışanda psikolojik zarar sinyali: anında durdurma.
• Operasyon bozulma riski: anında durdurma.

7. Yan etki kontrolü ve KVKK uyumu

Çalışan psikolojisi kampanya tasarımının ayrılmaz bir girdisidir. KVKK Md. 4 minimum işlemcilik ilkesi gereği yalnızca ölçüm için gereken kişisel veriyi işliyoruz; kampanya sonrasında anonimleştirilmiş raporlama uyguluyoruz. Kişi adı ve kimliği rapor dışında kalmakta; segment, persona ve dalga bazında dağılım korunmaktadır.

• KVKK Md. 4: minimum işlemcilik ilkesi.
• Anonimleştirilmiş raporlama; raporda kişi adı yer almamaktadır.
• Kampanya sonrası eğitim erişimi tüm hedeflere açıktır.

1. Yazılı yetki ve program SoW'u

Program, müşterinin yazılı yetkisi ve minimum üç ay süren bir Program SoW'u (Statement of Work) ile başlamaktadır. SoW; süreyi, hedef varlık setini, ritim sayısını, doğrulama haklarını ve kapsam dışı kalemleri kayda geçirmektedir. Yetki belgesi olmadan ritim açılmamaktadır.

• Müşteri yetkilisinin imzaladığı yazılı yetki ve sözleşme onayı zorunludur.
• Program SoW süresi minimum 3 aydır; daha kısa süre talepleri Uygulama Güvenliği Sızma Testi sayfasına yönlendirilmektedir.
• SoW kapsamı; hedef varlıkları, aylık ritim hakkını, derin inceleme hakkını ve ritim dışı sürüm doğrulama hakkını ayrıştırmaktadır.

2. Kapsam beyanı

Kapsam beyanı; ritim boyunca hangi hedef varlıkların test edileceğini, hangi rollerin ve kritik akışların kapsamda olduğunu ve hangi yüzeylerin kapsam dışı kaldığını sabit bir dille kayda geçirmektedir. Kapsam, ay başında değil, sözleşme aşamasında karara bağlanmaktadır.

• Hedef varlık tipleri: web uygulaması ve API yüzeyi (mobil, iç ağ ve bulut duruşu standart kapsam dışıdır).
• Aylık ritim hakkı sayısı (Temel: 1, Derin İnceleme: 2, İleri: 3) ve derin inceleme hakkı paket seviyesine bağlı olarak kayıtlanmaktadır.
• Kapsam dışı: 24/7 izleme, olay müdahalesi, BAS, Purple Team, Red Team, sosyal mühendislik, DDoS ve yıkıcı test.

3. Ritim başına RoE penceresi

Her aylık ritim için ayrı bir RoE penceresi açıyoruz; bu pencere kümülatif bir yetki gibi davranmamaktadır. Önceki ritimde yetkilenen aksiyonlar bir sonraki ritime otomatik taşınmamaktadır. Sürpriz hedef genişletme ve sürüm dışı varlık testi yasaktır.

• Kümülatif yetki yasağı: her ritim kendi RoE penceresiyle açılmakta, kapanmakta ve kayıtlanmaktadır.
• Sürpriz hedef genişletme yasağı: SoW dışı bir varlık veya rol o ritime tek taraflı olarak eklenmemektedir.
• Sürüm dışı varlık yasağı: yalnızca SoW'da tanımlı hedef varlıklar üzerinde test yürütülmektedir.
• Riskli aksiyon (yetki yükseltme, veri yazma, oturum müdahalesi) yazılı bir ek onay almaktadır.

4. Test penceresi ve erişim modeli

Test penceresi aylık takvim üzerine yerleşmekte; sürüm freeze günleri ve kritik iş günleri pencereye dahil edilmemektedir. Test hesapları, OpenAPI veya Postman koleksiyonları ve sürüm bildirim entegrasyonu ay başında hazır olmaktadır. Sürüm önceliği çakışırsa pencereyi kaydırıyoruz.

• Aylık takvim, ay başında müşteri ile test ekibi arasında onaylanmaktadır.
• Sürüm freeze veya kritik iş günleri pencere dışında bırakılmakta; öncelik çakışırsa pencere kaydırılmaktadır.
• Test hesabı, OpenAPI/Postman koleksiyonu ve sürüm bildirim akışı her ritimde doğrulanmaktadır.

5. Onay kapıları

Kritik bulgu tespiti, kapatma penceresi açılışı ve kapatma sonrası yeniden test, her biri ayrı bir onay kapısıdır. Müşterinin yetkilisi her kapıda yazılı onay vermekte; kapı atlanmadan bir sonraki adıma geçilmemektedir.

• Kapı 1: Kritik bulgu bildirimi: 24 saat içinde müşteri yetkilisine yazılı bildirim ve bir doğrulama görüşmesi.
• Kapı 2: Kapatma penceresi: müşteri ekibi kapatma planını sunmakta; kapatma sonrası yeniden test tarihi belirlenmektedir.
• Kapı 3: Yeniden doğrulama onayı: kontrollü yeniden test yetkisi ayrı yazılmakta; bulgunun kapatıldığının kanıtı kayıtlanmaktadır.

6. Eskalasyon ve raporlama

Her ritim sonunda bir yönetici özeti ve teknik bulgu listesi teslim ediyoruz. Kritik bulgu tespit edildiğinde 24 saat içinde bildirim akışı işlemekte; üretim etkisi riski oluşursa çalışma durdurulmakta ve eskalasyon hattı devreye girmektedir.

• Ritim sonu raporu: yönetici özeti, teknik bulgu listesi, kapatma oranı ve sonraki ayın öncelikli alanı.
• Kritik bulgu için 24 saat bildirim; yüksek bulgu için 72 saat bildirim hattı.
• Üretim etkisi riski oluşursa çalışma durdurulmakta; teknik temas kişisi ve acil irtibat çağrılmaktadır.

7. Yan etki kontrolü ve program yorgunluğu koruması

Aylık ritmi üretim temposunu zorlamayacak biçimde planlıyoruz; alarm kakofonisi (gereksiz uyarı yığını), düşük öncelikli bulgu yağmuru ve ürün ekibinin bunalması önlenmektedir. Yalnızca iş etkisine göre önceliklenmiş ve doğrulanmış bulguları bildiriyoruz.

• Alarm kakofonisi yasağı: tek tek bilgi düzeyi bildirim yerine ay sonunda konsolide bir rapor.
• Üretim tempo uyumu: freeze günleri test dışıdır; kritik iş saatlerinde riskli aksiyon yapılmamaktadır.
• Düşük öncelikli bulgu yığını yerine iş etkisine göre filtrelenmiş ve doğrulanmış bir bulgu listesi.

1. Yazılı yetki ve üst yönetim onayı: yetkilendirme zinciri

Çalışma; üst yönetimin (CISO veya CTO ekseninde, kritik senaryolarda CEO bilgisiyle) imzaladığı bir yetki belgesiyle başlamaktadır. Belge; kapsamı, başlangıç dayanağını, etik sınırları, kayıt tutma ilkesini ve sözleşmenin gizlilik düzlemini sabitlemektedir. Dar bir paydaş kümesi (white team) belirlenmekte; blue team ve geniş ekip bilgilendirilmemektedir.

• Üst yönetim imzalı yetki belgesi: CISO veya CTO ekseni; kritik senaryolarda CEO bilgisi.
• White team listesi: 2-4 kişi; CISO, güvenlik direktörü, üst yönetim irtibatı ve hukuk.
• Blue team kapsam dışıdır; gerçek tespit kabiliyetinin ölçülebilmesi için icra blue team'e karşı gizli tutulmaktadır.

2. Kapsam beyanı: modül seçimi ve kapsam çizgisi

Kapsam beyanı çekirdek modülü ve genişletmeleri ayrı sabitlemektedir: RT-1 tehdit aktörü davranışı, RT-2 hedef odaklı kritik varlık zinciri, RT-3 varsayılan ihlal lateral hareket, RT-4A insan katmanlı ilk erişim. Kritik varlık (crown jewel) ve başlangıç varsayımı yazılı olarak tanımlanmakta; kapsam dışı varlıklar (üçüncü taraf, regülatör, partner) ayrı listelenmektedir.

• Çekirdek modül: RT-1 Tehdit Aktörü Simülasyonu, RT-2 Hedef Odaklı Red Team veya RT-3 Varsayılan İhlal.
• Genişletme: RT-4A insan katmanlı ilk erişim, RT-4B fiziksel giriş, RT-5 purple/BAS doğrulama.
• Kritik varlık ve başlangıç varsayımı yazılıdır; kapsam dışı varlıklar ayrı listelenmektedir.

3. Çalışma kuralları (RoE): etik sınır pencereleri

Çalışma kuralları, işin hangi aksiyonun altında olmadığını sabitlemektedir. Yıkıcı aksiyon, kalıcı zararlı yazılım yerleştirme, fidye yazılımı yayımı, gerçek üretim verisinin dışarı aktarılması ve yetkisiz üçüncü taraf etkileşimi varsayılan olarak kapsam dışındadır. Veri erişimi gerektiren senaryolarda temsili veri etiketi kullanılmakta; gerçek müşteri kaydı kanıt paketinde yer almamaktadır.

• Yıkıcı aksiyon yasağı: DoS, kapasite testi veya sistem bütünlüğünü zedeleyen icra yapılmamaktadır.
• Fidye yazılımı yayımı ve gerçek zararlı yazılım yasağı; yalnızca kontrollü emülasyon araçları kullanılmaktadır.
• Gerçek veri dışarı aktarma yasağı: kanıt paketi temsili veri etiketiyle taşınmakta; gerçek müşteri verisi dışarı çıkmamaktadır.
• Üçüncü taraf tedarikçi varlık yasağı: yetkisiz partner, regülatör veya servis sağlayıcı sistemi kapsam dışındadır.
• Etik sınır pencereleri: kritik üretim saatleri, mevsimlik yoğunluk dönemleri ve denetim takvimleri yazılmaktadır.

4. Test penceresi: süre, ritim ve white team koordinasyonu

Modüler Red Team Simülasyonu, Ağ Güvenliği Sızma Testi hizmetinin tanımlı penceresinden farklı olarak haftalar ile aylar arasında değişen bir icra süresi taşımaktadır. Senaryo karmaşıklığına bağlı olarak 2-6 hafta tipik aralıktır; regüle çerçeveye (TIBER-EU/CBEST) bağlı çalışmalarda süre uzamaktadır. White team günlük veya haftalık koordinasyon kanalı üzerinden eşgüdüm sağlamakta; her kritik adım kayıt altına alınmaktadır.

• Tipik süre 2-6 haftadır; regüle çerçeve kapsamında daha uzundur.
• White team için günlük veya haftalık bir koordinasyon kanalı; faaliyet özeti raporlanmaktadır.
• Erişim modeli: yönlendirilmiş, gri kutu veya kara kutu; yazılı varsayım sabittir.

5. Onay kapıları: kritik adımda güvenilir temsilci onayı

Saldırı yolundaki kritik adımlar (üretim sistemine etki, ayrıcalık yükseltme, kalıcılık emülasyonu, kontrollü hedef etkisi) icra öncesinde güvenilir temsilci (trusted agent) onayından geçmektedir. Onay kayıt altına alınmakta ve geri çekilebilmektedir. Bu disiplin, hem üst yönetimin yan etki sürprizinden korunmasını hem de kanıt paketinin denetlenebilir kalmasını sağlamaktadır.

6. Eskalasyon hattı: gerçek olay yanıtıyla karışmayı önleme

SOC veya MSSP, simülasyon faaliyetini gerçek bir saldırı sanıp olay yanıt sürecini tetiklerse güvenilir temsilci kanalı devreye girmekte ve faaliyetin kontrollü olduğunu doğrulayan deconfliction sinyalini vermektedir. Aynı hat, gerçek bir saldırı eşzamanlı olarak geldiğinde simülasyonun derhal askıya alınmasını ve kaynakların gerçek olay yanıtına bırakılmasını da sağlamaktadır.

7. Yan etki kontrolü: deconfliction, kayıt ve temizleme

Yan etki kontrolü üç hat üzerinden yürümektedir: deconfliction (gerçek tehdit aktörüyle karıştırılmaması için zaman ve teknik kaydı), faaliyet kayıt tutma (her teknik adımın zaman damgası, hedef ve sonuçla kayda alınması) ve iz temizleme (icra sırasında oluşturulan hesap, dosya, ajan ve kalıcılık izi sözleşme bitiminde temizlenmekte; temizlik de kayıt altındadır).

• Deconfliction: faaliyet zamanı ve teknik kaydı; gerçek aktörle karışma riski yönetilmektedir.
• Faaliyet kayıt tutma: her adım zaman damgası, hedef ve sonuçla kayda alınmaktadır.
• İz temizleme: oluşturulan hesap, dosya, ajan ve kalıcılık izi sözleşme sonunda temizlenmektedir.

1. Yazılı yetkilendirme

Çalışma; yalnızca yazılı yetki, ajan ve hesap sahipliğinin doğrulanması ve entegre üçüncü taraf model sağlayıcılarının kullanım koşullarının ön kontrolüyle başlamaktadır. Sağlayıcı altyapısının kendisi kapsam dışındadır; kapsam müşterinin ajan iş akışıdır.

• İmzalı çalışma yetki belgesi (SoW) ve müşteri tarafındaki yasal sahibin onayı.
• Ajan iş akışı, hesap, RAG ve MCP sahipliğinin yazılı olarak doğrulanması.
• Üçüncü taraf model sağlayıcı kullanım koşulları (AUP) kontrolü ve uyumlu bir test profilinin önceden belirlenmesi.
• Sağlayıcı altyapısı kapsam dışıdır; ona karşı kara kutu saldırı testi yapılmamaktadır.

2. Kapsam beyanı

Kapsam, ajan iş akışı birim ölçüsünde tanımlanmaktadır. Araç kütüphanesi, RAG kaynakları, MCP sunucuları, sistem istemleri ve rol/onay sınırı kapsam içinde listelenmekte; kapsam dışı kalan bileşenler ayrıca yazılmaktadır.

• Kapsam içi: ajan iş akışı, araçlar/bağlayıcılar, RAG indeksleri, MCP sunucuları, sistem istemi ve güvenli yürütüm sınırı.
• Kapsam içi: kimlik doğrulama, yetkilendirme, onay ve token yönetimi katmanları.
• Kapsam dışı: model sağlayıcı altyapısı, model dosyası kaynak kökeni, sosyal mühendislik, fiziksel test ve üçüncü taraf sistemler.
• Kapsam dışı: DoS, yük ve stres testi; üretim üzerinde kontrolsüz veri dışarı aktarma.

3. Çalışma kuralları (RoE)

Çalışma kuralları; izinli ve yasak aksiyonları, hassasiyet sınırlarını ve durdurma kriterlerini yazılı olarak sabitlemektedir. Test, koşu zamanı (runtime) zincirini kanıtlamaya yetecek derinliğe inmekte; üretim kullanıcısının verisine ve gerçek aksiyonuna dokunmamaktadır.

• İzinli: dolaylı istem enjeksiyonu, jailbreak, hassas bilgi ifşası testi, araç kötüye kullanımı ve MCP yetkilendirme istismarı denemeleri.
• Yasak: üretim kullanıcı verisine ulaşma; bunun yerine sentetik veya maskelenmiş veri kullanılmaktadır.
• Yasak: gerçek finansal işlem, ödeme ya da e-posta/mesaj gönderimi tetikleyen aksiyonlar; karşılığında sandbox eşdeğeri kullanılmaktadır.
• Yasak: model davranışını kalıcı değiştirme, fine-tuning veya bellek manipülasyonunun üretim ortamında yapılması.
• Durdurma kriteri: müşteri verisi sızıntısı şüphesi, üretim kullanıcısı etkisi veya sağlayıcı AUP ihlali sinyali.

4. Test penceresi ve erişim modeli

Testi öncelikle bir sandbox veya canary tenant üzerinde yürütüyoruz. Üretim kapsamı yalnızca salt okunur ya da sıkı sınırlandırılmış senaryolarla, yazılı mutabakat altında ve dar bir pencerede ele alınmaktadır.

• Sandbox: ajanın üretim eşdeğeri yapısı; sentetik kullanıcı verisi, sahte bağlayıcılar ve izole MCP sunucuları.
• Canary tenant: üretim mimarisi ve izole hesap sınırı; gerçek müşteri verisinden ayrı, kontrollü bir PoC alanı.
• Üretim salt okunur: yalnızca okuma yetkili araçlar; yazma araçları bir onay kapısı arkasındadır.
• Test penceresi, sürüm dönemleri ve model sağlayıcı güncelleme takvimiyle çakıştırılmamaktadır.

5. Onay kapıları

Yüksek etkili senaryolar onay kapıları arkasında ilerlemektedir. Kapsam ve RoE onayı başlangıçta; yüksek etkili aksiyon, üretim dokunuşu ve rapor kabulü ayrı kapılarda kayıt altına alınmaktadır.

• Kapsam ve RoE onayı (kickoff): ajan iş akışı sahibi, güvenlik sponsoru ve yasal sahibin imzası.
• Yüksek riskli istem aileleri ve yazma yetkili araç çağrıları öncesinde yazılı onay.
• Üretim dokunuşu öncesinde onay: hangi araç, hangi kapsam ve hangi pencere.
• Raporlama fazında bulgu kabul oturumu ve yeniden test kapsam onayı.

6. Eskalasyon

Koşu zamanı testi, model sağlayıcı kullanım koşullarını tetikleme riski taşımaktadır. Eskalasyon hattı; kullanıcı verisi şüphesi veya üretim etkisi durumunda anlık koordinasyon için her iki tarafta belirlidir.

• Müşteri tarafı eskalasyon: ajan sahibi, güvenlik sponsoru ve yasal müşavir teması (24 saat).
• Hizmet sağlayıcı tarafı eskalasyon: test ekip lideri, proje yöneticisi ve güvenlik sorumlusu.
• Model sağlayıcı AUP ihlali sinyali: test durdurulmakta, kayıt alınmakta ve sağlayıcıyla koordinasyon yürütülmektedir.

7. Yan etki kontrolü

Çalışma sona erdiğinde test verisi, ajan log geçmişi ve sağlayıcı tarafındaki konuşma kayıtları yazılı bir temizlik prosedürüyle ele alınmaktadır. Müşteri verisinin testten kalan bir iz bırakmamasını bir güven unsuru olarak çerçeveliyoruz.

• Test sırasında oluşan ajan log geçmişi anonimleştirilmekte veya silinmektedir.
• Sağlayıcı tarafındaki konuşma kayıtları için saklama politikası önceden belirlenmektedir.
• Test verisi (sentetik veya maskelenmiş) çalışma sonunda imha edilmektedir.
• Bulgu raporunun saklama süresi ve erişim izni yazılıdır; çift dil opsiyonu varsa belirtilmektedir.

1. Yazılı yetkilendirme

Model sahibinin yazılı yetkilendirmesi olmadan değerlendirmeye başlamıyoruz. Yetki belgesinde; model envanteri, kayıt deposu erişim seviyesi, eğitim veri envanteri okuma sınırları ve sorumlu paydaşlar adlarıyla listelenmektedir.

Üçüncü taraf bir base model kullanılıyorsa sağlayıcı kullanım koşulları (Hugging Face model lisansı, kapalı sağlayıcı API kullanım koşulları, fine-tuning lisans şartları) yetki belgesine ek olarak değerlendirilmektedir. Lisans yorumu hukuki bir görüş değildir; bayrak işaretleyici düzeyinde kalmaktadır.

2. Kapsam beyanı

Değerlendirme kapsamı; model versiyon listesi, eğitim/fine-tune iş hattı, kayıt deposu (registry) ve yayına alma hedefleri (staging, production, çok müşterili, çok bölgeli) düzeyinde tanımlanmaktadır. Kapsam dışı kalan alanlar açıkça yazılmaktadır.

Kapsam dışı: koşu zamanı istem, araç, RAG ve MCP saldırı zinciri Üretken Yapay Zeka Red Team değerlendirmesine aittir; iç ofansif iş akışı ise Sızma Testi ve Red Team için Yapay Zeka kapsamındadır. Hukuki lisans görüşü ile doğruluk ve tarafsızlık (fairness) validasyonu hizmet kapsamı dışındadır.

3. Kontrollü icra kuralları

Kayıt deposu, iş hattı ve yayına alma manifestlerine erişim varsayılan olarak salt okumadır. Yetkisiz promote, rollback veya yapılandırma değişikliği yapmıyoruz; yazma erişimi yalnızca ayrı bir yazılı onayla ve kayıtlı bir pencere içinde uygulanmaktadır.

Eğitim veri kümesine erişim örnekleme yoluyla ve veri minimizasyonu ilkesi altında alınmaktadır. Hassas veri (özel nitelikli kişisel veri, ticari sır, müşteri verisi) maskelenmekte veya hash'lenmektedir; orijinal veri dışarı çıkarılmamaktadır.

Gerçek model artefaktı üzerinde yıkıcı test yapmıyoruz; canlı modelin ağırlıkları değiştirilmemektedir. Üretim yayına alma hattının kesintiye uğratılması yasaktır; bir bulgu üretim sırasında doğrulanacaksa yazılı onay ve kontrollü bir pencere altında sürdürülmektedir.

4. Test penceresi ve erişim modeli

Erişim modelini kanıt moduna göre kademeli kuruyoruz. CI/CD iş hattı okuması, model kayıt deposu okuması, eğitim veri envanteri örnek erişimi ve attestation log okuması birincil halkalardır. Air-gapped veya regüle ortamlarda yerinde bir çalışma penceresi açılmaktadır.

Çalışma penceresini, MLOps takviminin yeniden eğitim, fine-tune ve sürüm dalgalarıyla çakışmayacak biçimde planlıyoruz. Acil durum çıkışı her tarafın temas noktasında yazılı kalmakta; iletişim hattı 24 saat içinde yanıt eşiğine bağlıdır.

5. Onay kapıları

Eğitim verisi hassas kategori içeriyorsa gizlilik anlaşması (NDA) güçlendirilmekte ve veri sahibi (governance veya hukuk) ek bir onay kapısına bağlanmaktadır. Özel nitelikli kişisel veri varsa KVKK Md. 6 kapsamında ayrı bir onay alınmaktadır.

Üçüncü taraf bir base model üzerinde fine-tune yapılmışsa sağlayıcı kullanım koşulları onay zincirine eklenmektedir. Çoklu paydaş (ML platform, güvenlik, governance ve hukuk) ortak bir onay kapısında imzalamakta; eksik bir imza çalışmayı durdurmaktadır.

6. Eskalasyon hattı

Kayıt deposunda imza eksikliği, kanıt zinciri kopması veya yetkisiz promote izi tespit edilirse birincil teknik temas ile güvenlik sponsorunu derhal bilgilendiriyoruz. Ön rapor 24 saat içinde paylaşılmakta; kapatma planı sıkılaştırma iş listesine bağlanmaktadır.

Hassas veri sızma şüphesi, üçüncü taraf lisans ihlali işareti veya regülasyonel etki olası bir bulguyu doğrudan yönetim seviyesindeki paydaşlara taşıyoruz. Bilgi paylaşım yolu, bildirim hattı ve yazılı kayıt baştan netleştirilmektedir.

7. Yan etki kontrolü

Eğitim verisindeki kişisel veri, IP koruması kapsamındaki içerik ve regülasyonlu veri baştan tanımlanmaktadır. KVKK Md. 6 hassas veri ve özel nitelikli kişisel veri için ayrıca bir koruma kuralı uygulanmakta; veri minimizasyonu varsayılan ilkedir.

Müşteri verisi dışarı çıkarılmamakta; örnekler maskelenmekte ve sözleşme süresi sonunda silinmektedir. Varsayılan saklama süresi 30 gündür veya sözleşme ile farklı belirlenmektedir. Audit loglar değerlendirme süresince ayrı bir kanalda tutulmaktadır.

1. Yazılı yetki ve pilot sahipliği: sahibi belirsiz senaryo pilota alınmaz

Her iç pilot çalışmasını yazılı yetkilendirme ve iç ofansif liderin taahhüdüyle başlatıyoruz. Sahibi belirlenmemiş veya kabul kriterleri yazılı olmayan kullanım senaryoları pilot kapsamına alınmamaktadır. Pilotun sahibi iç ofansif liderdir; nihai bulgu kararı uzman analistin üzerindedir.

• İç ofansif liderin imzaladığı pilot çalışma yetkisi ve RoE eki teslim alınmaktadır.
• Kullanım senaryosu listesi, sahibi ve kabul kriterleri yazılı olarak sabittir.
• Üçüncü taraf yapay zeka tedarikçisinin AUP ve veri işleme şartları kontrol edilmektedir.

2. Kapsam beyanı: her senaryonun ayrı sahibi ve ayrı eval seti

Pilot kapsamı, ofansif iş akışı kullanım senaryolarının yazılı bir listesi olarak tanımlanmaktadır: keşif, hipotez, kanıt işleme, raporlama ve yeniden test. Her senaryo ayrı bir sahibi, ayrı kabul kriterleri ve ayrı bir eval seti taşımakta; "soyut yapay zeka kullanımı" bir kapsam değildir. Kapsam genişlemesi yazılı bir değişiklik talebiyle yönetilmektedir.

• Keşif / hedef ön değerlendirme iş akışı: sahibi ve kabul kriterleriyle.
• Test hipotezi iş akışı: bulgu kalıbı kütüphanesinin sahipliği.
• Kanıttan bulguya ve yeniden test iş akışı: rapor şablonunun sahipliği.
• Çok adımlı orkestrasyon: ileri bir pilot için ayrı bir RoE eki gerekmektedir.

3. RoE yasakları: hizmetin doğal sınırları

İç pilot, belirlenmiş kapsam ve insan denetimli bir iş akışı içinde yürütülmektedir. Bazı eylemler hizmetin kapsamı dışındadır ve yapılmamaktadır; bunlar çalışma kurallarında açıkça yasaklı sayılmaktadır. Otonom üretim aksiyonu ve uzmanı devre dışı bırakan çalışma vaadi reddedilmektedir.

• Tam otonom saldırı ajanı kurulmamakta; her aksiyonda insan onayı bulunmaktadır.
• Üretim güvenlik testinde otomasyon her aşamada yalnızca yazılı onayla açılmaktadır.
• Eval seti kapsamı dışındaki iş akışı üretime taşınmamakta; her senaryo bir kabul kapısı geçmektedir.
• Üçüncü taraf modelin AUP'una aykırı kullanım yapılmamakta; lisans ve veri işleme şartları korunmaktadır.
• Müşterinin yapay zeka ürününü saldırı testi bu kapsamın dışındadır; gerektiğinde Üretken Yapay Zeka Red Team açılmaktadır.

4. Test penceresi ve erişim modeli: sandbox, canary ve sınırlı pilot

İç pilot bir sandbox veya izole edilmiş geliştirme ortamında başlamakta; canary çalışmayla sınırlı bir gerçek senaryoya geçmekte; nihai pilot kapsamı yazılı bir kabul kapısıyla genişlemektedir. Üretim ortamına geçiş otomatik değildir; her ölçek artışı yeni bir onay kapısına bağlıdır.

• Sandbox: izole geliştirme ortamı; gerçek müşteri verisine temas yoktur.
• Canary: anonimleştirilmiş örnek artefaktlar ve dar bir senaryo.
• Sınırlı pilot: yazılı kabul ile genişletilmiş kullanım senaryosu seti.

5. Onay kapıları: her aşamada insan onayı

Kullanım senaryosu seçimi, RoE, artefakt ve erişim, eylem seviyesi, PoC kabul ve pilot kabul kapıları yazılı bir insan onayıyla açılmaktadır. Otomatik aksiyon sınırları en az ayrıcalık eylem matrisinde sabittir; matris dışı bir aksiyon onay olmadan yürütülmemektedir. Nihai bulgu kararı uzman analistin üzerindedir.

• Kullanım senaryosu onayı: kapsam, sahibi ve kabul kriterleri yazılı olarak.
• Eylem seviyesi onayı: salt okunur, taslak üretimi ve yürütüm ayrımı net tutulmaktadır.
• PoC ve pilot kabul kapıları: eval seti sonuçları kapı kararının girdisidir.

6. Eskalasyon hattı: eval seti düşüşü tetikleyicidir

İç ofansif lider ile pilot ekibi arasında yapılandırılmış bir eskalasyon hattı sabittir. Eval setinin kabul eşiğinin altına düşmesi, beklenmedik bir aksiyon, üçüncü taraf model uyarısı veya bir yan etki sinyali; pilotun anında durdurulması ve yapılandırılmış bir bildirim için tetikleyicidir.

• Birincil ve yedek iç ofansif irtibat kişisi (telefon ve e-posta).
• Eval seti düşüş eşiği yazılıdır; aşıldığında pilot durmakta ve revize edilmektedir.

7. Yan etki kontrolü: müşteri verisi modele beslenmez

Pilot içinde gerçek müşteri verisini yapay zeka modeline eğitim girdisi olarak beslemiyoruz. Anonimleştirme ve veri minimizasyonu baştan uygulanmakta; log temizleme süreci yazılıdır. Yapay zeka çıktısı uzmanın kararının yerine geçmemekte; her kritik karar uzman analist tarafından doğrulanmaktadır.

Her hizmetin ürettiği birincil kanıt nesnesinin tanımı ve karar etkisi.

Test başlamadan önce hazırlamanız gereken ön koşullar, erişim ve paydaşlar.

Hangi durumda hangi hizmetin doğru başlangıç olduğunu açar.

Hedef yüzeyi, yetki düzenini ve test penceresini bir keşif görüşmesinde birlikte belirleyelim; bağlayıcı kapsam onaylı çalışma alanı belgesiyle kesinleşir.

• Eğitim verisi politikası: müşteri kanıtı modele beslenmemekte; opt-out doğrulanmaktadır.
• Anonimleştirme: kişisel veri ve müşteri kimliği baştan kaldırılmaktadır.
• Log temizleme: pilot sonrası artefaktlar ve oturumlar yazılı bir süreçle kaldırılmaktadır.
• Uzman kararının yerine geçme yasaktır; yapay zeka çıktısı bir taslaktır, karar değildir.