Çalışan bir demo ile üretimde her gün gerçek veriyle işleyen bir sistem farklı şeylerdir; MIT'nin araştırmasına göre kurumsal üretken yapay zeka pilotlarının %95'i ölçülebilir bir kâr-zarar etkisi üretmeden sönümlenir. Pilotu üretime taşımanın önünde dört sessiz duvar vardır. Entegrasyon borcu, veri bataklığı, pilot yorgunluğu ve belirsiz sahiplik. Bir pilot çöktüğünde suç refleks olarak modele yazılmamalı; sonuç model, süreç ve insanın birlikte ürünüdür, önce hangi değişken diye sorulmalıdır. Geçişi belirleyen modelin gücü değil, pilotta ne kadar gerçeklikten kaçtığınızdır.
Çalışan bir demo ile çalışan bir sistem aynı şey değil
Serinin sekizinci yazısında ajanın ne olduğunu, onu kimin kuracağını ve ona ne kadar otonomi verileceğini ele aldım. Ajanı kurdunuz diyelim. Küçük bir ekip, dar bir alan, umut verici bir demo. İşte tam bu noktada serinin en sinsi eşiği başlıyor. Çünkü çalışan bir demo ile üretimde, her gün, gerçek veriyle, gerçek müşteriyle işleyen bir sistem arasında koca bir uçurum var. Bu yazı o uçurumu ve onu nasıl geçeceğinizi anlatıyor.
Rakam bu uçurumun büyüklüğünü gösteriyor. MIT'nin NANDA girişiminin 2025'te yayımladığı araştırmaya göre kurumsal üretken yapay zeka pilotlarının %95'i ölçülebilir bir kâr-zarar etkisi üretmiyor. Dikkat, bu "projeler çöküyor" demek değil. Bu, pilotların büyük çoğunluğunun demoda kalıp bilançoya hiç dokunmadan sönümlendiği demek. Yalnız %5'i hızlı ve gerçek bir gelir etkisine ulaşıyor. Bu yazının amacı sizi o %5'in tarafına geçirmek.
Bu yazının sonunda dört şeyi netleştirmiş olacaksınız. Pilotların neden ölçeğe çıkamadığını, yani hangi sessiz duvarlara çarptığını. Bir pilot sonucunu okurken yapılan en büyük yanılgıyı ve onun panzehiri olan üç değişkenli bakışı. Bir pilotun üretime gerçekten hazır olup olmadığını nasıl anlayacağınızı. Ve bu geçişi kimin, hangi sahiplikle yürüteceğini.
Pilot çıkmazı. Neden demo parlar, üretim çöker
Önce olguyu adıyla koyayım. Sektörde buna "pilot çıkmazı" (pilot purgatory) deniyor. Kurum bir yapay zeka denemesi başlatır, deneme küçük ölçekte güzel sonuç verir, herkes heyecanlanır, sonra o deneme aylarca ne ölür ne üretime geçer. Bir arafta asılı kalır. Bağımsız sektör analizleri kurumsal yapay zeka projelerinin %80'inden fazlasının tam da burada, kanıtlama ile üretim arasında takıldığını gösteriyor.
Bunun neden olduğunu anlamak için demonun neden kolay olduğunu görmek gerekir. Bir pilot, gerçekliğin en zor kısımlarından bilinçli olarak kaçınır. Temiz ve seçilmiş bir veriyle çalışır, tek bir dar senaryoya odaklanır, kurumun karmaşık sistemlerine dokunmaz ve genellikle işin meraklı, istekli birkaç kişisiyle yürür. Üretim ise bunun tam tersidir. Dağınık gerçek veri, sayısız istisna, birbirine bağlı kurumsal sistemler ve isteyeni de istemeyeni de olan koca bir kullanıcı kitlesi. Demo, sınav sorusunun cevabını önceden görmüş öğrenci gibidir. Üretim, sınavın kendisidir.
Bu yüzden "pilot başarılı oldu" cümlesi çoğu zaman yanıltıcıdır. Doğru soru şudur. Pilot, üretimin zorluklarından hangilerini test etti, hangilerinden kaçtı? Kaçtıklarının listesi, aslında sizi bekleyen gerçek işin listesidir. Sonraki bölümlerde bu listeyi tek tek açacağım.
Dört sessiz duvar. Pilotu üretimden ne ayırır
Pilotu üretimden ayıran dört duvar var ve dördü de teknik bir arıza gibi görünmez, o yüzden geç fark edilir.
Birincisi, entegrasyon borcu. Pilot, kurumun gerçek sistemlerine bağlanmadan çalışır. Üretime geçtiğinizde ise ajanı sipariş sistemine, müşteri kaydına, muhasebeye, belge arşivine bağlamanız gerekir. Bu bağlantı katmanı neredeyse her zaman olduğundan çok daha ağırdır. Zorluk mühendislik yeteneği değil, pilotun bilinçli olarak atladığı gerçek sistemlere bağlanmanın birikmiş karmaşıklığıdır. Ben buna entegrasyon borcu diyorum. Pilotta ertelediğiniz her bağlantı, üretimde faturasıyla önünüze gelir.
İkincisi, veri bataklığı. Pilot seçilmiş, temiz bir veriyle çalışır. Üretimde model, serinin hazırlık yazısında konuştuğum kurumun gerçek veri bataklığına düşer. Eksik kayıtlar, çelişen alanlar, güncel olmayan bilgiler. Pilotta %90 isabet eden bir sistem, üretim verisiyle çok daha düşük bir isabete inebilir ve bu bir model arızası değil, veri gerçeğidir.
Üçüncüsü, pilot yorgunluğu. Bu en görünmez ve en tehlikeli olanı. Deloitte'un 2026 kurumsal yapay zeka raporu bunu açıkça adlandırıyor. Art arda takılan pilotlar kurumun iştahını tüketir. Dördüncü pilot, zaten içten içe "burada yapay zeka işe yaramıyor" kararını vermiş bir kuruma iner. Güveni bir kez kaybettiğinizde, sonraki en iyi pilot bile o güvensizliğin gölgesinde başlar.
Dördüncüsü, belirsiz sahiplik. Pilotun bir sahibi vardır, genelde meraklı bir ekip. Ama "bu üretime geçince kim sorumlu, kim bütçe verecek, kim durduğunda müdahale edecek" sorusunun cevabı yoktur. Sahipsiz pilot üretime taşınamaz, çünkü üretime taşımak bir karar ve o kararı verecek kimse yoktur. Sahiplik meselesine ayrı bir bölüm ayıracağım, çünkü başarılı geçişlerin en ayırt edici özelliği bu.
Asıl yanılgı. Pilot çökünce modeli suçlamak
Şimdi serinin en çok işinize yarayacak bölümüne geliyorum. Bir pilot beklendiği gibi sonuç vermediğinde, kurumların neredeyse tamamı aynı refleksi gösterir. "Model yetersizmiş, daha güçlü bir modele geçelim." Bu refleks çoğu zaman yanlıştır ve pahalıdır.
Neden yanlış olduğunu bir rakam net gösteriyor. Boston Consulting Group'un (BCG) yaygın olarak alıntılanan 10-20-70 ilkesine göre yapay zeka değerinin belirleyicisi %10 algoritma, %20 veri ve teknoloji, %70 insan, süreç ve kurumsal dönüşümdür. Yani modelin kendisi, sonucun en küçük kaldıracıdır. Bir pilot çöktüğünde suçu ilk sıraya, yani %10'luk dilime yazmak, sorunun büyük olasılıkla yattığı %90'lık alana hiç bakmamak demektir. MIT araştırması bunu tamamlıyor. İç inşa pilotları dışarıdan alınan çözümlere göre yaklaşık iki kat sık başarısız oluyor ve temel neden modelin gücü değil, "öğrenme açığı", yani sistemin geri bildirimi tutmaması, bağlama uyum sağlamaması.
Buradan benim ÜÇ DEĞİŞKENLİ DENEY dediğim çerçeve çıkıyor. Bir pilot bir sonuç ürettiğinde, o sonuç asla tek başına modele yazılamaz. Sonuç her zaman üç değişkenin birlikte ürünüdür. Model, yani kullandığınız yapay zeka. Süreç, yani ajanı içine yerleştirdiğiniz iş akışı. Ve insan, yani işin başındaki kişilerin okuryazarlığı, deneyimi, denetleme ve yargı becerisi. Pilot iyi sonuç verdiyse üçü birden iyi çalışmıştır. Kötü sonuç verdiyse, arıza bu üçünden hangisinde, bunu bilmeden model değiştirmek karanlıkta ateş etmektir.
Çok pilot, farklı ekip. Teşhisi ve kültürü büyütmek
Üç değişkenli bakışın doğal bir sonucu var ve bu, pilot stratejinizi baştan değiştirir. Tek bir pilot, tek bir yargı üretir. O pilot kötü gittiyse elinizde tek bir veri noktası vardır ve arızanın modelde mi, süreçte mi, insanda mı olduğunu ayıramazsınız. Sonuç genellikle en kolay suçlanana, yani teknolojiye kesilir ve o ekip "yapay zeka bizde tutmadı" karnesiyle kalır.
Çözüm, aynı anda birden fazla pilotu, farklı ekiplerle yürütmektir. Böylece sonuçların birbirinden ayrışması bir teşhis aracına dönüşür. Bir ekipte iyi, diğerinde kötü sonuç veren aynı model, size sorunun modelde olmadığını, farkın süreçte ya da ekipte olduğunu söyler. Tek pilot bir yargıdır, çok pilot bir teşhistir. Bu, ilk ajanı seçerken savunduğum dar ve ölçülebilir başlama ilkesiyle çelişmez. Kastettiğim her şeyi birden otomatikleştirmek değil, aynı sorunu birkaç ekibe aynı anda denetip sonuçlarını kıyaslamaktır.
Bu yaklaşımın ikinci ve daha derin faydası kültüreldir. Farklı ekipler aynı anda denediğinde, aralarında ders paylaşımı başlar. Bir ekibin bulduğu iyi kullanım, diğerine geçer. Bir ekibin düştüğü tuzak, diğerine uyarı olur. Böylece hem kurumun ortak bilgi birikimi büyür, hem her pilotun tek tek başarı şansı artar. Tek pilot bir bahis, çok pilot bir öğrenme sistemidir.
Son bir ilke. Pilotta ekibe düşen görev sadece "aracı kullanmak" değildir, bir gelişim taahhüdüdür. Okuryazarlığını büyütmek, yeni akışa uyum sağlamak ve yönetimi süslü demolarla değil dürüst veriyle beslemek. Bir ekip pilotu bu sorumlulukla üstlendiğinde, sonuç ne olursa olsun kurum kazanır, çünkü ya çalışan bir sistem ya da paha biçilmez bir teşhis elde eder. Bu üç değişkenli bakışı serinin ilerleyen ölçüm ve kültür yazılarında daha da derinleştireceğim.
Üretime hazır mı. Beş boyutlu kontrol
Pilotu üretime taşımadan önce cevaplanması gereken net bir soru var. Bu gerçekten hazır mı, yoksa sadece demoda mı iyi? Bu soruyu duyguyla değil, beş boyutlu bir kontrol listesiyle cevaplayın. Bir pilot ancak beşini birden geçtiğinde üretime hazırdır.
Gerçek veri. Pilot, seçilmiş temiz veriyle değil, üretimdeki gerçek ve dağınık operasyonel veriyle test edildi mi? Kâğıt üstünde çalışan sistem, gerçek veriyle de çalışıyor mu?
Doğrulanmış entegrasyon. Ajan, üretimde bağlanacağı çekirdek sistemlere gerçekten bağlandı mı, yoksa bu bağlantı hâlâ "sonra hallederiz" listesinde mi? Entegrasyon borcu ödenmeden üretim olmaz.
Değişime hazırlık. Bu sistemle çalışacak insanlar hazır mı? Eğitildiler mi, akış onların işine oturuyor mu, dirençleri ele alındı mı? Bu boyutu serinin kültür yazısında ayrıca açacağım.
Belgelenmiş sahiplik. Bu sistemin tek ve net bir sahibi, tanımlı bir kapsamı ve yazılı bir yönetişim çerçevesi var mı? Sahibi olmayan sistem üretime çıkmamalı.
İzleme. Sistem üretimde yanlış yapmaya başladığında bunu yakalayacak bir izleme düzeneği kuruldu mu? Modelin zamanla sapmasını (drift) kim, nasıl fark edecek?
Bu beş boyut aynı zamanda bir dürüstlük testidir. Çoğu takılan pilot, aslında bu sorulardan üçüne "henüz değil" cevabı verilerek üretime itilmiş, sonra o eksikliklerin duvarına çarpmıştır.
Sahiplik. Pilotu üretime kim taşır
Başarılı geçişlerin en ayırt edici özelliği ne güçlü model ne büyük bütçedir. Net sahipliktir. Üretime ulaşan yapay zeka sistemlerinin ortak noktası, tek bir sorumlu sahibinin olmasıdır. Sistemin performansından, kötü gittiğinde alınacak aksiyondan ve nasıl kullanılıp güncelleneceğine dair kararlardan sorumlu, adı belli bir kişi ya da ekip.
Bu sahibin doğru yeri de önemli. Üretim yapay zeka sistemini bilgi işlem ya da veri bilimi ekibi değil, iş tarafından üst düzey bir yönetici sahiplenmelidir. Sahiplik üç şey demektir. Performanstan hesap verebilmek, sistemi durdurma ya da yeniden eğitme yetkisi, ve panoları düzenli gözden geçiren bir yönlendirme grubunu yürütme sorumluluğu. Sahibi iş tarafında olmayan sistem, teknik olarak çalışsa bile bir iş sonucuna bağlanamaz.
Kritik bir zamanlama var. Sahiplik ve yönetişim üretim aşamasına eklenen şeyler değildir, pilotun ilk gününden kurulur. Başarılı kurumlar pilotu başlatırken adı belli bir sahip, işlevler arası bir yönlendirme grubu ve izleme ile insan müdahalesine dair yazılı ilkeler tanımlar. Yönetişimi pilota baştan yerleştirmek, sonradan eklemeye çalışmaktan hem ucuz hem sağlamdır. Bu yüzden geçişi bir teknoloji sorunundan çok bir yönetim ve organizasyon sorunu olarak görmek gerekir.
Ölçek. Entegrasyon borcunu ödemek
Pilotu üretime taşımak, çoğunlukla sanıldığı gibi "aynı şeyi daha büyük yapmak" değildir. Farklı bir işin başlangıcıdır ve bu işin adı entegrasyon borcunu ödemektir. Pilotun bilinçli olarak kaçındığı her şeye, şimdi tek tek bağlanmanız gerekir.
Bunu somutlaştırayım. Pilotta ajan, örnek bir müşteri kaydıyla çalışıyordu. Üretimde binlerce gerçek kayda, üstelik canlı güncellenen bir sisteme bağlanacak. Pilotta tek bir senaryoyu hallediyordu. Üretimde onlarca istisnayı, "peki ya şu durumda" sorusunu karşılayacak. Pilotta hata yaptığında zararsızdı. Üretimde her hatanın gerçek bir maliyeti olacak, o yüzden hata durumunda ne yapacağı da tasarlanmalı. Bu iş, ilk demoyu kurmaktan daha uzun sürebilir ve bu normaldir.
Buradaki yönetici dersi beklentiyle ilgili. Serinin maliyet yazısındaki buzdağını hatırlayın. Görünen model ücretinin altında, entegrasyon ve bakım gibi görünmeyen kalemler yatar. Pilottan üretime geçiş, tam da o su altındaki kalemlerin faturasının geldiği andır. Bunu baştan bütçelerseniz, ölçekleme bir sürpriz değil, planlı bir iş olur. Baştan görmezden gelirseniz, projeniz üretimin eşiğinde "beklenmedik maliyetler" yüzünden durur ve iptal edilen çoğunluğa katılır.
Uygulamadan kültüre. Karar belgesindeki geçiş sütunu
Bu yazıyı üç cümlede toplayayım. Pilot, gerçekliğin zor kısımlarından kaçarak parlar, üretim ise o kısımların hepsiyle aynı anda yüzleşmektir, bu yüzden çalışan bir demo ile çalışan bir sistem farklı şeylerdir. Bir pilot çöktüğünde suç refleks olarak modele yazılmamalı, sonuç model, süreç ve insanın birlikte ürünüdür ve önce hangi değişken diye sorulmalıdır. Ve bir pilot ancak gerçek veri, entegrasyon, değişime hazırlık, sahiplik ve izleme boyutlarını birden geçtiğinde üretime hazırdır.
Karar belgenize bu geçişin sütununu ekleyin. Bu pilotun sahibi, iş tarafından adı belli bir yönetici mi? Pilot, üretimin gerçek verisini ve entegrasyonunu test etti mi, yoksa hangi zorluklardan kaçtı? Sonucu okurken üç değişkeni ayırabiliyor muyuz? Aynı fikri farklı ekiplerle deneyip teşhis üretiyor muyuz? İzleme ve müdahale düzeneği pilotun ilk gününden kurulu mu? Bu soruların yazılı cevabı, sizi demoda parlayıp üretimde sönen çoğunluğun dışına çıkarır.
Ama şu ana kadar hep sistemden, süreçten ve sahiplikten konuştum. Oysa üç değişkenin en belirleyici olanı sonuncusuydu, yani insan. En iyi kurulmuş sistem bile insanlar onu benimsemezse üretimde yaşamaz. "Aracı aldık ama kimse kullanmıyor" tuzağı, pilot çıkmazından bile yaygındır. Serinin bir sonraki yazısında tam da bunu, yani yapay zekayı insanlara benimsetmeyi, direnci aşmayı ve kurum içinde gerçek bir yapay zeka kültürü kurmayı konuşacağım.
Sıkça Sorulan Sorular
Pilotumuz çok iyi çalıştı ama üretime geçince bozuldu, neden?
Çünkü pilot ile üretim farklı zorluk seviyeleridir. Pilot seçilmiş temiz veriyle, tek bir senaryoyla ve kurumun karmaşık sistemlerine dokunmadan çalışır. Üretim ise dağınık gerçek veri, sayısız istisna ve birbirine bağlı kurumsal sistemler demektir. Pilotta %90 isabet eden bir sistem, gerçek veriye ve entegrasyona geçince düşebilir. Bu çoğu zaman bir model arızası değil, pilotun bilinçli olarak kaçtığı gerçekliğin faturasıdır.
"Pilot çıkmazı" (pilot purgatory) nedir, kurumumda olduğunu nasıl anlarım?
Pilot çıkmazı, bir yapay zeka denemesinin ne öldüğü ne de üretime geçtiği, arafta asılı kaldığı durumdur. Belirtileri şudur. Umut verici demolarınız var ama hiçbiri bilançoya dokunmuyor. Yeni pilotlar başlatılıyor ama eskiler bir türlü ölçeğe çıkmıyor. Ve ekiplerde "yine mi yapay zeka" yorgunluğu başlıyor. Bu işaretleri görüyorsanız, sorununuz model değil, üretime geçiş disiplinidir.
Pilot başarısız oldu, daha güçlü bir modele mi geçmeliyiz?
Çoğu zaman hayır, ya da en azından önce değil. Boston Consulting Group'un 10-20-70 ilkesine göre değerin yalnız %10'u algoritmadan gelir; kalan %90'ı veri, süreç ve insandan. Bir pilot çöktüğünde ilk bakılacak yer bu yüzden model değil, süreç ve ekiptir. Sonucu üç değişkene ayırın. Model mi, ajanı yerleştirdiğiniz süreç mi, yoksa işin başındaki insanlar mı? Bunu ayırmadan model değiştirmek, çoğu zaman pahalı ve sonuçsuz kalır.
Bir pilotun üretime hazır olduğunu nasıl anlarım?
Beş boyutlu bir kontrol uygulayın. Gerçek ve dağınık operasyonel veriyle test edildi mi? Üretimde bağlanacağı çekirdek sistemlere gerçekten bağlandı mı? Onunla çalışacak insanlar hazır mı? Adı belli bir sahibi ve yazılı bir yönetişim çerçevesi var mı? Yanlış yapmaya başladığında bunu yakalayacak bir izleme düzeneği kuruldu mu? Beşine birden net "evet" diyemiyorsanız, pilot henüz hazır değildir ve zorla itmek en sık yapılan hatadır.
Kaç pilotu aynı anda yürütmeliyiz, tek bir işe odaklanmak daha iyi değil mi?
Mümkünse birden fazla pilotu farklı ekiplerle yürütün. Tek pilot tek bir yargı üretir ve kötü gittiğinde arızanın modelde mi, süreçte mi, insanda mı olduğunu ayıramazsınız. Sonuç genelde haksızca teknolojiye kesilir. Aynı fikri farklı ekiplerle denediğinizde, sonuçların ayrışması bir teşhis aracına dönüşür ve ekipler arası ders paylaşımı kurum kültürünü büyütür. Tek pilot bir bahis, çok pilot bir öğrenme sistemidir.
Pilottan üretime geçiş ne kadar sürer?
Tek bir rakam yanıltıcı olur, çünkü bu geçiş "aynı şeyi büyütmek" değil, entegrasyon borcunu ödemektir. İyi tanımlı, sahibi belli ve pilotu gerçek veriyle test edilmiş bir sistem birkaç ay içinde üretime geçebilir. Entegrasyondan, sahiplikten ve veri gerçeğinden kaçmış bir pilot ise ya çok daha uzun sürer ya da hiç geçemez. Süreyi belirleyen modelin gücü değil, pilotta ne kadar gerçeklikten kaçtığınızdır. ---