Ajan tabanlı yapay zekâ projeleri neden iptal ediliyor ve sekiz haftalık pilot uygulama neyi doğru yapıyor?

Bir müşteri para iadesi ister; ajan da CRM’de siparişi bulur, iade politikasını kontrol eder ve bir dakikadan kısa sürede yanıt taslağı hazırlar. Ancak ardından takılır; çünkü iade onayı, ajanın hiçbir zaman bağlanmadığı bir finans sistemindedir ve müşterinin adresi iki veritabanında farklıdır. Bu tür aksaklıklar demoda nadiren ortaya çıkar; oysa ajanın işletme maliyetini ve ona güvenilip güvenilemeyeceğini belirleyen de bunlardır. Bu da ajan tabanlı yapay zekâdaki asıl riskin modelden ziyade ajanın kullanıma alındığı işletmede bulunduğunu gösterir.

Gartner, 2027 sonuna kadar ajan tabanlı yapay zekâ projelerinin %40’tan fazlasının iptal edileceğini öngörüyor; gerekçe olarak artan maliyetleri, iş değerinin net olmamasını ve risk kontrollerinin yetersizliğini gösteriyor. Bu tahmin dikkatle incelendiğinde, projelerin bugün bu işlerin ne kadara mal olduğuna ya da sonuçların sorumluluğunun kimde bulunduğuna dair pek az fikir veren demoların etkisiyle nasıl onaylandığına işaret ediyor.

Herhangi bir yönetim ekibine soracağım soru şu: İşletme, bu ajanın her gün, katlanabileceği bir maliyet ve risk düzeyinde iş yapmasını destekleyebilir mi? Bu soruyu yanıtlamak için, benim otomasyon sonrası iş olarak adlandırdığım, yani ajan kendi payına düşeni tamamladıktan sonra insanların hâlâ yapmak zorunda olduğu her şeyi yakından incelemek gerekir. Sekiz haftalık bir pilot uygulama da tam kapsamlı kullanıma geçmeden önce bunları ölçmenin pratik bir yoludur.

Ajanın İşletmeden Devraldığı Sorunlar

Ajanlar nadiren tek başına çalışır; çünkü basit görünen bir görev bile müşteri kayıtlarına, birkaç iş uygulamasına ve çoğunlukla bir onay aşamasına dokunur. Her bağlantı, ajanın görebileceklerini ve yapabileceklerini sınırlar. Kayıtlar tutarsızsa ya da kimin onay vermesi gerektiği tam olarak bilinmiyorsa ajan, görevle birlikte bu karmaşayı da devralır.

Sorun genellikle rutin durumlar değil, istisnalardır; çünkü operasyon maliyetleri bu noktalarda birikir ve demolar da özellikle bu durumları dışarıda bırakacak şekilde hazırlanır. Deloitte’un 2026 araştırması, kuruluşların yalnızca %5’inin iş süreçlerini yapay zekâ ajanlarına büyük ölçüde hazır gördüğünü ortaya koydu. Bu oran, herhangi bir model kıyaslama sonucundan daha açıklayıcı; çünkü yapay zekânın çoğu süreçten çok önce hazır hâle geldiğine işaret ediyor.

İş Gerekçesi, Otomasyon Sonrası Yapılan İşleri de Kapsamalı

Ajanın ne kadar hızlı çıktı ürettiğini ölçmek, değerini olduğundan yüksek göstermenin en kolay yoludur; çünkü önemli olan, görev tamamlandığında toplamda ne kadar emek gerektiğidir. Bir isteği işlemek çalışanın 20 dakikasını alıyor ve ajan ilk taslağı hazırlama süresini iki dakikaya indiriyor diyelim. Bu, biri sonucu kontrol edip hataları düzeltmek için 15 dakika harcayana kadar 18 dakikalık bir tasarruf gibi görünür. Ajanı çalıştırmanın maliyeti de hesaba katıldığında, üç dakikalık tasarruf pek tatmin edici bir getiri sayılmaz.

McKinsey’in bankacılıkta kullanılan bir müşteri hizmetleri ajanına ilişkin analizi de aynı örüntünün büyük ölçekte geçerli olduğunu gösteriyor: Değişken işletme maliyetlerinin %20–25’ini tokenlar, %70–75’ini ise insan gözetimi oluşturuyordu; dolayısıyla maliyetlerin büyük bölümü model dışındaki kalemlerden kaynaklanıyordu. Kod yazılmaya başlanmadan önce bir başlangıç ölçümü yapılmazsa pilot uygulama, teknik açıdan kayda değer ilerleme sağlayıp yatırımın iş gerekçesini yine de sınanmamış bırakabilir. İşletme sahibinin en azından aşağıdaki soruların her birine net yanıt verebilmesi gerekir:

