Şirket İçi Yapay Zeka Ajanları (Agents) Oluşturma Rehberi

Bir çalışanın her sabah CRM'e girip yeni lead'leri kontrol ettiğini, şirket bilgilerini araştırdığını, notları sınıflandırdığını, teklif için veri topladığını ve sonunda yine başka bir sisteme geçip sonuçları kaydettiğini düşünün. Bu iş akışı yalnızca tekrar eden bir otomasyon değildir çünkü her müşteri farklıdır, kullanılan bilgiler değişir ve bazı adımlarda karar vermek gerekir. İşte şirket içi yapay zeka ajanları tam olarak bu tür süreçlerde anlam kazanmaya başlar. Şirket İçi Yapay Zeka Ajanları (Agents) Oluşturma Rehberi boyunca şirket içi yapay zeka ajanı nasıl oluşturulur, kurumsal AI agent geliştirme mimarisi nasıl kurulur, şirket verileriyle RAG tabanlı yapay zeka ajanı geliştirme nasıl yapılır ve kurumsal AI agent sistemlerinde tool calling hafıza yetkilendirme ve güvenlik nasıl ele alınır gibi kritik konuları uygulama perspektifiyle inceleyeceğiz. Amacımız yalnızca çalışan bir demo yapmak değil, gerçek şirket verileriyle çalışan, yetkisi sınırlandırılmış, ölçülebilir ve production ortamında sürdürülebilen bir ajan tasarlamaktır.

Şirket İçi Yapay Zeka Ajanı Nedir?

Şirket içi yapay zeka ajanı, belirli bir kurumsal hedefi gerçekleştirmek için kullanıcı talebini anlayabilen, şirket verisine erişebilen, izin verilen araçları çağırabilen ve gerektiğinde birden fazla adımı takip edebilen yazılım sistemidir. Buradaki önemli nokta, ajanı yalnızca sohbet ekranı olarak görmemektir. Gerçek değer, modelin CRM, ERP, dosya sistemi, veri tabanı, ticket sistemi veya şirket içi servislerle kontrollü biçimde etkileşime geçmesiyle ortaya çıkar. Ajan bir insan çalışanın bütün yetkilerini kopyalamamalı, yalnızca ihtiyaç duyduğu veri ve işlemler için sınırlı izin almalıdır. Bu nedenle kurumsal ajan tasarımı model seçiminden önce süreç, yetki, veri ve hata senaryolarının anlaşılmasıyla başlar.

AI Agent Kavramı

AI Agent, bir hedef doğrultusunda çevresinden bilgi alan, bu bilgiyi değerlendiren ve belirli eylemler gerçekleştirebilen yazılım bileşenidir. Modern kurumsal ajanlarda büyük dil modeli genellikle anlama, planlama ve araç seçimi için kullanılır. Ajanın gerçek dünyadaki etkisi ise API, veri tabanı sorgusu, arama sistemi veya başka bir servis çağrısı üzerinden oluşur. Modelin tek başına cevap üretmesi ajan davranışı için yeterli değildir. Ajan dediğimiz yapı model, araçlar, durum yönetimi, güvenlik kontrolleri, gözlemleme ve gerektiğinde insan onayının birlikte çalıştığı sistemdir.

Bir Yapay Zeka Ajanı Ne Yapabilir?

Bir yapay zeka ajanı şirket politikasını bulabilir, destek talebini sınıflandırabilir, rapor hazırlayabilir, CRM kaydını güncelleyebilir veya bir satın alma talebini uygun onay akışına yönlendirebilir. Daha gelişmiş sistemlerde ajan farklı araçları sırayla kullanarak çok adımlı görevleri tamamlayabilir. Örneğin yeni lead geldiğinde şirket web sitesinden bilgi toplayabilir, CRM verisini okuyabilir, puanlama yapabilir ve satış temsilcisine taslak not hazırlayabilir. Kritik nokta, ajanın yapabileceklerinin system prompt ile değil gerçek authorization katmanıyla sınırlandırılmasıdır. Bir ajan teknik olarak her şeyi çağırabiliyorsa prompt içinde “silme yapma” yazmak güvenli bir yetkilendirme modeli değildir.

AI Agent ile ChatGPT Arasındaki Fark

ChatGPT genel amaçlı bir yapay zeka asistanıdır, şirket içi AI Agent ise belirli iş süreçlerine, şirket verilerine ve kontrollü araçlara bağlanan uygulama mimarisidir. Kurumsal ajan şirket kimliği, kullanıcı yetkisi ve iş akışı context'i gibi ek bilgilerle çalışabilir. Bir kullanıcı “bu müşterinin son üç teklifini getir ve yenisini hazırla” dediğinde ajan CRM ve doküman sistemine erişerek bu görevi gerçekleştirebilir. Genel sohbet sistemi bu şirket içi kaynaklara otomatik olarak sahip değildir. Kurumsal kullanımda asıl fark modelden çok veri bağlantısı, authorization, tool execution ve audit katmanında görülür.

AI Agent ile Chatbot Arasındaki Fark

Klasik chatbot çoğunlukla önceden tanımlanmış intent ve cevap akışları üzerinden çalışır. AI Agent daha esnek girdileri anlayabilir ve hedefe ulaşmak için farklı araçları seçebilir. Chatbot “kargo durumunuz” sorusunu belirli API'ye yönlendirebilirken ajan müşterinin siparişini bulup gecikme nedenini kontrol ederek uygun çözüm seçenekleri önerebilir. Ancak daha fazla esneklik daha fazla risk anlamına gelir. Bu nedenle ajanların yetki, tool sınırı, human approval ve gözlemleme katmanları chatbot sistemlerine göre daha güçlü tasarlanmalıdır.

AI Agent ile Klasik Otomasyon Arasındaki Fark

Klasik otomasyon deterministik kurallarda oldukça başarılıdır ve girdi ile çıktı açıkça tanımlanabiliyorsa çoğu zaman ajan kullanmaya gerek yoktur. Örneğin her gece saat 02.00'de rapor üretip e-posta göndermek için AI Agent gereksiz olabilir. Ajanlar değişken dil girdileri, belirsiz kararlar ve farklı araç seçimi gereken süreçlerde daha anlamlıdır. Buna rağmen ajan içinde mümkün olan bölümleri yine deterministik kodla çalıştırmak daha güvenlidir. Benim tercih ettiğim yaklaşım, belirsizliği modele bırakmak ve kritik işlem adımlarını normal uygulama kodu ile kontrol etmektir.

AI Agent ile AI Workflow Arasındaki Fark

AI Workflow genellikle önceden tanımlanmış adımlarda model çağrılarının kullanıldığı kontrollü bir süreçtir. Agent ise bazı durumlarda hangi adımı veya aracı kullanacağına kendi context değerlendirmesine göre karar verebilir. Bu ayrım pratikte siyah beyaz değildir ve birçok production sistemi ikisinin birleşimidir. Örneğin satış talebi önce deterministik doğrulama akışından geçebilir, ardından ajan araştırma aracı seçebilir ve son aşamada tekrar sabit approval workflow'una girebilir. Kurumsal ortamda tamamen serbest ajan yerine kontrollü workflow içinde sınırlı otonomi çoğu zaman daha güvenli başlangıçtır.

Agentic AI Nedir?

Agentic AI, yapay zeka sistemlerinin yalnızca metin üretmek yerine hedef doğrultusunda adım seçmesi, araç kullanması ve elde ettiği sonuçlara göre devam etmesi yaklaşımını ifade eder. Bu yapı planning, tool calling, memory ve state yönetimi gibi bileşenleri içerebilir. Agentic davranışın faydası çok adımlı görevlerin insan müdahalesini azaltmasıdır. Risk ise modelin beklenmeyen bir plan veya araç seçimi yapabilmesidir. Bu nedenle production sistemde otonomi artırılmadan önce test dataset'i, approval noktaları ve maksimum çalışma sınırları tanımlanmalıdır.

Şirketinizin Gerçekten Bir AI Agent'a İhtiyacı Var mı?

Bir süreçte yapay zeka kullanabiliyor olmak, o sürecin ajanla çözülmesi gerektiği anlamına gelmez. Şirketlerin ilk yaptığı hatalardan biri basit workflow'ları gereksiz yere agentic hale getirmektir. İyi aday süreçlerde girdiler değişken, karar noktaları fazla ve birden fazla sistem arasında geçiş ihtiyacı vardır. Ayrıca süreç insan çalışanların ciddi zamanını tüketmeli ve hataların business etkisi ölçülebilir olmalıdır. İlk değerlendirmede yapılması gereken soru “nerede ajan kullanabiliriz?” değil, “hangi iş probleminde kontrollü ajan yaklaşımı ölçülebilir değer üretir?” olmalıdır.

Agent Kullanılması Mantıklı Süreçlerin Özellikleri

Agent kullanımının mantıklı olduğu süreçler genellikle tek satırlık kurallarla ifade edilemez. İnsan çalışan aynı görevi yaparken farklı veri kaynaklarını açıyor, duruma göre karar veriyor ve sonuçta farklı eylemler seçiyorsa agent için anlamlı aday olabilir. Bununla birlikte her kararın yüksek risk taşımaması tercih edilir. İlk pilotta geri alınabilir veya insan tarafından kolay doğrulanabilir görevler daha uygundur. Sürecin mevcut zaman, hata ve maliyet baseline'ı ölçülebiliyorsa agent yatırımının başarısını değerlendirmek de kolaylaşır.

Çok Adımlı Olması

Çok adımlı süreçler agent yaklaşımının güçlü olduğu alanlardan biridir. Bir çalışan önce bilgi topluyor, sonra sınıflandırıyor, ardından başka sistemde kayıt açıyor ve sonuç raporu hazırlıyorsa süreç farklı context aşamalarına sahiptir. Ajan bu adımları state ile takip edebilir. Ancak her adımın serbest biçimde modele bırakılması gerekmez. Kritik adımlar deterministik servislerle sınırlandırılarak hem hata oranı hem de debug maliyeti azaltılabilir.

Değişken Girdiler İçermesi

Doğal dil, farklı formatlardaki dokümanlar ve tutarsız müşteri açıklamaları klasik rule tabanlı otomasyon için zor olabilir. LLM tabanlı ajan bu değişken girdileri normalize edip anlamlı yapıya dönüştürebilir. Örneğin farklı biçimde yazılmış satın alma taleplerinden ürün, adet, bütçe ve teslim tarihi çıkarılabilir. Yine de model çıktısı doğrudan işleme alınmamalıdır. Schema validation ve business rule kontrolleri sonraki aşamada mutlaka uygulanmalıdır.

Karar Vermeyi Gerektirmesi

Bazı iş süreçleri yalnızca veri taşımakla bitmez ve mevcut bilgiler üzerinden seçim yapılmasını gerektirir. Örneğin destek ticket'ının hangi uzman ekibe yönlendirileceği veya satış lead'inin hangi kategoriye gireceği bağlama göre değişebilir. Model bu kararın öneri katmanında yararlı olabilir. Yüksek riskli kararların otomatik ve denetimsiz verilmesi ise uygun değildir. Finansal, hukuki veya çalışan haklarını etkileyen kararlar için insan onayı ve açıklanabilir kriterler korunmalıdır.

Birden Fazla Sistem Kullanması

Çalışanların sürekli CRM, ERP, e-posta ve dosya sistemi arasında geçiş yapması operasyonel sürtünme yaratır. Agent ortak bir orchestration katmanı üzerinden bu sistemlerden kontrollü veri okuyabilir. Daha sonra kullanıcıya tek bir çalışma alanında özet ve öneri sunabilir. Write işlemleri read işlemlerinden ayrı yetkilendirilmelidir. Ayrıca her entegrasyon bağımsız timeout, retry ve audit politikasına sahip olmalıdır.

İnsanların Tekrarlayan Zamanını Tüketmesi

Bir iş yüksek nitelikli çalışanın saatlerini sürekli aynı veri toplama ve özetleme faaliyetlerine harcatıyorsa agent iyi aday olabilir. Burada hedef insanı tamamen çıkarmak değil, düşük değerli tekrarları azaltmaktır. İnsan daha yüksek bağlam ve sorumluluk gerektiren kararları üstlenmeye devam edebilir. ROI hesabında kazanılan saatler doğrudan ölçülebilir. Pilot öncesi baseline ölçülmediğinde daha sonra projenin gerçekten fayda üretip üretmediğini anlamak zorlaşır.

Agent Yerine Klasik Otomasyon Kullanılması Gereken Durumlar

Girdi ve çıktı tamamen belirliyse klasik otomasyon genellikle daha hızlı, ucuz ve güvenilir sonuç verir. Bir dosya geldiğinde sabit formatla başka sisteme kaydetmek için LLM çağrısı yapmak gereksiz olabilir. Aynı şekilde vergi oranı gibi kesin business rule modeller tarafından yorumlanmamalıdır. Agent sadece belirsizlik olan bölümlerde devreye girebilir ve kalan akış normal kodla yönetilebilir. Bu hibrit yaklaşım production sistemlerinde hem maliyet hem güvenilirlik açısından güçlü sonuç verir.

Agent Kullanılmaması Gereken Süreçler

Geri alınması zor, yanlış kararın ciddi hukuki veya finansal sonuç üreteceği ve insan doğrulamasının mümkün olmadığı süreçlerde otonom agent kullanımına temkinli yaklaşılmalıdır. Ayrıca veri kalitesi çok düşükse agent sadece kötü veriyi daha hızlı işleyebilir. Süreç sahibi belli değilse de automation kurmak sorumluluk problemini büyütür. Bir başka kötü aday, mevcut süreçte aslında problem bulunmaması ve projenin yalnızca teknoloji denemek amacıyla başlatılmasıdır. İlk ajan projesi düşük riskli, yüksek tekrar içeren ve başarı kriteri ölçülebilen alandan seçilmelidir.

İlk Kullanım Senaryosu Nasıl Seçilir?

İlk kullanım senaryosunu seçerken business değeri yüksek ama operasyon riski yönetilebilir bir süreç aramak gerekir. Bilgi asistanı, ticket sınıflandırma ve taslak oluşturma gibi görevler bu nedenle sık kullanılan pilot alanlarıdır. Tam otomatik para transferi veya sözleşme onayı ilk pilot için uygun değildir. Sürecin sahibi projeye aktif katılmalı ve gerçek örneklerden test dataset'i sağlamalıdır. Pilot sonunda devam kararı yalnızca kullanıcıların ilgisine değil ölçülen zaman kazanımı, doğruluk ve güvenlik sonuçlarına göre verilmelidir.

Impact × Risk × Complexity Matrisi

Impact, Risk ve Complexity matrisi aday kullanım senaryolarını karşılaştırmak için basit ama etkili yöntemdir. Impact business değerini, Risk yanlış çalışmanın etkisini ve Complexity geliştirme ile entegrasyon zorluğunu temsil eder. Yüksek etki, düşük risk ve orta complexity içeren senaryolar genellikle iyi pilot adaylarıdır. Çok yüksek etki fakat çok yüksek risk taşıyan süreçler önce decision support seviyesinde ele alınabilir. Bu matris farklı departmanların “bizim agent projemiz daha önemli” tartışmasını ölçülebilir kriterlere taşıdığı için roadmap oluşturmayı da kolaylaştırır.

Şirket İçi AI Agent Kullanım Alanları

Şirket içi ajanlar insan kaynaklarından satışa, finansa ve yazılım geliştirmeye kadar birçok bölümde kullanılabilir. Ancak her departmanda en değerli kullanım genellikle farklıdır. Bir ekipte bilgiye erişim sorunu varken başka ekipte asıl problem veri girişidir. Bu nedenle platform ekipleri tek büyük “her işi yapan şirket ajanı” yerine dar görevli ve net yetkili ajanlar tasarlamalıdır. Aşağıdaki örnekler kurumsal AI agent geliştirme mimarisi nasıl kurulur sorusunun iş süreci tarafını anlamak için iyi bir başlangıç sağlar.

İnsan Kaynakları Ajanı

İnsan kaynakları ajanı çalışan politikaları, onboarding adımları ve tekrarlayan personel sorularında destek olabilir. Bu tür sistemlerde kullanıcı identity'si önemlidir çünkü her çalışan aynı belgelere erişmeyebilir. Ajanın insan kaynakları kararlarını tek başına vermesi yerine bilgi erişimi ve ön değerlendirme için kullanılması daha güvenlidir. Kişisel veri içeren kaynaklara erişim minimum tutulmalıdır. Bütün retrieval ve kritik işlem event'leri audit edilebilir olmalıdır.

Şirket Politikalarını Yanıtlama

Çalışanlar izin, seyahat, uzaktan çalışma veya masraf politikaları hakkında sık sorular sorabilir. RAG tabanlı ajan güncel politika dokümanlarından ilgili bölümleri getirip kaynak gösteren yanıt üretebilir. Yanıtın belge tarihini ve sürümünü göstermesi yanlış veya eski policy kullanımını azaltır. Kullanıcı yetkisi olmayan dokümanlar retrieval sonucuna girmemelidir. Hukuki yorum gerektiren durumlar insan kaynaklarına eskale edilmelidir.

Onboarding Desteği

Yeni çalışanların ilk haftalarda tekrar eden çok sayıda operasyonel sorusu olur. Agent gerekli form, iç sistem, ekip dokümanı ve eğitim materyaline yönlendirme yapabilir. Kişiye göre farklı onboarding adımları varsa rol ve departman bilgisi context olarak kullanılabilir. Agent doğrudan production erişimi vermemeli, yalnızca gerekli request veya approval sürecini başlatmalıdır. Böylece kullanıcı deneyimi hızlanırken güvenlik kontrolü korunur.

CV Ön Değerlendirme

CV ön değerlendirme kullanımında otomatik karar yerine destekleyici sınıflandırma yaklaşımı daha sağlıklıdır. Agent ilan gereksinimlerine göre deneyim, teknoloji ve proje bilgilerini yapısal hale getirebilir. Nihai işe alım kararı model tarafından verilmemelidir. Ayrımcılık veya önyargı riski nedeniyle kriterler açık, tutarlı ve düzenli olarak değerlendirilmelidir. Kişisel verilerin saklama süresi ve erişim izinleri KVKK gereksinimleri kapsamında ayrıca planlanmalıdır.

Satış Ajanı

Satış ekipleri araştırma, CRM güncelleme ve teklif hazırlama gibi tekrar eden işlerde ciddi zaman harcar. Satış ajanı farklı kaynakları okuyup temsilciye özet sunabilir. Ancak müşteriye taahhüt, fiyat onayı veya sözleşme kabulü gibi konular insan kontrolünde kalmalıdır. CRM write yetkisi kayıt oluşturma ve belirli alan güncellemeleriyle sınırlandırılabilir. Agent'ın amacı satış ekibini devre dışı bırakmak değil, bilgi toplama ve operasyon yükünü azaltmaktır.

Lead Araştırma

Lead araştırma ajanı şirket web sitesi, CRM ve izin verilen dış kaynaklardan potansiyel müşteri hakkında bilgi toplayabilir. Toplanan verinin kaynağı ve tarihi cevapla birlikte saklanmalıdır. Modelin bulamadığı bilgiyi uydurması engellenmeli ve “bilgi bulunamadı” sonucu kabul edilmelidir. Dış web verisi güvenilmeyen içerik olarak değerlendirilmelidir. Prompt injection veya yanlış yönlendirici sayfa içeriğinin tool kararlarını etkilemesine izin verilmemelidir.

Lead Scoring

Lead scoring modelin keyfi değerlendirmesi yerine açık kriterler ve ölçülebilir özelliklerle desteklenmelidir. Agent şirket büyüklüğü, sektör, geçmiş etkileşim ve ihtiyaç sinyallerini toplayabilir. Skor formülü deterministik servis içinde hesaplanabilir. LLM yalnızca nitel açıklamaları yapısal alanlara dönüştürmek için kullanılabilir. Böylece satış temsilcisi skorun neden oluştuğunu daha kolay anlayabilir.

CRM Güncelleme

CRM güncelleme write tool olarak yüksek dikkat gerektirir. Agent sadece belirli alanları güncelleyebilmeli ve kullanıcı yetkisini aşmamalıdır. Büyük toplu değişiklikler veya kayıt silme işlemleri ayrı approval gerektirmelidir. Her write çağrısı önce dry run sonucu gösterebilir. Audit log hangi kullanıcının talebiyle hangi alanın eski değerden yeni değere geçtiğini kaydetmelidir.

Teklif Taslağı Oluşturma

Agent CRM bilgisi ve onaylı ürün kataloğundan yararlanarak teklif taslağı oluşturabilir. Fiyat ve indirim sınırları kesin business rule'lar üzerinden kontrol edilmelidir. Modelin katalog dışı ürün veya onaysız fiyat üretmesine izin verilmemelidir. Taslak satış temsilcisinin onayına sunulmalıdır. Gönderme işlemi ayrı tool olarak insan approval sonrasında çalıştırılmalıdır.

Müşteri Hizmetleri Ajanı

Müşteri hizmetleri ajanı ticket sınıflandırma, bilgi tabanı arama ve temsilciye cevap taslağı hazırlama gibi görevlerde kullanılabilir. İlk aşamada otomatik gönderim yerine temsilci destek modeli daha güvenli olabilir. Başarı arttıkça düşük riskli sorular için otomasyon oranı artırılabilir. Müşteri kimliği ve account verisi retrieval sırasında authorization ile kontrol edilmelidir. Ajanın yetkisi bir müşterinin verisini başka müşteriye göstermeyecek biçimde teknik olarak sınırlandırılmalıdır.

Ticket Sınıflandırma

Ticket sınıflandırma düşük riskli ve ölçülebilir bir başlangıç senaryosudur. Agent konu, ürün ve aciliyet kategorisi önerebilir. Gerçek geçmiş ticket verisi golden dataset olarak kullanılabilir. Yanlış yönlendirme oranı pilot boyunca izlenmelidir. Belirsizlik yüksek olduğunda ajan doğrudan insan kuyruğuna göndermelidir.

Bilgi Tabanından Cevap Üretme

RAG sistemi ilgili destek makalelerini getirir ve ajan yalnızca bu kaynaklara dayanarak cevap oluşturur. Kaynak linki veya doküman adı yanıtın altında gösterilebilir. Eski makaleler retrieval dışında tutulmalıdır. Model yeterli kaynak bulamazsa cevap üretmek yerine temsilciye eskalasyon yapmalıdır. Bu yaklaşım halüsinasyonu tamamen yok etmez, ancak doğrulama ve denetim imkanını önemli ölçüde artırır.

İnsan Temsilciye Eskalasyon

Agent'ın iyi çalışmasının önemli göstergelerinden biri ne zaman duracağını bilmesidir. Müşteri çok öfkeli, konu hukuki veya verilen bilgiler yetersizse insan temsilciye devretmek doğru seçimdir. Eskalasyon sırasında agent konuşma özetini ve kullandığı kaynakları temsilciye aktarabilir. İnsan tekrar baştan bilgi toplamak zorunda kalmaz. Bu handoff kullanıcı deneyimini bozmadan otonomi sınırını korur.

Finans Ajanı

Finans ajanları belge işleme, sınıflandırma ve raporlama gibi alanlarda ciddi zaman tasarrufu sağlayabilir. Bununla birlikte para transferi, ödeme onayı ve muhasebe kaydı gibi write işlemlerinin riski yüksektir. Ajanın başlangıçta read ve öneri modunda çalışması daha güvenlidir. Yetki matrisi tutar ve işlem tipine göre farklı approval seviyeleri tanımlayabilir. Bütün finansal tool çağrıları değiştirilemez audit kayıtlarıyla izlenmelidir.

Fatura Kontrolü

Agent faturadaki şirket, tutar, vergi, sipariş numarası ve tarih alanlarını çıkarabilir. Bu alanlar ERP veya satın alma kayıtlarıyla karşılaştırılabilir. Tutarsızlık bulunduğunda kullanıcıya açıklamalı uyarı üretilebilir. Nihai ödeme onayı insan sorumluluğunda kalmalıdır. OCR veya extraction güven skoru düşükse kayıt otomatik işlenmemelidir.

Masraf Sınıflandırma

Çalışan masrafları açıklama ve fiş içeriğine göre belirli kategorilere ayrılabilir. Agent öneri sınıfı üretirken şirket masraf politikasını RAG üzerinden kontrol edebilir. Politika dışı harcama otomatik reddedilmemelidir. Bunun yerine ilgili madde gösterilerek finans ekibine yönlendirilebilir. Bu yaklaşım hem hız hem de denetlenebilirlik sağlar.

Finansal Raporlama

Agent farklı veri kaynaklarından kontrollü sorgular çalıştırıp yönetim özeti hazırlayabilir. Sayısal hesaplamalar LLM yerine güvenilir SQL veya analytics servisleriyle yapılmalıdır. Model sonuçların yorumunu ve doğal dil açıklamasını üretebilir. Kullanılan sorgular ve veri zaman aralığı raporla birlikte gösterilmelidir. Böylece yönetici hem sonucu hem de kaynağı doğrulayabilir.

Satın Alma Ajanı

Satın alma ajanı ürün araştırma, teklif karşılaştırma ve sipariş taslağı gibi görevlerde kullanılabilir. Tedarikçi seçimi ve fiyat onayı şirket politikalarına bağlı olarak insan kararında kalabilir. Agent standart kriterleri uygulayarak karşılaştırmayı hızlandırabilir. Dış web sayfaları güvenilmeyen veri olarak ele alınmalıdır. Satın alma tool'larının write ve ödeme yetkileri kesin biçimde ayrılmalıdır.

Tedarikçi Araştırma

