# Kurumsal AI Ajan Yönetişimi: Envanter, İzlenebilirlik ve Sorumluluk (2026)

> Source: https://sukruyusufkaya.com/blog/kurumsal-ai-ajan-yonetisimi-2026
> Updated: 2026-07-15T04:45:02.510Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Ajanlar üretime girdikçe asıl risk yönetişimde. Ajan envanteri, izlenebilirlik, yetki sınırları ve sorumluluk çerçevesini CTO/CDO gözüyle kuruyorum.

**TL;DR —** AI ajanları pilot aşamasından çıkıp üretime girdikçe asıl risk modelde değil, yönetişimde ortaya çıkıyor. Sahada gördüğüm en yaygın başarısızlık nedeni; şirketin kaç ajanı olduğunu bilmemesi, bu ajanların ne yaptığını izleyememesi ve bir şey ters gittiğinde kimin sorumlu olduğunu söyleyememesidir. Bu yazıda bir CTO/CDO gözüyle beş temel yeteneği kuruyorum: **ajan envanteri (registry)**, **izlenebilirlik ve denetim kaydı**, **en az yetki ilkesiyle araç izinleri**, **net sahiplik ve RACI**, **sürekli izleme ve KPI'lar**. Ardından bunları ISO/IEC 42001, EU AI Act, KVKK ve BDDK çerçevelerine bağlıyor, 90 günlük bir devreye alma planı ve en sık yapılan hatalarla bitiriyorum. Gartner, 2026 sonuna kadar kurumsal uygulamaların %40'ının AI ajanı gömülü olarak geleceğini öngörüyor (2025'te bu oran %5'in altındaydı). Yani bu konuşmayı ertelemenin lüksü kalmadı.

## Neden yönetişim artık asıl darboğaz?

Son bir yılda katıldığım hemen her kurumsal projede aynı sahneyi yaşadım. Bir ekip heyecanla bir ajan geliştiriyor, demo muhteşem oluyor, yönetim "hadi üretime alalım" diyor. Sonra ilk soruyu ben soruyorum: "Bu ajan hangi sistemlere erişiyor, hangi kararları tek başına verebiliyor ve yanlış bir işlem yaptığında bunu nereden göreceğiz?" Genellikle sessizlik oluyor.

İşte o sessizlik, 2026'nın en büyük kurumsal riskidir. Model kalitesi değil, yönetişim boşluğu.

Bunun neden şimdi patladığını anlamak için ajanların klasik yazılımdan farkını kabullenmek gerekiyor. Geleneksel bir uygulama deterministiktir; aynı girdiye aynı çıktıyı verir, akışı bellidir, kod incelemesiyle davranışını öngörebilirsiniz. Bir AI ajanı ise **hedef verilen, karar veren ve araç çağıran** bir varlıktır. Kendi başına adım planlar, API'lere istek atar, veritabanı sorgular, e-posta gönderir, hatta başka ajanları tetikler. Yani artık elimizde davranışı çalışma zamanında şekillenen, yetkileri gerçek sistemlere uzanan bir "dijital çalışan" var. Ve çoğu kurum bu dijital çalışanı İK'dan geçirmeden, kimlik kartı vermeden, yetki matrisi tanımlamadan işe alıyor.

Gartner'ın tahminine göre 2026 sonuna kadar kurumsal uygulamaların **%40'ı** AI ajanı gömülü olarak gelecek; oysa 2025'te bu oran %5'in altındaydı. Bu, sekiz kat büyüme demek. Şunu net söyleyeyim: bu ajanların büyük kısmı sizin geliştirdiğiniz özel ajanlar olmayacak. CRM'inizin içinde, ERP'nizin içinde, çağrı merkezi yazılımınızda, hatta e-posta istemcinizde hazır gelecekler. Yani "biz ajan geliştirmiyoruz ki" demek sizi kapsam dışı bırakmıyor; tam tersine, envanterini bile tutamadığınız ajanlarla dolu bir kuruma dönüşüyorsunuz.

Sahada gözlemlediğim başarısız ajan programlarının kök nedeni neredeyse her zaman aynı: **yönetişim boşlukları ve ajan eylemlerini envanterleyip izleyememek.** Model harika çalışıyor olabilir; ama ajanın hangi müşteri kaydını değiştirdiğini, hangi iadeyi onayladığını, hangi tedarikçiye sipariş açtığını denetim kaydından çıkaramıyorsanız, bir gün regülatör ya da müşteri kapıyı çaldığında elinizde hiçbir şey olmaz.

