Blog Yazısı Özeti

Yapay zekâ ajanı (AI agent), kendisine verilen bir hedef doğrultusunda adımları planlayan, tanımlı araçları (ERP sorgusu, e-posta taslağı, belge okuma gibi) kullanan ve sonucu kontrol ederek ilerleyen bir yazılım bileşenidir. Sohbet botu soruya cevap verir; ajan ise bir işi başından sonuna yürütmeye çalışır.

Bu yazı, kavramı satıcı dilinden arındırarak anlatıyor: ajanın sohbet botu, RPA ve klasik iş akışı otomasyonundan farkı, bir işletmede ilk ajanın hangi sürece konulabileceği, hangi işlerin ajana hiç verilmemesi gerektiği ve Kişisel Verileri Koruma Kurumu'nun (KVKK) 12 Mart 2026'da duyurduğu "Etken Yapay Zekâ (Agentic AI)" dokümanı ışığında yetki, insan onayı ve kayıt tasarımı. Sonunda kendi sürecinizi puanlayabileceğiniz basit bir ölçek ve kontrol listesi var.

Yapay zekâ ajanı nedir?

KVKK'nın dokümanı, ISO/IEC 22989:2022 standardına dayanarak yapay zekâ aracısını (dokümanın "AI agent" için tercih ettiği karşılık) genel olarak "çevresini algılayan, bu çevreye tepki veren ve belirlenen hedefler doğrultusunda eylemlerde bulunan otomatik bir etmen" diye tanımlıyor. Doküman, "YZ Ajanı" karşılığının da kullanıldığını not ediyor; bu yazıda yaygın kullanım olan "ajan" kelimesini kullanıyoruz.

Üretken yapay zekâ (generative AI) ile farkı da burada: üretken model bir girdiye karşılık metin, görsel veya kod üretir; etken yapay zekâ (agentic AI) ise bu modeli, bir hedefe ulaşmak için adımları planlayıp araç çağıran bir sistemin parçası olarak kullanır.

İşletme diliyle bir ajanın dört özelliği var:

  1. Hedef alır. "Şu müşterinin talebine teklif taslağı hazırla" gibi bir görevle başlar, tek bir soruyla değil.
  2. Araç kullanır. ERP'den fiyat okur, stok sorgular, belge açar, e-posta taslağı yazar. Bu araçların her biri yazılımcının önceden tanımladığı, sınırları belli fonksiyonlardır.
  3. Çok adımlı çalışır. Bir adımın sonucuna göre sonraki adımı seçer: stok yoksa alternatif ürüne bakar, fiyat listesi eskiyse durur ve sorar.
  4. Sonucu kontrol eder. Ürettiği çıktıyı kurallara göre denetler, eksik varsa tamamlamaya çalışır ya da insana devreder.

Sohbet botundan farkı tek cümleyle şudur: sohbet botu bir girdiye bir cevap üretir ve orada durur; ajan bir hedefe ulaşmak için birden fazla eylemi sırayla ve koşullara göre yürütür. KVKK dokümanı da bu ayrımı örnekle yapıyor: çalışanların sorularına şirket el kitabından alıntıyla cevap veren bir sohbet botu, doküman tarafından etken olmayan sistem örneği olarak sayılıyor; çünkü çok adımlı hedef takibi yapmıyor.

Burada önemli bir not: "ajan" bir ürün değil, bir tasarım biçimidir. Aynı işi yapan iki sistemden biri ajan, diğeri basit otomasyon olarak kurulabilir. Doğru soru "ajan alalım mı?" değil, "bu süreç için hangi tasarım yeterli?" sorusudur.

Sohbet botu, RPA, iş akışı otomasyonu ve ajan: fark ne?