• Hacim: Süreç ne sıklıkta yürütülüyor ve kaç kişi bu sürece dokunuyor?
• Tamamlanma süresi: Kontrol ve düzeltmeler dâhil, görevin tamamı ne kadar sürüyor?
• Doğruluk: Ne sıklıkta hata yapılıyor ya da işin yeniden yapılması gerekiyor?
• Görev başına maliyet: Bugün başarıyla tamamlanan bir görev ne kadara mal oluyor?
• İş etkisi: Gerçek bir iyileşme müşteriler, çalışanlar ya da işletme için neyi değiştirir?

Ajan, İş Akışında Yerini Hak Etmeli

Benim deneyimime göre benimsenme genellikle değişim yönetimi başlığı altında ele alınsa da, çok daha önce, ajanın iş akışında nereye yerleştirildiğiyle belirlenir. Küresel bir profesyonel hizmetler şirketi, destek ve uyum çalışmaları için ajanlar geliştirmişti. Destek ajanı çeşitli iç sistemlerden bilgi alabiliyordu; ancak çalışanların ajanı kullanmak için ayrı bir uygulama açması gerekiyordu ve çoğu bunu yapmıyordu. Aynı iş akışı mevcut destek platformuna taşınınca ajan, çalışanların zaten üzerinde çalıştığı destek talebinin içinde görünür hâle geldi. Uyum tarama ajanı da benzer biçimde Salesforce’a entegre edildi ve her vaka oluşturulduğunda çalışmaya başladı.

Ajanların kendisinde hiçbir değişiklik olmadı; değişen, iş akışındaki konumlarıydı. Çalışanların bir destek talebi açmak ya da vaka oluşturmak için zaten bir nedeni vardı; ajan tam da o anda karşılarına çıktığında onlardan ekstra bir şey yapmaları istenmiyordu. Bu nedenle ajanın yerleştirileceği noktayı belirlemek, benimsenme kadar bir mimari kararıdır. Ajanın, işin yapıldığı yerde gerekli bağlama erişmesi ve çıktısının biri elle kopyalayıp aktarmadan sonraki adıma iletilmesi gerekir.

Özerklik Güvenlik Hesaplamasını Değiştirir

Yalnızca bilgi okuyabilen bir ajan bir tür risk taşırken kayıtları değiştirebilen ya da müşterilere e-posta gönderebilen bir ajan bambaşka bir risk taşır. Bu nedenle kontroller, ajanın gerçekte neler yapmasına izin verildiğine göre belirlenmelidir. Aşırı yetkilendirme ve hassas verilerin sızması bilinen risklerdir; ancak en yakından dikkat edilmesi gereken konu istem enjeksiyonudur: Ajanın, tamamen meşru bir işi yaparken okuduğu bir belgeye ya da e-postaya gizlenmiş talimatlar.

Gartner’ın ajan yönetişimine ilişkin Mayıs 2026 tarihli kılavuzu, özerkliği dört düzeye ayırarak kontrollerin ne kadar sıkı olması gerektiğine karar vermek için pratik bir yol sunuyor:

1. Gözlemleme: Ajan, salt okunur erişimle bilgi toplar ve örüntüleri belirler.
2. Tavsiye: Ajan bir eylem önerir, kararı ise bir çalışan verir.
3. Onayla eyleme geçme: Ajan, bir kişinin yürürlüğe girmeden önce onaylaması gereken bir eylemi hazırlar veya başlatır.
4. Özerk biçimde eyleme geçme: Ajan, belirlenen sınırlar içinde onaylanmış eylemleri kendi başına gerçekleştirir; istisnalar izlenir ve üst mercilere iletilir.

Her düzeyde ajanın kendine ait bir kimliği, görevle sınırlı izinleri ve gerçekleştirdiği her eylemin kaydı olmalıdır. Kuruluşların ayrıca verilerin nasıl işleneceğine ve saklanacağına ilişkin kurallara, hangi bilgilerin dış model sağlayıcılarına ulaştığı konusunda açıklığa ve bir sorun belirtisi görüldüğü anda ajanı duraklatıp erişimini kaldırma yetkisine sahip bir kişiye ihtiyacı vardır.

