İç risk sınıfı, inceleme önceliğini ve derinliğini belirlemek için kullanılır. Hukuki sınıflandırmanın yerine geçmez; farklı bağlamlar aynı teknik modele farklı öncelikler verebilir.
envanter savaşı: görünmeyen sistem yönetilemez
Her model risk çerçevesinin ilk cümlesi aynıdır: "kapsamdaki tüm modeller envantere kaydedilir." Sorun şu ki "kapsam" kelimesinin sınırını birileri çizmek zorundadır ve AI çağında bu çizgi kaydı: SQL raporu model mi? Excel'deki skorlama makrosu? Pazarlamanın kullandığı ChatGPT? Satın alınan CRM'in içine gömülü churn modeli? İK'nın CV eleme aracı? Copilot?
Envanter kapsamı teknik özellikler, iş etkisi ve yönetişim ihtiyacıyla belirlenir. Dar kayıt tanımı önemli sistemleri görünmez bırakabilir; her kayda aynı inceleme yükünü vermek ise kaynakları yanlış dağıtabilir. Kayıt ile inceleme derinliği ayrı tasarlanmalıdır.
Geniş kayıt, orantılı inceleme: Sistemler görünür kılınır; inceleme derinliği kullanım riskiyle ilişkilendirilir. Düşük riskli bir kayıt için daha yalın dokümantasyon mümkün olabilir, ancak sahiplik ve değişiklik takibi korunur.
EU AI Act bu tartışmayı kısmen dışsallaştırdı: "AI sistemi" tanımı artık hukuki bir tanım ve high-risk sınıfındaki kullanımlar için kayıt/dokümantasyon zorunlu. Ama dikkat: AI Act'in kapsamı ile ilgili iç envanter kapsamın aynı şey değil — AI Act minimum settir; iç çerçeven, AI Act kapsamına girmeyen ama bankaya zarar verebilecek sistemleri de (iç verimlilik araçları, analitik modeller) kapsamalıdır.
kayıt kriterleri: ne girer, ne girmez?
Pratik bir kayıt testi üç soruya dayanır: (1) Sistem, girdilerden çıktı üreten bir nicel/algoritmik bileşen içeriyor mu? (2) Çıktı, bir kararı veya finansal/müşteri sonucunu etkiliyor mu? (3) Hata, anlamlı zarar üretebilir mi? Üçüne de "evet" ise kayıt tartışmasızdır; ilk ikisi "evet" ise kayıt varsayılandır (tier düşük olabilir).
Bireysel verimlilik kullanımı — politika ve DLP kontrolüyle sınırlandırılmış olmak şartıyla
Sandbox/PoC aşamasındaki denemeler — üretime giden yolu envanter gate'inden geçmek şartıyla
Sağ sütunun her satırında bir "şart" var — bu tesadüf değil. "Girmez" listesi ancak çevresi kontrollerle çizilmişse savunulabilir: bireysel ChatGPT kullanımı envantere girmez ama kullanım politikası + veri sızıntısı kontrolü ister; PoC girmez ama üretim kapısı envanterden geçer. Denetçinin sorusu "neden kayıtlı değil?" olduğunda cevabın bir yazılı istisna kuralı olmalı, "kimse düşünmedi" değil.
tier hesaplayıcı: beş boyut, tek karar
Tiering'in amacı basit: sınırlı validasyon kapasitesini riskin olduğu yere yığmak. Aşağıdaki hesaplayıcı beş boyut üzerinden basitleştirilmiş bir tier önerisi üretiyor. Bir use-case düşün (ör. az önceki RAG mevzuat asistanı) ve boyutları seç:
interaktif tier hesaplayıcı
1 · Materiality: sistemin etkilediği hacim / finansal büyüklük?
2 · Müşteri etkisi: çıktı müşteriye dokunuyor mu?
3 · Otonomi: çıktı ile aksiyon arasında insan var mı?
4 · Regülasyon kapsamı: özel bir rejime giriyor mu?
5 · Teknoloji katmanı (Modül 05'in taksonomisi)?
TIER 2
Validasyon derinliği
—
Periyodik döngü
—
İzleme yoğunluğu
—
İki tasarım notu. Birincisi: gerçek çerçevede skorlama bu kadar mekanik olmamalı — hesaplayıcı bir öneri üretir, nihai tier kararı gerekçeli insan kararıdır (ve gerekçesi kaydedilir). Mekanik skor + gerekçeli override, hem tutarlılık hem esneklik sağlar; override oranını izlemek de ayrıca öğreticidir. İkincisi: otonomi boyutunun ağırlığına dikkat et — "otomatik aksiyon" seçildiğinde tier'ın nasıl sıçradığını gör. Bu, Modül 05'teki ilkenin operasyonel hali: riski büyüten şey teknolojinin yeniliği değil, hata ile zarar arasındaki mesafenin kısalığıdır.
validasyon takvimi: plan, kapasiteyle çarpışınca
Yıllık inceleme planı; periyodik incelemeler, düzenleme ve bulgu tarihleri, yeni sistemler, değişiklikler ve kullanılabilir uzmanlık kapasitesini birlikte ele alır. Aşağıdaki kurgusal panel, planlanan iş yükü ile kapasite arasındaki ilişkiyi gösterir.
yıllık kapasite simülatörü
Tier 1 yıllık inceleme
5
Tier 2 yıllık inceleme
14
Tier 3 yıllık inceleme
30
Yıl içi beklenen yeni/değişiklik talebi (×12 gün)
8
Analist sayısı (×180 net gün/yıl)
4
Talep: — analist-günKapasite: — analist-gün
Simülatörün öğrettiği ders: takvim bir istek listesi değil, bir bütçe kararıdır. Talep kapasiteyi aşıyorsa dört meşru kaldıraç vardır: tier eşiklerini gözden geçir (bazı Tier 2'ler gerçekten Tier 2 mi?), periyodik döngüleri riske göre uzat (Tier 3'ü 2 yıla çıkar), scope'u daralt (targeted validation — Modül 10) veya kapasite iste (işe alım gerekçen hazır: sayılarla). Meşru olmayan beşinci yol ise en yaygın olanıdır: planı olduğu gibi bırakıp kaliteyi sessizce düşürmek.
Takvimin görünmez kalemi: plansız talep. Yeni use-case'ler, acil değişiklikler, vendor güncellemeleri ve bulgu takibi yılın ortasında gelir ve tipik olarak kapasitenin %20–30'unu yer. Simülatörde "yeni/değişiklik talebi" kaydırıcısı bunu temsil ediyor — planında bu tampon yoksa, ya periyodik validasyonlar kayar (denetim bulgusu) ya yeni sistemler onaysız çıkar (daha kötüsü).
Sayılar toplam envanter değil, yıl içinde planlanan inceleme adetleridir. Tier 1/2/3 başına 40/15/4 gün, yeni kullanımın ayrı ön incelemesi için 12 gün ve kişi başına 180 kullanılabilir gün varsayılmıştır. Aynı iş iki başlıkta tekrar sayılmamalıdır. Periyotlar, ağırlıklar ve %85 tampon sınırı örnek politikadır; düzenleyici kural veya sektör ortalaması değildir.
Orantılı inceleme
İç risk sınıfı, inceleme önceliğini ve derinliğini belirlemek için kullanılır. Hukuki sınıflandırmanın yerine geçmez; farklı bağlamlar aynı teknik modele farklı öncelikler verebilir.
Planlama; inceleme talebi, değişiklik sıklığı, uzmanlık ve izleme iş yükünü birlikte ele alır. Kaynak açığı, zorunlu kontrollerin kendiliğinden azaltılması için gerekçe oluşturmaz.
anahtar çıkarımlar
geniş kayıt, orantılı yük
Kayıt eşiğini düşük tut, yükü tier'a bağla. Kayıttan kaçma teşviki, kaydın maliyetiyle orantılıdır — Tier 3 yükü yarım sayfaysa savaş biter. İstisnalar yazılı kurala bağlanır.
tier, sonraki her şeyin türetildiği karardır
Derinlik, sıklık ve izleme tier'dan türer; yanlış tier sistematik eksik gözetim üretir. Mekanik skor öneri verir, insan gerekçeyle karar verir — ve override'lar loglanır.
otonomi, tier'ı en hızlı yükselten boyuttur
Çıktı ile aksiyon arasındaki insan kalktığında hata-zarar mesafesi sıfırlanır. Aynı sistem, "öneri" modundan "otomatik" moda geçtiğinde yeniden tier'lanmalıdır.
takvim bir bütçe kararıdır
Talep kapasiteyi aşıyorsa kaynak, öncelik ve takvim yeniden değerlendirilir. Risk sınıflandırması ve zorunlu kontroller, plana sığdırmak için gevşetilmez.
Uygulama örneği · kurgusal vaka
karar masası: “Sadece verimlilik aracı” itirazı
Senaryo: Kurumsal Copilot envanter dışında; gerekçe “karar vermiyor.” Pilot grup kredi ret gerekçesi, müşteri e-postası ve mevzuat özeti üretmekte kullanıyor.
Örnek değerlendirmeyi aç
DeğerlendirmeEnvantere al; tier’ı ürün etiketinden değil gerçek ve öngörülebilir kullanımdan belirle. Kritik kullanım netleşene kadar yasak sınırı teknik/yönetsel kontrollerle uygula.
Gerekli kanıtKullanım telemetrisi; veri sınıfları; gerçek use-case örnekleri; müşteri süreçleri; insan kontrolü; vendor veri şartları; kapsam dışı oran; sahip ve bağımlılıklar.
Karar kaydıEnvanter kaydı + tier gerekçesi: hedef/yasak kullanım, sistem sınırı, kontroller, çerçeve onayı koşulları ve tier tetikleyicileri.