Sohbet botu RPA (yazılım robotu) İş akışı otomasyonu Yapay zekâ ajanı
Girdi Kullanıcının sorusu Ekran ve form alanları Yapılandırılmış olay (yeni sipariş, onaylanan form) Serbest metin, belge, birden çok sistemden veri
Karar Cevabın içeriği Yok; kayıtlı adımları tekrarlar Önceden yazılmış kurallar (eğer–ise) Model, tanımlı sınırlar içinde sonraki adımı seçer
Araç erişimi Genelde yalnız bilgi kaynağı Kullanıcı arayüzü üzerinden uygulamalar API ve entegrasyonlar Tanımlı araç seti (API, ERP sorgusu, e-posta taslağı)
Hata davranışı Yanlış veya uydurma cevap Ekran değişince durur Kural dışı durumda hata verir ya da kuyruğa atar Makul görünen ama yanlış bir adım atabilir; hata sonraki adımlara taşınabilir
Denetim Cevap kalitesi kontrolü Çalışma kaydı Akış kaydı ve kural testleri Yetki sınırı, insan onayı, adım adım kayıt
Uygun iş Bilgiye erişim, sık sorulan sorular API'si olmayan eski sistemlere veri girişi Kuralı net, tekrarlı süreçler Girdisi düzensiz, birkaç sistemi birleştiren, yargı gerektiren hazırlık işleri

Tablodaki "hata davranışı" satırı ajan kararında en çok gözden kaçan satırdır. KVKK dokümanı da üretken modellerin gerçeğe uymayan ama ikna edici çıktılar üretebildiğini ve çok adımlı işlerde erken aşamadaki küçük bir hatanın sonraki adımlara taşınıp büyüyebildiğini vurguluyor. Klasik otomasyon hata verip durur; ajan ise yanlış yolda ilerlemeye devam edebilir. Bu yüzden denetim katmanı ajanın kendisi kadar önemlidir.

Hangi araç ne zaman yeter? Kısa karar tablosu:

Durum Önce düşünülecek çözüm
Kural tamamen yazılabiliyor, girdi yapılandırılmış İş akışı otomasyonu
Sistemin API'si yok, adımlar hep aynı ekranlardan geçiyor RPA
İhtiyaç yalnız "doğru bilgiye hızlı erişim" Belgeye bağlı asistan (RAG mimarisi)
Girdi serbest metin, birkaç sistemden veri gerekiyor, sonuç bir taslak ya da öneri Yapay zekâ ajanı

KVKK dokümanı da aynı yönde: sipariş takibi, iade prosedürü veya adres güncellemesi gibi öngörülebilir taleplerde çok adımlı yapılara ihtiyacın sınırlı kalabileceğini, ajan yaklaşımının ise farklı veri kaynaklarını ilişkilendirmeyi ve duruma özgü değerlendirmeyi gerektiren taleplerde öne çıktığını yazıyor.

Bir ajan hangi parçalardan oluşur?

  • Model: Metni anlayan, plan çıkaran ve sonraki adımı öneren dil modeli. Ajanın "beyni" gibi anlatılır ama tek başına hiçbir sisteme dokunamaz.
  • Araçlar: Modelin çağırabildiği fonksiyonlar: "müşteri carisini oku", "stok sorgula", "teklif taslağı oluştur", "e-posta taslağı yaz". Ajanın neler yapabileceğini model değil, bu liste belirler.
  • Bellek ve bağlam: Görevin o ana kadarki adımları, ilgili şirket belgeleri, önceki yazışmalar. Belgeye dayalı bağlam genellikle RAG ile sağlanır.
  • Yönerge: Görevin tanımı, uyulacak kurallar, ne zaman durup insana soracağı. Yazılı ve sürümlü tutulmalıdır.
  • Denetim katmanı: Yetki kontrolü, onay adımı, tutar ve adet sınırları, kayıt ve acil durdurma. Bu katman modelin dışında, kodda çalışır.

Son madde pratikte en kritik olanıdır. "Ödeme yapma" kuralını yalnız yönergeye yazmak bir ricadır; ödeme aracını ajanın araç listesine hiç koymamak ise bir sınırdır. Ajanı güvenli yapan şey modelin iyi niyeti değil, eline verilen araçların ve yetkilerin dar olmasıdır.

İlk ajan için uygun beş süreç

