AI Risk Değerlendirme Dokümanı Nasıl Hazırlanır?

AI risk değerlendirmesi nasıl hazırlanır? Bir ai risk değerlendirmesi, bir yapay zeka sisteminin kime, hangi kararda, hangi veriyle ve hangi olası zarar potansiyeliyle kullanıldığını yapılandırılmış biçimde ortaya koyan; her riski olasılık ve etkiye göre puanlayan ve her risk için azaltıcı kontrol ile insan gözetimi mekanizmasını tanımlayan bir dokümandır. Kısacası, "bu sistem neyi yanlış yapabilir ve biz buna karşı ne yaptık" sorusunun yazılı, imzalı ve güncellenen cevabıdır.

Kurumlar yapay zekayı hızla devreye alırken en çok atladıkları adım, sistemi canlıya geçirmeden önce onun neyi bozabileceğini düşünmektir. Bir ai risk değerlendirmesi tam da bu boşluğu doldurur: teknik heyecanı, sorumlu bir karar kaydına dönüştürür. Bu rehberde risk dokümanı hazırlama sürecini bölüm bölüm, bir danışman titizliğiyle ele alıyoruz: dokümanın kimin sorusunu cevapladığından başlayarak sistem tanımı, veri ve kişisel veri boyutu, risk senaryoları ve etki analizi, azaltma önlemleri, insan gözetimi, şablon iskeleti ve onay süreci başlıklarını tek tek açıyoruz. Yazının sonunda, kopyalayıp doldurabileceğiniz bir iskelet ve en sık atlanan bölümleri gösteren bir tablo bulacaksınız. Bu içerik bilgilendirme amaçlıdır; hukuki tavsiye değildir ve kurumunuzun hukuk ve uyum birimiyle birlikte uygulanmalıdır.

Tanım

AI Risk Değerlendirmesi

Bir yapay zeka sisteminin kime, hangi kararda, hangi veriyle ve hangi olası zarar potansiyeliyle kullanıldığını yapılandırılmış biçimde ortaya koyan; her riski olasılık ve etkiye göre puanlayan; her risk için azaltıcı kontrol, kalan artık risk ve insan gözetimi mekanizmasını tanımlayan doküman ve süreç. Teknik ekip doldurur; iş sahibi, veri/gizlilik, bilgi güvenliği ve hukuk/uyum birlikte onaylar; sistem değiştikçe güncellenen canlı bir kayıttır.

Ayrıca: yapay zeka risk değerlendirmesi, AI risk analizi, risk dokümanı, etki değerlendirmesi

Birçok kurumda ai risk değerlendirmesi, doldurulup bir klasöre kaldırılan bir uyum formu olarak algılanır. Bu algı, belgenin bütün değerini yok eder. İyi bir risk değerlendirmesi bir form değil, bir karar kaydıdır: kurumun "bu yapay zeka sistemini şu koşullarla, şu riskleri bilerek ve şu önlemleri alarak kullanmayı kabul ediyoruz" dediği yerdir. Fark inceliktir ama sonuçları büyüktür — form doldurmak için yazılır, karar kaydı ise sorumluluk almak için yazılır.

Bu ayrımı somutlaştıralım. Bir form, "kişisel veri kullanılıyor mu? Evet/Hayır" kutucuğuyla yetinir. Bir karar kaydı ise şunu yazar: "Bu sistem müşteri destek geçmişini kullanıyor; içinde ad, iletişim ve şikayet detayı gibi kişisel veri var; işleme şartı sözleşmenin ifası; bu verinin modele gitmeden önce maskelenmesine karar verdik; maskeleme başarısız olursa sistem yanıt üretmiyor; bu kararı iş sahibi ve gizlilik sorumlusu onayladı." İkisi de aynı soruya değinir ama yalnızca ikincisi bir kurumu koruyabilecek düzeyde açıktır.

Bu yüzden bir ai risk değerlendirmesi yazarken sorulacak asıl soru "hangi kutucukları işaretlemeliyim" değil, "bir sorun çıktığında bu belge, aldığımız kararların gerekçesini ve makuliyetini gösterebilir mi" olmalıdır. Yapay zeka riskinin genel çerçevesini sorumlu yapay zeka nedir yazısında ele alıyoruz; bu rehber ise o riskleri belgeye dökmenin pratik yöntemidir. Değerlendirme, teknik bir denetim raporu değil; teknik gerçeği iş kararına bağlayan bir köprüdür.

Brief'in ilk maddesi haklı olarak şunu sorar: bu doküman kimin sorusunu cevaplıyor? Cevap, belgenin nasıl yazılacağını belirler; çünkü tek bir okuyucusu olmayan bir metindir. İyi bir ai risk değerlendirmesi aynı anda beş farklı okuyucuya konuşur ve her birinin sorusunu net biçimde yanıtlar. Bu okuyucuları bilmeden yazılan bir belge ya fazla teknik olur ve yönetim okuyamaz, ya fazla yüzeysel olur ve denetçi tatmin olmaz.

Birinci okuyucu iş sahibi ve yönetimdir. Onların sorusu şudur: "Bu sistemi kullanmak kurumu hangi risklere sokuyor ve bu risk kabul edilebilir mi?" Onlar için belge, iş diliyle yazılmış bir yönetici özeti ve net bir "kabul edilen artık risk" beyanı içermelidir. İkinci okuyucu hukuk ve uyum birimidir; onların sorusu "bu sistem yürürlükteki düzenlemelere ve iç politikalara uygun mu, uygunluğu nasıl kanıtlıyoruz" şeklindedir. Üçüncü okuyucu bilgi güvenliğidir; onlar erişim kontrolü, veri sızıntısı ve saldırı yüzeyiyle ilgilenir.

Dördüncü okuyucu, sistemi geliştiren ve işleten teknik ekiptir; onlar için belge, hangi kontrolleri kurmaları gerektiğinin somut listesidir. Beşinci ve çoğu zaman unutulan okuyucu ise gelecektir: altı ay sonra sisteme dokunacak, ekibe yeni katılan biri veya bir denetçi. O kişi, "bu sistem neden böyle kurulmuş, hangi riskler tartışılmış ve neye karar verilmiş" sorusunu belgeye sorar. Regüle sektörlerde bu okuyucu somut bir denetçiye dönüşür; regüle sektörde onay süreçlerinin sahadaki gerçeğini regüle sektörde AI onay süreçleri yazısında paylaşıyorum. Belgeyi bu beş okuyucuyu aynı anda düşünerek yazmak, onu gerçekten işlevsel kılar.

Bir ai risk değerlendirmesine oturmadan önce bütünü görmek gerekir. Aşağıdaki tablo, sağlam bir risk dokümanı hazırlama sürecinin bölümlerini, her bölümün ne içermesi gerektiğini ve sahada en sık atlanan noktayı bir arada gösterir. Bu tablo aynı zamanda yazının geri kalanının yol haritasıdır; her satırı ilerleyen bölümlerde derinleştiriyoruz.

AI risk değerlendirme dokümanı: bölüm × içerik × en sık atlanan

Doküman bölümü	Ne içermeli	Sık atlanan
Sistem tanımı ve amaç	Sistem ne yapar, kim kullanır, hangi karara dokunur	Kapsam sınırı ve amaç dışı kullanım yasağı
Veri ve kişisel veri	Veri envanteri, kaynak, kişisel veri, işleme şartı	Verinin sağlayıcıya gidip gitmediği
Risk senaryoları ve etki analizi	Neyin yanlış gideceği, olasılık, etki, skor	En kötü durum ve nadir yıkıcı senaryolar
Azaltma önlemleri	Her riske kontrol, kontrol tipi, sahibi	Kontrolden sonra kalan artık risk beyanı
İnsan gözetimi	Onay gereken kararlar, devir eşiği, itiraz	Devir eşiğinin somut sayı/kural olması
İzleme ve olay yönetimi	Metrikler, uyarılar, olay müdahale planı	Yeniden değerlendirme tetikleyicileri
Onay ve roller	Kim hazırlar, kim onaylar, tarih, versiyon	Riski kabul eden yetki seviyesinin uygunluğu

Bu tabloya dikkatle bakıldığında ortaya çıkan desen şudur: en sık atlanan noktaların çoğu, "kötü haber" taşıyan bölümlerdir. Artık risk beyanı, en kötü durum senaryosu, yeniden değerlendirme tetikleyicileri — bunlar belgeyi yazanı rahatsız eden ama tam da onu değerli kılan kısımlardır. Zayıf bir risk değerlendirmesi iyimserdir; güçlü bir tanesi ise dürüsttür. İlerleyen bölümlerde her satırı tek tek açıyoruz.

Her ai risk değerlendirmesi, değerlendirilen şeyin net tanımıyla başlar. Bu bariz görünür ama pratikte en çok karıştırılan adımdır: ekipler "yapay zeka sistemimiz" der ama tam olarak neyin sınır içinde, neyin dışında olduğunu tanımlamaz. Oysa risk, sınırın nerede çizildiğine göre tamamen değişir. Bir sohbet asistanının riski, onun sadece bilgi mi verdiğine yoksa işlem de mi yaptığına bağlıdır; bu ayrım sistem tanımında netleşmezse, tüm değerlendirme havada kalır.