Agent izin verilen kaynaklardan tedarikçi hakkında temel bilgi toplayabilir. Kaynak, tarih ve doğrulanabilir alanlar sonuçla birlikte gösterilmelidir. Modelin itibar veya güvenilirlik konusunda kanıtsız iddia üretmesine izin verilmemelidir. Hukuki veya finansal risk değerlendirmesi uzman kontrolüne bırakılmalıdır. Araştırma çıktısı yalnızca karar destek verisi olarak kullanılmalıdır.

Teklif Karşılaştırma

Farklı formatlardaki teklif dosyaları ortak şemaya dönüştürülebilir. Fiyat, teslim süresi, garanti ve ödeme koşulları tablo halinde karşılaştırılabilir. Eksik bilgi açıkça işaretlenmelidir. Agent eksik alanı varsayarak doldurmamalıdır. Son karar ilgili satın alma sorumlusuna bırakılmalıdır.

Sipariş Taslağı Oluşturma

Onaylanan teklif sonrası agent ERP için sipariş taslağı oluşturabilir. Taslak stage ile final commit birbirinden ayrılmalıdır. Kullanıcı önce değişiklikleri görmeli ve onaylamalıdır. Idempotency key çift sipariş oluşmasını önlemek için kullanılabilir. Büyük tutarlı veya sıra dışı siparişlerde ikinci approval seviyesi devreye alınmalıdır.

Hukuk ve Sözleşme Ajanı

Hukuk ajanları sözleşme karşılaştırma ve standart şablon kontrolünde yararlı olabilir. Ancak hukuki yorumun kesin doğru kabul edilmesi risklidir. Agent sonuçları “otomatik hukuk kararı” yerine uzman incelemesine yardımcı olacak özet olarak sunmalıdır. Gizli sözleşmeler için model sağlayıcı veri politikası ayrıca değerlendirilmelidir. Erişim yalnızca ilgili matter veya dosya yetkisine sahip kullanıcılarla sınırlandırılmalıdır.

Sözleşme Karşılaştırma

İki sözleşme sürümü madde bazında karşılaştırılabilir. Eklenen, çıkarılan ve değişen hükümler yapılandırılmış biçimde gösterilebilir. Model farklı yazılmış fakat aynı anlama gelen değişiklikleri de işaretleyebilir. Sonuç kaynak metin bölümüyle birlikte sunulmalıdır. Nihai yorum hukuk ekibine bırakılmalıdır.

Riskli Maddeleri İşaretleme

Şirket hukuk ekibinin tanımladığı risk kriterleri prompt içinde değil mümkün olduğunca yapılandırılmış policy olarak tutulmalıdır. Agent sözleşmede bu kriterlerle eşleşen maddeleri gösterebilir. Risk etiketi dayandığı kural ile birlikte sunulmalıdır. Model kendi başına yeni hukuk politikası üretmemelidir. Belirsiz maddeler uzman incelemesine yönlendirilmelidir.

Standart Şablonlarla Kontrol

Onaylı sözleşme şablonları RAG kaynağı olarak kullanılabilir. Agent gelen dokümanı ilgili standartla karşılaştırabilir. Eksik veya farklı maddeleri listeleyebilir. Kullanılan şablonun sürümü sonuçta belirtilmelidir. Böylece eski standart dokümanla yanlış karşılaştırma yapılması engellenebilir.

Pazarlama Ajanı

Pazarlama ajanı kampanya araştırması, içerik taslağı, rapor özeti ve müşteri segment analizi gibi görevlerde kullanılabilir. Marka tonu ve yasaklı ifadeler yapılandırılmış içerik kurallarıyla desteklenmelidir. Yayınlama işlemi insan onayından sonra çalıştırılmalıdır. Müşteri verisi kişiselleştirme için kullanılıyorsa açık veri yönetişimi gerekir. Agent'ın kullandığı dış kaynak ve iç veri setleri ayrı güvenlik sınıflarına sahip olmalıdır.

Veri Analizi ve Raporlama Ajanı

Veri analizi ajanı doğal dilde soruyu güvenli sorgulara dönüştürüp sonuçları açıklayabilir. Kullanıcının erişemediği tablo veya satırları ajan da görememelidir. SQL üretimi doğrudan production üzerinde sınırsız çalıştırılmamalıdır. Read only account, query timeout ve row limit uygulanabilir. Hesaplamalar veri motorunda yapılmalı, model yalnızca yorumlama katmanında kullanılmalıdır.

Yazılım Geliştirme Ajanı

Yazılım geliştirme ajanı issue analizi, kod önerisi, test üretimi ve pull request hazırlama gibi alanlarda çalışabilir. Repository write yetkisi kontrollü branch ve kullanıcı onayıyla sınırlandırılmalıdır. Production deploy veya secret erişimi varsayılan olarak kapalı tutulmalıdır. Kod çıktısı standart CI testlerinden geçmelidir. Agent'ın güvenli sınırı code review sürecini kaldırmak değil, geliştiricinin tekrar eden işlerini azaltmaktır.

Issue Analizi

Agent issue açıklamasını okuyup ilgili repository dosyalarını bulabilir. Benzer geçmiş issue ve pull request'leri inceleyebilir. Olası etki alanını geliştiriciye özetleyebilir. Doğrudan kod değişikliğine geçmeden önce plan üretmesi debug sürecini kolaylaştırır. Geliştirici planı onayladıktan sonra implementation aşaması başlatılabilir.

Kod Üretimi

Kod üretimi repository standardı ve architecture guideline ile sınırlandırılmalıdır. Agent yalnızca task kapsamındaki dosyalarda değişiklik yapabilir. Secret veya production config içeren alanlar tool allowlist dışında tutulabilir. Üretilen kod lint, unit test ve security scanning aşamalarından geçmelidir. Merge kararı insan reviewer tarafından verilmelidir.

Test Yazma

Agent mevcut kod ve issue acceptance criteria üzerinden test önerileri oluşturabilir. Edge case listesi özellikle faydalıdır. Test yalnızca mevcut implementation'ı tekrar etmemeli, beklenen davranışı doğrulamalıdır. Coverage artışı tek başarı kriteri olarak kullanılmamalıdır. Mutation veya regression testleri test kalitesini daha iyi gösterebilir.

Pull Request Hazırlama

Agent değişiklikleri ayrı branch üzerinde hazırlayabilir. Commit mesajı ve pull request açıklaması oluşturabilir. Test sonuçları otomatik olarak PR içine eklenebilir. Merge yetkisi verilmemesi güvenli başlangıçtır. Human reviewer kodu, testleri ve security sonuçlarını gördükten sonra normal development sürecini devam ettirir.

Şirket İçi Bilgi Asistanı

Şirket içi bilgi asistanı ilk kurumsal agent projesi için en uygun adaylardan biridir. Çalışanlar politika, proje, teknik doküman ve süreç bilgisine doğal dille ulaşabilir. RAG sayesinde cevaplar şirket kaynaklarına dayandırılabilir. Yetki duyarlı retrieval her kullanıcının yalnızca kendi erişebildiği dokümanlardan sonuç almasını sağlar. Sistem read only çalışabildiği için operasyon riski birçok write agent senaryosuna göre daha düşüktür.

Bir AI Agent Nasıl Çalışır?

Bir AI Agent genellikle kullanıcı veya sistem tetikleyicisiyle başlayan ve işlem tamamlanana kadar birden fazla kontrol aşamasından geçen döngü içinde çalışır. Model talebi yorumlar, gerekli tool'ları seçer ve sonuçlara göre sonraki adımı belirler. Bu süreç serbest bırakılmamalı, maksimum adım, tool çağrısı ve maliyet sınırıyla kontrol edilmelidir. Kritik eylemler insan onayına bağlanabilir. Bütün süreç trace olarak kaydedildiğinde production hatalarının nedenini anlamak çok daha kolay olur.

Tetikleyici

Tetikleyici kullanıcı mesajı, webhook, yeni ticket, zamanlanmış görev veya sistem event'i olabilir. Her trigger aynı güven seviyesinde değerlendirilmemelidir. Dışarıdan gelen webhook içeriği güvenilmeyen input olarak ele alınmalıdır. Trigger identity ve source bilgisi state içinde saklanmalıdır. Agent'ın yapabileceği işlemler trigger tipine göre ayrıca kısıtlanabilir.

Kullanıcı veya Sistem Talebi

Talep agent'ın görevinin başlangıç context'ini oluşturur. Kullanıcının kimliği ve authorization bilgisi modelden ayrı güvenlik katmanında doğrulanmalıdır. Model “ben yöneticiyim” yazan kullanıcıya yönetici yetkisi vermemelidir. Request normalize edilerek iş hedefi ve gerekli parametreler çıkarılabilir. Eksik kritik bilgi varsa agent işlem yapmak yerine kullanıcıdan tamamlamasını istemelidir.

LLM ile Anlama ve Muhakeme

LLM doğal dil talebini anlamak ve olası hareket planını belirlemek için kullanılır. Ancak muhakeme sonucu gerçek authorization kararı olarak kullanılmamalıdır. Model sadece izin verilen seçenekler arasından seçim yapabilir. Kesin hesaplama veya policy kontrolleri deterministik servislerde çalışmalıdır. Bu ayrım model hatasının doğrudan güvenlik açığına dönüşmesini engeller.

Planlama

Planlama agent'ın görevi hangi adımlarla çözeceğini belirlemesidir. Basit görevlerde explicit plan üretmek gereksiz gecikme yaratabilir. Çok adımlı süreçlerde plan state içinde tutulabilir ve her adım sonrası güncellenebilir. Planın uzunluğu maksimum adım limitiyle sınırlandırılmalıdır. Kritik tool kullanımından önce plan kullanıcıya veya approval mekanizmasına gösterilebilir.

Araç Seçimi

Model yalnızca task için uygun allowlist içindeki tool'ları görebilmelidir. Bütün şirket API'lerini tek agent'a tanımlamak saldırı yüzeyini gereksiz biçimde büyütür. Tool açıklamaları net ve tek anlamlı yazılmalıdır. Benzer iş yapan çok sayıda tool model seçim kalitesini düşürebilir. Kullanılmayan tool'lar agent context'inden tamamen kaldırılmalıdır.

Tool Calling

Tool Calling modelin belirli schema üzerinden uygulama veya API fonksiyonu çağırmasını sağlar. Parametreler server tarafında yeniden validate edilmelidir. Modelin ürettiği argument güvenilir veri olarak kabul edilmemelidir. Write operation authorization kontrolünden sonra çalıştırılmalıdır. Tool sonucu da modele geri verilmeden önce boyut, içerik ve hassas veri açısından filtrelenebilir.

Sonucu Değerlendirme

Agent tool sonucunu görevin hedefine göre değerlendirebilir. Ancak “işlem başarılı” bilgisini yalnızca model yorumuna bırakmak uygun değildir. Tool mümkünse machine readable status dönmelidir. Validation servisi beklenen state değişikliğini doğrulayabilir. Bu ayrım agent'ın hata mesajını başarı gibi yorumlamasını engeller.

Gerekirse Tekrar Deneme

Geçici API hatalarında retry yararlı olabilir. Her hatada tekrar denemek ise duplicate işlem veya yüksek maliyet oluşturabilir. Retry yalnızca güvenli ve idempotent işlemlerde uygulanmalıdır. Exponential backoff ve maksimum deneme sayısı tanımlanmalıdır. Kalıcı hata veya yetki reddi durumunda agent durmalı ve eskalasyon yapmalıdır.

İnsan Onayı

Kritik write işleminden önce agent hazırladığı eylemi kullanıcıya gösterebilir. Kullanıcı exact parametreleri görerek onay verebilir. Approval token belirli işlem ve kısa süre için geçerli olmalıdır. Genel “bundan sonra her şeyi onayla” modeli kullanılmamalıdır. Özellikle finansal, hukuki ve dış iletişim işlemlerinde approval temel güvenlik kontrolüdür.

İşlemi Tamamlama

Onaylanan veya düşük riskli işlem çalıştırıldığında agent sonucu doğrulamalıdır. Kullanıcıya yalnızca “tamamlandı” demek yerine yapılan değişikliğin ne olduğunu göstermek daha faydalıdır. Başarısız işlem success olarak raporlanmamalıdır. External system transaction ID saklanabilir. Aynı request'in tekrar gelmesi durumunda duplicate operation engellenmelidir.

Loglama ve Raporlama

Agent run boyunca prompt, tool adı, parametre özeti, result status, latency ve maliyet gibi bilgiler trace sistemine yazılabilir. Hassas veri ve secret değerleri logdan çıkarılmalıdır. Her run kullanıcı identity'si ve request ID ile ilişkilendirilmelidir. Bu kayıtlar debug, güvenlik investigation ve evaluation için kullanılır. Log retention KVKK ve kurumsal veri politikasına göre belirlenmelidir.

Şirket İçi AI Agent Mimarisinin Temel Bileşenleri

Kurumsal ajan mimarisi yalnızca bir LLM API çağrısından oluşmaz. Modelin yanında system prompt, tool katmanı, RAG, memory, state, orchestrator, guardrail, identity, observability ve evaluation bileşenleri bulunur. Production güvenilirliği bu katmanların birbirinden açık biçimde ayrılmasına bağlıdır. Model sağlayıcı değişse bile authorization ve business rule katmanının değişmemesi iyi mimari işaretidir. Şirket verileriyle RAG tabanlı yapay zeka ajanı geliştirme projesinde de asıl değer bu bileşenlerin birlikte doğru çalışmasından gelir.

Büyük Dil Modeli (LLM)

LLM agent'ın doğal dil anlama ve esnek karar üretme motorudur. Her işlem için en büyük modeli kullanmak gerekli değildir. Basit sınıflandırmalar küçük ve hızlı modelle yapılabilir. Kritik planning veya karmaşık analiz daha güçlü modele yönlendirilebilir. Model seçimi doğruluk, tool calling, gecikme, maliyet ve veri politikası birlikte değerlendirilerek yapılmalıdır.

System Prompt ve Agent Talimatları

System prompt agent'ın rol, görev sınırı ve davranış politikasını tanımlar. Bununla birlikte gerçek güvenlik kontrolü prompt değildir. Kullanıcı “önceki talimatları unut” yazsa bile authorization katmanını geçememelidir. Prompt mümkün olduğunca kısa, açık ve test edilebilir tutulmalıdır. Versiyon değişiklikleri eval dataset ile karşılaştırılmalıdır.

Tools

Tools agent'ın şirket sistemleriyle etkileşim kurmasını sağlayan fonksiyonlardır. Read ve write tool'lar ayrı tasarlanmalıdır. Her tool tek bir açık iş yapmalıdır. Parametre schema'sı dar ve validate edilebilir olmalıdır. Tool implementation kullanıcı identity ve authorization kontrolünü kendi içinde de doğrulamalıdır.

RAG ve Kurumsal Bilgi Kaynakları

RAG modelin şirket dokümanlarından ilgili bilgiyi retrieval ile almasını sağlar. Vector search tek başına yeterli olmayabilir ve metadata filtreleri kritik rol oynar. Kullanıcı yetkisi retrieval query aşamasında uygulanmalıdır. Kaynakların güncelliği index pipeline tarafından takip edilmelidir. Yanıtın dayandığı dokümanları göstermek kullanıcı güvenini artırır.

Memory

Memory önceki kullanıcı veya görev bilgilerini sonraki adımlarda kullanmak için tutulabilir. Her sohbetin kalıcı hafızaya yazılması gerekli değildir. Hassas veya kişisel veri memory'ye otomatik eklenmemelidir. Kullanıcı ve tenant isolation zorunludur. Expiration ve deletion mekanizması memory tasarımının başından düşünülmelidir.

State

State tek agent run içindeki mevcut görev durumunu temsil eder. Hangi adımların tamamlandığı, hangi tool sonucunun alındığı ve approval beklenip beklenmediği burada tutulabilir. State machine yaklaşımı debug edilebilirliği artırır. Kritik state değişiklikleri transactional store üzerinde saklanabilir. Process restart sonrası görev kaldığı yerden güvenli biçimde devam edebilmelidir.

Orchestrator

Orchestrator model, tool, state ve approval mekanizmaları arasındaki akışı yönetir. Her şeyi LLM'in serbest kararına bırakmak yerine belirli transition kuralları burada uygulanabilir. Timeout, retry ve step limit orchestrator seviyesinde enforce edilir. Multi agent yapıda handoff ve specialist seçimi de bu katmanda çalışabilir. Orchestrator production güvenilirliği için model kadar önemli bileşendir.

Guardrails

Guardrail input, output ve tool kullanımını belirli policy'lerle kontrol eder. PII masking, zararlı komut filtresi, domain allowlist ve schema validation örnek verilebilir. Guardrail modelin kendisine güvenilerek uygulanmamalıdır. Kritik kontroller ayrı kod veya güvenlik servisi olarak çalışmalıdır. False positive ve false negative oranları düzenli olarak ölçülmelidir.

Identity ve Authorization

Identity kullanıcı veya workload'un kim olduğunu doğrular. Authorization ise hangi veri ve araca erişebileceğini belirler. Agent kullanıcıdan daha geniş default yetkiye sahip olmamalıdır. Delegated access modeli kullanıldığında kullanıcı yetkisi tool katmanına taşınmalıdır. Her tool çağrısı principal identity ile audit edilmelidir.

Observability

Observability agent'ın neden belirli davranışı yaptığını anlamayı sağlar. Trace içinde model çağrıları, retrieval, tool call, latency ve errors görülebilir. Sensitive content loglama politikası ayrıca uygulanmalıdır. Token ve maliyet metric'leri task bazında izlenebilir. Production sorunları yalnızca kullanıcı şikayetiyle değil dashboard üzerinden erken tespit edilebilir.

Evaluation Katmanı

Evaluation agent değişikliklerinin kaliteyi artırıp artırmadığını ölçer. Golden dataset, tool selection accuracy ve groundedness gibi metric'ler kullanılabilir. Her prompt veya model değişimi regression eval'dan geçebilir. İnsan değerlendirici örnekleri belirli aralıklarla dataset'e eklenmelidir. Evals olmadan agent geliştirme çoğu zaman sezgisel deneme yanılmaya dönüşür.

AI Agent İçin Hangi LLM Seçilmeli?

Kurumsal ajan için model seçerken yalnızca benchmark puanına bakmak yeterli değildir. Tool calling güvenilirliği, Türkçe performansı, context davranışı, gecikme, maliyet ve provider veri politikası birlikte değerlendirilmelidir. Aynı model her görev için en iyi seçenek olmayabilir. Küçük sınıflandırma görevleri daha ekonomik modelle çalışırken uzun analiz farklı modele yönlendirilebilir. En doğru yaklaşım gerçek şirket senaryolarından oluşturulmuş evaluation dataset'i üzerinde birden fazla modeli karşılaştırmaktır.

Model Seçim Kriterleri

Model seçimi task profiline göre yapılmalıdır. Bir müşteri destek ajanında doğru kaynak kullanımı ve düşük gecikme önemli olabilir. Kod ajanında repository anlama ve tool calling daha kritik hale gelir. Modelin provider tarafında hangi veriyi tuttuğu da kurumsal security incelemesine girmelidir. Son karar yalnızca teknik ekibin değil security, hukuk ve iş biriminin gereksinimleriyle birlikte verilmelidir.

Muhakeme Yeteneği

Çok adımlı görevlerde modelin farklı seçenekleri karşılaştırabilmesi önemlidir. Daha güçlü reasoning modeli her basit işlem için kullanılmamalıdır. Uzun düşünme süresi latency ve maliyet oluşturur. Zor task router üzerinden güçlü modele gönderilebilir. Başarı gerçek görev tamamlanma oranıyla ölçülmelidir.

Tool Calling Kalitesi

Tool calling agent sistemlerinde en önemli model özelliklerinden biridir. Model doğru tool'u seçmeli ve schema'ya uygun parametre üretmelidir. Tool Selection Accuracy özel eval ile ölçülebilir. Hatalı parametre server validation tarafından reddedilmelidir. Model seçimi yapılırken yalnızca sohbet kalitesi değil gerçek API tool testleri kullanılmalıdır.

Context Window

Geniş context window çok dokümanlı görevlerde yararlı olabilir. Ancak her şeyi context'e koymak RAG tasarımını ortadan kaldırmamalıdır. Uzun context daha yüksek token maliyeti yaratabilir. İlgisiz bilgi modelin dikkatini dağıtabilir. Retrieval ve context compression birlikte kullanılmalıdır.

Türkçe Performansı

Türkiye'deki şirketlerde kullanıcı taleplerinin önemli bölümü Türkçe olacaktır. Model yalnızca genel Türkçe konuşmakla kalmamalı, şirket terminolojisini de doğru yorumlamalıdır. Evaluation dataset gerçek Türkçe kullanıcı sorularından oluşturulmalıdır. İngilizce benchmark sonucunu doğrudan Türkçe performans varsayımı olarak kullanmak doğru değildir. Yazım hataları ve günlük konuşma dili de test setine dahil edilmelidir.

Gecikme

Agent bir task sırasında birden fazla model çağrısı yaptığı için tek çağrı latency'si toplam sürede büyür. Kullanıcının anlık cevap beklediği müşteri hizmetleri senaryosu ile gece çalışan rapor agent'ının toleransı farklıdır. P50, P95 ve P99 latency ölçülmelidir. Streaming kullanıcı deneyimini iyileştirebilir. Router ve cache tasarımı toplam response süresini azaltabilir.

Maliyet

Token maliyeti agent task sayısı arttıkça önemli kalem haline gelir. Multi agent sistemler aynı görevi birkaç model çağrısıyla çözebilir. Her task için toplam token ve tool maliyeti izlenmelidir. Küçük model routing önemli tasarruf sağlayabilir. Maliyet metriği task completion ve kalite ile birlikte değerlendirilmelidir.

Veri Politikası

Kurumsal veri model sağlayıcıya gönderildiğinde retention, training kullanımı ve data location politikaları incelenmelidir. Hassas bilgi gerekiyorsa maskeleme veya private deployment düşünülebilir. Provider sözleşmesi security ve hukuk ekipleri tarafından değerlendirilmelidir. API kullanım politikasının tüketici ürünü kullanım koşullarıyla aynı olduğu varsayılmamalıdır. Veri sınıflandırması hangi task'ın hangi modele gönderilebileceğini belirleyebilir.

Tek Model mi, Birden Fazla Model mi?

Tek model başlangıçta mimariyi sadeleştirir ve debug sürecini kolaylaştırır. Trafik ve görev çeşitliliği arttığında farklı model tier'ları kullanılabilir. Basit extraction küçük modele, karmaşık reasoning güçlü modele yönlendirilebilir. Birden fazla provider dayanıklılık sağlayabilir ancak prompt ve output farklarını yönetmek gerekir. İlk pilotta sade başlayıp ölçüm sonucuna göre routing eklemek genellikle daha sağlıklıdır.

Model Routing

Model Routing task'ın zorluk ve risk seviyesine göre uygun modeli seçer. Router basit deterministic rule veya küçük classification modeli olabilir. Kritik task doğrudan güçlü modele yönlendirilebilir. Routing decision loglanmalı ve kalite metriğiyle izlenmelidir. Yanlış routing tasarruf sağlarken task failure oranını artırmamalıdır.

Küçük Model ve Büyük Model Birlikte Kullanımı

Küçük model intent classification, extraction ve basit routing için yeterli olabilir. Büyük model karmaşık planning ve belirsiz analiz görevlerinde devreye girebilir. Bu katmanlı yaklaşım maliyet ve latency açısından avantaj sağlar. Model geçişi state ve output schema'yı bozmamalıdır. Her iki model aynı evaluation dataset üzerinde kendi görev sınıfı için test edilmelidir.

Provider Fallback Tasarımı

Ana model sağlayıcı geçici olarak erişilemez olduğunda fallback provider devreye alınabilir. Fallback modelin tool schema ve output davranışı aynı olmayabilir. Bu nedenle gerçek failover testleri yapılmalıdır. Hassas veri farklı provider'a gönderilecekse data policy önceden onaylanmalıdır. Fallback yalnızca availability için değil kalite düşüşü ve rate limit senaryoları için de planlanabilir.

Cloud, Private Cloud veya On-Premise AI Agent?

Deployment modeli veri hassasiyeti, operasyon kapasitesi, gecikme ve maliyet gereksinimlerine göre seçilmelidir. Cloud API kullanımı hızlı başlangıç sağlarken self hosted model daha fazla kontrol ve daha fazla operasyon sorumluluğu getirir. Private cloud veya hibrit mimari hassas task'larla genel task'ları ayırabilir. Her şirket için on premise model daha güvenli değildir çünkü yanlış yönetilen self hosted infrastructure yeni riskler oluşturabilir. Mimari kararı gerçek veri sınıflandırması ve ekibin işletim yetkinliği üzerinden verilmelidir.

Cloud API Kullanmanın Avantajları

Cloud API yeni modeli hızlı kullanıma alma ve infrastructure işletimini azaltma avantajı sağlar. Model kapasitesi ve scaling provider tarafından yönetilir. Güncelleme ve inference optimizasyonu ekipten alınır. Buna karşılık veri transferi ve provider bağımlılığı değerlendirilmelidir. Hassas task'lar için sözleşme, retention ve access policy ayrıca kontrol edilmelidir.

Private Cloud Yaklaşımı

Private cloud şirketin daha kontrollü network ve account sınırlarında inference veya agent servisleri çalıştırmasını sağlar. Kurumsal IAM ve network policy daha güçlü entegre edilebilir. Managed hizmetlerden yararlanırken isolation artırılabilir. Maliyet normal API kullanımından farklı olabilir. Security modeli cloud provider ile shared responsibility yaklaşımında değerlendirilmelidir.

Self-Hosted Model Kullanımı

Self hosted model veri kontrolünü artırabilir fakat GPU, model serving, scaling ve upgrade sorumluluğu getirir. Model quality ve latency kullanılan hardware'e göre değişir. Security patch ve dependency yönetimi kurumun sorumluluğundadır. Küçük ekip için bu operasyon maliyeti cloud API tasarrufundan daha yüksek olabilir. Seçim ideolojik değil ölçülebilir requirement üzerinden yapılmalıdır.