> Bir ajanı üretime almak, ona bir bütçe ve imza yetkisi vermek gibidir. Hiçbir sağlıklı kurum, kime, ne kadar, hangi limite kadar imza yetkisi verdiğini bilmeden çalışmaz. AI ajanları için de aynı disiplini kurmak zorundayız.

Bir başka boyut da tedarikçi bağımlılığı. Yaptığım görüşmelerde kurumların **%75'inden fazlası** tedarikçi ve API bağımlılığı riskinden endişe ettiğini söylüyor. Haklılar: ajanınızın beyni bir dış sağlayıcının modelinde, hafızası bir vektör veritabanında, araçları üçüncü parti API'lerdeyse, o zincirin her halkası sizin kontrolünüz dışında bir risk taşıyor. Sağlayıcı fiyat değiştirebilir, modeli emekliye ayırabilir, davranışını sessizce güncelleyebilir. Yönetişim, sadece "içeride ne oluyor" değil, "dışarıya ne kadar bağımlıyız" sorusunu da kapsar.

Bu yüzden yönetişimi bir "uyum yükü" olarak değil, **ölçeklenmenin ön koşulu** olarak konumlandırıyorum. İyi kurulmuş bir yönetişim çerçevesi frenleme değil, güvenle hızlanmadır. Envanteriniz, izleriniz ve yetki sınırlarınız netse yeni bir ajanı üretime almak korkulacak bir olay değil, rutin bir süreç olur.

## Ajan envanteri: göremediğinizi yönetemezsiniz

Her şeyin başladığı yer burası. Bir kurumda ilk yaptığım şey her zaman şudur: "Bana çalışan tüm AI ajanlarının listesini çıkarın." Şu ana kadar bu listeyi ilk denemede eksiksiz çıkarabilen bir kurum görmedim. Çünkü ajanlar farklı ekiplerce, farklı platformlarda, çoğu zaman merkezi bir kayıt olmadan devreye alınıyor.

**Ajan envanteri (agent registry)**, kurumdaki her ajanın tek doğruluk kaynağıdır. Bunu bir varlık envanteri gibi düşünün; tıpkı sunucularınızı, veri tabanlarınızı ya da uygulamalarınızı kaydettiğiniz gibi ajanlarınızı da kaydediyorsunuz. Bir ajan bu kayıtta yoksa üretimde olmamalıdır. Kural bu kadar basit.

Bir ajan kaydında bulunmasını istediğim asgari alanlar şunlar:

- **Ajan kimliği ve adı:** Benzersiz bir tanımlayıcı ve insan-okunur ad.
- **İş sahibi (business owner):** Bu ajanın var olma sebebinden sorumlu iş birimi yöneticisi.
- **Teknik sahibi (technical owner):** Ajanı çalışır tutan mühendislik ekibi/kişisi.
- **Amaç ve kapsam:** Ajan neyi çözüyor, hangi süreçte çalışıyor, sınırları ne?
- **Kullandığı modeller:** Hangi temel model(ler), hangi sağlayıcı, hangi sürüm.
- **Eriştiği sistemler ve araçlar:** Bağlı olduğu API'ler, veri tabanları, uygulamalar.
- **Veri sınıflandırması:** İşlediği verinin hassasiyeti (kişisel veri, finansal veri, sağlık verisi vb.).
- **Özerklik seviyesi:** Sadece öneri mi sunuyor, insan onayıyla mı hareket ediyor, yoksa tam otonom mu?
- **Risk sınıfı:** Düşük/orta/yüksek/kritik — özellikle müşteriye zarar verebilecek kararlar veriyorsa.
- **Devreye alma tarihi ve son gözden geçirme tarihi.**
- **İlgili regülasyon etiketleri:** EU AI Act risk kategorisi, KVKK kapsamı, sektörel düzenleme (ör. BDDK).