Sağlam bir sistem tanımı şu soruları cevaplar: Sistem tam olarak ne yapıyor? Girdisi ne, çıktısı ne? Hangi model veya sağlayıcı kullanılıyor ve bu bir dış API mı yoksa kurum içinde mi çalışıyor? Kullanıcısı kim — çalışan mı, müşteri mi, otomatik başka bir sistem mi? Ve en kritiği: bu sistemin çıktısı hangi karara dokunuyor? Sadece bilgi mi sunuyor, yoksa bir onay, ret, fiyat, öneri veya işlem mi üretiyor? Karara dokunan sistemler, yalnızca bilgi sunanlardan çok daha yüksek risklidir.

Amaç bölümü ise "bu sistem neden var ve hangi sınırlar içinde kullanılmalı" sorusunu yanıtlar. Burada iki şey açıkça yazılır: hedeflenen kullanım ve yasaklanan kullanım. Örneğin bir özetleme asistanı için "hukuki bağlayıcılığı olan nihai karar üretmek için kullanılamaz" gibi bir amaç dışı kullanım sınırı, ileride pek çok riski baştan keser. Sistemin dış bir sağlayıcının modeline mi yoksa kendi altyapınızda çalışan bir modele mi dayandığı, veri ikametgahı ve kontrol açısından belirleyicidir; bu tercihin ayrıntısını on-premise ve egemen AI altyapısı yazısında ele alıyoruz.

Yapay zeka sistemlerinin riskinin büyük kısmı veriden gelir; bu yüzden bir ai risk değerlendirmesinin en özenli bölümü veri boyutudur. Burada üç soru cevaplanır: Sistem hangi veriyi kullanıyor? Bu veri nereden geliyor? Ve içinde kişisel veri var mı? Bu üç soruya yüzeysel cevap veren bir belge, en büyük riski görünmez kılar; çünkü veri hataları sessizdir ve genellikle bir olay patlayana kadar fark edilmez.

Veri envanteri, sistemin dokunduğu her veri kümesini listeler: eğitim/ince ayar verisi (varsa), getirme (retrieval) için kullanılan belgeler, kullanıcının girdiği veriler, sistemin ürettiği çıktılar ve logladığı kayıtlar. Her kalem için kaynak, hassasiyet düzeyi ve saklama süresi yazılır. Özellikle bir getirme tabanlı (RAG) sistemde, modele bağlam olarak giden belgeler kritik bir yüzeydir; bir kullanıcının görmemesi gereken bir belgenin yanıta sızması, buradaki en yaygın kazadır. RAG mimarisinin bilgi ve erişim boyutunu RAG nedir yazısında derinlemesine ele alıyoruz.

Kişisel veri boyutu ayrı bir titizlik ister. Belgede şu netleşmelidir: sistemde kişisel veri işleniyor mu, işleniyorsa hangi kategoride (iletişim, finansal, sağlık gibi özel nitelikli olabilir), hangi işleme şartına dayanılıyor ve bu veri dış bir modele/sağlayıcıya gidiyor mu? Bu son soru — verinin kurum dışına çıkıp çıkmadığı — tabloda "en sık atlanan" olarak işaretlediğimiz noktadır ve çoğu olayın kaynağıdır. Kişisel verinin ne olduğunu kişisel veri nedir yazısında; KVKK bağlamındaki güncel tartışmaları ise KVKK ve yapay zeka tartışmaları yazısında ele alıyoruz. İşleme şartı seçimi, otomatik karar ve model eğitiminde veri kullanımı gibi başlıklar, ai risk değerlendirmesinin veri bölümünü doğrudan besler.

Veri bölümünde cevaplanması gereken sorular ve neden önemli oldukları

Soru	Neden kritik	Atlanırsa risk
Hangi veri kullanılıyor?	Saldırı ve sızıntı yüzeyini tanımlar	Bilinmeyen veri = ölçülemeyen risk
Veri nereden geliyor?	Kaynak güvenilirliği ve izin zinciri	İzinsiz/kirli veri kullanımı
Kişisel veri var mı?	KVKK yükümlülüklerini tetikler	Hukuki ihlal ve yaptırım
Veri sağlayıcıya gidiyor mu?	Veri ikametgahı ve aktarım riski	Kontrolsüz yurt dışı aktarım
Ne kadar saklanıyor?	Saklama süresi ve silme yükümlülüğü	Süresiz saklama, gereksiz maruziyet

Bu tablo, veri bölümünün neden bir kutucuk işaretlemekten ibaret olamayacağını gösterir. Her satır, atlandığında somut bir zarara dönüşür. İyi bir veri bölümü, sistemin veri akışını uçtan uca — girdiden çıktıya, saklamadan silmeye — izlenebilir kılar ve bu akışın her durağında hangi kontrolün olduğunu belirtir.

Belgenin kalbi burasıdır. Risk senaryoları bölümü, "bu sistem neyi yanlış yapabilir" sorusunu somut senaryolara döker; etki analizi ise her senaryonun ne kadar olası olduğunu ve gerçekleşirse kime, ne kadar zarar vereceğini değerlendirir. Zayıf bir ai risk değerlendirmesi bu bölümü genel ifadelerle geçiştirir ("model hata yapabilir"); güçlü bir tanesi ise senaryoları isimlendirir, sahiplendirir ve puanlar.

İyi bir senaryo listesi, birbirinden farklı risk ailelerini tarar. Bunları düşünmek için pratik bir kontrol listesi kullanmak, kör noktaları azaltır. Yapay zeka sistemlerinde en sık karşılaşılan risk aileleri şunlardır:

• Doğruluk ve halüsinasyon: Sistem yanlış ama kendinden emin bir çıktı üretir ve kullanıcı buna güvenip yanlış karar verir. Halüsinasyonun doğasını yapay zeka halüsinasyonu nedir yazısında ele alıyoruz.
• Yanlılık ve ayrımcılık: Sistem belirli gruplara sistematik olarak dezavantajlı sonuç üretir; özellikle işe alım, kredi, fiyatlandırma gibi kararlarda kritiktir.
• Mahremiyet ve veri sızıntısı: Kişisel veya gizli bir bilginin yetkisiz bir kullanıcıya veya dışarıya sızması.
• Güvenlik ve manipülasyon: Prompt injection gibi girdi manipülasyonlarıyla sistemin kandırılması; bu saldırı türünü prompt injection nedir yazısında açıklıyoruz.
• Otomasyon ve devir riski: Sistemin, insan onayı olması gereken bir kararı otonom olarak alması veya çok adımlı bir görevde hatayı zincirleme büyütmesi. Ajan sistemlerinde hata yayılımını ajan iş akışlarında hata yönetimi yazısında derinleştiriyoruz.
• Bağımlılık ve süreklilik: Dış bir sağlayıcının modeline aşırı bağımlılık; sağlayıcı değişince veya hizmet kesilince iş sürecinin durması.

Her senaryo yazıldıktan sonra etki analizi devreye girer. Etki analizi iki eksende yürür: olasılık (bu senaryo ne kadar sık gerçekleşir) ve etki (gerçekleşirse zarar ne kadar büyük). Etki, tek bir açıdan değil; birey açısından (haksız karar, mahremiyet ihlali), kurum açısından (mali kayıp, itibar, hukuki yaptırım) ve gerektiğinde topluluk açısından ayrı ayrı düşünülmelidir. Bu üç düzeyi ayırmak, "kurum için küçük ama birey için yıkıcı" olan riskleri görünür kılar — ki bunlar en tehlikeli ve en çok atlanan senaryolardır.

Etki analizinin çıktısı bir risk skorudur, ama bu skorun amacı yanlış anlaşılırsa belge işe yaramaz. Skorun amacı kesin bir sayı üretmek değildir; riskleri karşılaştırılabilir kılıp önceliklendirmektir. Sahte bir kesinlik ("bu riskin skoru 7.4") tehlikelidir; çünkü tartışmayı bir sayının arkasına saklar. İyi bir puanlama, düşük/orta/yüksek gibi kaba ama üzerinde uzlaşılabilir kategoriler kullanır ve asıl değeri, o kategoriye neden karar verildiğinin gerekçesinde taşır.

Pratik bir yaklaşım, olasılık ve etkiyi ayrı ayrı üç veya beş kademede değerlendirip bir matris üzerinde birleştirmektir. Yüksek olasılık × yüksek etki = önce ele alınacak; düşük olasılık × düşük etki = kabul edilebilir ve izlenebilir. Ancak burada kritik bir uyarı vardır: düşük olasılıklı ama felaket etkili senaryolar (örneğin kitlesel bir veri sızıntısı) asla "düşük öncelik" olarak kestirilip atılmamalıdır. Bu tür "kuyruk riskleri", ortalama bir skorla gizlenir; bu yüzden en kötü durumu ayrıca yazmak, olgun bir etki analizinin ayırt edici özelliğidir.

Basit bir risk skorlama matrisi ve önerilen tepki

Olasılık × Etki	Skor bölgesi	Önerilen tepki
Yüksek × Yüksek	Kritik	Canlıya almadan azalt; gerekirse durdur
Yüksek × Düşük	Orta	Önleyici + tespit edici kontrol kur
Düşük × Yüksek	Kuyruk riski	En kötü durumu yaz, düzeltici plan hazırla
Düşük × Düşük	İzlenebilir	Kabul et, metrikle izle, dokümante et

Bu matris tek başına bir cevap değil, bir tartışma aracıdır. Asıl değer, ekibin her senaryoyu bu matrise yerleştirirken yaptığı konuşmadadır: "Bu gerçekten yüksek olasılıklı mı? Etkisi bireyi mi kurumu mu vuruyor?" Bu konuşma, riski herkesin aynı biçimde anlamasını sağlar ve etki analizini bürokratik bir egzersizden gerçek bir karar aracına dönüştürür. Skoru üreten süreç, skorun kendisinden daha değerlidir.

