# GenAI Uçurumu: Pilotların %95'i Neden Değer Üretmiyor ve %5 Ne Yapıyor?

> Source: https://sukruyusufkaya.com/blog/genai-divide-pilottan-degere-2026
> Updated: 2026-07-09T10:40:44.108Z
> Type: blog
> Category: yapay-zeka
**TLDR:** MIT'nin bulgusu net: pilotların %95'i ölçülebilir getiri üretmiyor. Sorun model değil entegrasyon. CDO/CTO için pilottan değere geçiş çerçevesi.

**TL;DR —** Kurumsal GenAI pilotlarının %95'i ölçülebilir bir getiri üretmeden ölüyor. Sebep model kalitesi değil; entegrasyon, öğrenme döngüsü ve yanlış problem seçimi. Başaran %5'in ne yaptığını ve pilotu değere çeviren bir çerçeveyi CDO/CTO gözünden, sahadan örneklerle anlatıyorum. Ana mesaj: parayı satış-pazarlama vitrinine değil, arka ofis otomasyonuna koyun; içeride her şeyi sıfırdan inşa etmek yerine uzman tedarikçiden alın; başarıyı en baştan net bir metrikle bağlayın.

## Bir toplantı, iki cümle ve bütün mesele

Geçen ay büyük bir holdingin yönetim katındaydım. CTO gururla anlattı: "On dört GenAI pilotu başlattık." Yanındaki CFO tek bir soru sordu: "Kaçı bütçeye dokundu?" Odada birkaç saniye sessizlik oldu. Sonra CTO dürüstçe cevap verdi: "Bir tanesi, belki. Diğerleri hâlâ 'öğreniyoruz' aşamasında."

O sessizlik, bugün Türkiye'deki ve dünyadaki neredeyse her kurumun içinden geçtiği yerin ta kendisi. Ben buna, literatürdeki adıyla **GenAI Uçurumu (the GenAI Divide)** diyorum. Bir yakada heyecan, demolar, "wow" anları ve slaytlar var. Öbür yakada ise P&L tablosuna dokunan, gerçekten para kazandıran ya da tasarruf ettiren uygulamalar. Ve arada, çoğu kurumun bir türlü atlayamadığı derin bir çukur.

Bu yazıda size, MIT'nin 2026'da yayımladığı ve sektörde ciddi ses getiren o raporun ortaya koyduğu tabloyu, sahadan gözlemlerimle harmanlayarak anlatacağım. Rapor keyfi bir anket değil; **300'den fazla yapay zekâ girişimi** incelenmiş, **150 mülakat**, **350 kişilik bir çalışan anketi** ve **300 kamuya açık dağıtımın analizi** üstüne kurulu. Çıkan sonuç net: **Kurumsal GenAI pilotlarının %95'i ölçülebilir bir yatırım getirisi üretemiyor.** Sadece **%5'i** hızlı gelir ivmesine ulaşıyor.

Rakam ilk duyduğunuzda insanı ürkütüyor. Ama ben yıllardır sahadayım ve size şunu söyleyebilirim: bu tablo kötümser değil, aslında iyi haber. Çünkü %95'in neden başarısız olduğu tesadüf değil; tekrar eden, isimlendirilebilen, düzeltilebilen sebeplerden kaynaklanıyor. Yani uçurumun öbür tarafına geçmek şans işi değil, yöntem işi.

## GenAI Uçurumu tam olarak nedir?

Şöyle netleştireyim. GenAI Uçurumu, "yapay zekâ çalışıyor mu çalışmıyor mu" tartışması değil. Modeller çalışıyor. Bir dil modeli bugün özet çıkarıyor, kod yazıyor, müşteri sorusunu yanıtlıyor, sözleşme tarıyor. Teknoloji tarafında sorun büyük ölçüde çözülmüş durumda. Uçurum, **teknolojinin yeteneği ile kurumun o yetenekten değer çıkarabilme kapasitesi** arasında.

Bunu bir benzetmeyle anlatayım. Elinizde son model bir yarış arabası var. Motor mükemmel. Ama pistiniz yok, pilotunuz ehliyetsiz, yakıt istasyonunuz kapalı ve kimse bu arabanın hangi yarışa gireceğine karar vermemiş. Araba kötü mü? Hayır. Sadece o arabayı sonuca çevirecek her şey eksik. GenAI pilotlarının %95'inde olan tam olarak bu.

