Kurumsal yapay zeka seçiminde kriter var, sıralama yok.

Karşılaştırma merkezi nedir, kim için?

Bu bölüm, kurumsal yapay zeka ve güvenlik yazılımı alımı öncesinde araştırma yapan bilgi işlem yöneticileri, satın alma birimleri ve dijital dönüşüm ekipleri için hazırlanmış bir referans noktasıdır. Amaç basit: satıcı sunumlarının parlattığı özellik listeleri yerine, kararınızı gerçekten etkileyecek boyutları — lisans modeli, toplam sahip olma maliyeti, veri egemenliği, ekip gereksinimi ve tedarikçiye bağımlılık riski — aynı tabloda, kaynak göstererek yan yana koymak.

Türkiye'de kurumsal yazılım alımlarının önemli bir kısmı hâlâ iki uçtan birine savrulur: ya en bilinen markaya "kimse IBM aldığı için kovulmaz" refleksiyle gidilir, ya da yalnızca liste fiyatına bakılarak en ucuz görünen seçenek alınır ve gizli maliyetler iki yıl sonra faturaya döner. İkisi de yöntem değildir. Yöntem; kurumun senaryosunu yazmak, kriterleri ağırlıklandırmak ve adayları bu kriterlere göre puanlamaktır. Aşağıdaki çerçeve tam olarak bunun için var.

İki okur profilini birden gözetiyoruz. Kamu tarafında şartname yazan uzman için her karşılaştırma, teknik şartnameye taşınabilir kriter ve kabul maddeleri üretir; rekabeti daraltan marka tarifi yerine ölçülebilir gereksinim dili kullanırız. Özel sektörde bütçe savunan yönetici için ise aynı tablolar, yönetim kuruluna sunulacak "neden bu seçenek" gerekçesinin hammaddesidir: fiyat modeli, üç yıllık maliyet davranışı ve ekip gereksinimi tek sayfada, kaynaklarıyla durur. Her iki durumda da amaç aynı — kararın satıcı sunumuna değil, kurumun kendi verisine dayanması.

Seçim kriterleri çerçevesi: 7 boyut

Hangi kategoride olursa olsun — LLM API'si, SIEM, iş zekası ya da kurumsal AI asistan (RAG) projesi — kurumsal yazılım kararını aynı yedi boyut belirler:

• 1 · Toplam sahip olma maliyeti (TCO): Liste fiyatı buzdağının görünen kısmıdır. Lisans/token ücretine entegrasyon, veri taşıma, eğitim, bakım, altyapı (GPU, depolama) ve personel maliyetini ekleyin; karşılaştırmayı 3 yıllık TCO üzerinden yapın.
• 2 · Lisans ve fiyat modeli: Kullanım birimi ne? Token, GB/gün, EPS, kullanıcı sayısı, çekirdek… Birim yanlış seçilirse büyüme doğrudan cezalandırılır. Örneğin log hacmiyle fiyatlanan bir SIEM'de veri iki katına çıktığında fatura da iki katına çıkar.
• 3 · Veri egemenliği ve mevzuat: Veri nerede işleniyor, nerede saklanıyor? KVKK, sektör regülasyonları ve kamu için yerlilik gereksinimleri; bulut API ile on-premise kurulum arasındaki tercihi çoğu zaman teknik kriterlerden önce belirler.
• 4 · Tedarikçiye bağımlılık (lock-in): Yarın bu üründen çıkmak isterseniz veriniz, konfigürasyonunuz ve iş mantığınız standart formatta dışa aktarılabiliyor mu? Çıkış maliyeti sözleşme imzalanmadan önce hesaplanmalıdır — sonrasında pazarlık gücünüz kalmaz.
• 5 · Ekip gereksinimi: Ürünü işletecek insan var mı? Açık kaynak bir çözüm lisans ücreti istemez ama mühendislik ister; yönetilen SaaS ise tersine, operasyon yükünü azaltıp birim fiyatı artırır. Kurumun gerçek kapasitesine dürüst bakmak gerekir.
• 6 · Entegrasyon ve ekosistem: Ürün mevcut dizin hizmetiniz (AD/LDAP, SSO), veri kaynaklarınız ve iş uygulamalarınızla hazır konnektörle mi konuşuyor, yoksa her bağlantı ayrı bir proje mi? Entegrasyon eforu çoğu projede lisanstan pahalıdır.
• 7 · Ölçeklenebilirlik ve çıkış stratejisi: Pilot 50 kullanıcıyla güzel çalışan sistem 5.000 kullanıcıda ne yapıyor? Büyüme senaryosunun maliyeti ve mimari sınırları en baştan sorulmalı; sözleşmeye veri dışa aktarım ve geçiş desteği maddesi yazılmalıdır.

Kriterleri ağırlıklandırma: puan tablosu nasıl kurulur?

Yedi boyutu listelemek yetmez; hepsi eşit önemde değildir ve önem sırası kurumdan kuruma değişir. Pratik yöntem şu: adayları incelemeye başlamadan önce kriterlere yüzdelik ağırlık verin ve bu ağırlıkları yazılı hâle getirin. Bir kamu kurumunda veri egemenliği tek başına %30 ağırlık taşıyabilirken, hızlı büyüyen bir e-ticaret şirketinde aynı kriter %10'da kalıp ölçeklenebilirlik %25'e çıkabilir. Ağırlıkları önce belirlemenin kritik faydası şudur: sunumu en parlak olan tedarikçiye göre kriterleri sonradan eğip bükmenizi engeller. Karar, sunum kalitesine değil, önceden ilan edilmiş bir ölçüye göre verilir.

