Toplantı odasında bu soru sorulduğunda ortaya genellikle iki cevap çıkar: ya bir araç adı ya da bir bütçe rakamı. İkisi de yanlış cevaptır — çünkü soru henüz doğru sorulmamıştır. "Nereden başlanır" bir teknoloji sorusu değil, bir karar sırası sorusudur.

Son yıllarda gördüğüm başarısız kurumsal yapay zekâ girişimlerinin ortak noktası teknoloji seçimi değildi. Hepsinde model çalışıyordu, demo etkileyiciydi, ekip hevesliydi. Tıkandıkları yer aynıydı: kimse baştan "bu sistem hangi kararı, kimin yerine, hangi ölçüde değiştirecek" sorusunu yazılı olarak cevaplamamıştı. Bu yazı o soruyu altı adımda cevaplamak için bir çerçeve sunuyor.

Çerçeve bilinçli olarak araç-bağımsız. Hangi modeli veya platformu seçeceğiniz altıncı adımda ortaya çıkan bir sonuçtur, birinci adımda verilen bir karar değil. Kurumsal tarafta bu sıralamayı doğru kurmak, yapay zekâ danışmanlığı işinin de büyük bölümünü oluşturuyor: teknoloji değil, sıralama.

Önce yanlış soruyu ayıklayın

"Hangi yapay zekâyı alalım?" sorusu, "hangi veritabanını alalım?" sorusuyla aynı kategoride. Cevabı olan bir soru gibi görünür ama bağlam olmadan cevaplanamaz. Daha da kötüsü, bu soruyu sorduğunuz anda tartışma satıcı sunumlarına kayar ve kurum kendi sorununu tanımlamadan çözüm dinlemeye başlar.

Doğru başlangıç sorusu şu: "Bu hafta kurumumuzda kaç kere, aynı bilgiye bakarak, aynı kararı, elle verdik?" Bu sorunun cevabı sayılabilir bir şeydir ve doğrudan bir aday listesi üretir. Yapay zekânın kurumsal değeri neredeyse her zaman burada — tekrar eden kararlarda — yoğunlaşır; tek seferlik stratejik kararlarda değil.

Adım 1 — Hangi kararı iyileştireceğinizi tek cümlede yazın

İlk adım bir teknoloji değerlendirmesi değil, bir cümle yazma egzersizidir. Cümlenin kalıbı şu: "[Kim], [ne sıklıkta], [hangi bilgiye bakarak], [hangi kararı] veriyor; bu kararın bugünkü maliyeti [ne]."

Örnek: "Destek ekibi, günde ortalama 120 kez, gelen e-postanın içeriğine bakarak talebi hangi birime yönlendireceğine karar veriyor; yanlış yönlendirme başına ortalama bir buçuk gün gecikme oluşuyor." Bu cümle yazılabiliyorsa proje tanımlanmıştır. Yazılamıyorsa henüz bir proje yok, bir merak var.

Cümlenin son kısmı — bugünkü maliyet — genellikle en zor yazılan yerdir ve tam da bu yüzden en değerlisidir. Maliyeti yazamıyorsanız, projenin başarılı olup olmadığını sonradan da ölçemezsiniz.

Adım 2 — Süreci sayın, veriyi değil

Kurumsal yapay zekâ tartışmaları çok erken bir aşamada "bizim verimiz hazır değil" cümlesine takılır ve orada durur. Bu cümle çoğu zaman doğrudur ama proje seçmek için yanlış filtredir. Çünkü veri olgunluğu bir süreklilik; "hazır" ya da "değil" diye ikiye ayrılmaz.