Bu envanteri statik bir Excel dosyası olarak tutmanın çekiciliğini biliyorum ama tavsiye etmiyorum. Ajanlar hızlı değişir; model sürümü güncellenir, yeni bir araç bağlanır, yetki genişler. Envanterin mümkün olduğunca **otomatik beslenmesi** gerekir: dağıtım hattına (CI/CD) bir kanca koyup her yeni ajan dağıtımını kayda düşmek, çalışma zamanında kullanılan araçları telemetriden toplamak gibi. Manuel tutulan envanter, tutulduğu ilk gün doğrudur ve sonra her gün biraz daha yanlışa kayar.

Envanter olgunluğunu değerlendirirken şu tabloyu kullanıyorum. Kendi kurumunuzu bu satırlarda dürüstçe işaretleyin:

| Yetenek | Seviye 1 (Ad-hoc) | Seviye 2 (Tanımlı) | Seviye 3 (Yönetilen) | Seviye 4 (Optimize) |
|---|---|---|---|---|
| Envanter | Liste yok, kimse tam bilmiyor | Manuel Excel, kısmen güncel | Merkezi registry, çoğu ajan kayıtlı | Otomatik beslenen, %100 kapsamlı registry |
| İzlenebilirlik | Log dağınık veya yok | Uygulama logları var, ajan eylemi izlenmiyor | Merkezi denetim kaydı, eylem düzeyinde iz | Uçtan uca korelasyonlu, değişmez iz kaydı |
| Yetki yönetimi | Ajanlar geniş/paylaşımlı kimlik kullanıyor | Ajan başına kimlik var, izinler geniş | En az yetki, kapsamlı izinler | Dinamik, zaman-sınırlı, onaya bağlı yetki |
| Sahiplik | Belirsiz, "IT bakar" | İş ve teknik sahip atanmış | RACI tanımlı, tatbik ediliyor | Sahiplik SLA'lara ve denetime bağlı |
| İzleme | Manuel, olay sonrası fark ediliyor | Temel uptime/hata izleme | KPI panosu, uyarılar kurulu | Anomali tespiti + otomatik müdahale |

Çoğu kurumu ilk değerlendirdiğimde satırların büyük kısmı Seviye 1-2 arasında oluyor. Hedef, 12 ay içinde tüm satırları en az Seviye 3'e taşımak. Seviye 4 bir lükstür ama kritik ajanlarınız için ulaşmanız gereken yerdir.

## İzlenebilirlik ve denetim kaydı: her eylem bir iz bırakmalı

Bir ajanı klasik bir mikroservisten ayıran şey, karar zincirinin görünmez oluşudur. Ajan "neden bu kararı verdim" sorusuna, siz onu tasarlamadıysanız cevap veremez. Bu yüzden izlenebilirliği baştan mimariye gömmek gerekir; sonradan eklenmez.

İzlenebilirliği üç katmanda düşünüyorum:

**1. Eylem izi (action trace):** Ajanın attığı her somut adım. Hangi aracı çağırdı, hangi parametrelerle, ne zaman, hangi sonucu aldı. Bu, "ajan saat 14:32'de X müşterisinin kredi limitini sorguladı, ardından iade onay aracını çağırdı" düzeyinde ayrıntı demektir.

**2. Karar izi (decision/reasoning trace):** Ajanın neden o adımı seçtiği. Hangi bağlamı gördü, hangi talimatla hareket etti, hangi ara çıkarımları yaptı. Modellerin muhakemesini birebir kaydetmek her zaman mümkün değil ama en azından girdi bağlamını, sistem talimatını ve seçilen aracın gerekçesini saklamak gerekir.

**3. Veri izi (data lineage):** Ajanın hangi veriyi okudu, hangi veriyi yazdı/değiştirdi. Özellikle kişisel veri söz konusuysa bu, KVKK açısından pazarlık konusu değil.

Bu izlerin taşıması gereken temel özellik **değişmezlik (immutability)**. Denetim kaydı sonradan düzenlenebiliyorsa denetim kaydı değildir. Kritik ajanlar için append-only, zaman damgalı, erişimi sınırlı bir kayıt deposu kuruyorum. Bir olay araştırması sırasında "logları biri silmiş olabilir mi?" sorusunun akla bile gelmemesi gerekir.

> Denetim kaydınızın kalitesini şu testle ölçün: rastgele bir ajan eylemini seçin ve o eylemi kimin/neyin, hangi bağlamla, hangi yetkiyle tetiklediğini beş dakikada geriye doğru izleyebiliyor musunuz? İzleyemiyorsanız, o ajan üretimde olmamalı.

