"Yapay zeka projesine nasıl başlanır?" sorusu, çoğu şirkette teknolojiden çok uygulama disipliniyle ilgilidir. İlk hata genellikle model seçerek başlar. Oysa işe problemi tanımlayarak başlamak gerekir. Hangi süreci iyileştireceksiniz? Hangi karar daha hızlı ya da daha doğru verilecek? Hangi ekip bu çıktıyı her gün kullanacak? Bu sorular netleşmeden, en iyi model bile üretim ortamında değer yaratmaz.

Kurumsal tarafta başarılı başlangıçlar, çoğunlukla küçük ama ölçülebilir hedeflerle yapılır. Örneğin destek taleplerinin ilk sınıflandırmasını otomatikleştirmek, teklif dokümanlarından veri çıkarmak ya da depo operasyonlarında sapma tespiti yapmak gibi. 6-10 haftalık bir pilot, çoğu şirket için gerçekçi bir başlangıç çerçevesi sunar. Daha kısa süreler veri hazırlığını hafife alır; daha uzun sürelerse öğrenme döngüsünü yavaşlatır.

Bu rehberde veri hazırlığı, API entegrasyonu, güvenlik ve pilot kapsamı belirleme başlıklarını teknik ama sade bir çerçevede ele alacağız. Amaç, yapay zeka yatırımını sunum aşamasından çıkarıp çalışan bir ürüne dönüştürmek.

1. Önce problemi tanımlayın: Model değil, iş senaryosu seçin

İyi bir başlangıç için tek cümlelik bir proje tanımı yazılmalıdır. Örneğin: “Müşteri e-postalarını 8 kategoriye ayırıp CRM içinde doğru kuyruğa düşürmek.” Bu tanımda kullanıcı, veri kaynağı, çıktı ve kullanım yeri nettir. Belirsiz hedefler ise projeyi hızla genişletir. “Müşteri hizmetlerinde yapay zeka kullanalım” gibi ifadeler, teknik ekip için uygulanabilir değildir.

İlk aşamada şu 4 soruya yazılı yanıt verin:

  • Karar noktası nedir?
  • Başarı neyle ölçülecek? Örneğin yanıt süresinde yüzde hedefi yerine dakika bazlı düşüş.
  • Çıktı hangi sistemde kullanılacak? ERP, CRM, mobil uygulama, çağrı merkezi ekranı gibi.
  • İnsan onayı gerekecek mi?

İlk pilot için tam otomasyon şart değildir. Hatta birçok senaryoda “öneri üret, kullanıcı onaylasın” yaklaşımı daha güvenlidir. Mesela satın alma taleplerinde sistem, geçmiş siparişlerden tedarikçi önerisi sunar; son karar yine uzman kullanıcıda kalır. Bu kurgu hem riski azaltır hem de kullanıcı güvenini artırır.

2. Veri hazırlığı: Projenin yüzde 50'sinden fazlası burada geçebilir

Kurumsal yapay zeka projelerinde en çok zaman alan bölüm veri hazırlığıdır. Bunun tek nedeni veri miktarı değildir. Veri dağınıktır, farklı sistemlerdedir, etiketleri tutarsızdır, erişim yetkileri karışıktır. 3 farklı kaynaktan gelen müşteri kaydı, aynı kişiyi farklı formatlarda tutabilir. İsim alanı bir yerde “ad soyad”, başka bir yerde iki ayrı kolon olabilir. Model bu karmaşayı kendiliğinden çözmez.

Hangi veri gerçekten gerekli?

İlk pilotta “tüm veriyi alalım” yaklaşımı yerine, minimum gerekli veri seti çıkarılmalıdır. Örneğin talep sınıflandırma projesinde son 12 ayın destek kayıtları çoğu zaman yeterlidir. 7 yıllık arşivi sisteme taşımak, başlangıcı gereksiz yere uzatır. Benzer şekilde belge işleme senaryosunda önce 500-2000 dokümanlık örnek havuzla ilerlemek, veri kalitesini görmek açısından daha pratiktir.

Kontrol listesi kısa ama kritiktir:

  • Veri kaynağı sayısı kaç adet?
  • Güncellenme sıklığı nedir: anlık, saatlik, günlük?
  • Eksik alan oranı kabaca ne düzeyde?
  • Kişisel veri ya da ticari sır içeriyor mu?

Etiketleme ve kalite ölçümü