Daha işlevli filtre şudur: süreç bugün nasıl işliyor, kaç adımı var ve bu adımların kaçı yazılı? Adımları yazılı olmayan bir süreci otomatikleştiremezsiniz — çünkü modelin neyi taklit edeceği belli değildir. Buna karşılık, verisi dağınık ama adımları net bir süreç, çoğu zaman düşünüldüğünden çok daha hızlı ilerler.

  • Adımlar yazılı, veri dağınık: başlanabilir. Veri toplama işin bir parçası olur.
  • Adımlar yazılı değil, veri temiz: önce süreci yazın. Model bu boşluğu dolduramaz.
  • İkisi de yok: burası pilot yeri değil. Önce süreç iyileştirme.
  • İkisi de var: ilk pilotunuz bu olmalı, en yüksek değerli olan değil.

Son madde çoğu kurumun yaptığı hatanın tersidir. İlk pilot en kârlı süreçte değil, en öğretici süreçte yapılmalıdır. Birinci projenin asıl çıktısı kazanç değil, kurumun kendi kapasitesini öğrenmesidir.

Adım 3 — Üç kutu testi: kural mı, tahmin mi, üretim mi?

Kurumsal düzeyde işe yarayan yapay zekâ uygulamalarını üç kutuya ayırmak, teknoloji seçimini neredeyse otomatik hale getirir. Sıraladığınız her aday süreci bu üç kutudan birine koyun.

Kutu 1 — Kural işi

Karar bir tabloya sığıyorsa, bu bir yapay zekâ problemi değildir. "Tutar 5.000 TL üzerindeyse müdür onayına gider" gibi bir kural, model değil if ister. Bu kutuya düşen işlerin çoğu klasik otomasyonla, bugünkü araçlarla, günler içinde çözülür. Kurumların yapay zekâ bütçesinin kayda değer bir kısmı aslında bu kutuda harcanabilecek işlere gider ve gereksiz karmaşıklık satın alınır.

Kutu 2 — Tahmin işi

Geçmiş veriden geleceğe dair bir sayı ya da olasılık üretiyorsanız — talep tahmini, müşteri kaybı riski, arıza öngörüsü — bu klasik makine öğrenmesi alanıdır. Bu kutu veriye gerçekten bağımlıdır: yeterli geçmiş yoksa proje yürümez. Buna karşılık başarı ölçümü nettir, çünkü tahminin tuttuğunu ya da tutmadığını zaman gösterir.

Kutu 3 — Üretim işi

Metin okuma, özetleme, sınıflandırma, taslak üretme, soru cevaplama — büyük dil modellerinin alanı. Bu kutunun kurumsal cazibesi şu: geçmiş veri gerektirmez. Model zaten dili biliyor; siz ona bağlam veriyorsunuz. Bu yüzden "verimiz hazır değil" diyen kurumların ilk pilotu genellikle bu kutudan çıkar.

Kutunun riski de aynı yerden gelir: çıktı akıcı olduğu için doğru sanılır. Bu kutuda çalışan her sistemin, çıktının doğrulanacağı bir adım içermesi gerekir — ya insan onayı ya da makine tarafından kontrol edilebilir bir alan.

Adım 4 — Yapmayacaklarınızı da yazın

Kapsam belgesinin en çok atlanan bölümü, kapsam dışı olanlar. Oysa yapay zekâ projelerinde asıl riski bu bölüm yönetir.

En az şu üç satırı yazın: hangi veri hiçbir koşulda sisteme girmeyecek; hangi karar hiçbir koşulda insan onayı olmadan uygulanmayacak; sistem hangi durumda kapatılacak. Üçüncüsü özellikle önemli — bir yapay zekâ sistemini kapatma koşulunu baştan yazmayan kurumlar, sistem kötü çalışmaya başladığında onu kapatmak yerine savunmaya geçer.

Kişisel veri söz konusuysa bu adım hukuki bir zorunluluğa da dönüşür. Hangi verinin dışarı çıkmayacağı ve modelin eğitiminde ne kullanılacağı, teknik mimariyi doğrudan belirler; bu kararların ayrıntısını kurumsal veriyi yapay zekâya vermek yazısında yedi teknik kontrol üzerinden ele aldım.

Adım 5 — Altı haftalık pilot ve önceden yazılmış başarı ölçütü

