Saha Notu: Regüle Sektörde AI Onay Süreçlerinde Karşılaştıklarım

Regüle sektör AI onayı, banka, sigorta ve sağlık gibi denetime tabi kurumlarda bir yapay zeka çözümünün üretime alınmadan önce bilgi güvenliği, uyum, hukuk ve model yönetişimi katmanlarından sırayla geçmesi gereken çok aşamalı bir onay sürecidir. Bu saha notu, regüle sektör AI onayı süreçlerinde tekrar tekrar karşılaştığım katmanları, her katmanın istediği belgeleri ve onay süresini kısaltan pratikleri tek bir çerçevede topluyor.

Deneyimimin gösterdiği tek cümlelik ders şudur: regüle sektörde bir projeyi durduran şey nadiren modelin kendisidir; asıl darboğaz, onay katmanlarının istediği belgelerin hazır olmaması ve katmanların gereksiz yere sıraya dizilmesidir. Aşağıdaki gözlemler bu katmanları isimlendirir ve her biri için pratik hazırlığı verir. Not: buradaki değerlendirmeler bilgilendirme amaçlıdır ve hukuki tavsiye değildir; kurumunuzun hukuk ve uyum birimiyle birlikte yürütülmelidir.

Bu saha notunu neden yazdığımı baştan söyleyeyim. Regüle sektörde çalışan ekiplerin bana en sık sorduğu soru "hangi modeli kullanmalıyız" değil, "bu proje neden aylardır onayda bekliyor" sorusudur. Teknoloji seçimi genellikle birkaç haftada çözülür; asıl zaman, çözümün üretime alınabilmesi için geçmesi gereken kurumsal onay katmanlarında harcanır. Regüle sektör AI onayı süreçlerinde tekrar tekrar aynı desenle karşılaştım: iyi tasarlanmış bir çözüm, kötü hazırlanmış bir onay dosyası yüzünden aylarca bekleme odasında kalır. Bu yazı, o bekleme odasını mümkün olduğunca boşaltmak için tuttuğum notların derli toplu halidir.

İkinci bir çerçeve uyarısı: bu bir hukuki ya da uyum danışmanlığı metni değildir. Amacım, regüle sektör AI onayı sürecinin nasıl işlediğini bir proje yöneticisinin gözünden anlaşılır kılmak, hangi katmanların hangi belgeyi neden istediğini açıklamak ve onay süresini kısaltan pratik hamleleri paylaşmaktır. Kurumunuzun kendi mevzuatı, iç politikaları ve düzenleyici beklentileri her zaman önceliklidir; bu notu o beklentilerin yerine değil, onlara hazırlanırken bir yol haritası olarak kullanın. Anlatının tamamı birinci tekil şahıs bir saha gözlemidir; belirli bir kuruma, sayıya ya da vakaya değil, farklı projelerde tekrar eden desenlere dayanır.

Tanım

Regüle sektör AI onayı

Banka, sigorta, sağlık ve kamu gibi denetime tabi sektörlerde bir yapay zeka çözümünün üretime alınmadan önce geçmesi gereken çok katmanlı kurumsal onay süreci. Bilgi güvenliği gözden geçirmesi, uyum/KVKK gözden geçirmesi, hukuk değerlendirmesi, model yönetişimi ve iş/sponsor onayı katmanlarından oluşur; her katman kendi belgesini ister ve zincirdeki en yavaş katman toplam onay süresini belirler.

Ayrıca: regüle sektör onayı, AI uyum onayı, kurumsal yapay zeka onay süreci, güvenlik ve uyum onayı

Regüle sektör AI onayı tek bir imza değil, sıralı katmanlardan oluşan bir zincirdir. Saha gözlemim şu: kurumlar farklı isimler kullansa da katmanlar hemen her yerde aynıdır — bilgi güvenliği, uyum/KVKK, hukuk, model yönetişimi ve iş/sponsor onayı. Her katmanın kendi sorusu, kendi paydaşı ve kendi istediği belgesi vardır. Zincir mantığı acımasızdır: toplam onay süresini en hızlı katman değil, en yavaş katman belirler.

Bu haritayı erken çıkarmayan ekipler, süreci "tek bir onay" sanarak başlar ve her yeni katmanda sürprizle karşılaşır. Bu sürpriz maliyetlidir: her yeni katman, hazırlanmamış bir belge ve tanınmayan bir paydaş demektir, dolayısıyla ekip her seferinde baştan hazırlanmak zorunda kalır. Olgun yaklaşım tersidir: daha ilk günde tüm katmanları, sahiplerini ve isteyecekleri belgeleri listelemek. Bu harita, sürecin hangi noktada kimin masasında beklediğini görünür kılar ve "proje neden ilerlemiyor" sorusunun cevabını somutlaştırır. Katmanların büyük çoğunluğunun teknoloji değil yönetişim sorusu sorduğuna dikkat edin; bu yüzden AI governance nedir ve sorumlu yapay zeka nedir çerçeveleri bu haritanın omurgasını oluşturur.

Katmanların sırası kurumdan kuruma değişebilir, ama bir kural neredeyse hep geçerlidir: bir katman ötekinin çıktısını girdi olarak bekler. Model yönetişimi katmanı, güvenlik ve uyumun tanımladığı sınırları varsayar; iş/sponsor onayı ise diğer tüm katmanların yeşil ışığını bekler. Bu bağımlılıkları baştan görmek, hangi katmanların gerçekten sıralı, hangilerinin ise paralel yürütülebileceğini ayırt etmenizi sağlar — ki bu ayrım, onay süresini kısaltmanın anahtarıdır.

Katmanlar neden hemen her kurumda aynı

Farklı bankalarda, sigorta şirketlerinde ve sağlık kuruluşlarında çalışırken kullanılan terminoloji değişse de altta yatan mantığın hep aynı olduğunu gördüm. Bunun nedeni tesadüf değil: her katman, kurumun bir riskini yönetmek için vardır. Bilgi güvenliği katmanı teknik riski, uyum katmanı mevzuat riskini, hukuk katmanı sözleşmesel ve sorumluluk riskini, model yönetişimi katmanı ise modelin yanlış davranma riskini yönetir. Bir kurum bu risklerden herhangi birini görmezden gelemeyeceği için, isim ne olursa olsun karşılık gelen katman mutlaka bir yerde belirir. Regüle sektör AI onayı sürecine yeni giren bir ekip için en pratik zihinsel model şudur: "Hangi risk kimin masasında yönetiliyor?" Bu soruyu her katman için yanıtladığınızda, kurumun organizasyon şemasından bağımsız olarak onay haritasının iskeletini çıkarmış olursunuz.

Bir başka gözlemim, katman sayısının kurumun büyüklüğüyle değil, işlenen verinin hassasiyetiyle orantılı olmasıdır. Küçük bir fintech ile büyük bir banka aynı müşteri verisini işliyorsa, ikisi de benzer bir uyum gözden geçirmesi ve güvenlik onayı katmanından geçer; fark, büyük kurumda bu katmanların daha fazla paydaş ve daha resmi bir sürece bağlanmasıdır. Dolayısıyla "biz küçük bir ekibiz, bu kadar katmana gerek yok" varsayımı regüle sektörde çoğu zaman yanıltıcıdır; katmanları atlamak değil, her katmanı hafif ama eksiksiz geçmek doğru stratejidir.

Zincir mantığı: neden en yavaş katman kazanır

Onay sürecini bir üretim hattı gibi düşünmek yararlıdır, ama tek bir farkla: burada paralel çalışmayan bir hatta toplam süre, katmanların sürelerinin toplamıdır. Beş katmanın her biri ikişer hafta sürüyorsa ve bunları sırayla yürütüyorsanız, en iyi ihtimalle on hafta harcarsınız — üstelik hiçbir katman takılmasa bile. Gerçekte katmanlar takılır: bir belge eksik çıkar, bir paydaş izinli olur, bir toplantı ertelenir. Bu yüzden onay süresini uzatan asıl mekanizma, tek bir katmanın yavaşlığı değil, katmanların birbirini beklemesidir. Bu zincir mantığını kavradığınızda, iyileştirme stratejiniz de netleşir: ya katmanları paralelleştirerek toplamı azaltırsınız, ya da her katmanı önden hazırlıkla hızlandırarak tek tek süreleri kısaltırsınız. En iyi ekipler ikisini birden yapar.

Bu haritayı kurumsal düzeyde standartlaştırmanın da büyük getirisi vardır. İlk projede haritayı sıfırdan çıkaran bir ekip, ikinci projede aynı katmanları, aynı sahipleri ve aynı belge listesini büyük ölçüde hazır bulur. Bu yüzden regüle sektörde AI'yı ölçeklemek isteyen kurumlara ilk önerim, onay haritasını bir kez düzgün çıkarıp kurumsal bir varlığa dönüştürmeleridir; bu, projelerin AI dönüşümündeki organizasyon tasarımıyla da doğrudan ilişkilidir ve merkezi bir yapının bu haritayı nasıl sahiplendiğini AI dönüşümünde organizasyon tasarımı yazısında ele alıyoruz.