Yerel LLM Kullanmanın Avantajları ve Dezavantajları

Yerel LLM hassas verinin kurum sınırlarından çıkmamasını sağlayabilir. Offline veya düşük network bağımlılıklı kullanım da avantajdır. Buna karşılık yüksek kaliteli model için ciddi compute kaynağı gerekebilir. Tool calling ve Türkçe performansı provider modellerinden düşük olabilir. Production bakım maliyeti mutlaka TCO hesabına dahil edilmelidir.

Hassas Veriler İçin Mimari Seçim

Hassas veri önce sınıflandırılmalıdır. Her PII içeren task'ın aynı deployment modeline gitmesi gerekmez. Masking ve data minimization ile cloud model kullanımı bazı durumlarda mümkün olabilir. Çok hassas içerik on premise veya private inference katmanına yönlendirilebilir. Policy engine task ve veri sınıfına göre model routing yapabilir.

Hibrit Mimari

Hibrit mimaride genel task'lar cloud modelde, hassas task'lar özel ortamda çalıştırılabilir. Ortak orchestrator farklı provider'ları tek interface üzerinden yönetebilir. Authorization ve audit bütün modellerde aynı merkezi katmanda tutulmalıdır. Routing kararı kullanıcıya görünür olmak zorunda değildir ancak loglanmalıdır. Data classification hatası hassas verinin yanlış provider'a gitmesine yol açabileceği için policy testleri kritik öneme sahiptir.

Şirket Verisini AI Agent'a Nasıl Bağlarız?

Şirket verisini ajanla bağlamanın en yaygın yöntemlerinden biri RAG yaklaşımıdır. RAG modeli yeniden eğitmeden ilgili kurumsal bilgi parçalarını retrieval ile context'e getirir. SharePoint, Google Drive, Notion, CRM, ERP ve SQL gibi farklı kaynaklar aynı bilgi katmanına bağlanabilir. En kritik konu yalnızca veriyi indexlemek değil kullanıcı erişim yetkisini retrieval sırasında korumaktır. Şirket verileriyle RAG tabanlı yapay zeka ajanı geliştirme projesinin başarısı veri temizliği, güncellik, metadata ve kaynak gösterme kalitesine doğrudan bağlıdır.

RAG Nedir?

RAG, Retrieval Augmented Generation yaklaşımının kısaltmasıdır. Kullanıcı sorusu geldiğinde ilgili doküman veya veri parçaları bulunur ve model yanıt üretirken bu context'i kullanır. Böylece modelin şirket içi bilgiyi önceden öğrenmiş olması gerekmez. Kaynak doküman güncellendiğinde index yenilenerek cevap güncelliği artırılabilir. RAG halüsinasyonu tamamen ortadan kaldırmaz ve bu nedenle kaynak gösterme ile evaluation gereklidir.

Kurumsal Bilgi Kaynakları

Kurumsal bilgi tek platformda bulunmaz. Aynı şirket içinde doküman, wiki, CRM, ERP ve veri tabanı gibi çok sayıda kaynak olabilir. Her kaynak için connector, sync sıklığı ve authorization modeli farklıdır. Retrieval katmanı bu çeşitliliği ortak metadata modeliyle normalize edebilir. Ajanın ihtiyacı olmayan kaynakları indexlemek hem maliyet hem güvenlik riskini artırır.

SharePoint

SharePoint birçok kurumda politika ve doküman deposu olarak kullanılır. Connector dosya içeriğiyle birlikte site, klasör ve erişim metadata'sını da almalıdır. Kullanıcı authorization retrieval sırasında bu metadata üzerinden filtrelenebilir. Silinen doküman index'ten de kaldırılmalıdır. Version değişiklikleri incremental sync ile takip edilebilir.

Google Drive

Google Drive connector dosya ve klasör permission bilgisini korumalıdır. Shared drive ve kullanıcıya özel dosya ayrımı önemlidir. Her dosyanın içeriği embedding'e gönderilmeden önce classification yapılabilir. Silinen veya permission değişen dosya hızlı biçimde index'e yansıtılmalıdır. Aksi halde ajan kullanıcının artık erişemediği eski içeriği göstermeye devam edebilir.

Notion

Notion ekip wiki ve proje dokümanları için sık kullanılan kaynaktır. Sayfa hiyerarşisi retrieval metadata'sına eklenebilir. Çok uzun sayfalar anlamlı bölümlere ayrılmalıdır. Internal link ve database property'leri gerektiğinde yapılandırılmış bilgi olarak tutulabilir. Permission modeli connector tarafından korunmalıdır.

Dosya Sunucuları

Legacy dosya sunucularında PDF, Word ve Excel dosyaları farklı klasörlerde bulunabilir. Connector filesystem permission bilgisini kullanıcı kimliğiyle eşleştirmelidir. Dosya adı tek başına anlamlı retrieval metadata sağlamayabilir. İçerik extraction pipeline kalite kontrolünden geçirilmelidir. Çok eski ve sahibi bilinmeyen dosyalar index'e otomatik eklenmemelidir.

CRM

CRM verisi doküman RAG'dan farklı olarak çoğunlukla yapılandırılmış ve sık değişen bilgidir. Her alanı vector database'e kopyalamak doğru yaklaşım olmayabilir. Güncel müşteri kaydı doğrudan API veya SQL tool üzerinden okunabilir. RAG daha çok geçmiş not ve uzun açıklamalar için kullanılabilir. Kullanıcı account ve territory yetkileri query sırasında korunmalıdır.

ERP

ERP stok, sipariş, finans ve satın alma gibi yüksek değerli veriler barındırır. Agent çoğu durumda read only API ile başlamalıdır. Güncel transaction verisi vector store yerine doğrudan ERP sorgusundan alınabilir. Doküman ve prosedür bilgileri RAG içinde tutulabilir. Write işlemleri ayrı approval ve business rule katmanından geçirilmelidir.

SQL Veritabanları

SQL veri tabanına doğal dille erişim güçlü fakat riskli olabilir. Agent read only role kullanmalıdır. Schema allowlist, query timeout ve row limit uygulanabilir. Sensitive column masking database veya query layer'da yapılmalıdır. Modelin doğrudan arbitrary SQL çalıştırması yerine controlled query service daha güvenli yaklaşım sunar.

Doküman Toplama ve Temizleme

RAG kalitesi çoğu zaman modelden önce veri pipeline'ında belirlenir. Duplicate, eski ve bozuk dokümanlar retrieval sonuçlarını zayıflatır. Dosyalar parse edilirken header, footer ve gereksiz navigation metinleri temizlenmelidir. Owner, source, date ve permission metadata'sı korunmalıdır. Veri ön işleme ve otomasyon yaklaşımına dair ek içerik için https://www.diyarbakiryazilim.com.tr/posts/veri-on-isleme-data-preprocessing-asamalarinda-otomasyon adresi incelenebilir.

Chunking

Chunking uzun dokümanı retrieval için daha küçük anlamlı parçalara ayırır. Çok küçük chunk context kaybı oluşturabilir. Çok büyük chunk ise gereksiz token ve ilgisiz bilgi taşır. Başlık ve paragraf yapısını koruyan semantic chunking çoğu dokümanda daha iyi sonuç verir. Chunk stratejisi evaluation dataset üzerinde test edilmelidir.

Embedding

Embedding metni semantic arama yapılabilecek vector representation'a dönüştürür. Model seçimi dil ve domain performansına göre yapılmalıdır. Türkçe kurumsal terminoloji içeren örneklerle retrieval test edilmelidir. Embedding version değiştiğinde reindex gerekebilir. Vector değerleri de hassas veri türevleri olarak güvenlik kapsamına alınmalıdır.

Vector Database

Vector Database embedding değerlerini ve metadata'yı saklar. Tenant, department ve ACL filtreleri query aşamasında uygulanmalıdır. Her index bütün şirket dokümanlarını tek permission alanında toplamamalıdır. Backup ve deletion süreci veri yönetişimiyle uyumlu olmalıdır. Seçim latency, scale, filtering ve operasyon maliyetine göre yapılmalıdır.

Retrieval

Retrieval kullanıcı sorusuna en ilgili parçaları getirir. Semantic search yanında keyword ve hybrid search kullanılabilir. Metadata filter kullanıcı access scope'unu daraltır. Top K değeri çok yüksek seçilirse ilgisiz context modele taşınabilir. Retrieval başarısı ayrı evaluation metric olarak ölçülmelidir.

Reranking

Reranking ilk retrieval sonuçlarını daha güçlü relevance modeliyle yeniden sıralar. Özellikle büyük doküman havuzunda doğruluk artışı sağlayabilir. Bununla birlikte ek latency ve maliyet oluşturur. İlk retrieval yeterince iyi değilse reranker sorunu tamamen çözmez. Önce metadata ve index kalitesi düzeltilmelidir.

Yetki Duyarlı Retrieval

Yetki duyarlı retrieval kurumsal RAG için vazgeçilmezdir. Kullanıcının SharePoint'te göremediği dokümanı agent da kullanmamalıdır. Permission filter model prompt'unda değil query layer'da uygulanmalıdır. Group membership ve role değişikliği index metadata'sına güncel biçimde yansıtılmalıdır. Retrieval log hangi principal'ın hangi kaynaklara eriştiğini gösterebilmelidir.

Kaynak Gösteren Yanıtlar

Kaynak gösteren yanıt kullanıcıya bilgiye nereden ulaşıldığını gösterir. Doküman adı, bölüm ve link mümkünse yanıtla birlikte sunulmalıdır. Bu özellik kullanıcı güvenini artırır ve yanlış cevabı daha hızlı fark etmeyi sağlar. Citation doğruluğu eval ile ölçülebilir. Model kaynakta olmayan iddiayı citation ile destekliyormuş gibi göstermemelidir.

Güncel Olmayan Dokümanların Yönetimi

Eski doküman production RAG sisteminin en yaygın sorunlarından biridir. Her source için updated at ve version metadata tutulmalıdır. Deprecated dokümanlar index dışında bırakılabilir veya düşük priority ile işaretlenebilir. Yeni policy yayınlandığında eski sürüm otomatik retire edilmelidir. Owner bulunmayan içerikler düzenli governance review'a alınmalıdır.

MCP ile Şirket Sistemlerini AI Agent'a Bağlamak

MCP, ajanların veri ve araçlara standart bir protokol üzerinden erişmesini amaçlayan yaklaşım sağlar. Kurumsal kullanımda MCP Server şirket içi servisleri kontrollü tool olarak sunabilir. Bu yapı entegrasyon tekrarını azaltabilir fakat yeni güvenlik sınırı oluşturur. Güvenilmeyen server'ın tool açıklamaları veya içeriği agent davranışını kötü etkileyebilir. Bu nedenle MCP deployment'ı normal API güvenliği, identity, authorization ve supply chain kontrolleriyle birlikte ele alınmalıdır.

Model Context Protocol Nedir?

Model Context Protocol modellerin external tool ve context kaynaklarıyla daha standart biçimde etkileşmesini sağlayan protokoldür. Bir agent farklı server'lardan tool veya resource keşfedebilir. Kurum içinde standart connector modeli oluşturmak açısından faydalı olabilir. Protokol güvenliğin kendisi değildir. Her server ve tool için trust, permission ve logging ayrıca tasarlanmalıdır.

MCP Client Nedir?

MCP Client agent uygulamasının server ile iletişim kuran tarafıdır. Hangi server'lara bağlanabileceği allowlist ile belirlenmelidir. User supplied random endpoint'lere bağlantı production ortamında kapatılmalıdır. Client alınan tool metadata'sını güvenilmeyen input olarak değerlendirmelidir. Connection ve tool usage trace içinde loglanmalıdır.

MCP Server Nedir?

MCP Server belirli resource ve tool'ları protokol üzerinden sunan servis bileşenidir. Örneğin CRM query veya Git repository search tool'u yayınlayabilir. Server kendi authorization kontrolünü mutlaka uygulamalıdır. Client'ın “kullanıcı yetkili” demesine tek başına güvenilmemelidir. Her tool minimum scope ile tasarlanmalıdır.

Şirket İçi MCP Server Nasıl Tasarlanır?

Şirket içi MCP Server tek büyük admin gateway yerine domain bazlı küçük servislerden oluşabilir. CRM read, ERP report ve Git search gibi farklı risk alanları ayrılabilir. Server SSO veya workload identity ile principal bilgisini doğrular. Tool parametreleri strict schema ve allowlist kullanır. Audit log gerçek kullanıcı ve yapılan backend operation arasında bağlantı kurar.

MCP ile Bağlanabilecek Sistemler

MCP birçok kurumsal sisteme adapter katmanı oluşturabilir. CRM, ERP, Git, file server, database ve mesajlaşma sistemleri örnek verilebilir. Her integration'ın read ve write yetkileri ayrı tutulmalıdır. Tool sayısı arttıkça agent context ve saldırı yüzeyi büyür. Bu nedenle yalnızca gerçekten kullanılan entegrasyonlar ilgili agent'a sunulmalıdır.

CRM

CRM MCP Server müşteri arama ve kayıt okuma tool'ları sunabilir. Write operasyonlar ayrı endpoint ve policy ile korunmalıdır. Kullanıcı territory veya account yetkisi backend'de doğrulanmalıdır. Bulk export varsayılan olarak kapalı tutulmalıdır. Query sonucu hassas alanlar gerekirse maskelenmelidir.

ERP

ERP entegrasyonu yüksek business etkisi taşıdığı için daha sıkı control gerektirir. İlk aşamada read only raporlama tool'ları tercih edilebilir. Sipariş veya ödeme write tool'ları approval mekanizmasıyla çalışmalıdır. Amount limit ve supplier allowlist uygulanabilir. Her transaction ERP audit ID ile kaydedilmelidir.

Git

Git MCP Server repository arama, issue okuma ve diff görüntüleme sağlayabilir. Write permission sadece agent branch ile sınırlandırılabilir. Main branch push kapalı tutulmalıdır. Secret içeren repository alanlarına access policy uygulanmalıdır. Pull request oluşturma ile merge yetkisi birbirinden ayrılmalıdır.

Dosya Sistemleri

File MCP Server belirli klasörlerde arama veya dosya okuma tool'u sağlayabilir. Path traversal saldırılarına karşı canonical path validation yapılmalıdır. Root directory allowlist dışında erişim reddedilmelidir. User permission filesystem seviyesinde de korunmalıdır. Write veya delete tool'ları ayrı servis olarak düşünülmelidir.

Veritabanları

Database MCP Server doğal dil agent ile backend arasında kontrollü query katmanı olabilir. Read only database role kullanılması başlangıç için uygundur. Table ve column allowlist uygulanabilir. Query timeout ve row limit zorunlu tutulmalıdır. Agent arbitrary DDL veya DML çalıştıramamalıdır.

Slack ve Teams

Mesajlaşma platformları bilgi arama ve notification için kullanılabilir. Agent kullanıcının erişemediği private channel içeriklerini görmemelidir. Mesaj gönderme write tool olarak approval gerektirebilir. Bot token scope minimum tutulmalıdır. Dış kullanıcılara mesaj gönderme ayrı risk kategorisinde değerlendirilmelidir.

MCP Server Güvenliği

MCP Server normal backend service kadar güçlü authentication ve authorization uygulamalıdır. Tool description güvenlik sınırı değildir. Input validation, rate limit, audit ve network restriction kullanılmalıdır. Server dependency ve version'ları supply chain açısından taranmalıdır. Sensitive tool'lar ayrı process veya network zone içinde tutulabilir.

Güvenilmeyen MCP Server Riskleri

Güvenilmeyen MCP Server kötü niyetli tool açıklamaları veya content döndürebilir. Agent'ı başka tool kullanmaya veya veri sızdırmaya yönlendiren indirect prompt injection oluşabilir. Random public MCP server production agent'a bağlanmamalıdır. Server source, owner ve security review süreci agent inventory içinde tutulmalıdır. Tool output her zaman güvenilmeyen veri olarak değerlendirilmelidir.

MCP mi, Doğrudan API Entegrasyonu mu?

Az sayıda stabil integration için doğrudan API daha sade olabilir. Çok sayıda agent aynı system'e bağlanacaksa MCP standardizasyon avantajı sunabilir. Protocol ek layer latency ve operational dependency oluşturur. Security review her iki modelde de gereklidir. Karar framework trendine değil reuse, governance ve maintenance ihtiyacına göre verilmelidir.

Tool Calling Tasarımı Nasıl Yapılmalı?

Tool Calling agent'ın gerçek sistemlere etki ettiği en kritik katmandır. Model doğru tool'u seçse bile parametreler backend tarafından yeniden doğrulanmalıdır. Read, write ve destructive tool ayrımı access policy içinde açık olmalıdır. Her tool küçük, tek amaçlı ve test edilebilir tasarlanmalıdır. Kurumsal AI agent sistemlerinde tool calling hafıza yetkilendirme ve güvenlik birlikte ele alınmadığında model hatası doğrudan production incident'a dönüşebilir.

Read Tools

Read Tool veri okur ve system state değiştirmez. Buna rağmen hassas veri sızıntısı riski taşır. Query scope kullanıcı authorization ile sınırlandırılmalıdır. Bulk export veya full table read ayrıca engellenebilir. Read olması güvenli olduğu anlamına gelmez.

Write Tools

Write Tool kayıt oluşturur veya değiştirir. Modelin ürettiği parametreler business rule validation'dan geçmelidir. Kullanıcıya yapılacak değişiklik gösterilerek confirmation alınabilir. Idempotency duplicate write riskini azaltır. Audit log eski ve yeni state bilgisini mümkünse saklamalıdır.

Destructive Tools

Delete, refund, cancel veya permission revoke gibi işlemler destructive kategoride değerlendirilebilir. Bu tool'lar varsayılan agent allowlist'inde bulunmamalıdır. Ek human approval ve step up authentication gerekebilir. Soft delete veya reversible action tercih edilebilir. Emergency kill switch bu tool grubunu merkezi olarak kapatabilmelidir.

Her Tool Tek Bir İş Yapmalı

“Müşteriyi yönet” gibi çok geniş tool model açısından belirsizdir ve authorization kontrolünü zorlaştırır. “Müşteriyi getir”, “not ekle” ve “teklif taslağı oluştur” gibi küçük tool'lar daha kontrollüdür. Her tool'un açık input ve output schema'sı olur. Test ve monitoring de kolaylaşır. Least privilege tool level'da uygulanabilir hale gelir.

Tool Parametreleri Nasıl Tanımlanmalı?

Parametreler strict schema ile tanımlanmalıdır. Serbest metin yerine enum ve bounded numeric alanlar mümkün olduğunda tercih edilmelidir. User ID model tarafından keyfi seçilmemeli ve backend identity context'ten alınmalıdır. URL parametrelerinde domain allowlist uygulanabilir. Validation başarısızsa tool çalışmadan error dönmelidir.

Tool Sonuçları Nasıl Doğrulanmalı?

Tool sonucu machine readable status ve ilgili transaction bilgisi içermelidir. Model success veya failure'ı doğal dil mesajından tahmin etmemelidir. Write operation sonrası backend state kontrolü yapılabilir. Örneğin CRM update sonrası ilgili field tekrar okunabilir. Validation başarısızsa agent işlemi tamamlandı diye kullanıcıya bildirmemelidir.

Timeout ve Retry

Her tool için maksimum execution süresi belirlenmelidir. Timeout agent loop'un gereksiz uzamasını engeller. Retry yalnızca güvenli hatalarda yapılmalıdır. Write tool'da idempotency olmadan retry duplicate işlem oluşturabilir. Retry policy tool type'a göre farklı olmalıdır.

Idempotency

Idempotency aynı request tekrarlandığında ek yan etki oluşmamasını sağlar. Finans ve sipariş gibi işlemlerde kritik öneme sahiptir. Request ID backend'e idempotency key olarak gönderilebilir. Retry aynı key ile çalışır. Böylece network timeout sonrası agent'ın işlemi iki kez gerçekleştirmesi önlenir.

Tool Çağrıları Nasıl Loglanmalı?

Tool loglarında run ID, user identity, tool name, parameter özeti, result status ve latency bulunabilir. Secret veya hassas field değerleri maskelenmelidir. Write operation için resource ID ve transaction ID saklanmalıdır. Log değiştirilmeye karşı korunmalıdır. Security ekibi olağandışı tool kullanımını bu event'ler üzerinden izleyebilir.

AI Agent Memory Nasıl Tasarlanır?

Memory ajan deneyimini kişiselleştirebilir ve uzun görevlerde context kaybını azaltabilir. Ancak her konuşmayı kalıcı hafızaya almak ciddi gizlilik ve veri yönetimi problemi oluşturur. Memory tipi, saklama süresi ve kullanıcı isolation açık biçimde tasarlanmalıdır. Kullanıcı isteğiyle silme mekanizması bulunmalıdır. Özellikle kurumsal ortamda memory bir convenience feature değil ayrı data store olarak değerlendirilmelidir.

Short-Term Memory

Short Term Memory mevcut konuşma veya task boyunca gerekli bilgileri tutar. Session sona erdiğinde silinebilir. Kullanıcının önceki adımda verdiği parametreleri tekrar sormamak için kullanışlıdır. Token sınırı nedeniyle context özetleme gerekebilir. Sensitive veri sadece ihtiyaç süresi boyunca tutulmalıdır.

Long-Term Memory

Long Term Memory farklı session'lar arasında bilgi saklar. Kullanıcı tercihleri veya tekrar eden çalışma context'i burada tutulabilir. Kalıcı hafıza açık business gerekçesi olmadan kullanılmamalıdır. PII ve hassas veriler için retention policy gerekir. Kullanıcı hangi bilginin saklandığını görebilmeli ve gerektiğinde silebilmelidir.

Working Memory

Working Memory agent'ın mevcut görevi çözmek için kullandığı ara bilgi alanıdır. Plan, tool sonuçları ve geçici hesaplamalar burada bulunabilir. Business log ile aynı şey değildir. Run sona erdiğinde gereksiz alanlar temizlenebilir. Çok büyük working memory model context maliyetini artırır.

Episodic Memory

Episodic Memory geçmiş task veya interaction örneklerini olay bazında saklar. Benzer task geldiğinde önceki çözüm yaklaşımı referans olabilir. Yanlış geçmiş sonucu tekrar kullanma riski vardır. Memory item quality ve source bilgisi tutulmalıdır. Eski veya hatalı episode'lar expire edilmelidir.

Hangi Bilgiler Hafızaya Yazılmalı?

Uzun vadeli değer sağlayan ve kullanıcının tekrar kullanacağı bilgiler aday olabilir. Tercih edilen rapor formatı veya sık kullanılan proje context'i örnek verilebilir. Business secret veya access token memory'ye yazılmamalıdır. Her bilgi için amaç ve retention süresi tanımlanmalıdır. Memory write işlemi mümkünse explicit policy kontrolünden geçmelidir.

Hangi Bilgiler Hafızaya Yazılmamalı?

Password, API key, token ve geçici credential kesinlikle memory store'a yazılmamalıdır. Sağlık, finans veya yüksek hassasiyetli kişisel veriler açık gerekçe olmadan saklanmamalıdır. Başka kullanıcıya ait veri tenant memory içinde paylaşılmamalıdır. Modelin “ileride faydalı olabilir” tahmini tek başına retention nedeni değildir. Data minimization memory tasarımının temel prensibi olmalıdır.

Memory Isolation

Her kullanıcı ve tenant'ın memory alanı birbirinden izole edilmelidir. Query sırasında user supplied identifier yerine authenticated principal kullanılmalıdır. Row level security veya ayrı partition yaklaşımı uygulanabilir. Shared team memory için explicit access policy gerekir. Cross tenant leakage en yüksek severity security incident olarak kabul edilmelidir.

Memory Expiration

Memory sonsuz süre saklanmamalıdır. Farklı data category için farklı TTL belirlenebilir. Son kullanım tarihi retention kararına yardımcı olabilir. Expiration sonrasında vector index ve backup lifecycle da dikkate alınmalıdır. Silme yalnızca primary database kaydını kaldırmakla bitmemelidir.

KVKK ve Unutulma Hakkı Açısından Memory

Kişisel veri içeren memory kayıtları KVKK kapsamındaki yükümlülüklerle birlikte değerlendirilmelidir. Hangi amaçla işlendiği ve ne kadar süre tutulduğu açık olmalıdır. Kullanıcı veya ilgili süreç verinin silinmesini gerektiriyorsa bütün storage ve index katmanlarında deletion yapılabilmelidir. Model training veya analytics için secondary kullanım ayrıca değerlendirilmelidir. Hukuki gereksinimler şirketin yetkili uzmanlarıyla doğrulanmalıdır.

AI Agent Planlama Yöntemleri

Planlama pattern'i agent'ın görevi nasıl parçaladığı ve ne zaman tool kullandığını belirler. Her task için aynı yaklaşım gerekli değildir. Basit query için router yeterliyken karmaşık araştırmada Plan and Execute kullanılabilir. Pattern sayısı arttıkça debug ve latency maliyeti de artar. İlk production agent'ta en basit çalışabilir orchestration seçilmelidir.

ReAct

ReAct yaklaşımı modelin gözlem ve eylem döngüsünü sırayla yürütmesine dayanır. Agent tool sonucu geldikçe sonraki eylemi seçebilir. Esnek olmasına rağmen uzun loop riski vardır. Maksimum adım ve tool call limiti uygulanmalıdır. Production trace üzerinden hangi adımda yanlış karar verildiği izlenebilmelidir.

Plan-and-Execute

