Bu yazı, konuk yazarımız Commencis CIO’su Duru Kızılkayak tarafından yazılmıştır. Yazının İngilizcesi ayrıca Duru Kızılkayak’ın Medium sayfasında yayımlanmıştır.
Kurumların AI’a “hazır” olması gerçekte ne anlama geliyor?
Yakın zamana kadar kurumsal yapılarda en sık sorulan soru olan “AI kullanmalı mıyız?” artık çok da
anlamlı gelmiyor.
Çoğu kurum çoktan “evet” dedi. Copilot’lar devreye alındı. GPT tabanlı uygulamalar yayında. En azından
kağıt üstünde verimlilik arttı. Kod daha hızlı yazılıyor, taslaklar anında çıkıyor, soruyu tamamlamadan
cevap geliyor.
Yine de bir şeyler eksik.
Büyük ve kompleks organizasyonlarda gördüğüm ise AI yetkinliklerinden çok, AI’a hazırlıkta eksik
olmaları. Çıktı üretme kapasitesi ciddi şekilde hızlandı ancak tasarlama, yönetme ve uygulama kapasitesi
aynı hızda gelişmedi.
Hangi varsayımlarla, nereye gittiğimizi bilmeden hızlanıyoruz. Asıl zorluk burada başlıyor.
Kurumsal dünyada AI’a hazır olmak, hangi modeli seçtiğinizle veya demoların ne kadar etkileyici olduğu
ile ilgili değil.
Asıl mesele, hızın kalıcı bir şey üretebilir hale gelip gelmediği yani denetlenebilir, güvenilebilir ve
açıklanabilir sistemler kurup kuramadığınız.
Özellikle de yapay zeka tabanlı mimarilere ve ekosistem düzeyinde etkileşime doğru gitmeyi hayal
ederken. Örneğin; hava yolu, sadakat ve seyahat platformlarının uçtan uca rezervasyon yolculuğunun
MCP ve A2A tabanlı ajan etkileşimleriyle tek sistem halinde koordine edildiği bir ekosistem deneyimi
hayat ettiğimizde, ilişkili tüm kurumsal sistemlerin aynı seviyede hazır olması gerekiyor.
Bu yazıda ele almak istediğim boşluk da tam olarak bu.
Kurum İçi Hazırlıktan Yapay Zeka Ekosistemine
Son bir yılda sohbetler sessizce yön değiştirdi.
Artık sadece kurum içindeki AI’ı değil, kurumlar arası AI’ı konuşuyoruz. Agent-to-agent etkileşimleri,
paylaşılan bağlamlar, ekosistem düzeyinde iş akışları.
Commencis’in düzenlediği AI NOW etkinliğinde, gerçek değerin şirket içi optimizasyonlardan değil, şirket
sınırlarının ötesine geçebilen koordineli sistemlerden çıkacağı fikrini ele almıştım.
Fakat bu hedefin kaçınılmaz bir gerçeği var: AI ekosistemi, kırılgan temeller üzerine kurulamaz.
Kurum içinde karar sahipliği belirsizse, ekosisteme geçince de sihirli şekilde netleşmeyecek.
İçeride açıklanamayan çıktılar, dışarıda yönetilemez hale gelecek.
Bugün; kontrol, sahiplik ve denetim sonradan düşünülüyorsa, yarın AI ajanlarının birlikte çalıştığı
ortamlarda risk katlanacak.
Bu yüzden AI ekosistemini konuşmadan önce, sistemlerin gerçekten nasıl tasarlandığı, işletildiği ve
güvenildiği üzerinden kurum içi hazırlığı konuşmak gerekiyor.
İşte, hızla yapı arasındaki boşluğun artık göz ardı edilemediği nokta tam da burası.
Neden Single-LLM ve GPT Wrapper yaklaşımları tıkanıyor?
Single-LLM sistemleri ve GPT benzeri wrapper’lar başlangıçta şaşırtıcı derecede iyi çalışıyor. Hafif,
ulaşılabilir, sihirli hissi veriyor. Tek komut ile güvenli bir cevap geliyor ve ilk kazanımlar hızlı.
Fakat, bankacılık, finansal hizmetler ve sigortacılıkta işler nadiren tek adımda gerçekleşiyor. Süreç
katmanlı, regüle ediliyor ve hesap verilebilirlik üzerine kurulu; her adımın farklı bir sahibi, farklı bir SLA’i,
farklı bir regülasyon yükü ve farklı bir denetim alanı var.
Bu nedenle, tek model yaklaşımları kurumsal kullanımlarda şu noktalarda hemen zorlanıyor:
★ regülasyon yükümlülüklerini özetleme
★ hukuki etkisi olan müşteri iletişimleri hazırlama
★ risk, sahtecilik veya hasar analizini destekleme
★ birden fazla iç sistemi koordine etme
Hata biçimi genellikle aynı. Çıktı makul görünse de, gerekçe belirsiz ve sahiplik net değil.
Ve sahiplik olmadan hız avantaj değil, riske dönüşüyor.
Kod yazımı hızlandı. Sistemler hızlanmadı.
Bu ikilem en çok yazılımda gözlemleniyor.
NVIDIA gibi şirketler ve Cursor, GitHub Copilot ve OpenAI’nin LLM platformları gibi verimlilik araçlarının
sağladığı ilerlemelerle, artık büyük kod tabanları daha önce görülmemiş hızlarla üretilebiliyor.
Ancak kod yazmak daha hızlı hale gelirken, sistemler hâlâ zor inşa ediliyor.
Kurumsal sistemler, dosya koleksiyonları değil.
Kurumsal sistemler, anlamlı görev çözümlemesine, uygulama adımlarının doğru sıralanmasına, açıkça
belirlenmiş kısıtlamalara (güvenlik, uyumluluk, performans) ve görünür, gözden geçirilebilir ve
sahiplenilmesi gereken varsayımlara dayalı kararlar ağları.
Yapay zeka kod üretebilir. Ancak hangi varsayımların yapıldığını, hangi kısıtlamaların basitleştirildiğini
veya gerçek operasyonel riskin nerede olduğunu doğal olarak göstermez.
Bu hangi aracın kullanılacağına dair değil, tasarlanacak sisteme dair bir sorun.
Üretkenlik inceleme kapasitesini geçtiğinde…
Farklı alanlarda aynı yapısal boşluk ortaya çıkıyor. Çıktı hızı, inceleme kapasitesini geçiyor.
AI, kurumların anlayabileceğinden, doğrulayabileceğinden ve sorumluluğunu alabileceğinden daha hızlı
üretiyor.
Bu durum, tam olarak anlaşılmayan yapay zeka destekli kodlardan, doğru gibi görünen ancak
savunulamaz uyum taslaklarına, akıcı bir şekilde seslendirilmiş ancak kritik bağlamı kaçıran müşteri
yanıtlarına ve yanlış varsayımları gizlerken zekice görünen analizlere kadar her yerde karşımıza çıkıyor.
Regüle edilen ortamlarda bu boşluk çok hızlı şekilde kırılganlığa dönüşüyor.
Yapay zeka çıktılarından sorumlu olmak, bir belgeyi onaylamaktan ibaret değil. Çıktının nasıl ve hangi
varsayımlarla üretildiğini anlamak; gerçek bir sistemde buna dayanarak hareket etmenin güvenli olup
olmadığını değerlendirmekle ilgili.
Ne Zaman Yapay Zeka Kullanılmamalı?
Kurumsal yapay zeka olgunluğunun en net göstergelerinden biri, ne zaman kullanılmaması gerektiğini
bilmek.
Bir görev, deterministik sonuçlar, katı kurallara dayalı uygulama veya belirsizliğe toleransı sıfır olan
hukuki yorum gerektiriyorsa, yapay zeka kullanmak genellikle değer katmak yerine gereksiz risk ekler.
Örneğin, bankacılık alanında, faiz birikimlerini veya düzenleyici sermaye oranlarını hesaplamak, üretici
yapay zeka kullanılarak yapılmamalı. Çünkü bunlar, açık formülleri, denetim gereksinimleri ve yorum
yapılacak hiç bir alanı olmayan deterministik hesaplamalardır ve yapay zeka sonucu açıklamada yardımcı
olabilir ancak sonucu üretmemelidir. Benzer şekilde, sahiplik belirsizse veya inceleme kapasitesi
sınırlıysa, yapay zeka kafa karışıklığını artırabilir.
Benzer şekilde, doğrudan sigorta kapsamı uygunluğu üzerinde etkisi olan bir sigorta tazminat kararı,
kararın sorumluluğunu üstlenen net bir rol yok ise, tamamen yapay zeka ile üretilmemeli. Bu tür durumlarda, yapay zeka belge özetlemede veya eksik bilgileri vurgulamada yardımcı olabilir, ancak nihai
karar insanın olmalı.
Yapay zekayı kullanmamayı seçmek, geri adım atmak değil; bir organizasyonun otomasyon, karar destek
ve denetim arasındaki sınırı anladığının bir göstergesi.
Ajan tabanlı yapay zeka otonomi ile ilgili değildir; yapı ile ilgilidir.
Ajan temelli yapay zeka genellikle otonom sistemlere doğru bir adım olarak tanımlıyor. Kurumsal
bağlamda ise bu tanım yanıltıcı. Ajan temelli yapay zeka, karmaşıklığa karşı geliştirilen bir mimari yanıt.
Tek bir modelden akıl yürütme, bilgi toplama, planlama, yürütme, doğrulama ve açıklama yapması
istenmek yerine, ajan temelli sistemler sorumlulukları genelde şöyle ayırıyor:
Kanallar ve Girdiler
İnsan talepleri, sistem tetikleyicileri, dışsal sinyaller.
Amaç ve Bağlam Normalizasyonu
Eylemden önce hedeflerin, kısıtlamaların ve kapsamın netleştirilmesi.
Planlayıcı / Orkestrasyon Ajanı
Görev çözümlemesi, sıralama, risk ve bütçe farkındalığı, insan etkileşimi yerleşimi.
Yürütme Ajanları
Bilgi toplama, analiz yapma, taslak hazırlama veya sistem entegrasyonu için dar, rol-spesifik ajanlar.
Koruyucu Çerçeveler ve Doğrulama Katmanı
Politika uygulaması, temellendirme, varsayım kontrolleri.
İnsan-etkileşimi
Gözden geçirme, onay ve üst birime aktarma; istisna değil, tasarımdan gelen bir zorunluluk.
Gözlemlenebilirlik ve Denetim
Tüm akış boyunca kaydetme, izlenebilirlik ve sorumluluk.
Bu ayrım, yapay zekayı daha akıllı hale getirmekle ilgili değil; onu işletilebilir kılmakla ilgili.
Entegrasyon ve Orkestrasyon Katmanı: Yapay Zekanın Gerçekle Buluştuğu Yer
Yapay zeka tartışmalarının çoğu modellere odaklanırken, yapay zekanın başarısız olduğu noktalar
genelde entegrasyon katmanından kaynaklanıyor. Kurumsal kullanım senaryolarında, bu katman teknik
bir kolaylık değil; kontrol düzlemi olarak konumlanıyor.
Entegrasyon ve orkestrasyon katmanı; yapay zeka yeteneklerinin gerçek iş akışlarıyla eşleştiği, sistem
sınırlarına sadık kalındığı, yetki ve rollerin uygulandığı ve hesap verebilirliğin netleştiği yer.
Ajan tabanlı mimarilerde bu katman, API çağrılarını yönlendirmekten çok daha fazlasını yapıyor. Kimin,
ne üzerinde, hangi kısıtlamalar altında ve kimin onayıyla hareket edebileceğini koordine ediyor.
“Güvenlik bariyerleri” de (guardrails) burada yaşıyor; sadece komuttan ibaret değiller, uygulanabilir
sistem kurallarını temsil ediyorlar:
★ Politika Bariyerleri: Mevzuat ve yasal uyumluluğu sağlamak için.
★ Veri Erişim Bariyerleri: Hangi ajanların hangi verilere erişebileceğini tanımlamak için.
★ Aksiyon Bariyerleri: “Önerme” ile “yürütme” yetkilerini birbirinden ayırmak için.
★ Bütçe ve Hız Bariyerleri: Kontrolsüz (runaway) davranışları engellemek için.
★ İnsana Devretme (Escalation) Bariyerleri: Belirlenen risk eşiklerinde incelemeyi zorunlu
kılmak için.
Güçlü bir orkestrasyon katmanı olmadığında, yapay zeka sistemleri mevcut süreçlerin içinden çalışmak
yerine onları bypass etme eğilimi gösteriyor ve kurumlar tam da bu noktada güvenlerini kaybediyor.
Ajan tabanlı yapay zeka başarısı, ajanların gücüne değil; güçlerinin kasıtlı olarak sınırlanmasına bağlı.
Cloud vs On-Prem yanlış başlangıç noktası
Sık sık aynı tartışmaya şahit oluyorum: Bu sistem kurum bünyesinde (on-prem) mi yoksa bulutta mı
çalışmalı?
MIT gibi kurumlardan çıkan çalışmaların da dahil olduğu araştırmalar ve saha içgörüleri, tutarlı bir şekilde
aynı sonuca işaret ediyor: Kurumsal yetkinlik, bu altyapı ve kurulum seçiminden daha önemli.
Modellerin nerede çalıştığı meselesi, şu kriterlerin sağlanıp sağlanmadığına kıyasla ikincil kalıyor:
★ Çıktılar açıklanabilir mi?
★ Yürütme süreci gözlemlenebilir mi?
★ Kararlar denetlenebilir mi?
★ Sorumluluk net bir şekilde tanımlanmış mı?
Ajan tabanlı mimariler hibrit ortamlarda da pekâlâ çalışabilir. Asıl önemli olan altyapı tercihi değil, yapısal
kontrol mekanizmalarına sahip olması.
Bulut, Veri, LLM’ler ve GDPR
GDPR ve yapay zeka çevresindeki tartışmalar genellikle aşırı basitleştirilmiş şu iki görüşe
indirgeniyor: “Bulut risklidir” veya “On-prem (yerleşik sistemler) daha güvenlidir.”
Oysa gerçekte GDPR bulut kullanımını yasaklamıyor. Bu başlı başına geniş bir konu, bir yandan da
düzeltilmesi gereken önemli bir yanılgı.
GDPR’ın asıl istediği; netlik, kontrol ve hesap verebilirlik. GDPR perspektifinden şu üç başlığa odaklanarak
değerlendirmek yeterli:
★ Uygulamanın barındırıldığı yer: Sağlayıcılar, uygun sözleşmeler kapsamında “veri işleyen”
(data processor) olarak hareket ettiğinde ve veri yerelliği (data residency) gereksinimleri
karşılandığında, bulut tabanlı uygulamalar genellikle kabul edilebilir.
★ Verinin saklandığı ve işlendiği yer: Verinin konumu, erişim kontrolü, şifreleme ve saklama
politikaları; altyapı tipinden çok daha önemlidir.
★ LLM servislerinin nasıl tüketildiği: Komutların kişisel veri içerip içermediği; bu verilerin nasıl
işlendiği, ne kadar süre saklandığı veya model eğitimi için kullanılıp kullanılmadığı kritik
değerlendirme noktalarıdır.
Regüle sektörlerde bu değerlendirme vaka bazlı yapılmalı. Aynı mimari; veri hassasiyetine, mevzuata
maruz kalma riskine ve kararların etki düzeyine bağlı olarak bir iş akışı için uygunken, diğeri için uygunsuz
olabilir.
GDPR uyumu; toptancı altyapı tercihlerine değil; amaçla sınırlılık, veri minimizasyonu ve şeffaflığa
dayanmalı.
Hazır Olmak İçin Tasarlamak
Kurumsal sistemlerde AI’ın üretebileceği hata, uç bir senaryo (edge case) olarak değil; bir çalışma koşulu
olarak düşünülmeli.
Tam da bu nedenle, ajan tabanlı (agentic) sistemler kontrollü hata yönetimi için tasarlanmalı. Tipik bir
kurumsal iş akışında birden fazla ajan bağlamı getirebilir, koşulları değerlendirebilir, öneriler
hazırlayabilir ve sonraki eylemleri tetikleyebilir. Her adımda belirsizlik birikir; bu belirsizlik eksik
verilerden çelişkili sinyallere, maliyet aşımlarından mevzuat kısıtlamalarına kadar uzanabilir.
Hata odaklı tasarım yapmak, bu aksaklıkları belirgin ve yönetilebilir kılmak demektir. Pratikte bu, bir dizi
bilinçli tasarım tercihiyle başlıyor:
★ Net durma koşulları ve güvenli yedekleme (fallback) mekanizmaları tanımlamak,
★ Yürütme ve maliyet sınırları belirlemek,
★ Geri döndürülemez eylemlerden önce doğrulama kapıları (validation gates) oluşturmak,
★ Güven düzeyi düştüğünde veya belirsizlik sürdüğünde üst makama bildirim (eskalasyon)
yolları belirlemek,
★ Ve ajan eylemlerinin; bağlam, kararlar ve sonuçlar genelinde izlenebilir olmasını sağlamak.
Bu tercihler basit uygulama detayları değil. Ajan tabanlı sistemlerin etkileyici birer prototip mi kalacağını,
yoksa kurumların güvenebileceği işletimsel sistemlere mi dönüşeceğini bu tercihler belirliyor.
Tutarlı sistemler, hatadan kaçınmakla değil; hatayı sınırlandırmak, açıklamak ve tasarım gereği hatadan
geri dönebilmekle elde edilebilir.
Ajan tabanlı yapay zekanın kestirme yolu yok, yapıya, hesap verebilirliğe ve netliğe ihtiyaç duyuyor.
Başarılı olan kurumlar, yapay zekayı en hızlı benimseyenler değil; zaman içinde güvenebilecekleri,
işletebilecekleri ve açıklayabilecekleri sistemler tasarlayanlar olacak.
AI’a hazır olmak, satın alabileceğiniz bir şey değil, inşa etmeniz gereken bir şey.
Ajan tabanlı sistemler günlük kurumsal operasyonların bir parçası haline geldikçe, bu ve benzeri
sorulara yanıt aramaya devam edeceğiz.
Bir sonraki yazıya dek hoşça kalın,