Kurumsal Yapay Zeka Satın Alma Süreci Nasıl Yönetilir?

Kurumsal yapay zeka satın alma süreci; ihtiyaç analizi, veri güvenliği (ISO 27001), hukuki uyumluluk (KVKK/GDPR) ve pilot (PoC) test aşamalarıyla yönetilir. İşletmelerin üretken yapay zeka modellerini operasyonel süreçlerine entegre ederken karşılaşacağı regülasyon engellerini, bütçe aşımlarını ve teknik darboğazları bertaraf etmek için uçtan uca yapılandırılmış bir tedarik çerçevesi oluşturulmalıdır.

Yapay zeka modellerinin şirket operasyonlarına dahil edilmesi, standart bir bulut yazılımı (SaaS) lisansı edinmekten çok daha karmaşık dinamikler barındırır. Çok modlu yapay zeka mimarileri, Büyük Dil Modelleri (LLM) ve otonom karar destek sistemleri; veri sızıntısı riskleri, değişken token maliyetleri, fikri mülkiyet ihlalleri ve regülasyon yaptırımları gibi çok katmanlı operasyonel zorluklar doğurmaktadır. Bir teknoloji yatırımının kurumsal getiriye (ROI) dönüşmesi, yalnızca algoritmanın gücüne değil; procurement (satın alma), hukuk, bilgi güvenliği ve mühendislik departmanlarının senkronize çalışmasına bağlıdır. Bu rehber, karar vericilerin "Kurumsal Yapay Zeka Satın Alma Süreci Nasıl Yönetilir?" sorusuna yanıt bulması amacıyla hazırlanmış olup; satıcı seçiminden model doğrulamasına, toplam sahip olma maliyetinden (TCO) hukuki sözleşme kurgularına kadar tüm aşamaları somut kriterlerle ortaya koymaktadır.

1. Adım: İhtiyaç Analizi ve Yapay Zeka Kullanım Senaryolarının Belirlenmesi

Yapay zeka tedarikinde yapılan en temel stratejik hata, iş problemine odaklanmak yerine trend olan algoritmaları doğrudan kuruma entegre etmeye çalışmaktır. Bir tedarik sürecinin ilk adımı, çözülmesi planlanan operasyonel darboğazın net bir şekilde formüle edilmesidir. Müşteri destek süreçlerindeki ilk yanıt süresinin kısaltılması, yüz binlerce sayfalık regülasyon metninden anlamsal veri çıkarımı yapılması, tedarik zinciri tahminlemelerinin hassaslaştırılması veya dahili yazılım ekiplerinin kod yazma hızının artırılması birbirinden tamamen farklı donanım, model ve lisans gereksinimleri doğurur. Kurumun çözmek istediği problem deterministik algoritmalar veya kural tabanlı geleneksel otomasyon sistemleri (RPA) ile çözülebiliyorsa, üretken yapay zeka modellerine yönelmek yalnızca bakım maliyetlerini ve hata olasılıklarını artıracaktır.

İş birimlerinden gelen taleplerin teknik fizibilitesi değerlendirilirken, çözümün hedefleyeceği etki alanı doğrudan ölçülebilir metriklerle desteklenmelidir. "Çalışan verimliliğini artırmak" gibi soyut gerekçeler, tedarik sürecinin bütçe onay aşamalarında tıkanmasına yol açar. Bunun yerine "Haftalık 1.200 saatlik manuel raporlama yükünün %60 oranında otonom hale getirilmesi" veya "Sözleşme inceleme sürelerinin vaka başına 4 saatten 25 dakikaya indirilmesi" gibi somut operasyonel hedefler konulmalıdır. Bu hedefler, daha sonra satıcılarla yapılacak pilot testlerin ve performans sözleşmelerinin temelini oluşturacaktır.

Kurumsal organizasyon yapısı içerisinde yapay zeka talebinin hangi merkezden yönetileceği netleştirilmelidir. Dağınık departmanların bağımsız olarak kredi kartlarıyla SaaS çözümleri satın alması (Shadow AI), veri güvenliği açıklarını ve kurum çapında kontrolsüz bütçe kullanımını tetikler. Bu nedenle Satın Alma Direktörlüğü, Bilgi Güvenliği (CISO) ve Hukuk birimlerinden oluşan ortak bir AI Tedarik Kurulu (AI Procurement Committee) tesis edilmeli, her talep bu kurulun belirlediği kontrol süzgecinden geçirilmelidir.