Raporun en çarpıcı bulgusu da burada: **Başarısızlığın kök nedeni model kalitesi değil.** Kök neden, iki büyük başlıkta toplanıyor. Birincisi **öğrenme boşluğu (learning gap)**: kurum, aracı bir kez kurup unutuyor; sistem kullanımdan öğrenmiyor, iş akışına gömülmüyor, geri bildirimle iyileşmiyor. İkincisi **kusurlu kurumsal entegrasyon**: veri hazırlığı zayıf, başarı metrikleri baştan yanlış tanımlanmış, iş akışı entegrasyonu kırık. Yani sorun laboratuvarda değil, laboratuvardan çıkıp gerçek işe temas ettiği yerde.

Ben bunu danışmanlıklarımda sürekli görüyorum. Pilot demoda muhteşem çalışıyor. Sonra gerçek verilerle, gerçek kullanıcılarla, gerçek onay süreçleriyle karşılaşınca tıkanıyor. Demo ile üretim arasındaki mesafe, çoğu kurumun küçümsediği mesafedir.

## Pilotlar neden takılıp kalıyor: model değil, entegrasyon

Gelin başarısızlığın anatomisini açalım. Sahada gördüğüm tıkanma noktaları neredeyse her seferinde aynı yerlerden geçiyor.

**Birincisi, iş akışına gömülmeyen araçlar.** Pilot çoğu zaman ana sistemin yanında, ayrı bir sekmede yaşıyor. Çalışan, işini yaparken bir de gidip o sekmeyi açmak, oraya bir şey yapıştırmak, çıkanı geri kopyalamak zorunda. Bu sürtünme öldürücüdür. İnsan doğası gereği fazladan tık istemez. Araç CRM'in, ERP'nin, çağrı merkezi ekranının, e-postanın içine gömülmediyse, birkaç hafta sonra kimse kullanmıyor. Kullanılmayan pilot, tanım gereği değer üretmez.

**İkincisi, öğrenmeyen sistemler.** Raporun "öğrenme boşluğu" dediği şey bu. İyi bir GenAI uygulaması, kullanıldıkça iyileşmeli. Kullanıcı düzeltmeleri, reddedilen yanıtlar, tekrar eden sorular geri besleme olarak sisteme dönmeli. Çoğu pilotta böyle bir döngü yok. Sistem ilk günkü haliyle donup kalıyor; kullanıcı ise iki hafta içinde onun sınırlarını öğrenip vazgeçiyor.

**Üçüncüsü, veri hazırlığı yokluğu.** "Modelimiz sözleşmeleri okusun" diyorsunuz ama sözleşmeler beş farklı formatta, yarısı taranmış PDF, meta verisi eksik, erişim izinleri karışık. Model kötü olduğu için değil, önüne konan veri dağınık olduğu için sonuç kötü çıkıyor. Türkiye'de bu tabloya bir de KVKK katmanı ekleniyor: kişisel veri içeren belgeler, veri işleme rızası, veri minimizasyonu, yurt dışına veri aktarımı kısıtları. Veri hazır değilse pilot da hazır değildir.

**Dördüncüsü, baştan yanlış tanımlanmış başarı.** "Pilotu başarılı sayalım mı?" sorusunun cevabı çoğu projede belirsiz. Metrik yoksa, herkes kendi hikâyesini anlatır; teknik ekip "model harika çalışıyor" der, iş birimi "bana bir faydası olmadı" der, ikisi de haklıdır çünkü aynı şeyi ölçmüyorlardır. Metriği başta bağlamayan pilot, sonunda kendi başarısını kanıtlayamaz.

## Bütçenin yanlış yere akması: vitrin mi, arka oda mı?

Şimdi en can alıcı noktaya geliyorum ve bu, danışmanlık masasında en çok tartıştığım konudur.