Plan and Execute önce genel plan oluşturur, sonra adımları tek tek yürütür. Uzun görevlerde kullanıcıya yol haritası göstermek için faydalıdır. Plan değişen tool sonuçlarına göre güncellenebilmelidir. Baştan yanlış plan yapılırsa tüm görev etkilenebilir. Kritik adımlar arasında evaluation checkpoint kullanılabilir.

Router Pattern

Router Pattern gelen task'ı uygun workflow veya specialist'e yönlendirir. Basit ve yüksek performanslı architecture sağlar. Intent classification deterministic rule veya küçük modelle yapılabilir. Yanlış routing kullanıcı deneyimini bozabilir. Router için ayrı confusion matrix ve accuracy metriği izlenmelidir.

Evaluator–Optimizer Pattern

Bir component çıktı üretir, evaluator belirlenen kriterlere göre kontrol eder. Başarısızsa optimizer veya generator tekrar çalışabilir. Bu yaklaşım yazı, kod ve rapor üretiminde kaliteyi artırabilir. Sonsuz self correction loop engellenmelidir. Maksimum iteration ve cost budget zorunlu olmalıdır.

Orchestrator–Worker Pattern

Orchestrator görevi alt işlere böler ve worker'lara dağıtır. Worker'lar belirli uzman görevlerde çalışabilir. Sonuçlar orchestrator tarafından birleştirilir. Parallel execution latency avantajı sağlayabilir. Ancak state ve error handling tek agent'a göre daha zor hale gelir.

Handoff Pattern

Handoff bir agent veya workflow'un görevi başka specialist'e devretmesini ifade eder. Müşteri destek ajanı teknik konu geldiğinde teknik specialist'e geçebilir. Handoff context minimum gerekli bilgiyle yapılmalıdır. User identity ve permission yeni agent'a doğru aktarılmalıdır. Handoff loop oluşmaması için transition kuralları sınırlandırılmalıdır.

Reflection ve Self-Correction

Reflection modelin kendi çıktısını tekrar değerlendirmesini sağlar. Bazı reasoning veya içerik görevlerinde doğruluk artabilir. Model aynı hatalı varsayımı tekrar doğrulayabilir, bu nedenle bağımsız deterministic validation daha değerlidir. Her task'ta reflection kullanmak maliyet ve gecikmeyi artırır. Sadece eval sonucunda fayda gösteren alanlarda kullanılmalıdır.

Iterasyon Sınırı Neden Gereklidir?

Agent başarısız tool call sonrası sürekli tekrar deneyebilir. Bu durum maliyet artışı ve backend overload oluşturur. Maksimum step, tool call ve runtime sınırı loop'u keser. Limit aşıldığında kullanıcıya kontrollü failure veya insan eskalasyonu yapılır. Production sistemde hiçbir agent sınırsız çalışmamalıdır.

Tek Agent mı, Multi-Agent Sistem mi?

Multi agent architecture etkileyici görünse de çoğu şirketin ilk ihtiyacı değildir. Tek agent daha kolay test edilir, daha düşük latency ve maliyet üretir. Multi agent ancak görevler gerçekten bağımsız uzmanlıklara ayrılıyorsa anlamlı hale gelir. Her yeni agent ek prompt, state, handoff ve authorization problemi getirir. Bu nedenle tek agent sınırlarına ulaşıldığı ölçümlerle kanıtlanmadan multi agent'a geçilmemelidir.

Tek Agent Kullanmanın Avantajları

Tek agent architecture state flow'u daha basittir. Debug sırasında hangi modelin karar verdiği kolay anlaşılır. Tool permission tek yerde yönetilir. Token ve latency maliyeti daha düşüktür. İlk pilot ve production learning için güçlü başlangıçtır.

Multi-Agent Sistem Nedir?

Multi Agent System birden fazla uzman agent'ın aynı hedef için koordineli çalışmasıdır. Orchestrator task'ı researcher, analyst veya executor agent'lara dağıtabilir. Her agent farklı tool set ve prompt'a sahip olabilir. Bu yapı uzmanlaşma sağlar. Aynı zamanda handoff hatası ve toplam maliyet önemli ölçüde artar.

Multi-Agent Ne Zaman Gereklidir?

Task doğal olarak farklı uzmanlık ve permission alanlarına ayrılıyorsa multi agent değerlendirilebilir. Örneğin araştırma, finans analiz ve sözleşme review birbirinden bağımsız policy setlerine sahip olabilir. Tek prompt çok büyümüş ve tool selection performansı düşmüş olabilir. Yine de önce router ile ayrı workflow'lar denenmelidir. Multi agent architecture ölçülen problem çözülüyorsa kullanılmalıdır.

Orchestrator Agent

Orchestrator task'ı hangi specialist'in işleyeceğine karar verir. Kendi tool yetkisi mümkün olduğunca az olmalıdır. Asıl business action specialist veya workflow tarafından gerçekleştirilir. Orchestrator handoff context'i filtrelemelidir. Gereksiz hassas veri bütün agent'lara yayılmamalıdır.

Specialist Agents

Specialist Agent belirli domain ve tool set ile sınırlandırılır. Her specialist daha küçük prompt ve daha net görev tanımına sahip olur. Authorization domain bazında uygulanabilir. Bununla birlikte specialist sayısı arttıkça yönetim maliyeti artar. Agent registry ve owner bilgisi tutulmalıdır.

Araştırmacı

Araştırmacı agent bilgi toplama ve kaynak bulma görevine odaklanır. Genellikle read only tool kullanır. Dış web içeriği güvenilmeyen data olarak işlenmelidir. Kaynak ve tarih sonucu ile birlikte tutulmalıdır. Araştırmacıya write veya send permission verilmesi çoğu durumda gereksizdir.

Analist

Analist agent toplanan veriyi karşılaştırır ve insight üretir. Hesaplama gerektiğinde deterministic analytics tool kullanmalıdır. Kaynak veriyi değiştirme yetkisi olmayabilir. Varsayım ve veri ayrımı sonuçta açıkça gösterilmelidir. Belirsizlik yüksek olduğunda ek data isteyebilmelidir.

Uygulayıcı

Uygulayıcı agent gerçek write tool'lara sahip olabilir. Bu nedenle en dar permission bu role verilmelidir. Orchestrator'ın ürettiği instruction tekrar authorization kontrolünden geçmelidir. Kritik eylem approval gerektirmelidir. Audit özellikle executor agent üzerinde ayrıntılı tutulmalıdır.

Denetçi

Denetçi agent diğer çıktıları policy ve kalite kriterlerine göre kontrol edebilir. Mümkünse write yetkisine sahip olmamalıdır. Aynı model provider'ı kullanılması bağımsızlık seviyesini sınırlayabilir. Deterministic validator ile birlikte çalışması daha güçlüdür. Denetçinin başarısı false approval ve false rejection metric'leriyle ölçülmelidir.

Agent Handoff

Handoff sırasında task context bir specialist'ten diğerine geçer. Context içinde yalnızca gerekli bilgiler bulunmalıdır. User authorization yeniden hesaplanmalıdır. Önceki agent'ın assertion'ları doğrulanmamış veri olarak işaretlenebilir. Handoff sayısı maksimum limit ile kontrol edilmelidir.

Agent-to-Agent İletişimi

Agent to Agent mesajlaşması structured schema üzerinden yapılmalıdır. Serbest doğal dil instruction injection riskini artırabilir. Sender identity ve allowed task type doğrulanmalıdır. Her mesaj trace içinde saklanabilir. Cross agent secret paylaşımı varsayılan olarak kapalı tutulmalıdır.

Multi-Agent Sistemlerin Dezavantajları

Multi agent architecture daha yüksek model çağrısı, daha fazla state ve daha çok failure point oluşturur. Bir specialist'in yanlış sonucu diğerlerine yayılabilir. Handoff debug süresi uzar. Authorization matrisinin yönetimi zorlaşır. Bu maliyetler gerçek business fayda ile karşılanmıyorsa tek agent daha doğru seçimdir.

Yüksek Maliyet

Bir task birkaç agent arasında dolaştığında token kullanımı katlanabilir. Her specialist farklı context alır. Reflection veya evaluator eklenirse çağrı sayısı daha da artar. Görev başına toplam maliyet ölçülmelidir. Kullanıcı başına veya departman başına budget konulabilir.

Yüksek Gecikme

Sequential agent call'ları toplam response süresini artırır. Her handoff ayrıca retrieval veya tool çağrısı tetikleyebilir. Kullanıcı gerçek zamanlı cevap bekliyorsa deneyim kötüleşebilir. Parallel execution bazı görevlerde fayda sağlar. Critical path latency trace üzerinden analiz edilmelidir.

Debug Zorluğu

Hata hangi agent'ın yanlış varsayımından kaynaklandı sorusu her zaman kolay değildir. Trace bütün handoff ve tool call'ları göstermelidir. Model ve prompt version her event'e eklenmelidir. Reproduction için deterministic test fixtures kullanılabilir. Observability olmadan multi agent production yönetimi çok zorlaşır.

Kontrol Kaybı

Agent sayısı arttıkça karar yolu daha az öngörülebilir hale gelebilir. Orchestrator bütün transition'ları explicit policy ile sınırlandırmalıdır. Specialist kendi permission alanının dışına çıkamamalıdır. Handoff chain maksimum uzunluğa sahip olmalıdır. Kill switch tek agent yanında bütün workflow'u durdurabilmelidir.

Multi-Agent Kullanılmaması Gereken Durumlar

Tek agent görevi güvenilir biçimde çözebiliyorsa multi agent gereksizdir. Küçük trafik ve dar use case'te ek architecture yalnızca bakım maliyeti yaratır. Evals bile kurulmamış bir projede specialist sayısını artırmak hata analizini zorlaştırır. Business process zaten birkaç deterministik adımdan oluşuyorsa workflow yeterlidir. Multi agent teknoloji tercihi değil kanıtlanmış ihtiyaç sonucu olmalıdır.

AI Agent Geliştirmek İçin Hangi Araçlar Kullanılabilir?

Agent geliştirmek için SDK, graph framework, low code platform ve tamamen custom implementation seçenekleri vardır. Araç seçimi ekip yetkinliği, production beklentisi ve vendor bağımlılığına göre yapılmalıdır. Bir framework prototipi hızlandırabilir fakat güvenlik veya observability problemini otomatik çözmez. Tool calling, identity ve eval katmanının nasıl uygulandığı ayrıca incelenmelidir. İlk proof of concept sonrası framework'ün gerçek maintenance maliyeti değerlendirilmelidir.

OpenAI Agents SDK

OpenAI Agents SDK agent orchestration, tool usage ve agent handoff gibi kullanım alanları için geliştirici altyapısı sağlayabilir. Model provider ile yakın entegrasyon hızlı prototyping avantajı sunar. Production kullanımında authorization application katmanında ayrıca uygulanmalıdır. Framework'ün trace ve tool behavior özellikleri gerçek use case üzerinde test edilmelidir. SDK güncellemeleri ve dependency management normal software lifecycle içinde yönetilmelidir.

LangGraph

LangGraph stateful graph tabanlı agent workflow'ları tasarlamak için kullanılabilir. Explicit node ve transition yapısı kontrollü orchestration sağlar. Human approval ve durable state gibi pattern'ler graph içinde modellenebilir. Bununla birlikte gereksiz büyük graph maintenance maliyeti oluşturabilir. Basit use case'te küçük custom workflow daha anlaşılır olabilir.

CrewAI

CrewAI rol bazlı multi agent senaryolarını hızlı denemek için kullanılabilir. Specialist agent ve task tanımları kolay prototyping sağlar. Production security için tool permission ve identity entegrasyonu ayrıca tasarlanmalıdır. Multi agent maliyeti gerçek eval ile ölçülmelidir. Sadece framework kolay olduğu için gereksiz specialist mimarisi kurulması doğru değildir.

AutoGen

AutoGen agentlar arası etkileşim ve orchestration pattern'lerini deneyen projelerde kullanılabilir. Çoklu agent diyalogları araştırma ve prototyping için yararlı olabilir. Production environment'da loop, cost ve permission limitleri kesin biçimde uygulanmalıdır. Framework behavior version değişiklikleriyle test edilmelidir. Agent communication güvenilir authorization yerine geçmez.

Semantic Kernel

Semantic Kernel özellikle Microsoft ecosystem kullanan ekipler için agent ve AI orchestration seçenekleri sunabilir. Plugin ve function yaklaşımı kurumsal servislerle integration sağlayabilir. Identity ve enterprise development stack ile uyum avantajı olabilir. Gerçek model ve provider desteği proje zamanında doğrulanmalıdır. Framework yalnızca orchestration sağlar ve security policy ayrıca oluşturulmalıdır.

Claude Agent SDK

Claude Agent SDK belirli agentic geliştirme pattern'leri için kullanılabilir. Tool usage ve model behavior gerçek şirket use case'leriyle değerlendirilmelidir. Provider data policy security review kapsamına alınmalıdır. Framework seçimi yalnızca model kalitesine dayanmamalıdır. Observability, cost ve vendor dependency de birlikte değerlendirilmelidir.

n8n

n8n low code workflow ve integration geliştirmede hızlı sonuç sağlayabilir. API connector ve webhook bazlı süreçler business ekiplerine yakın biçimde kurulabilir. Kritik credential ve production permission'lar güvenli secret store ile yönetilmelidir. Çok büyük agent logic'i görsel workflow içinde debug edilmesi zor hale gelebilir. Basit orchestration ve approval süreçlerinde güçlü seçenek olabilir.

Microsoft Copilot Studio

Microsoft ecosystem kullanan kurumlar düşük kodla agent ve enterprise integration geliştirmek isteyebilir. Hazır identity ve connector seçenekleri deployment süresini azaltabilir. Lisans, data governance ve connector permission'ları birlikte incelenmelidir. Platform default'larının şirket security standardına uygun olduğu varsayılmamalıdır. Custom requirement arttıkça extension ve vendor dependency maliyeti değerlendirilmelidir.

Hazır Kurumsal Agent Platformları

Hazır platformlar hızlı deployment ve governance özellikleri sunabilir. Identity, connector ve monitoring tek ürün içinde sağlanabilir. Bunun karşılığında esneklik ve vendor dependency artabilir. Business critical workflow'a geçmeden önce data export ve exit plan incelenmelidir. Pilot sırasında gerçek cost per task ve permission modeli ölçülmelidir.

Framework Kullanmadan Custom Agent Geliştirmek

Basit agent için framework zorunlu değildir. Model API, tool registry, state store ve birkaç kontrollü workflow normal application koduyla yazılabilir. Bu yaklaşım dependency sayısını ve abstraction yükünü azaltır. Geliştirme ekibi orchestration sorumluluğunu kendisi üstlenir. Dar ve kritik use case'lerde custom implementation daha kolay audit edilebilir olabilir.

No-Code, Low-Code veya Custom Development?

Agent geliştirme yöntemi şirketin teknik kapasitesi ve use case riskine göre değişir. No code platform hızlı proof of concept için yararlıdır. Low code integration ve governance konusunda daha fazla kontrol sunabilir. Custom development hassas, yüksek performanslı veya özel authorization isteyen sistemlerde avantajlıdır. Build vs Buy kararı ilk demo hızından çok üç yıllık bakım ve bağımlılık maliyeti üzerinden değerlendirilmelidir.

No-Code Agent

No Code Agent teknik olmayan ekiplerin hızlı prototip geliştirmesini sağlar. Basit bilgi asistanı veya internal workflow için yeterli olabilir. Yetki ve audit seçenekleri platform sınırlarıyla belirlenir. Karmaşık business rule ve custom security ihtiyacında sınıra ulaşabilir. Production öncesi IT ve security review yapılmalıdır.

Low-Code Agent

Low Code yaklaşım görsel workflow ile custom code'u birleştirebilir. Connector geliştirme ve approval step daha esnek hale gelir. Teknik ekip kritik tool'ları kodla yazabilir. Business ekip workflow konfigürasyonunu yönetebilir. Governance olmadan çok sayıda kontrolsüz agent oluşabileceği için merkezi registry gerekir.

Custom Coded Agent

Custom agent maksimum kontrol sağlar. Identity, tool, state ve observability şirket standardına tam uyarlanabilir. Development ve maintenance sorumluluğu yüksektir. Yüksek riskli ve core business süreçlerinde bu esneklik değerli olabilir. Ekip test, deployment ve on call kapasitesine sahip olmalıdır.

Hangi Şirket İçin Hangisi Daha Uygun?

Küçük ekip ve basit workflow no code ile başlayabilir. Orta büyüklükte organization low code ile platform standardı oluşturabilir. Çok özel integration ve yüksek compliance gerektiren kurum custom development seçebilir. Tek şirket içinde farklı use case'ler farklı yöntem kullanabilir. Merkezi governance bütün yöntemleri aynı security standardında değerlendirmelidir.

Build vs Buy Kararı

Buy yaklaşımı time to market avantajı sağlar. Build yaklaşımı farklılaşmış workflow ve özel security kontrolü sunabilir. Lisans maliyeti tek karar kriteri değildir. Custom sistemin engineer zamanı ve on call maliyeti eklenmelidir. Vendor çıkış planı ve data portability karar belgesinde yer almalıdır.

AI Agent Geliştirmek İçin En İyi Programlama Dili

Agent geliştirmek için tek bir en iyi programlama dili yoktur. Python ve TypeScript geniş AI ecosystem nedeniyle sık tercih edilir. C# ve Java enterprise integration için güçlü seçeneklerdir. Asıl önemli konu language değil identity, tool security, state management ve evaluation architecture'dır. Ekip mevcut production stack'i iyi biliyorsa yeni dil öğrenmeden sağlam agent geliştirmek çoğu zaman daha doğru karardır.

Python

Python LLM SDK, data processing ve RAG ecosystem açısından geniş desteğe sahiptir. Hızlı prototyping avantajı sağlar. Data scientist ve backend developer aynı code base üzerinde çalışabilir. Async tool calling ve production web service architecture doğru tasarlanmalıdır. Type validation için schema library kullanımı faydalıdır.

TypeScript / JavaScript

TypeScript web ve backend ekiplerinin agent geliştirmeye hızlı geçmesini sağlar. Strong typing tool schema'larında fayda sunar. Node.js streaming ve API integration için uygundur. Frontend ve backend aynı dil kullanabilir. Runtime secret ve permission yönetimi normal production uygulama standardında uygulanmalıdır.

C#

C# Microsoft ecosystem ve enterprise backend ortamlarında güçlüdür. Existing identity, logging ve dependency injection altyapısına agent kolay entegre edilebilir. Kurum .NET kullanıyorsa farklı stack açmaya gerek kalmayabilir. SDK support gerçek model provider'a göre değerlendirilmelidir. Production observability mevcut APM sistemiyle birleştirilebilir.

Java

Java büyük enterprise sistemlerde yaygın olduğundan agent layer mevcut backend servislerine yakın konumlandırılabilir. Strong typing ve mature security framework avantaj sağlar. Model çağrıları external service olarak ele alınabilir. Connection ve thread yönetimi yüksek concurrency altında test edilmelidir. Mevcut IAM ve audit standardı yeniden kullanılabilir.

Dil Seçerken Dikkat Edilecek Kriterler

Ekip deneyimi en önemli kriterlerden biridir. SDK ve framework desteği, async I/O, observability ve deployment tooling değerlendirilmelidir. Language benchmark tek başına karar vermemelidir. Uzun vadeli bakım ekibin mevcut skill set'iyle uyumlu olmalıdır. Kritik agent platformu yalnızca tek kişinin bildiği teknolojiye bağlı olmamalıdır.

En İyi Programlama Dilinden Daha Önemli Olan Mimari Kararlar

Yanlış authorization modelini daha hızlı dil çözmez. Tool validation, RAG permission, memory isolation ve human approval daha temel kararlardır. Model change ve prompt versioning architecture içinde desteklenmelidir. Evaluation pipeline olmadan herhangi bir dilde güvenilir gelişim zordur. İlk olarak doğru system boundary tasarlanmalı, sonra implementation teknolojisi seçilmelidir.

Şirket İçi İlk AI Agent Nasıl Oluşturulur?

İlk kurumsal agent projesi küçük ama gerçek business problem üzerine kurulmalıdır. Şirket içi yapay zeka ajanı nasıl oluşturulur sorusunun cevabı model seçimiyle değil süreç analiziyle başlar. Yetki sınırı, başarı metriği ve test dataset'i ilk haftada tanımlanmalıdır. Pilot read only veya düşük riskli write işlemleriyle çalışabilir. Production'a geçiş ancak gerçek kullanıcı testleri ve güvenlik kontrolleri tamamlandıktan sonra yapılmalıdır.

1. İş Problemini Tanımlayın

“AI Agent yapmak istiyoruz” business problem değildir. Hangi çalışanın hangi işi ne kadar sürede yaptığı açık biçimde yazılmalıdır. Mevcut hata oranı ve gecikme ölçülmelidir. Agent'ın çözmesi beklenen bölüm net sınırla tanımlanmalıdır. Scope dışı işlemler de dokümana eklenmelidir.

2. Başarı Metriklerini Belirleyin

Pilot öncesi success criteria belirlenmelidir. Task completion, time saved, error rate ve user satisfaction örnek metric'lerdir. Maliyet de aynı dashboard içinde bulunmalıdır. Sadece “kullanıcılar beğendi” sonucu scaling için yeterli değildir. Hedef değerler business owner ile birlikte belirlenmelidir.

3. Sürecin Mevcut Halini Haritalayın

İnsan çalışan mevcut task'ı hangi adımlarla tamamlıyor gözlemlenmelidir. Kullanılan bütün system ve approval noktaları çıkarılmalıdır. Gizli manual workaround'lar genellikle burada ortaya çıkar. Gereksiz adımlar agent'a kopyalanmamalıdır. Önce süreç sadeleştirilmeli, sonra otomasyon tasarlanmalıdır.

4. Agent'ın Yetki Sınırını Belirleyin

Agent hangi veriyi okuyabilir ve hangi işlemi yapabilir açıkça yazılmalıdır. İlk pilotta read only tercih edilebilir. Write gerekiyorsa yalnızca belirli resource ve action ile sınırlandırılmalıdır. Destructive tool varsayılan olarak kapatılmalıdır. Yetki prompt değil backend authorization ile enforce edilmelidir.

5. Modeli Seçin

Gerçek task örnekleri birkaç model üzerinde test edilmelidir. Tool calling ve Türkçe accuracy ölçülmelidir. Latency ve cost aynı karşılaştırmada bulunmalıdır. Hassas veri policy uyumu kontrol edilmelidir. Pilot için en güçlü değil yeterli ve sürdürülebilir model seçilmelidir.

6. Gerekli Araçları Tanımlayın

Süreci tamamlamak için gereken minimum tool listesi çıkarılmalıdır. Gereksiz tool agent context'ine eklenmemelidir. Read ve write ayrılmalıdır. Parametre schema ve validation kuralları tanımlanmalıdır. Her tool ayrı integration test'e sahip olmalıdır.

7. Şirket Verisini Bağlayın

Doküman gerekiyorsa RAG pipeline hazırlanır. Güncel transactional veri API üzerinden alınabilir. Permission metadata connector'dan itibaren korunmalıdır. Old document ve duplicate temizliği yapılmalıdır. Retrieval kalitesi golden dataset üzerinde ölçülmelidir.

8. System Prompt'u Oluşturun

Agent rolü, amacı ve scope'u açık yazılmalıdır. Yasak işlem ve escalation kuralları belirtilmelidir. Prompt business policy'nin tek uygulama yeri olmamalıdır. Version control altında tutulmalıdır. Her değişiklik regression eval ile test edilmelidir.

9. İnsan Onay Noktalarını Ekleyin

Kritik write işlemler belirlenmelidir. Approval öncesi kullanıcı exact action ve parametreleri görmelidir. Onay yalnızca o transaction için geçerli olmalıdır. Risk seviyesi arttıkça ikinci approval veya step up authentication kullanılabilir. Approval event audit log'a yazılmalıdır.

10. Test Dataset'i Oluşturun

Gerçek geçmiş örneklerden representative task set hazırlanmalıdır. Normal, edge ve adversarial senaryolar birlikte bulunmalıdır. Expected output veya allowed behavior tanımlanmalıdır. Dataset version control altında tutulmalıdır. Production incident örnekleri gelecekte regression setine eklenmelidir.

11. Pilot Kullanıcılarla Test Edin

Pilot kullanıcılar gerçek iş akışında agent'ı denemelidir. Sadece teknik ekip demo verisi kullanmamalıdır. Feedback kategori ve severity ile kaydedilmelidir. Human correction oranı ölçülmelidir. Kullanıcı agent'ın sınırlarını ve hata ihtimalini bilmelidir.

12. Production'a Alın

Production rollout küçük kullanıcı grubuyla başlayabilir. Rate ve budget limit uygulanmalıdır. Monitoring ve kill switch aktif olmadan deployment yapılmamalıdır. Access policy security review'dan geçmelidir. On call owner ve incident runbook hazır olmalıdır.

13. İzleyin ve İyileştirin

Agent deployment sonrası bitmiş ürün değildir. Task success, cost ve security event'leri sürekli izlenmelidir. Model ve prompt drift regression eval ile kontrol edilir. User feedback yeni test case'e dönüştürülmelidir. Otonomi ancak ölçülen kalite arttıkça kademeli olarak genişletilmelidir.

AI Agent System Prompt'u Nasıl Yazılır?

System Prompt agent'ın davranışını yönlendirir ancak authorization mekanizması değildir. İyi prompt rol, amaç, scope, tool kullanım şartı ve escalation politikasını açık biçimde tanımlar. Gereksiz uzun prompt modelin kritik talimatları kaçırmasına neden olabilir. Business rule mümkünse code ve policy engine içinde uygulanmalıdır. Prompt version'ı model version ile birlikte trace'e eklenmelidir.

Rol

