---
title: "CIO'lar için yapay zekâ yol haritası: 90 günde ilk üretim projesi"
author: "Abdulaziz Akyol"
author_url: https://www.abdulazizakyol.com/hakkimda/
url: https://www.abdulazizakyol.com/blog/cio-lar-icin-yapay-zeka-yol-haritasi-90-gunde-ilk-uretim-projesi/
language: tr
published: 2026-09-25
categories: ["Liderlik", "Yapay zekâ"]
tags: ["yapay zekâ stratejisi", "CIO", "BT yönetişimi", "COBIT 2019", "ITIL 4", "değişim yönetimi"]
translation: https://www.abdulazizakyol.com/en/blog/ai-roadmap-for-cios-first-production-project-in-90-days/
description: "CIO'lar için 90 günde ilk yapay zekâ üretim projesi: senaryo seçme matrisi, veri hazırlığı, yap-al kararı, 30-60-90 gün planı, metrikler, yönetişim ve bütçe."
---

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

Yazar: [Abdulaziz Akyol](https://www.abdulazizakyol.com/hakkimda/) · 2026-09-25

## Öne çıkanlar

- 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 ya da süresiz pilot değildir.
- Kullanım senaryosu, iş değeri ile uygulanabilirliğin (veri hazırlığı, entegrasyon, hata toleransı, regülasyon riski, sahiplik) birlikte puanlandığı bir matrisle seçilmelidir.
- 90 günlük plan üç karar kapısına bölünür: ilk 30 günde problem, veri erişimi ve başlangıç ölçümü; 30–60 günde gerçek veriyle çalışan ilk sürüm; 60–90 günde işletime alma ve ölçekle, iyileştir ya da durdur kararı.
- Yapay zekâ yönetişimi için yeni bir bürokrasi kurmak gerekmez; COBIT 2019 hedeflerine ve ITIL 4 uygulamalarına yapay zekâya özgü kontroller eklemek iyi bir başlangıçtır.
- Yapay zekâ bütçesinde en sık atlanan kalemler veri hazırlığı, entegrasyon, değişim yönetimi ve canlıya alındıktan sonraki işletim maliyetidir.

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](https://www.abdulazizakyol.com/blog/kurumsal-bt-yoneticiliginden-ai-girisimciligine-bes-yilda-ogrendiklerim/) 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](https://www.abdulazizakyol.com/blog/kurumsal-rag-sirket-dokumanlariyla-konusan-yapay-zeka-asistani/) 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](https://www.nist.gov/itl/ai-risk-management-framework) (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](https://www.abdulazizakyol.com/blog/ab-yapay-zeka-yasasi-eu-ai-act-turk-sirketleri-icin-uyum-rehberi/) kontrol listesini aynı envantere bağlayın. COBIT'in genel çerçevesi için [COBIT 5'ten COBIT 2019'a yazısına](https://www.abdulazizakyol.com/blog/cobit5/) 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.

## Sık sorulan sorular

### Yapay zekâ projesine nereden başlanmalı?

Teknolojiden değil, sahibi olan ve ölçülebilen bir iş probleminden başlanmalı. Adaylar iş değeri ve uygulanabilirlik açısından puanlanır; ilk proje için hem değeri hem uygulanabilirliği yüksek, verisi erişilebilir ve hatası geri alınabilir bir senaryo seçilir. Başlamadan önce mevcut durumun ölçümü alınır.

### Yapay zekâ projesinde yap mı satın al mı kararı nasıl verilir?

Yetenek şirketin rekabet avantajını oluşturacaksa ve iç ekip varsa geliştirmek; herkesin benzer biçimde çözdüğü standart bir problemse hazır ürün almak; alan uzmanlığı gerekiyor ama veri ve süreç şirkete özgüyse uzman bir firmayla ortaklık kurmak mantıklıdır. Her durumda veri sahipliği, çıkış koşulları ve bilgi transferi sözleşmeye yazılmalıdır.

### Yapay zekâ projesinin başarısı nasıl ölçülür?

Dört katmanda: iş sonucu (süre, maliyet, hata), kullanım (aktif kullanıcı, öneri kabul oranı), model kalitesi (değerlendirme setindeki doğruluk) ve işletim (erişilebilirlik, gecikme, birim maliyet). Model doğruluğu tek başına başarı ölçütü değildir; asıl ölçüt, başlangıç ölçümüne göre değişen iş metriğidir.

### Yapay zekâ yönetişimi COBIT ve ITIL ile nasıl bağlanır?

Politika ve karar hakları COBIT 2019'daki EDM01, senaryo önceliklendirme APO05, risk kaydı APO12, veri sahipliği APO14, benimseme BAI05 ve proje yürütme BAI11 altında ele alınabilir. Canlı işletim ise ITIL 4'teki değişiklik yönetimi, olay yönetimi, izleme ve hizmet seviyesi yönetimi uygulamalarına bağlanır.

### Yapay zekâ projeleri neden pilot aşamasında kalır?

En sık nedenler iş sahibinin olmaması, başlangıç ölçümünün alınmaması, pilotun gerçek veri ve gerçek kullanıcı olmadan demo ortamında yapılması, veri hazırlığının küçümsenmesi ve canlıya alındıktan sonra sistemin sahipsiz kalmasıdır.

## Kaynaklar

1. [NIST AI Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/itl/ai-risk-management-framework)
2. [ISO/IEC 42001:2023 – AI management systems](https://www.iso.org/standard/42001)
3. [ISACA, COBIT](https://www.isaca.org/resources/cobit)
4. [Avrupa Komisyonu, AI Act – Regulatory framework for AI](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

---

Abdulaziz Akyol, CX Teknoloji'nin (yapay zekâ, görüntü işleme ve IoT) kurucusudur. Asıl sürüm: https://www.abdulazizakyol.com/blog/cio-lar-icin-yapay-zeka-yol-haritasi-90-gunde-ilk-uretim-projesi/
