AI Ajanı Pilotu Production'a Neden Geçmiyor? 5 Tipik Sebep

AI ajanı pilotları production'a ne sıklıkla geçemiyor?

Büyük kısmı geçemiyor. IDC verisinde her 33 pilottan 4'ü production'a ulaşıyor, Gartner da ajan projelerinin %40'tan fazlasının 2027 sonuna kadar iptal edileceğini bekliyor.

İki rakam farklı şeyleri ölçüyor ama aynı yönü gösteriyor. IDC'nin Lenovo ile birlikte yürüttüğü ve CIO dergisinin Mart 2025'te aktardığı araştırma, gözlenen kavram kanıtı projelerinin %88'inin geniş ölçekli kullanıma geçmediğini buldu. Araştırmacılar düşük geçiş oranını kurumsal hazırlık eksikliğiyle açıklıyor: veri, süreç ve BT altyapısı tarafında kurumlar henüz hazır değil.

Gartner'ın 25 Haziran 2025 tarihli açıklaması doğrudan ajanlara odaklanıyor. Öngörülen iptallerin gerekçesi üç başlıkta toplanıyor: artan maliyet, belirsiz iş değeri ve yetersiz risk kontrolü. Açıklamada ajan projelerinin çoğunun heyecanla başlatılmış erken deneyler olduğu, bunun da ajanı ölçekte çalıştırmanın gerçek maliyetini ve karmaşıklığını gözden sakladığı vurgulanıyor. Gartner aynı metinde binlerce "ajan" satıcısından yalnızca 130 kadarının gerçek ajan yeteneği sunduğunu tahmin ediyor. Geri kalanı, mevcut asistan, RPA ve chatbot ürünlerinin yeni adla satılması. Bu ayrımı chatbot ile asistan karşılaştırmasında ayrıca açtık.

Sahada gördüğümüz tablo bu verilerle örtüşüyor. Pilot ekranında ajan etkileyici görünüyor, toplantı olumlu bitiyor, sonra aylar geçiyor. Aşağıdaki beş sebepten her biri tek başına bir pilotu durdurmaya yetiyor. Çoğu projede iki ya da üçü aynı anda duruyor.

Sebep 1: Pilotun başarı ölçütü neden "beğenildi" ile sınırlı kalıyor?

Çünkü ölçüt pilot başlamadan yazılmıyor. Ajanın hangi işte, hangi doğrulukla ve kaç gerçek vaka üzerinde başarılı sayılacağı belli değilse canlıya alma kararı verilemiyor.

Tipik pilot sunumu şöyle ilerliyor: ekip ajana on kadar örnek soru soruyor, cevaplar iyi, herkes etkileniyor. Bu bir demo. Production kararı ise başka bir soru soruyor. Ajan, ayda gelen 800 talebin kaçında doğru işi yapıyor ve yanlış yaptığında ne oluyor?

Bu soruyu cevaplamak için pilot başlamadan iki şey yazılmalı. Birincisi kabul eşiği, yani ajanın hangi doğruluk oranında canlıya çıkacağı. İkincisi ölçüm seti, yani bu oranın hangi gerçek vakalar üzerinde ölçüleceği. Bunlara bir de hataların ağırlığı ekleniyor. Yanlış kategoriye atılan bir talep ile müşteriye gönderilen yanlış fiyat aynı hata sayılmıyor.

Ölçütsüz bir pilotun bitiş tarihi de olmuyor. Her toplantıdan "biraz daha deneyelim" kararı çıkıyor, bütçe yenileme döneminde ise proje kendini savunamadığı için kapanıyor. Yazılımda bu disiplinin adı kabul testi. AI ajanlarında karşılığı değerlendirme seti: gerçek vakalardan oluşan bir liste, her değişiklikten sonra aynı listeyle tekrarlanan ölçüm ve eşiğin altında kalan sürümün yayına çıkmaması. Bizim çalışma biçimimizde bu set kod yazılmadan önce kuruluyor. Başlangıç ölçümünün neden bu kadar belirleyici olduğunu KOBİ AI dönüşümündeki üç hata yazısında anlattık.

Sebep 2: Demo verisi ile gerçek veri arasındaki fark ne kadar büyük?

