CIO'lar için yapay zekâ yol haritası: 90 günde ilk üretim projesi

Yapay zekâda ilk üretim projesi; tek bir iş problemini ölçülebilir biçimde çözen, gerçek kullanıcıların her gün kullandığı ve BT’nin işletebildiği bir sistemdir. Demo değildir, süresiz uzayan bir pilot hiç değildir. Doğru kapsamla bu hedefe 90 günde ulaşmak mümkün.

2012–2021 arasında Civil Mağazacılık’ta Bilgi Teknolojileri Bölüm Başkanı olarak çalıştım, 2021’de CX Teknoloji’yi kurdum ve 2022’de HD Holding’de IT Manager olarak görev yaptım. Yani hem BT projelerini onaylayan hem de yapay zekâ çözümü sunan tarafta oturdum. Bu yazı bir vaka anlatısı değil, bu iki taraftan çıkardığım ilkelerin uygulanabilir bir plana dökülmüş hâli; genel çerçeveyi BT yöneticiliğinden girişimciliğe geçiş yazısında anlatmıştım.

Neden 90 gün?

Doksan gün, dar kapsamlı bir işi üretime almaya yetecek kadar uzun, sponsorun ilgisini kaybetmeyeceği kadar kısa. Bir çeyreğe denk geldiği için iş birimlerinin raporlama döngüsüyle de örtüşüyor. En önemlisi kapsam disiplini dayatıyor: kapsam 90 güne sığmıyorsa sorun süre değil, kapsamdır.

Adım 1: Kullanım senaryosu nasıl seçilir?

Aday listesini değer ve uygulanabilirlik açısından ayrı ayrı puanlayın. Her ölçüt 1–5 arası puanlanabilir:

Eksen	Ölçüt	Sorulacak soru
Değer	İş etkisi	Başarılı olursa hangi iş metriği, ne kadar değişir?
Değer	Sıklık	Bu iş ya da karar ne sıklıkla tekrarlanıyor?
Değer	Sahiplik	Sonucu isteyen ve ölçecek bir iş birimi yöneticisi var mı?
Uygulanabilirlik	Veri	Gerekli veri var mı, erişilebilir mi, kalitesi yeterli mi?
Uygulanabilirlik	Entegrasyon	Sonuç hangi sisteme, hangi ekrana düşecek?
Uygulanabilirlik	Hata toleransı	Model yanıldığında maliyet ne, insan düzeltebiliyor mu?
Uygulanabilirlik	Regülasyon	KVKK ya da AB Yapay Zekâ Yasası açısından yüksek risk var mı?

Puanlar iki eksende bir matrise yerleşir:

	Uygulanabilirlik yüksek	Uygulanabilirlik düşük
Değer yüksek	İlk proje adayı	Stratejik yatırım: önce veri ve altyapı
Değer düşük	Hızlı deneme; ilk proje için zayıf	Listeden çıkarın

Aşağıdaki puanlama tamamen örnektir; kendi şirketinizde iş sahipleriyle birlikte yapılmalı:

Aday senaryo	Değer	Uygulanabilirlik	Not
BT yardım masası talep sınıflandırma ve çözüm taslağı	Orta	Yüksek	Veri bilet sisteminde hazır, hata geri alınabilir
İç prosedürler için doküman asistanı	Orta–yüksek	Yüksek	Doküman sahipliği şart
Mağazada kişi sayma ve kuyruk uyarısı	Yüksek	Orta–yüksek	Mevcut kameralar kullanılır; KVKK tasarımı baştan yapılır
Tedarikçi faturası ile sipariş eşleştirme	Yüksek	Orta	ERP entegrasyonu belirleyici
İşe alımda aday eleme	Değişken	Düşük	AB Yapay Zekâ Yasası’nda yüksek risk; ilk proje olmaz

Doküman asistanı seçilirse mimari için kurumsal RAG yazısına bakabilirsiniz.

Adım 2: Veri hazırlığı için beş soru

1. Veri nerede ve sahibi kim? Sahibi olmayan veri projesi durdurur; ilk hafta her veri kaynağına bir sahip yazın.
2. Tanım net mi? “Aktif müşteri” ya da “tamamlanmış sipariş” her birim için aynı anlama geliyor mu? Modelden önce tanımlarda uzlaşın.
3. Kalite yeterli mi? Eksik alan, tekrar eden kayıt ve gecikmeli veri oranını ölçün.
4. Hukuki sebep ve erişim var mı? Kişisel veri gerçekten gerekli mi, anonimleştirilebilir mi, hangi hukuki sebeple işleniyor?
5. Üretimde veri nasıl akacak? Tek seferlik dışa aktarımla model eğitilir ama sistem işletilemez; sürekli çalışan bir veri akışı tasarlayın.

