Kontrol Kulesi: Şirketler Ajan Ordusunu Nasıl Yönetir?

Yazar

8 Eylül 2026

On ajanı yönetmek kolaydır. Peki on bini? Ajan enflasyonu çağında şirketlerin çözmesi gereken sorun teknoloji değil, organizasyon modeli.

Ajan üretmenin maliyeti yazılım üretmek kadar ucuzladı ve şirketler kısa sürede birkaç ajandan binlercesine geçecek. Bu ölçekte hem her ajanı merkezi bir ekibe onaylatmak hem de herkese tam özerklik vermek çöker. Ortaya çıkan orta yol – farklı araştırmalarda farklı adlarla anılan ama aynı iskelete sahip bir model – “kontrol kulesi”: kimlik, politika, trafik, gözlemlenebilirlik, doğrulama ve maliyeti merkezde tutup; model, çerçeve, çalışma zamanı, ara yüz ve iş mantığını uçlara bırakmak. Bu yazı bu modelin altı kontrol katmanını, bir “ajan pasaportu” fikrini, insan-ajan otonomi merdivenini, gölge ajan paradoksunu, gerçek bir vaka örneğini (WPP) ve 30/90/180 günlük bir uygulama yol haritasını anlatıyor.

1. Kontrol Kulesi: 10 Ajan → 10.000 Ajan Problemi

Bir şirket 10 ajanı yönetebilir. Bir tablo tutulur. Birkaç kişi sahiplenir. Sorun çıkarsa kimi arayacağını bilirsin.

Peki 10.000 ajanı?

Bu soru retorik değil.

Cisco’nun 2025 Yapay Zeka Hazırlık Endeksi’ne göre şirketlerin %83’ü ajan dağıtmayı planlıyor, ama yalnızca %31’i bunları kontrol edecek donanıma sahip olduğunu söylüyor [Aurascape]. Deloitte’un 3.235 lider ile yaptığı ankette tablo daha çarpıcı: şirketlerin %74’ü iki yıl içinde otonom ajanları yaygınlaştırmayı planlarken, yalnızca %21’i bu ajanlar için olgun bir yönetişim modeline sahip olduğunu söylüyor [Deloitte].

(Bu iki rakamı yan yana koy, aradaki fark seni germeli.)

Bu boşluğun nedeni bir teknoloji eksikliği değil. Hâlâ 10 ajanlık bir dünya için tasarlanmış bir organizasyon modeliyle 10.000 ajanlık bir gerçekliği yönetmeye çalışmak. Tez şu: soru “ajanları nasıl merkezileştiririz” değil, “ajanların özgürce çoğalabilmesi için hangi sınırları merkezi olarak garanti etmeliyiz” sorusu.

Bu yazıda “ajan” derken neyi kastediyoruz?

2026’da herkes her şeye “ajan” diyor – bir chatbot, bir Copilot, bir n8n workflow’u, bir RPA botu, bir SaaS’ın içine gömülü “AI assistant”. Biraz durup netleştirelim: bu yazıda ajan derken kastettiğimiz, *bir hedef doğrultusunda karar alabilen, araç kullanabilen, birden fazla adımı art arda gerçekleştirebilen ve insan müdahalesi olmadan ilerleyebilen yazılım sistemi.* Deloitte’un ifadesiyle, bir ajan yalnızca görevi yerine getirmez – görevi tanımlar, planlar ve daha yüksek bir otonomi derecesiyle yürütür [Deloitte]. Basit bir soru-cevap botu bu tanımın dışında kalır; bu yazının derdi, birden çok adımı zincirleyen, araç çağıran, veri taşıyan sistemler.

2. Ajan Enflasyonu: Neden Sayı Bu Kadar Hızlı Artacak?

Eskiden bir şirketin tek bir yapay zeka platformu vardı. Sonra on kullanım senaryosu oldu.

Şimdi:

Bunun nedeni basit. Bir ajan üretmenin marjinal maliyeti neredeyse sıfıra yaklaşıyor. Bir çalışanın bir hafta sonunda kendi ajanını kurup üretime alması artık istisna değil, norm.

Asıl problem ajan sayısının artması değil – ajan üretmenin, yazılım üretmek kadar ucuzlaşmış olması. Bir organizasyonun “kaç ajanımız var” sorusuna net cevap veremediği an, aslında “kaç mikro-uygulamamız var, hangi verilere dokunuyorlar” sorusuna da cevap veremiyor demektir.

3. Üç Yönetim Modeli