Pilot süresi için altı ilâ sekiz hafta iyi bir aralık. Daha kısası öğrenmeye yetmez; daha uzunu, sonucu kötü olsa bile durdurulamayacak kadar çok kurumsal yatırım biriktirir.

Pilotun tek kuralı şu: başarı ölçütü, pilot başlamadan önce yazılmış olacak. Sonradan yazılan ölçüt, her zaman elde edilen sonuca uyacak şekilde yazılır. Ölçütü şu üç sorunun cevabı olarak kurun:

  • Hangi sayı değişecek? (süre, hata oranı, işlem başına maliyet, kapasite)
  • Ne kadar değişirse "işe yaradı" diyeceğiz?
  • Bu sayıyı bugün nasıl ölçüyoruz — ölçmüyorsak, pilot başlamadan önce ölçmeye başlıyoruz.

Son madde pratikte en çok atlanan ve en pahalıya mal olan maddedir. Başlangıç değerini ölçmeden başlayan bir pilotun sonunda elinizde karşılaştırılabilir hiçbir şey olmaz; geriye yalnızca izlenim kalır ve izlenimle bütçe alınmaz.

Adım 6 — Üretim kapısı: kim bakacak?

Pilot başarılı olduğunda çoğu kurum doğrudan yaygınlaştırmaya geçer. Arada atlanan adım şudur: pilot bir deneydir, üretim bir sistemdir. İkisinin işletme gereksinimleri farklıdır.

Üretime almadan önce dört sorunun yazılı cevabı olmalı:

  • Sahibi kim? Sistem bozulduğunda kimin telefonu çalacak. "BT" bir cevap değil, bir isim gerekir.
  • Nasıl izlenecek? Kalitenin düştüğünü kullanıcıdan önce nereden göreceksiniz.
  • Ne zaman gözden geçirilecek? Modelin çalıştığı dünya değişir; takvimde bir tarih olmalı.
  • Nasıl geri alınacak? Sistem kapatıldığında eski süreç hâlâ çalışıyor mu, yoksa unutuldu mu?

Dördüncü soru en sinsi olanı. Elle yapılan süreç birkaç ay kullanılmadığında, onu bilen insanlar başka işe geçer ve süreç fiilen kaybolur. Yapay zekâ sistemine bağımlılık, kimse karar vermeden oluşur.

Altı adım tek bir örnek üzerinde

Çerçeveyi soyut bırakmamak için, sık karşılaştığım bir senaryoyu baştan sona yürütelim: gelen destek taleplerinin doğru birime yönlendirilmesi.

Adım 1 — Karar cümlesi. "Destek ekibi, günde ortalama 120 kez, gelen e-postanın içeriğine bakarak talebi hangi birime yönlendireceğine karar veriyor; yanlış yönlendirme başına ortalama bir buçuk gün gecikme oluşuyor." Maliyet kalemi yazılabildi, demek ki proje tanımlı.

Adım 2 — Süreç sayımı. Süreç dört adım: oku, sınıflandır, ata, bilgilendir. Adımlar yazılı mı? Kısmen — sınıflandırma kuralları kimsenin kafasında. Yapılacak ilk iş model kurmak değil, iki hafta boyunca deneyimli bir kişinin verdiği kararları etiketleyip kuralı görünür kılmak.

Adım 3 — Kutu seçimi. Karar bir tabloya sığıyor mu? Hayır — metin okumayı gerektiriyor, gönderen aynı şeyi on farklı biçimde yazabiliyor. Geçmiş veri şart mı? Hayır. Demek ki Kutu 3: üretim işi, dil modeli alanı.

Adım 4 — Kapsam dışı. Müşteri e-postasındaki kimlik ve iletişim bilgileri modele gitmeyecek, önce maskelenecek. Model "şüpheli" dediği hiçbir talebi otomatik kapatmayacak. Doğruluk iki hafta üst üste %85'in altına düşerse sistem devre dışı, süreç elle devam.