Rapora göre **GenAI bütçelerinin yarısından fazlası satış ve pazarlama araçlarına gidiyor.** Mantıklı geliyor değil mi? Herkes gelir çizgisine yakın, gösterişli, sunumu kolay projeleri sever. Pazarlama içeriği üreten bir araç, satış e-postası yazan bir asistan, güzel demolar çıkarır, yönetime anlatması kolaydır.

Ama işin sırrı şu: **En büyük getiri arka ofis otomasyonunda.** BPO (iş süreçleri dış kaynak) maliyetlerini ortadan kaldırmak, ajans harcamalarını kısmak, operasyonu sadeleştirmek. Yani parlamayan, sunumu sıkıcı, ama faturayı doğrudan küçülten işler.

Bir örnek vereyim. İki farklı müşterim vardı. Birincisi bütçenin çoğunu pazarlama içeriği üreten bir GenAI aracına ayırdı. Altı ay sonra ellerinde bir sürü içerik vardı ama gelirde ölçülebilir bir artış yoktu; içerik zaten üretilebiliyordu, sadece hızlanmıştı, o da doğrudan paraya dönmüyordu. İkinci müşterim ise sıkıcı bir işi seçti: tedarikçi faturalarının mutabakatı. Dışarıya verdikleri bir ekip bu işi yapıyordu. GenAI destekli bir akış kurduk; mutabakat süresi düştü, hata oranı düştü, dışarıya ödenen aylık ücret ortadan kalktı. Altıncı ayın sonunda birinci müşterinin elinde slayt, ikinci müşterinin elinde kesilmiş bir fatura vardı.

İşte %95 ile %5 arasındaki fark çoğu zaman bu seçimden başlıyor. Vitrin projeleri egoyu besler, arka oda projeleri P&L'i besler.

Bunu bir tabloyla özetleyeyim:

| Boyut | Çoğunluğun yaptığı (%95) | Başaranların yaptığı (%5) |
|---|---|---|
| Bütçe önceliği | Satış/pazarlama vitrini | Arka ofis otomasyonu |
| Başarı metriği | "Etkileyici demo" | P&L'e dokunan somut sayı |
| Entegrasyon | Ayrı sekme, kopyala-yapıştır | İş akışına gömülü |
| Öğrenme | Kur-unut | Geri bildirim döngüsü |
| İnşa yöntemi | Her şeyi içeride yaz | Uzman tedarikçiden al |
| Problem seçimi | "AI ile ne yapabiliriz?" | "Hangi pahalı işi çözelim?" |

## Al ya da yap: veri ne diyor?

Kurumsal dünyanın en sevdiği tuzaklardan biri "biz bunu içeride yaparız" cümlesidir. Mühendislik gururu güzel bir şeydir ama burada rakamlar acımasız.

Rapor net bir sonuç veriyor: **Uzman tedarikçiden AI satın almak yaklaşık %67 oranında başarılı oluyor. İçeride sıfırdan inşa etmek ise bunun ancak üçte biri kadar başarılı.** Yani kabaca, satın alma iki kez üçte ikisi tutarken, içeride yapma her üç denemeden birini zar zor tutturuyor.

Neden? Çünkü bir GenAI uygulamasını üretime taşımak sadece model çağırmak değil. Değerlendirme altyapısı, güvenlik katmanı, veri boru hatları, izleme, geri bildirim döngüsü, sürüm yönetimi... Uzman tedarikçi bunları yüzlerce müşteride yaşayıp öğrenmiş oluyor. İçerideki ekip ise çoğu zaman bunları ilk defa, kendi başına, diğer işlerinin arasında öğrenmeye çalışıyor.

Burada bir nüans var, atlamayayım. "Satın al" demek "her şeyi dışarıdan al ve düşünme" demek değil. Rekabet avantajınız olan, size özgü, çekirdek iş süreçlerinizde ince ayar ve sahiplik sizde kalmalı. Ama koşan bir ata binmek varken, atı sıfırdan yetiştirmeye kalkmayın. Doğru formül genellikle şu: **çekirdek olmayanı satın al, çekirdekte tedarikçiyle birlikte inşa et, hiçbir şeyi tamamen sıfırdan tek başına yapma.**

