CTO İçin Yapay Zekâ Yol Haritası: Pilottan Ölçeğe 12 Ay

CTO için 12 aylık yapay zekâ yol haritası: envanter, pilot, ortak platform ve ölçekleme adımları, mimari kararların zamanlaması ve ekip planı.

Yazar: Abdulaziz Akyol · Kurucu ve CEO, CX Teknoloji

CTO için yapay zekâ yol haritası, ilk pilotu seçmekten birden fazla uygulamanın üretimde güvenle çalışmasına kadar geçen süreci veri, altyapı, ekip, güvenlik ve işletme adımlarıyla zamana yayan teknik plandır. Önerdiğimiz 12 aylık çerçevede ilk çeyrek temel ve seçim, ikinci çeyrek pilot, üçüncü çeyrek ortak platform, dördüncü çeyrek ölçekleme ve devirdir.

Bu yazı, yönetim kurulundan “yapay zekâ planımız ne?” sorusunu almış bir CTO ya da BT direktörü için yazıldı. Yönetimin sorması gereken soruları CEO için yapay zekâ stratejisi yazısında topladık; burada aynı kararın teknik karşılığını çeyrek çeyrek ele alıyoruz. Süreler bir yöntem önerisidir; şirketin veri durumuna ve ekip kapasitesine göre kayabilir.

Bu yol haritası neyi varsayıyor?

Plan, orta ya da büyük ölçekli bir üretim veya lojistik şirketini varsayar: çalışan bir ERP, kısmen dijital üretim verisi (MES, SCADA ya da Excel), küçük bir BT ekibi ve henüz üretimde çalışan bir yapay zekâ uygulamasının olmaması. Hedef, 12 ayın sonunda en az iki uygulamanın iş birimlerinin günlük akışında kullanılması ve üçüncüsünün daha kısa sürede devreye alınmasını sağlayacak ortak altyapının kurulmuş olmasıdır.

Şirkette uzman yapay zekâ ekibi yoksa ilk aylarda dış destek alınır. Burada dikkat edilecek nokta, desteğin şirket içinde yetkinlik bırakacak şekilde kurgulanmasıdır. CX Teknoloji'nin yapay zekâ danışmanlığı bu nedenle çalışan bir pilot ve yazılı bir devir planıyla tamamlanır.

0–3. ay: envanter, veri erişimi ve ilk pilotun seçimi

• Kullanım senaryosu envanteri: İş birimleriyle görüşüp aday işleri listeleyin; her biri için iş değeri, veri durumu, hata maliyeti ve iş sahibini not edin.
• Veri erişim haritası: Hangi veri hangi sistemde (ERP, MES, SCADA, kalite, doküman yönetimi), hangi yöntemle okunabiliyor (veritabanı görünümü, API, dosya aktarımı) ve sahibi kim?
• Veri sınıflandırması: Hangi veri sınıfı bulut hizmetine gidebilir, hangisi şirket içinde kalmalı? Kişisel veri içeren senaryolar ayrıca işaretlenir.
• İlk pilotun seçimi ve ölçütü: Bir senaryo seçilir, başlangıç değeri ölçülür, başarı ve durdurma eşiği yazılır.
• Kullanım kuralları: Çalışanların genel amaçlı araçları hangi verilerle kullanabileceği yazılı hale getirilir.

Bu dönemin en sık hatası, veri erişimini pilot başladıktan sonra çözmeye çalışmaktır. ERP veritabanına okuma yetkisi, MES'ten veri aktarımı ya da dosya sunucusundaki dokümanların toplanması kurum içinde onay gerektirir ve haftalar alabilir. Bu işleri pilottan önce başlatmak takvimi korur.

Aynı dönemde kısa bir altyapı envanteri de gerekir: mevcut sunucularda GPU var mı, sanallaştırma platformu yapay zekâ iş yüklerini taşıyabilir mi, güvenlik duvarı kuralları bulut servislerine erişime izin veriyor mu, üretim ağındaki kameralara ya da makinelere hangi ağdan ulaşılıyor? Bu cevaplar henüz bir yatırım kararı için değil, pilotun nerede ve nasıl çalışacağını belirlemek için gereklidir.

3–6. ay: pilotu sahada çalıştırmak ve ölçmek

