Yapay Zeka Demoları Neden Canlı Ortamda Çalışmaz: 7 Eksik Katman

Yapay zeka demoları canlı koşullarda çoğu zaman işlemez. Çünkü demo; temiz veriye, seçilmiş bir soruya ve tek bir başarılı örneğe dayanır. Canlı sistem ise hatalı girdiler, yetkilendirmeler, güncelliğini yitirmiş veriler, güvenlik saldırıları, gecikmeler, maliyetler ve hata sorumluluğuyla uğraşmak zorundadır. Model tek başına ürün değildir.

Bugün yapay zeka demosu hazırlamak kolaydır. Temiz bir PDF yüklenir, cevabı önceden bilinen bir soru sorulur ve model akıcı bir yanıt üretir. Müşteriniz ise PDF yüklemez; eksik bilgi girer, yanlış sipariş numarası yazar, erişim izni olmayan veriyi ister ve sistem hata verdiğinde bir açıklama bekler.

Bu ayrım, “model yeterince iyi mi?” sorusundan daha geniştir. Asıl soru şudur: Sistem gerçek bir iş sürecinde doğru, güvenli, izlenebilir ve maliyeti kontrol edilebilir biçimde çalışıyor mu? Bu yazı, demo ile üretim ortamı arasındaki farkı, canlı kullanımda ortaya çıkan yedi sorunu ve AI projesinde sorulması gereken soruları ele alır.

Öne Çıkanlar

• Demo, modelin seçilmiş bir örnekte ne yapabildiğini gösterir; canlı ortam sistemin binlerce gerçek istekte nasıl davrandığını test eder.
• Güvenilir bir AI uygulaması modelin yanında veri, yetki, entegrasyon, değerlendirme, izleme ve insan onayı katmanları gerektirir.
• Prompt injection, güncel olmayan dokümanlar ve yanlış yetkilendirme; demoda görünmeyip canlıda iş riski yaratan sorunlardır.
• Başarı “cevap güzel görünüyor” ile değil; doğruluk, görev başarısı, gecikme, maliyet ve insan müdahalesiyle ölçülür.
• Dar, ölçülebilir ve geri alınabilir bir pilot; geniş kapsamlı ama kontrolsüz bir AI projesinden daha değerlidir.

Demo Bir Yeteneği Gösterir, Canlı Sistem Bir Süreci Taşır

Demo ile canlı ürün arasındaki fark, bir otomobilin fuar salonunda hareket etmesiyle İstanbul trafiğinde her gün kullanılabilmesi arasındaki fark gibidir. İkisi de hareket eder. Ancak yağmur, yoğun trafik, bakım ihtiyacı ve beklenmeyen arızalar altında yalnızca biri iş görür.

Bir demo genellikle şu koşullarda hazırlanır:

• Veri seçilidir ve günceldir.
• Sorular önceden bilinir.
• Kullanıcı tek kişidir.
• Başarılı akış gösterilir.
• Hata senaryoları sunumun dışında bırakılır.
• Maliyet, gecikme ve servis kesintisi görünmez.

Canlı kullanımda bunların hiçbiri kesin değildir. Kullanıcılar sistemi her zaman tasarlandığı biçimde kullanmaz. Dosyalar düşük kaliteli taramalar olabilir. CRM alanları boş bırakılabilir. Aynı belgenin üç farklı sürümü aynı klasörde bulunabilir. Bir müşteri başka bir müşterinin siparişi hakkında bilgi almaya çalışabilir.

Demo için seçilen veri, gerçek kullanıcı verisi değildir

Şirket içi bir AI asistanı, demoda tek ve güncel bir prosedür PDF’iyle başarılı çalışabilir. Canlı ortamda ise prosedürün eski bir sürümü, departmana özel istisnalar ve yeni politika aynı klasörde yer alabilir.