Aşağıdaki tablo, en sık karşılaştığım katmanları, her birinin tipik olarak istediği belgeyi ve o belgeyi zamanında hazırlayacak önden hazırlığı bir arada gösterir. Bir onay sürecine girmeden önce bu tabloyu doldurmak, ilerideki gecikmelerin çoğunu baştan eler.

Onay katmanı × istenen belge × önden hazırlık

Onay katmanı	Tipik istenen belge	Önden hazırlık
Bilgi güvenliği	Mimari diyagram, veri akışı, erişim matrisi, sızma testi	Veri sınıflandırması + erişim kontrolü baştan tasarlanır
Uyum / KVKK	Veri envanteri, aydınlatma metni, etki analizi (DPIA), saklama politikası	Kişisel veri envanteri + amaçla sınırlılık netleştirilir
Hukuk	Tedarikçi sözleşmesi, sorumluluk ve fikri mülkiyet analizi	Model/tedarikçi sözleşme şablonu hazır tutulur
Model yönetişimi	Model kartı, değerlendirme (eval) raporu, insan gözetimi planı	Eval çerçevesi + guardrail tanımı önden kurulur
İş / sponsor	İş gerekçesi, ROI, pilot kabul kriterleri	Temel çizgi (baseline) + başarı metriği tanımlanır

Bu tabloyu bir projeye başlarken doldurmanın bir yan faydası da vardır: hangi belgelerin zaten elinizde olduğunu, hangilerini üretmeniz gerektiğini net gösterir. Çoğu ekip, aslında istenen belgelerin bir kısmına başka amaçlarla hazırladıkları dokümanlar içinde zaten sahiptir; bunları onay diline çevirmek, sıfırdan üretmekten çok daha hızlıdır. Tabloyu doldururken "bu belge var mı, yoksa hangi mevcut belgeden türetilebilir" sorusunu sormak, hazırlık yükünü çoğu zaman beklenenden hafif kılar. Regüle sektör AI onayı sürecine bu envanterle girmek, ekibin ilk günden somut bir yol haritası edinmesini sağlar.

Bir onay haritası ancak her katmanın bir sahibi olduğunda işe yarar. Saha gözlemimde en sık rastladığım gecikme türü, teknik bir eksiklik değil, "bu katmanın onayını kimin vereceğinin belli olmamasıdır." Dosya, karar verecek kişinin masasına ulaşmadan haftalarca ara katmanlarda dolaşır. Bu yüzden onay haritasını çıkarırken her katmanın yanına iki isim yazarım: o katmanın belgesini hazırlayacak kişi ve o katmanın onayını verecek kişi. Bu iki rolü ayırmak önemlidir; belgeyi hazırlayan çoğu zaman teknik ekipten biriyken, onayı veren o katmanın kurumsal sahibidir.

Sahipliği netleştirmenin en pratik yolu, basit bir sorumluluk tablosudur: her katman için kim hazırlar, kim gözden geçirir, kim onaylar ve kim bilgilendirilir. Bu tablo, "proje neden ilerlemiyor" sorusunu somut bir isme bağlar ve dosyanın nerede beklediğini görünür kılar. Regüle sektörde bir yapay zeka çözümünün onayı çoğu zaman beş-altı farklı birimi ilgilendirdiği için, bu tablo olmadan koordinasyon hızla dağılır. Onay koordinatörünün ilk işi bu tabloyu doldurmak ve her katmanın sahibini teyit etmektir.

Sahiplikte ikinci bir incelik, onay yetkisinin doğru düzeyde olmasıdır. Bir katmanın belgesini kıdemli bir uzman hazırlayabilir, ama onayı vermeye yetkili değilse süreç yine bir üst masaya taşınır. Bu "yetki atlaması" gecikmeyi büyütür. Bu yüzden haritayı çıkarırken her katman için "bu onayı kim verebilir" sorusunu net yanıtlamak, sürecin ortasında ortaya çıkacak yetki boşluklarını baştan kapatır. Kurumun karar yapısını erken anlamak, teknolojiyi anlamak kadar belirleyicidir.

Üçüncü incelik, sahipliğin projeyle birlikte devam etmesidir. Onay, üretime alma anında bitmez; çözüm yaşadıkça her katmanın sahibi, kendi alanındaki değişiklikleri izlemeye devam eder. Model güncellendiğinde model yönetişimi sahibi, yeni bir veri kaynağı eklendiğinde uyum sahibi devreye girer. Bu süreklilik, onayı bir kerelik bir kapı olmaktan çıkarıp bir yönetişim ilişkisine dönüştürür — ki regüle sektörde sürdürülebilir olan da budur.

Katmanların çoğunda ilk sırada bilgi güvenliği gelir ve genellikle en teknik olanıdır. Buradaki soru nettir: bu sistem verinizi nasıl işliyor, veri nereye akıyor, kimler erişiyor ve hangi açıkları taşıyor. Güvenlik ekibi mimari diyagram, veri akış şeması, erişim matrisi ve çoğu zaman bir sızma testi raporu ister. Güvenlik onayı çıkmadan, sonraki katmanların çoğu fiilen başlamaz; bu yüzden bu katmanı erken ve eksiksiz geçmek tüm süreci hızlandırır.

Saha gözlemim, en çok takılınan noktanın erişim kontrolü ve loglama olduğudur. Bir LLM tabanlı çözümde "kim hangi belgeyi görebilir" sorusu baştan tasarlanmamışsa, güvenlik ekibi haklı olarak süreci durdurur. Aynı şekilde, istem enjeksiyonu (prompt injection) gibi modele özgü riskler artık güvenlik incelemesinin standart parçasıdır; bu riskleri prompt injection nedir ve koruyucu katmanları guardrail nedir yazılarında ele alıyoruz. Güvenlik onayını hızlandırmanın yolu, bu belgeleri incelemeden önce değil, inceleme başvurusuyla birlikte sunmaktır.

Verinin kurum dışına çıkıp çıkmadığı da bu katmanın en hassas sorusudur. Bulut tabanlı bir modele veri gönderiliyorsa, güvenlik ekibi veri egemenliği ve barındırma konusunda ek güvence ister; on-prem bir kurulum bu soruyu büyük ölçüde ortadan kaldırır. İki seçeneğin dengesini on-premises yapay zeka vs bulut KVKK yazısında karşılaştırıyoruz; loglamanın KVKK boyutunu ise LLM loglama KVKK yazısında inceliyoruz. Barındırma tercihinin operasyonel sonuçlarını ise on-premise ve egemen AI altyapısı yazısında ayrıntılandırıyoruz; güvenlik onayı çoğu zaman bu iki yazının kesişimindeki soruları sorar.

Erişim kontrolü: güvenlik onayının en sık takıldığı yer

Güvenlik ekibinin bir LLM çözümünde ilk baktığı şey, kimin neye erişebildiğidir. Klasik bir uygulamada erişim kontrolü tablolarla, rollerle ve izinlerle nettir; oysa bir yapay zeka çözümünde model, birçok kaynaktan gelen bilgiyi tek bir yanıtta birleştirebildiği için "yetki sızıntısı" riski daha incedir. Bir kullanıcının normalde göremeyeceği bir belgenin içeriği, modele bağlam olarak verildiğinde dolaylı yoldan o kullanıcıya ulaşabilir. Güvenlik onayı sürecinde bu riski baştan ele almadıysanız, ekip haklı olarak süreci durdurur. Saha pratiğim, erişim matrisini yalnızca "kim uygulamaya girebilir" düzeyinde değil, "hangi kullanıcı hangi veri parçasını modele bağlam olarak sağlayabilir" düzeyinde tasarlamaktır. Bu ayrımı ilk toplantıda getiren ekipler, güvenlik onayının en zorlu sorusunu daha o gün cevaplamış olur.

Loglama ve denetim kaydı da bu katmanın ayrılmaz parçasıdır. Güvenlik ekibi, bir olay durumunda "kim, ne zaman, hangi veriyle ne sordu" sorusunun cevaplanabilmesini ister. Ancak burada bir gerilim vardır: her istem ve yanıtı loglamak denetimi kolaylaştırır ama aynı zamanda kişisel veriyi çoğaltarak uyum tarafında yeni bir yük yaratır. Bu yüzden loglama tasarımını güvenlik ve uyum katmanlarının ortak masasında yapmak, her iki tarafın da onayını hızlandırır. Güvenlik onayını hızlı geçmek isteyen ekiplere önerim, loglama politikasını bir "denetlenebilirlik" ve "veri minimizasyonu" dengesi olarak baştan yazmalarıdır.

Sızma testi ve modele özgü riskler

Sızma testi (penetration test) raporu, güvenlik onayının somut bir gereksinimidir ve genellikle bağımsız bir ekip tarafından yapılır. Klasik açıkların yanında, artık modele özgü saldırı yüzeyleri de test kapsamına girer: istem enjeksiyonu, veri sızdırma denemeleri, modelin yetkisiz eylemlere yönlendirilmesi. Bir ajan tabanlı çözümde bu yüzey daha da genişler, çünkü model yalnızca yanıt üretmez, araçları çağırır ve eylem alır. Ajanların hata durumlarını ve geri alma mekanizmalarını nasıl tasarladığımızı ajan iş akışlarında hata yönetimi ve geri alma yazısında ele alıyoruz; güvenlik ekibi tam da bu geri alma mekanizmalarının varlığını sorgular. Sızma testini onay sürecinin sonunda değil, mümkünse pilot aşamasında yaptırmak, güvenlik onayının en uzun sürebilecek kalemini erkene çeker ve toplam onay süresini belirgin biçimde kısaltır.

