Kurumsal bir yapay zekâ aracı seçerken en sık yapılan hata, genel yetenekleri iş sonucuyla karıştırmaktır. Akıcı metin yazan veya birkaç örnek soruyu doğru yanıtlayan bir sistem, sizin belgelerinizde güvenilir çalışmayabilir. Üstelik doğruluk tek başına yeterli değildir: Araç hassas bilgileri açığa çıkarabilir, hatalı çıktıyı son derece ikna edici sunabilir ya da otomasyon yetkisi verildiğinde beklenmeyen işlemler başlatabilir. Sağlıklı satın alma kararı bu nedenle ürün demosuyla değil, sınırları önceden belirlenmiş bir pilotla verilmelidir.
1. Önce ürünü değil, görevi tanımlayın
“Çalışanların yapay zekâ kullanması” ölçülebilir bir hedef değildir. Bunun yerine tek bir iş akışı seçin: destek taleplerini sınıflandırmak, uzun sözleşmelerden belirli maddeleri çıkarmak veya onaylanmış belgelerden taslak yanıt hazırlamak gibi. Girdiyi, beklenen çıktıyı, son kullanıcıyı ve yanlış sonucun etkisini yazılı hâle getirin.
Görevin başarısını mevcut yöntemle ölçün. Bir çalışan bugün aynı işi kaç dakikada tamamlıyor? Kaç düzeltme yapılıyor? Kritik hata oranı nedir? Bu başlangıç değeri olmadan pilot sonunda görülen hızlanmanın gerçek bir kazanım mı, yalnızca yeni araç heyecanı mı olduğu anlaşılamaz.
Yüksek etkili kararları ilk pilotun dışında bırakın. İşe alım, kredi, sağlık, hukuk veya çalışan performansı gibi alanlarda yanlış çıktı bireyler üzerinde ciddi sonuçlar doğurabilir. Pilot düşük riskli ve geri alınabilir bir görevle başlamalı; yapay zekâ nihai karar verici değil, incelemeye sunulan taslağın üreticisi olmalıdır.
2. Temsilî bir test kümesi hazırlayın
Gerçek işi yansıtan, kişisel ve gizli bilgilerden arındırılmış en az birkaç düzine örnek oluşturun. Yalnızca kolay örnekleri seçmeyin. Eksik bilgi, yazım hatası, çelişkili talimat, farklı belge biçimi, Türkçe karakterler, uzun bağlam ve cevaplanamayan soru gibi uç durumları da ekleyin. Sistemin doğru cevap vermesi kadar, yeterli kanıt olmadığında cevap üretmemesi de sınanmalıdır.
Her örnek için kabul ölçütünü testten önce belirleyin. Sonradan değiştirilen ölçütler iyi görünen sonuçlara göre hedef çizme riskini doğurur. Değerlendirme tablosunda olgusal doğruluk, kaynak gösterme, talimata uyma, eksik bilgi karşısında çekimser kalma, zararlı içerik üretmeme ve insanın düzeltmek için harcadığı süre ayrı sütunlarda tutulabilir.
Tek bir toplam puan kusurları gizleyebilir. Örneğin yüzde 95 başarı etkileyici görünürken kalan yüzde 5, müşteri verisini yanlış kişiye aktaran kritik vakalardan oluşabilir. Bu nedenle sıradan hata ile kritik hata ayrılmalı; kritik hatalar için sayı değil, sıfıra yakın bir kabul eşiği kullanılmalıdır.
3. Güvenlik sınırlarını gerçekçi biçimde sınayın
NIST’in üretken yapay zekâ profili, risk yönetimini yalnızca model performansına indirgemez; yönetişim, içerik bütünlüğü, mahremiyet, güvenlik ve insan gözetimi gibi konuları sistemin yaşam döngüsü boyunca ele alır. Pilot ekibi de veri akışını uçtan uca çıkarmalıdır: İstemler nerede işleniyor, ne kadar süre saklanıyor, eğitim için kullanılıyor mu, alt işleyenler kimler ve kayıtları kim görebiliyor?
Sözleşmedeki vaatleri ürün ayarlarıyla doğrulayın. Tek oturum açma, çok faktörlü doğrulama, rol tabanlı erişim, denetim kaydı, saklama süresi ve toplu veri silme seçeneklerini gerçekten deneyin. Kullanıcıların müşteri sırrı, kaynak kodu veya sağlık bilgisi yapıştırmasını yalnızca eğitim metniyle önlemeye çalışmayın; veri sınıflandırması ve teknik kısıtlar uygulayın.
OWASP’ın güncel LLM riskleri; istem enjeksiyonu, hassas bilgi ifşası, tedarik zinciri sorunları, uygunsuz çıktı işleme ve aşırı yetkilendirme gibi tehditlere dikkat çekiyor. Bu başlıkları test senaryosuna çevirin. Zararlı talimat içeren bir belge sisteme yüklendiğinde ne oluyor? Model çıktısı başka bir uygulamada komut gibi çalıştırılıyor mu? Araç e-posta gönderebiliyor veya dosya silebiliyorsa işlem öncesinde insan onayı gerekiyor mu? Eklenti ve bağlantılara yalnızca görev için gereken en düşük yetkiyi verin.
4. Türkçe kalitesini ayrıca ölçün
Bir sağlayıcının genel karşılaştırma testlerindeki başarısı, Türkçe iş akışınızın kalitesini garanti etmez. Ekler, olumsuzluk, tarih ve para yazımı, kurum içi terimler, resmî hitap biçimi ve farklı bölgesel ifadeler için ayrı örnekler kullanın. Çeviri üzerinden üretilmiş gibi duran metinleri, anlamı değiştiren noktalama sorunlarını ve yabancı dilde kaynaklara dayanarak verilen Türkiye’ye özgü yanlış yanıtları işaretleyin.
Kaynak temelli bir sistem deneniyorsa her iddianın gerçekten verilen belge tarafından desteklenip desteklenmediğini kontrol edin. Bağlantı veya sayfa numarası sunulması tek başına kanıt değildir; alıntılanan bölüm iddiayla uyuşmalıdır. Güncel bilgi gereken görevlerde bilgi kesim tarihi, arama özelliği ve kaynakların yenilenme sıklığı da kayıt altına alınmalıdır.
5. Maliyeti token fiyatından ibaret sanmayın
Lisans ücretine entegrasyon, çalışan eğitimi, güvenlik incelemesi, çıktı denetimi ve hataların düzeltilmesi için harcanan zamanı ekleyin. Kullanım arttıkça ortaya çıkabilecek kota, API, depolama ve destek maliyetlerini üç ayrı senaryoyla hesaplayın. OWASP’ın “sınırsız tüketim” başlığı, kontrolsüz kullanımın hem hizmet kesintisine hem de beklenmeyen faturaya dönüşebileceğini gösterir. Kullanıcı ve işlem başına sınır, bütçe alarmı ve kötüye kullanım izleme mekanizması pilot sırasında çalıştırılmalıdır.
6. Kararı kanıt dosyasıyla verin
Pilot sonunda yalnızca ortalama puanı değil; başarısız örnekleri, kritik hataları, insan düzeltme süresini ve güvenlik testlerini birlikte inceleyin. “Satın al”, “sınırlı kullanımda devam et” ve “durdur” kararlarının eşiklerini önceden yazın. Ürün başarılıysa hangi veri türlerinde, hangi kullanıcı grubunda ve hangi insan onayıyla kullanılabileceğini açıkça belirleyin.
Son olarak model ve hizmetlerin değişebildiğini unutmayın. Sağlayıcı model sürümünü, veri politikasını veya fiyatlandırmayı değiştirdiğinde test kümesinin yeniden çalıştırılmasını sözleşme ve işletim sürecine bağlayın. İyi bir pilot, yapay zekânın kusursuz olduğunu kanıtlamaz; hangi koşullarda yeterince yararlı, denetlenebilir ve güvenli olduğunu görünür kılar.