Gözetimli öğrenme ya da sınıflandırma projelerinde etiket kalitesi doğrudan sonucu etkiler. 1.000 kaydın 200'ü hatalı etiketlenmişse, ekip modelin başarısız olduğunu düşünebilir; oysa sorun veri setindedir. Bu yüzden örneklem üzerinden kalite kontrol yapılmalıdır. Pratik bir yöntem, ilk 300 kaydı iki farklı uzmana bağımsız olarak etiketletmek ve uyuşmazlıkları incelemektir. Uyuşmazlık oranı yüksekse kategori tanımları yeniden yazılmalıdır.

Metin tabanlı projelerde basit bir ön işleme hattı çoğu zaman yeterlidir: karakter normalizasyonu, tekrar kayıt temizliği, tarih formatı standardizasyonu. Buradaki amaç veriyi “mükemmel” hale getirmek değil, üretimde sürdürülebilir kılmaktır.

3. API entegrasyonu olmadan pilot, gerçek hayata bağlanmaz

Bir yapay zeka çıktısı, çalışanların kullandığı sisteme akmıyorsa çoğu zaman ekrandan ibaret kalır. Kurum içinde değer üretmesi için ERP, CRM, WMS, e-ticaret paneli, doküman yönetim sistemi ya da iç portal ile entegre çalışması gerekir. Bu aşamada API tasarımı kritik hale gelir.

En temel akış genellikle şöyledir: kaynak sistem veriyi gönderir, yapay zeka servisi işler, sonucu belirli bir formatta geri döner, işletme kuralı motoru da sonucu kaydeder veya kullanıcıya gösterir. Basit bir örnek JSON yanıtı şu şekilde olabilir:

 {
  "ticket_id": "T-10482",
  "predicted_category": "iade-talebi",
  "confidence": 0.91,
  "needs_human_review": false
}

Burada iki nokta önemlidir. İlki, yalnızca tahmini değil güven skorunu da döndürmektir. İkincisi ise insan incelemesi gerekip gerekmediğini açıkça belirtmektir. Mesela confidence 0.80 altındaysa kayıt manuel kuyruğa düşebilir. Bu tür eşikler pilot sırasında test edilir; üretimde rastgele belirlenmez.

Entegrasyonda sorulması gereken teknik sorular

  • API senkron mu çalışacak, kuyruk bazlı asenkron mu?
  • Yanıt süresi beklentisi nedir? 500 ms ile 30 saniye aynı tasarım değildir.
  • Hata durumunda geri alma senaryosu var mı?
  • Loglama ve izleme hangi katmanda yapılacak?

Örneğin çağrı merkezi ekranında anlık öneri gerekiyorsa, 1-2 saniyeyi aşan gecikmeler kullanıcı deneyimini bozar. Belge arşivleme gibi toplu işlemlerde ise kuyruk tabanlı mimari daha uygun olabilir. İlk pilotta bu ayrımı net yapmak, sonradan mimariyi baştan yazma ihtiyacını azaltır.

4. Güvenlik ve uyum: PII, erişim kontrolü ve kayıt izi

Yapay zeka projeleri güvenlik açısından klasik yazılımlardan daha hassas olabilir; çünkü veri çoğu zaman daha zengin bir bağlam içerir. Müşteri yazışmaları, sözleşmeler, sevk belgeleri, personel kayıtları buna dahildir. İlk günden veri sınıflandırması yapılmalıdır. En azından şu ayrım net olmalıdır: kişisel veri, hassas kişisel veri, ticari sır, operasyonel veri.

Şirket içinde uygulanabilecek temel teknik çerçeve şudur:

  • Aktarım sırasında TLS kullanımı
  • Depolamada şifreleme
  • Rol bazlı erişim kontrolü
  • Prompt ve çıktı logları için maskeleme
  • Audit trail: kim, ne zaman, hangi veriyi işledi

Özellikle üçüncü taraf model veya API kullanılıyorsa, veri işleme sınırları sözleşme tarafında da incelenmelidir. Verinin eğitim amacıyla kullanılıp kullanılmadığı, hangi bölgede işlendiği, saklama süresi ve silme mekanizması netleşmelidir. Bu madde atlanırsa teknik olarak çalışan çözüm, uyum tarafında durdurulabilir.

Pilotta güvenli başlangıç yaklaşımı