Risk senaryolarını yazmak ve puanlamak yarısıdır; belgenin diğer yarısı, her risk için ne yaptığınızı gösteren azaltma önlemleri bölümüdür. Buradaki altın kural basittir: puanlanan her riskin karşısında en az bir azaltıcı kontrol olmalı ve o kontrolden sonra kalan artık risk açıkça yazılmalıdır. "Kontrol koyduk, risk bitti" ifadesi bir zayıflık işaretidir; çünkü hiçbir kontrol riski sıfırlamaz — yalnızca azaltır. Olgun bir ai risk değerlendirmesi bu gerçeği saklamaz, kayda geçirir.

Azaltma önlemleri üç türe ayrılır ve iyi bir belge her risk için bu üç türü de düşünür. Önleyici kontroller, riskin gerçekleşme olasılığını düşürür: girdi doğrulama, erişim kısıtlama, hassas veri maskeleme, prompt injection savunması, çıktı filtreleme. Tespit edici kontroller, risk gerçekleştiğinde onu hızlı fark etmenizi sağlar: izleme, anomali uyarısı, denetim kaydı, kullanıcı geri bildirim kanalı. Düzeltici kontroller ise gerçekleşen zararı sınırlar ve geri döndürür: geri alma mekanizması, insana devir, olay müdahale prosedürü, acil durdurma (kill switch).

Azaltma önlemi tipleri, riski hangi eksende düşürdüğü ve örnekler

Kontrol tipi	Neyi düşürür	Örnek
Önleyici	Olasılığı	Erişim kısıtı, veri maskeleme, girdi doğrulama
Tespit edici	Fark etme süresini	İzleme, anomali uyarısı, denetim kaydı
Düzeltici	Etkiyi	Geri alma, insana devir, acil durdurma
Yönetişimsel	Tekrarı ve yayılmayı	Politika, eğitim, düzenli gözden geçirme

Her yazılan kontrolün iki niteliği olmalıdır: bir sahibi ve bir doğrulama yöntemi. "İnsan kontrol eder" gibi belirsiz bir ifade, kontrol değildir; çünkü kim, ne zaman, hangi eşikte kontrol edeceği belli değildir. Bunun yerine "güven skoru %80'in altındaki kararlar operasyon ekibine düşer ve onaylanmadan işleme geçmez" gibi somut, sahibi ve eşiği belli bir kural yazılır. Güvenlik tarafındaki koruyucu katmanları guardrail nedir yazısında ele alıyoruz; azaltma önlemleri bölümünün teknik sırtını bu tür kontroller oluşturur.

Artık risk beyanı, bu bölümün en çok atlanan ama en dürüst kısmıdır. Her kontrol sırasının sonunda "bu kontrollere rağmen kalan risk şudur ve bu riski kabul ediyoruz" cümlesi yazılır. Bu cümle, riski görünür kılar ve onu kabul edecek yetkiyi belgeye çağırır. Artık riski yazmayan bir belge, riski yok etmez; sadece onu belgeleyen kişiyi ileride savunmasız bırakır. Dürüst bir artık risk beyanı, hem kurumu korur hem de gelecekteki gözden geçirmeye sağlam bir başlangıç noktası verir.

"İnsan gözetimi vardır" cümlesi, risk değerlendirmelerinde en sık yazılan ama en az anlam taşıyan ifadedir. Çünkü bir eşik, bir kural ve bir sorumlu olmadan insan gözetimi bir slogandır. İyi bir ai risk değerlendirmesi, insan gözetimini somut sorulara indirger: Hangi kararlarda insan onayı zorunludur? Sistem hangi durumda kendiliğinden insana devreder? Devralan insan neyi görür ve neye göre karar verir? Ve kullanıcının bir karara itiraz kanalı nedir?

İnsan gözetiminin tasarımında üç yaygın model vardır ve doğru model, riskin büyüklüğüne göre seçilir. Birincisi "insan döngüde" (human-in-the-loop): sistem bir öneri üretir ama nihai kararı her zaman bir insan verir; yüksek riskli kararlar (kredi reddi, işe alım eleme, tıbbi öneri) için uygundur. İkincisi "insan döngü üzerinde" (human-on-the-loop): sistem otonom çalışır ama bir insan izler ve gerektiğinde müdahale eder; orta riskli, yüksek hacimli işlemler için uygundur. Üçüncüsü "insan döngü dışında": sistem tamamen otonomdur ve yalnızca çok düşük riskli, geri alınabilir kararlar için kabul edilebilir.

İnsan gözetimi modelleri ve hangi risk düzeyine uygun oldukları

Model	Nasıl çalışır	Uygun risk düzeyi
İnsan döngüde	Sistem önerir, insan karar verir	Yüksek: geri alınamaz, kişiyi etkileyen kararlar
İnsan döngü üzerinde	Sistem karar verir, insan izler ve müdahale eder	Orta: yüksek hacim, sınırlı etki
İnsan döngü dışında	Tam otonom, sonradan denetim	Düşük: geri alınabilir, düşük etkili kararlar

Eşik tanımı, insan gözetiminin en somut parçasıdır. "Sistem emin olmadığında insana devreder" cümlesi yeterli değildir; "emin olmama" bir sayıya bağlanmalıdır. Örneğin: güven skoru belirli bir seviyenin altındaysa, sistem işlemi otomatik olarak durdurup insan onayına gönderir; ya da işlem parasal bir eşiği aşıyorsa insan onayı zorunludur. Bu eşiklerin belgede somut yazılması, "gözetim var" iddiasını denetlenebilir bir gerçeğe dönüştürür. Prompt mühendisliğinin ötesine geçip insanla yapay zekanın rol paylaşımını tasarlamayı insan-AI iş birliği yazısında ele alıyoruz; iyi tasarlanmış bir gözetim, bu iş birliğinin belgedeki karşılığıdır.

Son olarak itiraz ve düzeltme kanalı, özellikle kişiyi etkileyen kararlarda vazgeçilmezdir. Sistem bir kullanıcı hakkında olumsuz bir karar ürettiyse (bir başvuruyu reddetti gibi), o kullanıcının bu karara itiraz edebileceği ve bir insanın durumu yeniden değerlendireceği bir yol tanımlanmalıdır. Otomatik kararlara itiraz hakkı, hem etik hem de KVKK gibi düzenlemeler açısından belgenin dikkat etmesi gereken bir noktadır.

Bir sistem canlıya alındığında risk değerlendirmesi bitmez; asıl orada başlar. Çünkü canlı bir sistemin davranışı, kağıt üzerindeki tasarımdan sapar: veriler değişir, kullanıcılar beklenmedik biçimde kullanır, model güncellenir. Bu yüzden sağlam bir ai risk değerlendirmesi, sistemin canlıdaki davranışını nasıl izleyeceğinizi ve bir sorun çıktığında ne yapacağınızı da tanımlar. Bu bölüm, belgeyi statik bir tasarım dokümanından yaşayan bir yönetim aracına dönüştürür.

İzleme bölümü, hangi metriklerin takip edileceğini belirler: sistemin çıktı kalitesi, hata oranı, insana devir sıklığı, kullanıcı şikayetleri, gecikme ve maliyet. Bu metriklerin her biri için bir "normal aralık" ve bir "uyarı eşiği" tanımlanır; eşik aşıldığında kimin haberdar olacağı yazılır. Yapay zeka sistemlerini üretimde izlemenin ve operasyonel disiplinin ayrıntısını LLMOps nedir yazısında ele alıyoruz. İzleme olmadan, bir sistemin sessizce bozulması — çıktı kalitesinin zamanla düşmesi — fark edilmeden büyür.

Olay yönetimi planı, "en kötü gerçekleşti" durumunu önceden düşünmektir. Belge şu soruları cevaplamalıdır: Bir olay (yanlış karar, veri sızıntısı, kötüye kullanım) nasıl tespit edilir? Kim bilgilendirilir? Sistem geçici olarak nasıl durdurulur? Etkilenen kişilere nasıl ulaşılır? Ve olaydan sonra kök neden analizi nasıl yapılır? Bu planı olay anında değil, sakin bir kafayla önceden yazmak, kriz anında kaybedilen değerli dakikaları kurtarır.

Yeniden değerlendirme tetikleyicileri ise belgenin canlı kalmasını garanti eder. Bir ai risk değerlendirmesi bir kez yazılıp rafa kaldırıldığında, kısa sürede gerçeği yansıtmayan tehlikeli bir kağıda dönüşür. Bu yüzden belgeye, onu ne zaman güncelleyeceğinizi söyleyen tetikleyiciler yazılır: takvimsel (en az yılda bir) ve olay bazlı (model/sağlayıcı değişimi, yeni veri kaynağı, kullanım amacının genişlemesi, yeni düzenleme, ciddi bir olay). Bu tetikleyiciler dokümanın içinde açıkça yer aldığında, güncelleme kişilerin hafızasına değil sürecin kendisine bağlanır.

Bir ai risk değerlendirmesi, imzalanmadan yalnızca bir taslaktır. Onay süreci, belgeyi bir kurumsal karara dönüştüren adımdır ve en sık yapılan hata, bunu tek bir imzaya indirgemektir. Sağlam bir onay süreci katmanlıdır: farklı riskleri farklı yetkinlikteki kişiler değerlendirir ve onaylar. Çünkü hiçbir tek kişi, bir yapay zeka sisteminin teknik, hukuki, güvenlik ve iş boyutlarının hepsinde yetkin değildir.

