Saha Notu: Pilotta Kalan AI Projelerinin Üç Ortak Nedeni

Pilot projesi başarısızlığı, kurumsal yapay zekada en sık ama en yanlış teşhis edilen sorundur: bir pilot teknik olarak çalışır, demoda herkesi etkiler, sonra üretim ölçeğine hiç geçemeden söner. Bu saha notu, onlarca kurumsal AI girişimini izlemiş bir danışman gözüyle, bu başarısızlığın tesadüf olmadığını ve neredeyse her seferinde aynı üç nedene dayandığını gösterir.

Damıtılmış saha deneyimi tek bir teşhisi öne çıkarır: pilot projesi başarısızlığı, bir teknoloji sorunu değil, baştan alınmamış üç kararın gecikmiş faturasıdır. Bu üç neden — başarı ölçütünün tanımsızlığı, destek yoğunluğunun seyrelmesi ve entegrasyon borcunun ertelenmesi — birleşerek bir pilot ölçek uçurumu yaratır; pilot etkileyici kalır ama üretim hiç gelmez. Konunun derinlemesine ve uçtan uca işlendiği kapsamlı rehber bu geçişin tüm aşamalarını ele alır; bu yazı ise saha gözlemiyle o üç nedene odaklanır.

Tanım

Pilot projesi başarısızlığı

Bir yapay zeka pilotunun teknik olarak çalışmasına rağmen üretim ölçeğine hiç geçememesi ve beklenen değeri üretmeden sönmesi durumu. Saha deneyimi bu başarısızlığın rastgele değil, tekrar eden üç nedenden doğduğunu gösterir: başarı ölçütünün baştan tanımlanmaması, pilottaki yoğun desteğin üretimde seyrelmesi ve entegrasyon borcunun ertelenmesi. Bu nedenler bir pilot ölçek uçurumu yaratır ve bir yaygınlaştırma kapısıyla erkenden önlenebilir.

Ayrıca: poc cehennemi, yaygınlaştırma engeli, pilot ölçek uçurumu, pilottan üretime geçememe

En kafa karıştırıcı örüntü şudur: pilot başarılı ilan edilir, ama üretimde çöker. Nedeni, "başarı"nın demoyla ölçülmesidir. Kontrollü bir ortamda, seçilmiş verilerle, birkaç istekli kullanıcıyla yapılan bir gösteri herkesi heyecanlandırır; oysa bu koşulların hiçbiri üretimde geçerli değildir. Gerçek veri daha dağınıktır, gerçek kullanıcı daha çeşitlidir, gerçek yük daha ağırdır. Demoda parlayan çözüm, bu üç baskı altında sessizce dağılır.

Bu çöküşün kurumsal adı bir pilot ölçek uçurumudur: pilotun kontrollü başarısı ile üretimin gerçek koşulları arasındaki, çoğu ekibin tahmininden kat kat büyük olan mesafe. Bu uçuruma düşen bir kurum çoğu zaman yeni bir pilot dener, o da geçmez ve ortaya bir PoC cehennemi çıkar — etkileyici demoların biriktiği ama hiçbirinin üretime dönüşmediği kısır döngü. PoC cehennemi, tek tek pilotların değil, pilotu tasarlama biçiminin başarısızlığıdır.

Bu çöküşün altında yatan asıl mesele, pilotun "gösteri yapmak" için mi yoksa "üretime geçmek" için mi tasarlandığıdır. Gösteri için tasarlanan bir pilot, en etkileyici anını demoda yaşar ve orada biter. Üretim için tasarlanan bir pilot ise en baştan gerçek veriyle, gerçek yükle ve bir çıkış kapısıyla kurulur. Aşağıdaki üç neden, tam olarak bu ayrımın nerede ve nasıl kırıldığını gösterir. Bu başarısızlığın kurumsal maliyetini yapay zeka yatırımlarında başarısızlık nedenleri yazısında ele alıyoruz.

Üç nedenin en sinsisi, başarı ölçütünün hiç tanımlanmamasıdır. Pilot "çalışıyor gibi" hissiyle yürür; ama "çalışıyor" bir his değil, bir sayı olmalıdır. Ölçülebilir bir eşik yoksa, pilot ne başarılı ne başarısız ilan edilebilir — belirsizlikte asılı kalır. Ve bu belirsizlik iki yönlü zarar verir: değeri kanıtlayamazsınız, ama zayıflığı da fark edemezsiniz.