Adım 5 — Pilot. Altı hafta, tek departman. Ölçüt: yanlış yönlendirme oranı. Bugünkü değeri bilinmiyor — o hâlde pilot başlamadan iki hafta boyunca elle ölçülüyor. Bu iki hafta pilotun parçası, hazırlığı değil.

Adım 6 — Üretim kapısı. Sahibi destek ekibi lideri. İzleme: haftalık yanlış yönlendirme raporu, ekip liderinin panosunda. Gözden geçirme: üç ayda bir. Geri alma: elle yönlendirme kuralları yazılı olarak duruyor ve ekipten iki kişi süreci hâlâ uyguluyor.

Dikkat edin: altı adımın hiçbirinde model, sağlayıcı ya da platform adı geçmedi. O seçim, Adım 4'teki maskeleme kararı ve Adım 6'daki izleme ihtiyacı netleştikten sonra kendiliğinden daralıyor.

Bu altı adımı atlayan üç kalıp

Vitrin projesi. Etkileyici bir demo çıkar, yönetim beğenir, kimse günlük işinde kullanmaz. Sebebi neredeyse her zaman Adım 1'in atlanmasıdır: proje bir karara değil, bir teknolojiye bağlanmıştır.

Her yere biraz. Sekiz departman kendi küçük denemesini başlatır, hiçbiri üretime ulaşmaz, hepsi ayrı satıcıyla çalışır. Kurum bir yıl sonunda sekiz yarım sistem ve tek bir öğrenilmiş ders ile kalır.

Önce altyapı. "Veri ambarını bitirelim, sonra yapay zekâya geçeriz" yaklaşımı makul görünür ve genellikle iki yıl sürer. Bu sürede kurum yapay zekâ konusunda hiçbir şey öğrenmez. Doğru sıra paralel ilerlemektir: üretim kutusundan (Kutu 3) bir pilot, veri çalışmasıyla eş zamanlı.

Peki bütçe?

Bu soruyu altıncı sıraya bırakmamın sebebi var: bütçe, kapsamın sonucudur. Yine de bir büyüklük fikri vermek gerekirse, tek bir sürece odaklı bir pilotun maliyeti üç kalemden oluşur — kurulum ve entegrasyon emeği, model kullanım (token) maliyeti ve kurum içi ayrılan zaman. Üçüncü kalem neredeyse her zaman hafife alınır ve çoğu zaman ilk ikisinden büyüktür.

Model kullanım maliyeti ise, kurumların korktuğu kalem olmasına rağmen genelde en küçüğüdür ve ölçeklenmeden önce tahmin edilebilir. Asıl maliyet, yanlış süreci seçip altı hafta harcamaktır. Bu yüzden bu yazının tamamı seçim üzerine.

İlk 30 gün: somut bir takvim

Yukarıdaki çerçeveyi bir sonraki ay içine yerleştirmek isterseniz, işe yaradığını gördüğüm dağılım şu:

  • 1. hafta — Aday karar listesi. Üç ilâ beş süreç için Adım 1'deki cümleyi yazın. Yazılamayanlar listeden düşer; bu eleme tek başına haftanın işidir.
  • 2. hafta — Kalan adayları üç kutuya dağıtın ve kapsam dışı listesini yazın. Hukuk ve bilgi güvenliği bu haftada masaya gelir, projenin sonunda değil.
  • 3. hafta — Tek bir aday seçin ve başarı ölçütünü yazın. Aynı hafta o ölçütün bugünkü değerini ölçmeye başlayın.
  • 4. hafta — Pilot kapsamını, süresini ve sahibini yazılı hale getirip başlayın.

Bu takvimde teknoloji seçimi yok; ilk ay tamamen eleme ayıdır. Bir ayın sonunda elinizde çalışan bir sistem olmaz ama yanlış projeye harcanmamış altı hafta olur.

Sık sorulan sorular

Şirkette yapay zekâya nereden başlanır?