Türkiye özelinde bir not düşeyim: yerel bir tedarikçi ekosistemi giderek olgunlaşıyor. KVKK uyumu, Türkçe dil performansı, yerinde (on-prem) veya yurt içi bulut dağıtımı gibi ihtiyaçlar söz konusuysa, yerel oyuncularla çalışmak hem uyum hem de destek açısından ciddi avantaj sağlıyor. Global bir modelin üstüne yerel bir entegrasyon katmanı koymak, çoğu Türk kurumu için en pratik yol.

## %5 ne yapıyor da farkı yaratıyor?

Şimdi işin ilham veren tarafına gelelim. Uçurumun öbür tarafına geçen o %5, sihirli bir model bulmuş değil. Aynı modelleri kullanıyorlar. Farkı yaratan şey davranışları. Sahada gözlemlediğim ortak desenler şunlar:

**Bir: İş akışına gerçekten gömüyorlar.** Araç, çalışanın zaten baktığı ekranın içinde yaşıyor. Fazladan tık yok, sekme yok. Kullanıcı çoğu zaman "AI kullanıyorum" diye düşünmüyor bile; iş sadece daha hızlı akıyor.

**İki: Öğrenme döngüsü kuruyorlar.** Sistem kullanımdan öğreniyor. Reddedilen çıktı, düzeltilen yanıt, tekrar eden soru geri besleniyor. Üç ay sonraki sistem, ilk günkünden belirgin şekilde daha iyi.

**Üç: Metriği baştan bağlıyorlar.** Pilot başlamadan önce "bu proje başarılıysa şu sayı şu kadar değişecek" diye yazıyorlar. Süre, maliyet, hata oranı, dönüşüm — her neyse, tek ve net. Böylece altıncı ayda tartışma olmuyor; ya sayı tuttu ya tutmadı.

**Dört: Arka ofise odaklanıyorlar.** Sıkıcı ama pahalı işleri seçiyorlar. Vitrin yerine faturayı hedefliyorlar.

**Beş: Doğru yerden satın alıyorlar.** Uzman tedarikçiyle hızla başlıyorlar, öğrenilmiş çözümlerin üstüne kendi bağlamlarını ekliyorlar.

**Altı: Değişim yönetimini ciddiye alıyorlar.** Aracı masaya koyup "buyurun kullanın" demiyorlar. Eğitim veriyorlar, şampiyonlar seçiyorlar, süreci yeniden tasarlıyorlar. Çünkü GenAI bir yazılım kurulumu değil, bir çalışma biçimi değişikliğidir.

## Pilottan değere çerçevesi: beş adım

Danışmanlıklarımda kullandığım basit bir çerçeve var. Beş adım, ve sıralaması önemli. Çoğu kurum ikinci ve üçüncü adımı atlayıp doğrudan araca koşuyor; uçurumun dibi tam da orası.

**Adım 1 — Problem seçimi.** Soruyu tersten sorun. "AI ile ne yapabiliriz?" değil, "Bize en çok paraya, zamana, hataya mal olan tekrar eden iş hangisi?" Sonra o işin AI'ya uygun olup olmadığına bakın. İyi bir aday: yüksek hacimli, kurallı ama insan yargısı gerektiren, dile veya belgeye dayalı, sonucu ölçülebilir bir iş. Arka ofiste bunlardan bolca var.

**Adım 2 — Veri hazırlığı.** Seçtiğiniz problem için gereken veri nerede, hangi formatta, ne kadar temiz, erişim izinleri ne durumda? KVKK açısından kişisel veri var mı, rıza ve amaç uyumu tamam mı, veri minimizasyonu uygulanabiliyor mu? Bu adımı atlayan pilot, demo aşamasını geçemez. Veri hazır değilse, önce veriyi hazırlayın; model beklemez ama iyi de çalışmaz.

**Adım 3 — Entegrasyon tasarımı.** Aracın çalışanın hangi ekranında, hangi anında, hangi tıkla devreye gireceğini baştan tasarlayın. "Sonra entegre ederiz" cümlesi bir pilotu öldüren en yaygın cümledir. Entegrasyon sonradan yamanacak bir detay değil, pilotun kalbidir.

