Üretken Yapay Zekâ Projesi Başlatmadan Önce Sorulması Gereken 20 Stratejik Soru

Kurumsal üretken yapay zekâ projelerinde en sık görülen hata, teknoloji tarafına çok hızlı geçmek ama stratejik hazırlığı yeterince yapmamaktır. Model seçilir, birkaç demo denenir, ilk sonuçlar umut verici görünür ve proje başlamış kabul edilir. Oysa bu yaklaşım, üretken yapay zekâ projelerinin en kırılgan yönünü gözden kaçırır: başarısızlık çoğu zaman model zayıflığından değil, yanlış problem tanımından, eksik veri hazırlığından, belirsiz sahiplikten, zayıf güvenlik kurgusundan ve ölçülemeyen iş değerinden doğar.

Başka bir ifadeyle, Generative AI projelerinde asıl farkı çoğu zaman teknoloji değil; projeye başlamadan önce sorulan soruların kalitesi belirler. Çünkü doğru sorular, yanlış use-case’i erken eler. Yanlış beklentiyi görünür kılar. Riskli alanları baştan işaretler. Mimariyi sadeleştirir. İnsan onayı gereken noktaları netleştirir. Maliyetin gerçekten nerede oluşacağını gösterir. Ölçekleme için gerekli olgunluk seviyesini ortaya çıkarır.

Bu nedenle üretken yapay zekâ projelerine “hangi modeli kullanalım?” sorusuyla değil, “neyi neden yapıyoruz, hangi veriyle yapıyoruz, nasıl ölçeceğiz, nasıl yöneteceğiz ve nasıl güvenli hale getireceğiz?” sorularıyla başlamak gerekir. Kurumsal olgunluk tam olarak burada başlar.

Bu yazıda, bir Generative AI projesi başlamadan önce kurumların mutlaka netleştirmesi gereken 20 stratejik soruyu sistematik biçimde ele alacağım. Soruları; iş değeri, use-case uygunluğu, veri hazırlığı, güvenlik, yönetişim, maliyet, operasyon ve ölçekleme başlıkları altında işleyeceğim. Amaç, bu soruları yalnızca kontrol listesi olarak değil; kurumsal proje olgunluğunu belirleyen bir ön değerlendirme çerçevesi olarak sunmaktır.

Bir üretken yapay zekâ projesi başlamadan önce doğru soruları sormamak, genellikle şu sonuçlara yol açar:

• İş değeri zayıf use-case’lere yatırım yapılır
• Aslında LLM ile değil klasik otomasyonla çözülmesi gereken problemler seçilir
• Doğru veri yokken modelden mucize beklenir
• PoC başarısı ile production readiness karıştırılır
• Risk yönetimi çok geç devreye alınır
• Başarı ölçülemediği için proje “iyi hissettirdi” düzeyinde kalır

Oysa doğru sorular, projenin başlamadan önce yönünü düzeltir. Bazen en iyi sonuç projeyi hızlandırmak değil, projeyi hiç başlatmamaktır. Stratejik hazırlık tam olarak bu ayrımı yapabilmeyi sağlar.

"

Kritik gerçek: Generative AI projelerinde en büyük tasarruf, doğru modeli seçmekten önce yanlış projeyi seçmemektir.

1. Gerçekte hangi iş problemini çözmeye çalışıyoruz?

Birçok proje teknoloji fikriyle başlar, problem tanımı sonradan eklenir. Oysa önce net iş problemi tanımlanmalıdır. Metin üretimi mi gerekiyor, bilgi erişimi mi, karar desteği mi, süreç hızlandırma mı? Problem net değilse çözüm tasarımı da dağılır.

2. Bu problem gerçekten Generative AI problemi mi?

Her problem LLM ile çözülmez. Bazı sorunlar klasik kural motoru, arama, BI, workflow otomasyonu veya entegrasyon geliştirmesiyle daha doğru çözülebilir. LLM yalnızca gerçekten belirsiz, bilgi yoğun, dil tabanlı veya dönüşüm gerektiren problemler için anlamlıdır.