Model bu belgelerden birini güvenle kaynak gösterebilir. Ancak kaynak eskiyse akıcı yanıtın işletme açısından bir değeri kalmaz. Yanlış bilgi, “bilmiyorum” yanıtından daha maliyetlidir.

İç prosedür asistanını deneyen bir ekibi düşünün. Demoda yalnızca güncel izin politikası yüklüdür ve sistem soruları doğru yanıtlar. Pilot açıldığında aynı klasöre eski PDF’ler de eklenir. Asistan, bir çalışana artık yürürlükte olmayan izin kuralını kesin ifadelerle anlatır. Sorun modelin Türkçe performansı değildir. Doküman sahipliği, sürüm kontrolü ve kaynak doğrulama hiç tasarlanmamıştır.

Tek başarılı akış, binlerce gerçek isteği temsil etmez

“Cevap üretiyor” olmak, “işi doğru tamamlıyor” olmak değildir. Özellikle müşteri desteği, teklif hazırlığı, belge işleme ve sipariş takibinde sistemin yalnızca yanıt vermesi yeterli sayılmaz.

Bir e-ticaret destek botunu düşünün. Demoda “Kargo ne zaman gelir?” sorusunu doğru yanıtlar. Canlıda kullanıcı bir sipariş numarası girer. Bu numara başka bir müşteriye ait olabilir, kargo firması API’si geç yanıt verebilir ve iade şartları geçen hafta değişmiş olabilir.

Bu noktada botun işi güzel cümleler kurmak değildir. Doğru müşteriyi doğrulamalı, güncel veriyi almalı, belirsizlik varsa işlem yapmamalı ve gerektiğinde talebi destek ekibine aktarmalıdır.

Canlı Ortamda Demoda Görünmeyen 7 Sorun Çıkar

Bir yapay zeka pilot projesinin neden canlıya geçemediğinin tek bir nedeni yoktur. Ancak sorunlar çoğunlukla aynı yedi katmanda toplanır.

1. Gerçek girdiler temiz gelmez

Demoda yüklenen fatura net çözünürlüklüdür, alanları eksiksizdir ve dosya biçimi beklenendir. Canlı ortamda kullanıcı eğik çekilmiş bir görsel yükleyebilir, alanlardan birini boş bırakabilir ya da aynı mesajda üç ayrı talep yazabilir.

Sistem böyle bir durumda ne yapacaktır? Eksik alanı tespit edecek mi? Tahmin etmek yerine kullanıcıdan teyit isteyecek mi? Hatalı kaydı geri almak mümkün olacak mı?

Belge işleme otomasyonunda bu sorular doğrudan mali risktir. Bir faturadaki virgülün yanlış okunması, sistemin yanlış tutarla kayıt oluşturmasına neden olabilir.

2. Şirket verisi güncel, düzenli ve erişilebilir olmayabilir

RAG sistemleri ve şirket belgelerinden yanıt veren asistanlar model hafızasına değil, kaynak veriye dayanır. Kaynak veri dağınıksa AI asistanı da düzensiz çalışır.

Bu yüzden “dokümanlarımız var” demek yetmez. Şu noktalar açık olmalıdır:

• Hangi doküman güncel ve sahibi kim?
• Eski sürüm nasıl kaldırılacak?
• Bilgi hangi sıklıkta yenilenecek?
• Kaynak bulunamadığında sistem ne söyleyecek?
• Yanıtın hangi belgeye dayandığı kullanıcıya gösterilecek mi?

Güçlü bir model, bozuk bilgi mimarisini düzeltemez. Yalnızca yanlış bilgiyi daha ikna edici biçimde aktarabilir.

3. Yetkilendirme ekrana değil, veriye uygulanmalıdır

Bir kullanıcının sisteme giriş yapmış olması, bütün verilere erişebileceği anlamına gelmez. Satış temsilcisi kendi müşterilerinin tekliflerini görebilir. Finans ekibi ödeme durumuna erişebilir. Ancak herkesin tüm fiyat listelerini, sözleşmeleri veya müşteri kayıtlarını görmesi gerekmez.