Hazır Çözümler (SaaS) ve Özel Geliştirme (RAG / Fine-tuning) Ayrımı

Kurumsal mimarların satın alma sürecinde vermesi gereken ilk yapısal karar, kullanıma hazır bir yapay zeka yazılımı (Off-the-shelf SaaS) edinmek ile kurumun kendi verileri üzerinde özelleştirilmiş bir mimari (In-house / Hybrid Development) inşa etmek arasındaki ayrımdır. Hazır SaaS çözümleri, minimum teknik eforla hızlı dağıtım imkanı sunarken, kurumun operasyonel süreçlerini sağlayıcının belirlediği sınırlar içine hapseder. Ayrıca bu platformlar, kurum içi özel bilgi bankalarına derin entegrasyonda yetersiz kalabilir.

Öte yandan, açık kaynaklı veya kapalı uçlu Büyük Dil Modelleri (LLM) kullanılarak kurgulanan RAG (Retrieval-Augmented Generation) mimarileri, şirket içi verilerin model ağırlıklarına doğrudan gömülmeden, dinamik vektör veri tabanları (Vector Databases) üzerinden modele beslenmesini sağlar. RAG sistemleri, modelin uydurma (halüsinasyon) riskini minimize ederken kurumun veri egemenliğini korur. Eğer kurumun kendine has bir endüstriyel jargonu, terminolojisi veya katı bir sınıflandırma metodolojisi bulunuyorsa, temel modellerin ince ayardan (Fine-tuning) geçirilmesi gerekebilir. Fine-tuning, yüksek hesaplama gücü (GPU kaynakları) ve temizlenmiş etiketli veri gerektirdiğinden, sadece SaaS ve RAG yapılarının yetersiz kaldığı uç senaryolarda tercih edilmelidir.

Toplam Sahip Olma Maliyeti (TCO) ve Gizli Giderler

Yapay zeka satın alma süreçlerinde yalnızca satıcının teklif ettiği taban lisans veya API fiyatlandırmasına odaklanmak, projelerin ilk mali yılda bütçe aşımıyla karşılaşmasının ana sebebidir. Toplam Sahip Olma Maliyeti (TCO), bir yapay zeka çözümünün tüm yaşam döngüsü boyunca yaratacağı doğrudan ve dolaylı giderlerin bütününü ifade eder. Bu hesaplamada görünmeyen maliyet katmanları göz ardı edilmemelidir.

Toplam maliyet projeksiyonu çıkarılırken aşağıdaki gider kalemleri 3 yıllık vadede simüle edilmelidir:

• Token Tüketim Değişkenliği: Girdi (input) ve çıktı (output) token maliyetleri kullanıcı sayısı veya işlem hacmi arttıkça doğrusal değil, logaritmik olarak tırmanabilir. Özellikle uzun bağlam pencereli (long-context window) modellerde her sorgu başına harcanan tutarlar operasyonel bütçeyi baskılayabilir.

• Vektör Veri Tabanı ve Altyapı Giderleri: Pinecone, Qdrant, Milvus veya AWS OpenSearch gibi vektör indexleme sistemlerinin barındırma, yedekleme ve sorgu başına maliyetleri.

• Veri Hazırlama ve Temizleme Maliyeti: Kurumun dağınık haldeki PDF, SQL ve intranet verilerinin etiketlenmesi, anonimleştirilmesi ve chunking (parçalama) süreçleri için harcanan mühendislik iş gücü.

• Gizil Gecikme (Latency) ve Donanım Masrafları: On-premise veya özel bulut (Dedicated Instance) kurulumlarında ihtiyaç duyulan enterprise-grade GPU kümelerinin (örn. NVIDIA H100, A100 serileri) enerji, soğutma ve kiralama bedelleri.

• Eğitim ve Adaptasyon Masrafları: Çalışanların prompt optimizasyonu, araç kullanımı ve denetim mekanizmalarına alıştırılması için harcanan zaman ve dış danışmanlık faturaları.

