Yapay zekâ projeleri neden başarısız olur? Sahadan 12 neden

Kurumsal yapay zekâ projelerinin başarısız olma nedenleri sorulduğunda beklenen cevap teknik olur: model yeterince iyi değildi, veri azdı, altyapı yetmedi. Sahada gördüğümüz tablo farklı. Başarısızlığın büyük kısmı, projenin ilk üç haftasında verilen kararlardan doğar ve model kalitesiyle ilgisi yoktur.

Aşağıdaki on iki neden, farklı sektörlerde tekrar tekrar karşımıza çıkan örüntülerdir. Her birinin bir erken uyarı sinyali ve onu önleyen bir yapısal karar vardır.

Başarısızlık üç farklı şekilde görünür

Nedenlere geçmeden önce ayrım gerekir, çünkü üçü farklı yerlerde tedavi edilir:

1. Durdurulan proje. Bütçe biter ya da onay çıkmaz. En görünür, en az maliyetli başarısızlık türüdür — erken durursa.
2. Kullanılmayan sistem. Teknik olarak çalışır, canlıya alınır, kimse kullanmaz. En sık görülen ve en sinsi türdür: kimse başarısız olduğunu söylemez.
3. Güvenilmeyen sistem. Kullanılır ama çıktısına inanılmaz; herkes sonucu elle kontrol eder. Bu durumda sistem iş yükünü azaltmaz, artırır.

Problem seçiminden gelen dört neden

1. Teknolojiden başlamak, problemden değil

"Yapay zekâ yapalım" bir brief değildir. Bu şekilde başlayan projelerde senaryo teknolojiye uydurulur; sonuç, kimsenin gerçekten ihtiyaç duymadığı bir demodur.

Erken sinyal: Toplantıda konuşulan cümlelerde iş sonucu değil teknoloji adı geçiyor. Önleyen karar: Projeyi bir problem cümlesiyle başlatın — "şu iş şu kadar sürüyor / şu hata şu sıklıkla oluyor". Teknoloji seçimi bu cümleden sonra gelir.

2. Başarı kriterinin yazılmamış olması

Kriter yazılmadığında proje bitmez, sadece durur. Herkesin kafasında farklı bir "iyi" tanımı olur ve hiçbiri doğrulanamaz.

Erken sinyal: "Nasıl anlarız işe yaradığını?" sorusuna verilen cevap bir sayı içermiyor. Önleyen karar: Kriter tek cümle, ölçülebilir ve mevcut duruma kıyaslı olsun. Kıyas için bir başlangıç ölçümü gerekir — mevcut durumun sayısı alınmadan iyileşme iddia edilemez.

3. Yanlış ilk senaryo

Görünürlüğü yüksek ama etkisi düşük senaryolarla başlamak yaygın bir hatadır. Yönetime gösterişli gelir, kullanıcının gününü değiştirmez.

Erken sinyal: Senaryonun etkilediği kişi sayısı az ya da etkilenen iş zaten hızlı. Önleyen karar: İlk senaryoyu iki eksende seçin — sık tekrarlanan ve bugün yavaş olan. Gösterişli olması gerekmez, günlük olması gerekir.

4. Olgunluk sırasının atlanması

Veri altyapısı ve süreç otomasyonu kurulmamışken yapay zekâya geçmek, temeli atılmamış binaya çatı döşemektir. Model iyi çalışsa bile besleneceği düzenli veri yoktur.

Erken sinyal: "Bu veriyi nereden çekeceğiz?" sorusunun cevabı "Excel'den". Önleyen karar: Doğru sırayı belirlemek için önce nerede durduğunuzu ölçün; yöntemi dijital olgunluk yazımızda anlattık.

Veriden gelen üç neden

5. Veri sahipliğinin belirsiz olması

Verinin teknik olarak erişilebilir olması yetmez; içeriğin doğru olup olmadığına karar verecek bir kişi gerekir. Sahibi olmayan veri, kimsenin düzeltmediği veridir.

Erken sinyal: "Bu alan ne anlama geliyor?" sorusuna üç kişi üç farklı cevap veriyor. Önleyen karar: Her veri kümesi için adı yazılı bir sahip belirleyin — projeye değil, veriye.

6. Verinin "var" sanılması

Kurumların çoğunda veri vardır ama kullanılabilir hâlde değildir: taranmış belgeler, metin katmanı olmayan PDF'ler, aynı bilginin üç sistemde üç farklı yazımı, boş bırakılmış alanlar.

Erken sinyal: Örnek veri istendiğinde gelen dosya elle hazırlanmış. Önleyen karar: Fizibilite fazında gerçek veriyle küçük bir örnek çalıştırın. Temiz örnekle yapılan fizibilite, fizibilite değildir.

7. Değerlendirme setinin hiç kurulmaması

Ölçüm hattı olmayan bir sistemde "iyi çalışıyor mu?" sorusu kanaate kalır. Zamanla doğruluk düşse bile kimse fark etmez.