**Adım 4 — Metrik ve ölçüm.** Başarıyı tek bir taban çizgisiyle (baseline) bağlayın. "Şu an bu iş X saat sürüyor / Y TL'ye mal oluyor / %Z hata veriyor. Pilot başarılıysa bu sayı şu olacak." Ölçümü pilot başlamadan kurun; sonradan kurulan ölçüm hep tartışmalıdır.

**Adım 5 — Değişim yönetimi.** İnsanları sürece katın. Eğitim, iç şampiyonlar, süreç yeniden tasarımı, açık iletişim. Aracın kullanılmasını sağlamak, aracı kurmaktan daha zordur ve daha önemlidir.

Bu beş adımı sırayla ve dürüstçe geçen bir pilot, otomatik olarak %5'e girmez ama %95'in içindeki kolay tuzakların neredeyse hepsinden kurtulur.

## ROI'yi doğru ölçmek

Getiriyi ölçme kısmı hak ettiği ciddiyeti nadiren görür, o yüzden biraz durayım.

Öncelikle **taban çizgisi olmadan ROI olmaz.** Pilot başlamadan önceki durumu sayıyla kaydetmediyseniz, sonradan "iyileşti" demeniz bir histen ibaret kalır. İşin ne kadar sürdüğünü, kaça mal olduğunu, ne kadar hata ürettiğini önce ölçün.

İkincisi, **doğru maliyetleri toplayın.** Sadece lisans ücreti değil; entegrasyon, veri hazırlığı, eğitim, bakım, izleme ve insan denetimi maliyetleri de hesaba girer. Birçok "kârlı" pilot, gizli maliyetler eklenince başabaş noktasının altına düşer.

Üçüncüsü, **doğru faydaları sayın.** Zaman tasarrufu güzeldir ama "kazanılan saat" ancak o saat başka değerli bir işe dönüyorsa ya da başlık maliyeti gerçekten azalıyorsa paraya çevrilir. Boşta duran kapasite, tasarruf değildir. Arka ofis projelerinin cazibesi de burada: dış kaynak ücreti, ajans faturası, fazla mesai gibi gerçekten kesilen kalemlere dokunuyorlar.

Dördüncüsü, **zaman ufkunu net koyun.** Bazı getiriler ilk ayda gelir, bazıları öğrenme döngüsü olgunlaştıkça altıncı ayda belirginleşir. Pilotu üçüncü haftada "işe yaramadı" diye kapatmak, çoğu zaman erken hükümdür. Ama ölçüt de baştan konmalı ki "biraz daha bekleyelim" bir bahaneye dönüşmesin.

Basit bir ROI iskeleti şöyle görünür:

| Kalem | Pilot öncesi | Pilot sonrası | Fark |
|---|---|---|---|
| İşlem başına süre | ölç | ölç | ? |
| Aylık doğrudan maliyet (BPO/ajans/mesai) | ölç | ölç | ? |
| Hata / yeniden iş oranı | ölç | ölç | ? |
| Toplam sahip olma maliyeti (lisans+entegrasyon+bakım) | — | ölç | ? |

Bu tablo mütevazı görünüyor ama CFO'nun masasında bir slayttan çok daha ağır basar. Çünkü CFO demoyla değil, farkla ilgilenir.

## Türkiye bağlamı: KVKK, ekosistem ve yetenek

Buraya kadar anlattıklarım evrensel, ama Türkiye'de sahnenin birkaç yerel rengi var.

**KVKK ve veri yönetişimi.** Kişisel veri içeren her GenAI akışında; işleme amacının belirliliği, rıza veya meşru menfaat dayanağı, veri minimizasyonu ve özellikle yurt dışına veri aktarımı konusu masaya baştan yatırılmalı. Bir modelin verinizi nereye gönderdiği, nerede işlediği, ne kadar sakladığı artık teknik değil hukuki bir sorudur. Başaran kurumlar bu soruları pilotun sonunda değil, başında soruyor. Uyum bir frendir ama iyi kurulduğunda güven de üretir; müşteri ve çalışan, verisinin nereye gittiğini bildiğinde araca daha çok güvenir.