Bu kontrollerin her birinin sürekli bir maliyeti vardır; çünkü daha geniş izinler, ek izleme ve sık onaylar zaman içinde maliyeti artırır. Dolayısıyla uygun özerklik düzeyini belirlemek, güvenlik kadar ekonomik bir karardır ve ajanın, işletmenin kabul edebileceği bir risk düzeyinde kayda değer sonuçlar sağladığı noktada belirlenir.

Ajan Kullanımını Haklı Çıkarabilecek Bir Süreç Seçin

Pek çok ekip işe teknolojiyle başlayıp bir sorun arıyor; oysa daha iyi bir başlangıç noktası, maliyeti ya da yarattığı gecikmeler işi yapan kişiler için zaten açık olan bir süreçtir.

Birlikte çalıştığımız küresel bir uzman ağı şirketi bu tanıma uyuyordu: Şirketin ekibi, birbirleriyle iletişim kurmayan üç sistemdeki anket taleplerini uzmanlarla eşleştiriyor, her eşleştirme için profilleri, geçmiş katılımları ve uyumluluk durumunu elle kontrol ediyordu. Anlamsal aramayı katılım geçmişi ve uyumluluk kurallarıyla birleştiren bir ajan geliştirdik. Üretim ortamında eşleşme hatalarına ilişkin bildirimler %80 azaldı, eşleştirme doğruluğu %40 arttı ve ekip kapasitesinin %22’sini geri kazandı.

Proje başarılı oldu; çünkü sorun net biçimde tanımlanmıştı: Bilgiler dağınıktı, bunları elle bir araya getirmek gerekiyordu ve eşleştirme kalitesi uygulama öncesinde ve sonrasında ölçülebiliyordu. Sorunun net tanımlanması, bir süreç için ajana gerçekten ihtiyaç olup olmadığını yanıtlamaya da yardımcı olur. Sabit kurallara tabi işler genellikle geleneksel otomasyonla daha düşük maliyetle yürütülür. Ağırlıklı olarak bilgi bulma ve özetleme gerektiren işler içinse çoğu zaman bir yapay zekâ asistanı yeterlidir. Buna karşılık, iş bağlamı okumayı, izin verilen eylemler arasında seçim yapmayı ve bir sonuca ulaşmak için birden fazla adımı birbirine bağlamayı gerektiriyorsa ajanların ek maliyet ve riskini göze almaya değer.

Net Karar Noktaları İçeren Sekiz Haftalık Pilot

Pilotun tamamı tek bir ticari soruya dayanır: Bu ajan, süreci büyük ölçekte çalıştırmayı haklı çıkaracak kadar iyileştirebilir mi? Sekiz hafta; iş gerekçesini, teknolojiyi ve kuruluşun geliştirdiği sistemi yönetme becerisini sınamak için yeterli zaman sağlar.

1–2. Haftalar: Nelerin İyileştirilmesi Gerektiğini Belirleyin

İşe, sürecin bugün nasıl yürütüldüğünü belgeleyerek başlayın; işlem hacminden tamamlanma süresine, hata oranlarından yeniden çalışma ve maliyete kadar her şeyi kaydedin. Sürece hangi sistemlerin dahil olduğunu, her aşamadan kimin sorumlu olduğunu ve hangi istisnaların insan müdahalesi gerektirdiğini not edin. Ardından iş biriminin sorumlusu ile teknik ekibin, ajanın iyileştirmesi beklenen tek bir sonuç üzerinde anlaşmasını sağlayın. Karar noktası: Sorun, başlangıç değerleri, sorumlu kişi ve başarı ölçütleri netleştiğinde devam edin.

3. Hafta: Ajanın Sınırlarını Belirleyin

Ajanın kimliği, izinleri, verilere erişimi, kullanmasına onay verilen araçlar ve özerklik derecesi dahil olmak üzere sınırları bu aşamada belirlenir. Ajanı istem enjeksiyonu, yetkisiz erişim, hassas verilerin açığa çıkması ve araçların kötüye kullanılması durumlarına karşı sınayın. Günlük kaydı ve olay müdahale süreçlerini oluşturmanın yanı sıra ajanı askıya almanın veya erişimini iptal etmenin bir yolunu da belirleyin. Karar noktası: Kontroller ve müdahale adımları gerçekten sınandıktan ve herkes ajanın neler yapmasına izin verildiğini anladıktan sonra devam edin.