Pratik bir not: izler mutlaka **korelasyon kimliği (correlation ID)** taşımalı. Bir kullanıcı isteği, ajanın attığı beş araç çağrısı ve bunların tetiklediği alt işlemler aynı iz kimliğiyle bağlanabilmeli. Aksi halde elinizde birbirinden kopuk log parçaları olur ve bir olayı yeniden kurmak saatler sürer. Ajanlar arası çağrılarda (bir ajanın başka bir ajanı tetiklediği durumlarda) bu korelasyon daha da kritik hale gelir; zinciri baştan sona takip edemezseniz sorumluluğu da atayamazsınız.

Gözlemlenebilirlik (observability) araçlarınızı ajan dünyasına genişletin. Klasik APM araçları istek/yanıt sürelerini ölçer ama "ajan bu ay kaç kez insan onayını atladı" gibi soruları cevaplamaz. Ajan-özel metrikleri (araç çağrı dağılımı, onay oranı, geri alma/rollback sayısı, halüsinasyon şüpheli çıktı oranı) ayrı bir katmanda toplamak gerekiyor.

## En az yetki ilkesiyle araç izinleri

Şimdi en kritik ve en çok ihmal edilen konuya geliyorum: **ajanların ne yapabildiği.** Bir ajanın yeteneği, ona verdiğiniz araçlarla ve o araçların yetkileriyle sınırlıdır. Bu yüzden yönetişimin kalbi izin yönetimidir.

Sahada gördüğüm en tehlikeli desen şudur: ekip geliştirmeyi hızlandırmak için ajana geniş, hatta yönetici (admin) düzeyinde bir kimlik veriyor. "Şimdilik böyle kalsın, sonra kısarız" deniyor. O "sonra" hiç gelmiyor ve üretimde, veritabanının tamamını silebilecek yetkiye sahip, davranışı olasılıksal bir ajanınız oluyor. Bu, birine kör bir çeke imza yetkisi verip "dikkatli ol" demeye benziyor.

Uyguladığım ilkeler şunlar:

- **En az yetki (least privilege):** Ajan yalnızca görevini yapmak için gereken minimum izne sahip olmalı. İade onaylayan bir ajanın müşteri silme yetkisi olmamalı. Nokta.
- **Kapsamlı/dar izinler (scoped permissions):** İzinler mümkün olan en dar kapsamda tanımlanmalı; "tüm siparişlere yaz" değil, "yalnızca kendi kanalındaki, belirli tutar altındaki siparişlere yaz".
- **Ajan başına ayrı kimlik:** Her ajanın kendi hizmet kimliği olmalı. Paylaşımlı kimlik, denetim kaydını işe yaramaz hale getirir; kimin ne yaptığını ayıramazsınız.
- **Zaman ve tutar sınırları:** Yüksek etkili işlemler için eşikler koyun. Belirli bir tutarın üstündeki işlem otomatik onaya değil, insan onayına gitmeli.
- **İnsan onay kapıları (human-in-the-loop):** Geri alınamaz veya yüksek riskli eylemlerde (para transferi, sözleşme imzası, müşteriye olumsuz karar bildirimi) insan onayı zorunlu olmalı.
- **Dinamik/geçici yetki:** İdeal olgunlukta yetkiler kalıcı değil, göreve özel ve zaman-sınırlı verilir; iş bitince geri alınır.

Bir ajanın izinlerini tasarlarken kendime hep şunu sorarım: "Bu ajan tamamen ele geçirilirse ya da tümüyle yanlış davranırsa yapabileceği en kötü şey nedir?" Cevap kabul edilemezse, izinleri o cevabı kabul edilebilir kılacak kadar daraltırım. Buna **patlama yarıçapını (blast radius) sınırlama** diyorum. Ajanınızın hata yapacağını varsayın; soru "hata yapar mı" değil, "hata yaptığında ne kadar zarar verebilir" olmalı.

Araç kataloğu da bu resmin parçası. Ajanların erişebileceği araçları merkezi, onaylı bir katalogda tutuyorum. Yeni bir araç eklemek bir gözden geçirme sürecinden geçmeli; herhangi bir mühendisin ajana keyfi olarak yeni bir güçlü araç bağlaması engellenmeli. Araç kataloğu, ajanların "yeteneklerinin" resmi kayıt defteridir.