Erken sinyal: Doğruluk hakkında konuşulurken örnek anlatılıyor, oran söylenmiyor. Önleyen karar: Kurumun gerçek sorularından bir test seti oluşturun ve göstergeyi düzenli çalıştırın. Set, projenin teslimatları arasında yazılı olsun.

Mimari ve güvenden gelen üç neden

8. Kaynak gösteremeyen mimari seçimi

Cevabın hangi belgeye dayandığı gösterilemiyorsa, denetim ve hukuk onayı çıkmaz — sistem teknik olarak çalışsa bile canlıya alınamaz. Bu, sahada gördüğümüz en pahalı geri dönüşlerden biridir.

Erken sinyal: "Model bunu nereden biliyor?" sorusunun cevabı yok. Önleyen karar: Doğrulanabilirlik gerekiyorsa bilgi katmanı kaynak atıflı olmalı; yöntem karşılaştırmasını RAG mi fine-tuning mi yazımızda ele aldık.

9. Yetkinin sistem dışında bırakılması

Yetki kontrolü arayüzde yapılıp arama katmanına inmiyorsa, kullanıcı görmemesi gereken bir belgeden türetilmiş cevabı alabilir. Bu, tek bir olayla projeyi bitirebilecek bir risktir.

Erken sinyal: Yetki modeli "sonra ekleriz" listesinde. Önleyen karar: Yetkiyi ilk günden arama ve erişim katmanına yerleştirin; sonradan eklenen yetki, mimariyi yeniden yazmak demektir.

10. Halüsinasyonun ürün tasarımıyla değil, uyarıyla yönetilmesi

Ekrana "yapay zekâ hata yapabilir" yazmak bir çözüm değildir. Kullanıcı bir süre sonra bu uyarıyı görmez — uyarı yorgunluğu devreye girer ve yanlış cevaplar denetimsiz akmaya başlar.

Erken sinyal: Doğruluk sorusuna verilen tek cevap "kullanıcıyı uyarıyoruz". Önleyen karar: Halüsinasyonu mimariyle sınırlayın: kaynak atfı, ilgili belge yoksa cevap üretmeme ve ölçüm hattı. Uyarı, bunların tamamlayıcısıdır, yerine geçeni değil.

İnsandan gelen iki neden

11. Kullanıcının akışına girmeyen ürün

Kullanıcı işini yaparken başka bir ekrana geçip "yapay zekâya sormak" zorunda kalıyorsa, çoğunlukla sormaz. Bu bir eğitim sorunu değil, yerleşim sorunudur.

Erken sinyal: Sistem ayrı bir uygulama ya da ayrı bir sekme olarak tasarlanmış. Önleyen karar: Yeteneği işin geçtiği yere taşıyın. Ürün tarafında bunu neden mimari bir tercih olarak kurduğumuzu Suite Pro mimarisi yazımızda anlattık.

12. Sahipsizlik ve kapsam kayması

Proje bittiğinde kimin bakacağı belirsizse sistem altı ayda eskir. Aynı belirsizlik, proje sürerken de kapsam kaymasını besler: her toplantıda bir istek eklenir, hiçbiri çıkarılmaz.

Erken sinyal: "Bunu da ekleyelim" cümlesi son iki haftada üçten fazla duyuldu; devir sonrası sahibi belirlenmemiş. Önleyen karar: Devirden önce üç soruyu yazılı cevaplayın — değerlendirme setini kim çalıştıracak, sonucu kim okuyacak, içerik güncellemesini kim onaylayacak.

Erken uyarı tablosu

Başarısızlığı önleyen beş yapısal karar

On iki nedenin büyük kısmı, projenin başında verilen beş kararla kapanır:

1. Problem cümlesiyle başlayın. Teknoloji seçimi ikinci adımdır.
2. Başarı kriterini ve başlangıç ölçümünü yazın. Sayı yoksa proje yoktur.
3. Fizibiliteyi gerçek veriyle yapın. Temiz örnek, gerçeği gizler.
4. Yetki ve kaynak atfını ilk günden mimariye koyun. İkisi de sonradan eklenmez.
5. Devir planını başta yazın. Sahibi olmayan sistem, bakımsız sistemdir.

Toparlarken

Yapay zekâ projelerinde başarısızlığın adresi genellikle model değil, karar sırasıdır. İyi haber şu: bu on iki nedenin tamamı, projenin ilk üç haftasında verilen kararlarla ilgilidir — yani hâlâ ucuz olduğu bir aşamada düzeltilebilir.

Bütçeyi bu kararlara göre fazlara yaymanın yöntemini maliyet yazımızda, kararın otomatikleşmemesi gereken yerlerdeki tasarım ilkesini ise insan onaylı yapay zekâ yazımızda ele aldık.

Nereden başlamanız gerektiğini ölçün — ücretsiz olgunluk analizi