Tipik bir katmanlı onay süreci şöyle işler. Belgeyi sistemin teknik sahibi (ürün, veri veya ML ekibi) hazırlar; çünkü sistemin nasıl çalıştığını en iyi o bilir. Ardından her paydaş kendi alanından onay verir: iş sahibi kullanım amacını ve kabul edilen artık riski; veri/gizlilik sorumlusu kişisel veri boyutunu ve işleme şartını; bilgi güvenliği erişim ve güvenlik kontrollerini; hukuk/uyum düzenleyici uygunluğu. Bu paydaşlardan biri "hayır" derse, belge onaylanmaz — bu, sürecin bir özelliğidir, hatası değil.

Onay sürecinde roller ve her rolün onayladığı boyut

Rol	Neyi onaylar	Sorusu
Teknik sahip	Sistem tanımı ve kontroller doğru mu	Belge sistemi gerçekten yansıtıyor mu?
İş sahibi	Amaç ve kabul edilen artık risk	Bu riski almaya değer mi?
Veri/gizlilik	Kişisel veri ve işleme şartı	KVKK uyumu sağlandı mı?
Bilgi güvenliği	Erişim ve güvenlik kontrolleri	Saldırı yüzeyi kabul edilebilir mi?
Hukuk/uyum	Düzenleyici ve sözleşmesel uygunluk	Yasal olarak savunulabilir mi?
Yönetim/komite	Yüksek riskli sistemlerde nihai kabul	Kurum bu sorumluluğu üstleniyor mu?

Onay sürecinin en kritik ilkesi şudur: riski kabul eden kişi, o riskin sonucundan sorumlu tutulabilecek yetki seviyesinde olmalıdır. Küçük bir riski bir ekip lideri kabul edebilir; ama kuruma ciddi mali veya itibar riski taşıyan bir sistemi bir yazılımcının "onayladı" sayılması yanlıştır. Riskin büyüklüğü, onay seviyesini yukarı çeker. Yüksek riskli veya müşteriye/çalışana doğrudan dokunan sistemlerde onay, bir risk komitesine veya yönetim seviyesine çıkar. Regüle sektörlerde bu onay süreci daha da katmanlıdır ve dış denetime hazır olmak gerekir; bu sürecin sahadaki gerçek işleyişini ve en sık takılınan noktaları regüle sektörde AI onay süreçleri yazısında paylaşıyorum.

Onay süreci ayrıca versiyonlanmalıdır. Her onay, belgenin belirli bir versiyonuna verilir; belge güncellendiğinde, değişikliğin büyüklüğüne göre yeniden onay gerekip gerekmediği değerlendirilir. Küçük bir düzeltme yeni bir tam onay gerektirmeyebilir; ama kullanım amacının veya veri kaynağının değişmesi, onay sürecini baştan tetikler. Bu disiplin, belgenin gerçekten kurumun güncel kararını yansıtmasını sağlar.

Şimdiye kadar anlattığımız her şeyi bir araya getirelim. Aşağıdaki iskelet, bir ai risk değerlendirmesi dokümanının kopyalanıp doldurulabilecek bir başlangıç yapısıdır. Amaç, sıfırdan başlamanın verdiği "nereden tutsam" felcini ortadan kaldırmaktır. Bu iskeleti kurumunuzun bağlamına, sektörüne ve risk iştahına göre uyarlayın; her başlığın altına, ilgili bölümde anlattığımız içeriği yazın.

Nasıl Yapılır

AI risk değerlendirme dokümanı iskeleti

Boş bir risk değerlendirme dokümanını oluşturan bölümler; her adım belgede bir başlığa karşılık gelir.

1. 1

   Kapak ve versiyon

   Sistem adı, doküman sahibi, versiyon numarası, tarih, onay durumu ve sınıflandırma (gizlilik düzeyi).

2. 2

   Yönetici özeti

   Sistem ne yapar, en yüksek üç risk, alınan başlıca önlemler ve kabul edilen artık risk; iş dilinde yarım sayfa.

3. 3

   Sistem tanımı ve amaç

   Ne yapar, kim kullanır, hangi karara dokunur, hangi model/sağlayıcı, hedeflenen ve yasaklanan kullanım.

4. 4

   Kapsam ve sınırlar

   Neyin kapsam içi, neyin dışı olduğu; bilinçli olarak başka değerlendirmeye bırakılanlar.

5. 5

   Veri ve kişisel veri envanteri

   Veri kalemleri, kaynak, hassasiyet, kişisel veri kategorisi, işleme şartı, sağlayıcıya aktarım, saklama süresi.

6. 6

   Risk senaryoları ve etki analizi

   Her senaryo için tanım, olasılık, etki (birey/kurum/topluluk), risk skoru ve en kötü durum.

7. 7

   Azaltma önlemleri ve artık risk

   Her riske kontrol (önleyici/tespit edici/düzeltici), kontrol sahibi, doğrulama yöntemi ve kalan artık risk beyanı.

8. 8

   İnsan gözetimi

   Onay gereken kararlar, devir eşiği (somut kural), gözetim modeli ve itiraz/düzeltme kanalı.

9. 9

   İzleme ve olay yönetimi

   Takip edilecek metrikler, uyarı eşikleri, olay müdahale planı ve yeniden değerlendirme tetikleyicileri.

10. 10

    Roller ve onaylar

    Hazırlayan ve onaylayan roller, imza, tarih, onaylanan versiyon ve bir sonraki gözden geçirme tarihi.

Bu iskeletin gücü, tamlığında ve sırasındadır. Yönetici özeti başta durur ki meşgul bir okuyucu ilk yarım sayfada resmi görebilsin; teknik derinlik sonra gelir. Artık risk beyanı ve yeniden değerlendirme tetikleyicileri gibi en sık atlanan bölümler, iskelette açıkça yer alarak "unutulamaz" hale gelir. Şablonu bir kez kurumunuza uyarlayıp standartlaştırdığınızda, her yeni yapay zeka sistemi için risk dokümanı hazırlama süreci hem hızlanır hem de tutarlı olur.

Bir uyarı: şablon bir yardımcıdır, bir düşünme yerine geçmez. Boş başlıkları mekanik biçimde doldurmak, belgenin ruhunu kaçırır. Her başlığın altına yazarken sorulacak soru hep aynıdır: "Bir sorun çıkarsa, bu satır bize ve bir denetçiye ne söyler?" Bu soruyu her bölümde sormak, iskeleti gerçek bir değerlendirmeye dönüştürür.

Şablonu bilmek ayrı, onu ilk kez doldurmak ayrıdır. Aşağıdaki adımlar, bir ai risk değerlendirmesini sıfırdan ilk onaylı sürümüne taşıyan pratik bir akış sunar. Bu akış, risk dokümanı hazırlama işini büyük ve korkutucu bir görevden, yönetilebilir adımlara böler.

İlk adım, doğru kişileri bir araya getirmektir. Risk değerlendirmesi tek kişilik bir iş değildir; teknik sahip, iş sahibi ve mümkünse gizlilik/güvenlik temsilcisinin birlikte olduğu kısa bir çalıştay, dağınık bir belgeden çok daha iyi sonuç verir. İkinci adım, sistemi ve veriyi tanımlamaktır — iskeletin ilk bölümlerini birlikte doldurmak, herkesin aynı sistemden bahsettiğinden emin olmayı sağlar. Şaşırtıcı biçimde, ekipler sıklıkla "sistem tam olarak ne yapıyor" sorusunda bile başta anlaşamaz; bu adım o farkı ortaya çıkarır.

Üçüncü adım, riskleri birlikte beyin fırtınasıyla çıkarmaktır. Yukarıdaki risk aileleri kontrol listesini kullanarak "bu ailede bizim sistemimiz için ne yanlış gidebilir" sorusunu tek tek sorun. Dördüncü adım, çıkan riskleri puanlamak ve önceliklendirmektir — burada etki analizi matrisi işe yarar. Beşinci adım, en yüksek öncelikli risklerden başlayarak azaltma önlemleri ve artık riski yazmaktır. Altıncı adım, insan gözetimi ve izleme planını tanımlamak; yedinci adım ise belgeyi onay sürecine sokmaktır. Bu yedi adım, ilk taslağı birkaç oturumda ortaya çıkarır; mükemmel olması gerekmez, çünkü belge zaten canlı ve güncellenecek bir kayıttır.

Yeterince belge gördükten sonra, başarısız risk değerlendirmelerinin benzer hatalarla battığı görülür. Bunları önceden bilmek, kendi belgenizde onlardan kaçınmanızı sağlar. En yaygın hatalar şunlardır:

• Belgeyi bir form gibi doldurmak: Kutucuk işaretleyip bir gerekçe yazmamak. Belgenin değeri "evet/hayır"da değil, "neden ve nasıl"dadır.
• İyimser senaryo yanlılığı: Yalnızca olası ve orta etkili riskleri yazıp, nadir ama yıkıcı "kuyruk risklerini" görmezden gelmek. En kötü durumu yazmayan bir etki analizi eksiktir.
• Artık riski gizlemek: Her kontrolden sonra "risk bitti" demek. Sıfırlanmayan riski yazmamak, onu yok etmez; sadece belgeyi yalancı yapar.
• Belirsiz insan gözetimi: "İnsan kontrol eder" yazıp eşik, kural ve sorumlu tanımlamamak. Somut bir eşik olmadan gözetim bir slogandır.
• Tek imza ile onay: Katmanlı onay yerine tek kişinin imzasına güvenmek. Hiçbir tek kişi tüm boyutlarda yetkin değildir.
• Rafa kaldırmak: Belgeyi bir kez yazıp güncellememek. Yeniden değerlendirme tetikleyicisi olmayan bir belge, kısa sürede gerçeği yansıtmaz.
• Veri akışını yüzeysel geçmek: Verinin sağlayıcıya gidip gitmediğini net yazmamak. Bu, olayların en yaygın kaynağıdır.
• Kopyala-yapıştır değerlendirme: Başka bir sistemin belgesini isim değiştirip kullanmak. Her sistemin riski kendine özgüdür; şablon paylaşılır, içerik paylaşılmaz.