## Sahiplik ve RACI: bir ajanın sahibi kim?

Bir ajan yanlış bir iade onayladığında, gece 3'te kimi ararsınız? Bu sorunun net bir cevabı yoksa yönetişiminiz yok demektir. Teknoloji tarafını ne kadar mükemmel kurarsanız kurun, sahiplik belirsizse ilk ciddi olayda herkes birbirini işaret eder.

Her ajanın iki tür sahibi olmalı: bu ajanın var olma gerekçesinden ve iş sonuçlarından sorumlu **iş sahibi**, ve ajanı teknik olarak çalışır ve güvenli tutan **teknik sahibi**. Bu ikisi aynı kişi olamaz; çıkar dengeleri farklıdır. İş sahibi değer ister, teknik sahip güvenlik ve sürdürülebilirlik ister; sağlıklı gerilim buradadır.

Kurumsal ajan yönetişimi için kullandığım örnek RACI şu şekilde (R: Yapan, A: Onaylayan/Nihai sorumlu, C: Danışılan, I: Bilgilendirilen):

| Faaliyet | İş Sahibi | Teknik Sahip | AI Yönetişim Kurulu | Güvenlik/Uyum | CTO/CDO |
|---|---|---|---|---|---|
| Yeni ajan önerisi | A | C | C | C | I |
| Risk sınıflandırması | C | C | A | R | I |
| Üretime alma onayı | C | R | C | C | A |
| İzin/yetki tanımı | C | R | C | A | I |
| Denetim kaydı gözden geçirme | I | R | C | A | I |
| Olay müdahalesi | C | R | I | C | A |
| Periyodik gözden geçirme | R | C | A | C | I |
| Ajanı emekliye ayırma | A | R | C | I | I |

Bu tablo bir şablondur; kendi kurumunuzun yapısına uyarlamanız gerekir. Ama değişmeyen ilke şu: her satırda **tek bir A (nihai sorumlu)** olmalı. İki nihai sorumlu, sıfır nihai sorumlu demektir.

Bu noktada **AI Yönetişim Kurulu**'ndan bahsetmeliyim. Belirli bir olgunluğun üstündeki kurumlarda ajanların üretime alınmasını, risk sınıflandırmasını ve periyodik gözden geçirmeleri yöneten çapraz-fonksiyonel bir kurul kurmayı öneriyorum. Bu kurulda teknoloji, hukuk/uyum, güvenlik, veri ve ilgili iş birimleri temsil edilmeli. Ağır bürokrasi kurmayın; amaç hızı öldürmek değil, kritik kararlarda birden fazla göz olmasını sağlamak. Düşük riskli ajanlar için hafif, hızlı bir onay; yüksek riskli ajanlar için kurul incelemesi — riskle orantılı bir yönetişim.

## İzleme ve metrikler: yönetemediğinizi ölçemezsiniz

Bir ajanı üretime almak bir bitiş değil, bir başlangıçtır. Ajanların davranışı zamanla kayar: modeller güncellenir, veri dağılımı değişir, kullanıcı davranışı evrilir. Bu yüzden sürekli izleme yönetişimin ayrılmaz parçası.

İzlediğim metrikleri dört kategoride topluyorum:

**Operasyonel metrikler:** Erişilebilirlik, gecikme, hata oranı, araç çağrı başarısı. Klasik ama gerekli.

**Kalite metrikleri:** Görev tamamlama oranı, insan düzeltme/müdahale oranı, geri alma (rollback) sayısı, halüsinasyon şüpheli çıktı oranı. "Ajan işini ne kadar iyi yapıyor" sorusunun cevabı burada.

**Yönetişim metrikleri:** Envanter kapsama oranı (kaç ajan kayıtlı / toplam tahmini ajan), izin denetimi geçme oranı, denetim kaydı bütünlüğü, insan onay kapılarının atlanma sayısı. Bu kategori benim en çok önem verdiğim yer; çünkü yönetişimin kendisini ölçüyor.

**İş metrikleri:** Ajanın ürettiği değer, maliyet (token/işlem başına), otomasyon oranı, yatırım getirisi. Yönetişim maliyet gibi görünmesin diye değeri de ölçmek şart.