2. Adım: Teknik Değerlendirme ve Model Performans Kriterleri

Satıcıların sunduğu pazarlama odaklı benchmark verileri (MMLU, HumanEval veya GSM8K skorları), modelin kurumsal ortamdaki gerçek performansını yansıtmakta çoğunlukla yetersiz kalır. Akademik testlerde yüksek skorlar alan bir model, şirketin tescilli veri formatlarıyla karşılaştığında veya karmaşık SQL sorguları üretirken yüksek hata payı üretebilir. Bu nedenle teknik değerlendirme aşamasında satıcıdan bağımsız, kurumun kendi kullanım senaryolarından (use-case) türetilmiş test kümeleri (golden datasets) kullanılmalıdır.

Teknik inceleme sadece modelin zeka katsayısını değil; çıktı üretme hızını (Time-to-First-Token - TTFT), saniye başına üretilen token hacmini (Tokens Per Second - TPS) ve eşzamanlı kullanıcı (concurrency) baskısı altındaki dayanıklılığını kapsamalıdır. Canlı müşteri operasyonlarında çalışan bir yapay zeka aracının 15 saniye yanıt süresi üretmesi, model ne kadar doğru cevap verirse versin kullanıcı deneyimini tahrip eder. Bu nedenle latency-accuracy (gecikme-doğruluk) dengesi, kurumun operasyonel tolerans sınırlarına göre ağırlıklandırılmalıdır.

Model mimarisinin "kara kutu" (black box) olmasından kaynaklanan riskler teknik komite tarafından kayıt altına alınmalıdır. Modelin kararlarını hangi mantıksal referanslara dayandırdığını gösteren açıklanabilirlik (explainability) araçlarının, loglama altyapılarının ve denetim izlerinin (audit trails) varlığı sorgulanmalıdır. Bu parametreler, teknik satın almanın taviz verilemez çekirdek maddeleridir.

Doğruluk Limitleri ve Halüsinasyon (Uydurma) Riski Yönetimi

Üretken yapay zekanın doğasında bulunan olasılıksal (probabilistic) metin tamamlama mekanizması, modellerin gerçeğe aykırı bilgileri son derece ikna edici bir üslupla üretmesine (halüsinasyon) yol açar. Finans, sağlık, hukuk veya kurumsal muhasebe gibi hata toleransının sıfır olduğu kritik alanlarda bir modelin uydurma yapması, şirketi regülasyon cezaları veya doğrudan maddi kayıplarla karşı karşıya bırakır. Satın alma sürecinde satıcının halüsinasyon riskini nasıl sınırlandırdığı teknik olarak belgelenmelidir.

Satıcı platformun aşağıdaki koruma katmanlarını sağlayıp sağlamadığı kontrol edilmelidir:

1. Kaynak Atıflı Yanıt Üretimi (Grounding): Modelin ürettiği her cümlenin arkasındaki kurumsal kaynak dokümanı sayfa, paragraf ve link seviyesinde referans gösterebilmesi.

2. Korumalı Çit Mekanizmaları (Guardrails): NeMo Guardrails, Llama Guard veya benzeri güvenlik katmanlarıyla, modelin yetki alanı dışındaki sorulara yanıt vermesinin ve zararlı içerik üretmesinin yazılımsal düzeyde engellenmesi.

3. Güven Skoru Filtreleme: Modelin verdiği cevabın olasılık skorunu hesaplayarak, belirlenen eşik değerin (örn. %85 doğruluk) altındaki çıktıları otomatik olarak insan onay havuzuna yönlendirmesi.

4. Çıktı Determinizmi: Sıcaklık (temperature), top_p gibi parametrelerin sabitlenebilmesi ve API düzeyinde tekrarlanabilir (seed destekli) çıktılar alınabilmesi imkânı.

API Kullanımı ve Altyapı Entegrasyon Kabiliyeti