İlk ajan için aranan özellikler dört tanedir: iş tekrarlı olmalı, ajanın yaptığı geri alınabilmeli, gereken veri erişilebilir olmalı ve hata yapıldığında maliyeti düşük olmalı. Aşağıdaki beş süreç bu dört özelliği çoğu işletmede taşır. Genel bir başlangıç çerçevesi için işletmeler için yapay zekâ nereden başlamalı yazımıza da bakabilirsiniz.

  1. Teklif ön hazırlığı. Müşterinin e-postasındaki serbest metin talebi okunur, ürünler ERP'deki kodlarla eşleştirilir, güncel fiyat ve stok okunur, teklif taslağı hazırlanır. Teklifi gönderen satış temsilcisidir. Neden uygun: tekrarlı, taslak silinebilir, veri ERP'de, hatalı taslak insan onayında yakalanır. Sınırların nasıl çizileceğini ERP'ye bağlanan teklif asistanı nasıl sınırlandırılır yazısında ayrıntılı anlattık.
  2. Sipariş durumu sorgusu. Dürüst bir uyarıyla: "Siparişim nerede?" sorusu tek bir sorguyla cevaplanıyorsa ajan gerekmez, basit bir entegrasyon yeter. Ajan, gecikmiş bir siparişte üretim planını, sevkiyat kaydını ve kargo durumunu birlikte okuyup müşteri temsilcisine durumu özetleyen ve cevap taslağı hazırlayan işte anlam kazanır. Neden uygun: veri sistemlerde mevcut, ajan yalnız okur, cevabı insan gönderir.
  3. Bakım kaydı. Teknisyenin serbest notu veya sesli kaydı, arıza kodu, makine ve parça kodlarıyla eşleştirilmiş yapılandırılmış bir iş emri kaydı taslağına dönüştürülür; eksik alan varsa teknisyene sorulur. KVKK dokümanı da teknisyenler için ayrıntılı destek kaydı oluşturan bir destek sistemini etken yapay zekâ örnekleri arasında sayıyor. Neden uygun: tekrarlı, kayıt düzeltilebilir, sonraki analizlerin (kestirimci bakım gibi) veri kalitesini artırır.
  4. Belge sınıflandırma ve eksik takibi. Gelen fatura, irsaliye, sertifika ve sözleşmelerin türünü belirlemek tek başına bir sınıflandırma işidir; KVKK dokümanının örneğindeki spam filtresi gibi etken bir sistem sayılmaz. Ajan, bunun bir adım ötesinde devreye girer: belgedeki alanları ERP kaydıyla karşılaştırır, uyuşmazlığı işaretler, eksik belge için tedarikçiye hatırlatma taslağı hazırlar. Neden uygun: belge kaybolmaz, ajanın önerisi bir kuyruğa düşer, hata ucuzdur.
  5. Tedarikçi takibi. Açık satın alma siparişleri için teslim tarihi teyidi istenir, gelen cevaplar okunur, gecikme riski olan kalemler satın alma sorumlusuna listelenir. Neden uygun: tekrarlı, ajanın çıktısı bir liste ve e-posta taslağı, karar satın almada kalır.

Kendi sürecinizi puanlayın

Aşağıdaki ölçek, bu yazı için önerdiğimiz kaba bir eleme aracıdır; bilimsel bir eşik değildir. Her ölçüte 0, 1 veya 2 puan verin.

Ölçüt 0 puan 1 puan 2 puan
Tekrar Ayda birkaç kez Haftada birkaç kez Her gün, çok sayıda
Geri alınabilirlik Geri alınamaz (ödeme, silme, dışarıya gönderim) Geri alınabilir ama zahmetli Çıktı taslak; onaysız hiçbir şey değişmez
Veri erişimi Veri kâğıtta veya kişilerin aklında Veri var ama dağınık, API yok Veri ERP/CRM'de ve API ile okunabilir
Hata maliyeti Hukuki, finansal veya kişiye etkili sonuç İç düzeltme gerektirir İnsan onayında kolayca yakalanır