Sorun, ölçütün genellikle demodan sonra, geriye dönük aranmasıdır. Oysa başarı ölçütü pilottan önce yazılmalıdır: hangi metrik (doğru yanıt oranı, kazanılan süre, çözüm oranı), hangi eşikte, hangi temel çizgiye (baseline) göre. Baseline alınmadıysa "ne kadar iyileştik" sorusu havada kalır; eşik yazılmadıysa herkes kendi başarısını kendi tanımlar. Ölçütü nesnelleştirmenin çerçevesini yapay zeka ROI nasıl hesaplanır ve önceliklendirmeyi AI use-case önceliklendirme matrisi yazısında somutlaştırıyoruz.

Somut bir örnek (illustratif): bir kurumda müşteri destek asistanı pilotu "harika çalışıyor" diye sunulur; ama kimse "kaç soruyu insana devretmeden çözdü" sorusunu baştan bir eşiğe bağlamamıştır. Üretime geçildiğinde bu oran ilk kez ölçülür ve kabul edilemez olduğu görülür — oysa aynı eşik pilottan önce yazılsaydı, karar aylar önce ve çok daha ucuza verilebilirdi. Ölçüt yalnızca başarıyı tartmaz; kararın maliyetini öne çeker ve pilot projesi başarısızlığını, henüz ucuzken görünür kılar.

İkinci neden daha az konuşulur ama en az birincisi kadar belirleyicidir: pilotu ayakta tutan yoğun elle destek, üretimde sürdürülemez. Bir pilotta genellikle bir uzman sürekli devrededir — veriyi elle hazırlar, hataları anında düzeltir, kullanıcıya birebir yardım eder. Bu görünmez emek, pilotun "pürüzsüz" görünmesini sağlar; ama gerçek performansı değil, desteğin yoğunluğunu ölçer.

Üretime geçildiğinde bu destek zorunlu olarak seyrelir: aynı uzman binlerce kullanıcıya birebir yetişemez. Ve destek seyreldiği anda sistem, gerçek koşulun ne olduğunu ilk kez gösterir. Pilotta insanın kapattığı boşluklar — kenar durumlar, kötü veri, beklenmedik sorular — üretimde açıkta kalır. Bu yüzden bir pilotun gerçek testi, en iyi gününde değil, desteğin çekildiği gününde yapılır. Bu operasyonel sürdürülebilirliğin altyapısını MLOps nedir ve LLMOps nedir yazılarında ele alıyoruz.

Olgun yaklaşım, pilotu baştan "desteksiz" senaryoyla sınamaktır: sistemin, elle taşıma olmadan ne kadar ayakta kaldığını ölçmek. Eğer pilot yalnızca sürekli müdahaleyle çalışıyorsa, o pilot aslında hazır değildir; yalnızca hazır görünmektedir. Bu ayrımı erken görmek, aylar sonra üretimde yaşanacak bir çöküşü baştan önler.

Üçüncü neden en pahalı olanıdır: entegrasyon, güvenlik ve veri borularının "sonra hallederiz" diye ertelenmesi. Pilot bilinçli olarak sadeleştirilmiş bir ortamda kurulur — veri elle hazırlanır, kimlik doğrulama atlanır, tek bir sistemle konuşulur. Bu sadeleştirme pilotu hızlandırır; ama gerçek entegrasyon hiç kurulmadığı için görünmeyen bir teknik borç birikir.

Bu borç üretime geçilmek istendiğinde bir anda faturaya döner. Gerçek veri boru hattı, erişim kontrolü, güvenlik, izleme ve mevcut sistemlerle entegrasyon — bunların hepsi ertelenmişse, ortaya çoğu zaman pilotun kendisinden daha büyük bir iş çıkar. İşte bu ödenmemiş borç, bir yaygınlaştırma engeli halini alır: pilot teknik olarak çalışsa bile, onu üretime bağlayacak boru hattı yoktur. Bu yaygınlaştırma engeli, çoğu kurumun "demo hazır ama bir türlü canlıya alamıyoruz" dediği yerdir. Erişim ve uyum katmanının neden baştan tasarlanması gerektiğini kurumsal yapay zeka stratejisi nasıl oluşturulur yazısında değerlendiriyoruz.

Olgun ekipler entegrasyonu pilotun sonuna değil, tasarımına koyar: en azından bir "ince ama gerçek" uçtan uca bağlantı kurar, böylece borç görünür kalır ve büyümeden ödenir. Bu geçişin nerede kırıldığını yapay zeka olgunluk modeli çerçevesinde inceliyoruz.