Bu sınır AI uygulamalarında daha da önemlidir. Kullanıcı doğal dille “X müşterisinin son teklifini göster” diyebilir. Sistem yalnızca arayüz rolünü değil, istenen veriye erişim yetkisini de kontrol etmelidir.

Yetkilendirme sonradan eklenecek bir ekran seçeneği değildir. Veri katmanına ait bir tasarım kararıdır.

4. Kullanıcılar sistemi tasarlanmadığı amaçla kullanır

Kullanıcı, “sadece iade politikası hakkında cevap ver” amacıyla tasarlanmış bir bota sistem talimatlarını açıklattırmaya çalışabilir. Belge içine saklanmış komutlarla asistanın davranışını değiştirmeyi de deneyebilir.

Bu saldırı alanına prompt injection denir. OWASP’ın 2025 LLM uygulamaları listesinde prompt injection, hassas bilgi ifşası, aşırı yetkilendirme ve veri zehirleme gibi canlı ortamda kritikleşen riskler yer alır.

Konu, kullanıcıya güvenmemek değildir. Sistem tasarımı, kullanıcının yanlışlıkla veya kötü niyetle hareket edebileceğini kabul etmelidir. AI asistanı doğrudan işlem yapabiliyorsa bu varsayım daha da önem kazanır.

5. Model çıktısı zamanla bozulabilir

Bugün işe yarayan prompt, yarın aynı çıktıyı vermeyebilir. Model sürümü değişebilir. Kaynak dokümanlar güncellenebilir. Bir API’nin yanıt biçimi farklılaşabilir. Entegrasyona yeni bir alan eklenebilir.

Bu değişikliklerin çoğu sessiz gerçekleşir. Sistem hata vermez; yalnızca daha zayıf veya daha riskli yanıtlar üretmeye başlar.

Bu nedenle bir değerlendirme seti gerekir. OpenAI’nin değerlendirme rehberi, model veya uygulama değişikliklerinde davranışı yeniden ölçebilmek için eval süreçlerini güvenilir LLM uygulamalarının temel bileşenlerinden biri olarak tanımlar. Basitçe söylemek gerekirse, canlıya almadan önce test ettiğiniz 100 gerçek senaryoyu her önemli değişiklikten sonra yeniden çalıştırmalısınız.

6. Gecikme ve maliyet canlıda görünür hale gelir

Demo 20 istekle çalışır. Canlı ortamda ise binlerce istek, uzun mesaj geçmişleri, dosya işleme, yeniden denemeler ve araç çağrıları devreye girer.

Bir kullanıcının yanıt için 15 saniye beklemesi destek akışını bozabilir. Tek işlemde birden fazla model çağrısı yapılması maliyeti beklenenden hızlı artırabilir. Dış API yavaşladığında tüm süreç bekleyebilir.

Teklif hazırlama asistanını deneyen bir satış ekibinin ilk demodan memnun kaldığını düşünün. Sistem, örnek CRM kaydından birkaç saniye içinde teklif taslağı oluşturur. Canlı veride ise müşteri alanlarının eksik olduğu ve fiyat listesinin üç farklı dosyada tutulduğu ortaya çıkar. Her taslak ek veri sorguları ve yeniden denemeler gerektirir. Asistan çalışır; ancak satış temsilcisinin kontrol süresi ve işlem maliyeti hesaplanmadığı için otomasyon beklenen zaman tasarrufunu sağlamaz.

7. Hata olduğunda kimse demo modunda değildir

Canlıda hatalı yanıt müşteriye ulaşır. Yanlış fiyat teklifi satış ekibinin karşısına çıkar. Hatalı belge kaydı muhasebe sürecini etkiler. Böyle bir durumda “model öyle söyledi” kabul edilebilir bir gerekçe değildir.

Her AI sistemi için şu soruların yanıtı yazılı olmalıdır:

• Hata nerede kaydedilecek?
• Kim inceleyecek?
• Kullanıcıya nasıl bilgi verilecek?
• Hatalı işlem geri alınabilecek mi?
• Sistem hangi durumda duracak ve insana devredecek?

NIST’in üretken AI risk yaklaşımı; yönetişimi, bağlamı anlamayı, ölçümü ve müdahaleyi birlikte ele alır. Canlıya geçiş projenin sonu değildir. İzleme ve değişiklik yönetimi bu aşamada başlar.

Yapay Zeka Projesi Model Değil, Bir Sistemdir

Yapay zeka entegrasyonunun neden zor olduğu burada ortaya çıkar. Kurumlar çoğu zaman modeli görür, sistemin geri kalanını sonraya bırakır. Güvenilir bir uygulama ise şu bileşenlerin birlikte çalışmasına bağlıdır:

1. Model: Metni, görseli veya veriyi işleyen LLM ya da başka AI bileşeni.
2. Şirket verisi: Güncel, sahipliği tanımlı ve kaynak gösterilebilir bilgi.
3. Uygulama entegrasyonları: CRM, stok, sipariş, ERP, destek veya belge sistemleri.
4. Yetki ve güvenlik katmanı: Kullanıcının yalnızca erişmesi gereken veriyi görebilmesi.
5. Değerlendirme seti: Gerçek iş senaryoları, kötü girdiler ve istisnalarla yapılan tekrar edilebilir testler.
6. İzleme ve loglama: Hangi yanıtın hangi kaynakla, hangi maliyetle ve hangi gecikmeyle üretildiğinin kaydı.
7. İnsan onayı: Finansal, hukuki veya geri alınması zor aksiyonlarda son karar noktası.

Bu katmanlardan biri eksikse yapay zeka projesi etkileyici bir demo olarak kalabilir. Sistem canlıda çalışıyor gibi görünür, ancak hiç kimse ona güvenip iş emanet edemez.

AI arayüzü de bu tasarımın parçasıdır. Hızlı ve sade bir kullanıcı deneyimi gerektiğinde, gereksiz istemci yükü taşımayan Astro web geliştirme yaklaşımı; model çıktısının kullanıcıya nasıl sunulacağını daha kontrollü kurmaya yardımcı olabilir. Ancak hızlı arayüz, yanlış veri veya eksik yetki modelini çözmez.

Canlıya Çıkmadan Önce Ölçülmesi Gereken 6 Şey

Bir AI projesi “iyi çalışıyor” denilerek değerlendirilemez. Hangi ölçüte göre iyi çalıştığı tanımlanmalıdır.

1. Doğruluk

Sistem doğru kaynağa mı dayanıyor? Kaynak bulunmadığında bunu açıkça söylüyor mu? Eski dokümana dayanarak kesin yanıt veriyor mu?

2. Görev başarısı

Kullanıcı işi gerçekten tamamlıyor mu? Destek botu yalnızca yanıt mı veriyor, yoksa müşteriyi doğru iade sürecine mi yönlendiriyor? Teklif asistanı sadece metin mi yazıyor, yoksa doğru ürün, fiyat ve koşullarla taslak mı oluşturuyor?

3. Güvenlik

Yetkisiz veri erişimi, prompt injection denemeleri ve hassas bilgi sızıntıları test edildi mi? Sistem, kullanıcı komutuyla kendi güvenlik sınırlarının dışına çıkabiliyor mu?

4. Gecikme

Kullanıcı kabul edilebilir sürede yanıt alıyor mu? Yanıt gecikirse arayüz ne gösteriyor? Dış servis kesildiğinde sistem bekliyor mu, yoksa kontrollü biçimde devrediyor mu?

5. Maliyet

Başarılı bir işin gerçek maliyeti nedir? Buna yalnızca model token maliyeti değil; dosya işleme, arama, API çağrıları, yeniden denemeler ve insan inceleme süresi de dahildir.