Okuma şekli: Geri alınabilirlik 0 ise toplam puan ne olursa olsun o süreç ilk ajan adayı değildir. Toplam 7–8 ise süreç iyi bir adaydır. 5–6 ise önce veri erişimi veya onay akışı üzerinde çalışmak gerekir. 4 ve altıysa ajan için erkendir. Bir uyarı daha: süreç kuralları tamamen yazılabiliyorsa, puanı yüksek olsa bile önce iş akışı otomasyonunu düşünün; daha ucuz ve daha öngörülebilirdir.

Ajana verilmemesi gereken üç iş

Bu, yapay zekânın bu süreçlerde hiç kullanılamayacağı anlamına gelmez. Ajan hazırlık yapabilir, özet çıkarabilir; ama son eylemi ve kararı insan verir.

  1. Geri alınamaz işlemler. Ödeme talimatı, kayıt silme, stok veya cari kaydını kalıcı değiştirme, müşteriye ya da resmî kuruma onaysız gönderim. Ajan ödeme listesini hazırlayabilir; ödeme aracı ajanın araç listesinde olmamalıdır.
  2. Hukuki ve finansal kararlar. Sözleşme hükmünü kabul etmek, kredi limiti açmak, cezai şart uygulamak, iskonto politikası dışına çıkmak. Bu kararların sorumlusu bir kişidir ve gerekçesi kayıtlı olmalıdır.
  3. Kişisel veri ağırlıklı değerlendirmeler. İşe alımda aday eleme, çalışan performansı puanlama, müşteri hakkında profil çıkarma. 6698 sayılı Kanun'un 11. maddesi, verilerin münhasıran otomatik sistemlerle analiz edilmesi sonucunda kişinin aleyhine bir sonuç çıkmasına itiraz hakkını tanıyor. AB Yapay Zekâ Tüzüğü (2024/1689) de işe alım ve aday değerlendirme amaçlı sistemleri Ek III'te yüksek riskli sistemler arasında sayıyor. KVKK dokümanı ayrıca farklı kaynaklardan gelen verilerin birleştirilmesiyle kişiler hakkında öngörülmeyen çıkarımlar ve kapsamlı profiller oluşabileceğine dikkat çekiyor.

KVKK'nın Etken Yapay Zekâ dokümanına göre kontrol listesi