**Yerel ekosistem.** Türkçe dil performansı, sektörel bağlam, yerinde dağıtım ve yerli destek ihtiyaçları olduğunda yerel tedarikçilerle çalışmak giderek daha güçlü bir seçenek. "Satın al" tavsiyem burada yerel oyuncuları da kapsıyor; global modelin gücünü yerel entegrasyon ve uyum katmanıyla birleştirmek çoğu kurum için en dengeli yol.

**Yetenek.** İçeride sıfırdan inşanın düşük başarı oranının bir sebebi de yetenek darboğazı. Deneyimli GenAI mühendisi ve MLOps yetkinliği kıt ve pahalı. Bu yüzden içeride yapmak istediğiniz her şey, aslında o kıt yeteneği en yüksek katma değerli, size özgü işlere ayırmanız gereken bir bütçe kararıdır. Standart olanı satın alın ki nadir olanı doğru yere koyabilesiniz.

## CDO/CTO için somut kontrol listesi

Şimdi masaya oturduğunuzda kullanabileceğiniz, doğrudan uygulanabilir bir listeyle bağlayayım. Bir sonraki yönetim toplantısına bununla girin.

**Portföyü gözden geçirin.**
- Aktif GenAI pilotlarınızı listeleyin ve her birinin yanına tek bir sayı yazın: bu proje başarılıysa P&L'de ne değişecek? Sayı yazamadığınız her pilot, kırmızı bayraktır.
- Bütçe dağılımınıza bakın. Yarısından fazlası satış/pazarlamada mı? Dengeyi arka ofise kaydırma vaktidir.

**Problem seçimini disiplinize edin.**
- "AI ile ne yaparız?" toplantılarını yasaklayın. Yerine "En pahalı tekrar eden işlerimiz hangileri?" sorusuyla başlayın.
- En az bir sıkıcı ama pahalı arka ofis işini pilot listesine ekleyin (mutabakat, belge işleme, çağrı özetleme, uyum kontrolleri gibi).

**Al/yap kararını verilere bağlayın.**
- Her yeni pilot için varsayılanınız "satın al" olsun; "yap" kararını gerekçelendirmeyi zorunlu kılın.
- İçeride yapmayı yalnızca çekirdek, farklılaştırıcı süreçlerle sınırlayın.

**Entegrasyon ve veriyi baştan çözün.**
- Hiçbir pilotu, iş akışına gömme planı ve veri hazırlık kontrolü tamamlanmadan başlatmayın.
- KVKK kontrol listesini (amaç, dayanak, minimizasyon, aktarım) pilotun ön koşulu yapın.

**Ölçümü kurun.**
- Her pilot için taban çizgisini pilot başlamadan kaydedin.
- Toplam sahip olma maliyetini (lisans + entegrasyon + bakım + insan denetimi) baştan hesaplayın.

**Öğrenmeyi ve insanı unutmayın.**
- Her pilotta bir geri bildirim döngüsü olsun; sistem kullanımdan öğrensin.
- Değişim yönetimini projeye dahil edin: eğitim, iç şampiyonlar, süreç yeniden tasarımı.

Bu listenin sihirli tarafı yok. Ama %95'in düştüğü çukurların neredeyse tamamı, bu maddelerden birinin atlanmasıyla açılıyor. Uçurumun öbür tarafı, dâhice bir fikirle değil, sıkıcı bir disiplinle geçiliyor.

Son bir söz olarak değil, bir davet olarak bırakayım: bir sonraki pilotunuzu başlatmadan önce kendinize tek bir soru sorun — "Bu başarılı olursa, altıncı ayda CFO'ya hangi kesilmiş faturayı ya da hangi net sayıyı göstereceğim?" Bu soruya net cevabınız varsa, zaten %5'e doğru yürüyorsunuz demektir. Yoksa, pilotu başlatmadan önce bu yazıya bir kez daha dönün; çünkü uçurum tam da o cevabın olmadığı yerde başlıyor.

## Sahadan üç senaryo: uçurumun iki yakası nasıl görünüyor?

Soyut kalmasın diye danışmanlıklarımda gerçekten yaşadığım, detayları anonimleştirdiğim üç kısa senaryoyu paylaşayım. Her biri, aynı teknolojinin nasıl bir yakada çöp, öbür yakada değer üretebildiğini gösteriyor.