Son bir gözlem: güvenlik onayı bir "geç/kal" kapısı gibi görünse de, pratikte çoğu zaman bir "koşullu geçiş" üretir — yani ekip bazı iyileştirmeleri yapmayı taahhüt eder ve süreç şartlı olarak ilerler. Bu koşullu geçişleri net bir eylem listesine bağlamak, hem güvenlik ekibinin güvenini kazandırır hem de projenin diğer katmanlarda beklemeden ilerlemesini sağlar.

İkinci belirleyici katman uyum gözden geçirmesidir ve regüle sektörde çoğu zaman en kritik olanıdır. Buradaki soru teknik değil hukukidir: bu sistem KVKK'ya ve kurum politikasına uygun mu? Uyum ekibi kişisel veri envanteri, aydınlatma metni, etki analizini (DPIA) ve saklama/silme politikasını ister. Bir uyum gözden geçirmesinin en sık tıkandığı yer, kişisel verinin hangi amaçla işlendiğinin net tanımlanmamış olmasıdır; amaçla sınırlılık ilkesi baştan yazılmazsa süreç geri döner. Kişisel verinin kapsamını kişisel veri nedir, KVKK çerçevesini KVKK nedir yazısında ele alıyoruz.

Hukuk katmanı ise sorumluluk ve sözleşme tarafına bakar: model yanlış bir çıktı üretirse sorumluluk kimde, tedarikçi hangi taahhütleri veriyor, fikri mülkiyet ve veri kullanım hakları nasıl düzenlenmiş. Bu katman, tedarikçi sözleşmesi hazır ve net olduğunda hızla geçer; belirsiz olduğunda haftalarca sürer. Avrupa'ya hizmet veren kurumlar için EU AI Act ek bir yükümlülük katmanı getirir; çerçevesini EU AI Act nedir yazısında bulabilirsiniz. Bir yönetim sistemi standardı olarak ISO 42001 nedir de bu katmanın beklentilerini karşılamayı kolaylaştırır. KVKK boyutunun uçtan uca kontrol listesi için kapsamlı rehbere başvurmanızı öneririm; bu saha notu o rehberin dar ve pratik tamamlayıcısıdır. Yeniden hatırlatayım: bu bir hukuki tavsiye değildir.

Uyum gözden geçirmesinde amaçla sınırlılığın merkeziliği

Uyum gözden geçirmesi katmanında gördüğüm en yaygın tıkanma, çözümün "ne için" kullanıldığının bulanık kalmasıdır. Regüle sektörde bir yapay zeka çözümünün kişisel veri işlemesi tek başına sorun değildir; sorun, o işlemenin hangi meşru amaca dayandığının net yazılmamış olmasıdır. Uyum ekibi "bu model müşteri verisiyle ne yapıyor, çıktısı hangi kararı etkiliyor, bu amaç aydınlatma metniyle uyumlu mu" sorularını sorar. Amaç net değilse, saklama süresi, erişim kapsamı ve silme politikası da tanımlanamaz; dolayısıyla amaçla sınırlılık, uyum gözden geçirmesinin çözülmeden diğer her şeyin askıda kaldığı düğüm noktasıdır. Saha pratiğim, projeyi tanımlarken tek cümlelik bir "işleme amacı" ifadesi yazmak ve bunu tüm belgelerin başına koymaktır; bu tek cümle, uyum gözden geçirmesinin yarısını baştan çözer.

Regüle sektörde AI ile KVKK'nın kesişiminde güncel tartışma başlıkları da hızla değişiyor; otomatik karar verme, profilleme ve açık rıza gibi konuların onay masasına nasıl yansıdığını KVKK ve yapay zeka: güncel tartışma başlıkları yazısında topluyoruz. Uyum ekibinin gündemindeki soruları önceden bilmek, gözden geçirmeye hazırlıklı girmenin en pratik yoludur.

Hukuk katmanında en çok atlanan üç madde

Hukuk değerlendirmesinde ekiplerin en sık atladığı üç madde şudur. Birincisi, çıktının kullanım hakkı: modelin ürettiği içeriğin fikri mülkiyeti kime ait, kurum bunu serbestçe kullanabilir mi. İkincisi, eğitim verisi taahhüdü: tedarikçi, kuruma ait veriyi başka bir modeli eğitmek için kullanmayacağını taahhüt ediyor mu. Üçüncüsü, hizmet sürekliliği ve çıkış planı: tedarikçi hizmeti durdurursa kurum ne yapacak, veriler nasıl geri alınacak. Bu üç madde sözleşmede net değilse, hukuk katmanı süreci —haklı olarak— askıya alır. Bu maddeleri bir sözleşme şablonuna baştan gömmek, hukuk onayını en çok hızlandıran hazırlıktır.

Katmanların en yenisi ve regüle sektörde giderek ağırlaşanı model yönetişimidir. Bu katmanın sorusu ne teknik güvenliktir ne de mevzuat uyumu; soru şudur: bu model beklendiği gibi mi davranıyor, davranmadığında bunu kim, nasıl fark edecek ve ne yapacak. Model yönetişimi katmanı tipik olarak model kartını (modelin ne için tasarlandığını, sınırlarını ve bilinen risklerini özetleyen belge), bir değerlendirme (eval) raporunu ve insan gözetimi planını ister. Bu belgeler yoksa, kurumun çözümü üretime alması, davranışını sürekli izleyemeyeceği bir kutuyu üretime almak anlamına gelir — regüle sektörde bu kabul edilemez.

Değerlendirme raporu bu katmanın kalbidir. Bir modelin "iyi çalıştığını" iddia etmek yetmez; hangi görevlerde, hangi ölçütlerle ve hangi örneklerle test edildiğini gösteren bir eval çerçevesi gerekir. Saha gözlemim, ekiplerin çoğunun modeli öznel izlenimlerle değerlendirdiği ve model yönetişimi katmanına geldiğinde elinde ölçülebilir bir kanıt bulunmadığıdır. Oysa eval çerçevesini pilot aşamasında kurmak hem ürünü iyileştirir hem de bu katmanı hazır karşılar. Değerlendirme setinin nasıl kurulacağını ve hangi metriklerin anlamlı olduğunu ayrı yazılarımızda ele alıyoruz; buradaki saha dersi şudur: eval'i onay için sonradan üretilen bir belge değil, geliştirme sürecinin doğal bir çıktısı olarak kurun.

İnsan gözetimi planı ise "model hata yaptığında ne olur" sorusunun cevabıdır. Regüle sektörde tam otomatik karar, çoğu senaryoda kabul görmez; bu yüzden model yönetişimi katmanı, kritik kararlarda bir insanın döngüde olduğunu, hataların nasıl fark edildiğini ve geri alma mekanizmasının nasıl işlediğini görmek ister. Bu plan, sorumlu yapay zeka ilkelerinin somut kurumsal karşılığıdır; çerçevesini sorumlu yapay zeka nedir yazısında, kurumsal yönetişim boyutunu ise AI governance nedir yazısında ele alıyoruz. Model yönetişimi katmanını hafife alan ekipler, güvenlik ve uyumu geçtikten sonra burada beklenmedik biçimde takılır; bu katmanı da hazırlık paketinin bir parçası olarak baştan planlamak, o sürprizi ortadan kaldırır.

Teknik ve hukuki katmanların gölgesinde en çok küçümsenen, ama gecikmelerin şaşırtıcı biçimde büyük bölümünden sorumlu olan katman iş ve sponsor onayıdır. Bu katmanın sorusu basit görünür ama en zorudur: bu çözüm gerçekten bir iş problemini çözüyor mu ve kurum bunun için gereken bütçeyi, değişimi ve riski üstlenmeye hazır mı. İş/sponsor katmanı iş gerekçesini, temel çizgiyi (baseline) ve pilot kabul kriterlerini ister. Bu belgeler yoksa, diğer tüm katmanlar teknik olarak geçilse bile proje, "değer önermesi net değil" gerekçesiyle sonda takılır.

Saha gözlemim, bu katmanın gecikmesinin çoğu zaman bir sahiplik boşluğundan kaynaklandığıdır. Teknik ekip çözümü üretir, uyum ve güvenlik katmanları görüşünü verir, ama nihai onayı verecek iş sahibi (sponsor) sürece geç dahil olur ve elindeki dosyayı yeni görür. Bu geç görüş, çoğu zaman yeni sorular ve yeni beklentiler üretir; proje başa döner. Bu yüzden sponsoru sürecin sonunda değil başında masaya almak, bu katmanı hızlandırmanın en etkili yoludur. Sponsor, projenin risk sahibidir; onun sorularını önceden yanıtlamak, sondaki sürprizi baştan eritir.