KVKK, 12 Mart 2026'da "Etken Yapay Zekâ (Agentic AI)" başlıklı bir doküman duyurdu. Doküman; etken sistemleri, yapay zekâ aracılarını, kullanım örneklerini, riskleri ve kişisel verilerin korunması açısından dikkate alınabilecek hususları ele alıyor. Kendi ifadesiyle bu hususları "genel hatlarıyla" ele alıyor ve etken yapay zekâ için üzerinde uzlaşılmış tek bir tanım bulunmadığını not ediyor. Aşağıdaki liste dokümandaki başlıkların bizim cümlelerimizle uygulamaya çevrilmiş hâlidir; hukuki görüş değildir. Kendi durumunuz için KVKK uyum sorumlunuza veya hukuk danışmanınıza başvurun.

  • Amaç ve veri listesi yazıldı mı? Ajanın hangi amaçla, hangi veri türlerine eriştiği tek tek listelenmeli. Doküman, ajanların hedefe ulaşmak için gerekenden geniş veri kümelerine erişebileceği riskini amaçla sınırlılık ve veri minimizasyonu ilkeleriyle ilişkilendiriyor (6698 md. 4: "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma").
  • Kapsam kayması izleniyor mu? Pilot sırasında ajana yeni bir veri kaynağı eklenirse, bu kullanımın hangi hukuki sebebe dayandığı yeniden değerlendirilmeli. Doküman, başlangıçta öngörülmeyen veri kullanımlarının işleme şartıyla bağı koparabileceği uyarısını yapıyor.
  • İnsan gözetiminin ne zaman devreye gireceği tanımlı mı? Doküman, insan gözetimini üç aşamada ele alıyor: geliştirmede ajanın hangi veriye erişip hangi kararı verebileceğinin insanlarca tanımlanıp test edilmesi, kullanıma almada yüksek riskli adımlar için ek insan incelemesi, kullanım sonrasında davranışın izlenmesi ve geri bildirim.
  • Her adım izlenebilir mi? Hangi kararın hangi adımda, hangi veriyle ve hangi araçla verildiği sonradan görülebilmeli. Doküman, izlenebilirliğin sınırlı kalmasının yanlılıkların kaynağını bulmayı ve sorumluluğun kimde olduğunu belirlemeyi zorlaştırdığını vurguluyor.
  • Doğruluk kontrolü var mı? Ajanın ürettiği bir bilgi, doğrulanmadan iç sistemlere yazılmamalı. Doküman, hatalı çıktıların otomatik süreçlerle iç sistemlere aktarılıp kişilere ait bilgileri zamanla yanlış güncelleyebileceğini belirtiyor.
  • Roller net mi? Ajanı geliştiren taraf ile onu kendi işinde kullanan taraf (dokümandaki ifadeyle "yerleştirici") arasında görev ve sorumluluklar yazılı olmalı. 6698 açısından veri sorumlusu ve veri işleyen ayrımı, bir ilgili kişi başvurusunun kime geleceği ve ihlalde kimin ne yapacağı sözleşmede netleşmeli.
  • Güvenlik tedbirleri ajana göre güncellendi mi? Doküman, birden çok sistemle bağlantılı çalışmanın saldırı yüzeyini genişlettiğini ve girdilerin manipüle edilerek hassas bilgilerin ifşa ettirilebileceğini yazıyor. 6698 md. 12 de veri sorumlusuna uygun güvenlik düzeyi için teknik ve idari tedbir yükümlülüğü getiriyor.
  • Tasarımdan itibaren mahremiyet uygulandı mı? Varsayılan ayar, her amaç için yalnız gerekli verinin işlenmesi olmalı.
  • Risk değerlendirmesi yapıldı mı? Doküman, uygun durumlarda veri koruma etki değerlendirmesi gibi araçlardan yararlanılmasını öneriyor.
  • Kullanan ekip eğitildi mi? Ajanı kullanan ve işleten kişilerin sistemin sınırlarını ve risklerini bilmesi dokümanda tamamlayıcı tedbirler arasında sayılıyor.

Ajanın içinde bir üretken model çalıştığı için KVKK'nın 24 Kasım 2025 tarihli "Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)" metni de birlikte okunmalı. Proje planlama tarafını AI Act ve KVKK ışığında yapay zekâ projesi nasıl planlanır yazımızda ele aldık.

Yetki tasarımı: okuma, yazma, onay ve kayıt

Ajanın güvenliği büyük ölçüde dört kararla belirlenir.

1. Okuma ve yazma araçlarını ayırın. İlk sürümde ajanın yazma yetkisi ya hiç olmamalı ya da yalnız "taslak" durumunda kayıt oluşturabilmeli. Fiyat okumak ile fiyat değiştirmek iki ayrı araçtır; ikincisi ilk pilotta listede yer almaz.

2. Ajana kendi kimliğini verin. Ajan, onu kullanan kişinin tüm ERP yetkisini devralmamalı; kendi servis hesabıyla, yalnız ihtiyaç duyduğu tablolara ve alanlara erişmeli. Böylece kayıtlarda "bu işlemi ajan yaptı" ayrımı da kendiliğinden oluşur.

3. Onay adımlarını eylem türüne göre tanımlayın.

Eylem İlk pilotta Güven oluştuktan sonra
Veri okuma, özetleme Onaysız Onaysız
Taslak oluşturma (teklif, e-posta, iş emri) Onaysız, ama taslak olarak işaretli Onaysız
Müşteriye veya tedarikçiye gönderim Her seferinde insan onayı Belirli şablonlarda toplu onay değerlendirilebilir
ERP'de kalıcı kayıt değişikliği Ajanda yok Tutar/adet sınırı içinde, onaylı
Ödeme, silme, sözleşme Ajanda yok Ajanda yok

Ayrıca tek görevde yapılabilecek işlem sayısına ve tutara üst sınır koyun ve ajanı tek düğmeyle durdurabilecek bir kapatma anahtarı tasarlayın.