Bir araç seçerek değil, bir karar seçerek. Kurumunuzda tekrar eden, aynı bilgiye bakılarak verilen ve bugünkü maliyeti yazılabilen bir karar bulun. Sonra o kararın hangi kutuya düştüğünü belirleyin: kural işi mi (klasik otomasyon yeter), tahmin işi mi (geçmiş veri gerekir), üretim işi mi (dil modeli, geçmiş veri gerekmez). Altı-sekiz haftalık bir pilotla, başarı ölçütünü önceden yazarak ilerleyin.

Verimiz hazır değil, yine de başlayabilir miyiz?

Evet — hangi kutuda çalıştığınıza bağlı. Tahmin işleri (talep tahmini, kayıp riski) geçmiş veriye gerçekten bağımlıdır ve veri yoksa yürümez. Üretim işleri (metin sınıflandırma, özetleme, taslak üretme) ise geçmiş veri gerektirmez; model dili zaten bilir, siz bağlam verirsiniz. "Verimiz hazır değil" diyen kurumların ilk pilotu genellikle bu ikinci gruptan çıkar ve veri çalışması paralel yürür.

İlk pilot hangi süreçte olmalı?

En kârlı süreçte değil, en öğretici süreçte. İlk projenin asıl çıktısı kazanç değil, kurumun kendi kapasitesini öğrenmesidir: veriye ne kadar hızlı erişebiliyorsunuz, hukuk süreci ne kadar sürüyor, ekip aracı benimsiyor mu. Adımları yazılı ve sonucu ölçülebilir bir süreç seçin; en yüksek getirili süreci ikinci sıraya koyun.

Pilot ne kadar sürmeli?

Altı ilâ sekiz hafta. Daha kısası öğrenmeye yetmez; daha uzunu, sonuç kötü olsa bile durdurulamayacak kadar kurumsal yatırım biriktirir. Süreden daha önemlisi başarı ölçütünün pilot başlamadan önce yazılmış olmasıdır — ve o sayının bugünkü değerinin pilot başlamadan ölçülmüş olması.

Hazır bir araç mı almalıyız, kendi sistemimizi mi kurmalıyız?

Bu karar altıncı adımda verilir, birincide değil. Kapsam, veri hassasiyeti ve entegrasyon ihtiyacı netleştikten sonra cevap genellikle kendiliğinden çıkar: süreç standartsa ve veri hassas değilse hazır araç; süreç kuruma özgüyse ya da veri dışarı çıkamıyorsa kendi kurgunuz. Pilot aşamasında hazır araçla başlamak, kendi sisteminizi kurmadan önce ne istediğinizi öğrenmenin en ucuz yoludur.

Çalışanların direncini nasıl yönetiriz?

Direncin kaynağı genelde teknoloji değil belirsizliktir: "bu benim işimi mi alacak" sorusu cevapsız kaldığında insanlar temkinli davranır. En işe yarayan yaklaşım, pilotu o işi bugün yapan ekiple birlikte tasarlamak ve hangi adımın devredileceğini, hangisinin insanda kalacağını yazılı olarak paylaşmaktır. Kapsam dışı listesi (Adım 4) burada da işe yarar.

Nereden devam etmeli

Bu altı adım bir yol haritası değil, bir eleme sırası. Amacı doğru projeyi bulmak değil, yanlış projeleri ucuza elemek. Kurumsal yapay zekâda pahalı olan şey yanlış modeli seçmek değil, yanlış süreçte altı hafta harcamaktır.

Aynı kararları yönetim kurulu masasında, yatırım önceliklendirme diliyle konuşmak isterseniz C-level yapay zekâ eğitimi sayfasındaki karar atölyesi formatı bu çerçevenin üzerine kuruluyor. Yapay zekâ destekli üretimin mühendislik tarafını merak ediyorsanız vibe coding ve mühendislik disiplini yazısı aynı soruyu yazılım geliştirme tarafından ele alıyor.

Bu yazıyı, telekomünikasyondan havacılığa 15+ yıl yazılım deneyimi ve kurumsal yapay zekâ projelerindeki saha gözlemlerimle yazdım. Hakkımda daha fazlası: Ufuk Aytaş kimdir.