Bir ai risk değerlendirmesi boşlukta yazılmaz; yürürlükteki düzenlemeler ve tanınmış çerçeveler onun iskeletini besler. Bu bölüm, belgeyi hangi referanslara yaslayabileceğinizi özetler. Önemli bir not: aşağıdakiler bilgilendirme amaçlıdır, hukuki tavsiye değildir; her kurumun kendi hukuk ve uyum birimiyle çalışması şarttır ve düzenlemeler zamanla değişir.

Türkiye bağlamında ilk referans KVKK'dır (Kişisel Verilerin Korunması Kanunu). Sistem kişisel veri işliyorsa, risk değerlendirmesinin veri bölümü doğrudan KVKK yükümlülükleriyle konuşur: işleme şartı, amaçla sınırlılık, veri minimizasyonu, saklama süresi, aktarım kuralları ve ilgili kişinin hakları. Otomatik kararlara itiraz ve model eğitiminde veri kullanımı gibi güncel tartışma başlıklarını KVKK ve yapay zeka tartışmaları yazısında ele alıyoruz; bu başlıklar, ai risk değerlendirmesinin veri ve insan gözetimi bölümlerini doğrudan etkiler.

Avrupa'ya ürün veya hizmet sunan Türk kurumları için ek bir katman EU AI Act'tir (Avrupa Yapay Zeka Yasası). Bu yasa, yapay zeka sistemlerini risk seviyelerine göre sınıflandırır ve yüksek riskli sistemlere risk yönetim sistemi, veri yönetişimi, teknik dokümantasyon, kayıt tutma, şeffaflık ve insan gözetimi gibi somut yükümlülükler getirir. Bir risk değerlendirme dokümanı, tam da bu yükümlülüklerin çoğunu karşılayan bir yapı sunar. Uluslararası referans olarak ISO/IEC 42001 (yapay zeka yönetim sistemi standardı) ve NIST AI RMF (yapay zeka risk yönetimi çerçevesi), bir risk değerlendirmesinin bölümlerini ve süreçlerini yapılandırmakta yol gösterir; ikisi de "yönet, ölç, azalt, izle" mantığını paylaşır.

Belgeyi besleyen başlıca çerçeveler ve odakları

Çerçeve	Odağı	Belgeye katkısı
KVKK	Kişisel verinin korunması	Veri bölümü ve işleme şartı
EU AI Act	Risk seviyesine göre yükümlülük	Risk yönetimi ve insan gözetimi iskeleti
ISO/IEC 42001	Yapay zeka yönetim sistemi	Süreç ve rol yapısı
NIST AI RMF	Risk yönetim fonksiyonları	Yönet-ölç-azalt-izle döngüsü

Bu çerçeveleri bir zorunluluk listesi gibi değil, bir olgunluk rehberi gibi kullanmak en sağlıklısıdır. Hepsine aynı anda tam uyum, çoğu kurum için gerçekçi bir başlangıç değildir; ama bunların ortak mantığını — sistemi tanımla, riski analiz et, azalt, gözetim koy, izle ve gözden geçir — benimsemek, kurumunuzu hem bugünün hem yarının düzenlemelerine hazırlar. Ölçeklendikçe uyumu derinleştirebilir, dış denetime hazır bir yapıya doğru ilerleyebilirsiniz.

Her kurum ilk günden dört çerçeveye tam uyumlu, kusursuz bir ai risk değerlendirmesi üretemez ve buna çalışmak da yanlış olur. Doğru yaklaşım, olgunluğa göre büyüyen bir değerlendirme pratiğidir. Yeni başlayan bir kurum için tek sayfalık, dürüst bir risk notu bile hiç yoktan çok daha iyidir; olgunlaşmış bir kurum ise standartlaşmış, versiyonlanan ve dış denetime hazır bir süreç işletir. Önemli olan, bulunduğunuz yerden bir adım ötesine geçmektir.

Pratik bir olgunlaşma yolu şöyledir. Başlangıç seviyesinde, en yüksek riskli tek bir sistem için basit bir risk notu yazın; amaç, ekibin bu düşünme biçimine alışmasıdır. Bir sonraki seviyede, bu notu bu yazıdaki iskelete taşıyıp bir şablon standardı oluşturun ve tüm yeni yapay zeka sistemlerinde zorunlu kılın. Daha ileri bir seviyede, onay sürecini katmanlandırın, bir risk kaydı (envanter) tutun ve yeniden değerlendirmeyi takvime bağlayın. En olgun seviyede ise değerlendirme, bir yapay zeka yönetişim sisteminin parçası olur ve ISO/IEC 42001 gibi standartlarla hizalanır.

Bu yolculuğu hızlandırmanın en etkili yolu, değerlendirmeyi bir ceza değil bir kültür olarak konumlandırmaktır. Ekipler risk değerlendirmesini "canlıya almayı geciktiren bir engel" olarak görürse, onu baştan savar; "sistemimizi daha güvenli ve savunulabilir kılan bir araç" olarak görürse, sahiplenir. Bu kültürü kurmak, kurumun genel yapay zeka olgunluğuyla iç içedir; dijital ve yapay zeka olgunluğunu değerlendirmenin boyutlarını dijital olgunluk nedir yazısında ele alıyoruz. Kurumunuza özel bir risk değerlendirme çerçevesi ve şablonu kurmak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu yetkinliği kazanması için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

Her yapay zeka sistemi aynı düzeyde risk taşımaz; bu yüzden bir ai risk değerlendirmesinin derinliği, değerlendirilen sistemin türüne göre ölçeklenmelidir. Basit bir bilgi aracına ağır bir değerlendirme uygulamak kaynak israfıdır; kritik bir karar sistemine yüzeysel bir değerlendirme uygulamak ise tehlikelidir. Doğru orantıyı kurmak için sistemleri kabaca üç risk profiline ayırmak pratik bir başlangıçtır ve değerlendirmenin kapsamını bu profil belirler.

Birinci profil, yalnızca bilgi sunan araçlardır: özetleme, arama, taslak yazma, soru-cevap. Bu sistemlerin çıktısı bir insana yardımcı olur ama doğrudan bir karara dönüşmez; bir çalışan çıktıyı okur, değerlendirir ve kendi kararını verir. Buradaki başlıca riskler doğruluk, halüsinasyon ve veri sızıntısıdır; etki genellikle orta düzeyde kalır çünkü aradaki insan bir güvenlik ağı işlevi görür. Yine de "sadece bilgi veriyor" varsayımı yanıltıcı olabilir: eğer kullanıcılar çıktıya körü körüne güvenmeye başlarsa, insan güvenlik ağı erir ve risk sessizce yükselir.

İkinci profil, karar üreten veya bir karara doğrudan girdi olan sistemlerdir: bir başvuruyu puanlayan, bir fiyat öneren, bir işlemi onaylayan veya reddeden sistemler. Bu profil çok daha yüksek risklidir çünkü çıktı bir sonuca dönüşür ve o sonuç bir bireyi veya kurumu etkiler. Burada yanlılık, ayrımcılık ve haksız karar riskleri öne çıkar; insan gözetimi ve itiraz kanalı vazgeçilmez hale gelir. Üçüncü profil ise ajan sistemlerdir: çok adımlı görevleri planlayan ve araç kullanarak eyleme geçen sistemler. Bunlar en yüksek risk profilini taşır çünkü hem karar verir hem de eylemi kendisi uygular; hatanın zincirleme büyümesi ve geri alınamaz işlem riski buradadır. Ajan risklerinin ayrıntısını ajan iş akışlarında hata yönetimi yazısında derinleştiriyoruz.

Sistem türüne göre risk profili ve değerlendirme derinliği

Sistem türü	Baskın risk	Değerlendirme derinliği
Bilgi aracı	Halüsinasyon, sızıntı	Hafif-orta; doğruluk ve veri odaklı
Karar sistemi	Yanlılık, haksız karar	Derin; insan gözetimi ve itiraz zorunlu
Ajan sistem	Zincirleme hata, geri alınamazlık	En derin; işlem sınıfı ve geri alma odaklı

Bu profilleme, değerlendirme çabasını doğru yere yöneltir. Aynı şablonu kullanırsınız ama karar ve ajan sistemlerinde risk senaryoları, insan gözetimi ve azaltma önlemleri bölümlerine çok daha fazla emek verirsiniz. Sistemin profilini belgenin başında açıkça belirtmek, okuyucuya "bu değerlendirmenin neden bu derinlikte olduğunu" da anlatır.

Aynı yapay zeka yeteneği, farklı sektörlerde farklı risk ağırlıkları taşır; bu yüzden bir ai risk değerlendirmesi, kurumun içinde bulunduğu sektörün hassasiyetlerini yansıtmalıdır. Bir perakende öneri motorunun yanlış çalışması ile bir sağlık triyaj asistanının yanlış çalışması, aynı teknik hata olsa bile bambaşka sonuçlar doğurur. Değerlendirmeyi sektör bağlamından kopuk yazmak, en kritik riskleri gözden kaçırmanın en kolay yoludur.