Çoğu zaman pilotu bitirecek kadar büyük. Demo için seçilen temiz örneklerin yerini production'da eksik, karışık ve beklenmedik talepler alıyor, ajan bu uzun kuyrukta zorlanıyor.

Pilot için veri seçilirken farkında olmadan bir eleme yapılıyor. Kimse ajana en karışık müşteri mailini, yarısı fotoğraf olan belgeyi ya da üç ayrı talebi tek mesajda soran kişiyi göstermek istemiyor. Ajan güzel örneklerle test ediliyor ve güzel sonuç veriyor.

Production'da tablo değişiyor. Talebin çoğu sıradan, ama sorun çıkaran kısım sayıca küçük olan tuhaf vakalar: yanlış yazılmış ürün adı, eksik sipariş numarası, iki dili karıştıran mesaj, eski sistemden kalma tarih biçimi.

Ajanlarda bu etki tek adımlı araçlara göre daha sert, çünkü ajan bir işi birkaç adımda tamamlıyor. Talebi okuyor, müşteriyi buluyor, kaydı kontrol ediyor, cevabı yazıyor. Adımların her biri tek başına iyi çalışsa bile hata payları çarpılarak birikiyor. Adımların birbirinden bağımsız hata yaptığı basit bir varsayımla hesap şöyle:

Her adımda %95 doğrulukla çalışan bir ajan, on adımlı bir işi baştan sona yaklaşık 10 denemenin 6'sında doğru bitiriyor. Demoda bu kayıp görünmüyor, çünkü demoda genelde tek adım gösteriliyor. Gerçek hayatta hatalar her zaman bağımsız olmuyor, bazen birbirini düzeltiyor, bazen büyütüyor. Yön ise aynı kalıyor: adım sayısı arttıkça uçtan uca doğruluk düşüyor.

Bundan iki pratik sonuç çıkıyor. Ajanın ilk sürümü olabildiğince az adımlı tutulmalı. Test seti de gerçek trafikten, tercihen son birkaç ayın ayıklanmamış kayıtlarından seçilmeli. Kişisel veri içeren kayıtlar maskelenerek kullanılabilir. Maskeleme zahmetli bir adım, ama ölçümden vazgeçmek için geçerli bir gerekçe sayılmaz.

Sebep 3: Ajan okumaktan yazmaya geçince ne değişiyor?

Riskin türü değişiyor. Okuyan ajan en kötü ihtimalle yanlış bir özet çıkarır. Yazan ajan yanlış mail gönderebilir, kayıt silebilir, ödeme tetikleyebilir.

Pilotların çoğu güvenli bölgede kalıyor. Ajan veriyi okuyor, öneri hazırlıyor, bir çalışan da öneriyi kopyalayıp sisteme işliyor. Bu düzende yetki sorusu hiç gündeme gelmiyor, çünkü ajan hiçbir şeye dokunmuyor.

Production'da değer yazma yetkisinden geliyor. Talebi CRM'e kendisi kaydeden, randevuyu kendisi açan, cevabı müşteriye kendisi gönderen ajan iş yükünü gerçekten azaltıyor. Aynı anda bilgi işlem ve hukuk ekibinin masasına yeni sorular geliyor. Ajan hangi hesapla bağlanacak, hangi tabloya yazabilecek, geri alınamayan bir işlemi kimin onayıyla yapacak?

Güvenlik tarafında bu riskin bilinen bir adı var. Yazılımcı Simon Willison Haziran 2025'te "ölümcül üçlü" (lethal trifecta) dediği durumu tarif etti: özel veriye erişen, dışarıdan gelen güvenilmeyen içeriği okuyan ve dışarıya mesaj gönderebilen bir ajan, içeriğe gömülmüş bir talimatla veriyi saldırgana göndermeye kandırılabiliyor. Sebebi, dil modellerinin metnin içindeki talimatı operatörün talimatından güvenilir biçimde ayıramaması. Müşteri mailini okuyup cevap yazan bir destek ajanı bu üç özelliği birden taşıyor.

Çözüm, yetkiyi işin gerektirdiği kadarla sınırlamak. Production öncesi dört kontrol yerinde olmalı:

• En az yetki. Ajan yalnızca işi için gereken kayda ve işleme erişiyor, genel yönetici hesabıyla bağlanmıyor.
• Onay kapısı. Geri alınamayan işlemler (gönderim, silme, ödeme) bir insanın onayından ya da kodla yazılmış sabit bir kontrolden geçiyor.
• İz kaydı. Ajanın yaptığı her işlem, hangi girdiye dayandığıyla birlikte kayda geçiyor.
• Üçlüyü bölmek. Dışarıdan içerik okuyan ajan, aynı akışta dışarıya serbest mesaj gönderemiyor. Gönderim ayrı ve kısıtlı bir adımda yapılıyor.

Kendi tarafımızda da kural aynı. Bu blogda yazı hazırlayan ajan yayındaki siteye doğrudan yazamıyor. Hazırladığını ayrı bir dala gönderiyor, yayını ise derleme kontrolünü geçen sabit bir adım yapıyor. Ajan hata yapabilir, kontrolü geçemeyen hatası canlıya çıkamaz.

Sebep 4: Ölçekte maliyet ve gecikme neden sürpriz çıkıyor?

Pilotta maliyet tek bir çağrı üzerinden tahmin ediliyor. Production'da tekrar denemeler, uzayan bağlam ve hacim birleşince aylık fatura bu tahminin birkaç katına çıkabiliyor.

Gartner'ın iptal gerekçeleri arasında artan maliyetin ilk sırada yazılması anlamlı. Pilot döneminde ajan günde birkaç düzine istek işliyor ve fatura önemsiz görünüyor. Hesap da genelde basit bir varsayımla yapılıyor: bir istek, bir model çağrısı, sabit bir birim fiyat.

Ajan bu varsayıma uymuyor. Bir işi bitirmek için modeli birkaç kez çağırıyor, araçtan gelen sonucu okuyor, emin olamadığında yeniden deniyor. Her turda okunan metin büyüyor, çünkü önceki adımlar da bağlama ekleniyor. Takıldığı bir vakada aynı adımı defalarca tekrarlayan ajan, tek bir talep için yüzlerce sıradan talebin maliyetini harcayabiliyor.

Gecikme de aynı kaynaktan çıkıyor. İç raporlama işinde 40 saniye kimseyi rahatsız etmez. Telefonda ya da WhatsApp'ta cevap bekleyen bir müşteri için aynı süre, konuşmanın bittiği an olabilir.

Production öncesi üç ayar yapılmalı:

• Maliyeti iş başına ölçmek. Tek çağrının fiyatı yerine bir talebin baştan sona kapanmasının kaç liraya mal olduğu hesaplanıyor.
• Döngü sınırı koymak. Ajanın bir iş için kaç tur dönebileceği ve ne kadar harcayabileceği kodla sınırlanıyor. Sınır aşılınca iş insana devrediliyor.
• İşi doğru modele vermek. Sınıflandırma gibi basit kararlar için en büyük model gerekmiyor. Önce orta boy tek bir modelle taban ölçülüyor, karmaşık yönlendirme ancak bu tabanı geçerse ekleniyor.

İş başına maliyet bilindiğinde ajanın kazandırdığı süreyle karşılaştırma yapmak kolaylaşıyor. Bu karşılaştırmanın yöntemini yapay zeka ROI hesabı yazısında adım adım gösterdik.

Sebep 5: Pilot bittiğinde ajanın sahibi kim oluyor?

Çoğu projede belirsiz kalıyor. Kuran ekip ayrıldıktan sonra ajanı izleyen ve sonucundan sorumlu bir iş sahibi yoksa sistem birkaç ayda kullanılmaz hale geliyor.

Ajan, kurulup bırakılan bir yazılım gibi davranmıyor. Kullandığı model sağlayıcı tarafından güncelleniyor ve aynı soruya verilen cevap sürümden sürüme değişebiliyor. Müşterilerin sorduğu sorular mevsime, kampanyaya, yeni ürüne göre kayıyor. Bağlandığı sistemde bir alanın adı değiştiğinde ajan hata vermeden yanlış veri okumaya başlayabiliyor.

Bunların hepsi izleme istiyor, izleme de bir sahip. Pilotlarda sık gördüğümüz düzende projeyi bilgi işlem ya da dış bir ekip yürütüyor, iş birimi yalnızca sonucu bekliyor. Pilot bitince teknik ekip başka işe geçiyor. İş birimi ise ajanın hatasını kime bildireceğini bilmiyor.