3. Bu use-case’in iş değeri nedir?

Zaman tasarrufu, kalite artışı, hata azaltma, kullanıcı deneyimi, gelir etkisi veya operasyonel kapasite gibi boyutlarda net iş değeri tanımlanmalıdır. “Yapay zekâ kullanalım” tek başına iş gerekçesi değildir.

4. Bu değer ölçülebilir mi?

Eğer başarıyı nasıl ölçeceğiniz belli değilse proje hızla öznel yorumlara kalır. Dakika tasarrufu, insan düzeltme süresi, görev tamamlama oranı, doğruluk, memnuniyet veya dönüşüm etkisi gibi metrikler baştan tanımlanmalıdır.

5. Use-case neden şimdi ele alınmalı?

Bazı use-case’ler stratejik olarak anlamlıdır ama henüz zamanı gelmemiş olabilir. Veri hazır olmayabilir, güvenlik gereksinimi yüksek olabilir veya organizasyonel sahiplik net olmayabilir. Zamanlama da stratejik bir değişkendir.

6. Nihai kullanıcı kim olacak?

Çalışan mı, yönetici mi, müşteri temsilcisi mi, geliştirici mi, dış müşteri mi? Kullanıcı profili; arayüzü, doğruluk beklentisini, insan onayı ihtiyacını ve latency toleransını doğrudan etkiler.

7. Sistem mevcut iş akışında nereye oturacak?

Üretken yapay zekâ çoğu zaman tek başına değer üretmez; bir iş akışının içine girdiğinde değer üretir. Bu nedenle sistem, sürecin başında mı, ortasında mı, sonunda mı yer alacak netleştirilmelidir.

8. İnsan bu sistemde hangi rolde kalacak?

İnsan tamamen devreden çıkacak mı, gözden geçirici mi olacak, son onayı mı verecek, sadece istisnalarda mı devreye girecek? Human-in-the-loop tasarımı belirsizse risk seviyesi artar.

9. Çıktı taslak mı olacak, öneri mi olacak, doğrudan aksiyon mu üretecek?

Taslak üreten sistem ile işlem başlatan sistem aynı risk sınıfında değildir. Sistemin ürettiği şeyin iş üzerindeki etkisi net tanımlanmalıdır.

10. Modelin ihtiyaç duyduğu bilgiye gerçekten sahip miyiz?

Kurumsal bilgi dağınık, güncel değil, erişilemez ya da kalitesizse modelden güçlü sonuç beklemek gerçekçi değildir. Bilgi katmanı zayıfsa, en iyi model bile sınırlı kalır.

11. Bu use-case için retrieval gerekiyor mu, yoksa prompt yeterli mi?

Kuruma özel, güncel ve kaynaklı bilgi gerektiren senaryolarda retrieval şart olabilir. Her şeyi modele gömmeye çalışmak ya da model hafızasına güvenmek ciddi hata üretir.

12. Veri hassasiyeti seviyesi nedir?

Müşteri verisi, çalışan verisi, sözleşmeler, finansal bilgiler veya hassas iç belgeler kullanılıyorsa veri egemenliği, erişim kontrolü ve model seçimi buna göre şekillenmelidir.

13. Verinin sahibi kim ve veri kalitesinden kim sorumlu?

Çoğu proje bu noktada belirsizleşir. Verinin sahibi yoksa, güncellik ve doğruluk sorumluluğu da dağılır. Veri sahipliği net değilse üretim kalitesi sürdürülemez.

14. Bu use-case’in risk seviyesi nedir?

İç doküman özeti ile müşteriye giden hukuki iletişim aynı riskte değildir. Use-case düşük, orta veya yüksek riskli olarak sınıflandırılmalıdır. Bu sınıf; insan onayı, güvenlik testi ve release kriterini belirler.

15. En kötü senaryoda yanlış çıktı neye yol açar?