Bu üç nedeni önlemenin en pratik yolu, sezgiye değil bir kapıya dayanmaktır. Yaygınlaştırma kapısı, bir pilotu üretime taşımadan önce karşılanması gereken altı nesnel kriterden oluşan bir eşiktir; altısı da "evet" değilse pilot üretime alınmaz. Bu kapı, geç/geçmez kararını kişisel heyecandan çıkarıp kanıta bağlar ve yukarıdaki üç nedeni sistematik olarak yakalar.

Yaygınlaştırma kapısı: pilotu üretime taşımadan önce karşılanması gereken 6 kriter

#	Kriter	Neyi kanıtlar
1	Yazılı ve karşılanmış başarı ölçütü	Başarı bir his değil, temel çizgiye göre bir sayı
2	Gerçek veri hacmi ve kullanıcı çeşitliliğiyle doğrulama	Demo koşulu değil, üretim koşulu
3	Destek seyreltilince korunan kararlılık	Elle taşımaya bağımlı değil
4	Tamamlanmış entegrasyon, güvenlik, veri boru hattı	Ertelenmiş teknik borç yok
5	Ölçekte sürdürülebilir birim maliyet	Büyüyünce bütçeyi patlatmaz
6	Atanmış üretim sahibi + izleme/geri bildirim	Canlıda kimin baktığı ve nasıl ölçüldüğü belli

Bu altı kriterin gücü, üç nedeni doğrudan hedeflemesindedir: 1. ve 2. kriter ölçüt belirsizliğini, 3. kriter destek seyrelmesini, 4. ve 5. kriter entegrasyon borcunu ve maliyeti, 6. kriter ise sahiplik ve sürdürülebilirliği kapatır. Kapıyı bir engel değil, bir güvence olarak düşünün: geçen pilot, üretimde çökmeyecek pilottur. Kurumsal bir projeyi bu kapıyla üst yönetime sunmanın yolunu üst yönetime yapay zeka projesi sunumu yazısında ele alıyoruz.

Kapıyı işletmek için biçimsel bir tören gerekmez; tek bir toplantı ve altı satırlık bir kontrol listesi yeter. Her kriter için "evet/hayır" ve kanıtı — hangi sayı, hangi test, hangi tarih — yazılır; tek bir "hayır" bile pilotu üretime değil, eksiğini kapatmaya geri gönderir. Kritik olan, kararın kişiye değil listeye ait olmasıdır: böylece "çok emek verdik, geri dönmek günah olur" duygusu, üretimde çökecek bir pilotu geçiremez. Kapı, saha deneyiminin en pahalı dersini tek bir eşikte kurumsallaştırır.

Bu saha notunun taşıdığı mesaj umut vericidir: pilot projesi başarısızlığı tekrar ettiğine göre, önlenebilir de demektir. Üç neden bilindiğinde, her yeni pilotta sıfırdan başlamak yerine bilinen tuzakları önceden görebilirsiniz. Asıl beceri yeni bir çözüm icat etmek değil, pilotu daha ilk günden bu üç nedene karşı bağışık tasarlamaktır.

Damıtılmış saha deneyimi üç tekrarlanabilir dersi öne çıkarır. Birincisi: başarıyı bir his değil, temel çizgiye bağlı bir sayı olarak baştan tanımlayın. İkincisi: pilotu en iyi gününde değil, desteğin çekildiği gününde sınayın. Üçüncüsü: entegrasyonu pilotun sonuna değil, tasarımına koyun. Bu üç ders, dağınık deneyimi bir yaygınlaştırma kapısına dönüştürür ve pilotu bir PoC cehennemi döngüsünden çıkarıp üretime taşınabilir bir hatta oturtur.

Benzer kurumsal kalıpların tekrar ettiğini kurumsal AI dönüşüm kalıpları saha notu yazısında da görebilirsiniz. Eğer bir pilotunuz aylardır üretime geçemiyorsa ya da yeni bir pilota başlamadan bu üç nedene düşmemek istiyorsanız, birlikte bakalım: kurumunuza özel bir yaygınlaştırma kapısı ve yol haritası için danışmanlık görüşmesi ile başlayabilir, kavramların tümünü öğrenme merkezinde derinleştirebilirsiniz.

AI pilotları neden ölçeklenmiyor?