**Senaryo bir: Çağrı merkezi özeti.** Bir bankanın çağrı merkezinde, her görüşmeden sonra temsilci elle bir özet yazıyordu. Bu iş temsilci başına günde neredeyse bir saat alıyordu. İlk ekip "GenAI ile sohbet botu kuralım, müşteri hiç temsilciye ulaşmasın" diye bir vitrin projesine soyundu; altı ayda müşteri memnuniyeti düştü ve proje sessizce rafa kalktı çünkü karmaşık soruları bot çözemedi ve devir teslim kırıktı. İkinci yaklaşım çok daha mütevazıydı: temsilci görüşmeyi bitirdiğinde, sistem konuşma dökümünden otomatik bir özet taslağı üretiyor, temsilci sadece okuyup onaylıyordu. Yeni bir ekran yok, kopyala-yapıştır yok; özet zaten temsilcinin baktığı ekranda beliriyordu. Temsilci başına kazanılan süre gerçek bir kapasiteye dönüştü, çünkü o süre yeni çağrıları karşılamaya gitti. Fark, teknolojide değil, entegrasyon ve problem seçimindeydi.

**Senaryo iki: Sözleşme tarama.** Bir enerji şirketinin hukuk birimi, yüzlerce tedarikçi sözleşmesinde belirli maddeleri (fesih, cezai şart, mücbir sebep) elle arıyordu. İçeride "kendi modelimizi eğitelim" denildi; altı ay ve ciddi bir bütçe harcandı, ortaya kırılgan, bakımı zor bir sistem çıktı. Sonra strateji değişti: uzman bir tedarikçinin belge analiz çözümü alındı, üstüne şirketin kendi madde tanımları ve KVKK gereği kişisel veri maskeleme katmanı eklendi. Sonuç, içeride harcanan sürenin çok altında ve çok daha güvenilir bir akış oldu. "Al ve üstüne bağlamını koy" formülünün canlı örneği.

**Senaryo üç: Pazarlama içeriği tuzağı.** Bir perakende markası, bütçesinin büyük kısmını sosyal medya metni üreten bir GenAI aracına ayırdı. Araç çalışıyordu, güzel metinler çıkarıyordu. Ama altı ay sonra CFO tek soru sordu: "Bu içerikler satışa ne kattı?" Cevap yoktu, çünkü içerik zaten üretiliyordu; araç sadece hızlandırmıştı ve o hız doğrudan gelire dönmüyordu. Aynı bütçe stok tahmini ya da iade süreci otomasyonu gibi arka ofis bir işe gitseydi, fatura ölçülebilir şekilde küçülecekti. Bu senaryoyu her anlattığımda odadaki yöneticilerin bir kısmı utangaç bir gülümsemeyle başını sallıyor; çünkü aynısını yaşamışlar.

## Uçuruma düşüren beş sessiz varsayım

Başarısız pilotların altında, kimsenin yüksek sesle söylemediği ama herkesin inandığı bazı sessiz varsayımlar yatıyor. Bunları masaya yatırmak, uçurumdan kaçınmanın yarısıdır.

**"Model yeterince iyi olursa gerisi gelir."** Gelmiyor. Model kalitesi çoktan yeterli; darboğaz entegrasyon ve öğrenme tarafında. En iyi modeli seçmek için harcanan enerji, çoğu zaman iş akışına gömme işine harcansa proje kurtulurdu.

**"Önce kuralım, değeri sonra ölçeriz."** Sonradan ölçüm hiç kurulmaz. Taban çizgisi kaybolur, kimse pilot öncesi durumu hatırlamaz ve proje "iyi hissettirdiği" için devam eder ya da "somut fayda göremedik" diye kapanır. İkisi de ölçüm eksikliğinin sonucudur.

**"Bunu içeride yaparsak bize özel olur."** Çoğu iş aslında size özel değil; sektörde binlerce kez çözülmüş standart bir problem. Standart problemi içeride sıfırdan çözmek, kıt yeteneği ziyan etmektir.

**"Araç iyi olursa insanlar kendiliğinden kullanır."** Kullanmazlar. İnsan, en küçük sürtünmede eski alışkanlığına döner. Değişim yönetimi olmadan en iyi araç bile masada tozlanır.