Bir yapay zeka çözümünün değeri, mevcut kurumsal mimariyle ne kadar pürüzsüz entegre olabildiğiyle doğru orantılıdır. Bağımsız bir portalda izole çalışan araçlar, kurum çalışanları tarafından hızla terk edilme eğilimindedir. Bu nedenle satın alınacak yapay zeka servisinin REST API, gRPC veya WebSocket uç noktaları ayrıntılı incelenmelidir. Model sağlayıcısının API sürümleme (versioning) ve kullanımdan kaldırma (deprecation) politikaları sözleşme öncesinde masaya yatırılmalıdır; sağlayıcının temel modeli aniden güncellemesi, kurumun downstream (bağlı) uygulamalarının bozulmasına sebep olabilir.

Kurumun mevcut SSO (Single Sign-On), IdP (Identity Provider - Okta, Microsoft Entra ID), SIEM (Splunk, QRadar) ve ERP/CRM ekosistemleriyle entegrasyon kabiliyeti aranmalıdır. Rol tabanlı erişim kontrolü (RBAC) desteği sunmayan, API anahtarlarının (API keys) güvenli kasalarda (Azure Key Vault, HashiCorp Vault) saklanmasına ve dinamik rotasyonuna izin vermeyen sistemler, kurumsal siber güvenlik mimarisine dahil edilmemelidir.

3. Adım: Veri Güvenliği, KVKK ve GDPR Uyumluluğu

Yapay zeka sistemleri, geleneksel yazılımlardan farklı olarak işledikleri veriyi yalnızca saklamakla kalmaz; çıkarım, indeksleme ve potansiyel olarak yeniden eğitim süreçlerine dahil edebilirler. Bu durum, Türkiye'de 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR), AB Yapay Zeka Yasası (EU AI Act) ve Birleşik Krallık ile BAE'deki yerel veri egemenliği yasaları ekseninde ciddi hukuki sorumluluklar doğurur. Bir yapay zeka satıcısının sistem mimarisi, şirket verilerini sınır ötesine taşıyor veya üçüncü taraf alt yüklenicilerin sunucularında önbelleğe alıyorsa, veri sorumlusu (data controller) sıfatıyla kurum doğrudan cezai yaptırımların muhatabı olur.

Tedarik sürecinde satıcının "Veri İşleme Sözleşmesi" (Data Processing Agreement - DPA) satır satır denetlenmelidir. Çoğu tüketici odaklı veya genel yapay zeka aracı, kullanıcıların girdiği istemleri (prompt) ve yüklediği belgeleri modellerini gelecekte eğitmek (training/fine-tuning) amacıyla kullanma hakkını sözleşmelerinde saklı tutar. Kurumsal satın almalarda bu madde kesin biçimde "Zero Data Retention" (Sıfır Veri Saklama) veya "No Training on Customer Data" (Müşteri Verisiyle Eğitmeme) maddesiyle değiştirilmelidir.