6. İnsan müdahalesi

Otomasyon hangi durumda durmalıdır? Hangi kararlar taslak olarak kalmalıdır? İnsan incelemesi ne kadar sürüyor ve bu süre otomasyonun faydasını azaltıyor mu?

AI projenizde “güzel cevap” yerine ölçülebilir iş sonucu arıyorsanız, yapay zeka çözümleri kapsamında önce iş akışını, veri erişimini ve hata maliyetini tanımlamak gerekir. Model seçimi bundan sonra gelir.

Ajansınıza veya Yazılım Ekibinize Soracağınız 12 Soru

AI demo ile üretim ortamı arasındaki farkı anlamanın en kısa yolu, sunum sırasında doğru soruları sormaktır.

1. Bu sistemi hangi gerçek kullanıcı verisiyle test ettiniz?
2. Başarılı cevap oranının yanında yanlış cevap oranını nasıl ölçeceksiniz?
3. Kullanıcıların erişebileceği veri hangi yetki kurallarıyla sınırlı?
4. Kaynak doküman değiştiğinde sistem bunu nasıl fark edecek?
5. Prompt injection denemelerinde sistem ne yapıyor?
6. Model veya prompt değiştiğinde regresyon testiniz var mı?
7. Hata loglarını kim izliyor ve ne sıklıkla inceliyor?
8. Hatalı cevap verildiğinde geri alma veya insan onayı akışı ne?
9. API kesintisinde ya da gecikmede sistem ne yapacak?
10. Bir işlem veya başarılı görev başına maliyeti nasıl izleyeceksiniz?
11. Hangi işlerde AI yalnızca taslak üretir, hangi işlerde doğrudan aksiyon alır?
12. Kullanıcı verisi, kayıtlar ve entegrasyon kodu kimin sahipliğinde?

Bu sorular projeyi yavaşlatmaz. Tersine, yanlış kapsamla başlayıp aylarca pilotta kalan işi daha baştan ayıklar.

Doğru Başlangıç: Dar, Ölçülebilir ve Geri Alınabilir Bir İş Akışı

İlk AI projesinin amacı her şeyi otomatikleştirmek olmamalıdır. Amaç, hata maliyeti yönetilebilir tek bir işi güvenilir biçimde geliştirmektir.

İlk sürümde tek işi çözün

“Şirketin tüm dokümanlarından cevap veren asistan” geniş ve belirsiz bir hedeftir. “Satış ekibinin güncel ürün föylerinden teklif taslağı çıkarması” ise sınırları belirlenebilen bir iş akışıdır.

Kapsam küçüldükçe test edilecek veri, kullanıcı rolü ve hata senaryosu daha net hale gelir. Bu, hedefi küçültmek değil; ölçülebilir kılmaktır.

Başarı ölçütünü lansmandan önce yazın

Sistemi devreye almadan önce şu cümleyi tamamlayın: “Bu proje başarılı sayılacak, eğer…”

Örnek:

• Teklif hazırlama süresi yüzde kaç azalacak?
• Hangi doğruluk oranının altı kabul edilemez?
• Hangi hata türü otomatik olarak insan incelemesine gidecek?
• Kullanıcı başına kabul edilebilir gecikme ne olacak?
• Aylık maliyet hangi sınırı aşmamalı?

Üretken AI yatırımlarında değeri belirleyen çoğu zaman teknik kabiliyet değildir; entegrasyon ve iş akışı tasarımıdır. Başarı ölçütü baştan yazılmamışsa, yatırımın getirisi de ölçülemez.

İnsan onayını hata değil, tasarım kararı olarak görün

Bir AI asistanının taslak teklif oluşturması mantıklı olabilir. Bu taslağı müşteriye otomatik göndermesi ise farklı bir risk seviyesidir.