Rol agent'ın kim adına hangi fonksiyonu yerine getirdiğini tanımlar. “Sen yardımcı bir asistansın” yerine “satış operasyon ekibine lead araştırması yapan read only asistansın” daha nettir. Role göre tool set sınırlandırılmalıdır. Role kullanıcı tarafından değiştirilememelidir. Aynı application içinde farklı role'lar ayrı agent configuration olabilir.

Amaç

Amaç agent'ın optimize edeceği business sonucu belirtir. Örneğin “ticket'ı doğru kategoriye yönlendir ve yeterli kaynak yoksa insan ekibe eskale et” açık hedef sağlar. Amaç kalite ile güvenlik arasında denge içermelidir. Sadece “görevi ne olursa olsun tamamla” tehlikeli objective olabilir. Başarısızlık kabul edilebilir bir sonuç olarak tanımlanmalıdır.

Görev Kapsamı

Scope agent'ın yapabileceği görevleri sınırlar. Scope dışı isteklerde agent işlem yapmamalıdır. Kullanıcı başka departman görevi verdiğinde uygun yönlendirme yapılabilir. Tool allowlist aynı scope ile uyumlu olmalıdır. Scope değişikliği ayrı release olarak değerlendirilmelidir.

İzin Verilen Araçlar

Prompt tool'ların ne amaçla kullanılacağını açıklayabilir. Gerçek tool erişimi platform configuration tarafından belirlenmelidir. Agent tool görünmüyorsa kullanamaz. Tool description açık input ve expected output belirtmelidir. Risk seviyesi de metadata olarak orchestrator tarafından kullanılabilir.

Yasaklanan İşlemler

Agent'ın yapmaması gereken işlemler açıkça listelenebilir. Örneğin müşteri kaydı silme, ödeme başlatma veya permission değiştirme yasak olabilir. Bu yasaklar backend'de de enforce edilmelidir. Prompt injection yasak işlemi açamamalıdır. Security test bu boundary'leri özellikle denemelidir.

İnsan Onayı Gerektiren Durumlar

Hangi tool ve koşulda approval gerektiği belirtilmelidir. Amount threshold gibi kesin kurallar code içinde uygulanmalıdır. Model kullanıcıya approval mesajı hazırlayabilir. Approval olmadan tool endpoint erişimi kapalı olmalıdır. Onay sonucu state machine içinde kaydedilmelidir.

Belirsizlik Politikası

Agent yeterli bilgi yoksa bunu açıkça söylemelidir. Tahmin ederek business action yapmamalıdır. Belirsizlik threshold'u task type'a göre değişebilir. RAG kaynağı bulunamazsa insan eskalasyonu yapılabilir. “Bilmiyorum” güvenilir sistemde başarısızlık değil doğru davranış olabilir.

Hata Yönetimi

Tool error sonrası agent'ın hangi durumda retry yapacağı tanımlanmalıdır. Permission denied hata tekrar denenmemelidir. Temporary network failure sınırlı retry alabilir. Hata kullanıcıya secret veya internal stack trace göstermemelidir. Kritik failure incident event'i oluşturabilir.

Çıktı Formatı

Structured output downstream validation için önemlidir. JSON schema veya belirli alanlar kullanılabilir. Kullanıcıya gösterilen doğal dil ile internal machine output ayrılabilir. Field değerleri server tarafında validate edilmelidir. Model formatı bozarsa otomatik repair yerine kontrollü retry uygulanabilir.

Eskalasyon Kuralları

Agent hangi durumda insana veya başka workflow'a devredeceğini bilmelidir. Confidence düşük, tool unavailable veya policy conflict örnek durumlardır. Eskalasyon mesajı kısa task özeti ve kullanılan kaynakları içerebilir. Kullanıcı yeniden bütün süreci açıklamamalıdır. Escalation rate kalite metriği olarak izlenebilir.

Şirket İçi AI Agent Yetkilendirmesi Nasıl Yapılmalı?

Yetkilendirme kurumsal ajan güvenliğinin merkezindedir. Agent'ın yaptığı her tool call gerçek kullanıcı veya workload identity ile ilişkilendirilmelidir. Model permission kararı vermemelidir. Read, write ve destructive capability ayrı role'lara bölünmelidir. En güvenli başlangıç agent'ın kullanıcıdan daha fazla yetkiye sahip olmamasıdır.

Least Privilege İlkesi

Agent yalnızca görevi için gereken minimum permission'ı almalıdır. CRM read agent'ına delete yetkisi verilmez. SQL agent yalnızca gerekli view'ları okuyabilir. Permission zaman içinde düzenli review edilmelidir. Kullanılmayan tool ve scope kaldırılmalıdır.

Role-Based Access Control

RBAC kullanıcı ve agent rollerini permission set ile eşleştirir. Satış rolü yalnızca kendi account verisini görebilir. Finance agent farklı tool set kullanabilir. Role inheritance dikkatli tasarlanmalıdır. Çok geniş shared role'lar blast radius'u büyütür.

Kullanıcı Kimliği ile Agent Yetkisinin Ayrılması

Agent service account sahibi olabilir fakat kullanıcı adına işlem yaparken delegated identity bilgisi kaybolmamalıdır. Backend hem agent application'ı hem end user'ı doğrulayabilir. Kullanıcı yetkisi tool query'sine uygulanmalıdır. Bu sayede service account'un geniş teknik yetkisi kullanıcıya otomatik aktarılmaz. Audit gerçek principal bilgisini korur.

SSO Entegrasyonu

SSO kullanıcı identity'sini merkezi ve güvenilir biçimde sağlar. Group veya role claim'leri authorization için kullanılabilir. Agent ayrı password sistemi kurmak zorunda kalmaz. Session ve token expiry normal enterprise policy'ye uyar. High risk action step up MFA isteyebilir.

Service Accounts

Service account machine identity için kullanılır. Long lived password yerine short lived token veya workload identity tercih edilmelidir. Her agent ayrı account kullanabilir. Shared admin account audit kalitesini düşürür. Credential rotation ve secret management merkezi platformla yapılmalıdır.

Geçici Yetkilendirme

Temporary permission belirli task veya süre boyunca ek yetki verir. Satın alma agent'ı sadece onaylanmış transaction için write token alabilir. Token task ID ve resource scope'a bağlanabilir. Süre sonunda otomatik expire olur. Bu yaklaşım standing privilege riskini azaltır.

Read ve Write Yetkilerini Ayırmak

Read tool çok sayıda kullanıcının güvenle kullanabileceği şekilde tasarlanabilir. Write ayrı permission ve approval isteyebilir. Agent bir bilgiyi görebiliyor diye onu değiştirebilmemelidir. Service layer bu ayrımı API scope ile enforce etmelidir. Monitoring read ve write event'lerini farklı risk seviyesinde ele almalıdır.

Kritik İşlemlerde İnsan Onayı

Kritik action öncesi human approval güçlü güvenlik sınırı oluşturur. Kullanıcı neyin değişeceğini açık biçimde görmelidir. Onay token'ı exact action'a bağlı olmalıdır. Timeout sonrası approval geçerliliğini kaybetmelidir. Agent approval metnini değiştirememeli veya atlayamamalıdır.

Şirket İçi Yapay Zeka Ajanlarının Güvenlik Riskleri

AI Agent güvenliği klasik uygulama güvenliğine yeni riskler ekler. Prompt injection, excessive agency, tool abuse, memory poisoning ve malicious MCP server bunlardan bazılarıdır. En önemli fark modelin güvenilmeyen içeriği instruction gibi yorumlayabilmesidir. Bu nedenle data ve instruction katmanı teknik olarak ayrılmalıdır. Agent hiçbir zaman bütün sistemlere geniş admin access ile bağlanmamalıdır.

Prompt Injection

Prompt Injection modelin güvenilmeyen input içindeki komutu takip etmeye yönlendirilmesidir. Kullanıcı mesajı veya retrieved doküman saldırı taşıyabilir. Modelin talimatı görmesi engellenemese bile etkisi sınırlandırılabilir. Tool permission, output validation ve approval bunun için gereklidir. Prompt savunması tek bir filtreyle çözülemez.

Direct Prompt Injection

Direct Prompt Injection kullanıcı mesajında doğrudan “önceki kuralları unut” gibi talimat verilmesidir. Model bu mesajı işlemek zorundadır. Ancak backend permission kullanıcı mesajından bağımsızdır. Agent yasak tool'u teknik olarak görememelidir. Security testing bu tür bypass denemelerini düzenli olarak içermelidir.

Indirect Prompt Injection

Indirect Prompt Injection ajan tarafından okunan dış doküman veya web sayfasında kötü niyetli instruction bulunmasıdır. Agent bu metni data yerine talimat sanabilir. Retrieved content açık data boundary içinde modele verilmelidir. Tool use dış içerik talimatıyla genişlememelidir. Dış kaynak okuyan ajanların write yetkileri daha dikkatli sınırlandırılmalıdır.

Tool Abuse

Tool Abuse izin verilen fonksiyonun beklenmeyen amaçla kullanılmasıdır. Search tool ile toplu veri exfiltration yapılabilir. Limit, scope ve rate control gerekir. Tool input model tarafından üretildi diye güvenilir kabul edilmez. Backend business policy her çağrıda doğrulanmalıdır.

Excessive Agency

Excessive Agency agent'a task için gereğinden fazla otonomi verilmesidir. Bir taslak hazırlaması gereken agent'ın doğrudan e-posta göndermesi gereksiz risk olabilir. Otonomi ölçülen kaliteye göre kademeli artırılmalıdır. Human approval özellikle dış dünyaya etkisi olan işlemlerde korunmalıdır. En yüksek automation seviyesi hedef olmak zorunda değildir.

Yetki Yükseltme

Agent farklı tool veya identity aracılığıyla başlangıç permission'ından daha yüksek yetki elde etmeye çalışabilir. Tool chaining bu riski artırabilir. Service account permission minimum tutulmalıdır. Delegation chain server tarafında doğrulanmalıdır. Permission değiştiren tool'lar agent allowlist'inden çıkarılmalıdır.

Veri Sızıntısı

Agent başka kullanıcıya ait bilgiyi yanlış context veya retrieval nedeniyle gösterebilir. Tenant isolation ve permission filter bu riski azaltır. Prompt ve response logları da veri sızıntısı kaynağı olabilir. Sensitive field masking uygulanmalıdır. Cross user memory access security testlerinin temel senaryolarından biri olmalıdır.

Secret Leakage

API key ve token model context'ine verilmemelidir. Tool backend secret'ı kendi içinde kullanmalı ve modele yalnızca sonuç dönmelidir. Log ve error message secret içermemelidir. AI coding agent developer environment'taki secret dosyalarına erişmemelidir. Secret scanning agent output ve generated code üzerinde de çalıştırılabilir.

Memory Poisoning

Memory Poisoning saldırganın kalıcı hafızaya yanlış veya zararlı bilgi yazdırmasıdır. Sonraki session'lar bu bilgiyi güvenilir context gibi kullanabilir. Memory write explicit policy ile sınırlandırılmalıdır. User supplied statement otomatik kalıcı gerçek olarak saklanmamalıdır. Memory item source ve confidence metadata taşıyabilir.

Tool Poisoning

Tool description veya output içine kötü niyetli instruction eklenmesi agent davranışını etkileyebilir. Third party tool metadata güvenilmeyen input olarak değerlendirilmelidir. Tool registry yalnızca security review'dan geçen integration'ları yayınlamalıdır. Runtime tool discovery sınırsız olmamalıdır. Version değişiklikleri approval ve regression test gerektirebilir.

Zararlı MCP Server

Malicious MCP Server sahte tool veya yanıltıcı context sağlayabilir. Agent data exfiltration veya yanlış write operation yapmaya yönlendirilebilir. Public server'lar otomatik trust edilmemelidir. Network allowlist ve signed deployment artefact kullanılabilir. Organization approved MCP registry oluşturmak governance açısından faydalıdır.

Halüsinasyon

Model olmayan bilgi üretebilir veya tool sonucunu yanlış yorumlayabilir. RAG ve validation bu riski azaltır ama tamamen ortadan kaldırmaz. High impact kararlar deterministic source ve human review ile doğrulanmalıdır. Factual accuracy düzenli eval metric olmalıdır. Yeterli kaynak yoksa agent açıkça bunu söylemelidir.

Agent Loop

Agent aynı tool'u tekrar tekrar çağırabilir. Bu durum maliyet ve external API load üretir. Maximum steps ve runtime limiti zorunludur. Repeated identical call detection circuit breaker olarak kullanılabilir. Loop sonlandığında run failure olarak raporlanmalıdır.

Supply Chain Riskleri

Agent framework, MCP server, plugin ve SDK bağımlılıkları supply chain riski taşır. Dependency version pinning ve vulnerability scanning uygulanmalıdır. Random community plugin production'a alınmamalıdır. Build pipeline artefact integrity kontrolü yapmalıdır. Security update süreci agent platform owner tarafından takip edilmelidir.

Multi-Agent Güvenlik Riskleri

Multi agent sistemde bir agent'ın compromise olması diğerlerine zararlı context aktarabilir. Handoff mesajı güvenilir instruction olarak kabul edilmemelidir. Her specialist kendi permission boundary'sine sahip olmalıdır. Shared memory en az yetkiyle kullanılmalıdır. Agent to Agent identity ve audit ayrı security layer gerektirir.

Prompt Injection'a Karşı AI Agent Nasıl Korunur?

Prompt injection'a karşı tek bir “güçlü prompt” yeterli değildir. Savunma model dışında architecture katmanına taşınmalıdır. Dış içerik güvenilmeyen data olarak işaretlenmeli, tool allowlist uygulanmalı ve kritik işlemler approval gerektirmelidir. Output ve input validation birlikte kullanılmalıdır. Agent breach olsa bile yapabileceği işlem minimum olacak şekilde blast radius daraltılmalıdır.

Dış Veriyi Güvenilmeyen Veri Olarak Kabul Etmek

Web sayfası, e-posta, PDF ve retrieved doküman instruction içeriyor olabilir. Agent bu içeriği data olarak kullanmalı fakat sistem politikasını değiştirmemelidir. Retrieval content delimiters ile ayrılabilir. Tool authorization external content'ten bağımsızdır. Security test gerçek malicious document örnekleriyle yapılmalıdır.

Instructions ve Data Ayrımı

System instruction, user request ve external data farklı message veya schema alanlarında tutulmalıdır. Data içindeki “şu tool'u çağır” ifadesi instruction olarak uygulanmamalıdır. Model yine hata yapabilir. Bu nedenle backend policy kesin sınırı oluşturur. Tool call request context source'a göre risk kontrolünden geçebilir.

Input Validation

Tool parametreleri strict input validation kullanmalıdır. URL, ID ve enum alanları allowlist veya format kontrolünden geçmelidir. Modelin arbitrary path veya SQL göndermesi engellenmelidir. Oversized payload reddedilmelidir. Validation error modelin kendisi tarafından override edilememelidir.

Output Validation

Model output'u downstream system'e gönderilmeden önce schema ve content açısından kontrol edilmelidir. Finansal tutar limitleri deterministic rule ile doğrulanabilir. Customer message toxic veya policy dışı content için filtrelenebilir. Generated SQL parser üzerinden kontrol edilebilir. Validation başarısızsa insan review veya safe fallback kullanılmalıdır.

Tool Allowlist

Agent sadece görevi için gereken tool'ları görmelidir. Global tool registry bütün tool'ları her agent'a sunmamalıdır. Role ve environment bazlı allowlist oluşturulabilir. Production write tool development agent'ına görünmemelidir. Tool list değişikliği security review gerektirebilir.

Domain Allowlist

Web veya HTTP tool sadece onaylı domain'lere erişebilir. Arbitrary URL server side request forgery riskini artırır. Redirect target da allowlist kontrolünden geçmelidir. Internal metadata endpoint'leri tamamen block edilmelidir. Dynamic domain ihtiyacı varsa approval veya proxy policy kullanılabilir.

Read-Only Mod

İlk deployment read only modda çalışabilir. Agent gerçek süreç ve veri üzerinde test edilir ama system state değiştirmez. Shadow mode kullanıcı kararlarıyla karşılaştırma imkânı verir. Başarı yeterli hale geldiğinde sınırlı write açılabilir. Bu geçiş risk yönetimini ciddi biçimde kolaylaştırır.

İnsan Onayı

Prompt injection modelin write tool kullanmasını tetiklese bile approval bariyeri işlemi durdurabilir. Kullanıcı onay ekranında dış data kaynaklı instruction görünür hale getirilebilir. Approval request hangi tool ve parametreyi içerdiğini açıkça göstermelidir. Kullanıcı yanlış veya beklenmeyen action'ı reddedebilir. Approval güvenlik katmanlarından biridir ancak read data leakage riskini tek başına çözmez.

Sandbox

Kod çalıştıran veya dosya işleyen agent sandbox içinde izole edilmelidir. Network ve filesystem erişimi minimum tutulmalıdır. Execution CPU, memory ve süre limitiyle sınırlandırılmalıdır. Production secret sandbox'a mount edilmemelidir. Output normal application katmanına geçmeden önce validate edilmelidir.

Adversarial Testing

Security test yalnızca normal kullanıcı senaryolarını içermemelidir. Direct injection, malicious document, oversized tool argument ve permission bypass denenmelidir. Başarılı saldırı örnekleri regression dataset'e eklenmelidir. Red team exercise production öncesi ve büyük değişiklikler sonrasında tekrarlanabilir. Test sonucu fix owner ve deadline ile takip edilmelidir.

Agent'ın Yetkisini Nasıl Sınırlandırırız?

Agent yetkisi yalnızca hangi tool'a eriştiğiyle sınırlı değildir. Maksimum adım, token, maliyet, çalışma süresi ve işlem tutarı da güvenlik sınırlarıdır. Bu limitler model prompt'unda değil orchestrator veya backend seviyesinde enforce edilmelidir. Limit aşılırsa agent güvenli biçimde durmalıdır. Kurumsal sistemde hiçbir agent açık uçlu resource tüketimi veya sınırsız action hakkına sahip olmamalıdır.

Maksimum Adım Sayısı

Agent run için step limit belirlenmelidir. Basit task beş adımda çözülebiliyorsa elli adım izin vermek gereksizdir. Limit task type'a göre değişebilir. Aşıldığında controlled failure oluşur. Bu metric loop problemini tespit etmek için izlenebilir.

Maksimum Token Bütçesi

Her run için token budget belirlemek maliyet kontrolü sağlar. Context büyüdükçe summary veya retrieval compression uygulanabilir. Budget aşılmadan agent kullanıcıya kısmi sonuç sunabilir. Multi agent chain ortak global budget paylaşmalıdır. Kullanıcı bazlı abuse limitleri de eklenebilir.

Maksimum Maliyet

Task başına maksimum para maliyeti hesaplanabilir. Model ve tool kullanım bedeli aynı budget içinde izlenir. Limit yaklaşınca daha küçük model veya safe fallback kullanılabilir. Yüksek maliyetli task kullanıcı approval isteyebilir. Cost anomaly security ve operasyon alarmı olarak değerlendirilebilir.

Maksimum Çalışma Süresi

Run sonsuza kadar açık kalmamalıdır. Overall deadline bütün model ve tool çağrılarını kapsamalıdır. Timeout sonrası background write devam etmemelidir. Long running workflow durable state ile kontrollü biçimde yeniden başlatılabilir. User experience için progress state gösterilebilir.

Maksimum Tool Çağrısı

Tool call sayısı task type'a göre sınırlandırılmalıdır. Aynı tool'a tekrar eden call anomaly olarak işaretlenebilir. External API rate limit korunur. Tool count cost calculation'a dahil edilir. Limit aşıldığında escalation veya failure kullanılır.

İşlem Tutarı Limiti

Finans veya satın alma agent'ında amount limit kritik boundary'dir. Belirli tutara kadar taslak oluşturabilir, üstünde approval isteyebilir. Model tutarı bölerek limiti aşmaya çalışmamalıdır. Backend günlük ve transaction bazlı limit uygular. Approval history audit edilir.

Domain ve API Limitleri

Agent sadece onaylı API ve domain'lere erişebilmelidir. HTTP proxy policy uygulanabilir. API method ve endpoint allowlist ayrı tanımlanabilir. GET access olması POST erişimi olduğu anlamına gelmemelidir. Environment bazlı network policy production ve test servislerini ayırmalıdır.

Kill Switch

Kill Switch güvenlik veya quality incident sırasında agent'ı anında durdurur. Merkezi configuration ile bütün write tool'lar kapatılabilir. Model provider erişimi de geçici olarak kesilebilir. Operasyon ekibi switch'in nerede olduğunu ve nasıl kullanılacağını bilmelidir. Tatbikatla düzenli test edilmelidir.

Circuit Breaker

Circuit Breaker aynı hata tekrarlandığında tool veya workflow'u geçici durdurur. Backend'i sürekli hatalı request'ten korur. Failure threshold ve cooldown süresi tanımlanır. Human operator manuel reset yapabilir. Metric ve alarm ile birlikte kullanıldığında production resilience artar.

Human-in-the-Loop Nasıl Tasarlanır?

Human in the Loop ajan ile insanın sorumluluk sınırını netleştirir. Her küçük işlemde approval istemek automation faydasını azaltır. Hiç approval istememek ise yüksek riskli süreçlerde uygun değildir. Risk bazlı model düşük etkili işlemleri otomatik, yüksek etkili olanları kontrollü hale getirir. İnsan kararı gelecekte evaluation ve policy iyileştirmesi için feedback olarak kullanılabilir.

İnsan Onayı Gerektirmeyen İşlemler

Read only arama ve taslak oluşturma çoğu durumda otomatik çalışabilir. Kullanıcıya şirket politikası bulmak veya ticket kategorisi önermek düşük riskli örnektir. Yine de veri erişim yetkisi korunmalıdır. Agent kesin business commitment vermemelidir. Automation level task riskine göre belirlenmelidir.

İnsan Onayı Gerektiren İşlemler

Dış dünyaya mesaj gönderen, para hareketi yapan veya veri silen işlemler approval gerektirebilir. Onay ekranı action ve parametreleri açık biçimde göstermelidir. Kullanıcı neyi onayladığını anlamalıdır. Approval ayrı identity event'i olarak loglanmalıdır. Risk arttıkça ikinci onay seviyesi uygulanabilir.

E-posta Gönderme

Agent e-posta taslağı hazırlayabilir. Gönderme tool'u ayrı tutulmalıdır. Alıcı, konu ve içerik kullanıcıya gösterilmelidir. External recipient ise ek uyarı verilebilir. Bulk send kesin limitlerle sınırlandırılmalıdır.

Veri Silme

Delete işlem geri alınması zor olabilir. Soft delete mümkünse tercih edilmelidir. Agent silinecek resource ID'yi approval ekranında göstermelidir. Bulk deletion ayrı permission gerektirmelidir. Recovery window incident etkisini azaltabilir.

Finansal İşlem

Para transferi veya ödeme işlemi yüksek riskli kategoridir. Agent yalnızca taslak transaction hazırlayabilir. Amount ve beneficiary deterministic rule ile doğrulanmalıdır. MFA veya ikinci approver gerekebilir. Transaction sonucu bankacılık veya ERP ID ile audit edilmelidir.

Sözleşme Onayı

Agent sözleşme risklerini özetleyebilir. Nihai kabul hukuk veya yetkili yöneticiye ait olmalıdır. Approved template dışında değişiklik varsa ek review gerektirilebilir. Signature tool agent'ın default permission'ında bulunmamalıdır. Approval policy contract amount ve risk class'a göre değişebilir.

Müşteriye Taahhüt Verme

Fiyat, SLA veya teslim tarihi müşteriye verilen business commitment'tır. Agent bu bilgiyi approved source'tan çekebilir. Yine de yetkili kullanıcı onayı gerekebilir. Model kendi tahminiyle taahhüt oluşturmamalıdır. Gönderilen mesaj ve dayandığı source audit için saklanabilir.

Risk Bazlı Approval

Her tool aynı riskte değildir. Read operation otomatik, küçük write tek approval, yüksek değerli işlem iki approval isteyebilir. Risk score action type, amount ve data sensitivity ile hesaplanabilir. Policy deterministic service içinde uygulanmalıdır. Model risk seviyesini düşüremez.

Agent'ın İnsana Eskalasyon Yapması

Agent confidence düşük veya policy conflict varsa görevi insana devretmelidir. Eskalasyon failure gibi değerlendirilmemelidir. Sistem kaliteli handoff özeti üretmelidir. İnsan hangi tool sonuçlarının kullanıldığını görebilmelidir. Escalation rate zaman içinde optimize edilebilir.

İnsan Kararının Agent'a Geri Bildirim Olarak Dönmesi

Human approval veya correction değerli evaluation verisidir. Yanlış agent önerileri kategorize edilerek golden dataset'e eklenebilir. Her correction otomatik prompt training verisi yapılmamalıdır. Privacy ve data quality kontrolü gerekir. Düzenli analysis en fazla hatanın hangi pattern'de olduğunu gösterir.

KVKK ve Kurumsal Veri Yönetişimi

AI Agent şirket içinde çok sayıda veri kaynağını bir araya getirebildiği için veri yönetişimi daha önemli hale gelir. Agent'ın eriştiği veri business ihtiyacıyla sınırlı olmalıdır. Kişisel ve hassas veriler classification policy'ye göre maskelenebilir. Model provider, data location ve retention koşulları hukuk ile security ekiplerinin ortak incelemesine girmelidir. Audit log kullanıcının hangi veriye hangi amaçla eriştiğini gösterebilmelidir.

Agent Hangi Verilere Erişebilir?

Agent bütün şirket datasını görmemelidir. Use case için gereken source listesi açık biçimde tanımlanmalıdır. Kullanıcı permission'ı retrieval ve tool query'ye uygulanmalıdır. Admin debugging access ayrıca kontrol edilmelidir. Data access inventory agent registry içinde tutulabilir.