Pilot, gerçek kullanıcıların gerçek iş akışında kullandığı bir sistemdir. Test ortamında iyi sonuç veren bir model sahada farklı ışıkla, farklı belge formatıyla ya da farklı kullanıcı alışkanlığıyla karşılaşır. Bu yüzden pilotun ilk haftaları ölçümden çok gözlemle geçer: kullanıcı öneriyi nerede reddediyor, sistem hangi durumda yanılıyor, hangi veri eksik?

İlk pilotlarda insan onaylı akış önerilir: model öneri üretir, kullanıcı onaylar ya da düzeltir, her düzeltme kayda geçer. Bu kayıtlar hem doğruluğun ölçülmesini hem de modelin iyileştirilmesini sağlar. Şirket dokümanlarından cevap veren bir asistan kuruluyorsa cevabın kaynak belgeyi göstermesi, kullanıcının sonucu doğrulayabilmesi için şarttır; bu yaklaşımın teknik temeli RAG nedir yazısında anlatılıyor.

Altıncı ayın sonunda yönetime sunulacak tablo nettir: başlangıç değeri, ölçülen değer, harcanan bütçe, karşılaşılan sorunlar ve ölçekleme önerisi.

6–9. ay: ikinci senaryo ve ortak platform

İkinci proje, yol haritasının asıl sınavıdır. İlk pilotun her bileşeni o projeye özel yazıldıysa ikinci proje sıfırdan başlar. Bu dönemde ilk pilottan tekrar kullanılabilecek parçalar ayrılır ve ortak platform haline getirilir:

• Veri katmanı: ERP, MES ve diğer kaynaklardan düzenli veri akışı; ortak ürün, makine ve vardiya tanımları.
• Kimlik ve yetki: Kullanıcının yapay zekâ asistanında yalnızca kendi yetkisindeki belgeleri görmesi.
• Model ve sürüm yönetimi: Hangi modelin hangi sürümünün nerede çalıştığı ve ne zaman güncellendiği.
• İzleme ve kayıt: Her istek, cevap, kullanıcı düzeltmesi ve hata için denetlenebilir kayıt.

İkinci senaryonun ilkinden farklı türde seçilmesi platformu sınar. İlk pilot bir doküman asistanıysa ikincisi bir sınıflandırma ya da görüntü işleme uygulaması olabilir. Sahaya çıkan modellerin yaşam döngüsünün nasıl yönetileceğini MLOps yazısında ele aldık.

9–12. ay: ölçekleme, işletme ve devir

Ölçekleme, aynı uygulamanın başka hatlara, tesislere ya da birimlere yayılmasıdır ve kendine özgü sorunlar getirir. Her tesisin süreç alışkanlıkları, veri kalitesi ve ağ altyapısı farklıdır. Pilotta elle yapılan işler (veri temizliği, eşik ayarı, kullanıcı eğitimi) tekrar edilebilir prosedürlere dönüşmelidir. Bu geçişin ayrıntısı pilottan ölçeğe yazısında.

Bu dönemde işletme modeli de netleşir: sistem çöktüğünde kim aranır, model performansı düştüğünde kim fark eder, yeni bir kullanıcı nasıl eklenir, model güncellemesi kimin onayıyla yayına alınır? Dış destekle kurulan sistemler için devir planı burada uygulanır ve şirketin kendi ekibi sistemi işletebilir hale gelir.

Hangi mimari karar ne zaman verilmeli?

CTO'ların sık zorlandığı konu, hangi kararın erken, hangisinin geç verilmesi gerektiğidir. Erken verilen altyapı kararı ihtiyaçla uyuşmayabilir; geç verilen veri kararı ise takvimi kaydırır. Aşağıdaki tablo bir öneri çerçevesidir.

Görüntü işleme gibi düşük gecikme isteyen işlerde altyapı tercihinin mantığını edge mi bulut mu yazısında anlattık. Kişisel veri işleyen senaryolarda mimari, KVKK ilkelerine göre veri en aza indirilerek ve erişim rolle sınırlandırılarak tasarlanır. Bu genel bilgidir, hukuki danışmanlık yerine geçmez.

Ekip: kimi, ne zaman işe almalı?