İş gerekçesinin en güçlü hali, çözümün mevcut duruma göre ne kazandırdığını ölçülebilir bir temel çizgiyle göstermesidir. "Bu araç işleri hızlandırır" ifadesi zayıftır; "bu araç, şu görevi bugünkü sürenin belirgin bir kısmı kadar kısaltıyor ve pilotta şu kabul kriterini karşıladı" ifadesi güçlüdür. Değeri ölçmeden onay istemek, sponsordan kör bir güven istemek demektir; regüle sektörde bu güven nadiren verilir. Bu yüzden temel çizgiyi ve başarı metriğini pilot aşamasında tanımlamak, hem model yönetişimi hem iş/sponsor katmanını aynı anda besleyen çift işlevli bir hazırlıktır.

Onay sürecinin kalbi belgelerdir; her katman kendi belgesini ister ve o belge hazır değilse süreç durur. Bu bölümde, regüle sektör AI onayı süreçlerinde en sık istenen belgeleri tek tek ele alıyorum: her belge hangi soruya cevap verir, kim hazırlar ve neyi içerirse "hazır" sayılır. Bu belge rehberi, hazırlık paketinin içeriğini somutlaştırır.

Mimari diyagram ve veri akış şeması

Güvenlik katmanının ilk istediği belge, çözümün nasıl kurulduğunu ve verinin nasıl aktığını gösteren bir mimari diyagramdır. İyi bir diyagram, sistemin bileşenlerini, veri kaynaklarını, modelin nerede çalıştığını ve verinin kurum sınırlarını nerede geçtiğini net gösterir. Güvenlik ekibinin ilk sorusu neredeyse her zaman "veri kurum dışına çıkıyor mu, çıkıyorsa nereye" olduğu için, bu sınırı diyagramda açıkça işaretlemek gözden geçirmenin yarısını baştan çözer. Veri akış şeması ise diyagramın dinamik tamamlayıcısıdır: hangi verinin hangi adımda işlendiğini, nerede saklandığını ve ne zaman silindiğini izler. Bu iki belge net olduğunda güvenlik onayı hızlanır; bulanık olduğunda ekip her toplantıda aynı soruları tekrar sorar.

Erişim matrisi

Erişim matrisi, "kim neye erişebilir" sorusunun yapılandırılmış cevabıdır. Bir tabloda rolleri, veri sınıflarını ve her rolün her veri sınıfına erişim düzeyini gösterir. Yapay zeka çözümlerinde bu matrisin klasik uygulamalardan bir farkı vardır: modele bağlam olarak verilen veriyi de kapsaması gerekir, çünkü model dolaylı yoldan bir kullanıcıya yetkisi olmayan bir bilgiyi aktarabilir. İyi bir erişim matrisi bu dolaylı yolu da hesaba katar. Bu belgeyi hazırlarken kendime sorduğum kontrol sorusu şudur: "En düşük yetkili kullanıcı, modeli kullanarak görmemesi gereken bir bilgiye ulaşabilir mi?" Bu soruya "hayır" diyebildiğinizde, güvenlik katmanının en zorlu sorusunu geçmişsiniz demektir.

Kişisel veri envanteri ve DPIA

Uyum katmanının temel belgesi kişisel veri envanteridir: sistemin hangi kişisel veriyi, hangi amaçla, hangi hukuki dayanakla işlediğini listeler. Bu envanterin üstüne, etki analizi (DPIA — veri koruma etki değerlendirmesi) kurulur: işlemenin bireyler üzerindeki risklerini ve bu risklerin nasıl azaltıldığını değerlendirir. Regüle sektörde bu iki belge, uyum gözden geçirmesinin omurgasıdır. En sık gördüğüm eksiklik, envanterin "hangi veri" sorusunu yanıtlayıp "hangi amaç" sorusunu boş bırakmasıdır; oysa amaç, saklama süresini ve erişim kapsamını belirlediği için envanterin en kritik sütunudur. Kişisel verinin kapsamını kişisel veri nedir, çerçeveyi ise KVKK nedir yazısında ele alıyoruz.

Aydınlatma metni ve saklama politikası

Aydınlatma metni, veri sahiplerine işlemenin amacını ve haklarını bildiren belgedir; regüle sektörde bir yapay zeka çözümü kişisel veri işliyorsa, bu işlemenin mevcut aydınlatma metniyle uyumlu olup olmadığı sorgulanır. Saklama ve silme politikası ise "bu veri ne kadar tutulacak, sonra ne olacak" sorusunu yanıtlar. Yapay zeka çözümlerinde bu politika özellikle loglar açısından önemlidir: her istem ve yanıt loglanıyorsa, bu logların da bir saklama süresi ve silme kuralı olmalıdır. Bu belgeleri önden hazırlamak, uyum gözden geçirmesinde haftalar kazandırır.

Model kartı ve değerlendirme raporu

Model yönetişimi katmanının belgeleri, çözümün davranışını görünür kılar. Model kartı, modelin ne için tasarlandığını, hangi verilerle çalıştığını, sınırlarını ve bilinen risklerini özetleyen bir belgedir. Değerlendirme (eval) raporu ise modelin hangi görevlerde, hangi ölçütlerle test edildiğini ve nasıl performans gösterdiğini belgeler. Bu iki belge, "model iyi çalışıyor" iddiasını kanıta dönüştürür. Regüle sektörde öznel bir iyi çalışıyor izlenimi yeterli değildir; ölçülebilir bir eval, model yönetişimi katmanının en ikna edici belgesidir ve aynı zamanda iş/sponsor katmanının değer sorusunu da besler.

İnsan gözetimi planı

İnsan gözetimi planı, "model hata yaptığında ne olur" sorusunun belgelenmiş cevabıdır. Hangi kararlarda bir insanın döngüde olduğunu, hataların nasıl fark edildiğini, kimin müdahale edeceğini ve geri alma mekanizmasının nasıl işlediğini tanımlar. Regüle sektörde tam otomatik karar çoğu senaryoda kabul görmediği için, bu plan model yönetişimi katmanının vazgeçilmez belgesidir. İyi bir plan, gözetimi bir slogan olmaktan çıkarıp somut bir operasyonel akışa dönüştürür: kim, ne zaman, hangi eşikte devreye girer.

Tedarikçi sözleşmesi ve sorumluluk analizi

Hukuk katmanının belgesi, tedarikçi sözleşmesi ve ona bağlı sorumluluk analizidir. Bu belge, modelin yanlış çıktı üretmesi durumunda sorumluluğun nasıl paylaşıldığını, tedarikçinin veri kullanımına dair taahhütlerini, fikri mülkiyet haklarını ve hizmet sürekliliğini düzenler. Bu belgeyi önden hazır bir şablona bağlamak, hukuk onayının en uzun sürebilecek kalemini kısaltır. Sözleşmede en çok atlanan üç madde —çıktının kullanım hakkı, eğitim verisi taahhüdü ve çıkış planı— bu belgede net olduğunda hukuk katmanı hızla ilerler.

İş gerekçesi ve pilot kabul kriterleri

Son belge grubu, iş/sponsor katmanınındır: iş gerekçesi, temel çizgi (baseline) ve pilot kabul kriterleri. İş gerekçesi çözümün hangi problemi çözdüğünü ve mevcut duruma göre ne kazandırdığını anlatır; temel çizgi bu kazancı ölçmenin referans noktasıdır; pilot kabul kriterleri ise çözümün üretime alınmaya hazır sayılması için karşılaması gereken eşikleri tanımlar. Bu belgeleri pilot aşamasında oluşturmak, hem onay için hazır belge üretir hem de çözümü gerçekten iyileştirir. Bu belge, aynı zamanda pilottan üretime geçişin de temelidir; bu geçişin dinamiğini PoC'den üretime yapay zeka projeleri yazısında ayrıntılandırıyoruz.

Katmanların iskeleti hemen her regüle sektörde aynı olsa da, her sektörün kendi ağırlık noktası vardır. Bu farkları bilmek, hangi katmana daha çok hazırlık ayıracağınızı baştan belirlemenizi sağlar. Aşağıdaki gözlemler, banka sigorta AI projeleri ile sağlık ve kamu alanlarındaki vurgu farklarını özetler; hiçbiri kesin bir kural değil, sahada tekrar eden bir eğilimdir.

Bankacılıkta ağırlık noktası, karar süreçlerine etki ve finansal veridir. Bir kredi, risk ya da dolandırıcılık senaryosunu etkileyen bir yapay zeka çözümü, hem yoğun bir uyum gözden geçirmesinden hem de sektör düzenleyicisinin beklentilerinden geçer. Bu yüzden bankada model yönetişimi ve açıklanabilirlik katmanı özellikle ağırlaşır: modelin bir kararı neden verdiğini gösterebilmek, bankacılıkta çoğu zaman bir tercih değil zorunluluktur. Banka sigorta AI projelerinde onayı ağırlaştıran asıl unsur, çözümün karar etkisidir; iç verimlilik araçları görece hafif hattan geçerken, karara dokunan sistemler tam denetimden geçer.

Sigortada ağırlık noktası, kişisel ve çoğu zaman hassas veridir. Sağlık bilgisi, hasar geçmişi ve profil verisi işleyen bir sigorta çözümü, uyum gözden geçirmesinin en ayrıntılı halini gerektirir; amaçla sınırlılık ve saklama politikası burada özellikle titiz incelenir. Banka sigorta AI çözümleri bu yüzden çoğu zaman aynı katmanları paylaşır ama sigortada uyum, bankada ise model yönetişimi ve açıklanabilirlik biraz daha öne çıkar.