**"Pilot başarılı olursa ölçekleme kolaydır."** Ölçekleme, pilotun kendisinden daha zordur. On kullanıcıda çalışan bir akış, bin kullanıcıda veri, izin, performans ve destek açısından bambaşka bir canavara dönüşür. Bunu baştan hesaba katmayan pilot, başarılı olsa bile ölçekte tıkanır.

Bu varsayımları bir toplantıda yüksek sesle okumak bile faydalıdır; çünkü çoğu ekip, kendi projesinde bunlardan en az ikisine sessizce inandığını fark eder.

## Ölçekleme köprüsü: pilottan üretime

Diyelim ki pilotunuz %5'e yakışır şekilde çalıştı; sayı tuttu, CFO ikna oldu. İş burada bitmiyor, asıl köprü şimdi başlıyor. Pilotu üretime taşırken sahada en sık gördüğüm üç kırılma noktası şunlar.

**Yönetişim ve izin.** On kişilik pilotta göz ardı edebildiğiniz veri erişim izinleri, bin kişilik dağıtımda ciddi bir risk kalemine dönüşür. Kimin hangi veriye eriştiği, modelin hangi verilerle beslendiği, çıktının nerede saklandığı; hepsi KVKK ve iç denetim açısından baştan tasarlanmalı.

**İzleme ve kalite güvencesi.** Pilotta bir yanlış çıktıyı elle yakalayabilirsiniz; üretimde binlerce çıktı arasında bunu yakalayacak otomatik izleme gerekir. Model sürükleniyor mu, kalite düşüyor mu, kullanıcı düzeltme oranı artıyor mu? Bunları ölçen bir gösterge paneli olmadan üretim körlemesine gider.

**Destek ve sahiplik.** Pilotu bir kişi tutkuyla taşır; üretimi bir ekip sahiplenmeli. "Bu araç kimindir, kim bakar, kim geliştirir?" sorusunun cevabı belirsizse, en başarılı pilot bile birkaç ay içinde çürür. Sahipsiz sistem, ölü sistemdir.

Köprüyü kurarken sırrı, ölçeği baştan düşünmektir. En iyi kurumlar pilotu tasarlarken bile "bu bin kullanıcıya çıkarsa ne değişir?" diye sorar. Böylece pilot, üretimin küçük bir provası olur; atılıp yeniden başlanacak bir deneme değil.

## Yatırımı zamana yaymak: üç ufuklu bir bakış

CDO ve CTO'lara sıkça verdiğim bir tavsiye, GenAI portföyünü tek bir kova gibi değil, üç zaman ufkuyla düşünmeleri. Bu, hem beklentiyi yönetir hem de bütçeyi dengeler.

**Yakın ufuk (0-6 ay): hızlı, ölçülebilir kazançlar.** Arka ofiste, net metrikli, düşük riskli işler. Amaç para kazanmaktan çok, kuruma "bu işin değeri gerçek" dedirtmek ve öğrenme kaslarını çalıştırmak. Bir mutabakat otomasyonu, bir belge özeti, bir çağrı özeti buraya girer.

**Orta ufuk (6-18 ay): entegre iş akışları.** Yakın ufukta öğrenilenler, birden fazla adımı kapsayan, birden fazla sistemle konuşan daha derin akışlara dönüşür. Burada öğrenme döngüsü ve entegrasyon olgunlaşır; getiri de büyür.

**Uzak ufuk (18 ay+): farklılaştırıcı yetenekler.** Ancak bu aşamada, size özgü, rekabet avantajı yaratan, belki içeride birlikte inşa edilen yeteneklere geçilir. Çoğu kurumun hata yaptığı yer, sıfırıncı günde doğrudan bu ufka atlamaya çalışmaktır; temel atılmadan çatı kurulmaz.

Bu üç ufuklu bakış, "%5'e nasıl geçilir?" sorusunun da örtük cevabıdır: yakın ufukta disiplinle kazanan kurum, orta ve uzak ufukta zaten farkı açar. Aceleyle uzak ufka atlayan ise genellikle %95'in içinde kaybolur.