Veri yerleşimi (Data Residency) gereksinimleri de göz önünde bulundurulmalıdır. Finans, bankacılık ve telekomünikasyon gibi regüle sektörlerde çalışan şirketlerin, müşteri kimlik ve işlem verilerini ülke sınırları dışına çıkarması yasal olarak yasaklanmıştır. Bu bağlamda, sağlayıcının verileri yerel bölgede (örneğin Türkiye'deki yerel veri merkezlerinde veya ilgili regülasyonun zorunlu kıldığı coğrafi sınırlarda) işleyip işlemediği veya kurum içi (On-premise) / özel sanal bulut (VPC) kurulum seçenekleri sunup sunmadığı teyit edilmelidir.

ISO Standartları ve Kurumsal Veri Gizliliği

Kurumsal yapay zeka satın alımlarında teknik olgunluk, uluslararası standartlara uyum ile belgelenir. ISO/IEC 27001 (Bilgi Güvenliği Yönetim Sistemi), satıcının altyapısındaki temel siber güvenlik kontrollerini teyit ederken; yapay zeka özelinde yayınlanan ISO/IEC 42001 (Yapay Zeka Yönetim Sistemi) standardı, yapay zekanın etik kullanımı, risk değerlendirmesi ve algoritma yaşam döngüsü yönetimini standartlaştırır. Satıcının bu sertifikalara sahip olması, kurumsal denetim riskini minimize eder.

SOC 2 Type II denetim raporu da mutlaka talep edilmeli ve rapordaki "Güvenilirlik", "Gizlilik" ve "Erişilebilirlik" kriterlerinin istisnaları (exceptions) CISO ekibi tarafından incelenmelidir. Yalnızca sertifikanın kapağına bakmak yeterli değildir; satıcının yapay zeka modeli sağlayan üçüncü taraf API'leri (örneğin arka plandaki model tedarikçilerini) bu sertifika kapsamına alıp almadığı açıkça doğrulanmalıdır.

Üçüncü Taraf Model Sağlayıcılarında Veri Sızıntısı Riskleri

Birçok yapay zeka girişimi (wrapper SaaS), kendilerine ait tescilli bir model geliştirmek yerine OpenAI, Anthropic, Google veya Mistral gibi büyük sağlayıcıların API'lerini bir ara katman yazılımıyla kurumlara sunar. Bu tip dolaylı mimarilerde "üçüncü tarafın üçüncü tarafı" (Fourth-Party Risk) riski ortaya çıkar. Kurum verisi önce ara yazılıma, oradan da ana model sağlayıcısına iletilir. Bu zincirdeki herhangi bir halkanın zafiyeti veri sızıntısıyla sonuçlanabilir.

Dolaylı yapay zeka tedariklerinde şu riskler bertaraf edilmelidir:

• Prompt Injection Saldırıları: Kötü niyetli kullanıcıların veya manipüle edilmiş girdi verilerinin, modelin sistem yönergelerini geçersiz kılarak kurumun hassas verilerini dışarı sızdırması.

• Veri Maskeleme ve PII (Kişisel Bilgiler) Temizliği: Model girdisine gitmeden önce TC Kimlik Numarası, kredi kartı bilgisi, isim-soyisim veya sağlık verilerinin ara katmanda regex ve NLP tabanlı anonimleştirme araçlarıyla maskelenmesi zorunluluğu.

• API Loglama ve Sızma Testleri: Sağlayıcının API isteklerini ne kadar süreyle logladığı ve bağımsız etik hacker ekiplerine düzenli olarak sızma testi (Penetration Test) yaptırıp yaptırmadığı sorgulanmalıdır.

4. Adım: Pilot Çalışma (PoC) ve Canlı Performans Testi

Teknik ve yasal şartları karşılayan satıcılarla doğrudan uzun vadeli lisans anlaşmaları imzalamak ciddi bir finansal risktir. Kurumsal satın alma sürecinin dördüncü ve en belirleyici adımı, sınırları net olarak çizilmiş 4 ila 8 haftalık bir Pilot Çalışma (Proof of Concept - PoC) yürütmektir. PoC süreci, satıcının demo ortamlarında gösterdiği mükemmel senaryoların ötesine geçerek, platformun şirketin gerçek dünyadaki kirli, yapılandırılmamış ve eksik verileriyle nasıl başa çıktığını test etme fırsatı sunar.

PoC sürecinde satıcıya sentetik veya temizlenmiş veriler yerine, günlük operasyonun zorlayıcı örneklerini içeren kontrollü bir test veri seti sağlanmalıdır. Örneğin, taranmış düşük çözünürlüklü faturalar, yazım hatalarıyla dolu müşteri yazışmaları veya karmaşık ve birbiriyle çelişen şirket içi yönetmelik dokümanları bu test setine dahil edilmelidir. Amaç modeli başarısızlığa zorlamak ve sistemin sınırlarını, istisnai durumları (edge cases) ele alış biçimini net bir şekilde görmektir.

PoC sürecinin sonunda satıcının entegrasyon ekibinin reaksiyon hızı, teknik dokümantasyonun yeterliliği ve platformun stabilite performansı da puanlanmalıdır. Başarılı bir PoC yalnızca modelin doğruluğunu değil, satıcının kurumsal bir iş ortağı olarak teknik yetkinliğini ve destek kapasitesini de tescil eder.

Yapay Zeka Projelerinde KPI (Başarı Metrikleri) Belirleme

Bir yapay zeka PoC çalışmasının başarılı olup olmadığı genel kanılarla veya hislerle değil, önceden belirlenmiş matematiksel ve iş odaklı KPI'lar ile ölçülmelidir. "Sonuçlar oldukça iyi görünüyor" ifadesi satın alma masasında geçerli bir argüman değildir. Projenin türüne göre teknik performans ve iş etkisi metrikleri birbirini tamamlamalıdır.

Kurumsal karar vericilerin sözleşmeye bağlaması gereken temel yapay zeka KPI grupları şunlardır:

• Teknik Doğruluk Metrikleri:

• Precision ve Recall / F1-Score: Sınıflandırma ve veri çekme senaryolarında yanlış pozitiflerin ve yanlış negatiflerin dengesi.

• ROUGE ve BLEU Skorları: Özetleme ve çeviri görevlerinde model çıktısının insan uzman referansıyla semantik örtüşme oranı.

• Halüsinasyon Oranı (Hallucination Rate): Üretilen yanıtların kaynak metinle çelişme veya kaynaksız bilgi içerme yüzdesi (Kritik kurumsal süreçlerde %1'in altında olması hedeflenmelidir).

• Operasyonel ve İş Metrikleri:

• Görev Tamamlama Süresi (Time-to-Task-Completion): Bir çalışanın ilgili işi yapay zeka destekli ve desteksiz tamamlama süreleri arasındaki fark.

• İlk Temasta Çözüm Oranı (First Contact Resolution): Müşteri odaklı botlarda insan temsilciye aktarılmadan başarıyla sonuçlandırılan vaka oranı.

• Maliyet / Verimlilik Oranı: Yapay zeka sistemi için harcanan 1 birimlik maliyetin (lisans + token + altyapı), kaç birimlik insan iş gücü veya zaman tasarrufu yarattığı.

İnsan Denetimi (Human-in-the-Loop) İş Akışlarının Tasarımı

Yapay zeka modellerinin olasılıksal doğası gereği, kritik iş kararlarının hiçbir denetim olmadan %100 otonom biçimde modele bırakılması kurumsal bir intihardır. Satın alma sürecinde değerlendirilen platformun yerleşik bir İnsan Denetimi (Human-in-the-Loop - HITL) arayüzü ve onay iş akışı sunup sunmadığı kontrol edilmelidir. HITL mimarisi, yapay zekayı karar verici değil, uzman personele yardımcı bir koprofil (co-pilot) pozisyonunda konumlandırır.

İş akışı kurgulanırken modelin ürettiği çıktılara bir güven skoru (confidence score) atanmalıdır. Örneğin, güven skoru %90'ın üzerinde olan standart fatura işleme işlemleri doğrudan muhasebe sistemine aktarılabilirken; skoru %70-%90 arasında kalan işlemler insan operatörün onay ekranına "inceleme" etiketiyle düşmeli, %70'in altındaki vakalar ise doğrudan manuel sürece yönlendirilmelidir. Satın alınacak platformun bu kademeli yönlendirme kurallarını kod yazmaya gerek kalmadan (no-code / low-code) kural motorlarıyla yönetmeye imkân tanıması operasyonel çeviklik kazandırır.

5. Adım: Hukuki Sözleşmeler, SLA Şartları ve Satıcı Değerlendirmesi

Geleneksel yazılım sözleşmeleri, yapay zekanın dinamik ve belirsiz doğasını kapsamakta yetersiz kalır. Bir ERP veya CRM yazılımının çalışıp çalışmadığı ikili mantıkla (açık/kapalı, hata veriyor/vermiyor) belirlenebilirken; bir yapay zeka modelinin "çalışması" ama "saçmalaması" veya "yanlış kararlar alması" gri bir alan yaratır. Bu nedenle yapay zeka satın alma sözleşmeleri, klasik SLA (Service Level Agreement) şablonlarının çok ötesine geçen özel maddeler içermelidir.

Hukuk ve satın alma departmanları, satıcının sunduğu standart kullanıcı sözleşmesini (EULA) kabul etmek yerine, kurumsal riskleri satıcıya rücu eden özel ek protokoller (Addendum) talep etmelidir. Fikri mülkiyet hakları (IP Rights), bu sözleşmelerin en can alıcı maddesidir. Modelin girdi olarak aldığı kurum verilerinin ve model tarafından üretilen çıktıların tüm mülkiyetinin kayıtsız şartsız müşteriye ait olduğu sözleşmede açıkça belirtilmelidir. Ayrıca modelin eğitim verilerinden kaynaklanan olası telif hakkı ihlallerine karşı satıcının kurumu koruyacağını taahhüt eden bir "Telif Tazminat Maddesi" (Copyright Indemnification) mutlaka sözleşmeye eklenmelidir.

Satıcı bağımlılığı (Vendor Lock-in) riski de sözleşme aşamasında bertaraf edilmelidir. Satıcının iflas etmesi, fahiş fiyat artışlarına gitmesi veya hizmeti durdurması ihtimaline karşı; kurumun biriktirdiği vektör verilerini, prompt şablonlarını, fine-tuning ağırlıklarını ve kullanıcı geri bildirim verilerini standart açık formatlarda (JSON, Parquet vb.) eksiksiz geri alabilme garantisi bağlanmalıdır.

Yapay Zeka Odaklı SLA Kriterleri

Geleneksel SLA sözleşmelerinde yer alan "%99.9 Uptime" taahhüdü, yapay zeka sistemleri için tek başına anlamsızdır. Sunucusu ayakta olan ancak yanıt süresi 45 saniyeye fırlamış veya parametre kayması (model drift) nedeniyle yanıt doğruluğu yarı yarıya düşmüş bir model teknik olarak uptime kriterini karşılıyor görünür; fakat iş operasyonunu fiilen durdurur.

Yapay zeka satın alımlarında sözleşmeye dahil edilmesi gereken yeni nesil SLA bileşenleri şunlardır:

• Gecikme (Latency) SLA: P95 ve P99 gecikme sürelerinin belirlenmesi (Örneğin: İsteklerin %95'inin 2.5 saniyenin altında yanıtlanması garantisi).

• Kullanılabilirlik ve Kota (Rate Limit) Garantisi: Yoğun saatlerde kurumun API isteklerinin "Rate Limit Exceeded" (429) hatası almayacağının ve taahhüt edilen TPM (Token Per Minute) / RPM (Request Per Minute) değerlerinin garanti edilmesi.

• Model Sürüm Sabitleme (Model Version Pinning): Satıcının mevcut çalışan model sürümünü en az 12 ay boyunca haber vermeksizin değiştiremeyeceği veya kullanımdan kaldıramayacağı taahhüdü.

• Model Bozulması (Model Drift) Müdahale Süresi: Model çıktılarındaki doğruluk kaybının belirlenen referans skorun altına düşmesi durumunda satıcının mühendislik ekibinin en geç 24 saat içinde müdahale etme yükümlülüğü.

6. Adım: Kurumsal Yaygınlaştırma, Değişim Yönetimi ve Sık Yapılan Hatalar

Teknolojinin satın alınması, sürecin sadece ilk yarısıdır. En pahalı ve teknik olarak en yetkin yapay zeka araçları dahi, şirket çalışanları tarafından benimsenmediği takdirde başarısız birer bilanço yüküne dönüşür. Kurumsal yaygınlaştırma (rollout), aşamalı bir değişim yönetimi stratejisiyle yürütülmelidir. Tüm şirkete aynı gün binlerce lisans dağıtmak yerine; pilot departmanlar, süreci sahiplenecek "yapay zeka şampiyonları" (AI Champions) belirlenmeli ve yatay genişleme bu çekirdek ekiplerin başarı hikayeleri üzerinden kurgulanmalıdır.

Eğitim programları araçların sadece nasıl kullanılacağını değil; istem mühendisliğinin (prompt engineering) inceliklerini, modelin sınırlarını, güvenlik ilkelerini ve halüsinasyonların nasıl tespit edileceğini içermelidir. Çalışanlar, yapay zekanın kendi işlerini ellerinden alacak bir tehdit değil, operasyonel angaryalarını devralan bir verimlilik asistanı olduğunu hissetmelidir. Bu psikolojik bariyer aşılmadığı sürece kurum içi direnç projelerin atıl kalmasına neden olur.

Satın alma sonrası süreçte düzenli denetim mekanizmaları canlı tutulmalıdır. Hangi departmanın aracı ne sıklıkla kullandığı, hangi iş akışlarında verimlilik sağlandığı ve kullanıcıların verdiği geri bildirimler (thumbs up/down logları) düzenli olarak izlenmeli, beklenen ROI hedeflerinin altında kalan lisanslar derhal optimize edilmelidir.