Sağlıkta ağırlık noktası, kararın birey üzerindeki doğrudan etkisi ve verinin en hassas kategoriye girmesidir. Sağlık verisiyle çalışan bir çözümde insan gözetimi planı ve güvenlik onayı özellikle titiz ele alınır; tam otomatik karar neredeyse hiç kabul görmez ve modelin sınırlarının model kartında açıkça belirtilmesi beklenir. Kamu tarafında ise şeffaflık, denetlenebilirlik ve veri egemenliği öne çıkar; verinin nerede barındığı ve kararların nasıl kayda geçtiği çoğu zaman en kritik sorulardır.

Bu sektörel farklar, hazırlık paketini de şekillendirir. Bankada eval ve açıklanabilirlik belgesine, sigortada uyum ve DPIA'ya, sağlıkta insan gözetimi planına, kamuda ise veri egemenliği ve denetim kaydına önden daha çok emek ayırmak, o sektörün en ağır katmanını baştan hafifletir. Sektörünüzün ağırlık noktasını erken teşhis etmek, enerjinizi doğru katmana yöneltmenin en pratik yoludur. Yine de altta yatan disiplin değişmez: hangi sektörde olursanız olun, regüle sektör AI onayı süreçlerinde belirleyici olan, her katmanın belgesinin baştan hazır olması ve katmanların akıllıca paralel yürütülmesidir.

Bir onay sürecine girmeden önce ekibin kendine sorması gereken birkaç soru vardır; bu soruların cevabı, sürecin ne kadar pürüzsüz ilerleyeceğini büyük ölçüde önceden söyler. Bu öz değerlendirmeyi bir "onay öncesi uçuş kontrolü" gibi düşünmek yararlıdır: uçağa binmeden önce her sistemin hazır olduğunu teyit etmek gibi.

Birinci soru veriyle ilgilidir: Bu çözüm hangi kişisel ya da gizli veriyi işliyor ve bu işlemenin amacını tek cümlede yazabiliyor muyuz? Bu soruya net cevap veremeyen bir ekip, uyum gözden geçirmesine hazır değildir; çünkü amaç net olmadan saklama, erişim ve silme politikaları da tanımlanamaz. Amaç ifadesini baştan yazmak, uyum katmanının en kritik sorusunu daha ilk günden çözer.

İkinci soru erişimle ilgilidir: En düşük yetkili kullanıcı, bu çözümü kullanarak görmemesi gereken bir bilgiye ulaşabilir mi? Bu soruya "hayır" diyebilmek, güvenlik onayının kalbini geçmek demektir. Cevap belirsizse, erişim matrisini ve modele bağlam sağlama kurallarını gözden geçirmek gerekir. Güvenlik ekibi bu soruyu mutlaka soracaktır; cevabı önden hazırlamak, güvenlik onayını hızlandırır.

Üçüncü soru davranışla ilgilidir: Bu modelin beklendiği gibi çalıştığını ölçülebilir bir kanıtla gösterebiliyor muyuz? Elde bir eval çerçevesi ve raporu yoksa, model yönetişimi katmanına öznel izlenimlerle girilir ve bu izlenimler ikna edici olmaz. Değerlendirme setini pilot aşamasında kurmak, bu soruyu kanıta bağlar.

Dördüncü soru sorumlulukla ilgilidir: Model yanlış bir çıktı ürettiğinde ne olur, kim fark eder, kim müdahale eder ve sorumluluk nasıl paylaşılır? Bu soruya net cevap veren bir insan gözetimi planı ve tedarikçi sözleşmesi, hem model yönetişimi hem hukuk katmanını baştan besler. Beşinci ve son soru sahiplikle ilgilidir: Her katmanın onayını verecek kişi belli mi? Bu soruya isim isim cevap veremiyorsanız, süreç daha başlamadan bir sahiplik boşluğu taşıyor demektir.

Bu beş soruya güvenle cevap verebilen bir ekip, onay sürecine hazır demektir; veremeyen bir ekip ise hangi katmanda takılacağını daha baştan görebilir. Bu öz değerlendirme, hazırlık paketinin bir özeti gibidir: eksik cevaplar, tam olarak hangi belgeyi önden tamamlamanız gerektiğini gösterir. Regüle sektör AI onayı sürecine bu beş soruyu yanıtlayarak girmek, çoğu gecikmeyi daha ilk toplantıdan önce eritir. Bu değerlendirmeyi bir kez şablonlaştırdığınızda, her yeni projede ilk gün doldurulan standart bir başlangıç aracına dönüşür ve ekibin sürece ne kadar hazır olduğunu tek bakışta gösterir.

Onay süreçlerinde gecikmeleri anlamanın en pratik yolu, onların rastgele değil desenli olduğunu görmektir. Farklı projelerde aynı birkaç tıkanmanın tekrar ettiğini fark ettiğimde, bunları önceden tanıyıp önlemenin mümkün olduğunu anladım. Aşağıda bu tekrar eden tıkanmaları sırayla ele alıyorum; her birini erkenden teşhis etmek, onay süresini uzatan asıl mekanizmaları baştan devre dışı bırakır.

Onay süreçlerinde gecikmeler tesadüfi değildir; tekrar eden birkaç noktada birikir. Birincisi belge eksikliğidir: bir katman belge ister, belge yoktur ve süreç bir sonraki toplantıya kayar — çoğu zaman iki hafta kaybedilir. İkincisi sahiplik boşluğudur: onayı kimin vereceği belirsizse, dosya masadan masaya dolaşır. Bu iki tıkanma, gözlemlediğim gecikmelerin çoğunun kaynağıdır.

Üçüncü sık takılma, katmanların sıralı yürütülmesidir. Ekipler önce güvenliği bitirip sonra uyuma, sonra hukuka geçmeyi doğal sanır; oysa bu sıralı akış, birbirinden bağımsız katmanları gereksizce arka arkaya dizerek onay süresini ikiye üçe katlar. Dördüncüsü, paydaşların sürecin sonunda masaya gelmesidir: son anda ortaya çıkan bir uyum ya da güvenlik itirazı, aylarca ilerlemiş bir dosyayı başa döndürebilir. Bu tıkanmaların çoğu, pilottan üretime geçişte belirginleşir; bu geçişin dinamiğini PoC'den üretime yapay zeka projeleri yazısında ele alıyoruz.

Bu dört tıkanmanın ortak bir kök nedeni vardır: sürecin sahibinin, her katmanın ne isteyeceğini önceden bilmemesi. Deneyimli bir ekip, ilk toplantıya girmeden önce her katmanın kontrol listesini elinde tutar ve toplantıyı "belge toplama" değil "onay alma" toplantısına dönüştürür. Erken uyarı sinyali basittir: bir katman toplantısından "şu belgeyi de getirin, tekrar görüşelim" diyerek çıkıyorsanız, hazırlık paketiniz eksik demektir ve onay süresi uzamaya başlamıştır.

Beşinci ve daha ince bir tıkanma da vardır: kapsamın süreç ortasında değişmesi. Ekip, bir katmanın itirazını karşılamak için çözümün kapsamını genişletir; ama bu genişleme, daha önce onaylanmış bir katmanın varsayımını bozar ve o katmana geri dönmeyi gerektirir. Regüle sektör AI onayı süreçlerinde bu "kapsam kayması" sessiz bir zaman katilidir. Çözüm, kapsamı ilk toplantıda net bir sınırla tanımlamak ve her değişikliği bilinçli bir karar olarak yönetmektir; kapsamı sabit tutmak, onay süresini korumanın en az konuşulan ama en etkili yollarından biridir.

Farklı projelerde tekrar eden gecikme desenlerini bir arada görmek, hangi müdahalenin en çok zaman kazandıracağını netleştirir. Aşağıdaki tablo, saha gözlemlerimde en sık rastladığım desenleri, her birinin onay süresi üzerindeki tipik etkisini ve pratik karşı hamlesini bir arada topluyor. Buradaki "etki" değerlendirmesi ölçülmüş bir istatistik değil, farklı projelerdeki nitel gözlemin özetidir; amacı öncelik sırası vermektir.

Gecikme deseni × onay süresine etki × karşı hamle

Gecikme deseni	Onay süresine etki	Karşı hamle
Belge eksikliği	Her eksik belge süreci bir sonraki toplantıya kaydırır	Hazırlık paketini önden tamamla, ilk toplantıya eksiksiz gir
Sahiplik boşluğu	Dosya masadan masaya dolaşır, kimse karar vermez	Her katman için tek bir onay sahibi ata
Katmanların sıralı yürütülmesi	Bağımsız katmanlar arka arkaya dizilir, süre katlanır	Bağımsız katmanları paralel başlat
Paydaşların geç dahil olması	Sonda çıkan itiraz aylarca ilerlemiş dosyayı başa döndürür	Onay kurulunu süreç başında bilgilendir
Kapsam kayması	Değişen kapsam onaylanmış katmanları geçersiz kılar	Kapsamı ilk toplantıda sabitle, değişimi bilinçli yönet