Ardından her adayı kriter bazında 1-5 arası puanlayın, ağırlıkla çarpın ve toplayın. Burada iki kural işi kurtarır. Birincisi, eleyici kriterler puanlamaya girmez: mevzuatın veya veri konumunun karşılanmaması bir puan kaybı değil, adayın listeden çıkması demektir — bu maddeleri en başta ayrı bir kontrol listesine koyun. İkincisi, puanın gerekçesi yazılır: "entegrasyon: 4" değil, "entegrasyon: 4 — AD/SSO ve ERP için hazır konnektör var, bordro sistemi için özel geliştirme gerekiyor (yaklaşık 15 adam-gün)". Gerekçesiz puan, altı ay sonra kimsenin savunamayacağı bir tablodur; gerekçeli puan ise doğrudan sözleşme pazarlığının ve proje planının girdisidir.

Sık yapılan 5 hata

• Demo etkisiyle karar vermek: Satıcının kendi verisiyle kurguladığı demo, ürünün sizin verinizle davranışını göstermez. Karar öncesi kendi veri örnekleminizle sınırlı kapsamlı bir PoC (kavram kanıtı) şart — kabul kriterleri yazılı olmalı.
• Liste fiyatını TCO sanmak: Özellikle token ve veri hacmi bazlı modellerde asıl soru birim fiyat değil, sizin hacminizin yıllık karşılığıdır. Fiyat modelini kendi kullanım projeksiyonunuzla çarpın; üç yıllık toplamı karşılaştırın.
• "En iyi" ürünü aramak: Bağlamsız "en iyi" sorusunun cevabı yoktur; senaryonuza en uygun ürün vardır. Aynı SIEM, 7/24 SOC ekibi olan bir bankada doğru, iki kişilik BT ekibi olan bir KOBİ'de yanlış tercihtir.
• Lock-in'i sözleşmeye yazmamak: Veri dışa aktarım formatı, API erişimi ve sözleşme bitiminde geçiş desteği pazarlık aşamasında ücretsiz istenebilecek maddelerdir; kullanım başladıktan sonra ise pahalı birer "ek hizmet" olur.
• Ekip gereksinimini yok saymak: Ürün alınır, kuran entegratör gider, işletecek kimse kalmaz. Alım kararıyla birlikte işletme planı (kim yönetecek, hangi eğitim, hangi destek SLA'sı) netleşmelidir.

Şartname yaklaşımı: özellik listesi değil, senaryo

İyi şartname marka tarif etmez, problemi tarif eder. Pratikte en iyi çalışan yaklaşım üç katmandır:

1. Senaryolar: "Sistem X kaynaklarından günde Y hacminde veri alacak, Z senaryosunda şu çıktıyı üretecek" biçiminde, ölçülebilir kullanım senaryoları. Adaylar bu senaryolar üzerinden puanlanır.
2. Zorunlu nitelikler: Mevzuat (KVKK, log mevzuatı), güvenlik standartları (ISO 27001, erişim kontrolü), veri konumu ve dışa aktarım hakkı gibi pazarlık edilemez maddeler. Bu katman kısa ama serttir.
3. Kabul kriterleri: Ürün canlıya alınmadan önce hangi testlerin, hangi eşiklerle geçileceği. LLM projelerinde doğruluk/groundedness değerlendirme seti, SIEM projelerinde tespit senaryoları ve EPS/hacim yük testi yazılı kabul kriteri olmalıdır.

Bu yaklaşımın kategori bazında nasıl uygulandığını kurumsal siber güvenlik ve SIEM & SOC çözüm sayfalarımızda şartname maddeleriyle birlikte anlatıyoruz; veri tarafı için iş zekası ve veri ambarı sayfası da aynı disiplinle yazılmıştır.

PoC ve pilot: kâğıt üstünden gerçeğe

Kriter tablosu adayları üçe indirir; nihai kararı ise kontrollü bir deneme verir. İşleyen bir PoC kurgusunun dört şartı vardır: kendi veriniz (satıcının örnek seti değil, sizin gerçek belge/log örnekleminiz), sınırlı kapsam (tek departman veya tek kullanım senaryosu; 2-4 hafta), yazılı başarı eşiği (ör. "test setindeki soruların en az %85'ine kaynak gösterilebilir doğru yanıt" ya da "saniyede X olay işlenirken sorgu gecikmesi Y altında") ve maliyet ölçümü (PoC sırasındaki gerçek tüketim, yıllık hacme çarpan olarak yansıtılır). Bu dört şart yazılı değilse yapılan şey PoC değil, uzatılmış bir demodur.

TCO hesabında pratik bir kural: birim fiyatı değil, sizin hacminizin üç yıllık toplamını karşılaştırın. Token bazlı bir LLM API'sinde bu "aylık sorgu × ortalama token × birim fiyat × 36 ay + entegrasyon + bakım" demektir; SIEM'de "günlük GB/EPS × birim maliyet × 36 ay + depolama + analist zamanı". İki üründen biri düşük birim fiyat, diğeri düşük işletme yüküyle gelir — üç yıllık toplam alınmadan bu ikisi kıyaslanamaz. Karşılaştırma sayfalarımızdaki tablolar bu hesabın girdilerini (fiyat modeli, indirim mekanizmaları, ekip gereksinimi) tek yerde toplamak için tasarlandı.