BNY agent’ları kurumsal ölçekte devreye alırken her bankanın er ya da geç karşılaştığı bir soruyla yüzleşti: AI sistemlerine işe yarayacak kadar özerklik verirken düzenleyicilerin istediği kontrolü nasıl korursunuz? Microsoft’un Azure AI Foundry blogundaki yazı, bankaların bugün runtime’dan network izolasyonuna kadar verdiği mimari kararları ve production’da kullanılan Microsoft teknolojilerini ele alıyor.
Bugün: modelden agent harness’a
Bankaların Microsoft AI ve agent servisleriyle yaptığı production deployment’ları büyük ölçüde iki gruba ayrılıyor. Birincisi Copilot Studio ve yeni Copilot entegrasyonları. İkincisi, yazının odaklandığı taraf: Microsoft Foundry üzerindeki model deployment’ları ve platformun diğer bileşenleriyle kurulan agent harness ya da benzeri framework’ler.
Microsoft’un agent tarafındaki servis haritası şöyle özetleniyor: GitHub ile geliştir, Foundry ile çalıştır, deploy et ve ölçekle, IQ ile grounding yap, Agent 365 ile yönet, M365 ya da Teams ile dağıt.
Microsoft’un Global Black Belt ekibi bu platformu tek bir uygulama olarak değil, katmanlardan ve bileşenlerden oluşan, müşterinin kendi çözümüne göre uyarlayabildiği bir araç seti olarak tanımlıyor. Temelde bir large language model var; 2026 itibarıyla bunu çoğu kurum zaten ölçekli kullanıyor. Bir sonraki kritik bileşen agent harness.
Microsoft Learn’deki tanıma göre agent harness (ya da AI harness), bir language model’i iş yapabilen bir agent’a dönüştüren runtime iskeleti. Doğru kurulduğunda agent’ın prompt’larla, tool’larla ve diğer servislerle nasıl etkileşeceğini yöneten bütünleşik çerçeve oluyor. Copilot Studio’nun yerleşik harness’ından Microsoft Agent Framework (MAF) tabanlı özel Foundry çözümlerine kadar farklı seçenekler var.
Kurumsal katmanlar
Bankacılıktaki yaygın kurumsal agent mimarisinde modele ek olarak dört katman bulunuyor: grounding, runtime, orchestration ve security. Agent harness bu katmanları birbirine bağlıyor ve agent sisteminin hangi akışları, bağlantıları ve aksiyonları gerçekleştirebileceğini tanımlıyor. Çok adımlı ya da uzun süren her iş için bir harness gerekiyor. Bu bileşenlerin nasıl düzenleneceği, bilgi güvenliği ekibince nasıl inceleneceği agent’tan agent’a değişse de temel parçalar Azure örnekleri ve accelerator’larla bugün deploy edilebilir durumda.
Birinci zorluk: agent nedir?
Yazıya göre şirketlerin ilk yapması gereken şey, kendileri için agent’ı tanımlamak ve farklı agent türlerini hangi özerklik seviyesinin ayırdığını belirlemek. Bunun asıl nedeni, herkesin bir AI sistemi kurmaya gerçekten gerek olup olmadığını sorgulaması. Çoğu zaman cevap generative AI değil, daha iyi bir machine learning sistemi oluyor. Generative AI ve agent özerkliği gerçekten gerekiyorsa, her kullanım senaryosu için başarının hangi metriklerle ölçüleceği de baştan belirlenmeli. Bu adımı atlamak genelde pahalı yeniden çalışmaya ya da başarısız deployment’lara yol açıyor.
Microsoft, AI’a yeni başlayan ve agent’lara geçen şirketlere bir responsible AI çerçevesi ve yönetişim inceleme kurulu gibi, çoğu şirkette henüz olmayan organizasyonel yapılar kurmalarını öneriyor.
AI agent’lar yerel chatbot’lardan LangChain sistemlerine, oradan tool ve aksiyon kullanan reasoning döngülerine, son olarak da daha az gözetimle çalışan, uzun soluklu ve kendini tekrar tekrar geliştiren production sistemlerine evrildi. Bankalar ve benzeri düzenlemeye tabi kurumlar da bu yelpazeyi tanımlayıp bileşenleri adım adım ekleyerek güvenli şekilde ölçeklenmeli.
İkinci zorluk: agent’ın neden harness’a ihtiyacı var?
LLM alanı o kadar hızlı değişiyor ki, production uygulamalarında alıştığımız güvenilirlik, izleme ve güvenlik kriterlerinin agent’lar için standart bir karşılığı yok. LLM’ler ve agent sistemleri, alışık olduğumuz siber güvenlik ilkelerini yeniden tanımlıyor. Asıl soru şu: agent’lara “güvenebilir miyiz?” Harness’ın güveni artıran kontrolleri var, ama bu sistemlerin yapı taşlarının her zaman rastgele ve öngörülemez çıktı üretebilen stokastik süreçler olduğunu unutmamak gerekiyor.
Üçüncü zorluk: güvenli şekilde nasıl ölçeklenir?
Bankalar genelde bir proof of concept kurmayı başarıyor; asıl sorunlar production’a çıkarken başlıyor. Agent’la konuşan birkaç düzine iç kullanıcı yerine yüzlerce kullanıcı geliyor, uygulama model sağlayıcısının kapasite limitine dayanıyor, güvenlik ekibi rogue agent’ları ve prompt injection saldırılarını soruyor. Yazara göre AI çağında olay müdahalesi haftalık ya da günlük değil, belki saatlik bir iş. Bunu bir zorluktan çok “bitmeyen bir savaşın başlangıcı” olarak tanımlıyor.
Birinci karar: runtime ve hosting
Sonraki pek çok kararı belirleyen ilk soru, agent’ın nerede çalışacağı. Microsoft tarafındaki seçenekler Azure Virtual Machines, Azure Container Apps, Azure Kubernetes Service, Azure Functions ve Foundry Hosted Agents. Seçimi belirleyen şey, ne kadar kontrol istediğiniz ve o kontrolü yönetmenin ne kadar karmaşık olduğu.
En yüksek kontrol ve en yüksek karmaşıklık doğrudan VM üzerinde çalışmak: makinenin kendisi dışında image’dan container’a kadar her şeyi siz kuruyorsunuz, operasyonel yük de size kalıyor. Diğer uçta en az kontrol ve en az karmaşıklıkla Foundry agent’ları var. Seçim için Azure Architecture Center’daki “Choose an Azure compute service” rehberi temel referans. Foundry yetenekleriyle entegre çalışan ve tanımı hazır bir agent için önerilen seçenek Foundry Hosted Agents.
İkinci karar: ortam ve network izolasyonu
Bankalar için ortam izolasyonu, herhangi bir özerklik verilmeden önce AI’ın risklerinin ve güvenlik kontrollerinin anlaşılmış, tanımlanmış ve izlenebilir olması anlamına geliyor. Pratikte bu network izolasyonu, private networking, inceleme ve loglama demek. Kontroller tarafında guardrail’ler, safety servisleri ve erişim kısıtları var. Örneğin agent’a sadece kimliği doğrulanmış kullanıcılar erişmeli, sadece işle ilgili onaylı prompt’lara izin verilmeli, agent’a yüklenen ya da onunla paylaşılan her şey denetim için izlenebilir olmalı.
Bu kararları büyük ölçüde bankanın mevcut güvenlik altyapısı belirliyor: kullanılan firewall, network inceleme araçları ve model onay süreçleri. AI yeni riskler getirdiği için bir agent ortamını mevcut güvenlik protokollerine entegre edip onaylatmak çoğu zaman vaka bazında özelleştirme gerektiriyor. Microsoft Foundry’nin bu iş için sunduğu başlıca seçenekler şunlar:
| Servis | Ne işe yarıyor |
|---|---|
| Foundry Hosted Agents | Custom-code agent’lar için session izolasyonu, kimlik, ölçekleme, observability ve opsiyonel VNet entegrasyonu sunan yönetilen runtime. |
| BYO VNet Private Networking (Standard Agent Setup) | Agent compute’unu müşteriye ait delegated subnet’e yerleştirir; DNS, NSG, UDR, firewall ve private endpoint’ler müşterinin kontrolünde. |
| Capability Hosts | Agent thread’lerinin, dosyaların, vector store’ların ve ilgili verilerin müşteri kaynaklarında nerede saklanıp işleneceğini tanımlar. |
| Private Endpoints (Private Link) | Foundry kaynaklarına güvenli inbound erişim ve Storage, Search, Cosmos DB, Key Vault gibi bağımlılıklara private erişim. |
| Toolbox | Merkezi tool ve MCP endpoint yönetimi, tool keşfi, kimlik doğrulama ve yönetişim. |
| Agent Identity | Microsoft Entra Agent ID: agent’lara özel kimlik, RBAC, yetkilendirme, yönetişim ve denetlenebilirlik. |
| APIM / AI Gateway | Modeller, MCP tool’ları ve agent’lar için policy, throttling, metering ve loglama uygulayan yönetilen giriş noktası. |
| Foundry Observability + Application Insights | Tracing, evaluation, izleme ve OpenTelemetry ingestion. Ek güvenlik kontrolleri için opsiyonel olarak Sentinel ve Purview. |
| Müşteriye ait Storage / Azure AI Search / Cosmos DB | Standard Agent Setup’ın thread geçmişi, dosyalar, vector store, bilgi ve state için kullandığı BYO data plane. |
Yarın: neler takip edilmeli
Tüm bu zorluklara rağmen kimsenin yavaşlamaya niyeti yok. Çalışan verimliliğinden yazılım geliştirme otomasyonuna kadar pek çok kurumsal senaryo agent’lardan şimdiden fayda görüyor. Microsoft’ta yeni duyurular genelde kışın Ignite’ta, yazın Build’de geliyor. Bankacılıkta agent kuranlar için yazının işaret ettiği başlıklar şunlar:
- Ignite 2026’daki agent oturumları; özellikle doğru agent mimarisini seçmek ve production’daki başarısızlık örüntüleri üzerine olan oturum.
- Build 2026’da Foundry’ye yerleşik Toolbox özelliklerini anlatan, agent’ları ölçekte kurup çalıştırma sunumu.
- Foundry’de preview’daki memory yönetimi ve yeni yapılandırma seçenekleri.
- Maliyet dahil observability ve optimizasyon tarafındaki duyurular; Eylül 2026’da açıklanan Model Router ve Agent Optimizer bunların başında geliyor.
Yazının en değerli kısmı, teknoloji listesinden çok sıraladığı sorular. “Agent’a gerçekten ihtiyacımız var mı?” sorusunu ilk adım olarak koyması, birçok kurumun atladığı bir şey. Hosting ve izolasyon tablosu da bankacılıkta Foundry tabanlı bir agent mimarisi çizen ekipler için iyi bir kontrol listesi. Eksik kalan taraf, BNY örneğinin somut detayları; hangi kararların neden verildiği ve production’da neyle karşılaşıldığı daha ayrıntılı anlatılsa yazı çok daha öğretici olurdu.