İlk denemede tüm canlı veriyi açmak zorunda değilsiniz. Sık kullanılan yöntemlerden biri, 30-60 günlük sınırlı veri setiyle başlamak ve kişisel alanları maskeleyerek test etmektir. Örneğin müşteri adı yerine hash ya da anonim kimlik kullanılır. Yapay zeka yine kategori çıkarabilir, özet oluşturabilir veya risk işareti verebilir. Bu yaklaşım hem güvenlik ekiplerinin onayını hızlandırır hem de hukuki riskleri azaltır.

5. Pilot kapsamı nasıl belirlenir?

İlk pilotun başarısı, neyi dışarıda bıraktığınızla da ilgilidir. Kapsam dar olmalı, çıktı net olmalı, ölçüm en baştan tanımlanmalıdır. 1 departman, 1 süreç, 1 veri kaynağı ile başlayan projeler daha hızlı öğrenme sağlar. 5 sistemli, 4 departmanlı bir kurguda sorun çıktığında kök neden analizi zorlaşır.

İyi bir pilot çerçevesi şu özellikleri taşır:

  • Süre: 6-10 hafta
  • Kullanıcı grubu: 10-30 kişilik net bir ekip
  • İş hacmi: günlük veya haftalık tekrar eden süreç
  • Başarı metriği: süre kısalması, manuel iş yükü azalması, doğruluk artışı

Örnek bir senaryo düşünelim. Bir distribütör firma, e-posta ile gelen sipariş formlarındaki ürün kodlarını ERP'ye elle giriyor. Pilot kapsamı, yalnızca tek bölgenin siparişleri ve sadece 2 belge formatı ile sınırlandırılabilir. Hedef, veri giriş süresini sipariş başına ortalama 7 dakikadan 3 dakikanın altına çekmek olabilir. Bu kadar somut bir çerçeve, teknik ekibin neyi optimize edeceğini açıkça gösterir.

Başarı metriği nasıl seçilir?

“Verimlilik arttı” ifadesi yeterli değildir. Ölçüm tablosu en başta hazırlanmalıdır. Örnek metrikler:

  • İşlem başına süre: 12 dakikadan 5 dakikaya
  • İnsan incelemesine düşen kayıt oranı: yüzde 40'ın altı
  • Yanlış yönlendirilen talep sayısı: haftalık bazda takip
  • API başarısızlık oranı: binde seviyesinde izleme hedefi

Buradaki amaç, projeyi teknik bir gösterim olmaktan çıkarıp operasyonel bir iyileştirmeye dönüştürmektir.

6. Ekip yapısı ve teslim modeli

Başlangıç için büyük bir organizasyona gerek yoktur. Çoğu pilotta 4-6 kişilik çekirdek ekip yeterlidir: iş birimi sahibi, ürün veya proje sorumlusu, veri/entegrasyon geliştiricisi, yazılım geliştirici, güvenlik veya uyum temsilcisi. Gerekirse alan uzmanı yarı zamanlı katkı verir. Tek bir kişinin hem iş ihtiyacını hem entegrasyonu hem de veri kalitesini üstlenmesi genellikle darboğaz yaratır.

Teslim modelinde haftalık döngü işe yarar. İlk hafta kapsam ve veri erişimi. İkinci hafta örnek veri analizi. Üçüncü haftada ilk entegrasyon iskeleti. Dördüncü haftada kullanıcı testine açılacak prototip. Sonraki haftalarda eşik ayarları, hata senaryoları ve raporlama. Bu ritim, yönetim tarafına da görünür bir ilerleme sağlar.

İyi kurgulanmış bir yapay zeka projesi yalnızca model performansıyla değil; veri akışı, güvenlik, entegrasyon ve kullanıcı benimsemesiyle başarıya ulaşır. Başlangıç noktası da çoğu zaman düşündüğünüzden daha nettir: küçük bir iş problemi seçin, veriyi hazırlayın, sistemi mevcut operasyonlara bağlayın, pilotu ölçülebilir tutun. Bu şekilde ilerleyen projeler, ikinci fazda daha güçlü ölçeklenir.

Eğer şirketinizde yapay zeka fikri masadaysa ama başlangıç çerçevesi net değilse, ilk adım teknoloji demosu yapmak değil; iş senaryosu, veri erişimi ve entegrasyon planını aynı masada toplamaktır. Sağlam bir temel, hız kazandırır.