Finans sektöründe baskın hassasiyet, düzenleyici uyum ve haksız karardır. Kredi, sigorta ve dolandırıcılık tespiti gibi kararlar hem bireyi doğrudan etkiler hem de yoğun düzenlemeye tabidir; bu yüzden yanlılık analizi, açıklanabilirlik ve denetim izi öne çıkar. Sağlık sektöründe etki, doğrudan insan sağlığına dokunduğu için en yüksek düzeydedir; burada en kötü durum senaryosu ve insan gözetimi, tartışmasız bir zorunluluktur. Kamu sektöründe ise şeffaflık, ayrımcılık yasağı ve vatandaşın itiraz hakkı öne çıkar; kamusal bir karar, açıklanabilir ve hesap verebilir olmak zorundadır.

Sektöre göre öne çıkan risk ağırlıkları

Sektör	Öne çıkan risk	Değerlendirmede vurgu
Finans	Haksız karar, uyum	Yanlılık, açıklanabilirlik, denetim izi
Sağlık	İnsan sağlığına etki	En kötü durum, insan gözetimi
Kamu	Ayrımcılık, hesap verebilirlik	Şeffaflık, itiraz hakkı
Perakende	Mahremiyet, manipülasyon	Kişisel veri, öneri etiği

Perakende ve pazarlamada ise mahremiyet ve manipülasyon riski öne çıkar: kişiselleştirme ne kadar güçlüyse, kişisel veri kullanımı ve kullanıcıyı yönlendirme etiği o kadar dikkatli değerlendirilmelidir. Sektör hangisi olursa olsun, değerlendirmeyi yazarken sorulacak soru şudur: "Bu sektörde bir hata, en çok kimi ve nasıl vurur?" Bu soru, risk senaryoları bölümüne sektörün gerçek hassasiyetlerini taşır. Regüle sektörlerde ayrıca dış onay katmanları devreye girer; bunların sahadaki işleyişini regüle sektörde AI onay süreçleri yazısında paylaşıyorum.

Çoğu kurumsal yapay zeka sistemi, dış bir sağlayıcının modeline veya altyapısına dayanır; bu yüzden sağlam bir ai risk değerlendirmesi, yalnızca kendi kodunuzu değil, bağımlı olduğunuz üçüncü tarafları da kapsamalıdır. Sistemin kalbindeki model bir dış API ise, o sağlayıcının davranışı, politikası ve sürekliliği doğrudan sizin risk profilinize girer. Bu bağımlılığı değerlendirmemek, riskin en büyük parçasını görmezden gelmektir.

Sağlayıcı riskinin birkaç boyutu vardır. Birincisi süreklilik ve bağımlılık: sağlayıcı hizmeti keserse, fiyatı ani değiştirirse veya modeli emekliye ayırırsa iş süreciniz durabilir. Buna karşı bir çıkış planı (başka bir sağlayıcıya geçebilme, kritik bileşenleri soyutlama) değerlendirmede yer almalıdır. İkincisi veri işleme: sağlayıcıya gönderdiğiniz veri nasıl işleniyor, saklanıyor, eğitimde kullanılıyor mu? Bu sorular hem gizlilik hem KVKK açısından kritiktir ve genellikle sağlayıcının sözleşme ve veri işleme şartlarında yanıtlanır. Üçüncüsü model değişimi: sağlayıcı modeli sessizce güncellediğinde, sizin sisteminizin davranışı habersiz değişebilir; bu, izleme ve yeniden değerlendirme tetikleyicilerinin neden gerekli olduğunun somut bir nedenidir.

Bu riskleri azaltmanın yolu, teknik kontrollerin yanında sözleşmesel kontrollerdir. Değerlendirmede, sağlayıcıyla yapılan sözleşmenin veri işleme, gizlilik, hizmet sürekliliği ve sorumluluk maddelerine atıf yapılır. Kritik bir sistemde, tek bir sağlayıcıya kilitlenmemek için bileşenleri değiştirilebilir tutmak (soyutlama katmanı) hem teknik hem stratejik bir azaltma önlemidir. Verinin kurum dışına hiç çıkmaması gereken durumlarda, dış sağlayıcı yerine kendi altyapınızda çalışan bir modele geçmek bir seçenektir; bu tercihin maliyet ve kontrol dengesini on-premise ve egemen AI altyapısı yazısında ele alıyoruz. Sağlayıcı riski, "sistem bizim ama beyni başkasının" gerçeğini belgeye dürüstçe yazmayı gerektirir.

Bir ai risk değerlendirmesinin en olgun ama en az konuşulan parçası, "hangi riski kabul ediyoruz, hangisini kabul etmiyoruz" çizgisidir. Bu çizgiye risk iştahı denir ve onu belirlemeden yapılan değerlendirme yarım kalır: riskleri listelersiniz ama hangisinin "yeterince düşük" olduğuna karar verecek bir ölçütünüz olmaz. Risk iştahı, kurumun "buraya kadar tamam, buradan sonrası kabul edilemez" dediği yerdir ve bu karar teknik değil, yönetsel bir karardır.

Risk iştahı sektöre, kurum kültürüne ve sistemin etkisine göre değişir. Geri alınabilir, düşük etkili bir iç verimlilik aracında iştah yüksek olabilir — bazı hatalar kabul edilir, çünkü maliyeti düşüktür ve öğrenme değeri yüksektir. Müşteriye veya çalışana doğrudan dokunan, geri alınamaz bir kararda ise iştah çok düşüktür — burada "belki çalışır" yeterli değildir. İyi bir değerlendirme, bu iştahı soyut bırakmaz; her risk kategorisi için bir kabul eşiği tanımlar ve o eşiği aşan riskleri "canlıya almadan önce azalt" olarak işaretler.

Kabul edilebilir eşiği somutlaştırmanın pratik yolu, artık risk beyanını bir kabul kararına bağlamaktır. Her artık risk satırının yanında "bu risk kabul edilebilir mi, evetse kim kabul ediyor" sorusu yanıtlanır. Eğer bir artık risk, tanımlı iştahın üzerindeyse iki seçenek vardır: ya ek azaltma önlemleri ekleyip riski eşiğin altına indirmek, ya da riski daha yüksek bir yetki seviyesine taşıyıp bilinçli bir istisna kararı almak. Kritik olan, hiçbir riskin "sessizce kabul edilmiş" olmamasıdır; her kabul, bilinçli, kayıtlı ve sahibi belli olmalıdır. Risk iştahını baştan tanımlamak, onay sürecini hızlandırır çünkü her tartışmayı sıfırdan yapmak yerine önceden anlaşılmış bir çizgiye başvurulur.

Soyut ilkeleri somutlaştırmak için tipik bir örneği izleyelim. Bir kurumun müşteri destek ekibi için, ürün dokümantasyonu üzerinden yanıt üreten bir asistan kuracağını varsayalım. Bu örnek gerçek bir kurumu değil, sahada sık gördüğüm deseni temsil eder; amaç, bir ai risk değerlendirmesinin adımlarını canlı bir bağlamda göstermektir. Ekip, sistemi canlıya almadan önce kısa bir çalıştayda toplanır: teknik sahip, destek ekibi lideri (iş sahibi) ve bir gizlilik temsilcisi.

Önce sistemi tanımlarlar. Asistan, müşteri sorusunu alır, ürün dokümantasyonundan ilgili parçaları getirir ve bir yanıt üretir; çıktıyı önce destek uzmanı görür, sonra müşteriye iletir. Bu tanım tek başına kritik bir kararı ortaya çıkarır: asistan doğrudan müşteriye mi yazacak, yoksa uzman bir ara katman mı olacak? Ekip, başlangıçta uzmanın araya girmesine karar verir — bu, insan gözetimini mimariye baştan gömen bir tercihtir ve pek çok riski azaltır. Sonra veriye bakarlar: asistan, geçmiş destek kayıtlarına da erişmeli mi? Bu kayıtlar müşteri kişisel verisi içerdiği için, ekip erişimi yalnızca ürün dokümantasyonuyla sınırlamaya karar verir; kişisel veri boyutu böylece baştan daraltılır.

Risk senaryolarını çıkarırken risk aileleri kontrol listesini kullanırlar. En yüksek skorlu senaryo şudur: asistan, dokümantasyonda olmayan bir bilgiyi uydurur ve uzman fark etmeden müşteriye iletir. Bunun için iki azaltma önlemi koyarlar: asistan yalnızca getirilen belgeye dayanacak ve kaynağını gösterecek (önleyici); uzman ekranında "bu yanıt şu belgeye dayanıyor" uyarısı olacak (tespit edici). İkinci yüksek skorlu senaryo, bir müşterinin dolaylı yoldan başka bir müşterinin bilgisini elde etmesidir; buna karşı erişim kontrolü ve girdi doğrulama koyarlar. Her senaryonun yanına kalan artık riski dürüstçe yazarlar: "kaynak gösterimine rağmen uzman yanlış yanıtı onaylayabilir; bu artık riski kabul ediyor ve ilk üç ay yakın izliyoruz."

