Kurumsal AI tedarikçisi nasıl değerlendirilir?

Satın alınan teknoloji değil, iş sonucu tanımlanmalıdır

Değerlendirme dosyası “kuruma AI alınacaktır” ifadesiyle başlayamaz. Hangi kullanıcı grubunun hangi işi yaptığı, mevcut sürenin ve hata oranının ne olduğu, AI çıktısının karar mı yoksa taslak mı üreteceği ve başarının nasıl ölçüleceği açıklanmalıdır. İhtiyaç net değilse tedarikçi karşılaştırması özellik listesine dönüşür.

İş ihtiyacı mümkün olduğunca teknoloji bağımsız yazılmalıdır. Böylece kurum, AI olmayan bir süreç iyileştirmesi veya daha dar bir otomasyon çözümünün daha düşük riskle aynı sonucu üretip üretmediğini karşılaştırabilir.

Veri yaşam döngüsü sözlü beyanla değil, açık veri haritasıyla doğrulanmalıdır

• Hangi veri alanları ürüne gönderilecek?
• Veri hangi ülkede ve hangi altyapıda işlenecek?
• İstemler, çıktılar ve loglar ne kadar süre saklanacak?
• Veri model eğitimi, iyileştirme veya insan incelemesi için kullanılacak mı?
• Alt işleyenler ve model sağlayıcıları kimlerdir?
• Silme, dışa aktarma ve erişim talebi nasıl uygulanır?
• Kurumsal sır, kişisel veri ve telifli içerik için hangi sınırlar vardır?

Model ve tedarik zinciri görünür olmalıdır

Tedarikçi kendi modelini geliştirebilir, üçüncü taraf API kullanabilir, açık kaynak modeli barındırabilir veya bunları birlikte orkestre edebilir. Kurum; hangi model ailesi ve sürümünün kullanıldığını, model değişikliğinin nasıl duyurulduğunu, bileşenlerin nereden geldiğini ve kritik alt tedarikçinin değişmesi hâlinde performans ile sözleşmenin nasıl etkileneceğini bilmelidir.

NIST’in üretken AI profili, değer zinciri ve üçüncü taraf bileşen risklerinin envanter, sözleşme, izleme ve değişiklik kontrolüyle yönetilmesini önerir. Kurum, “temel model sağlayıcısı sorumludur” diyerek kendi deployer veya hizmet sahibi sorumluluğunu ortadan kaldıramaz.

Performans kurumun gerçek verisi ve görevleriyle ölçülmelidir

Genel benchmark, ürünün kurum içindeki başarısını göstermez. Değerlendirme seti; gerçek görev türlerini, kolay ve zor örnekleri, güncel olmayan belgeleri, erişim sınırlarını, Türkçe terminolojiyi, eksik bilgi durumunu ve kötü niyetli girdileri kapsamalıdır.

Güvenlik, standart sertifika listesinin ötesinde test edilmelidir

• Kimlik, rol, tenant ve servis hesabı ayrımı.
• En az yetki ve ayrıcalıklı işlem onayı.
• Prompt injection, veri dışarı çıkarma ve araç kötüye kullanımı testleri.
• Şifreleme, anahtar yönetimi ve log erişimi.
• Zafiyet, olay ve ciddi değişiklik bildirim süresi.
• Güvenli geliştirme, bağımlılık ve tedarik zinciri kontrolleri.
• Yedekleme, kapasite, felaket kurtarma ve iş sürekliliği.
• Denetim izi, çıktı sürümü ve geri alma imkânı.

Sertifika yalnız tanımlı kapsam ve tarih için kanıttır. AI uygulamasının kullandığı model, connector, veri akışı veya yeni özellik sertifika kapsamında değilse kurum ek kanıt ve teknik test istemelidir.

Fikri haklar, veri koruma ve düzenleyici roller sözleşmede ayrıştırılmalıdır

Girdi ve çıktıların kullanım hakkı, tedarikçinin ürün geliştirme hakkı, telif ihlali iddiaları, açık kaynak bileşenler, veri sorumlusu/işleyen rolleri, yetkili temsilci gereksinimleri ve sektörel yükümlülükler aynı “uyumlu ürün” cümlesine sığdırılamaz.

• Girdi, çıktı, konfigürasyon ve özel değerlendirme setinin mülkiyeti.
• Telif veya üçüncü taraf iddiasında bildirim, savunma ve tazmin mekanizması.
• Kişisel veri rolleri, amaç, saklama ve sınır ötesi aktarım.
• AI Act veya başka düzenlemelerde provider, deployer, importer ve distributor rolü.
• Yüksek risk veya şeffaflık yükümlülüğü doğurabilecek kullanım değişiklikleri.
• Denetim, bilgi talebi ve düzenleyici iş birliği hükümleri.

Bu rehber hukuki görüş değildir. Somut ürün, ülke, sektör ve kullanım amacı için hukuk ve uyum incelemesi ayrıca yapılmalıdır.

Canlı işletim, değişiklik ve olay yönetimi satın alma kararına dâhildir

Tedarikçi; model güncellemesi, özellik değişikliği, fiyat değişikliği, bölgesel kesinti, veri olayı veya alt tedarikçi değişikliğini nasıl yönettiğini açıklamalıdır. Kurumun yeniden test, geçici kapatma, eski sürüme dönüş ve kullanıcı bilgilendirme hakkı bulunmalıdır.

Fiyat, toplam sahip olma maliyeti ve bağımlılıkla birlikte değerlendirilmelidir

Lisans veya token fiyatına; entegrasyon, veri hazırlığı, güvenlik, değerlendirme, insan kontrolü, eğitim, destek, egress, saklama ve çıkış maliyetleri eklenmelidir. Kullanım arttığında fiyat eğrisi, model değişikliğinin maliyet etkisi ve minimum taahhütler test edilmelidir.

• İş sonucu veya kalite ayarlı birim maliyet.
• Deneme, test ve üretim ortamlarının ayrı tüketimi.
• Fiyat değişikliği için bildirim ve fesih hakkı.
• Veri, prompt, workflow ve connector taşınabilirliği.
• Standart formatta dışa aktarım ve silme kanıtı.
• Geçiş desteği, süre ve profesyonel hizmet ücretleri.

Pilot, sözleşme ve yönetişim tek karar kapısında birleşmelidir

1. Hazırlık: Kullanım amacı, veri sınıfı, risk iştahı ve kabul ölçütlerini yazın.
2. Bilgi talebi: Veri, model, alt tedarikçi, güvenlik, hak, işletim ve maliyet kanıtlarını isteyin.
3. Skorlama: Kritik kriterleri ağırlıklandırın; telafi edilemeyecek kırmızı bayrakları ayrı tutun.
4. Pilot: Kuruma ait veri ve görevlerle sınırlı, geri alınabilir ve ölçümlü test yapın.
5. Sözleşme: Testte doğrulanan özellikleri, değişiklik ve çıkış haklarını bağlayıcı hâle getirin.
6. Canlı izleme: Kalite, maliyet, güvenlik, olay ve tedarikçi değişimini periyodik gözden geçirin.