AI pilotları çoğunlukla teknoloji yetersizliğinden değil, üç tekrar eden nedenden ötürü ölçeklenmez. Birincisi, başarı ölçütü baştan tanımlanmadığı için pilot "çalışıyor gibi" hissiyle başarılı sayılır; ölçülebilir bir eşik olmadan üretim kararı sezgiye kalır. İkincisi, pilotta işi yürüten yoğun elle destek üretimde sürdürülemez; destek seyreldiğinde sistem gerçek koşulda çöker. Üçüncüsü, entegrasyon ve veri boruları "sonra hallederiz" diye ertelenir ve pilot ile üretim arasında ödenmemiş bir teknik borç birikir. Bu üçü birleşince ortaya bir pilot ölçek uçurumu çıkar; pilot etkileyicidir ama üretime hiç geçemez. Bu yüzden pilot projesi başarısızlığı, aslında baştan alınmamış kararların gecikmiş faturasıdır.

Pilot ne zaman başarılı sayılır?

Bir pilot, demoda etkileyici göründüğü için değil, üretim koşullarında önceden yazılmış bir başarı ölçütünü karşıladığı için başarılı sayılmalıdır. Bu ölçüt üç şeyi içerir: gerçek kullanıcıyla ve gerçek veri hacmiyle ölçülmüş bir sonuç metriği (örneğin doğru yanıt oranı veya kazanılan süre), önceden alınmış bir temel çizgiyle (baseline) karşılaştırma ve destek seyreltildiğinde bile korunan bir kararlılık. Yani "çalışıyor" bir his değil, bir sayıdır. Ölçüt baştan tanımlanmadıysa pilot ne başarılı ne başarısız ilan edilebilir; belirsizlikte asılı kalır ve bu belirsizlik, pilot projesi başarısızlığının en yaygın gizli nedenidir.

Yaygınlaştırma kapısı kriterleri neler?

Yaygınlaştırma kapısı, bir pilotu üretime taşımadan önce karşılanması gereken altı nesnel kriterden oluşur: (1) önceden yazılmış ve karşılanmış bir başarı ölçütü; (2) gerçek veri hacmi ve kullanıcı çeşitliliğiyle doğrulanmış performans; (3) destek seyreltildiğinde korunan kararlılık (elle taşımaya bağımlı olmama); (4) tamamlanmış entegrasyon, güvenlik ve veri boru hattı (ertelenmiş teknik borç yok); (5) birim maliyetin ölçekte sürdürülebilir olması; (6) atanmış bir üretim sahibi ve izleme/geri bildirim döngüsü. Altı kriter de "evet" değilse pilot üretime alınmaz; bu kapı, geç/geçmez kararını sezgiden çıkarıp kanıta bağlar ve yaygınlaştırma engelini görünür kılar.

PoC cehennemi nedir ve nasıl kaçınılır?

PoC cehennemi, bir kurumun sürekli yeni kavram kanıtı (proof of concept) üretip hiçbirini üretime taşıyamadığı, etkileyici demoların biriktiği ama değerin hiç gerçekleşmediği kısır döngüdür. Nedeni genellikle her pilotun bir sonraki adım düşünülmeden, üretim kısıtları göz ardı edilerek tasarlanmasıdır. Kaçınmanın yolu, her pilotu baştan üretim gerçekleriyle kurmak ve bir yaygınlaştırma kapısıyla bağlamaktır: pilot, kapıyı geçmek üzere tasarlanır, gösteri yapmak üzere değil. Böylece saha deneyimi bir demolar mezarlığına değil, üretime dönüşen bir öğrenme hattına yatırılır.

Entegrasyon borcu neden pilotta görünmez?

Entegrasyon borcu pilotta görünmez, çünkü pilot bilinçli olarak sadeleştirilmiş bir ortamda kurulur: veri elle hazırlanır, kimlik doğrulama atlanır, tek bir sistemle konuşulur ve ölçek küçüktür. Bu koşullarda çözüm parlar; ama gerçek entegrasyon, güvenlik ve veri boru hattı hiç kurulmadığı için görünmeyen bir borç birikir. Üretime geçilmek istendiğinde bu borç bir anda faturaya döner ve çoğu zaman pilotun kendisinden daha büyük bir iş çıkar. Bu yüzden olgun ekipler entegrasyonu pilotun sonuna değil, tasarımına koyar; "sonra hallederiz" cümlesi, pilot projesi başarısızlığının en pahalı erteleme biçimidir.