Bu tabloyu bir projeye başlarken elinize almak, "bizde hangi desen baskın" sorusunu sormanızı sağlar. Kurumların çoğunda bir ya da iki desen baskındır; onları erken teşhis etmek, enerjinizi doğru müdahaleye yöneltir. Örneğin belge eksikliği baskınsa, çözüm hazırlık paketidir; sahiplik boşluğu baskınsa, çözüm net bir onay sahipliği tanımıdır. Deseni görmeden genel "hızlanma" çabaları çoğu zaman boşa gider.

Bu desenlerin çoğunun ortak paydası, bir onay dosyasını bir risk değerlendirme dokümanı gibi düşünmemektir. Regüle sektörde onay, aslında riskin nasıl yönetildiğinin belgelenmesidir; dosyanızı bu çerçevede kurduğunuzda katmanların soruları da öngörülebilir hale gelir. Bir AI çözümünün risklerini yapılandırılmış bir belgede nasıl topladığımızı AI risk değerlendirme dokümanı nasıl hazırlanır yazısında adım adım gösteriyoruz; bu doküman, çoğu onay katmanının ortak girdisidir ve bir kez iyi hazırlandığında birden çok katmanı aynı anda besler.

Onay süresini kısaltmanın en güçlü kaldıracı, katmanları paralel yürütmektir. Katmanların birçoğu birbirinden bağımsızdır: bilgi güvenliği incelemesi sürerken uyum ekibi kendi belgelerini incelemeye, hukuk ekibi sözleşmeyi değerlendirmeye çoktan başlayabilir. Bu katmanları arka arkaya dizmek yerine eşzamanlı başlatmak, çoğu projede haftalar kazandırır. Tek koşul, her katmanın kendi belgesinin hazır olmasıdır — ki bu da bizi hazırlık paketine götürür.

Paralel yürütmenin en sık gözden kaçan koşulu, katmanların aynı gerçekliği görmesidir. Bir katman çözümün bir sürümünü, başka bir katman farklı bir sürümünü incelerse, paralellik zaman kazandırmak yerine tutarsızlık üretir. Bu yüzden paralel yürütmeden önce tek bir "onay sürümü" dondurulur ve tüm katmanlar bu aynı sürüm üzerinden çalışır. Sürüm değişirse, değişiklik tüm katmanlara aynı anda bildirilir. Bu disiplin olmadan paralellik, katmanların birbirinden habersiz farklı varsayımlarla ilerlemesine yol açar ve sonunda kazanılan zamandan fazlasını yeniden çalışmayla kaybettirir. Onay sürümünü sabitlemek, akıllı paralelliğin görünmeyen ön koşuludur.

İkinci fırsat, onay kurulunu erken bilgilendirmektir. Karar verecek paydaşları süreç başında bir araya getirip haritayı, riskleri ve belgeleri masaya koymak, sonda çıkacak sürpriz itirazları büyük ölçüde önler. Üçüncü fırsat, düşük riskli çözümler için hafifletilmiş bir onay hattı tanımlamaktır: kişisel veri işlemeyen bir iç verimlilik aracıyla, müşteri kararını etkileyen bir sistemin aynı ağır süreçten geçmesi gerekmez. Risk düzeyine göre farklı hızlarda ilerleyen bir onay tasarımı, hem onay süresini kısaltır hem de ekibin enerjisini gerçekten kritik olan projelere ayırır.

Paralel yürütmenin pratikte nasıl kurulacağını da netleştirmek gerekir, çünkü "paralel yapın" demek kolay, uygulamak koordinasyon ister. Saha pratiğim, tek bir onay koordinatörü atamaktır: bu kişi katmanları ayrı ayrı yönetmez, tersine tüm katmanların aynı hazırlık paketinden beslenmesini ve eşzamanlı ilerlemesini sağlar. Koordinatör, her katmanın durumunu tek bir tabloda takip eder — hangi katman hangi belgeyi bekliyor, hangi katman koşullu geçti, hangi katman karar aşamasında. Bu görünürlük, paralel yürütmenin kaosa dönüşmesini önler. Onay koordinatörü olmadan paralel yürütme çoğu zaman "herkes bir şey bekliyor ama kimse neyi beklediğini bilmiyor" haline gelir.

Paralelleştirilemeyecek gerçek bağımlılıkları da tanımak önemlidir. Bazı katmanlar gerçekten bir öncekinin çıktısını bekler: model yönetişimi, güvenlik ve uyumun tanımladığı sınırları varsayar; iş/sponsor onayı, diğer katmanların görüşünü ister. Bu gerçek bağımlılıkları paralelleştirmeye çalışmak zaman kazandırmaz, tersine yeniden çalışma üretir. Doğru strateji, bağımsız katmanları paralel başlatıp bağımlı katmanları doğru sıraya dizmektir. Bu ayrımı yapan bir onay haritası, paralel yürütmenin sınırlarını da net gösterir; onay süresini kısaltan, körü körüne paralellik değil, akıllı paralelliktir.

Dördüncü bir fırsat, tekrarlanabilir katmanları şablonlaştırmaktır. Bir kurumun ikinci, üçüncü AI projesinde güvenlik onayı ve uyum gözden geçirmesi katmanları büyük ölçüde aynı belgeleri ister; bu belgeleri her projede sıfırdan üretmek yerine, kurumsal bir şablon kütüphanesi kurmak onay süresini kalıcı olarak kısaltır. Regüle sektörde AI'yı ölçekleyen kurumların ortak özelliği, onayı her seferinde yeniden keşfetmek yerine bir kez kurup tekrar tekrar kullanmalarıdır.

Tüm bu gözlemlerin pratik çıktısı tek bir fikirde toplanır: onay sürecine girmeden önce, her katmanın isteyeceği belgeyi tek bir hazırlık paketinde hazır tutmak. Aşağıdaki adımlar, banka sigorta AI projelerinde ve diğer regüle alanlarda tekrar tekrar işe yaradığını gördüğüm bir hazırlık sırasını özetler.

Nasıl Yapılır

Regüle sektör AI onayı için hazırlık paketi

Bir yapay zeka çözümünü onay kuruluna sunmadan önce her katmanın belgesini önden hazırlamaya yarayan adım adım hazırlık.

1. 1

   Veri envanteri ve sınıflandırma

   Sistemin hangi kişisel/gizli veriyi işlediğini envanterleyin ve sınıflandırın; amaçla sınırlılığı baştan yazın.

2. 2

   Erişim kontrolü ve loglama tasarımı

   Kim hangi belgeye erişebilir sorusunu ve denetim kaydını mimariye baştan gömün.

3. 3

   Uyum belgeleri

   Aydınlatma metni, etki analizi (DPIA) ve saklama/silme politikasını hazır sunun.

4. 4

   Model yönetişimi paketi

   Model kartını, değerlendirme (eval) raporunu ve insan gözetimi planını ekleyin.

5. 5

   Hukuk ve tedarikçi paketi

   Tedarikçi sözleşmesini, sorumluluk ve fikri mülkiyet analizini netleştirin.

6. 6

   Tek dosyada sunum

   Tüm belgeleri onay kuruluna hazır tek bir dosyada toplayıp katmanları paralel başlatın.

Bu paket bir kez kurulduğunda, sonraki projelerde neredeyse şablon gibi tekrar kullanılır; her yeni çözüm için sıfırdan başlanmaz. Hazırlık paketini kurumun standart bir varlığına dönüştürmek, onay süresini kalıcı olarak kısaltan en değerli yatırımdır.

Paketin son adımı olan tek dosyada sunum, çoğu zaman en az emek verilen ama en çok fark yaratan adımdır. Belgeler ayrı ayrı, farklı formatlarda ve farklı dillerde durduğunda, onay kurulu resmi bir bütün olarak göremez ve her katman kendi parçasını ayrı ayrı sorgular. Aynı belgeler tek bir tutarlı dosyada, ortak bir dille ve net bir dizinle sunulduğunda, onay kurulu çözümün bütün resmini bir bakışta görür. Bu bütünlük, güveni hızlandırır: paydaşlar dağınık parçalar yerine düşünülmüş bir bütünle karşılaştıklarında, çözümün ciddiyetine dair ilk izlenim baştan olumlu olur. Tek dosyada sunum, hazırlık paketini bir belge yığınından bir onay aracına dönüştüren son dokunuştur.

Paketin en çok atlanan parçası, çözümün risk düzeyini baştan sınıflandıran kısa bir değerlendirmedir. Bir sistemin hangi veriyi işlediğini, kararı ne ölçüde etkilediğini ve insan gözetiminin nerede devreye girdiğini tek sayfada özetlemek, hem güvenlik onayı hem uyum gözden geçirmesi ekiplerinin ilk sorusunu baştan yanıtlar. Bu risk sınıflandırması, düşük riskli çözümlerin hafif hattan, yüksek riskli olanların ise tam denetimden geçmesini sağlayarak paketi gerçek bir hızlandırıcıya dönüştürür.