Somut olarak izlenmesini önerdiğim bazı KPI'lar:

- **Envanter kapsama oranı:** Kayıtlı ajan / toplam ajan. Hedef: %100.
- **Ortalama iz-geri-izleme süresi:** Bir ajan eylemini kökene kadar izleme süresi. Hedef: dakikalar.
- **En az yetki uyum oranı:** İzinleri denetlenmiş ve dar kapsamlı ajan yüzdesi.
- **İnsan onay kapısı bütünlüğü:** Zorunlu onay kapılarının atlanma sayısı. Hedef: sıfır.
- **Ortalama olay müdahale süresi (MTTR):** Ajan kaynaklı bir olayın tespit-müdahale süresi.
- **Sahipsiz ajan sayısı:** İş veya teknik sahibi atanmamış ajan sayısı. Hedef: sıfır.
- **Model/sağlayıcı bağımlılık dağılımı:** Tek bir sağlayıcıya bağımlılık yüzdesi; tedarikçi riskini görünür kılar.

Bir uyarı: metrik panosu kurmak kolay, onu okumak ve harekete geçmek zordur. Her metriğin bir sahibi ve bir eşiği olmalı; eşik aşıldığında ne olacağı önceden tanımlı olmalı. Aksi halde güzel ama kimsenin bakmadığı bir pano kurmuş olursunuz.

## ISO 42001, EU AI Act, KVKK ve BDDK'ya haritalama

Buraya kadar anlattığım her şey aslında bir dizi düzenleyici çerçeveyle örtüşüyor. Bunu bir tesadüf olarak görmeyin; bu çerçeveler tam da sahadaki bu boşlukları kapatmak için doğdu. Yönetişim yapınızı kurarken bu haritayı gözetmek, hem tekerleği yeniden icat etmenizi önler hem de denetim gününe hazır olursunuz.

**ISO/IEC 42001 — AI Yönetim Sistemi:** Bu standart, bir kuruluşun yapay zekâyı sorumlu biçimde yönetmesi için bir yönetim sistemi (AIMS) tanımlar; tıpkı ISO 27001'in bilgi güvenliği için yaptığı gibi. Envanter, rol ve sorumluluklar, risk değerlendirmesi, izleme ve sürekli iyileştirme döngüsü doğrudan bu standardın omurgasıyla örtüşür. Ajan yönetişim çerçevenizi ISO 42001 kontrolleriyle eşlerseniz, hem içeriye tutarlı bir dil kazandırır hem de sertifikasyona giden yolu açarsınız.