Yapay zekâ ekibini ilk günden kurmak cazip gelir, ama ilk aylarda en çok ihtiyaç duyulan yetkinlik veri mühendisliğidir: verinin kaynak sistemlerden düzenli ve güvenilir şekilde alınması. Model geliştirme uzmanlığı başlangıçta dış destekle karşılanabilir. Pratik bir sıralama şöyledir:

1. İlk 3 ay: İç ekipten bir sorumlu (BT ya da süreç geliştirmeden) ve her iş biriminden bir anahtar kullanıcı.
2. 3–6. ay: Veri mühendisliği yetkinliği; iç işe alım ya da dış destekle yan yana çalışan bir iç kişi.
3. 6–12. ay: Ölçekleme kararına göre bir makine öğrenmesi ya da yapay zekâ uygulama mühendisi ve sistemin işletmesinden sorumlu bir rol.

Dış destek alınıyorsa her aşamada iç ekipten birinin işi birlikte yapması devir planının parçası olmalıdır. Aksi halde on ikinci ayın sonunda sistem çalışır, ama nasıl çalıştığını şirkette kimse bilmez.

Yol haritasının sağlıklı ilerlediğini nasıl anlarsınız?

• Üçüncü ayın sonunda ilk pilotun başarı ve durdurma ölçütü yazılı ve veri erişimi sağlanmış.
• Altıncı ayın sonunda pilot gerçek kullanıcılarla birkaç hafta çalışmış ve ölçüm sonucu yönetimle paylaşılmış.
• Dokuzuncu ayda ikinci senaryo, ilkinin veri katmanını ve yetki yapısını yeniden kullanıyor.
• On ikinci ayda en az bir uygulama iş biriminin günlük işinde kullanılıyor ve iç ekip tarafından işletiliyor.

Bu işaretlerden biri gecikiyorsa sebebi çoğu zaman teknik olmaz: veri erişimi onayı, iş biriminin zaman ayıramaması ya da önceliklerin değişmesi daha sık görülür. CX Teknoloji'de yol haritasını çizen ve sistemi sahada kuran ekip aynı olduğu için bu tıkanmalar planlama toplantısında değil sahada konuşulur. Kendi başlangıç noktanızı görmek için ücretsiz ön değerlendirmeyle başlayabilirsiniz.

Sık sorulan sorular

Yapay zekâ yol haritası neden 12 ay olarak planlanıyor?

12 ay, bir pilotun ölçülmesine ve ikinci bir senaryoyla ortak altyapının sınanmasına yetecek bir planlama ufkudur. Daha kısa planlar çoğu zaman tek pilotta kalır, çok uzun planlar ise teknoloji değiştikçe eskir. Plan her çeyrek gözden geçirilmelidir.

İlk yapay zekâ pilotu için hangi proje seçilmeli?

Tekrarlanan, bugünkü maliyeti ölçülebilen, verisi erişilebilir ve hatası insan tarafından yakalanabilen bir iş seçilmelidir. Projenin iş tarafında bir sahibi olması da şarttır. Doküman asistanı ya da talep sınıflandırma gibi işler bu kriterlere sık uyar.

Açık kaynak model mi, ticari model servisi mi kullanılmalı?

Karar veri sınıflandırmasına, maliyete ve ekip yetkinliğine göre verilir. Verinin şirket dışına çıkmaması gerekiyorsa şirket içinde çalışan açık kaynak modeller öne çıkar; hızlı deneme için ticari servisler daha az kurulum gerektirir. Seçim, pilot sırasında gerçek veriyle karşılaştırılarak yapılmalıdır.

Yapay zekâ için ayrı bir ekip kurmak gerekir mi?

Başlangıçta gerekmez; ilk aylarda iç ekipten bir sorumlu, anahtar kullanıcılar ve dış destek yeterli olabilir. Uygulama sayısı arttıkça veri mühendisliği ve işletme rolleri iç ekipte kalıcı hale getirilmelidir. Aksi halde sistemler dış desteğe bağımlı kalır.

Pilot beklenen sonucu vermezse ne olur?

Önceden yazılmış durdurma kriterine göre proje durdurulur ya da kapsamı değiştirilir. Başarısız bir pilot da veri durumu, süreç ve kullanıcı ihtiyacı hakkında değerli bilgi üretir. Bu bilgi bir sonraki senaryonun seçiminde kullanılmalıdır.