Hazırlık paketinin bir de "canlı belge" boyutu vardır. Onay bir kerelik bir olay değildir; çözüm üretime alındıktan sonra da model güncellenir, kapsam genişler, yeni veri kaynakları eklenir. Bu değişikliklerin her biri, ilgili katmanı yeniden ziyaret etmeyi gerektirebilir. Bu yüzden hazırlık paketini bir arşiv değil, güncellenen bir varlık olarak tutmak gerekir: model kartı yeni sürümle güncellenir, veri envanteri yeni kaynakla genişler, eval raporu yeni testlerle tazelenir. Paketi canlı tutan ekipler, bir sonraki onay turunu neredeyse formaliteye indirger; paketi rafa kaldıran ekipler ise her değişiklikte süreci baştan yaşar.

Son bir pratik: hazırlık paketini kurumun ortak diline çevirmek. Teknik ekibin yazdığı bir mimari diyagram, uyum ekibi için çoğu zaman anlaşılmazdır; uyum ekibinin yazdığı bir DPIA da teknik ekip için soyut kalır. İyi bir hazırlık paketi, her belgenin başına bir cümlelik "bu belge hangi katmanın hangi sorusuna cevap veriyor" notu koyar. Bu küçük çeviri, katmanlar arası yanlış anlamayı azaltır ve onay toplantılarını kısaltır. Regüle sektör AI onayı, sonuçta farklı disiplinlerin aynı masada anlaşabilmesi meselesidir; ortak dil, o anlaşmanın en ucuz hızlandırıcısıdır.

Bu bölümü, tek tek katmanları anlattıktan sonra hepsini bir arada nasıl yürüttüğümü göstermek için ekliyorum. Anlatı belirli bir kuruma değil, farklı projelerde tekrar eden bir akışa dayanır; sayı ya da vaka uydurmadan, sürecin ritmini aktarmayı amaçlar.

İlk hafta, teknoloji konuşmadan önce haritayı çıkarmakla geçer. Çözümün hangi veriyi işlediğini, hangi kararı etkilediğini ve kurumun hangi katmanlarının devreye gireceğini bir sayfada toplarım. Bu sayfada her katmanın adı, sahibi ve isteyeceği belge yazar. Bu harita, projenin geri kalanının pusulasıdır; onsuz her katman bir sürprizdir, onunla her katman bir kontrol listesi kalemi. Bu ilk adımı atlamak, sonraki tüm gecikmelerin tohumunu ekmektir.

İkinci aşamada hazırlık paketini kurarım. Veri envanteri, erişim ve loglama tasarımı, uyum belgeleri, model yönetişimi paketi ve hukuk/tedarikçi paketi — hepsi ilk onay toplantısından önce hazır olur. Buradaki disiplin şudur: bir katmanın toplantısına, o katmanın isteyeceği belge elde olmadan girmem. Bu kural tek başına, "şu belgeyi de getirin, tekrar görüşelim" döngüsünü büyük ölçüde ortadan kaldırır ve onay süresini en çok kısaltan alışkanlıktır.

Üçüncü aşamada katmanları paralel başlatırım. Güvenlik onayı incelemesi sürerken uyum gözden geçirmesi ve hukuk değerlendirmesi de eşzamanlı ilerler; onay koordinatörü tüm katmanların durumunu tek tabloda takip eder. Bağımlı katmanları —model yönetişimi ve iş/sponsor onayı— doğru sıraya dizerim, çünkü onlar diğerlerinin çıktısını bekler. Bu aşamada en sık yaptığım müdahale, bir katmanın koşullu geçişini net bir eylem listesine bağlayıp projeyi beklemeden ilerletmektir.

Dördüncü aşamada sponsoru ve onay kurulunu masada tutarım. Süreç boyunca düzenli, kısa bilgilendirmelerle paydaşları güncel tutmak, sonda çıkabilecek büyük itirazları küçük ve erken sorulara dönüştürür. Onay kurulu, dosyayı ilk kez son toplantıda görmez; süreç boyunca zaten görmüştür, dolayısıyla son onay bir formaliteye yaklaşır. Bu ritmi bir kez kuran kurumda, bir sonraki proje aynı hattı çok daha hızlı geçer; çünkü artık harita, paket ve koordinasyon kurumsal bir alışkanlık haline gelmiştir. Kullanıcıların çözümü gerçekten benimseyip benimsemediği ise ayrı bir konudur ve onay kadar önemlidir; benimsemeyi belirleyen faktörleri kullanıcı benimsemesini belirleyen faktörler saha notunda ele alıyorum.

Onay sürecini hızlandıran ama en az konuşulan unsurlardan biri iletişim ritmidir. Katmanlar arasında bilgi doğru zamanda akmazsa, teknik olarak hazır bir dosya bile bekler. Saha pratiğim, süreç boyunca kısa ve düzenli bir ritim kurmaktır: haftalık, on beş dakikayı geçmeyen bir durum toplantısında her katmanın nerede olduğu tek tabloda paylaşılır. Bu ritim, uzun ve seyrek toplantılardan çok daha etkilidir; çünkü tıkanmaları büyümeden yakalar. Bir katman bir belge bekliyorsa, bu haftalık ritimde hemen görünür ve gecikme iki güne iner, iki haftaya çıkmaz.

Toplantıların amacını da doğru tanımlamak gerekir. Bir katman toplantısı "belge toplama" toplantısı değil, "onay alma" toplantısı olmalıdır; yani ekip o toplantıya belgeyle gelir, toplantıda belge üretmez. Bu ayrım basit görünür ama onay süresini en çok etkileyen alışkanlıklardan biridir. Belgesiz girilen bir toplantı, çoğu zaman "şunu da hazırlayın, tekrar görüşelim" diyerek biter ve süreci bir sonraki takvim penceresine iter. Belgeyle girilen bir toplantı ise karar üretir.

İletişimin bir de yukarı doğru boyutu vardır: sponsoru ve onay kurulunu güncel tutmak. Bu paydaşlara her ayrıntıyı değil, sürecin genel sağlığını ve varsa kritik riskleri iletmek yeterlidir. Düzenli ve kısa üst düzey bilgilendirme, sonda çıkabilecek büyük sürprizleri erken ve küçük sorulara dönüştürür. Bir sponsor, sürecin ortasında bir riski öğrenip küçük bir kararla çözebilirken, aynı riski son toplantıda öğrendiğinde koca bir dosyayı geri çevirebilir. İletişim ritmi, bu farkı yaratan görünmez kaldıraçtır ve onay süresini kısaltan en ucuz müdahaledir.

Regüle sektörde onayın en çok yanlış anlaşılan yanı, bir bitiş çizgisi sanılmasıdır. Oysa üretime alma anı, uyumun bittiği değil sürekli hale geldiği andır. Bir yapay zeka çözümü canlıya geçtikten sonra da model güncellenir, veri kaynakları değişir, kullanım kapsamı genişler ve bu değişikliklerin her biri onaylanmış varsayımları test eder. Bu yüzden olgun kurumlar onayı bir kapı değil, bir yönetişim döngüsü olarak kurar: onaydan sonra düzenli gözden geçirmeler, değişiklik yönetimi ve izleme devreye girer.

Üretimde sürekli uyumun ilk bileşeni izlemedir. Modelin davranışı zamanla kayabilir; girdi verisi değişir, kullanıcı davranışı evrilir ve model onay anındaki performansından uzaklaşabilir. Bu kaymayı fark etmek için model yönetişimi katmanının kurduğu eval çerçevesini üretimde de çalıştırmak gerekir. Onay anında iyi çalışan bir modelin, altı ay sonra hâlâ iyi çalıştığını varsaymak regüle sektörde riskli bir varsayımdır; izleme, bu varsayımı kanıta bağlar.

İkinci bileşen değişiklik yönetimidir. Modelde, veride ya da kapsamda bir değişiklik olduğunda, hangi katmanın yeniden devreye gireceğini önceden tanımlamak, her değişikliği tam bir onay turuna dönüştürmekten kurtarır. Küçük bir değişiklik yalnızca ilgili katmanı ziyaret ederken, kapsamı genişleten büyük bir değişiklik daha geniş bir gözden geçirme gerektirebilir. Bu ayrımı baştan yapan kurumlar, üretim sonrası değişiklikleri hızlı ve güvenli yönetir; yapmayanlar ise her küçük güncellemede süreci baştan yaşar.

Üçüncü bileşen belgelerin canlı tutulmasıdır. Model kartı, veri envanteri ve DPIA gibi belgeler, sistem değiştikçe güncellenmezse kısa sürede gerçeklikten kopar ve bir denetim anında kurumu zor durumda bırakır. Belgeleri güncel tutmak, hem bir sonraki onay turunu hızlandırır hem de kurumun her an denetime hazır olmasını sağlar. Regüle sektörde uyum, bir kez kazanılıp rafa kaldırılan bir sertifika değil, sürekli beslenen bir ilişkidir; onay sürecini bu bakışla kuran ekipler, hem bugünün onayını hem yarının denetimini aynı disiplinle karşılar.