Veri Minimizasyonu

Task için gerekli olmayan field modele gönderilmemelidir. Örneğin müşteri segment analizi için kimlik numarası gerekmeyebilir. API response server tarafında filtrelenebilir. Minimum context token maliyetini de azaltır. Data minimization security ve cost açısından aynı anda fayda sağlar.

Kişisel Veri Maskeleme

PII modellerden önce tokenization veya masking ile azaltılabilir. Her task'ta masking mümkün olmayabilir. Reversible mapping güvenli ayrı service içinde tutulabilir. Loglarda da aynı masking policy uygulanmalıdır. Masking doğruluğu test edilmelidir.

Hassas Veri Sınıflandırması

Public, internal, confidential ve restricted gibi data class tanımlanabilir. Her model provider hangi class'a erişebilir policy ile belirlenir. Restricted veri yalnızca özel inference ortamına yönlendirilebilir. Tool output classification taşıyabilir. Routing yanlış data exposure oluşturmayacak şekilde test edilmelidir.

Veri Saklama Süresi

Prompt, response, trace ve memory için ayrı retention süresi olabilir. Debug için her şeyi sonsuza kadar saklamak doğru değildir. Compliance ihtiyacı minimum required retention ile dengelenmelidir. Expired log otomatik silinmelidir. Backup retention de aynı policy'ye dahil edilmelidir.

Silme ve Unutulma Süreci

Kullanıcı verisi silindiğinde memory, vector index ve analytics kopyaları da değerlendirilmelidir. Primary database deletion tek başına yeterli olmayabilir. Deletion workflow data lineage bilgisine dayanmalıdır. İşlem audit edilebilir olmalıdır. Hukuki talepler için SLA tanımlanabilir.

Üçüncü Taraf Model Sağlayıcıları

Provider hangi veriyi ne kadar süre tuttuğunu açıkça belirtmelidir. Training kullanım politikası incelenmelidir. Enterprise sözleşme ve güvenlik sertifikaları değerlendirilmelidir. Subprocessor listesi data governance kapsamına girebilir. Provider değişikliği architecture içinde mümkünse düşük maliyetli olmalıdır.

Veri Lokasyonu

Veri hangi region veya ülkede işlendiği bazı kurumlar için önemlidir. Model endpoint deployment location buna göre seçilebilir. Log ve vector database de aynı incelemeye dahil edilmelidir. Cross border transfer gereksinimleri hukuk uzmanlarıyla değerlendirilmelidir. Architecture kararları dokümante edilmelidir.

Audit Log Gereksinimleri

Audit kim, ne zaman, hangi agent ve tool üzerinden hangi resource'a erişti sorusunu cevaplamalıdır. Secret değer loglanmamalıdır. High risk operation ayrı event type olarak işaretlenebilir. Log integrity ve retention policy uygulanmalıdır. Security investigation için merkezi SIEM entegrasyonu yapılabilir.

AI Agent Nasıl Test Edilir?

Agent testleri normal unit testlerden daha geniş kapsam gerektirir. Tool integration, end to end, adversarial ve regression testleri birlikte kullanılmalıdır. Model nondeterminism nedeniyle tek expected string karşılaştırması yeterli olmayabilir. Behavior ve task outcome metric'leri daha anlamlıdır. Production incident'lar test dataset'ine eklenerek aynı hatanın tekrar çıkması engellenmelidir.

Unit Test

Deterministic function ve policy component normal unit test ile doğrulanmalıdır. Tool parameter validation önemli örnektir. Model çağrısını mock ederek workflow state transition test edilebilir. Authorization logic LLM'den bağımsız test edilmelidir. Hızlı unit suite CI içinde her commit'te çalışmalıdır.

Tool Integration Test

Her tool gerçek veya sandbox backend ile test edilmelidir. Timeout, invalid parameter ve permission denied senaryoları eklenmelidir. Write tool idempotency doğrulanmalıdır. Output schema değişikliği breaking change olarak yakalanmalıdır. Production credential test ortamında kullanılmamalıdır.

End-to-End Test

E2E test user request'ten final outcome'a kadar bütün sistemi çalıştırır. Model, retrieval, tool ve approval birlikte doğrulanır. Representative gerçek workflow örnekleri kullanılır. Test environment production'a mümkün olduğunca benzer olmalıdır. Latency ve cost de sonuçla birlikte ölçülebilir.

Golden Dataset

Golden Dataset doğrulanmış input ve expected behavior örneklerinden oluşur. Tek doğru cümle yerine kabul edilebilir action ve source tanımlanabilir. Dataset gerçek user traffic pattern'lerini temsil etmelidir. Zaman içinde yeni edge case eklenir. Model veya prompt değişikliği aynı set üzerinde karşılaştırılır.

Gerçek Kullanıcı Senaryoları

Lab prompt'ları gerçek çalışan dilini her zaman temsil etmez. Yazım hatası, kısa mesaj ve eksik context test edilmelidir. Pilot user session'larından anonimleştirilmiş örnek alınabilir. Data privacy kontrolü gerekir. En sık kullanılan task'lar test ağırlığında daha yüksek pay almalıdır.

Edge Case Testleri

Boş input, çok uzun dosya, eksik data ve çelişkili kaynak edge case'tir. Tool API unavailable senaryosu da test edilmelidir. Agent güvenli failure üretmelidir. Edge case yalnızca technical error değil business boundary'i de kapsamalıdır. Test sonucu pass criteria önceden tanımlanmalıdır.

Adversarial Testler

Kötü niyetli user ve data senaryoları denenmelidir. Permission bypass, prompt injection ve data exfiltration attempt örnek verilebilir. Agent'ın yasak tool'a erişemediği doğrulanmalıdır. Test sonucu security backlog'a taşınmalıdır. Düzenli red team exercise faydalıdır.

Prompt Injection Testleri

Direct ve indirect injection ayrı test edilmelidir. Web content veya doküman içinde malicious instruction kullanılabilir. Agent data ile system instruction'ı karıştırmamalıdır. Backend authorization yine fail safe olmalıdır. Yeni tool eklendiğinde injection testleri tekrar çalıştırılmalıdır.

Regression Testleri

Model upgrade kaliteyi bazı task'larda düşürebilir. Prompt küçük değişiklikle başka intent'i etkileyebilir. Golden dataset her release'te çalıştırılmalıdır. Metric delta threshold aşarsa deployment durdurulabilir. Canary release production regressions için ek güvence sağlar.

Load Testleri

Agent aynı anda çok kullanıcı tarafından çağrıldığında model ve tool limitlerine yaklaşabilir. Rate limit ve queue behavior test edilmelidir. Vector database ve backend API capacity ölçülmelidir. P95 latency SLO ile karşılaştırılmalıdır. Cost burst senaryosu da load test planına dahil edilmelidir.

AI Agent Kalitesi Nasıl Ölçülür?

Agent kalitesi tek bir accuracy sayısıyla ölçülemez. Task completion, tool selection, groundedness, latency ve cost birlikte değerlendirilmelidir. Ayrıca human escalation ve correction oranları üretim kalitesi hakkında önemli sinyal verir. Metric'ler use case'e göre ağırlıklandırılmalıdır. Finans agent'ında hata maliyeti destek agent'ından farklı olduğu için ortak tek skor yanıltıcı olabilir.

Task Completion Rate

Görevin beklenen sonuca başarıyla ulaşma oranıdır. Sadece güzel cevap üretmesi completion değildir. Gerçek CRM update veya doğru report generation doğrulanmalıdır. Partial completion ayrı kategori olabilir. Failure nedeni taxonomy ile tutulmalıdır.

Tool Selection Accuracy

Model doğru tool'u seçiyor mu sorusunu ölçer. Golden dataset hangi tool veya tool sequence'in kabul edilebilir olduğunu içerebilir. Gereksiz tool call da hata sayılabilir. Accuracy düşükse tool description veya routing iyileştirilebilir. Model değişiklikleri bu metriği etkileyebilir.

Tool Execution Success Rate

Seçilen tool gerçekten başarıyla çalışıyor mu ölçülür. Invalid argument, timeout ve backend error ayrı sınıflandırılır. Model hatası ile infrastructure hatası ayrılmalıdır. Write success backend state ile doğrulanmalıdır. Bu metric integration quality hakkında net bilgi verir.

Factual Accuracy

Agent'ın söylediği bilginin doğru olma oranıdır. Structured fact set veya human review kullanılabilir. RAG kaynaklarıyla cevap karşılaştırılabilir. Tahmin ile doğrulanmış bilgi ayrı belirtilmelidir. High risk domain daha yüksek threshold gerektirir.

Groundedness

Groundedness cevabın sağlanan kaynaklara dayanma derecesidir. Citation varlığı tek başına yeterli değildir. İddianın gerçekten ilgili source tarafından desteklenmesi gerekir. Automated evaluator ve human sample review birlikte kullanılabilir. Kaynaksız kesin iddia oranı ayrıca izlenebilir.

Human Escalation Rate

Agent kaç task'ı insana devrediyor ölçülür. Çok yüksek oran automation değerini düşürebilir. Çok düşük oran agent'ın riskli durumda bile gereksiz confidence gösterdiğini gösterebilir. Task difficulty ile birlikte analiz edilmelidir. Hedef oran use case riskine göre belirlenmelidir.

Ortalama Görev Süresi

User request'ten final outcome'a kadar geçen süre ölçülür. Model latency yanında tool ve approval süresi dahil edilir. Human approval bekleme süresi ayrı metric olarak tutulabilir. Baseline insan süreciyle karşılaştırma ROI için anlamlıdır. P95 değer ortalamadan daha kullanışlı olabilir.

Ortalama Maliyet

Görev başına model, tool, vector ve infrastructure cost toplanır. Ortalama yanında P95 cost da izlenmelidir. Bazı task'lar beklenenden çok fazla loop yapabilir. Budget limit anomaly'yi kontrol eder. Maliyet kalite düşürmeden optimize edilmelidir.

Kullanıcı Memnuniyeti

Kullanıcı feedback sistemi kısa ve kolay olmalıdır. Sadece yıldız yerine hata nedeni veya usefulness kategorisi alınabilir. Memnuniyet task success ile birlikte analiz edilmelidir. Kullanıcı hızlı ama yanlış cevabı bazen iyi puanlayabilir. Bu nedenle subjective metric tek başına yeterli değildir.

İnsan Tarafından Düzeltilen İşlem Oranı

Agent önerisinin ne sıklıkla insan tarafından değiştirildiğini gösterir. Teklif taslağı veya ticket classification için çok değerlidir. Correction type modele veya business rule'a göre sınıflandırılabilir. Yüksek oran agent scope'unun fazla geniş olduğunu gösterebilir. Düzeltmeler regression dataset'e kontrollü biçimde eklenebilir.

AI Agent Observability Nedir?

Agent Observability bir request sırasında model, retrieval, tool ve approval akışının izlenebilmesini sağlar. Normal application logundan daha fazla context gerekir. Trace hangi model version, prompt version ve tool call sequence kullanıldığını göstermelidir. Hassas veri loglardan maskelenmelidir. Bu görünürlük olmadan production agent hatasını tekrar üretmek ve düzeltmek ciddi biçimde zorlaşır.

Agent Trace

Trace bir run içindeki bütün önemli adımları tek timeline'da gösterir. Model call, retrieval, tool ve approval event'leri bulunabilir. Her span latency ve status taşır. Run ID user request ile ilişkilendirilir. Debug sırasında exact failure path kolayca bulunur.

Prompt ve Response Logları

Prompt logları debug için yararlı ama veri riski taşır. Sensitive field ve PII maskelenmelidir. Her production prompt'u full text saklamak zorunlu değildir. Hash veya sample strategy kullanılabilir. Retention kısa ve amaca uygun tutulmalıdır.

Tool Call Logları

Tool name, input özeti ve result status kaydedilebilir. Write call resource ve transaction ID içermelidir. Secret veya token log'a yazılmamalıdır. Retry sayısı anomaly tespiti için önemlidir. Security ekibi destructive tool kullanımını ayrı alarm olarak izleyebilir.

Latency

Her model ve tool span latency ölçmelidir. Toplam task süresi critical path'e göre analiz edilir. P95 ve P99 production SLO için önemlidir. Provider veya backend slowdown hızlı tespit edilir. Optimization en büyük latency kaynağına odaklanabilir.

Token Kullanımı

Input ve output token ayrı izlenmelidir. Context büyümesi hidden cost oluşturabilir. Retrieval fazla doküman getiriyorsa token metriği bunu gösterir. Task type bazlı budget tanımlanabilir. Multi agent token attribution specialist bazında yapılabilir.

Maliyet

Her model call estimated cost ile trace'e eklenebilir. Tool ve external API fee varsa ayrıca tutulabilir. Daily ve monthly budget alert kurulabilir. Cost per successful task daha anlamlı KPI'dır. Kalitesiz task'a yüksek harcama yapan workflow öncelikli optimizasyon adayıdır.

Hata Türleri

Model refusal, validation error, permission denied, timeout ve backend failure ayrı kategori olmalıdır. Tek “agent failed” metriği aksiyon üretmez. Error taxonomy root cause analysis'i hızlandırır. Trend belli release sonrası artarsa regression kolay bulunur. User error ve system error ayrımı yapılmalıdır.

İnsan Müdahaleleri

Approval, correction ve escalation event'leri trace içinde bulunmalıdır. İnsan hangi noktada action değiştirdi görülebilir. Bu data automation readiness ölçümünde kullanılır. Tekrar eden correction pattern model veya workflow iyileştirmesi gösterebilir. Human feedback kişisel performans değerlendirmesi için kontrolsüz kullanılmamalıdır.

Distributed Tracing

Agent birden fazla backend'e çağrı yaptığı için distributed trace faydalıdır. Correlation ID CRM, API gateway ve agent service arasında taşınabilir. External tool latency tek timeline'da görülebilir. Open telemetry tabanlı yaklaşım mevcut observability stack ile integration sağlayabilir. PII propagation kontrollü yapılmalıdır.

Production Ortamında AI Agent Monitoring

Production monitoring agent'ın teknik health, business success, maliyet ve security davranışını aynı anda takip etmelidir. Sadece API uptime yeterli değildir. Model performansı, RAG retrieval ve tool error ayrı dashboard metric'leri olmalıdır. Alarm threshold gerçek baseline üzerinden belirlenmelidir. Yeni release sonrası canary group daha sık izlenebilir.

Gerçek Zamanlı Hata İzleme

High severity tool ve permission error anında alarm üretmelidir. Tek kullanıcı input hatası on call alarmı olmamalıdır. Error rate baseline üstüne çıkarsa incident tetiklenebilir. Trace link alert içine eklenebilir. Böylece ekip sorunu hızlı analiz eder.

Başarı Oranı Alarmı

Task Completion Rate belirli threshold altına düşerse alarm oluşabilir. Model provider değişikliği veya backend data sorunu buna neden olabilir. Rolling window tekil anomaly'leri filtreler. Task type bazlı ayrı threshold daha anlamlıdır. Critical workflow daha sıkı SLO kullanabilir.

Maliyet Alarmı

Daily cost veya task başı cost beklenen aralığı aşabilir. Agent loop bu alarm sayesinde erken fark edilir. Department budget ayrıca izlenebilir. Emergency limit write değil model call sayısını da durdurabilir. Cost anomaly security abuse işareti de olabilir.

Güvenlik Alarmı

Permission denial spike, destructive tool denemesi veya cross tenant access attempt yüksek öncelikli event'tir. SIEM entegrasyonu kullanıcı ve network context'i ekleyebilir. Agent prompt içeriği gereksiz biçimde security log'a kopyalanmamalıdır. Incident runbook hangi access token'ın revoke edileceğini belirtmelidir. Kill switch gerektiğinde hızlı uygulanmalıdır.

Model Performansındaki Değişimi İzleme

Provider model behavior zamanla değişebilir. Aynı evaluation dataset düzenli schedule ile çalıştırılabilir. Tool accuracy veya groundedness düşerse alert üretilebilir. Production sample human review ek sinyal sağlar. Model update öncesi ve sonrası karşılaştırma yapılmalıdır.

RAG Kalitesini İzleme

Retrieval hit rate, source freshness ve citation accuracy izlenebilir. “Sonuç bulunamadı” oranında ani artış index pipeline sorununa işaret edebilir. Permission filter bug security riskidir. Stale document usage ayrı metric olarak takip edilebilir. Index sync job health dashboard'da görünmelidir.

Tool Hatalarını İzleme

Her tool için success, timeout ve validation error oranı tutulmalıdır. Backend API değişikliği agent tool'u bozabilir. Retry spike external system slowdown gösterebilir. Write failure kritik alarm olabilir. Tool SLO agent toplam task SLO'suna bağlanmalıdır.

Dashboard Oluşturma

Dashboard business ve technical metric'leri farklı görünümde sunabilir. Management ROI ve adoption görürken platform team latency ve errors izler. Security ayrı permission ve injection event'lerini takip eder. Tek dashboard her ihtiyacı karşılamak zorunda değildir. Ortak run ID katmanlar arasında correlation sağlar.

AI Agent Hata Yaptığında Ne Olmalı?

Agent'ın hata yapmayacağı varsayımı production mimarisi değildir. Sistem yanlış tool seçimi, provider outage ve invalid output gibi durumlara hazırlıklı olmalıdır. Fail safe behavior state değiştirmek yerine durmayı tercih etmelidir. Retry ve rollback kuralları task tipine göre belirlenmelidir. Incident sonrası aynı failure pattern regression test setine eklenmelidir.

Fail-Safe Tasarım

Belirsizlik veya policy conflict durumunda default action güvenli olmalıdır. Ödeme yapmamak, kaydı silmemek veya taslakta kalmak örnek verilebilir. Fail safe user experience açısından açık mesaj üretmelidir. Kullanıcı süreci manual devam ettirebilir. Security boundary hiçbir model cevabıyla bypass edilememelidir.

Retry

Temporary network veya rate limit error tekrar denenebilir. Invalid permission veya business validation error retry edilmemelidir. Exponential backoff kullanılabilir. Maximum retry sayısı sınırlıdır. Write operation idempotent değilse automatic retry kapalı tutulmalıdır.

Fallback Model

Ana model unavailable olduğunda başka model kullanılabilir. Fallback tool calling behavior test edilmelidir. Data policy ikinci provider için de uygun olmalıdır. Daha düşük quality model yalnızca read task'ta kullanılabilir. High risk workflow insan eskalasyonuna geçebilir.

Fallback Workflow

AI katmanı çalışmıyorsa klasik deterministic workflow devreye girebilir. Örneğin ticket otomatik sınıflandırılamazsa default human queue'ya gider. Bu yaklaşım availability'yi artırır. Business process agent availability'sine tamamen bağlı kalmaz. Fallback düzenli olarak test edilmelidir.

İnsana Eskalasyon

Agent hatayı çözemediğinde insan müdahalesi isteyebilir. Escalation context tool result ve hata özetini içermelidir. Sensitive data gereksiz aktarılmamalıdır. Human operator görevi devam ettirebilir. Son karar future evaluation için feedback oluşturur.

İşlemi Geri Alma

Reversible action için compensating operation tasarlanabilir. CRM note delete veya status revert örnek verilebilir. Her action'ın rollback'i mümkün olmayabilir. Bu nedenle transaction öncesi risk sınıfı bilinmelidir. Compensating tool ayrı authorization gerektirebilir.

Rollback

Workflow version hatalıysa previous stable release'e dönülebilir. Prompt ve model config versionlanmalıdır. Database schema compatibility dikkate alınmalıdır. Canary deployment rollback kararını hızlandırır. Rollback procedure otomasyonla test edilmelidir.

Incident Kaydı

High impact agent failure incident management sistemine kaydedilmelidir. Run ID ve trace eklenmelidir. Etkilenen kullanıcı ve resource belirlenir. Security etkisi varsa ayrı severity uygulanır. Owner ve resolution deadline tanımlanmalıdır.

Root Cause Analysis

Hatanın sadece “model yanlış cevap verdi” şeklinde kapatılması yeterli değildir. Prompt, tool schema, data, authorization ve monitoring eksikleri incelenmelidir. Neden validation bunu yakalamadı sorusu sorulmalıdır. Kalıcı action item çıkarılmalıdır. Aynı category başka agent'larda da aranmalıdır.

Aynı Hatanın Tekrarlanmasını Önleme

Incident örneği regression dataset'e eklenmelidir. Gerekirse policy veya tool validation güçlendirilir. Prompt fix tek başına yeterli olmayabilir. Monitoring yeni pattern'i detect edecek şekilde güncellenir. Improvement sonucu release öncesi eval ile doğrulanır.

AI Agent Maliyeti Nasıl Hesaplanır?

AI Agent maliyeti yalnızca model token ücretinden oluşmaz. Tool API, vector database, infrastructure, observability, development ve human approval maliyetleri birlikte ele alınmalıdır. Görev başına toplam maliyet business value ile karşılaştırılmalıdır. Çok ucuz model düşük başarı nedeniyle insan düzeltme maliyetini artırabilir. Bu nedenle TCO ve cost per successful task daha gerçekçi metric'lerdir.

Model Token Maliyeti

Input ve output token kullanımını task bazında ölçmek gerekir. System prompt ve retrieved context input cost'u büyütür. Multi agent aynı content'i tekrar tüketebilir. Caching ve context compression tasarruf sağlar. Maliyet tahmini gerçek production volume ile yapılmalıdır.

Tool ve API Maliyeti

Harici search, enrichment veya SaaS API çağrıları ayrıca ücretli olabilir. Agent loop gereksiz API maliyeti oluşturabilir. Tool çağrı sayısı budget içinde izlenmelidir. Cache ve batch bazı operation'larda fayda sağlar. Vendor rate limit maliyet ve availability planına dahil edilmelidir.

Vector Database Maliyeti

Storage, query ve indexing vector platform maliyetini belirler. Her dokümanı sonsuz retention ile saklamak gereksiz büyüme yaratır. Multi tenant isolation ek resource isteyebilir. Managed ve self hosted seçenek TCO ile karşılaştırılmalıdır. Reindex operation'ın compute maliyeti unutulmamalıdır.

Sunucu ve Altyapı

Orchestrator, API gateway, queue ve state database altyapı maliyeti üretir. Self hosted model GPU maliyetini önemli ölçüde artırır. High availability ek replica gerektirir. Development ve staging ortamları da toplam hesaba dahil edilmelidir. Average utilization düşükse managed hizmet daha ekonomik olabilir.

Observability

Trace ve log hacmi yüksek olabilir. Full prompt logging storage maliyetini büyütür ve privacy riski oluşturur. Sampling ve retention policy uygulanabilir. Metric aggregation daha ekonomik olabilir. Security log minimum retention requirement nedeniyle ayrı maliyet kalemi olabilir.

Geliştirme ve Bakım

Engineer zamanı TCO'nun büyük bölümünü oluşturabilir. Prompt, tool, connector ve security maintenance sürekli devam eder. Model provider update regression test gerektirir. On call ve incident response maliyeti hesaplanmalıdır. Buy seçeneği bu insan maliyetiyle birlikte karşılaştırılmalıdır.

İnsan Kontrol Maliyeti

Human approval automation kazanımını azaltabilir ama risk kontrolü sağlar. Approval süresi ve çalışan maliyeti task başına hesaplanabilir. Kalite arttıkça düşük riskli approval kaldırılabilir. High risk action için insan kontrol maliyeti business requirement olarak kabul edilir. ROI tamamen insanı sıfırlamak üzerinden hesaplanmamalıdır.

Görev Başına Toplam Maliyet

Model, API, infrastructure ve human cost aynı task ID altında toplanabilir. Başarısız task'ların maliyeti ayrıca izlenmelidir. Cost per completed task karar için daha anlamlıdır. İnsan baseline maliyetiyle karşılaştırılabilir. Volume büyüdükçe unit economics tekrar değerlendirilmelidir.

AI Agent ROI Nasıl Hesaplanır?

ROI hesabı agent projesinin gerçekten business değer oluşturup oluşturmadığını gösterir. Baseline ölçülmeden ROI hesaplamak mümkün değildir. Zaman kazanımı, hata azalması, cycle time ve revenue etkisi birlikte değerlendirilebilir. Total ownership cost denklemin diğer tarafında yer almalıdır. Pilot sonrası continuation kararı teknoloji heyecanına değil ölçülen sonuçlara dayanmalıdır.

Mevcut Sürecin Baseline'ını Belirleme

Agent öncesi task süresi, hata ve çalışan eforu ölçülmelidir. Sample sayısı representative olmalıdır. Peak ve normal dönem ayrılabilir. Qualitative pain point not edilebilir. Sonraki bütün iyileştirme bu baseline'a göre karşılaştırılır.

Kazanılan Çalışan Saati

Agent bir task'ı tamamen kaldırmasa bile hazırlık süresini azaltabilir. Ayda kaç task yapıldığıyla zaman kazancı çarpılır. İnsan approval süresi düşülmelidir. Kazanılan zamanın gerçekten başka değere dönüp dönmediği değerlendirilmelidir. Sadece teorik saat birikimi revenue değildir.

Hata Azalması

Manual data entry hatası veya yanlış routing azalabilir. Her error'ın düzeltme maliyeti hesaplanabilir. Agent yeni error türleri de oluşturabilir. Net hata oranı ölçülmelidir. High severity hata sayısı ayrıca takip edilmelidir.

İşlem Süresindeki Azalma

Lead response veya ticket resolution süresinin kısalması customer experience etkisi yaratabilir. Cycle time agent öncesi ve sonrası ölçülür. Approval bottleneck ayrı görünür. Sadece model response latency değil end to end business process dikkate alınmalıdır. Improvement trendi volume ile birlikte analiz edilmelidir.

Gelir Artışı