Bu soru çoğu zaman ihmal edilir. Oysa üretken yapay zekâ projelerinde gerçek tasarım, başarının değil hatanın etkisini düşünerek yapılır. Yanlış çıktı itibar kaybı mı, finansal zarar mı, süreç gecikmesi mi, güvenlik ihlali mi doğurur?

16. Güvenlik tehdit modeli tanımlandı mı?

Prompt injection, data leakage, role bypass, tool misuse ve yetkisiz erişim gibi riskler daha proje başında düşünülmelidir. Güvenlik, PoC sonrasında eklenecek bir katman olmamalıdır.

17. Regülasyon, audit ve kayıt gereksinimleri nelerdir?

Özellikle finans, sağlık, kamu, savunma ve regülasyon yoğun alanlarda audit trail, veri saklama, erişim kayıtları ve açıklanabilirlik beklentisi netleştirilmelidir.

18. Bu use-case için hangi mimari yaklaşım gerçekten gerekli?

Sadece prompt mu yeterli, yoksa retrieval, workflow, tool use, human approval ve routing katmanları gerekiyor mu? Mimari ihtiyaç yanlış okunursa ya gereksiz karmaşıklık kurulur ya da eksik sistem tasarlanır.

19. Başarı için hangi kalite seviyesi gerçekten gerekli?

Her iş için frontier kalite gerekmez. Bazı use-case’lerde hızlı ve yeterince iyi model daha doğrudur; bazı alanlarda ise çok yüksek doğruluk şarttır. Gerekli kalite seviyesi use-case bazlı tanımlanmalıdır.

20. Bu sistemi ölçeklemek istersek ne değişecek?

PoC seviyesinde çalışan yapı, daha fazla kullanıcı, daha fazla veri, daha fazla istek ve daha sıkı kontrol altında aynı şekilde çalışmayabilir. Ölçekleme; latency, cost, governance, evaluation ve ownership boyutlarıyla önceden düşünülmelidir.

Bu sorular bağımsız kontrol listeleri değildir. Aralarında güçlü bağlantılar vardır. Örneğin iş değeri net değilse başarı metriği de zayıf kalır. Veri hazır değilse doğruluk beklentisi boşa çıkar. Risk sınıfı net değilse insan onayı yanlış tasarlanır. Ölçekleme sorusu sorulmazsa mimari yanlış kurulur. Bu yüzden stratejik hazırlık, bu soruları birlikte okuyabilme disiplinidir.

Kurumsal olgunluk da tam olarak burada görünür. Olgun ekipler yalnızca “ne yapabiliriz?” diye sormaz; aynı zamanda “bunu neden yapıyoruz, hangi koşulda yapıyoruz, ne kadar güvenle yapıyoruz ve başarısız olursa ne olur?” diye de sorar.

Kurumlar bu 20 soruyu daha yapısal hale getirmek için dört ana sütunlu bir değerlendirme tablosu kurabilir:

• İş Değeri: Problem, kullanıcı, KPI, öncelik
• Veri ve Mimari: Bilgi kaynağı, retrieval ihtiyacı, entegrasyon, model tipi
• Risk ve Güvenlik: Risk sınıfı, insan onayı, güvenlik tehditleri, regülasyon
• Operasyon ve Ölçekleme: Sahiplik, evaluation, maliyet, latency, rollout planı

Bu yapı sayesinde proje başlamadan önce yalnızca teknoloji değil, işletim mantığı da görünür hale gelir.

1. İş problemini netleştirmeden modele odaklanmak
2. Use-case uygunluğunu sorgulamadan teknoloji seçmek
3. Başarı kriterini tanımlamadan pilot başlatmak
4. Veri kalitesini ve veri sahipliğini küçümsemek
5. Retrieval gerektiren problemi prompt ile çözmeye çalışmak
6. Risk sınıflandırmasını proje sonrasına bırakmak
7. İnsan onayı gereken alanları netleştirmemek
8. Güvenlik tehdit modelini kurmamak
9. PoC ile ölçeklenebilir sistemi aynı sanmak
10. Maliyeti yalnızca token fiyatı sanmak
11. Sahiplik ve sorumluluğu dağıtık bırakmak
12. Tüm use-case’leri aynı mimariyle çözmeye çalışmak