Bu saha notunun taşıdığı ders umut vericidir: regüle sektör AI onayı süreçleri yavaş görünse de, yavaşlığın nedeni büyük ölçüde önlenebilir. Süreci uzatan şey teknolojinin karmaşıklığı değil, belge ve paydaş hazırlığının eksikliğidir; ve bu, doğru hazırlıkla baştan çözülebilir bir problemdir. Katmanların haritasını çıkaran, her katmanın belgesini önden hazırlayan ve bağımsız katmanları paralel yürüten bir ekip, aynı onayı çok daha kısa sürede alır. Bu farkın en çarpıcı yanı, hiçbir ileri teknoloji ya da özel bütçe gerektirmemesidir; yalnızca disiplin, öngörü ve koordinasyon ister. Onay süresini uzatan darboğazların büyük kısmı, aslında bir ekibin bir günlük düzgün bir planlama toplantısıyla önleyebileceği türdendir. Bu yüzden regüle sektörde AI onayı, çoğu ekibin sandığından çok daha fazla kontrol edilebilir bir süreçtir.

Özetle regüle sektör AI onayı, bir teknoloji sınavı değil, bir hazırlık ve koordinasyon disiplinidir. Güvenlik onayı, uyum gözden geçirmesi ve hukuk katmanlarını ayrı ayrı ama eşzamanlı yönetmek; belgeleri tek pakette toplamak ve paydaşları erken masaya almak — bu birkaç pratik, onay süresini belirgin biçimde kısaltır ve çözümün değerini bekleme odasında kaybetmenizi önler.

Bu saha notunu tek bir cümleye indirmem gerekseydi şöyle derdim: regüle sektörde AI'yı üretime almanın hızı, modelinizin ne kadar iyi olduğuyla değil, onay dosyanızın ne kadar hazır olduğuyla ölçülür. Teknolojiyi geliştirmek için harcadığınız emeğin bir kısmını onay hazırlığına ayırmak, çoğu projede en yüksek getirili yatırımdır; çünkü dünyanın en iyi çözümü bile onaydan geçemezse hiçbir değer üretmez. Regüle sektör AI onayı sürecini bir engel değil, çözümünüzün gerçekten güvenli, uyumlu ve yönetilebilir olduğunu kanıtlayan bir disiplin olarak görmek, hem süreci hızlandırır hem de ortaya çıkan çözümün kalitesini yükseltir.

Son olarak, bu disiplinin kurumsal hafızaya dönüşmesi gerektiğini vurgulayayım. İlk projede öğrendiklerinizi bir harita, bir hazırlık paketi ve bir koordinasyon ritmi olarak kayda geçirirseniz, ikinci proje bu birikimin üzerine kurulur. Regüle sektörde AI onayında ustalık, tek bir projeyi hızlı geçmek değil, her yeni projeyi bir öncekinden daha hızlı geçirecek bir kurumsal kas hafızası inşa etmektir. Bu saha notu, o kası kurmaya başlayan ekipler için bir başlangıç noktasıdır.

Regüle sektörde AI onayı ne kadar sürer?

Kesin bir süre yoktur; onay süresi kurumun olgunluğuna ve çözümün risk düzeyine göre birkaç haftadan birkaç aya kadar değişir. Düşük riskli, kişisel veri içermeyen bir iç verimlilik aracı görece hızlı geçebilir; müşteri verisi işleyen, karar destekleyen bir sistem ise bilgi güvenliği gözden geçirmesi, uyum gözden geçirmesi ve hukuk katmanlarının tümünden geçmek zorunda olduğu için daha uzun sürer. Belirleyici olan teknolojinin karmaşıklığı değil, her katmanın istediği belgenin baştan hazır olup olmadığıdır.

Regüle sektör AI onayında hangi belgeler isteniyor?

Katmana göre değişir. Bilgi güvenliği katmanı mimari diyagram, veri akış şeması, erişim matrisi ve sızma testi raporu ister. Uyum/KVKK katmanı kişisel veri envanteri, aydınlatma metni, etki analizini (DPIA) ve saklama/silme politikasını ister. Hukuk katmanı tedarikçi sözleşmesini, sorumluluk ve fikri mülkiyet analizini ister. Model yönetişimi katmanı model kartını, değerlendirme (eval) raporunu ve insan gözetimi planını ister. İş/sponsor katmanı ise iş gerekçesini, temel çizgiyi ve pilot kabul kriterlerini ister.

Regüle sektörde AI onay süresi nasıl hızlandırılır?

En etkili üç müdahale şudur. Birincisi, katmanları sıralı değil paralel yürütmek: bilgi güvenliği incelemesi devam ederken uyum ve hukuk katmanlarını da eşzamanlı başlatmak, haftaları toplar. İkincisi, hazırlık paketini önden oluşturmak: her katmanın isteyeceği belgeyi ilk toplantıdan önce hazır sunmak, süreci her seferinde bir sonraki toplantıya kaymaktan kurtarır. Üçüncüsü, onay kurulunu erken bilgilendirmek: paydaşları süreç başında masaya almak, sonda çıkacak sürpriz itirazları önler.

Güvenlik onayı ile uyum gözden geçirmesi aynı şey mi?

Hayır; farklı sorulara cevap veren iki ayrı katmandır. Güvenlik onayı "bu sistem teknik olarak güvenli mi" sorusuna bakar: veri nasıl akıyor, kimler erişiyor, açıkları neler. Uyum gözden geçirmesi ise "bu sistem mevzuata ve kurum politikasına uygun mu" sorusuna bakar: KVKK yükümlülükleri, amaçla sınırlılık, saklama süresi ve gerekli belgeler. Bir sistem güvenli olup uyumsuz ya da uyumlu olup güvensiz olabilir; bu yüzden iki katman ayrı ayrı geçilir. Bu bir hukuki tavsiye değildir.

Banka sigorta AI projelerinde onay neden daha zordur?

Çünkü bu kurumlar hem yoğun denetime tabidir hem de işledikleri veri büyük ölçüde kişisel ve finansaldır. Banka sigorta AI çözümleri genellikle müşteri verisiyle çalışır, karar süreçlerini etkiler ve bu nedenle hem KVKK hem sektör düzenleyicisinin beklentilerini karşılamak zorundadır. Bu da uyum gözden geçirmesi ve güvenlik onayı katmanlarının daha ayrıntılı, daha fazla belge isteyen ve daha çok paydaş içeren bir hale gelmesi demektir.

Bu saha notunu, onay sürecini bir yük olarak değil bir değer aracı olarak görmeye çağırarak bitirmek istiyorum. Regüle sektörde çalışan ekipler onayı çoğu zaman aşılması gereken bir engel olarak yaşar; oysa iyi kurulmuş bir onay süreci, çözümün gerçekten güvenli, uyumlu ve yönetilebilir olduğunu kanıtlayan bir kalite güvencesidir. Güvenlik onayı, çözümün verinizi doğru işlediğini; uyum gözden geçirmesi, mevzuata uygun olduğunu; model yönetişimi, beklendiği gibi davrandığını gösterir. Bu katmanların her biri, aslında çözümünüzü daha iyi hale getiren bir geri bildirimdir.

Bu bakış açısı pratik bir sonuç doğurur: onay için hazırladığınız belgeler, çözümü sonradan yönetmenin de altyapısını kurar. Model kartı, üretimde modelin sınırlarını hatırlatır; eval raporu, davranış kaymasını izlemenin temelini atar; erişim matrisi, güvenlik olaylarında ilk başvuru kaynağıdır; DPIA, bir denetimde kurumu koruyan belgedir. Yani onay hazırlığına ayırdığınız emek, sadece bir kapıyı geçmek için değil, çözümü ömrü boyunca yönetmek için harcanır. Bu yüzden hazırlık paketini bir formalite değil, kurumsal bir varlık olarak kurmak en yüksek getirili yatırımdır.

İkinci bir değer boyutu güvendir. Regüle sektörde AI'nın önündeki en büyük engel çoğu zaman teknoloji değil, kurum içi güvensizliktir: paydaşlar çözümün riskini görmedikçe onay vermekte tereddüt eder. İyi kurulmuş bir onay süreci, bu güveni sistematik biçimde inşa eder; her katman, kendi alanındaki riskin yönetildiğini görüp güven verir. Onay süreci bittiğinde elinizde sadece bir izin değil, kurumun her kademesinin çözüme duyduğu güven de vardır — ki bu güven, çözümün gerçekten benimsenmesinin ön koşuludur.

Üçüncü değer boyutu ölçeklenebilirliktir. İlk projede kurduğunuz harita, paket ve koordinasyon ritmi, sonraki projelerde tekrar tekrar kullanılır; kurum, AI'yı proje proje değil bir yetkinlik olarak ölçekler. Regüle sektörde AI'da gerçek rekabet avantajı, tek bir çözümü üretime almak değil, çözümleri güvenli ve hızlı biçimde üretime alabilen bir kurumsal kas kurmaktır. Bu saha notunun tüm pratikleri, sonuçta o kası inşa etmeye hizmet eder: onayı her seferinde yeniden keşfetmek yerine bir disipline dönüştürmek.

Kurumunuz regüle bir sektörde bir yapay zeka çözümünü üretime almaya hazırlanıyorsa, onay sürecini baştan doğru kurmak aylar kazandırabilir. Katmanların haritasını çıkarmak, hazırlık paketini oluşturmak ve paralel yürütme hattını tasarlamak için birlikte bakalım. Somut bir onay yol haritası için danışmanlık görüşmesi üzerinden başlayabilir; uyum tarafını kapsamlı rehber ve KVKK uyumlu yapay zeka nedir yazılarıyla derinleştirebilirsiniz.