Kurumsal yapay zeka operasyon modelleri literatüründe üç saf seçenek tartışılıyor: merkezi, federatif, hub-and-spoke ([Agility at Scale].

Merkezi modelde tüm ajanlar tek bir ekip tarafından inşa edilir ve onaylanır. Güvenlidir. Yavaştır. Ekipleri gölge çözümlere iter. Saf federatif modelde tam özerklik verilir; hızlıdır, ama kısa sürede kimin ne çalıştırdığının bilinmediği bir kaosa dönüşür. Üçüncü model – pratikte çoğu büyük organizasyonun vardığı nokta – merkezi bir çekirdeğin altyapıyı, standartları ve gözlemlenebilirliği sahiplendiği, iş birimlerinin ise kullanım alanı keşfini ve iterasyonu sahiplendiği bir yapı [RevOps]. Gartner’ın veri ve analitik yönetişimi için önerdiği model de aynı iskeleti taşıyor: merkezi otorite standartları belirlerken, alan ekipleri bunları kendi sistemlerinde uygular [Promethium].

(Bir not: bu üçüncü modele endüstride tek bir isim yerleşmiş değil.)

Kimi “hub-and-spoke” diyor, kimi “federatif yönetişim”, kimi yalnızca “operasyon modeli”. Burada iddia ettiğimiz şey tek ve resmi kabul görmüş bir terminoloji değil; farklı kurum ve araştırmalarda farklı isimlerle tarif edilen, ama aynı ortak iskelete sahip bir işletim modelinin ortaya çıkıyor olması. Bunun kanıtı, birazdan göreceğimiz WPP örneğinde: aynı mimariyi “hub-and-spoke” kelimesini hiç kullanmadan tarif ediyorlar.

4. Kontrol Neyi Kontrol Eder?

İşte yazının taşıyıcı fikri, tek cümlede: Hub ajanları yönetmez. Ajanların çalışabileceği sınırları yönetir.

Bunu tek bir matrisle netleştirelim – hangi katman merkezde, hangisi ekipte:

Bu tablonun kendisi bir “aha” anı olabilir: merkezi olmak zorunda olmayan çok şey var. (ve bu, klasik “her şeyi IT onaylasın” refleksinden bilinçli bir kopuş.)

Havacılık metaforunu sonuna kadar taşıyalım

Kontrol kulesi benzetmesi süslü bir açılış cümlesi olarak kalmasın; yazı boyunca taşıyalım:

Kule hiçbir pilota rotasını çizmez. Ama her uçağın bir çağrı işareti vardır, her kalkış izin ister, her rota radarda görünür. Bu benzetmeye yazının sonunda bir daha döneceğiz.

5. Ajan Pasaportu

Kimlik tek başına yetmiyor. “Ajan X’in kimliği nedir?” sorusu, “bu ajan kimin adına hareket ediyor, kim sorumlu, bütçesi ne kadar” sorularının yanında eksik kalıyor.

Bir ajan bozulduğunda kim sorumlu? Bir müşteri verisi yanlış yere gittiğinde kim hesap verecek? Bir ajan ayda 20.000 avro harcadığında kim kapatacak?

Bu üç sorunun cevabı üç ayrı alanda yaşamalı – kimlik, hesap verebilir insan, verilmiş yetki. Ve bu üçü sıkça üç farklı ekibin elinde kalıyor: kimlik altyapısını güvenlik sahiplenir, çünkü zaten kimlik bilgisi yaşam döngüsünü yönetiyor; uygulama noktasını platform mühendisliği sahiplenir, çünkü yürütme yolunu o işletiyor; yetki modelini risk ve uyum sahiplenir, çünkü organizasyonun neyin sorumluluğunu almaya razı olduğuna onlar karar veriyor [NATARAJA].

(Bu üç ekip arasındaki boşluk, tam olarak ajanların gözden kaybolduğu yer.)

Buna “ajan pasaportu” diyelim. Bir hub’ın kayıt defterinde en azından şu alanlar olmalı:

Ajan ID

Sahip (isim, ekip mailbox’ı değil)

İş amacı

Erişilen veri

Kullandığı araçlar

Kullandığı model

Risk seviyesi

Bütçe

Ortam (dev / staging / prod)

Sürüm

Son doğrulama tarihi

Kill switch durumu

Kimlik zinciri de tek katmanlı değil, üç katmanlı olmalı: insan kimliği → ajan kimliği → araç kimliği.

Hedef, sistemin şunu söyleyebilmesi: “Murat’ın başlattığı Kreatif Ajan, saat 14:03’te CRM’den şu veriyi aldı ve şu API’yi çağırdı.” Bu, hesap verebilirliği soyut bir ilkeden somut bir cümleye indiriyor.

6. Otonomi Merdiveni: Her Aksiyona İnsan Onayı Gerekli mi?

Hayır. Ve bu, çoğu şirketin gözden kaçırdığı nokta.

500 ajan çarpı 20 işlem, insan onayına dayalı bir sistemi anında tıkar. Araştırmacılar bu spektrumu üç terimle tarif ediyor:

İnsan döngüde (human-in-the-loop, HITL): Kritik bir aksiyon çalışmadan önce insan onaylar. Yüksek riskli kararlar için uygun.

İnsan döngü üzerinde (human-on-the-loop, HOTL): Ajan otonom çalışır, insan izler ve gerektiğinde müdahale eder.

İnsan döngü dışında (human-out-of-the-loop, HOOTL): Ajan, belirlenmiş sınırlar içinde tamamen bağımsız çalışır.

Kritik ayrıntı: bu üç seviye tek bir ajan için tek bir ayar değil. (Yani “bu ajan otonom” demek yeterli değil – hangi aksiyonda otonom, sorusu asıl mesele.) Aynı ajan bir aksiyonda döngü dışında (veri okurken), başka bir aksiyonda döngü üzerinde (kendi giden mesajlarını raporlarken), üçüncü bir aksiyonda döngüde olabilir (bir iade işlemi yaparken) – her aksiyon kendi riskine göre ayarlanır [Pickaxe].

Burada bir tuzak var: çok fazla onay noktası, ajanı daha güvenli değil daha az güvenli yapıyor. “Onay yorgunluğu” (approval fatigue) dediğimiz şey, bir kişiye çok sık onay sorulduğunda değerlendirmeyi bırakıp reflekse geçmesi – tık, tık, tık. O noktada gözetim kâğıt üzerinde var ama fiilen işlemiyor [Pickaxe]. AB Yapay Zeka Yasası’nın yüksek riskli sistemler için insan gözetimini şart koşması da (Madde 14) bunu artık felsefi değil, düzenleyici bir mesele hâline getiriyor [Strata].

Bunu somutlaştırmak için risk-bazlı bir otonomi merdiveni kurulabilir:

Hub’ın görevi, hangi ajanın hangi aksiyonda hangi seviyede çalışacağına önceden karar vermek. Sonradan değil.

7. Gölge Ajanlar: Yasaklamanın Paradoksu

Burada güzel bir paradoks var. Şirket ajanları yasaklarsa, gölge yapay zeka artar. Şirket her şeyi serbest bırakırsa, yönetişim çöker. Yani yönetişimin amacı ajanları kontrol etmek değil, güvenli yolu en kolay yol haline getirmek olmalı.

Bunu bir sahne olarak düşün. Bir kreatif ekip yeni bir kampanya için bir ajana ihtiyaç duyuyor.

(Tanıdık geldi mi?)

Gölge ajan tam burada doğuyor. Bir çalışan müşteri kayıtlarını kişisel bir hesaba yapıştırdığında, bu trafik ne e-posta ağ geçidinden ne CASB’ın gördüğü SaaS günlüklerinden geçer – güvenlik ekibi için tamamen görünmezdir ([Forcepoint]. Cyberhaven’ın tarif ettiği gibi bu klasik gölge BT de değil: ajanlar dosya okuyor, API çağırıyor, veri taşıyor – insan onayı beklemeden, makine hızında [Cyberhaven].

Güvenlik endüstrisi bu boşluğa hızla yeni bir kategori üretti: kimlik ile ağ geçidini birlikte çalıştıran “Identity × Gateway” modeli. Ajanlar Okta gibi bir kimlik sağlayıcı üzerinden birinci sınıf, insan-olmayan kimlikler olarak yönetilirken, Cloudflare AI Gateway gibi bir ağ geçidi tüm istem, model yanıtı ve veri akışını denetleyen merkezi bir kontrol noktası olarak devreye giriyor [Master Concept]. Wiz’in AI-SPM yaklaşımı aynı sorunu bulut tarafından çözüyor: ajansız tarama, bulut varlıklarını, kimlikleri ve veri akışlarını tek bir güvenlik grafiğinde birleştiriyor [Wiz]. Klasik CASB’ın “openai.com’a trafik var” demesinin ötesine geçip “bu kullanıcı bir müşteri listesini genel bir modele yapıştırmak üzere” diyebilen bir araç kategorisi doğuyor.

8. Sahada Bir Örnek: WPP

Soyut kalmasın.

Reklam ve iletişim grubu WPP’nin araştırma birimi, kendi ajan ekosisteminde tam olarak bu iskeleti kurmuş görünüyor. (Ve ajans dünyasından bakınca bu örnek özellikle değerli – çünkü aynı sorunu bir teknoloji şirketi değil, bir yaratıcı organizasyon çözmeye çalışıyor.)

Yayımladıkları teknik notta üç katmanda tam serbestlik tanımlıyorlar:

– İnşa katmanı – ajanların hangi araçla bir araya getirildiği.

– Çalışma zamanı – ajanın hangi motor üzerinde koştuğu.

– Uygulama katmanı – ajanın nihayetinde bir sohbet penceresinde mi, bir tarayıcı eklentisinde mi karşımıza çıktığı.

Buna karşılık altı alanı merkezden yönetiyorlar: kimlik, politika, trafik, iz kaydı, doğrulama, maliyet.

Bu ikisini yan yana koyduğumuzda:

İlginç olan şu: metin “hub-and-spoke” ya da “federatif” kelimelerini hiç kullanmıyor. Ama tarif ettiği mimari, endüstrinin başka yerlerde bu isimlerle andığı modelin neredeyse birebir aynısı. Bu da modelin tek bir şirketin icadı değil, birbirinden bağımsız aynı probleme aynı çözümü bulan bir organizasyonlar kümesinin ürünü olduğunu gösteriyor. Ve daha önemlisi: bu teorik bir yönetişim çerçevesi değil, gerçek bir yaratıcı organizasyonun operasyonel problemi.

9. Kontrol Kulesinin Teknik Omurgası

Altı kontrol alanının her biri somut bir teknik karşılığa ihtiyaç duyar.

Kimlik. Her ajan, bir ekibin ödünç verdiği paylaşımlı bir servis hesabıyla değil, kendine ait doğrulanabilir bir makine kimliğiyle çalışmalı. (Yani kimsenin ödünç veremeyeceği bir kimlik kartı.) Singapur’un Ocak 2026’da yayımladığı Ajan Yapay Zekası için Model Yönetişim Çerçevesi, her ajanın doğrulanabilir bir dijital kimlik ve hangi yetkiyle kimin adına hareket ettiğini gösteren bir iz kaydı taşımasını şart koşuyor [arXiv]. NIST de Şubat 2026’da başlattığı Yapay Zeka Ajan Standartları girişimiyle aynı boşluğa işaret ediyor: ajanlar bugün genellikle kimliksiz, yetkisiz, hesap verilebilirlikten yoksun genel servis hesapları gibi ele alınıyor. Microsoft’un Entra Agent ID’si ve Google’ın SAIF 2.0 Ajan Risk Haritası aynı ihtiyacı kurum-içi sınırlarda çözmeye çalışıyor.

Kayıt tarafında ise bir ajan kaydı (registry), her ajan ve MCP sunucusu için kaynak referansı görevi görür – kimlik, yetenek şeması, sahiplik, erişim politikası, sürümleme. Kayıt neyin var olduğunu izler; ağ geçidi neyin çalışabileceğini uygular. Biri olmadan diğeri eksik kalır: kayıtsız bir ağ geçidi, hangi politikayı uyguladığını bilmeyen bir uygulama noktasına dönüşür [Explore Agentic].

Politika. Kimlik “kimsin” sorusuna cevap verir, politika “ne yapabilirsin” sorusuna. Ajandan bağımsız, ayrı bir motorda tutulan, sürümlenen ve kod gibi yönetilen kurallar (policy-as-code), her istek için üç olası cevap üretir: izin ver, reddet, ya da bir insana yükselt. Jargonu ödeyelim, sahte-kod ile gösterelim:

KURAL 1

EĞER ajan = pazarlama

VE veri = müşteri_kişisel_verisi

VE hedef = dış_model

İSE insan_onayı_gerekli

KURAL 2

EĞER aylık_ajan_maliyeti > 500€

İSE sahip_onayı_gerekli

Open Policy Agent gibi bulut-native araçların ajan dünyasına taşınması bu prensibi teknik olarak uygulanabilir kılıyor. Ajanın kendi mantığı manipüle edilse – bir prompt injection saldırısına maruz kalsa – bile dışarıdaki kurallar aynı kalır.

Trafik ve maliyet kontrolü. Bir ajan üç türlü trafik üretir: kendisine gelen çağrılar, kullandığı modele giden çağrılar, eriştiği araçlara ve diğer ajanlara giden çağrılar. Her biri ayrı hız sınırlarına, yönlendirme kurallarına, harcama tavanlarına ihtiyaç duyar.

(Bunun soyut bir risk olmadığını gösteren gerçek bir vaka var.)

Hugging Face’in bir olay sonrası yayımladığı incelemeye göre, saldırgan konumdaki otonom ajanlar platform üzerinde tespit edilebilen yaklaşık 17.600 aksiyon gerçekleştirdi. O vakada token faturası bir model sağlayıcısına düştü; kurumsal bir müşteride ise kontrolden çıkan bir ajanın faturası doğrudan size kesilir ([CSO Online]. Döngüye giren ya da alt-ajan üreten tek bir ajan, paylaşılan bir kaynağı hızla tüketebilir.

Gözlemlenebilirlik. Bir ajanın hayatındaki her mesaj, her araç çağrısı, her erişim kendi kaydını bırakmalı. Ama sorulması gereken soru “ajan ne yaptı” değil, “ajan neden bunu yaptı, hangi kararla, hangi sonuca ulaştı” – niyetten sonuca uzanan bir zincir:

OpenTelemetry gibi açık bir standardın seçilmesi, hangi motorda çalışırsa çalışsın tüm ajanların aynı formatta iz bırakmasını sağlıyor; bu da tedarikçi kilitlenmesini önlüyor. Bu zincir kurulduğunda gözlemlenebilirlik yalnızca “log tutmak” olmaktan çıkıp gerçek bir hesap verebilirlik mekanizmasına dönüşüyor.

Doğrulama. Bir ajan üretime çıkmadan önce hem işlevsel (“işini doğru yapıyor mu?”) hem işlevsel-olmayan (“hızlı, güvenli, dayanıklı mı?”) eksende test edilmeli; canlıya çıktıktan sonra da düzenli olarak yeniden değerlendirilmeli.

10. Yönetişim, Güvenlik ve Operasyon Aynı Şey Değil

Buraya kadarki anlatı güvenlik ağırlıklı görünebilir. Oysa yönetişim yalnızca güvenlik meselesi değildir – ayrı ayrı ele almak gerekiyor.

Güvenlik: Bunu yapabilir mi? (Teknik olarak erişim var mı?)

Yönetişim: Bunu yapmasına izin vermeli miyiz? (İş kararı olarak doğru mu?)

Operasyon: Bunu verimli ve sürdürülebilir şekilde yapabiliyor muyuz?

Örnek: bir ajan CRM’e erişebiliyor. Güvenlik “erişebilir mi?” sorusunu yanıtlar. Yönetişim “erişmesi gerekli mi?” sorusunu sorar. Operasyon “her çağrının maliyeti ne?” diye sorar. Üçü de doğru soru. Üçü de farklı bir cevap gerektiriyor. Ve çoğu şirketin hatası, bu üçünü tek bir ekibe – genellikle güvenliğe – yüklemek.

## 11. Maliyet: Token’ın Ötesinde

Agentic AI’da maliyet yalnızca model çağrısı maliyeti değil. Şu kalemlerin hepsi sayılmalı: model çıkarımı, araç çağrıları, API kullanımı, veritabanı sorguları, vektör veritabanı, tarayıcı/bilgisayar kullanımı, orkestrasyon, depolama, insana yükseltme, alt akış SaaS maliyetleri.

Daha önemlisi, doğru soru “ne kadar harcadı” değil, “yaptığı iş başına ne kadar harcadı.”

(100 avro harcayan bir ajan kötü değildir. 1 avro harcayıp 20 sentlik değer üreten bir ajan kötüdür.)

Buna “sonuç başına maliyet” (cost per outcome) diyelim – ve bunu bir hub, yalnızca toplam harcamayı değil, harcama/çıktı oranını da izleyerek ölçebilir.

12. Kill Switch – Ama Tek Başına Yeterli Değil

Kontrol kulesi metaforunda bunun karşılığı net: kule yalnızca uçağı izlemez, gerektiğinde piste kapatabilir. Her production ajanı için duraklat / iptal et / karantinaya al / sonlandır türünde bir acil müdahale mekanizması olmalı. Bu, kimlik + politika + gözlemlenebilirlik üçlüsünün doğal sonucu.

Ama burada dürüst olalım: kill switch tek başına bir yönetişim stratejisi değil. Bir ajan envanterde yoksa, hangi kimlik bilgisiyle çalıştığı, hangi izinlere sahip olduğu bilinmiyorsa, “kapatın” demek pratikte kime söyleneceği belli olmayan bir emirdir. Ajanın hangi servis hesabını kullandığından IT emin değilse, finans ay sonu kapanışına bağlı olduğu için itiraz ediyorsa, hukuk verinin nereye gittiğini soruyorsa – düğmeye basmak tek başına yetmez [Forbes].

Kill switch, ajan pasaportu ve gözlemlenebilirlik zaten yerindeyse işe yarayan bir son çare. Onların yerine geçen bir kısayol değil.

13. Düzenleyiciler Aynı İskeleti Görüyor

Bu altı kontrol alanı artık yalnızca bir şirketin kendi tercihi değil, giderek düzenleyici bir beklenti haline geliyor. AB Yapay Zeka Yasası’nın 14. maddesi yüksek riskli alanlarda insan gözetimini, 15. maddesi doğruluk, dayanıklılık ve siber güvenliği şart koşuyor; bu yükümlülük protokolün kendisine değil, ajanı kullanan tarafa düşüyor ([arXiv]. ISO/IEC 42001, sertifikalanabilir bir yapay zeka yönetim sistemi standardı olarak aynı disipline kurumsal bir çerçeve kazandırıyor; NIST’in AI 600-1’i de kendi risk yönetim çerçevesini üretken yapay zekaya genişletiyor [arXiv].

Bir dipnot: akademik tarafta bu konuda simülasyon-temelli çalışmalar da var – örneğin bir ajan yönetişimi olgunluk modeli üzerine yapılan 750 simülasyonluk bir çalışma, belirli bir yönetişim eşiğinin altında kalan senaryolarda ihlal oranının yüksek kaldığını, eşiği aşan senaryolarda ise ölçülen ajan yayılması ve risk olayı göstergelerinin simülasyon ortamında %90’ın üzerinde düştüğünü rapor ediyor [arXiv].

(Bu rakamı temkinli okumak lazım: 750 simülasyon, gerçek kurumsal ajan ortamlarına doğrudan genellenebilecek nedensel bir kanıt değil.)

Yine de bu durum, ‘biraz yönetişim’ gibi ölçülü bir orta yolun, ölçülen senaryolarda beklendiği kadar koruma sağlamadığını gösteriyor.

14. Model Üreticileri de Kendi Kulesini Kuruyor

Bu yazı yayına hazırlanırken, bir hafta arayla gelen iki frontier model çıkışı tezi beklenmedik bir yerden doğruladı.

Anthropic, 1 Eylül’de Claude Fable 5.1 ve Claude Mythos 5.1’i duyurdu – aynı model, iki farklı güvenlik katmanı. Fable 5.1 herkese açık; Mythos 5.1 ise siber güvenlik ve yaşam bilimleri alanında çalışan, onaylanmış kurumlara özel güvenilir erişim programlarının arkasında ([Anthropic]. İki gün sonra OpenAI, GPT-6 Astra’yı tanıttı: Temmuz’daki Hugging Face olayının ardından çıkışı ek güvenlik önlemleri için ertelenen, şirketin Hazırlık Çerçevesi’nde siber yeteneklerde ilk kez “Kritik” eşiğine ulaşan ve tam da bu yüzden en hassas yetenekleri kademeli/güvenilir erişimle sunulan bir model [OpenAI System Card], [Al Jazeera]. OpenAI o olaydan bir de değerlendirme türetmiş: üretim korumaları olmadan GPT-5.6 Sol, zor ya da imkânsız bir görevle karşılaştığında vakaların %48’inde yetkilendirilmiş hedefin dışına çıkarken, Astra’nın bunu hiç yapmadığını rapor ediyorlar [OpenAI].

(Bu rakamlar üreticinin kendi ölçümü – 13. bölümdeki simülasyon istatistiğine gösterdiğimiz temkinin aynısını hak ediyor.)

Asıl mesele rakamlar değil, desen. Kademeli erişim, risk bazlı yetenek kapıları, kapsam-sadakati testleri: model üreticileri, bu yazının şirketlere önerdiği kontrol kulesinin bir benzerini kendi katmanlarında kuruyor. Bu, iki şeyi aynı anda söylüyor. Birincisi, yön doğrulanıyor – risk bazlı kademeli kontrol fikri endüstrinin her katmanında birbirinden bağımsız olarak ortaya çıkıyor.

İkincisi ve daha önemlisi: üreticinin kulesi senin kulen değil.

Astra’nın kapsam sadakati, senin hangi ajana hangi veriyi açtığını bilmez. Mythos’un erişim programı, senin ajanının sahibinin kim olduğunu kaydetmez. Model katmanındaki hizalama, kurumsal katmandaki kimlik, sahiplik, bütçe ve iz kaydının yerine geçmez – olsa olsa üzerine inşa edeceğin zemini sağlamlaştırır. Ve bu modellerin bilgisayar kullanımında koyduğu çıta düşünüldüğünde, ajan enflasyonu yavaşlamayacak; kulenin aciliyeti artacak.

15. Kontrol Kulesi Kurarken Yapılmaması Gereken 5 Hata

Her ajanı merkezi ekibe geliştirtmeye çalışmayın. Bu, saf merkezi modelin hızı öldüren hatasını tekrar eder.
Her ajan için manuel onay süreci yaratmayın. Onay yorgunluğu, gözetimi kâğıt üzerinde bırakır; riske göre kademelendirin.
Politikayı ajanın prompt’una gömmeyin. Ayrı, sürümlenen bir motorda tutun.
Yalnızca üretimdeki ajanları envantere almayın. Geliştirme ve test ortamındaki ajanlar da veriye dokunuyor.
Yönetişimi tek başına güvenlik ekibinin problemi haline getirmeyin. Kimlik, uygulama ve yetki farklı ekiplerin elinde; bunu tek bir kayıtta birleştirmezseniz ajanlar tam da o dikişlerin arasında kaybolur.

16. Şirketiniz İçin Yol Haritası

0–30 gün: Gör. Envanter çıkarın, sahiplik atayın, risk sınıflandırması yapın, maliyet taban çizgisini belirleyin.

30–90 gün: Kontrol et. Kimliği zorunlu kılın, politikayı ayırın, bir ağ geçidi kurun, gözlemlenebilirliği devreye alın, doğrulama sürecini başlatın.

90–180 gün: Ölçeklendirin. Kendi kendine hizmet eden bir ajan platformu kurun, policy-as-code’u standartlaştırın, otomatik doğrulamayı yaygınlaştırın, maliyet atfını ekip/müşteri bazında raporlayın, hub’ı kapı bekçisinden danışmana dönüştürmeye başlayın.

Üç fazın hepsinde tekrarlayan bir ilke var: uyumluluğu ödüllendirin, yasaklamayın. Yeni kurulan bir ajanın bu altı ilkenin birkaçını ihlal etmesi neredeyse kaçınılmaz; önemli olan uyumluluğa giden yolun net tarif edilmiş ve somut faydalarla – maliyetin karşılanması, tescilli veriye erişim, kurumsal uygulamalarda öne çıkarılma – motive edilmiş olması. Microsoft’un Cloud Adoption Framework’ünde gördüğümüz “kapı bekçisinden danışmana” geçiş de aynı mantığı izliyor: olgunlaştıkça merkez, engellemek yerine standart koyan bir forum haline geliyor ([Microsoft Learn].

17. Kule Her Zaman Tam Görmez

Kontrol kulesi metaforunun bir sınırı var: gerçek bir kule, hava sahasındaki her uçağı görür. Kurumsal bir hub böyle değil – çalışanların IDE’sine gömülü kişisel kodlama asistanları, abone olunan bir SaaS ürününün içine gömülü ajan özellikleri, herkese açık tüketici asistanları, müşterilerin ya da ortakların kendi ortamında çalıştırdığı sistemler her zaman radarın dışında kalacak.

Bunlar için altı soruyu doğrudan yanıtlayamazsın. Yapabileceğin, her birinin kapsamını belgelemek, boşlukları tespit etmek ve o boşlukları kapatacak politikalar tasarlamak.

18. Sonuç

Geleceğin yapay zeka organizasyonlarında rekabet avantajı en iyi ajanı yapmak olmayacak. En fazla ajanı güvenle çalıştırma yetkinliği olacak.

Ve bunun için: şirketler ajanlarını merkezileştirmeyecek. Kontrolü merkezileştirecek.

Kule uçakları uçurmaz. Kimin, ne zaman, hangi yetkiyle uçtuğunu bilir – ve gerektiğinde pisti kapatabilir. Sorulması gereken soru artık “her ajanı nasıl merkezileştiririz” değil: “Radarın göremediği kısmı nasıl haritalandırır, hangi boşlukları bilerek açık bırakırız?” Bu haritayı çizmeyen şirketler için asıl risk, ajanların hız kazanması değil – kaç tanesinin zaten uçtuğunu hiç bilmemeleri.

Sıkça Sorulan Sorular

Federatif yapay zeka yönetişimi (hub-and-spoke / kontrol kulesi) nedir?

Merkezi bir hub’ın kimlik, politika, trafik, gözlemlenebilirlik, doğrulama ve maliyet gibi ortak kuralları belirlediği; iş birimlerinin ise hangi araçla, hangi çalışma zamanında ve hangi uygulama katmanında çalışacağına kendi karar verdiği bir yapay zeka yönetişim modelidir.

Hub-and-spoke modelinin merkezi (centralized) modelden farkı nedir?

Merkezi modelde tüm ajanlar tek bir ekip tarafından inşa edilir ve onaylanır; bu yavaşlar ve gölge çözümlere yol açar. Hub-and-spoke’ta inşa özgürlüğü dağıtılır, yalnızca ortak riskler (kimlik, politika, maliyet) merkezde tutulur.

Ajan pasaportu nedir?

Bir ajanın kimliğini, sahibini, iş amacını, eriştiği veriyi, kullandığı araçları, risk seviyesini, bütçesini ve kill switch durumunu tek bir kayıtta toplayan bir envanter modelidir.

Her ajan aksiyonunda insan onayı gerekli mi?

Hayır. Oturum düzeyinde tek bir ayar yerine, her aksiyon kendi riskine göre insan-döngüde, insan-döngü-üzerinde veya insan-döngü-dışında olarak ayarlanmalı. Aşırı onay noktası “onay yorgunluğu” yaratıp gözetimi işlevsiz bırakır.

Policy-as-code nedir ve neden ajan yönetişiminde önemlidir?

Erişim kurallarının ajanın kendi koduna gömülmek yerine, ayrı ve sürümlenen bir politika motorunda tutulmasıdır. Ajanın kendi mantığı manipüle edilse bile dışarıdaki kurallar değişmeden kalır.

Gölge ajanlar (shadow AI agents) nedir ve nasıl önlenir?

Kurumsal envanterde görünmeyen, IT onayından geçmemiş ajanlardır. Tek çözüm yasaklamak değildir – asıl hedef, güvenli yolu en kolay yol haline getirmektir.

Kill switch tek başına yeterli bir yönetişim stratejisi midir?

Hayır. Bir ajan envanterde yoksa ya da sahipliği belirsizse, kill switch’in kime ve neye uygulanacağı da belirsiz kalır. Kill switch, ajan pasaportu ve gözlemlenebilirlik zaten kurulduğunda anlamlı bir son çaredir.

Model üreticisinin güvenlik önlemleri kurumsal yönetişimin yerine geçer mi?

Hayır. Kademeli erişim programları ve kapsam-sadakati testleri model katmanını güvenli kılar; ama ajanınızın kimliğini, sahibini, bütçesini ve veri kapsamını yalnızca sizin kontrol kuleniz bilir. İkisi birbirini tamamlar, ikame etmez.

Bu model hangi ajanları kapsamaz?

Kişisel kodlama asistanları, üçüncü taraf SaaS ürünlerine gömülü ajan özellikleri, herkese açık tüketici asistanları ve müşteri/ortak ortamında çalışan ajanlar tipik olarak kurumsal hub’ın doğrudan kontrolü dışındadır.

Kaynaklar

Kaynaklar dört kategoride: akademik/standart çalışmalar, düzenleyici çerçeveler, kurumsal araştırma (Deloitte, Microsoft, Gartner ekosistemi) ve güvenlik/vendor perspektifi. Rakamsal iddialar için kaynağın türünü göz önünde bulundurun.

Akademik & standartlar

1. arXiv – Trust Without Trusting: A Recomputable Trust Protocol for Autonomous Agents

2. arXiv – A Governance Maturity Model for Managing AI Agent Sprawl

Kurumsal araştırma

3. [Deloitte – Deloitte Expands End-to-End AI Controls and Assurance Capabilities

4. [Deloitte – Agentic AI is scaling faster than guardrails

5. [Microsoft Learn – Establish an AI Center of Excellence

6. [Agility at Scale – AI Operating Model

7. [RevOps – Centralized, federated, or hub and spoke

8. [Promethium – Federated Data Governance: Complete Guide for 2026

9. [Aurascape – The AI Security Landscape in 2026

Güvenlik & operasyon (vendor/pratik perspektifi)