İşe yarayan düzen iki sponsor istiyor. Biri iş tarafında: ajanın yaptığı işin sonucundan sorumlu olan, ölçütü onaylayan ve "bu çıktı yanlış" diyebilecek kişi. Diğeri yönetim tarafında: bütçeyi koruyan ve proje takıldığında engeli kaldıran kişi. Birincisi eksikse ajan teknik olarak çalışıp kullanılmıyor. İkincisi eksikse kullanılıyor ama ilk bütçe döneminde kesiliyor.

Devir de baştan tasarlanmalı. Ajan hata yaptığında hangi ekranda görünecek, kim düzeltecek, model güncellendiğinde ölçüm setini kim yeniden çalıştıracak? Bu soruların cevabı pilotun ilk haftasında yazılmalı. Son haftaya kalırsa devir çoğu zaman hiç gerçekleşmiyor.

Forward Deployed çalışma modelinin ortaya çıkış sebebi de bu boşluk. Ajanı kuran mühendis işletmenin içinde, gerçek sistemler ve gerçek kullanıcılarla çalışıyor, sistem günlük işe oturana ve iç ekip devralana kadar kalıyor. Nasıl çalıştığımızı hizmetler sayfasında anlattık.

AI ajanı pilotunu production'a hazırlayan kontrol listesi nedir?

Pilot başlamadan beş soruya yazılı cevap vermek: ölçüt, gerçek test verisi, yazma yetkisi, iş başına maliyet ve sahip. Cevapsız kalan her soru production'ı bekletiyor.

Aşağıdaki tablo beş sebebi pilotun ilk haftasında sorulacak sorulara çeviriyor. Son sütun, production kararı verilirken masada olması gereken kanıtı gösteriyor.

Listede model seçimi yok. Hangi modelin kullanılacağı önemli bir karar, ama bu beş sorudan sonra geliyor ve çoğu projede en kolay değiştirilen parça oluyor. İlk ajanın hangi işe kurulacağına henüz karar verilmediyse ilk otomasyon adayını seçme yazısı iyi bir başlangıç noktası.

Bir AI ajanı pilotunu durdurmak ne zaman doğru karar?

Ölçüm süresi dolduğunda doğruluk eşiği tutmuyorsa ya da iş başına maliyet kazandırılan emeği aşıyorsa. Eşikler baştan yazılırsa bu karar birkaç haftalık maliyetle veriliyor.

Her pilotun production'a geçmesi gerekmiyor. IDC'nin 33 pilotta 4 oranının bir kısmı yerinde verilmiş durdurma kararlarından oluşuyor olabilir ve bu sağlıklı bir durum. Asıl sorun, durdurulması gereken pilotun aylarca "biraz daha deneyelim" modunda kalması.

İki durumda durmak mantıklı. İlki, ölçüm süresi dolduğunda gerçek vakalardaki doğruluğun eşiğin altında kalması ve hataların kaynağının kısa sürede düzeltilemeyecek bir veri ya da süreç sorunu olması. İkincisi, iş başına maliyetin ajanın kurtardığı emeğin karşılığını aşması. İkinci durum genelde iş yanlış seçildiğinde ortaya çıkıyor. Hacmi düşük ve her vakası birbirinden farklı bir işi ajanla yapmak, elle yapmaktan pahalıya gelebiliyor.

Durdurmanın da bir bedeli var ve hesaba girmeli. Pilot kapandığında ajanın yapacağı iş elle yapılmaya devam ediyor. Bu işin ayda kaç saate mal olduğu biliniyorsa karar iki rakamın karşılaştırmasıyla veriliyor: ajanın aylık maliyeti ve elle yürüyen işin aylık maliyeti.

Sık sorulan sorular

Beş sebebin ortak noktası, hepsinin pilot başlamadan görülebilmesi. Ölçüt, gerçek veri, yetki, maliyet ve sahiplik ilk haftada yazıya döküldüğünde pilot ya production'a geçiyor ya da erken ve ucuz biçimde durduruluyor. İki sonuç da aylarca askıda kalan bir projeden daha iyi. Diğer yazılara blog sayfasından, çalışma biçimimize hizmetler sayfasından ulaşabilirsiniz.