**EU AI Act:** Avrupa'nın yapay zekâ düzenlemesi risk temelli bir yaklaşım getiriyor. Türkiye'de faaliyet gösteren ama AB pazarına dokunan (AB'li müşterisi, kullanıcısı ya da veri öznesi olan) kurumlar için bu doğrudan bağlayıcı hale gelebiliyor. Genel amaçlı yapay zekâ (GPAI) modellerine yönelik yükümlülüklerin uygulanması **2 Ağustos 2026**'dan itibaren devreye giriyor ve şeffaflık yükümlülükleri öne çıkıyor. Ajan envanterinizdeki "risk sınıfı" ve "şeffaflık" etiketleri tam da bu yüzden var: hangi ajanınızın hangi risk kategorisine düştüğünü ve kullanıcıya yapay zekâ ile etkileşimde olduğunu bildirip bildirmediğinizi gösterebilmelisiniz.

**KVKK:** Türkiye'de en sık atlanan nokta bu. Yurt dışında barındırılan bir modeli (ki çoğu öyle) kullanan bir ajan, işlediği kişisel veriyi büyük olasılıkla **yurt dışına aktarıyor** demektir. KVKK'nın yurt dışına veri aktarımı rejimi burada devreye girer ve uygun bir hukuki zemin (açık rıza, taahhütname, yeterlilik kararı vb.) olmadan bu aktarım ihlal oluşturabilir. KVKK'nın **Kasım 2025 tarihli Üretken Yapay Zekâ rehberi**, bu alanda beklentileri netleştiriyor. Ajan envanterindeki "veri sınıflandırması" ve "eriştiği sistemler" alanları, hangi ajanın hangi kişisel veriyi nereye taşıdığını gösterebilmeniz için kritik.

**BDDK:** Finans sektöründeyseniz bu sizin için özellikle önemli. BDDK, bankalar için algoritmik şeffaflık, denetlenebilirlik ve açıklanabilirliği vurgulayan bir yapay zekâ düzenleyici çerçevesi hazırlıyor; özellikle kredi reddi gibi müşteriye zarar verebilecek kararlar için. Bir müşteriye "krediniz reddedildi" diyen bir ajanınız varsa, o kararın **neden** verildiğini açıklayabilmeniz, izini sürebilmeniz ve denetleyebilmeniz gerekecek. Bu, izlenebilirlik ve karar izi başlıklarında anlattığım her şeyin regülatif bir zorunluluğa dönüşmesi demek.

| Çerçeve | Odak | Ajan yönetişiminde karşılığı |
|---|---|---|
| ISO/IEC 42001 | AI yönetim sistemi | Envanter, roller, risk, sürekli iyileştirme |
| EU AI Act | Risk temelli düzenleme, şeffaflık | Risk sınıfı etiketleri, kullanıcı bildirimi, GPAI yükümlülükleri (2 Ağustos 2026) |
| KVKK | Kişisel veri, yurt dışı aktarım | Veri sınıflandırması, aktarım hukuki zemini, Üretken YZ rehberi (Kasım 2025) |
| BDDK | Bankacılıkta şeffaflık/açıklanabilirlik | Karar izi, açıklanabilirlik, müşteriye zararlı karar denetimi |

Bir noktanın altını çizeyim: bu çerçeveler birbirini dışlamaz, üst üste biner. İyi haber şu ki her biri için ayrı bir yönetişim kurmanıza gerek yok. Sağlam bir ajan envanteri, izlenebilirlik altyapısı ve sahiplik modeli kurarsanız, dördünün de gereksinimlerinin büyük kısmını aynı temelle karşılarsınız. Tek yapmanız gereken, envanterinize doğru etiketleri eklemek ve denetim gününde doğru raporu üretebilmektir.

Bir de **build-vs-buy** boyutu var. Ajanı kendiniz mi geliştiriyorsunuz yoksa hazır bir üründen mi alıyorsunuz — bu, yönetişim sorumluluğunu değiştirir ama ortadan kaldırmaz. Satın aldığınız bir üründeki ajan için bile envanterinize kaydetmek, veri akışını anlamak, sağlayıcının denetim kaydı ve şeffaflık taahhütlerini sözleşmeye bağlamak sizin sorumluluğunuzdadır. "Tedarikçi hallediyor" cümlesi bir regülatör karşısında sizi kurtarmaz. Tedarikçiye devredebileceğiniz şey işin yapılması olabilir; ama hesap verebilirlik devredilemez.

## 90 günlük yönetişim devreye alma planı

Teorinin sahada işe yaraması için bir yol haritası şart. Kurumlara önerdiğim, ilk 90 günde somut ve ölçülebilir bir temel kuran plan şöyle:

**Gün 0-30: Görünürlük ve temel.**
- Bir ajan envanteri oluşturun; kaynak ne olursa olsun (kendi geliştirdiğiniz + hazır ürünlerdeki) tüm ajanları bulup kaydedin. Bu ilk keşif genellikle herkesi şaşırtır; kimsenin bilmediği ajanlar ortaya çıkar.
- Her ajana bir iş ve teknik sahip atayın. Sahipsiz ajan sayısını sıfıra indirin.
- Her ajanı risk sınıfına ayırın (düşük/orta/yüksek/kritik).
- Hızlı bir "en kötü senaryo" değerlendirmesi yapın: hangi ajan ele geçirilse en büyük zararı verir?

**Gün 31-60: Kontrol ve izlenebilirlik.**
- Yüksek ve kritik risk sınıfındaki ajanlardan başlayarak en az yetki ilkesini uygulayın; geniş/paylaşımlı kimlikleri ajan-başına dar kapsamlı kimliklerle değiştirin.
- Merkezi, değişmez denetim kaydını devreye alın; korelasyon kimliğiyle uçtan uca izlenebilirliği kurun.
- Geri alınamaz/yüksek riskli eylemler için insan onay kapıları ekleyin.
- Onaylı araç kataloğunu oluşturun; yeni araç ekleme sürecini tanımlayın.

**Gün 61-90: Yönetişim ve süreklilik.**
- RACI'yi devreye alın ve tatbik edin; olay müdahale sürecini yazın ve bir tatbikat yapın.
- AI Yönetişim Kurulu'nu kurun ve ilk periyodik gözden geçirmeyi yapın.
- İzleme panosunu ve KPI'ları kurun; her metriğe sahip ve eşik atayın.
- Envanterinize regülatif etiketleri ekleyin (EU AI Act risk kategorisi, KVKK kapsamı, BDDK ilgisi) ve ISO 42001 kontrolleriyle eşleyin.
- İlk çeyreklik yönetişim raporunu üretin ve yönetime sunun.

Bu planın gücü, mükemmeli değil **ölçülebilir ilerlemeyi** hedeflemesinde. 90 gün sonunda her ajanı Seviye 4'e taşımış olmazsınız; ama görünürlük, sahiplik ve temel kontroller yerinde olur. Bu, çoğu kurumun bugün bulunduğu yerden devasa bir sıçramadır. Sonrası, olgunluk tablosunda satır satır yukarı tırmanmaktan ibaret.

## Sık yapılan hatalar

Bunca projeden sonra tekrar tekrar gördüğüm tuzakları paylaşmadan bitirmek istemem. Bunları bilmek, aynı bedeli ödemeden öğrenmenizi sağlar.

- **Yönetişimi en sona bırakmak.** "Önce çalışsın, sonra yönetişimi ekleriz" en pahalı hatadır. İzlenebilirliği ve yetki sınırlarını sonradan eklemek, temeli atılmış binaya bodrum kazmaya benzer. Baştan mimariye gömün.
- **Envanteri manuel ve statik tutmak.** İlk gün doğru olan Excel, altıncı ayda kurgu haline gelir. Otomatik besleme şart.
- **Paylaşımlı kimlik kullanmak.** "Kolay olsun" diye birden çok ajana aynı kimliği vermek, denetim kaydını değersizleştirir. Kimin ne yaptığını asla ayıramazsınız.
- **Geniş yetkiyi "geçici" sanmak.** Admin yetkisiyle başlayan hiçbir ajan sonradan kısılmıyor. En az yetkiyle başlayın, gerektikçe genişletin — tersi değil.
- **İnsan onay kapısını "sürtünme" olarak görmek.** Geri alınamaz eylemlerde insan onayı sürtünme değil, sigortadır. Onu hız uğruna kaldıran, ilk büyük olayda çok daha fazlasını kaybeder.
- **Sahipliği belirsiz bırakmak.** "IT bakar" bir sahiplik modeli değildir. Her ajanın tek bir nihai sorumlusu olmalı.
- **Regülasyonu sadece hukukun işi sanmak.** EU AI Act, KVKK ve BDDK gereksinimleri teknik mimariye dokunur. Hukuk ekibi tek başına şeffaflık etiketi ya da karar izi kuramaz; bu ortak bir iştir.
- **Tedarikçi ajanını kapsam dışı bırakmak.** Hazır üründeki ajan da sizin envanterinize girer. Hesap verebilirlik satın alınamaz.
- **Yönetişimi tek seferlik proje sanmak.** Ajanlar yaşayan varlıklar; yönetişim sürekli bir döngüdür. Periyodik gözden geçirme olmadan en iyi çerçeve bile altı ayda paslanır.
- **Değeri ölçmeyi unutmak.** Yönetişimi sadece maliyet ve kısıt olarak sunarsanız kurum içinde direnç görürsünüz. İş değerini de ölçün ki yönetişim "hızlanmanın güvenli yolu" olarak anlaşılsın.

Buraya kadar okuduysanız, muhtemelen kendi kurumunuzda bu satırların bir kısmının size tanıdık geldiğini fark ettiniz. İyi haber şu: bu bir teknoloji sorunu değil, bir disiplin sorunu — ve disiplin kurulabilir. Elinizdeki ajan sayısını bugün öğrenmekle başlayın; envanterin ilk satırını yazdığınız an, yönetişim yolculuğunuz fiilen başlamış olur. Gerisi, bu yazıdaki haritayı adım adım takip etmekten ibaret.