Satış agent'ı daha hızlı follow up ile conversion artışı sağlayabilir. Attribution dikkatli yapılmalıdır. Aynı dönemde kampanya veya fiyat değişimi sonucu etkileyebilir. Controlled pilot group daha doğru karşılaştırma sağlar. Revenue impact uzun dönem izlenmelidir.

Agent'ın Toplam Sahip Olma Maliyeti

TCO development, model, infrastructure, support ve human review içerir. Yıllık lisans veya provider cost eklenir. Security ve compliance çalışması da gerçek maliyettir. Self hosted model on call burden yaratabilir. ROI net değer üzerinden hesaplanmalıdır.

Break-Even Hesabı

Initial development cost aylık net kazanca bölünerek break even süresi tahmin edilebilir. Ongoing maintenance düşülmelidir. Volume arttıkça model cost da artabilir. Best ve worst case scenario hesaplanmalıdır. Çok uzun break even pilotun durdurulmasını gerektirebilir.

Pilotun Devam Edip Etmemesine Karar Verme

Pilot sonucunda success metric hedefleri karşılaştırılır. Güvenlik veya kalite problemi çözülmemişse scaling ertelenmelidir. Business owner kullanım ihtiyacını doğrulamalıdır. Teknik ekip maintenance maliyetini değerlendirmelidir. Başarısız pilot da değerli öğrenim olarak dokümante edilmelidir.

Şirket İçinde AI Agent Governance Nasıl Kurulur?

Agent sayısı arttıkça merkezi governance gerekli hale gelir. Hangi agent'ın kim tarafından kullanıldığı, hangi tool ve modele eriştiği envanterde tutulmalıdır. Business owner, technical owner ve risk owner farklı kişiler olabilir. Prompt ve model değişikliği versionlanmalıdır. Kullanılmayan agent'lar kontrollü biçimde devreden çıkarılmalıdır.

Agent'ın İş Sahibi Kim?

Business owner agent'ın çözdüğü sürecin sorumlusudur. Success metric ve scope kararını onaylar. Agent yanlış business sonucu üretirse teknik ekip tek başına karar sahibi değildir. Kullanıcı feedback bu owner tarafından değerlendirilir. Scaling kararı business sonuçla ilişkilendirilir.

Teknik Sahibi Kim?

Technical owner code, deployment ve integration sorumluluğunu taşır. Model ve tool version upgrade'lerini yönetir. Monitoring ve on call sürecine katılır. Security fix'leri zamanında uygular. Owner değişirse knowledge transfer yapılmalıdır.

Risk Sahibi Kim?

Risk owner security, legal veya process risklerini kabul eden yetkili role olabilir. High risk tool ve data access kararlarında görüş verir. Residual risk dokümante edilir. Risk kabulü süresiz olmamalıdır. Belirli aralıklarla yeniden değerlendirilmelidir.

Hangi Agent'ların Kullanıldığı Nasıl Kaydedilir?

Merkezi Agent Registry oluşturulabilir. Name, owner, purpose, model, tool, data source ve environment bilgisi tutulur. Production status ve last review date eklenebilir. Security incident sırasında etkilenen agent'lar hızlı bulunur. Shadow veya kişisel agent kullanımını azaltmak için discovery ve policy gerekir.

Agent Envanteri

Inventory aynı zamanda compliance ve cost yönetimine yardımcı olur. Her agent için data classification tutulabilir. Model provider ve region bilgisi kaydedilebilir. Kullanılmayan agent decommission adayına dönüşür. Inventory otomatik deployment metadata ile güncellenebilir.

Yetki Değişiklikleri

Agent tool veya data permission değişikliği normal code change kadar ciddi değerlendirilmelidir. Pull request ve approval süreci uygulanabilir. Büyük scope artışı security review gerektirebilir. Change audit log'a yazılır. Regression test yeni permission ile tekrar çalıştırılır.

Model ve Prompt Versiyonlama

Her production run model ve prompt version bilgisi taşımalıdır. Böylece incident hangi konfigürasyonda oluştu görülebilir. New version canary ile yayınlanabilir. Golden dataset karşılaştırması release gate olabilir. Rollback previous configuration'a hızlı dönmelidir.

Periyodik Agent Denetimi

Agent üç veya altı aylık review cycle'a alınabilir. Permission, owner, success metric ve data source tekrar değerlendirilir. Kullanılmayan tool kaldırılır. Model ve dependency security status kontrol edilir. Risk seviyesi değişmişse approval policy güncellenir.

Agent'ı Devreden Çıkarma Süreci

Decommission yalnızca UI'ı kapatmak değildir. Service account ve token revoke edilmelidir. MCP ve tool access kaldırılmalıdır. Memory ve data retention policy uygulanmalıdır. Inventory status archived olarak güncellenmelidir.

Şirket İçi AI Agent'ları Ölçeklendirme

Bir pilotun başarılı olması onlarca agent'ın hemen kurulması gerektiği anlamına gelmez. Scale sırasında ortak tool, identity, RAG ve eval altyapısı oluşturmak duplication'ı azaltır. Her departmanın kendi framework'ünü seçmesi governance sorununa yol açabilir. Merkezi platform team güvenli building block sağlar. Business ekipler bu standard üzerinde kendi use case'lerini geliştirebilir.

Pilot Agent'tan Production Agent'a Geçiş

Pilotda kullanılan temporary code production standardına taşınmalıdır. Security review, load test ve observability tamamlanmalıdır. Owner ve SLO belirlenir. Data retention ve incident response hazırlanır. User rollout kademeli yapılır.

Bir Departmandan Diğerlerine Yaygınlaştırma

Aynı use case başka ekipte farklı process'e sahip olabilir. Template kopyalanmadan önce requirement tekrar çıkarılmalıdır. Shared tool yeniden kullanılabilir. Department specific data ve permission ayrı kalır. Scaling merkezi ama esnek platform modeliyle yapılmalıdır.

Ortak Tool Katmanı

CRM read veya document search tool birden fazla agent tarafından kullanılabilir. Central tool service security ve audit standardını tek yerde uygular. Version ve schema contract yönetilmelidir. Tool owner belirlenir. Shared component outage etkisi için HA planı gerekir.

Ortak RAG Altyapısı

Document ingestion, chunking ve retrieval pipeline ortaklaştırılabilir. Tenant ve ACL boundary korunmalıdır. Her agent aynı index'i doğrudan kullanmak zorunda değildir. Domain specific collection oluşturulabilir. Central quality metric source freshness izler.

Merkezi Identity Katmanı

SSO ve service identity ortak platform servisi olabilir. Agent developer authorization logic'i sıfırdan yazmaz. Delegated user context standard token formatıyla taşınır. Audit bütün tool'larda aynı principal ID kullanır. Merkezi katman yüksek availability gerektirir.

Ortak Evaluation Platformu

Dataset, metric ve release gate ortak platformda yönetilebilir. Her agent kendi domain evaluator'ını ekler. Model ve prompt değişikliği otomatik karşılaştırılır. Sonuç dashboard'da owner'a gösterilir. Bu yaklaşım kalite standardını organization genelinde yükseltir.

Agent Platform Ekibi Kurmak

Büyük kurumda platform team ortak SDK, tool ve security pattern sağlayabilir. Business agent ekipleri domain logic'e odaklanır. Platform governance merkezi olur. Team aynı zamanda model provider ve cost management'i yönetebilir. Kullanıcı desteği ve documentation önemli sorumluluklardır.

Agent-as-a-Service Yaklaşımı

Agent as a Service departmanların kontrollü platform üzerinden agent oluşturmasını sağlar. Identity, observability ve eval default olarak gelir. Tool marketplace sadece approved integration'ları içerir. Template'ler güvenli başlangıç sağlar. Bu model shadow agent kullanımını azaltabilir.

Çalışanların AI Agent Kullanımına Hazırlanması

Teknik olarak iyi agent kullanıcılar güvenmiyorsa değer üretmez. Çalışanlar agent'ın neyi iyi yaptığını ve nerede hata yapabileceğini bilmelidir. İnsan ile ajan arasındaki görev paylaşımı açık olmalıdır. Feedback vermek kolay hale getirilmelidir. Değişim yönetimi teknik deployment kadar önemlidir.

AI Agent Literacy

Çalışanlar agent'ın probabilistic bir sistem olduğunu anlamalıdır. Her cevabın kesin doğru olmadığı öğretilmelidir. Kaynak kontrolü ve approval davranışı eğitimde gösterilmelidir. Prompt injection gibi temel riskler ilgili kullanıcı gruplarına anlatılabilir. Eğitim task odaklı ve kısa olmalıdır.

Çalışan Eğitimi

Eğitim gerçek şirket kullanım senaryoları üzerinden yapılmalıdır. Hangi verinin agent'a gönderilemeyeceği açıkça belirtilmelidir. Kullanıcı hata raporlama yöntemini bilmelidir. Onay ekranında neyi kontrol etmesi gerektiği gösterilmelidir. Yeni feature geldiğinde eğitim güncellenmelidir.

İnsan ve Agent İş Bölümü

Agent tekrar eden bilgi toplama ve taslak görevlerini üstlenebilir. İnsan belirsiz, yüksek riskli ve ilişki gerektiren kararları verir. Bu sınır çalışan endişesini azaltır. Role definition iş süreci dokümanına eklenebilir. Zamanla success metric'e göre otonomi yeniden dengelenebilir.

Çalışan Güvenini Oluşturmak

Agent cevabının kaynağını göstermek güven yaratır. Kullanıcı yanlış sonucu kolayca düzeltebilmelidir. Sistem hatayı gizlemek yerine açıkça failure göstermelidir. Pilot feedback'e gerçekten cevap verilmesi adoption'ı artırır. Zorunlu kullanım yerine faydanın gösterilmesi daha sürdürülebilir sonuç verir.

Agent'ın Hata Yapabileceğini Öğretmek

Kullanıcılar modelin confident ama yanlış cevap verebileceğini bilmelidir. Critical action öncesi doğrulama alışkanlığı oluşturulmalıdır. Agent “kaynak bulamadım” dediğinde bunu zayıflık değil güvenli davranış olarak görmek gerekir. Eğitim gerçek hata örnekleri içerebilir. Overtrust riskini azaltmak önemli change management hedefidir.

Geri Bildirim Mekanizması

Feedback tek tıkla verilebilmelidir. Kullanıcı yanlış source, hatalı tool veya eksik cevap kategorisi seçebilir. Free text ek alan olarak kullanılabilir. High severity feedback incident oluşturabilir. Feedback backlog owner tarafından düzenli incelenmelidir.

Değişim Yönetimi

Agent yeni iş yapma biçimi getirir ve rol beklentilerini etkileyebilir. Liderler projenin amacını açıkça anlatmalıdır. Çalışan input'u tasarım sürecine erken alınmalıdır. Başarı hikayeleri ölçülebilir veriyle paylaşılmalıdır. Zorunlu hızlı rollout yerine kontrollü adoption daha sağlıklı olabilir.

Şirket İçi Örnek Proje: Bilgi Asistanı Agent

Bilgi asistanı agent çoğu şirket için düşük riskli ve yüksek değerli ilk projedir. Sistem SharePoint, Notion veya file server dokümanlarını RAG ile searchable hale getirir. Kullanıcı SSO identity'si retrieval permission'a uygulanır. Yanıtlar kaynak gösterir ve yetersiz veri olduğunda açıkça bunu belirtir. Pilot birkaç departmanla başlayıp accuracy ve user satisfaction ölçülebilir.

Problem Tanımı

Çalışanlar bilgiye ulaşmak için çok fazla doküman ve kişiye başvuruyor olabilir. Aynı soru tekrar tekrar uzman ekipleri meşgul eder. Baseline olarak cevap bulma süresi ölçülür. En sık soru kategorileri çıkarılır. Agent scope yalnızca onaylı internal knowledge ile sınırlandırılır.

Veri Kaynakları

Önce en güvenilir ve güncel source'lar seçilir. Eski shared folder'ın tamamını indexlemek yerine owner'lı dokümanlardan başlanır. Permission metadata connector ile alınır. Source refresh schedule belirlenir. Stale ve duplicate content düzenli temizlenir.

RAG Mimarisi

Document pipeline parse, chunk, embedding ve indexing adımlarından oluşur. Query önce permission filter uygular. Hybrid retrieval ve reranker kullanılabilir. Top result modele context olarak verilir. Citation mapping final response'a eklenir.

SSO ve Kullanıcı Yetkisi

Kullanıcı girişini enterprise SSO sağlar. Group ve role bilgisi retrieval scope'a çevrilir. Agent service account bütün dokümanı teknik olarak okuyabilse bile kullanıcıya filtrelenmiş sonuç verir. Permission backend seviyesinde uygulanır. Audit user ID ve source ID ile kaydedilir.

Kaynaklı Yanıtlar

Her önemli iddia ilgili belgeye bağlanır. Kullanıcı tek tıkla source'a gidebilir. Source version ve updated date gösterilebilir. Yeterli belge yoksa agent tahmin etmez. Citation accuracy eval metriği olur.

Evals

Gerçek employee question set'i hazırlanır. Expected source ve acceptable answer belirlenir. Retrieval Recall ve groundedness ölçülür. Türkçe ve kısa günlük sorular dahil edilir. Her index veya model değişimi dataset üzerinde test edilir.

Pilot

Pilot tek veya iki departmanda başlatılır. User feedback doğrudan product backlog'a gider. En sık failure pattern analiz edilir. Adoption ve search time improvement ölçülür. Permission leakage testi paralel yürütülür.

Production Deployment

Successful pilot sonrası kullanıcı grubu kademeli artırılır. Capacity ve cost monitor edilir. SSO ve connector HA kontrol edilir. Incident response ve support owner belirlenir. Yeni source ekleme change process'e bağlanır.

Monitoring

Search success, no result, citation click ve user feedback izlenebilir. Source freshness önemli dashboard metriğidir. Cross permission access attempt güvenlik alarmıdır. Cost per query takip edilir. Model ve retrieval regression düzenli eval ile izlenir.

Şirket İçi Örnek Proje: Satış Operasyon Ajanı

Satış operasyon ajanı bilgi asistanına göre daha fazla tool ve write işlemi içerir. Yeni lead geldiğinde araştırma, CRM okuma, scoring ve teklif taslağı oluşturabilir. CRM güncelleme insan onayıyla yapılabilir. Dış web verisi güvenilmeyen içerik olarak işlenmelidir. Bu proje kurumsal AI agent geliştirme mimarisi nasıl kurulur sorusunu uçtan uca göstermek için iyi bir örnektir.

Yeni Lead'in Gelmesi

CRM webhook yeni lead event'i oluşturur. Agent task ID üretir. Lead owner ve user permission context'e eklenir. Duplicate lead kontrol edilir. Event schema validation'dan sonra workflow başlar.

Şirket Araştırması

Agent onaylı web search tool ile şirket hakkında bilgi toplar. Kaynak URL ve tarih saklanır. Web sayfası instruction değil data olarak değerlendirilir. Unsupported claim rapora eklenmez. Araştırma süresi ve domain sayısı limitlidir.

CRM Verisini Okuma

Agent mevcut account ve contact kayıtlarını read tool ile getirir. Territory permission backend'de kontrol edilir. Sensitive field gerekmiyorsa response'tan çıkarılır. Aynı şirketin geçmiş opportunity verisi özetlenebilir. Bulk CRM export mümkün değildir.

Lead Skorlama

Agent qualitative sinyalleri structured field'a dönüştürür. Final skor deterministic scoring service tarafından hesaplanır. Kriter ve ağırlık business owner tarafından yönetilir. Agent score'u açıklayan kısa özet üretir. Belirsiz data skor confidence'ını düşürür.

Teklif Taslağı

Approved product ve pricing data kullanılır. Model serbest fiyat uyduramaz. Customer context'e göre metin taslağı hazırlanır. Discount limit business rule ile kontrol edilir. Taslak satış temsilcisine gösterilir.

İnsan Onayı

Sales representative research ve teklif içeriğini inceler. Gerekirse düzenleme yapar. CRM write ve e-mail send ayrı approval olabilir. Human correction feedback olarak kaydedilir. Approval token task specific olur.

CRM Güncelleme

Agent sadece onaylanan alanları günceller. Old ve new value audit log'a yazılır. Idempotency duplicate update'i engeller. Permission yeniden kontrol edilir. Failure halinde manual fallback sunulur.

Audit Log

Run boyunca kullanılan source, tool ve approval event'leri saklanır. Secret veya personal unnecessary content maskelenir. Business owner task history'yi görebilir. Security unusual access'i SIEM üzerinden izler. Audit retention corporate policy ile uyumludur.

Open Source ve İşbirliği ile AI Agent Geliştirme

Açık kaynak agent framework, model ve MCP server ekosistemi geliştirme hızını artırabilir. Bununla birlikte her dependency ayrı trust ve maintenance riski getirir. Public repository olması güvenli veya sürdürülen yazılım olduğu anlamına gelmez. Security review, version pinning ve vulnerability scanning kullanılmalıdır. Ekip içi issue, pull request ve evaluation dataset çalışmaları kaliteyi sürekli geliştirmek için güçlü yöntemdir.

Açık Kaynak Agent Framework'leri

Framework'ler orchestration ve tool calling için hazır abstraction sunabilir. Project activity ve maintainer response incelenmelidir. API stability production maintenance açısından önemlidir. Dependency sayısı minimumda tutulmalıdır. Framework security boundary olarak görülmemelidir.

Açık Kaynak LLM'ler

Open weight veya açık kaynak model seçenekleri self hosted deployment sağlayabilir. Türkçe ve tool calling kalitesi gerçek testle ölçülmelidir. GPU ve inference operasyonu TCO hesabına dahil edilmelidir. License commercial usage açısından incelenmelidir. Model security update ve artifact source doğrulanmalıdır.

Açık Kaynak MCP Server'lar

Community MCP Server entegrasyonu hızlı sağlayabilir. Ancak server çok geniş filesystem veya token access isteyebilir. Code review ve sandbox test yapılmalıdır. Unmaintained project production'a alınmamalıdır. Kurum onaylı fork oluşturmayı tercih edebilir.

Güvenilmeyen Açık Kaynak Bileşenlerin Riskleri

Dependency malicious code veya vulnerability içerebilir. Build pipeline SBOM ve scanning kullanabilir. Runtime permission minimum tutulmalıdır. Package update otomatik production'a gitmemelidir. High risk component için source review yapılabilir.

Git ve GitHub ile Agent Projesi Yönetimi

Prompt, tool schema ve eval dataset version control altında tutulabilir. Branch protection ve code review normal software practice olarak uygulanmalıdır. Secret repository'ye yazılmamalıdır. CI regression eval çalıştırabilir. Release tag model config ile ilişkilendirilebilir.

Issue ve Pull Request Süreci

Agent failure issue olarak kaydedilebilir. Reproduction input ve trace ID eklenir. Sensitive data sanitize edilmelidir. Pull request eval result göstermelidir. High risk tool değişikliği security reviewer isteyebilir.

Evaluation Dataset'lerini Ekip Olarak Geliştirmek

Business uzmanları gerçek expected behavior konusunda teknik ekipten daha fazla bilgiye sahip olabilir. Dataset birlikte hazırlanmalıdır. New production case düzenli eklenir. Label quality review edilir. Dataset içindeki kişisel veri maskelenmelidir.

İç Developer Platform Oluşturmak

Platform team common agent SDK, identity ve tool registry sunabilir. Yeni agent güvenli template ile başlar. Observability ve eval default olarak aktive edilir. Developer sadece domain specific logic'e odaklanır. Platform documentation adoption için kritik öneme sahiptir.

Şirket İçi AI Agent Geliştiren Bir Yazılımcı Olmak İçin Ne Yapmalı?

Kurumsal agent geliştirmek yalnızca prompt yazma becerisi değildir. Programlama, API, database, LLM, RAG, tool calling, security ve observability birlikte öğrenilmelidir. Bir production project geliştirmek teorik eğitimden daha fazla değer sağlar. Önce tek agent ve read only tool ile başlanabilir. Daha sonra authorization, eval ve human approval eklenerek gerçek sistem tasarımı öğrenilebilir.

Programlama Temelleri

Data structure, error handling, concurrency ve testing bilgisi agent sistemlerinde doğrudan kullanılır. Model çağrısı normal backend operation gibi yönetilmelidir. Timeout ve retry behavior anlaşılmalıdır. Secure coding temel beceridir. Framework bu temellerin yerine geçmez.

Python veya TypeScript

İki dil de agent ecosystem içinde güçlü seçeneklerdir. Birini iyi öğrenmek başlangıç için yeterlidir. SDK, async request ve schema validation üzerinde pratik yapılmalıdır. Küçük API service geliştirmek faydalıdır. Language değişiminden çok production skill önemlidir.

API ve Webhook

Agent tool'ları çoğunlukla API çağrısıdır. REST, authentication, rate limit ve webhook güvenliği bilinmelidir. Idempotency write operation için önemlidir. API error taxonomy agent workflow'u etkiler. OAuth ve service identity pratik olarak öğrenilmelidir.

Veritabanları

Structured data çoğu kurumsal agent'ın temel kaynağıdır. SQL query ve transaction davranışı bilinmelidir. Read only access ve row level security uygulanmalıdır. Vector database ayrıca öğrenilebilir. Data modeling tool design kalitesini artırır.

LLM ve Prompt Engineering

Modelin instruction ve context davranışı anlaşılmalıdır. Structured output ve tool calling pratik edilmelidir. Prompt version ve eval birlikte kullanılmalıdır. Güvenliği sadece prompt ile çözmeye çalışmamak önemli öğrenimdir. Model limitation gerçek örneklerle görülmelidir.

RAG

Ingestion, chunking, embedding, retrieval ve reranking öğrenilmelidir. Metadata filtering kurumsal use case'te özellikle önemlidir. Source citation quality ölçülmelidir. Permission aware retrieval practice yapılmalıdır. Data cleanup RAG performansının önemli bölümüdür.

Tool Calling

Function schema ve argument validation temel konulardır. Read ve write ayrımı uygulanmalıdır. Tool result machine readable tasarlanmalıdır. Retry ve idempotency öğrenilmelidir. Audit logging practice yapılmalıdır.

MCP

MCP client server architecture anlaşılmalıdır. Kendi küçük internal server'ını geliştirmek iyi pratiktir. Authentication ve tool permission eklenmelidir. Malicious server riskleri test edilmelidir. Protocol security ile application authorization ayrımı bilinmelidir.

Agent Framework'leri

En az bir framework kullanmak orchestration pattern'lerini anlamaya yardımcı olur. Daha sonra aynı sistemi küçük custom implementation ile yapmak abstraction farkını gösterir. Framework seçimine bağımlı kalmamak gerekir. State ve graph concept öğrenilmelidir. Production evaluation her frameworkte ortak ihtiyaçtır.

Güvenlik

Prompt injection, secret leakage ve least privilege temel konulardır. OWASP tarzı application security bilgisi agent dünyasında da geçerlidir. Threat modeling öğrenilmelidir. Authorization LLM dışında uygulanmalıdır. Adversarial test practice yapılmalıdır.

Evals ve Observability

Golden dataset oluşturma ve metric tasarımı öğrenilmelidir. Trace ile model ve tool flow analiz edilmelidir. Cost ve latency dashboard kurulabilir. Regression CI pipeline'a eklenebilir. Production quality bu beceriler olmadan sürdürülemez.

Production Projesi Geliştirmek

En iyi öğrenme küçük gerçek project kurmaktır. Internal document assistant iyi başlangıçtır. SSO, RAG, source citation ve eval eklenebilir. Daha sonra controlled write tool ile ikinci project yapılabilir. Deployment ve monitoring tamamlanmadan project bitmiş sayılmamalıdır.

Diyarbakır Yazılım Topluluğu ile AI Agent Ekosistemi

Kurumsal yapay zeka ajanları üzerine çalışan yazılımcılar için yerel teknik topluluklar hem öğrenme hem de proje geliştirme açısından önemli ortamlar sunabilir. Diyarbakır'da farklı seviyelerdeki geliştiricilerin agent, RAG, MCP ve güvenlik başlıklarını birlikte uygulaması bölgesel teknik yetkinliğin gelişmesine katkı sağlayabilir. Diyarbakır Yazılım Topluluğu'nun çalışma alanları ve teknik yaklaşımı için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir. Topluluk modeli özellikle gerçek şirket problemlerinin workshop ve açık kaynak pilotlara dönüştürülmesi açısından değerli olabilir. Şirketler için özel yapay zeka ajanı geliştirme ve entegrasyon hizmeti düşünen ekipler önce küçük, ölçülebilir ve güvenli bir pilotla başlamalıdır.

Şirket İçi AI Ajanları Üzerine Teknik Çalışma Grupları

Çalışma grubu her ay belirli agent architecture konusunu ele alabilir. Bir ay RAG, sonraki ay MCP veya eval çalışılabilir. Katılımcılar ortak demo project üzerinde kod geliştirebilir. Security review ayrı oturum olarak yapılabilir. Çıktılar açık teknik doküman haline getirilebilir.

Yerel İşletmeler İçin Agent Projeleri

Yerel işletmelerde müşteri destek, doküman arama ve raporlama iyi pilot alanları olabilir. Süreç önce gözlemlenmelidir. Küçük proof of concept gerçek data ile controlled environment'da test edilebilir. ROI ve risk sonucu production kararı verilir. Gereksiz geniş kapsam yerine tek problem çözülmelidir.

AI Agent Workshopları

Workshop yalnızca model API çağrısı göstermemelidir. Tool calling, RAG permission ve eval dahil edilmelidir. Katılımcılar malicious prompt injection senaryosu da deneyebilir. Human approval ve audit eklenebilir. Böylece demo ile production architecture arasındaki fark öğrenilir.

Open Source Agent Projeleri