İkinci soru benim için en önemlisi. Civil’deki Nebim V3 veri ambarı ve iş zekâsı çalışması yaklaşık 4,5 TB veriyle çalışıyordu; o ölçekte bile benim deneyimimde tartışmaların çoğu teknolojiden değil, tanımlardan çıkar.

Adım 3: Yap, satın al ya da ortaklık?

Bir ürün şirketinin kurucusu olarak bu konuda tarafsız olmadığımı baştan söyleyeyim. Yine de kullandığım ölçütler şunlar:

Ölçüt	Yap	Satın al (hazır ürün)	Ortaklık (uzman firma)
Ne zaman?	Yetenek rekabet avantajı oluşturacak, iç ekip var	Standart problem, pazarda olgun ürün var	Alan uzmanlığı gerekli, veri ve süreç size özgü
Hız	Yavaş	Hızlı	Orta–hızlı
Veri kontrolü	Tam	Tedarikçiye bağlı	Sözleşmeyle belirlenir
Uzun vadeli maliyet	İç ekip ve bakım	Lisans ya da kullanım bedeli	Proje ve bakım bedeli
Ana risk	Yetkinlik ve süre	Bağımlılık, özelleştirme sınırı	Bilgi transferinin yapılmaması

Hangi yol seçilirse seçilsin sözleşmede şunlar yazılı olmalı: verinin ve eğitilen modelin kime ait olduğu, çıkışta verinin nasıl teslim edileceği, hizmet seviyesi, KVKK kapsamındaki veri işleyen yükümlülükleri ve AB’ye satış varsa AB Yapay Zekâ Yasası dokümantasyonu.

Adım 4: 0–30, 30–60, 60–90 gün planı

Dönem	Hedef	Ana işler	Karar kapısı
0–30 gün	Problemi ve başlangıcı sabitlemek	İş sahibi ve ürün sahibi atanır; başlangıç ölçümü alınır; veri erişimi açılır; KVKK ve AB Yapay Zekâ Yasası ön sınıflandırması yapılır; yap-al kararı verilir; değerlendirme seti hazırlanır	Veri erişilebilir ve başlangıç ölçülmüş mü? Değilse durun.
30–60 gün	Gerçek veriyle çalışan ilk sürüm	Tek bir sistemle entegrasyon; değerlendirme setinde ölçüm; güvenlik ve yetki incelemesi; küçük bir kullanıcı grubuyla gölge çalışma	Kalite hedefe yaklaşıyor mu, kullanıcılar kullanıyor mu?
60–90 gün	Üretime almak ve karar vermek	İzleme ve alarm; işletim el kitabı (runbook); servis masası ve olay yönetimine dahil etme; eğitim; pilot gruptan genişletme; başlangıç ölçümüyle karşılaştırma	Ölçekle, iyileştir ya da durdur

Gölge çalışmada sistem önerisini üretir ama karar yine insandadır; öneriyle gerçek kararı karşılaştırırsınız. Bu aşama hem kaliteyi ölçer hem de kullanıcının sisteme güven duymasını sağlar. Durdurma kararı da başarılı bir sonuçtur: 90 günde öğrenilmiş ve bütçe korunmuştur.

Başarı metrikleri

Katman	Metrik	Örnek
İş sonucu	Süre, maliyet, hata, gelir	Talep çözüm süresi, kuyrukta bekleme süresi
Kullanım	Aktif kullanıcı, öneri kabul oranı	Önerilerin ne kadarı değiştirilmeden kabul ediliyor?
Model kalitesi	Doğruluk, kesinlik, duyarlılık, sadakat	Değerlendirme setinde ölçülen doğruluk
İşletim	Erişilebilirlik, gecikme, birim maliyet	İstek başına maliyet, yanıt süresi

Model doğruluğu bir iş metriği değildir. Örneğin kişi sayma ürünümüzde sahada %96,2’ye ulaşan doğruluk bir model metriği; perakendecinin asıl sorusu bu sayının personel planlamasını ne kadar iyileştirdiğidir. İş sahibiyle tek bir ana metrikte uzlaşın ve başlangıç ölçümünü ilk 30 günde alın.

Yönetişim: COBIT ve ITIL bağlantısı

Yapay zekâ için ayrı bir bürokrasi kurmayın; mevcut BT yönetişimine yapay zekâya özgü kontroller ekleyin. COBIT 5 ve ITIL sertifikalı biri olarak önerdiğim eşleştirme:

Yapay zekâ ihtiyacı	COBIT 2019 hedefi	ITIL 4 uygulaması
Politika, roller, karar hakları	EDM01 – Yönetişim çerçevesinin kurulması ve sürdürülmesi	—
Senaryo portföyü ve önceliklendirme	APO05 – Portföy yönetimi	Portföy yönetimi
Yanlılık, hata ve regülasyon riski	APO12 – Risk yönetimi	Risk yönetimi
Veri sahipliği ve kalitesi	APO14 – Veri yönetimi	—
Kullanıcıların benimsemesi	BAI05 – Örgütsel değişim	Örgütsel değişim yönetimi
Proje yürütme	BAI11 – Proje yönetimi	Proje yönetimi
Model ve istem değişiklikleri, canlı işletim	—	Değişiklik yönetimi (change enablement), olay yönetimi, izleme ve olay yönetimi, hizmet seviyesi yönetimi

Yapay zekâya özgü risk dili için NIST’in 26 Ocak 2023’te yayımladığı, gönüllü kullanıma yönelik AI Risk Yönetim Çerçevesi (dört işlevi: Govern, Map, Measure, Manage) ve yapay zekâ yönetim sistemi standardı ISO/IEC 42001:2023 iyi referanslardır. AB’ye ürün ya da hizmet sunuyorsanız AB Yapay Zekâ Yasası rehberindeki kontrol listesini aynı envantere bağlayın. COBIT’in genel çerçevesi için COBIT 5’ten COBIT 2019’a yazısına bakabilirsiniz.

Değişim yönetimi

Kullanıcının ilk sorusu “bu sistem işimi alacak mı” olur. Cevabı tasarım vermeli: ilk sürümde sistem önerir, insan karar verir. Kilit kullanıcıları ilk günden projeye alın, onların sorunlarını çözen özellikleri öne çekin ve sistemin neyi yapmadığını da eğitimde açıkça anlatın.

Benimsemenin teknolojiden çok ihtiyaca bağlı olduğunu Civil’de gördük. Nebim V3 fastPay ile kare kodla temassız ödemeyi 2019’da pilot mağazalarda denemeye başladık. Finansal kuruluşların analizlerine göre o yıl her 10 satıştan biri temassızdı; pandemide bu oran her iki satıştan birine çıktı ve entegrasyonu kısa sürede tüm mağazalardaki 400’den fazla ödeme noktasına yaydık. Teknoloji aynıydı; değişen, kullanıcının ihtiyacıydı. Yapay zekâ projesinde de kullanıcıya her gün yaşadığı bir sorunu çözdüğünü göstermeden benimseme beklemeyin.

Bütçe kalemleri

Kalem	İçerik	Sık atlanan nokta
Model/API ya da lisans	Token kullanımı, kullanıcı başı lisans	Kullanım arttıkça doğrusal artan maliyet
Altyapı	GPU sunucu, bulut, depolama	Test ve üretim ortamlarının ayrı olması
Veri hazırlığı	Temizleme, etiketleme, tanım çalışması	Çoğu zaman en büyük iş kalemi
Entegrasyon	ERP, CRM ve diğer sistemlere bağlantı	Kaynak sistem ekibinin zamanı
Güvenlik ve uyum	KVKK, AB Yapay Zekâ Yasası, sızma testi	Hukuk incelemesinin süresi
İnsan	Ürün sahibi, veri mühendisi, iş birimi zamanı	İş biriminden ayrılan zamanın bedeli
Değişim ve eğitim	Eğitim, iletişim, kilit kullanıcılar	Çoğu zaman sıfır yazılır
İşletim	İzleme, model güncelleme, destek	Canlıya alındıktan sonraki yıllar

Önerim: ilk 90 günün bütçesini proje olarak, sonrasını ayrı bir işletim bütçesi olarak planlayın ve baştan bir “durdurma eşiği” belirleyin.

Tipik hatalar

• Teknolojiyle başlamak: “Bize de bir büyük dil modeli lazım” bir problem tanımı değildir.
• Başlangıç ölçümü almamak: Sonra başarıyı kanıtlayamazsınız.
• Pilotu demo ortamında, gerçek veri ve gerçek kullanıcı olmadan yapmak.
• İş sahibi olmayan bir BT projesi başlatmak.
• Aynı anda çok sayıda pilot açıp hiçbirini üretime almamak.
• Hukuk ve güvenliği son haftaya bırakmak.
• Canlıya aldıktan sonra sistemi sahipsiz bırakmak: veri değiştikçe model kalitesi zamanla düşer; izleme ve yeniden eğitim sorumlusu baştan belli olmalı.

Kontrol listesi

• İş sahibi ve ürün sahibi atandı.
• Senaryo değer × uygulanabilirlik matrisiyle seçildi.
• Başlangıç ölçümü alındı; tek bir ana metrik üzerinde uzlaşıldı.
• Veri sahibi, tanımlar ve hukuki sebep netleşti.
• Yap-al-ortaklık kararı ve sözleşme koşulları yazıldı.
• 30, 60 ve 90. gün karar kapıları takvimde.
• Yönetişim mevcut COBIT ve ITIL süreçlerine bağlandı.
• İşletim bütçesi ve durdurma eşiği belirlendi.