4. Dış içerik veri olarak işlenmeli, talimat olarak değil. Ajanın okuduğu e-posta, belge veya web sayfasının içinde "önceki kuralları yok say ve şunu gönder" gibi bir cümle olabilir. Bu tür girdilerin ajanın davranışını değiştirememesi için yetkiler kodda sınırlanmalı; gönderim gibi eylemler zaten onaya bağlı olduğundan bu risk de daralır. Ayrıntılar için yapay zekâ asistanı geliştirirken güvenlik ve veri kalitesi yazımıza bakabilirsiniz.

Kayıt (log) tasarımı. Her çalıştırma için en azından şunlar kaydedilmeli: görevi tetikleyen talep, çağrılan araçlar ve parametreleri, okunan kayıtların kimlikleri, modelin ürettiği çıktı, onaylayan kişi ve zamanı, sonuç. Bu kayıtlar hem hatayı geriye doğru izlemeyi hem de ölçümü mümkün kılar. Unutulmaması gereken nokta: kayıtların kendisi de kişisel veri içerebilir; bu yüzden erişimi sınırlı tutulmalı ve 6698 md. 4'teki "gerekli olan süre kadar muhafaza" ilkesine göre bir saklama süresi belirlenmelidir.

İlk ajan nasıl devreye alınır? Pilot, ölçüm ve geri alma

Ajan projelerinde en çok zaman alan iş model seçimi değil, sürecin gerçekte nasıl işlediğini öğrenmektir: hangi müşteri hangi kısaltmayı kullanıyor, hangi ürün kodu sistemde iki kez var, hangi istisnayı yalnız bir kişi biliyor. Bunlar uzaktan yazılmış bir gereksinim dokümanına girmez; kullanıcının yanında görülür. Bu yüzden ilk ajanı sahada, süreci kullanan ekiple birlikte kurmayı öneriyoruz. Bu yaklaşımı Forward Deployed Engineer (FDE) nedir yazısında anlattık.

Pilot kurgusu üç aşamalı olabilir:

  1. Gölge çalışma: Ajan önerisini üretir ama hiçbir şey göndermez; ekip işi eskisi gibi yapar ve sonuçlar karşılaştırılır.
  2. Onaylı çalışma: Ajanın taslakları kullanılır, her gönderim insan onayından geçer.
  3. Sınırlı otomasyon: Yalnız ölçümle güvenilir olduğu görülen dar adımlarda onay gevşetilir; geri alınamaz eylemler yine ajanda olmaz.

Ölçüm pilotun başında tanımlanır, sonunda değil. Ajan devreye girmeden önce mevcut durumun ölçülmesi gerekir; yoksa karşılaştırma yapılamaz. Takip edilebilecek göstergeler:

  • İşlem başına harcanan süre (önce ve sonra)
  • Ajan taslaklarının değiştirilmeden onaylanma oranı ve en sık yapılan düzeltme türleri
  • İnsana devredilen görevlerin oranı ve devretme sebepleri
  • Geri alınan veya düzeltilen işlem sayısı
  • Ekibin ajanı gerçekten kullanıp kullanmadığı

Geri alma planı: Ajan kapatıldığında süreç eski hâliyle yürüyebilmeli. Ajanın oluşturduğu kayıtlar ayrı bir etiketle işaretlenmeli ki gerekirse toplu olarak bulunup düzeltilebilsin. Yönerge ve araç setindeki her değişiklik sürüm numarasıyla kaydedilmeli; sorun çıkarsa bir önceki sürüme dönülebilmeli.

Busana olarak bu işi yapay zekâ ve Forward Deployed Engineer hizmetlerimiz kapsamında yürütüyoruz: aday süreçlerin puanlanması, ERP ve e-posta entegrasyonu, yetki ve kayıt tasarımı, pilotun ekibinizle birlikte yürütülmesi. Hangi sürecin ajan için uygun, hangisinin henüz erken olduğunu çoğu zaman kısa bir süreç analizi gösterir; bazen de doğru cevap ajan değil, basit bir otomasyon olur.

Kaynaklar