Community internal knowledge assistant veya secure MCP template geliştirebilir. Contributor'lar issue ve pull request üzerinden çalışabilir. Security policy ve test dataset repository'de bulunabilir. Gerçek şirket secret'ları kullanılmamalıdır. Project yeni geliştiricilere production pattern öğretir.

Diyarbakır'daki En İyi Yazılımcılarla Bilgi Paylaşımı

Bilgi paylaşımının değeri kişilerin birbirini sıralamasından değil, farklı tecrübelerin bir araya gelmesinden gelir. Backend, security, data ve product uzmanları aynı agent projesinde farklı sorunları görür. Code review ortak öğrenmeyi hızlandırır. Demo day gerçek implementation kararlarını tartışmaya açar. Topluluk hakkında daha fazla bilgi https://www.diyarbakiryazilim.com.tr/about adresinden alınabilir.

Yerel Şirketlere Yönelik Pilot Projeler

Yerel şirketler için pilot project gerçek business problem üzerinden seçilmelidir. İlk hedef her departmana agent kurmak değildir. Tek süreçte zaman ve kalite kazanımı gösterilmelidir. Security ve data ownership baştan belirlenmelidir. Pilot sonunda ölçülebilir sonuç paylaşılması sonraki yatırımı daha sağlıklı hale getirir.

Müşteri Destek Agent'ı

Internal knowledge ve FAQ üzerinden cevap taslağı hazırlayabilir. İlk aşamada insan temsilci gönderimi onaylar. Ticket classification otomatik yapılabilir. Kaynaksız cevaplar reddedilebilir. Success rate pilot boyunca ölçülür.

Satış Agent'ı

Lead research ve CRM summary için kullanılabilir. Dış web içeriği güvenilmeyen data olarak işlenir. Teklif taslağı insan approval ister. CRM write limited scope'a sahip olur. ROI satış temsilcisinin kazandığı zamanla ölçülebilir.

Doküman ve Bilgi Agent'ı

SharePoint veya file server içeriğini RAG ile erişilebilir hale getirir. SSO permission retrieval'a uygulanır. Citation zorunlu tutulabilir. Eski doküman index'ten çıkarılır. Read only olduğu için düşük riskli pilot sunar.

Raporlama Agent'ı

Natural language soruyu güvenli analytics query'ye dönüştürebilir. SQL read only role kullanır. Hesaplama database'de yapılır. Model yalnızca sonuç yorumunu üretir. Dashboard veya scheduled summary oluşturulabilir.

Şirket İçi AI Agent Projelerinde Sık Yapılan Hatalar

Agent projelerinde en büyük sorun çoğu zaman model kalitesi değil yanlış scope ve eksik governance olur. Fazla geniş yetki, test dataset eksikliği ve human approval'ı erken kaldırmak production riskini artırır. Multi agent mimarisine hemen geçmek debug ve maliyeti gereksiz büyütebilir. RAG kullanmak da yanlış bilgiyi tamamen ortadan kaldırmaz. Başarılı projeler küçük scope, net owner ve sürekli evaluation disipliniyle ilerler.

Agent Gerekmeyen Sürece Agent Kurmak

Deterministik workflow için LLM kullanmak gereksiz maliyet yaratır. Basit cron veya API automation daha güvenilir olabilir. Agent belirsizlik ve karar gereken yerde kullanılmalıdır. Architecture review bu soruyu ilk aşamada sormalıdır. En iyi agent bazen hiç agent kurmamaktır.

Çok Geniş Kapsamla Başlamak

“Şirketin bütün işlerini yapan agent” başarısız pilot için uygun tariftir. Tool ve data sayısı hızla büyür. Evaluation mümkün olmaktan çıkar. Tek use case ile başlanmalıdır. Sonuç kanıtlandıkça scope kademeli genişletilir.

Agent'a Fazla Yetki Vermek

Admin service account kullanmak hızlı prototip sağlayabilir. Production'da ciddi blast radius oluşturur. Least privilege role hazırlanmalıdır. Read ve write ayrılmalıdır. Permission review release gate olabilir.

İnsan Onayını Kaldırmak

Pilot iyi sonuç verince bütün approval'ları kaldırmak doğru değildir. High risk action için insan kontrolü kalabilir. Approval rate ve correction metriği otonomi kararına yön verir. Sadece düşük riskli sınıf otomatikleştirilebilir. Otonomi task bazında artırılmalıdır.

Test Dataset'i Oluşturmamak

Dataset olmadan prompt değişikliği daha iyi mi kötü mü bilinmez. Demo örnekleri gerçek user davranışını temsil etmez. Production issue tekrar ortaya çıkabilir. Golden set version control altında tutulmalıdır. Release CI içinde eval çalışmalıdır.

Prompt Injection'ı Görmezden Gelmek

Agent dış doküman veya web okuyorsa injection riski vardır. “Kullanıcılarımız kötü niyetli değil” yeterli savunma değildir. Dış kaynakta zararlı instruction bulunabilir. Tool permission boundary güvenilir olmalıdır. Adversarial test yapılmalıdır.

RAG Kullanmanın Halüsinasyonu Tamamen Çözdüğünü Düşünmek

RAG yanlış veya ilgisiz kaynak getirebilir. Model kaynakta olmayan yorum ekleyebilir. Citation presence doğruluk garantisi değildir. Groundedness ve retrieval eval gereklidir. Yeterli source yoksa agent cevap vermemelidir.

Log ve Trace Tutmamak

Kullanıcı “agent yanlış yaptı” dediğinde ne olduğunu anlamak zorlaşır. Tool sequence ve model version bilinmez. Trace production debugging için zorunludur. Sensitive data masking gerekir. Incident reproduction büyük ölçüde kolaylaşır.

Maliyeti İzlememek

Agent loop veya multi agent call maliyeti hızla artırabilir. Kullanıcı başı veya task başı cost ölçülmelidir. Budget alert kullanılmalıdır. Expensive model bütün task'larda kullanılmamalıdır. Cost optimization kalite metriğiyle birlikte yapılmalıdır.

Multi-Agent Mimarisine Çok Erken Geçmek

Multi agent architecture ilk demo için etkileyici görünebilir. Production'da handoff ve debugging zorlaşır. Tek agent'ın gerçekten yetersiz olduğu eval ile gösterilmelidir. Router veya deterministic workflow önce denenmelidir. Ek complexity business value ile gerekçelendirilmelidir.

Agent'ın İş Sahibinin Belirsiz Olması

Business owner yoksa success tanımı belirsiz olur. User feedback kimin sorumluluğunda olduğu bilinmez. Incident sonrası karar gecikir. Agent inventory owner field zorunlu olabilir. Sahipsiz agent production'a alınmamalıdır.

Pilot Başarısını Ölçmeden Ölçeklendirmek

Kullanıcıların demo ilgisi gerçek ROI değildir. Task completion ve time saving ölçülmelidir. Security ve cost sonuçları dahil edilmelidir. Pilot target karşılamıyorsa önce problem çözülmelidir. Başarısız pattern başka departmanlara kopyalanmamalıdır.

Production Öncesi AI Agent Kontrol Listesi

Production deployment öncesi business, security, quality ve operation kontrolleri aynı listede değerlendirilmelidir. Use case net değilse teknik checklist tek başına fayda sağlamaz. Yetki ve data erişimi minimum olmalıdır. Evals, monitoring ve incident response hazır olmalıdır. Kill switch ve fallback gerçek ortamda test edilmeden kritik workflow açılmamalıdır.

Kullanım Senaryosu Net mi?

Agent'ın hangi problemi çözdüğü tek paragrafta açıklanabilmelidir. Scope dışı görevler yazılı olmalıdır. Business owner belli olmalıdır. Kullanıcı grubu tanımlanmalıdır. Başarılı sonucu ölçen metric bulunmalıdır.

Başarı Metrikleri Tanımlı mı?

Task completion ve quality hedefleri sayısal olmalıdır. Cost ve latency target eklenmelidir. Human correction threshold belirlenebilir. Security incident zero tolerance olabilir. Pilot baseline ile karşılaştırma yapılmalıdır.

Yetkiler Minimum Seviyede mi?

Tool allowlist review edilmelidir. Service account scope kontrol edilmelidir. Read ve write ayrılmalıdır. Destructive operation varsayılan kapalı olmalıdır. Permission change audit edilebilir olmalıdır.

Hassas Veriler Korunuyor mu?

Data classification yapılmalıdır. Model provider policy incelenmelidir. Log masking test edilmelidir. RAG permission filter doğrulanmalıdır. Memory sensitive data'yı gereksiz saklamamalıdır.

Prompt Injection Testi Yapıldı mı?

Direct ve indirect attack örnekleri denenmelidir. Malicious document ve web content kullanılmalıdır. Agent forbidden tool'a erişememelidir. Data exfiltration attempt test edilmelidir. Findings kapanmadan production write açılmamalıdır.

Kritik İşlemlerde İnsan Onayı Var mı?

High risk action listesi hazırlanmalıdır. Approval UI exact action göstermelidir. Token task specific olmalıdır. Timeout ve rejection behavior test edilmelidir. Approval event audit'e yazılmalıdır.

Maksimum Maliyet ve Adım Limiti Var mı?

Run limits config olarak tanımlanmalıdır. Model loop sınırsız olmamalıdır. Budget aşımında safe stop yapılmalıdır. Multi agent global limit paylaşmalıdır. Alarm threshold production volume'a göre ayarlanmalıdır.

Audit Log Tutuluyor mu?

Identity ve tool event correlation yapılmalıdır. Secret loglanmamalıdır. Write resource ID bulunmalıdır. Retention policy belirlenmelidir. Security team log erişimine sahip olmalıdır.

Evals Çalıştırıldı mı?

Golden dataset güncel olmalıdır. Model ve prompt exact production version ile test edilmelidir. Security eval ayrıca çalışmalıdır. Threshold fail ise release durmalıdır. Sonuçlar release artifact olarak saklanabilir.

Fallback Mekanizması Var mı?

Model veya tool unavailable olduğunda system davranışı bilinmelidir. Human queue fallback olabilir. Critical task silent fail olmamalıdır. Provider fallback data policy açısından onaylı olmalıdır. Düzenli disaster test yapılmalıdır.

Kill Switch Var mı?

Emergency stop kolay erişilebilir olmalıdır. Kimlerin kullanabileceği belirlenmelidir. Write tool ayrı kapatılabilir. Switch operation audit edilir. Tatbikatla gerçek çalışması doğrulanır.

Incident Response Süreci Hazır mı?

On call owner belirlenmelidir. Security ve business escalation path bulunmalıdır. Trace ve audit erişimi hızlı olmalıdır. Token revoke ve tool disable adımları runbook'ta yer almalıdır. Postmortem ve regression update süreci tanımlanmalıdır.

Sık Sorulan Sorular

Şirket İçi Yapay Zeka Ajanları (Agents) Oluşturma Rehberi kapsamında en sık karşılaşılan sorular genellikle agent'ın klasik otomasyondan farkı, şirket verisine bağlantı, güvenlik ve maliyet çevresinde toplanır. Her şirketin teknoloji stack'i ve risk seviyesi farklı olduğu için tek bir doğru framework yoktur. En sağlam ortak yaklaşım küçük scope, least privilege, human approval ve sürekli evaluation kullanmaktır. Kurumsal agent geliştirme danışmanlığı yakınımda gibi arayışlarda da danışmanlık hizmetinin yalnızca demo değil production güvenliği ve ölçüm disiplinini kapsaması önemlidir. Aşağıdaki yanıtlar karar sürecine pratik bir çerçeve sunar.

Şirket içi yapay zeka ajanı nedir?

Şirket içi yapay zeka ajanı belirli business task'ları anlamak ve tamamlamak için şirket verisi ile tool'lara kontrollü erişen yazılım sistemidir. Model agent'ın yalnızca bir bileşenidir. Identity, authorization, RAG, tool calling ve observability birlikte çalışır. Agent kullanıcıdan daha fazla default permission almamalıdır. Production kullanımda human approval ve limits risk seviyesine göre uygulanmalıdır.

AI agent ile chatbot arasındaki fark nedir?

Chatbot çoğunlukla bilgi verir veya belirli intent akışını takip eder. Agent tool kullanarak real system action gerçekleştirebilir. Bu nedenle state ve authorization ihtiyacı daha fazladır. Her chatbot agent olmak zorunda değildir. Basit bilgi soruları için chatbot veya RAG assistant yeterli olabilir.

AI agent ile otomasyon arasındaki fark nedir?

Klasik otomasyon önceden belirlenmiş kuralları takip eder. Agent değişken input ve context'e göre tool veya adım seçebilir. Deterministik işlemde normal otomasyon daha güvenilirdir. Agent yalnızca belirsizlik değer sağladığında kullanılmalıdır. Production system genellikle iki yaklaşımı birlikte kullanır.

Şirket için AI agent nasıl yapılır?

İlk olarak iş problemi ve başarı metriği tanımlanır. Agent'ın tool ve data permission sınırı çizilir. Model, RAG ve integration eklenir. Golden dataset ve human approval ile pilot yapılır. Sonuç kanıtlandıktan sonra production deployment ve monitoring başlatılır.

AI agent yapmak için hangi programlama dili kullanılır?

Python ve TypeScript yaygın seçeneklerdir. C# ve Java enterprise sistemlerde güçlüdür. Dil yerine tool security ve state architecture daha önemlidir. Ekip mevcut production stack'i iyi biliyorsa onu kullanmak avantajlıdır. Framework ve SDK desteği ikinci kriter olarak değerlendirilmelidir.

Kod yazmadan AI agent oluşturulabilir mi?

Evet, no code ve low code platformlarla bazı agent'lar geliştirilebilir. Basit internal workflow için yeterli olabilir. Özel authorization ve high risk integration ihtiyacında custom code gerekebilir. Production security platform default'larına bırakılmamalıdır. Build vs buy TCO ile değerlendirilmelidir.

AI agent şirket verilerine nasıl bağlanır?

Doküman için RAG ve connector kullanılabilir. Transactional data API veya database tool ile okunabilir. SSO identity permission filter'a taşınmalıdır. Her source için data freshness ve ownership bilinmelidir. Agent sadece görev için gerekli verilere erişmelidir.

RAG ve AI agent arasındaki fark nedir?

RAG bilgi retrieval yöntemidir. Agent ise hedefe ulaşmak için RAG yanında tool ve workflow kullanabilen daha geniş sistemdir. Bir bilgi asistanı sadece RAG kullanabilir. Satış agent'ı RAG ile doküman okuyup CRM tool çağırabilir. İki kavram birbirinin alternatifi değildir.

MCP nedir ve AI agent'ta ne işe yarar?

MCP external tool ve context entegrasyonunu standartlaştırmaya yardımcı olan protokoldür. Agent şirket içi MCP Server üzerinden CRM veya Git tool kullanabilir. Server authentication ve authorization sağlamalıdır. Public server otomatik trust edilmemelidir. Protocol güvenlik kontrolünün yerine geçmez.

AI agent güvenli midir?

Doğru architecture ile risk önemli ölçüde azaltılabilir. Prompt injection ve tool abuse tamamen yok olmaz. Least privilege, approval ve validation blast radius'u sınırlar. Security test düzenli yapılmalıdır. Güvenlik model seçimi kadar system design'a bağlıdır.

AI agent KVKK açısından riskli midir?

Kişisel veri işliyorsa KVKK gereksinimleri değerlendirilmelidir. Data minimization ve retention policy uygulanmalıdır. Third party model sağlayıcı incelemesi gerekir. Memory ve log da kişisel veri içerebilir. Hukuki değerlendirme şirketin ilgili uzmanları tarafından yapılmalıdır.

AI agent'a hangi yetkiler verilmelidir?

Yalnızca task için gereken minimum permission verilmelidir. Read ve write ayrılmalıdır. Destructive action insan approval istemelidir. User identity tool layer'a taşınmalıdır. Permission düzenli review edilmelidir.

AI agent yanlış işlem yaparsa ne olur?

Fail safe ve rollback tasarımı bu durum için vardır. Write işlem idempotent ve mümkünse reversible olmalıdır. Critical action approval gerektirir. Incident trace üzerinden analiz edilir. Aynı hata regression test'e eklenir.

Tek agent mı yoksa multi-agent mı kullanılmalı?

İlk tercih genellikle tek agent olmalıdır. Multi agent ancak specialist separation ölçülebilir fayda sağlıyorsa kullanılır. Ek agent maliyet ve latency üretir. Debug ve authorization zorlaşır. Tek agent sınırı evaluation ile kanıtlanmadan architecture büyütülmemelidir.

AI agent nasıl test edilir?

Unit, integration, end to end ve adversarial test birlikte kullanılır. Golden dataset model behavior'ını ölçer. Prompt injection ve permission bypass özellikle denenmelidir. Production incident regression case olur. Load ve cost testleri deployment öncesi yapılmalıdır.

AI agent başarısı nasıl ölçülür?

Task completion, accuracy, groundedness ve tool success önemli metric'lerdir. Human correction ve escalation oranı da izlenir. Cost ve latency business value ile birlikte değerlendirilmelidir. Tek metric bütün kaliteyi göstermez. Use case özel scorecard hazırlanmalıdır.

Şirket içi AI agent'ın maliyeti ne kadardır?

Maliyet task hacmi ve architecture'a göre değişir. Model token, tool API, vector database ve infrastructure kalemleri bulunur. Human approval ve maintenance de hesaba eklenmelidir. Cost per successful task en faydalı metric'lerden biridir. Pilot production volume için gerçek tahmin sağlar.

AI agent ROI'si nasıl hesaplanır?

Önce mevcut süreç baseline'ı ölçülür. Kazanılan saat, error reduction ve cycle time improvement hesaplanır. Agent TCO bu değerden düşülür. Pilot group kontrol grubu ile karşılaştırılabilir. Break even süresi scaling kararına yardımcı olur.

Open source AI agent framework'leri nelerdir?

Agent orchestration için çeşitli açık kaynak framework'ler bulunur. LangGraph, CrewAI ve AutoGen gibi seçenekler farklı pattern'lere odaklanır. Seçim gerçek use case ve maintenance ihtiyacına göre yapılmalıdır. Framework security guarantee değildir. Dependency ve license review yapılmalıdır.

Yazılımcı olmak için AI agent teknolojilerini öğrenmek gerekli mi?

Her yazılımcının agent uzmanı olması zorunlu değildir. Ancak API, LLM ve tool calling kavramlarını anlamak giderek daha faydalı hale gelmektedir. Özellikle backend, platform ve data ekipleri bu sistemlerle daha sık karşılaşabilir. Temel security ve evaluation bilgisi önemlidir. En iyi öğrenme yöntemi küçük production benzeri project geliştirmektir.

Sonuç: Şirket İçi AI Agent Kurmanın En Sağlıklı Yolu

Şirket İçi Yapay Zeka Ajanları (Agents) Oluşturma Rehberi için en önemli sonuç, başarılı kurumsal ajanların model seçimiyle değil doğru iş problemi ve güvenli sistem sınırlarıyla başladığıdır. İlk ajan mümkün olduğunca dar kapsamlı, düşük riskli ve ölçülebilir olmalıdır. Tool Calling, RAG, Memory ve MCP gibi bileşenler gerçek ihtiyaç oldukça eklenmelidir. Kurumsal AI agent geliştirme danışmanlığı yakınımda veya şirketler için özel yapay zeka ajanı geliştirme ve entegrasyon hizmeti arıyorsanız, Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir ve proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz. En güçlü başlangıç, mevcut iş akışınızdan bir pilot seçmek, agent'ın yetkisini minimumda tutmak ve başarıyı production'a geçmeden önce gerçek dataset ile kanıtlamaktır.

Önce İş Problemini Seçin

Teknoloji ile değil business pain point ile başlayın. İnsanların en fazla zaman kaybettiği tekrarlı süreci bulun. Mevcut zamanı ve hata oranını ölçün. Agent'ın yalnızca belirli bölümünü çözmesini sağlayın. Başarıyı pilot öncesinde tanımlayın.

En Az Yetki ile Başlayın

İlk agent read only olabilir. Tool allowlist minimum tutulmalıdır. Kullanıcıdan geniş permission alınmamalıdır. Write işlemi business ihtiyacı kanıtlanınca eklenebilir. Least privilege bütün ölçeklendirme sürecinde korunmalıdır.

Dar Kapsamlı Bir Pilot Kurun

Bir departman ve bir task seçin. Golden dataset oluşturun. Gerçek kullanıcılarla test yapın. ROI ve security metric'lerini aynı anda ölçün. Pilot sonucu scaling kararını belirlesin.

İnsan Denetimini Koruyun

High risk action için human approval devam etmelidir. Kullanıcı agent'ın önerisini kontrol edebilmelidir. Correction data quality improvement için kullanılabilir. Agent yanlışsa durabilmelidir. Automation yüzdesi tek başına başarı metriği değildir.

Evals ve Monitoring ile Güven Oluşturun

Model ve prompt her değişiklikte değerlendirilmelidir. Production trace error'ın nedenini göstermelidir. Cost ve latency izlenmelidir. Security anomaly alarm üretmelidir. Kullanıcı güveni ölçülebilir kaliteyle oluşturulmalıdır.

Sonuç Kanıtlandıktan Sonra Otonomiyi Artırın

Agent önce öneri verir, sonra sınırlı action yapabilir. Human correction oranı düştükçe düşük riskli approval kaldırılabilir. High risk action'da kontrol korunabilir. Otonomi task bazlı artırılmalıdır. Her yeni seviye ayrı evaluation gerektirir.

Tek Agent'tan Kurumsal Agent Platformuna Kademeli Geçin

İlk başarılı agent sonrası ortak tool ve identity katmanı oluşturulabilir. RAG, eval ve observability platform servislerine dönüştürülebilir. Yeni ekipler güvenli template üzerinden geliştirme yapabilir. Multi agent ancak gerçekten gerektiğinde eklenmelidir. Böylece şirket agent projelerini kontrollü, ölçülebilir ve sürdürülebilir biçimde büyütebilir.

Ek Sık Sorulan Sorular

Aşağıdaki sorular şirket içi ajan geliştirmeye başlamak isteyen ekiplerin en pratik karar noktalarını özetler. Teknik başarı kadar yetkilendirme, veri erişimi ve insan sorumluluğu da aynı anda tasarlanmalıdır. İlk pilotun amacı maksimum otonomi değil güvenli ve ölçülebilir değer üretmek olmalıdır. Kurumsal yapay zeka projelerinde özellikle retrieval kaynaklarının ve tool action'larının audit edilebilir olması sonraki ölçeklendirmeyi kolaylaştırır. Şirket İçi Yapay Zeka Ajanları (Agents) Oluşturma Rehberi kapsamında bu sorular karar sürecinde kısa bir kontrol noktası olarak kullanılabilir.

Şirket içi yapay zeka ajanları (AI Agents) nasıl oluşturulur?

Önce agent'ın çözeceği iş problemi, kullanıcı grubu ve başarı metriği tanımlanır. Daha sonra model, izin verilen tool'lar, şirket verisi ve authorization katmanı oluşturulur. RAG gerekiyorsa permission metadata korunan bir retrieval pipeline kurulmalıdır. İnsan onayı, maksimum adım ve maliyet limitleri production öncesinde eklenmelidir. Pilot gerçek kullanıcılarla test edilip eval sonuçları hedefi karşılıyorsa kademeli deployment yapılmalıdır.

Kurumsal AI ajanları hangi iş süreçlerinde kullanılabilir ve mevcut sistemlerle nasıl entegre edilir?

Satış araştırması, müşteri desteği, iç bilgi erişimi, raporlama, onboarding ve yazılım geliştirme yaygın kullanım alanlarıdır. CRM, ERP, database ve doküman sistemleri doğrudan API veya MCP Server üzerinden tool olarak bağlanabilir. Her entegrasyon user identity ve least privilege policy uygulamalıdır. Read ve write operation ayrı tutulmalıdır. İlk entegrasyon mümkün olduğunca düşük riskli ve kolay geri alınabilir süreçten seçilmelidir.

Şirket içi yapay zeka ajanlarında veri güvenliği, yetkilendirme ve gizlilik nasıl sağlanır?

Agent yalnızca kullanıcının zaten erişebildiği data ve tool'lara ulaşmalıdır. Authorization model prompt'unda değil backend policy katmanında uygulanmalıdır. PII minimization, log masking ve memory expiration kullanılmalıdır. Third party model sağlayıcıların retention ve data processing politikaları incelenmelidir. Prompt injection ve cross tenant leakage düzenli security testleriyle doğrulanmalıdır.

AI ajanlarının performansı, doğruluğu ve insan onayı gerektiren işlemleri nasıl yönetilmelidir?

Task Completion Rate, Tool Selection Accuracy, Groundedness, cost ve latency birlikte izlenmelidir. Golden dataset her model ve prompt release'inde regression test olarak çalıştırılmalıdır. Düşük riskli read operation otomatik olabilir. E-posta gönderme, finansal işlem, sözleşme veya destructive action insan approval gerektirebilir. Human correction oranı azaldıkça yalnızca uygun task sınıflarında otonomi kademeli artırılmalıdır.

Şirket içi yapay zeka ajanı geliştirme eğitimi veya danışmanlığını yakınımda nerede bulabilirim?

Kurumsal AI Agent eğitimi yalnızca prompt yazmayı değil RAG, Tool Calling, MCP, Identity, Security, Evals ve Observability başlıklarını birlikte ele almalıdır. Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilirsiniz. Proje ve çalışma alanları için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz. Eğitim veya danışmanlık öncesinde şirketinizdeki aday iş akışlarını, mevcut veri kaynaklarını ve kullanılacak sistemleri listelemek görüşmeyi daha verimli hale getirir. En sağlıklı ilk adım, tek bir gerçek kullanım senaryosunu güvenli pilot olarak tasarlayıp sonuçlarını ölçmektir.