4–6. Haftalar: Demoyu Başarısızlığa Uğratan Koşulları Sınayın

Şimdi ajana eksik kayıtlar, çelişkili bilgiler, alışılmadık talepler ve ara sıra yaşanan sistem arızaları dahil gerçekçi işler verin. Tamamladığı görev sayısını, doğruluk düzeyini ve insanların ne kadar düzeltme yapmak zorunda kaldığını izleyin. Ardından model kullanımını, entegrasyonları, izlemeyi ve incelemeyi de hesaba katarak başarıyla tamamlanan bir görevin gerçek maliyetini hesaplayın. Karar noktası: Ajan üzerinde anlaşılan eşikleri karşıladığında ve ekip hem işletme maliyetini hem de başarısız olduğu durumları anladığında canlı testlere geçin.

7–8. Haftalar: Ajanı Gerçek Kullanıcıların Karşısına Çıkarın

Ajanı küçük bir çalışan grubunun kullanımına sunun ve gerçek işlerin sınırlı bir bölümünde deneyin; ajanın üstesinden gelemediği durumlar için eski süreci kullanmaya devam edin. İnsanların ajanı gerçekten kullanıp kullanmadığını, işlerini kolaylaştırıp kolaylaştırmadığını ve ürettiklerine güvenip güvenmediklerini gözlemleyin.

Pilotun sonunda sonuçları ilk haftadaki başlangıç değerleriyle karşılaştırın; üretkenliği, doğruluğu, benimsenme düzeyini, insanların ne sıklıkla müdahale etmek zorunda kaldığını, toplam işletme maliyetini ve halen çözülmemiş güvenlik risklerini değerlendirin. Sonrasında ölçeklendirme, belirli eksikleri giderip yeniden sınama ya da projeyi durdurma kararı verilir. Ajanın bu iş için fazla pahalı veya güvenilmez olduğunu gösteren bir pilot da amacına ulaşmış demektir; çünkü varsayımlara dayalı, çok daha büyük bir yatırımın önüne geçmiştir.

Sonuçları ölçün, ardından ne kadar özerklik tanıyacağınıza karar verin

Bir ajanın işlediği görev sayısını ölçmek pek bir şey ifade etmez; çünkü bir sistem binlerce isteği işleyip çalışanlara bunların çoğunu doğrulatmaya, düzeltmeye ya da tamamlatmaya devam edebilir. Başarıyla tamamlanan görev başına maliyetin doğruluk ve istisna oranlarıyla birlikte değerlendirilmesi, sürecin baştan sona iyileşip iyileşmediğini çok daha iyi gösterir.

Aynı ölçütler, ajana daha fazla hareket alanı tanımanın da gerekçesini oluşturur. Üzerinde uzlaşılan sınırlar içinde rutin istekleri güvenilir biçimde karşılayan bir ajana bunları kendi başına yerine getirme yetkisi verilebilir. Belirsiz durumlarla sık sık karşılaşan bir ajanın kararlarını ise bir insan onaylamaya devam eder; elde edilen kanıtlar arttıkça izinler de gözden geçirilir.

İşletme ajanı destekleyebilecek durumdaysa ölçeği büyütün

Bir ekipte iyi çalışan bir ajan er ya da geç diğer departmanlarla, uygulamalarla ve onay süreçleriyle de ilgilenmek zorunda kalacaktır. Ölçeği büyütmek için net sorumluluklar, tutarlı erişim denetimleri ve istisnaları ele alacak bir yöntem gerekir. Ayrıca çevresindeki süreçler değiştikçe ajanı güncel tutmak için bütçe ayrılmalıdır.

Tüm bunların temelindeki karar, kuruluşun ne kadar sorumluluğu devretmeye hazır olduğudur; bu karar etkileyici bir demoya değil, gerçek işlerden elde edilen kanıtlara dayanmalıdır. Liderler sekiz haftanın sonunda ajanın neleri yapabildiğini, hangi noktalarda insanların hâlâ devreye girmesi gerektiğini ve işletme maliyetini bilmelidir. Ajan tabanlı yapay zekâda öne geçecek kuruluşlar, ilk haftadan itibaren otomasyon sonrasındaki işleri planlayan ve ajanlara yalnızca gerçekten tamamladıkları görevler için kaynak ayıranlar olacaktır.