Finansal işlemlerde, fiyat değişikliklerinde, müşteri iletişiminde, hukuki içerikte ve hassas veri erişiminde insan onayı otomasyonun eksikliği değildir. Hata maliyetine göre verilmiş doğru bir ürün kararıdır.

Önce güvenli pilot, sonra kapsam genişletin

Müşteri destek otomasyonu kuran bir ekibin, ilk sürümde botun sipariş değişikliği yapmasına izin vermediğini düşünün. Sistem yalnızca yetki kontrolüyle sipariş durumunu gösterir, istisna hallerinde destek kaydı açar. Ekip ilk haftalarda en sık gelen belirsiz talepleri toplar ve yanlış yönlendirmeleri değerlendirir. Ardından iade sürecine kontrollü biçimde geçer. Pilot küçük başlar, ama ekip hangi işleri otomatikleştirebileceğini veriye bakarak öğrenir.

Bu yöntem gösterişli görünmez. Canlı ortamda güven böyle kurulur.

Sık Sorulan Sorular

Yapay zeka demosu ile canlı ortam arasındaki fark nedir?

Demo, modelin seçilmiş örneklerde neler yapabildiğini gösterir. Canlı ortam ise sistemin gerçek veriler, farklı kullanıcılar, yetkiler, güvenlik riskleri, gecikmeler, maliyetler ve hata sorumluluğu altında ne kadar tutarlı çalıştığını sınar.

Yapay zeka projesi neden pilot aşamasında kalır?

Projeler çoğu zaman model seçimine odaklanır. Veri kalitesi, mevcut yazılımlarla entegrasyon, kullanıcı yetkileri, değerlendirme, maliyet ve sorumluluk planı sonraya bırakılır. Bu katmanlar kurulmadığında pilot etkileyici görünse bile güvenilir bir ürüne dönüşmez.

Yapay zeka için sadece iyi bir prompt yeterli mi?

Hayır. Prompt, sistem davranışının yalnızca bir parçasıdır. Güvenilir uygulama için doğru veri kaynağı, kaynak doğrulama, erişim yetkisi, test senaryoları, izleme ve hata durumunda insan müdahalesi gerekir.

Yapay zeka asistanı şirket verilerine doğrudan erişmeli mi?

Hayır. Erişim, kullanıcının rolüne ve ihtiyacına göre sınırlandırılmalıdır. Sistem yalnızca gerekli veriye, gerekli süre boyunca ve kaydı tutulacak şekilde erişmelidir.

Yapay zeka çıktıları nasıl test edilir?

Gerçek iş senaryolarından oluşan bir değerlendirme seti hazırlanır. Sistem; doğru yanıt, yanlış yanıt, eksik veri, kötü niyetli istek, farklı dosya biçimi, yetkisiz kullanıcı ve dış servis kesintisi gibi durumlarda tekrar tekrar sınanır.

Yapay zeka sisteminde insan onayı ne zaman gerekir?

Finansal işlem, müşteri iletişimi, fiyat değişikliği, hukuki içerik, hassas veri erişimi ve geri alınması zor eylemlerde insan onayı tasarımın parçası olmalıdır. İnsan onayı otomasyonun başarısızlığı değil, hata maliyetine göre alınmış bir ürün kararıdır.

Yapay Zeka Demosu Satın Almayın, Ölçülebilir Bir Sistem Kurun

Yapay zeka demoları başarısız değildir. Demo, seçilmiş bir senaryoda etkileyici bir yanıt gösterir; canlı ortamın sınadığı şeyi göstermez.

Asıl değer modelin akıcı konuşmasında değildir. Gerçek iş akışında doğru veriye dayanmasında, yetki sınırlarını korumasında, hatalarının izlenmesinde ve maliyetinin denetlenmesindedir. Bu yüzden ilk karar “hangi modeli kullanalım?” olmamalıdır. İlk karar, hangi işin ölçülebilir, güvenli ve geri alınabilir biçimde geliştirileceği olmalıdır.