Son olarak onay ve izleme adımını tasarlarlar. Belgeyi teknik sahip hazırlar; iş sahibi kabul edilen artık riski, gizlilik temsilcisi kişisel veri kararını onaylar. İzleme için üç metrik seçerler: uzmanın asistan yanıtını düzeltme oranı, müşteri şikayeti ve kaynak gösterilmeyen yanıt sayısı. Yeniden değerlendirme tetikleyicisi olarak "asistanın müşteriye doğrudan yazması" senaryosunu işaretlerler — bu değişiklik olursa değerlendirme baştan yapılacaktır. Bu mini vaka, risk dokümanı hazırlama sürecinin nasıl birkaç saatlik odaklı bir çalışmayla somut bir çıktıya dönüştüğünü gösterir; belge uzun değildir ama dürüst ve kullanışlıdır.

Bu vakadan çıkan üç ders, çoğu ai risk değerlendirmesi için geçerlidir. Birincisi, en değerli kararlar teknik değil mimari kararlardır: "uzman araya girsin" ve "kişisel veriye erişme" kararları, sonradan eklenecek onlarca kontrolden daha fazla risk azalttı. İkincisi, dürüst artık risk beyanı ekibi rahatsız etmedi, tersine güven verdi; çünkü riski gizlemek yerine adını koyup sahiplendiler. Üçüncüsü, doğru yeniden değerlendirme tetikleyicisini baştan yazmak, geleceği bugünden güvence altına aldı — sistem büyüdüğünde değerlendirmenin de büyüyeceği belliydi. Bu üç ders, risk dokümanı hazırlama işinin özünü gösterir: karmaşık formlar değil, doğru soruları doğru sırada sormak.

Bir ai risk değerlendirmesinin en büyük başarısızlık nedeni, onu projenin sonunda, canlıya almadan hemen önce yapılan bir "onay kutusu" haline getirmektir. Bu noktada değerlendirme, tasarımı etkileyemeyecek kadar geç gelir; ekip zaten sistemi kurmuştur ve risk bulguları ya görmezden gelinir ya da pahalı yeniden çalışmaya yol açar. Doğru yaklaşım, değerlendirmeyi tek bir kapıya değil, projenin yaşam döngüsüne yaymaktır. Risk düşüncesi ne kadar erken başlarsa, o kadar ucuz ve etkilidir.

Pratik bir gömme deseni şöyledir. Fikir aşamasında, hafif bir "risk taraması" yapılır: bu sistem hangi risk profiline giriyor, kişisel veri var mı, karar mı üretiyor? Bu tarama, projenin baştan doğru derinlikte planlanmasını sağlar. Tasarım aşamasında, risk değerlendirmesinin ilk taslağı çıkarılır ve bulgular mimariyi etkiler — örneğin insan gözetimi bir sonradan eklenti değil, tasarımın parçası olur. Geliştirme aşamasında, azaltma önlemleri kod olarak hayata geçirilir ve doğrulanır. Canlıya alma aşamasında, belge onay sürecinden geçer ve izleme kurulur. Canlı yaşam boyunca ise yeniden değerlendirme tetikleyicileri devreye girer.

Bu gömme, değerlendirmeyi bir engelden bir yardımcıya dönüştürür. Ekip riski erken görürse, onu ucuza azaltır; geç görürse, pahalıya öder veya görmezden gelir. Ayrıca değerlendirmeyi yaşam döngüsüne yaymak, onu tek bir kişinin sırtından alıp sürecin doğal bir parçası yapar — böylece "kimin işi" tartışması ortadan kalkar. Olgun kurumlar, risk değerlendirmesini bir kapı bekçisi gibi değil, bir tasarım disiplini gibi kullanır; tıpkı güvenlik ve kalitenin yaşam döngüsüne gömülmesi gibi. Bu disiplini kurumun genel yapay zeka yönetişimiyle birlikte inşa etmek için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin risk düşüncesini kazanması için kurumsal eğitim seçeneklerini değerlendirebilirsiniz.

Kurumlar sıklıkla sorar: bir ai risk değerlendirmesi ile veri koruma etki değerlendirmesi (KVKK bağlamında sıkça anılan DPIA benzeri değerlendirme) aynı şey midir, yoksa iki ayrı belge mi tutmalıyız? Cevap, ikisinin farklı ama örtüşen amaçlar taşıdığıdır. Veri koruma etki değerlendirmesi, odağını kişisel verinin işlenmesinin bireyin hak ve özgürlükleri üzerindeki etkisine daraltır; ai risk değerlendirmesi ise daha geniştir ve doğruluk, güvenlik, otomasyon, süreklilik gibi kişisel veriyle sınırlı olmayan tüm riskleri kapsar.

Pratikte iki belge büyük ölçüde konuşur ve akıllı bir yaklaşım onları birbirini besleyecek şekilde tasarlamaktır. Sisteminiz kişisel veri işliyor ve yüksek riskli bir işleme yapıyorsa, veri koruma etki değerlendirmesi zaten bir zorunluluk olabilir; bu durumda ai risk değerlendirmesinin veri bölümü, o etki değerlendirmesinin bulgularını içine alır veya ona atıf yapar. Tersi de geçerlidir: veri değerlendirmesi, yapay zekaya özgü riskleri (halüsinasyon, model yanlılığı) tek başına ele almaz; işte bu boşluğu ai risk değerlendirmesi doldurur.

Doğru kurgu, çift kayıt tutup ikisini senkron dışı bırakmak değil, tek bir tutarlı yapı içinde her ikisinin gereksinimlerini karşılamaktır. Kurum, kendi bağlamına göre ya tek bir birleşik belge ya da birbirine atıf yapan iki belge seçebilir; kritik olan, kişisel veri boyutunun hiçbir belgede eksik kalmamasıdır. Bu tercih hukuki sonuçlar taşıdığı için, kurumun hukuk ve uyum birimiyle birlikte kararlaştırılmalıdır; bu yazı bilgilendirme amaçlıdır ve hukuki tavsiye yerine geçmez. KVKK bağlamındaki güncel tartışmaları KVKK ve yapay zeka tartışmaları yazısında; kişisel veri kavramını kişisel veri nedir yazısında ele alıyoruz.

İzleme bölümünü somutlaştırmak için, bir ai risk değerlendirmesinin canlı yaşamda hangi metriklere bakması gerektiğini netleştirmek gerekir. "İzliyoruz" demek yeterli değildir; neyi, hangi eşikle ve kime raporlayarak izlediğiniz belgede yazılı olmalıdır. İyi seçilmiş bir metrik seti, bir sorunun sessizce büyümesini erken yakalar; kötü seçilmiş veya hiç olmayan metrikler ise ilk uyarıyı bir olay patladığında verir.

Metrikleri dört gruba ayırmak pratiktir. Kalite metrikleri: çıktı doğruluğu, hata oranı, kaynak gösterilmeyen yanıt oranı, kullanıcı düzeltme sıklığı. Bu grup, sistemin işini ne kadar iyi yaptığını ve zamanla bozulup bozulmadığını gösterir. Gözetim metrikleri: insana devir sıklığı, devredilen kararların ne kadarının değiştirildiği, itiraz sayısı ve sonucu. Bu grup, insan gözetiminin gerçekten çalışıp çalışmadığını ölçer — eğer insan hiçbir kararı değiştirmiyorsa, gözetim göstermelik olabilir.

Güvenlik ve uyum metrikleri: anormal erişim denemeleri, prompt injection şüpheli girdileri, kişisel veri sızıntısı uyarıları, erişim ihlali sayısı. İşletme metrikleri: gecikme, maliyet, kullanım hacmi, kullanıcı memnuniyeti. Her metrik için bir normal aralık ve bir uyarı eşiği tanımlanır; eşik aşıldığında kimin haberdar olacağı ve ne yapacağı yazılır. Bu metriklerin üretimde nasıl toplanıp izlendiğinin operasyonel disiplinini LLMOps nedir yazısında ele alıyoruz. Ölçülmeyen bir risk, yönetilemeyen bir risktir; metrik seçimi, ai risk değerlendirmesini kağıttan canlı bir yönetim aracına çeviren köprüdür.

Tek bir sistem için iyi bir ai risk değerlendirmesi yazmak bir başarıdır; ama olgun bir kurum, onlarca yapay zeka sistemini bir arada yönetmek zorundadır. İşte bu noktada iki disiplin devreye girer: versiyonlama ve risk kaydı (envanter). Bunlar olmadan, tek tek iyi yazılmış belgeler bile zamanla dağılır ve kurum, "hangi sistemde hangi risk var, hangi belge güncel" sorusuna cevap veremez hale gelir.

Versiyonlama, her belgenin bir sürüm numarası, tarihi ve değişiklik günlüğü taşımasıdır. Bir değerlendirme güncellendiğinde, neyin neden değiştiği kaydedilir ve önceki sürümler saklanır. Bu, hem denetimde "o karar ne zaman, hangi bilgiyle alındı" sorusunu yanıtlar hem de bir sorun çıktığında geriye dönük izlenebilirlik sağlar. Versiyonsuz bir belge, sürekli değişen ama hiçbir anını hatırlamayan bir sistemdir; güvenilmezdir.

Risk kaydı ise kurumdaki tüm yapay zeka sistemlerinin ve onların risk değerlendirmelerinin merkezi bir envanteridir. Bu envanter şu soruları tek bakışta yanıtlar: Hangi sistemler canlıda? Her birinin risk profili ne? En son ne zaman değerlendirildi ve bir sonraki gözden geçirme ne zaman? Hangi yüksek riskli açık maddeler var? Bu envanter, dağınık belgeleri yönetilebilir bir portföye dönüştürür ve yönetime kurumun toplam yapay zeka riskine dair bütünsel bir görünüm verir. Olgun bir yapay zeka yönetişimi, tek tek belgelerden değil, bu envanterden ve onu besleyen süreçten doğar. Kurumunuz için böyle bir risk kaydı ve değerlendirme çerçevesi kurmak istiyorsanız yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu disiplini kazanması için kurumsal eğitim seçeneklerini değerlendirebilirsiniz.