Soru Alanı	Başlamaya Hazır Sinyal	Uyarı Sinyali
İş değeri	Net KPI ve ölçülebilir fayda	Genel “AI kullanalım” motivasyonu
Use-case uygunluğu	Dil / bilgi yoğun problem	Aslında klasik otomasyon problemi
Veri hazırlığı	Bilgi kaynağı net ve erişilebilir	Dağınık, güncel olmayan veri
Risk yönetimi	Risk sınıfı ve HITL tanımlı	Yanlış çıktının etkisi belirsiz
Operasyon	Sahiplik, eval ve rollout net	“Önce yapalım sonra bakarız” yaklaşımı

İlk 30 Gün: Soruları Cevapla ve Filtrele

• 20 stratejik soruyu aday use-case’lere uygula
• Düşük değerli veya yüksek belirsiz use-case’leri ele
• İlk kısa listeyi iş değeri ve risk dengesine göre oluştur

31-60 Gün: Veri, Risk ve Mimari Netliği Kur

• Bilgi kaynaklarını ve veri hassasiyetini netleştir
• Retrieval, workflow ve human-in-the-loop ihtiyacını belirle
• İlk evaluation ve güvenlik test mantığını tasarla

61-90 Gün: Kontrollü Pilot Kararı Ver

• Sadece stratejik soruları güçlü cevaplayabilen use-case’lerle pilot başlat
• Başarı metriği, sahiplik ve rollout şartlarını baştan tanımla
• PoC ile production readiness ayrımını net koy

Üretken yapay zekâ projelerinde başarı çoğu zaman ilk kod satırında değil, ilk toplantıda belirlenir. Çünkü projenin yönünü, sınırını, riskini ve işletim mantığını belirleyen şey teknoloji seçimi kadar; hatta bazen ondan daha fazla, başlangıçta sorulan sorulardır.

İş problemi net değilse teknoloji dağılır. Veri hazır değilse kalite düşer. Risk düşünülmezse güven kaybolur. İnsan rolü tasarlanmazsa kontrol bozulur. Ölçekleme hesaba katılmazsa ilk başarı kurumsal avantaja dönüşmez. Bu yüzden üretken yapay zekâya başlamak isteyen kurumlar önce hızlanmamalı; önce doğru soruları sormalıdır.

Uzun vadede başarılı kurumlar, en erken pilotu yapanlar değil; en doğru problemi, en doğru hazırlıkla ve en kontrollü çerçevede ele alan kurumlar olacaktır.

Bu 20 sorunun hepsi her proje için gerekli mi?

Evet. Tüm sorular aynı ağırlıkta olmayabilir; ancak her biri proje hazırlığının farklı bir risk ve değer boyutunu görünür hale getirir.

İlk bakılacak en kritik üç soru hangisidir?

Genellikle hangi iş problemini çözdüğünüz, bu problemin gerçekten Generative AI problemi olup olmadığı ve iş değerinin nasıl ölçüleceği en kritik başlangıç sorularıdır.

Bu soruların cevabı net değilse proje başlamamalı mı?

Her şeyin kusursuz net olması gerekmez; ancak temel alanlarda belirsizlik çok yüksekse, önce stratejik hazırlık yapmak çoğu zaman daha doğrudur.

Bu sorular teknoloji ekipleri için mi, iş ekipleri için mi hazırlanmalı?

Her ikisi için. En doğru cevaplar genellikle iş birimi, veri, güvenlik, ürün ve teknik ekiplerin ortak çalışmasıyla çıkar.

Bu çerçeve PoC öncesi mi, production öncesi mi kullanılmalı?

En değerli olduğu yer PoC öncesidir. Çünkü yanlış başlangıcı erkenden fark etmek, sonradan düzeltmekten çok daha ucuzdur.