Kurumsal AI projeleri neden pilot aşamasında kalıyor?

Pilot çoğu zaman yanlış soruyu cevaplıyor

Pilotlarda genellikle “model bunu yapabiliyor mu?” sorusuna odaklanıyoruz. Oysa canlı kullanımda asıl sorular farklı: Çıktının sahibi kim? Hatalı yanıt nasıl fark edilecek? Kullanıcı hangi durumda sisteme güvenmemeli? Kaynak veri değiştiğinde ne olacak?

Teknolojinin çalışması gerekli; fakat tek başına ürün kararı vermek için yeterli değil. İyi bir pilot, yalnız kabiliyeti göstermek yerine bir sonraki kararın belirsizliğini azaltmalı.

Sözleşme projesinde bizim yaşadığımız

İlk yapay zeka modellerini sistemlerimize entegre ederken pilot çok iyi gidiyordu. Birkaç sözleşmenin dokümanlarını veriyorduk, model bunları RAG ile okuyup inceliyor, anlamlı yorumlar çıkarıyordu. Sözleşmelerden doğru bilgiyi çekiyordu. Pilotta 2-3 gün süren işe UAT'de 1 hafta verdik; biter, sonra canlıya geçeriz diye düşündük.

UAT'de iş büyüyünce sorunlar çıktı. Sözleşmelerin bir kısmı Word, bir kısmı imzalı PDF'ti. Bazıları çok eskiden beri süren, yenilemelerle devam eden işlerdi ve bağlı oldukları bilgiler ortak alanlarda yoktu. Model bir cevap vermek zorunda olduğu için bilgi eksik olan yerde tahmin yürütmeye başladı. Sonuçları tek tek incelemeye başlayınca işin o kadar kolay olmadığı netleşti: Çöp bilgi, çöp sonuç üretiyordu.

UAT'yi uzattık ve önce veri temizliğine karar verdik. Bunu yaparken de yine modellerden yararlandık. Sözleşme bilgilerini ve dosyaları ortak alanlardan toplayıp kriterlere uyup uymadığını kontrol ettik, temizledik. RAG mimarisini ve chunk ayarlarını baştan ele aldık; PDF için ayrı, Word ve Excel gibi dokümanlar için ayrı süreçler kurduk. Uzun sürdü ama sonunda çok iyi hazırlanmış bir veriye sahip olduk. Canlıya geçmek ise açıkçası işin en kolay kısmıydı.

Sahiplik sonradan eklenemez

Kurumsal AI sistemlerinde model bir yanıt üretir; fakat o yanıtın iş sonucundan model sorumlu değildir. Süreç sahibi, veri sahibi, teknik ekip ve operasyon ekibi arasındaki sorumluluk sınırları pilot aşamasında konuşulmadığında sistem canlıya yaklaştıkça yavaşlar.

Bu nedenle ürün tanımının içinde yalnız özellikler değil; onay, geri bildirim, izleme, itiraz ve gerektiğinde insan devri de bulunmalıdır.

Yıllarca sistem ve uygulama tarafında çalıştım. Canlıya çıkan her şeyin bir gün gece yarısı birini aratacağını oradan biliyorum. AI'da da durum aynı: Kaynak doküman değişti, cevaplar bozuldu. Kim fark edecek, kim düzeltecek, kullanıcıya kim haber verecek? Bunun cevabı yoksa pilot biter ama ürün başlamaz.

Ölçüm, model kalitesinden daha geniştir

Bir demo için birkaç başarılı örnek ikna edici görünebilir. Ürün içinse kaliteyi sürekli ölçmek gerekir. Yanıt doğruluğu kadar gecikme, maliyet, kaynak gösterme, kullanıcı davranışı ve operasyonel hata oranı da ürünün parçasıdır.

Başarı ölçütü baştan tanımlanmadığında pilot başarılı ilan edilir; fakat neyin ölçekleneceği bilinmez.

Basit bir örnek düşünün: şirket içi bir destek asistanı. Pilotta "cevaplar doğru mu?" diye bakılır. Canlıda ise asıl sorular şunlar olur: Kaç soru insana devredildi, kullanıcı cevabı beğenmeyince ne yaptı, aylık maliyet ne tuttu, cevap kaç saniyede geldi? Bu sayıları ilk günden toplamazsanız pilot bittiğinde elinizde sadece izlenim kalır.

Pilotun bitişi bir karar üretmeli

Her pilotun sonunda üç karardan biri açık olmalı: ölçekle, değiştir veya durdur. “Biraz daha deneyelim” kararı çoğu zaman teknik eksikten değil, ürün sorusunun başta net kurulmamış olmasından doğar.

Kurumsal AI projelerini pilot aşamasından çıkaran şey yalnız daha iyi model değildir. Net problem, görünür sahiplik, ölçülebilir başarı ve işletilebilir bir ürün modelidir.

Sözleşme projesinden çıkardığım ders şu: Pilot başlamadan önce hangi problemi çözdüğünüz, başarıyı hangi sayıyla ölçeceğiniz ve pilot bitince kararı kimin vereceği yazılı olmalı. Bir de şu soru: Canlıdaki veri pilottaki veriye benziyor mu? Bizde benzemiyordu ve bunu UAT'de öğrendik.