Yapay zeka sistemlerinin en sinsi risklerinden biri, doğru bir karar üretseler bile o kararı gerekçelendirememeleridir. Bir model bir başvuruyu reddettiğinde "neden reddedildi" sorusuna net bir cevap veremiyorsa, bu bir kara kutu riskidir ve bir ai risk değerlendirmesinin açıkça ele alması gereken bir boyuttur. Özellikle bireyi etkileyen kararlarda açıklanabilirlik, hem etik hem de düzenleyici açıdan giderek daha fazla beklenen bir özelliktir.

Açıklanabilirlik riski iki düzeyde ortaya çıkar. Birincisi, kullanıcıya veya karardan etkilenen kişiye yönelik açıklamadır: bir kişi hakkında olumsuz bir karar verildiğinde, o kişinin makul bir gerekçe görme ve itiraz edebilme hakkı vardır. Sistem bu gerekçeyi üretemiyorsa, itiraz kanalı da işlevsiz kalır. İkincisi, kurum içi denetime yönelik açıklamadır: bir denetçi veya yönetici, sistemin belirli bir kararı neden verdiğini anlayabilmelidir. Bu iki düzey, değerlendirmenin insan gözetimi ve onay bölümleriyle doğrudan bağlantılıdır.

Değerlendirmede açıklanabilirliği ele almanın pratik yolu, her karar tipi için "bu karar nasıl gerekçelendirilecek" sorusunu yanıtlamaktır. Bazı sistemlerde model, kararına dayanak olan belgeyi veya kuralı gösterebilir; bazılarında ise kararın ardındaki mantık opaktır ve bu durumda ek kontroller (insan gözden geçirmesi, karar kayıtları, örnek denetimleri) gerekir. Kara kutu riski yüksek olan sistemlerde, çözüm her zaman modeli şeffaflaştırmak olmayabilir; bazen doğru karar, o sistemi yüksek etkili bir kararda hiç kullanmamak ya da mutlaka bir insanın gerekçeli onayına bağlamaktır. Açıklanabilirliği değerlendirmenin bir parçası yapmak, sistemin yalnızca "doğru" değil, aynı zamanda "hesap verebilir" olmasını sağlar; bu da güvenilir yapay zekanın temel taşlarından biridir. Temel kavramlar için sorumlu yapay zeka nedir yazısına bakabilirsiniz.

AI risk değerlendirmesi nasıl yazılır?

Bir ai risk değerlendirmesi altı bölümden ilerleyerek yazılır: sistem tanımı ve amaç, veri ve kişisel veri boyutu, risk senaryoları ve etki analizi, azaltma önlemleri, insan gözetimi, ve izleme ile onay süreci. Her bölüm iş dilinde ve iddiaları kanıta bağlayarak yazılır; teknik ekip doldurur ama iş sahibi, hukuk/uyum ve bilgi güvenliği birlikte onaylar. En sağlıklı başlangıç, doğru kişileri kısa bir çalıştayda toplayıp sistemi ve veriyi birlikte tanımlamak, sonra risk ailelerini tek tek tarayarak senaryoları çıkarmaktır.

AI risk değerlendirme dokümanında hangi bölümler olmalı?

Asgari bölümler şunlardır: kapak ve versiyon; yönetici özeti; sistem tanımı ve amaç; kapsam ve sınırlar; veri ve kişisel veri envanteri; risk senaryoları ve etki analizi tablosu; azaltma önlemleri ve artık risk beyanı; insan gözetimi ve devir eşikleri; izleme, metrikler ve olay yönetimi; yeniden değerlendirme tetikleyicileri; roller ve onaylar. En sık atlanan bölümler artık risk beyanı, izleme planı ve yeniden değerlendirme tetikleyicileridir; bunlar olmadan belge canlı bir kayıt değil, bir kerelik formalite olur.

AI risk değerlendirmesini kim hazırlar ve kim onaylar?

Dokümanı genellikle sistemin teknik sahibi hazırlar; ama tek başına onaylayamaz. Onay süreci katmanlıdır: iş sahibi kullanım amacını ve kabul edilen artık riski; veri/gizlilik sorumlusu kişisel veri boyutunu; bilgi güvenliği erişim ve güvenlik kontrollerini; hukuk/uyum düzenleyici uygunluğu onaylar. Yüksek riskli veya müşteriye/çalışana doğrudan dokunan sistemlerde onay bir risk komitesine veya yönetim seviyesine çıkar. Temel ilke: riski kabul eden kişi, o riskin sonucundan sorumlu olabilecek yetki seviyesinde olmalıdır.

Etki analizi risk değerlendirmesinde nasıl yapılır?

Etki analizi iki eksende yürür: bir senaryonun gerçekleşme olasılığı ve gerçekleşirse yaratacağı etki. Etki; birey, kurum ve topluluk düzeyinde ayrı ayrı düşünülür. Her senaryoya düşük/orta/yüksek gibi bir olasılık ve etki değeri verilir; ikisinin birleşimi risk skorunu belirler. Amaç kesin bir sayı üretmek değil, riskleri karşılaştırılabilir kılıp önceliklendirmektir. İyi bir etki analizi, düşük olasılıklı ama yıkıcı "kuyruk risklerini" ayrıca yazar; çünkü en tehlikeli senaryolar genellikle ortalama bir skorun arkasında gizlenenlerdir.

Azaltma önlemleri belgede nasıl yazılır?

Her risk satırının karşısına en az bir azaltıcı kontrol yazılır ve bu kontrolün riski olasılık mı yoksa etki mi ekseninde düşürdüğü belirtilir. Azaltma önlemleri önleyici (erişim kısıtı, veri maskeleme, girdi doğrulama), tespit edici (izleme, anomali uyarısı, denetim kaydı) ve düzeltici (geri alma, insana devir, acil durdurma) olarak sınıflanır. Kontrolden sonra kalan artık risk mutlaka yazılır. Her kontrolün bir sahibi ve bir doğrulama yöntemi olmalı; belirsiz ifadeler yerine "X eşiğinin altındaki kararlar Y rolüne düşer" gibi somut kurallar tercih edilir.

AI risk değerlendirmesi ne sıklıkla güncellenmeli?

Doküman canlı bir kayıttır ve iki tür tetikleyiciyle güncellenir. Takvimsel tetikleyici en az yılda bir düzenli gözden geçirmedir. Olay bazlı tetikleyici ise model veya sağlayıcı değişimi, yeni veri kaynağı eklenmesi, kullanım amacının genişlemesi, yeni bir düzenlemenin yürürlüğe girmesi veya ciddi bir olay/şikayet yaşanmasıdır. Bu tetikleyiciler dokümanın içine açıkça yazılmalı ki güncelleme kişilerin hafızasına değil sürece bağlı olsun. Güncellenmeyen bir risk değerlendirmesi en tehlikeli belge türüdür; kurum kendini korunmuş sanır ama belge gerçeği yansıtmaz.

Kısaca, bir ai risk değerlendirmesi nasıl hazırlanır sorusunun cevabı: sistemi net tanımlayan, veriyi ve kişisel veri boyutunu envanterleyen, risk senaryolarını ve etki analizini somutça yazan, her riske azaltma önlemleri ve kalan artık riski atayan, insan gözetimini somut eşiklerle tanımlayan, izleme ve olay yönetimini planlayan ve katmanlı bir onay sürecinden geçen bir doküman hazırlamak. Bu belge bir form değil bir karar kaydıdır; teknik ekip doldurur, iş/hukuk/güvenlik birlikte onaylar ve sistem değiştikçe güncellenir.

En önemli mesaj şudur: iyi bir risk dokümanı hazırlama işi, mükemmel bir kağıt üretmek değil, dürüst bir düşünme süreci yürütmektir. En sık atlanan bölümler — artık risk beyanı, en kötü durum, yeniden değerlendirme tetikleyicileri — tam da belgeyi değerli kılan, "kötü haber" taşıyan kısımlardır. Onları yazmaktan kaçınmayın; kurumu koruyan belge, iyimser olan değil, gerçekçi olandır.

Son bir hatırlatma: bir ai risk değerlendirmesi hiçbir zaman tek başına bir hedef değildir; amaç, sorumlu ve güvenilir bir yapay zeka kullanımıdır. Belge, o amacın hizmetindeki bir araçtır. Bu yüzden değerlendirmeyi mükemmelleştirmeye harcanan enerji, bir noktadan sonra gerçek riskleri azaltmaya harcanan enerjiye dönüşmelidir. En iyi risk değerlendirmesi, en kalın olan değil, kararları gerçekten etkileyen ve kurumu somut olarak daha güvenli kılan olandır. Küçük bir sistemle başlayın, dürüstçe yazın, canlıya alın, izleyin ve öğrendikçe güncelleyin; bu döngü, kurumunuzu hem bugünün risklerine hem de yarının düzenlemelerine karşı adım adım olgunlaştırır. Bu yolculukta doğru şablon, doğru roller ve doğru kültür bir araya geldiğinde, risk değerlendirmesi bir yük olmaktan çıkıp bir rekabet avantajına dönüşür. Temel kavramlar için sorumlu yapay zeka nedir ve kişisel veri nedir yazılarına bakabilir; kurumunuza özel bir risk değerlendirme çerçevesi ve şablonu kurmak için yapay zeka danışmanlığı ile başlayabilir, ekipleriniz için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.