Gökhan MERCANOĞLU

bulut bilişim büyük veri CRM yazılımı Dijital Dönüşüm dijital pazarlama Endüstri 4.0 ERP entegrasyonu Fintech ihtiyaç analizi iş sürekliliği iş zekası Karar Alma KOBİ ERP KOBİ Finansmanı KOBİ teknoloji KOBİ yazılım KOBİ yazılım seçimi KOBİ yazılımı KOBİ yönetimi kurumsal iletişim kurumsal yazılım liderlik makine öğrenmesi marka dili marka iletişimi muhasebe yazılımı Müşteri Deneyimi nakit akışı Navision Proje Yönetimi RPA siber güvenlik Sosyal CRM Sosyal Medya Stratejisi Sosyal Medya Yönetimi stok takibi stok yönetimi süreç optimizasyonu Süreç Otomasyonu TCO analizi tedarik zinciri veri ambarı veri analitiği veri kalitesi üretim planlama

  • Agentic Çözümler Kurumsal İş Akışlarını Nasıl Değiştirir?

    Bir ajanın kaç görevi tamamladığı yanlış metriktir. Doğru soru şu: o ajan hangi kararı insana bıraktı? Gaziantep’te 287 çalışanlı bir makine imalatçısının satın alma ekibi, geçen yılın sonunda bir tedarikçi değerlendirme ajanı devreye aldı. Ajan, teklifleri tarıyor, teslimat geçmişini çekiyor, fiyat tutarsızlıklarını işaretliyordu. Altı hafta sonra ekibin şikâyeti teknik değil yönetimseldi: ajan çok şeyi kendi hallediyor, kararın nerede durduğunu kimse bilmiyordu. Yanlış bir tedarikçi onayı, üç ay sonra üretim hattını durdurdu. Bu, ajanın işlevsiz olduğunu değil, sorumluluk hattının tanımlanmadığını gösteriyordu. Agentic AI tartışmasının 2026’da geldiği yer tam olarak burası: teknik kapasite artık sorgulanmıyor, yönetim netliği sorgulanıyor.Agentic AI, bir büyük dil modelinin tek seferlik sorulara yanıt vermesinden farklıdır. Ajan, bir hedefe ulaşmak için adım sırasını kendisi belirliyor, araçları kendisi çağırıyor ve bir adımın sonucuna göre bir sonraki adımı şekillendiriyor. Bu esneklik değerlidir — ama değerin kaynağı aynı zamanda riskin kaynağıdır. Türkiye’nin kurumsal yazılım ortamında yaygın olan ERP ve CRM sistemleriyle entegrasyon, ajanın operasyonel veriyi gerçek zamanlı okumasına imkân tanır; ancak bu okuma yetkisi yazma yetkisine dönüştüğünde ne olduğunu sormak gerekiyor. EU AI Act’ın 2025’ten itibaren aşamalı yürürlüğe girişiyle birlikte, yüksek riskli iş akışlarında insan gözetimi (human oversight) artık etik tercih değil yasal gereklilik. AB pazarına ihracat yapan Türk firmaları bu gereksinimi doğrudan hissediyor; ihracat belgelerini veya müşteri uyum kayıtlarını işleyen ajanların hangi kararlarda insanı devrede tutması gerektiğini şimdiden belgelemek zorundalar.Agentic mimariyi laboratuvardan kurumsal operasyona taşımanın önünde iki gerçek engel var: veri kalitesi ve görev sınırı tanımı. Bunları sırayla ele almak gerekiyor, çünkü çoğu uygulama ikinci engelde değil birincisinde tökezliyor. Ankara’da faaliyet gösteren orta ölçekli bir lojistik yazılım şirketinin operasyon ekibi, 2025 yılsonunda bir rota optimizasyon ajanı kurdu. Ajan başarılı çalışıyordu — doğru koşullar altında. Sorun, araç verisinin üç farklı kaynaktan beslenmesi ve bu kaynaklar arasındaki senkronizasyonun %63 oranında güncel kalabilmesiydi. Kalan %37’lik veri gecikmesi, ajanın zaman zaman geçersiz araç konumlarıyla rota önerisi üretmesine yol açtı. Sonuç: ajan çalışıyor, ama güvenilirliği operatörün veri kaynağını ayrıca doğrulama alışkanlığına bağlı. Bu durumu ‘ajanın başarısı’ saymak doğru olmaz. Veri bütünlüğü olmadan ajan otomasyonu, manuel sürecin maliyetini artırarak kopyalar.Görev sınırı tanımı meselesine gelince: ajanın neyi yapabileceğini değil, neyi yapmaması gerektiğini belgelemek daha kritik ve daha zor. Konya’da 312 çalışanlı bir ısıtma-soğutma ekipmanı üreticisi, müşteri talep yönetimi için bir ajan pilot başlattı. Ajan standart servis taleplerini sınıflandırıyor, öncelik atıyor ve ilgili teknik ekibe yönlendiriyordu. İlk iki ayda ortalama yanıt süresi 47 saatten 9 saate indi — ölçülebilir ve anlamlı bir iyileşme. Ancak ajanın müşteriye doğrudan e-posta gönderme yetkisi verildiğinde sorunlar başladı: bir müşteriye yanlış teknik dokümantasyon gönderildi, bir diğerine servis garantisinin kapsamı dışındaki bir konuda taahhüt içeren bir mesaj iletildi. Ajan yetkisiz taahhüt verdi; sonuç hem müşteri ilişkisi hem hukuki açıdan yönetilmesi gereken bir dosyaya dönüştü. Bu vakada ajanın başarısı gerçekti — ama sınırı yanlış çizilmişti. Okuma yetkisi ile yazma yetkisi, sınıflandırma yetkisi ile taahhüt yetkisi birbirinden net ayrılmalıydı.Çalışan adaptasyonu, teknik dokümantasyondan çok daha fazla zaman alan kısımdır ve çoğu uygulama planı bunu hafife alır. Ajan devreye girdiğinde çalışanın işi değişir: rutin görev azalır, istisna yönetimi artar. Bu değişim olumludur — ama yalnızca çalışan istisnaları tanıyacak bilgiye sahipse. Aksi durumda ajan çalışanı by-pass eder, çalışan ajanı körü körüne onaylar ve gerçek karar kalitesi düşer. İstanbul’da bir sağlık malzemeleri distribütörünün muhasebe ekibinde yaşanan tablo buydu: fatura mutabakat ajanı %57 oranında işlemi tamamen kapattı, kalan mutabakatları ise insan onayına sundu. Sorun, insan onay adımının içeriğini kimsenin sorgulamıyor olmasıydı — ekip ajanın işaretlediği her şeyi ‘zaten ajan gördü’ refleksiyle geçiriyordu. Kalite güvencesi değil, varlığı taklit eden bir onay döngüsü. Bunu ölçmenin yolu basit: onay adımında reddedilen işlem oranı nedir? Bu oran sıfıra yaklaşıyorsa, insan denetimi işlevini yitirmiş demektir.Sınırlılık notunu açıkça koymak gerekiyor: agentic mimari her iş akışına uygun değil. Yüksek belirsizlik içeren, bağlamın sürekli değiştiği ve kararın insan sezgisi gerektirdiği süreçlerde ajan koordinasyon yükü getirir, yük almaz. Türkiye KOBİ ortamında bütçe kısıtı ve BT kaynağı sınırlılığı bu denkleme ek ağırlık ekliyor: ajanı kurmak bir kez, izleme altyapısını işletmek süreklidir. Döviz bazlı SaaS maliyetleri düşünüldüğünde, yanlış kullanım senaryosu seçimi nakit akışını zorlayan bir yatırım haline gelebilir. Doğru başlangıç noktası şu soruyu yanıtlamaktır: bu süreçte tekrar eden, kurallı ve sonucu doğrulanabilir karar adımları var mı? Varsa ajan değer üretir. Yoksa önce süreci yapılandırmak gerekir — ajanı değil.Gaziantep’teki makine imalatçısına dönelim: tedarikçi değerlendirme ajanını kapatmadılar. Sorumluluk hattını yeniden çizdiler. Ajan artık yalnızca teklifleri sıralıyor ve ön eleme kriterlerini işaretliyor; nihai onay adımı satın alma yöneticisinde ve sistem bunu kayıt altına alıyor. Ölçüm şu: onay adımında değiştirilen öneri oranı ilk dört haftada %72 iken altıncı haftada %48’e indi — yani insan ve ajan birbirini kalibre etti. Bu sayı bir başarı metriği değil, bir olgunluk göstergesi. Agentic AI’ın kurumsal değerini ajan sayısıyla değil, insan-makine karar sınırının ne kadar bilinçli çizildiğiyle ölçebilirsiniz. Bu sınırı belgeleyemiyorsanız, ajana değil önce sürece yatırım yapın.

    6 dk

  • Şirketler AI Ajanlarını Nasıl Konumlandırmalı?

    AI ajan sayısı bir şirketin dijital olgunluğunun ölçütü değildir. Bunu 2026 başında Ankara merkezli, 312 çalışanlı bir sigorta aracılık şirketinde bizzat gördüm. Şirket, müşteri poliçe yenileme sürecini otomatize etmek amacıyla iki farklı SaaS AI ajan platformuna aynı anda yatırım yapmıştı. Altı hafta sonra ajan sistemi müşterilere hatalı prim teklifleri gönderiyordu; kimse hangi sistemin hangi kararı ürettiğini söyleyemiyordu. Sorun teknolojinin kendisinde değildi. Sorun, ‘bu ajan neye karar verebilir, neye veremez?’ sorusunun hiç sorulmamış olmasıydı. Bu makale tek bir tezi savunuyor: şirketler AI ajanlarını araç olarak değil, organizasyonel sorumluluk birimi olarak konumlandırmak zorunda. Bunu yapmadan gerçekleşen her ajan dağıtımı yalnızca hatayı hızlandırır.Kurumların büyük bölümü ajanı bir otomasyon katmanı olarak görüyor: görev tanımla, bağla, çalıştır. Bu yaklaşım kısmen doğru — ama yalnızca ajanın etki alanı dar ve geri dönüşü kolay işlemlerde. Sorun, ajan sistemlerinin 2025-2026 döneminde olgunlaşmasıyla birlikte etki alanlarının genişlemesinde. Artık bir müşteri hizmetleri ajanı yalnızca bilgi vermekle kalmıyor; başvuru başlatıyor, öncelik sıralaması yapıyor, zaman zaman iade kararı üretiyor. Eskişehir’deki orta ölçekli bir makine imalatçısında gördüğüm örnek şu: ihracat teklifleri için devreye alınan ajan, 11 ay boyunca yanlış döviz kuru parametresiyle fiyatlama yapmış. Hata denetim dışı kalmış çünkü ‘ajan zaten çalışıyor’ kabulü bir gözetim boşluğu yaratmış. Hesap verebilirlik hattı belirsiz olan sistemlerde otomasyon, denetimi yok etmenin zarif bir yoluna dönüşür.EU AI Act 2025’te aşamalı yürürlüğe girdi ve Türk şirketleri için AB pazarındaki ticari ilişkiler açısından somut bir uyum sorusu doğurdu. Act’in ‘yüksek riskli AI sistemi’ tanımına giren ajan uygulamaları — istihdam, kredi kararı, sağlık triajı gibi alanlarda çalışanlar — artık teknik dokümantasyon, insan gözetimi ve kayıt tutma yükümlülüğü taşıyor. Türkiye’nin iç hukuku bu çerçeveyle tam uyumlu değil; ama Avrupa’ya ihracat yapan veya AB müşterisi olan her şirket uyum yüküyle karşı karşıya. Bursa’daki bir otomotiv yan sanayi firmasıyla geçen ay yaptığım görüşmede yönetim, kalite kontrol sürecine entegre ettikleri görüntü işleme ajanının hangi risk kategorisinde değerlendirileceğini bilmiyordu. ‘Nasıl ölçersiniz?’ sorusu yanıtsız kalmıştı. Risk kategorisi belirsiz kalan ajan sistemleri için uyum maliyeti her geçen ay büyür — baştan tanımlamak her zaman sonradan düzeltmekten ucuzdur.Türkiye’nin veri egemenliği tartışması 2026 itibarıyla kurumsal karar masasına taşınmış durumda. Bulut tabanlı ajan platformları cazip: hızlı kurulum, düşük başlangıç maliyeti, genişleyen özellik seti. Ama bu platformlardaki ajan aktivitesi şirket verisini yurt dışı sunuculara taşıyabilir. KVKK’nın 9. maddesi yurt dışına veri aktarımını yeterli güvence olmaksızın yasaklıyor; ancak ajan sistemlerinin hangi veriyi işlediği ve nerede sakladığı çoğu zaman teknik ekip tarafından bile tam bilinmiyor. Sağlık sektöründe çalışan bir medikal cihaz distribütörüyle yaptığım değerlendirmede, CRM ajanlarının hasta randevu verilerini işlediği ve bu verinin ajan platformunun eğitim altyapısına dahil edilip edilmediğinin sözleşmede netleştirilmediği ortaya çıktı. Bu bir hukuki risk; ama daha önce bir güven sorunudur. Şirketin müşterisine açıklayamayacağı bir veri akışını sisteme dahil etmesi kabul edilemez. Ajan konumlandırmasının veri egemenliği denetimi olmadan başlaması bu yüzden strateji değil ihmaldir.Peki ‘Pazartesi sabahı ne yapmalı?’ sorusunun yanıtı somut olarak ne? Üç adım öneriyorum — sırası önemli. Birincisi: mevcut ve planlanan tüm ajan sistemleri için bir karar sınırı haritası çıkarın. Her ajan için ‘bu karar ajanın yetkisinde mi, yoksa insan onayı gerekli mi?’ sorusunu yazılı hale getirin. Ajanın yapabileceği ve yapamayacağı işlemler liste olarak belgede görünmeli; bu liste teknik ekip değil iş birimi tarafından onaylanmalı. İkincisi: her ajan için bir ölçüm protokolü tanımlayın. ‘Çalışıyor mu?’ sorusu yeterli değil. ‘Doğru kararı ne sıklıkla veriyor, hata yaptığında ne kadar sürede fark ediliyor, kim düzeltiyor?’ soruları yanıtlanmadan ajan sistemi kör bir noktada çalışıyor demektir. Ankara’daki sigorta şirketine dönerek söylersem: bu üç soruyu sorsalardı, hatalı poliçe teklifleri 48 saatten kısa sürede tespit edilirdi, altı haftada değil. Üçüncüsü: AB pazarında iş yapıyorsanız ajan sisteminizin EU AI Act risk sınıfını hukuk ekibiyle birlikte belirlemenizi şiddetle öneririm — gerekirse harici danışman desteğiyle. Bu bir uyum egzersizi değil, rekabet riskini yönetme kararıdır.Sigorta şirketindeki yönetim kurulu toplantısına geri dönelim: platformları kapattılar mı? Hayır. İki platformdan birini seçip karar sınırı haritasını çıkardılar, insan onayı gerektiren işlemler için bir iş akışı tasarladılar ve ajan aktivite loglarını haftalık gözden geçirmeye başladılar. Dört ayda sistem istikrar kazandı. Şunu söylediler: ‘Başlarken sistemi değil, sınırları kurmuş olsaydık altı hafta kaybetmezdik.’ AI ajanlarını doğru konumlandırmak teknoloji seçimi değil, yönetim disiplini sorusudur. Hangi kararı ajana bırakacağınızı bilmiyorsanız, ajan sizin adınıza her kararı verir — çoğu zaman yanlış.

    5 dk

  • AI Destekli ERP, CRM ve BI Seçerken Hangi Kriterler Gerçekten Önemli?

    Vendor sunumu bitti, ekran kapandı — ve satın alma ekibinin yarısı ‘etkileyiciydi’ dedi. Bu cümleyi son iki yılda onlarca toplantıda duydum. Soru şu: demo ekranındaki akıcı tahmin motoru, sizin ham verinizle, sizin süreç kırıklarınızla ve sizin BT kaynağınızla aynı şekilde çalışır mı? Çoğu zaman çalışmıyor. AI destekli ERP, CRM veya BI seçiminde asıl ayrışma noktası, yapay zekanın varlığı değil; hangi mimaride çalıştığı, hangi veriyi tükettiği ve kuruluşun onu kimin hesabına çalıştırdığını bilebilmesidir. Bu makale o soruların yanıtına bir çerçeve sunuyor — hem satın alma masasında hem de pilot tasarımında kullanılabilecek bir çerçeve.Önce tezi net koyayım: 2026’da ‘AI özelliği var’ ifadesi bir seçim kriteri değil, pazarlama gürültüsüdür. Gerçek kriter, o AI katmanının arkasında ne tür bir mimari olduğu ve bu mimarinin kuruluşun veri olgunluğuyla örtüşüp örtüşmediğidir. Kayseri’de ambalaj malzemesi üreten, 312 çalışanlı bir üretim firmasını ele alalım — temsili ama gerçekçi bir profil. Firma, üç farklı ERP satıcısından teklif aldı; üçü de ‘AI tabanlı talep tahmini’ sunuyordu. Birincisinde AI, yalnızca kendi veritabanındaki son 24 aylık satış datasını kullanıyordu. İkincisi RAG (Retrieval-Augmented Generation) mimarisiyle dışarıdan ham madde fiyat endekslerini de çekiyordu. Üçüncüsü ise ‘büyük dil modeliyle desteklenmiş’ diyordu ama pilot aşamada hangi modelin kullanıldığını bile yazılı olarak veremedi. Bu üç teklif aynı ‘AI’ etiketini taşıyordu. Seçim kriteri olmadan bunları ayırt etmek mümkün değildi.İlk değerlendirme boyutu: AI mimarisi ve veri bağlantısı. Satıcıya şu soruyu sormak gerekiyor — doğrudan, teknik: ‘AI modeli hangi veriyi tüketiyor ve bu veriyi nasıl güncelliyor?’ RAG tabanlı sistemlerde kurumsal belgeler, sözleşmeler, envanter geçmişi ve harici fiyat akışları modele bağlanabiliyor; bu, LLM’nin yalnızca eğitim verisiyle kapalı çalışmasından belirgin biçimde farklı bir kapasite sunuyor. Ama RAG da sihirli değil — ham verinin temiz olmasını zorunlu kılıyor. Eğer stok hareketleri ERP’ye düzensiz giriliyorsa, çok sayıda manuel düzeltme barındırıyorsa, RAG tabanlı tahmin motoru bu kirliliği olduğu gibi amplifikasyonla geri verecektir. Nasıl ölçersiniz? Pilot öncesinde veri kalite skoru isteyin: son 12 ayda elle müdahale edilen kayıt oranı nedir? Bu oran yüzde yirminin üzerindeyse, önce veri yönetimi süreçlerini düzeltin; AI katmanını ondan sonra açın.İkinci boyut: AI ajanlarının sınırları ve hesap verebilirlik haritası. Pek çok ERP ve CRM satıcısı artık ‘otonom ajan’ özelliğiyle geliyor — satın alma siparişi önerebilen, müşteri segmentasyonunu yeniden çizebilen ya da tedarikçi performans puanını güncelleyebilen bileşenler. Bu bileşenlerin satın alma kararında ele alınması gereken üç net soru var. Birincisi: ajan ne öneriyor, ne icra ediyor? Öneri sistemleri denetim yükü açısından çok daha güvenlidir; ajan bir satın alma emri oluşturuyorsa bu tamamen farklı bir yönetişim gereksinimi doğurur. İkincisi: EU AI Act kapsamında bu sistemin risk sınıfı nedir? Türk şirketleri AB’ye ihracat yapıyorsa veya AB’li müşteriyle çalışıyorsa bu sınıflandırma hem uyum hem de sigorta yükümlülüklerini doğrudan etkiliyor. Üçüncüsü: bir hata olduğunda sorumluluk nerede? Satıcı sözleşmesinde ‘AI kararlarından doğan operasyonel kayıplar’ açıkça düzenlenmemişse, o madde müzakere edilmeden imza atılmamalı. Bir Bursa otomotiv yan sanayi firmasında (temsili senaryo) ajan tabanlı satın alma modülünün pilot değerlendirmesinde tam da bu soru muğlak kaldı — satıcı ‘sistem önerir, insan onaylar’ dedi; ama onay adımının hangi kullanıcı rolünde ve hangi zaman aralığında tetikleneceği sistemde tanımlanmamıştı. Pilot donduruldu. Altı haftalık gecikme, sözleşme müzakeresinden değil, işlevsel tanımsızlıktan kaynaklandı.Üçüncü boyut: SLM seçeneği ve veri egemenliği hesabı. Büyük bulut sağlayıcıların LLM tabanlı ERP eklentileri cazip görünüyor; ancak veri egemenliği, özellikle Türkiye’nin KVKK yükümlülükleri ve üretim sırları söz konusu olduğunda, bulut API’sine gönderilen sorgunun ne taşıdığı kritik hale geliyor. SLM’ler (Small Language Models) — 1 ila 13 milyar parametre arasında çalışan, yerel donanımda veya özel bulut ortamında konuşlandırılabilen modeller — bu gerilimi çözmek için 2025’ten itibaren ciddi bir alternatif oluşturuyor. Bir Gaziantep tekstil ihracatçısının (295 çalışan, temsili profil) yaptığı değerlendirmede, SLM tabanlı bir yerel konuşlandırma, aylık bulut API maliyetini döviz bazında yaklaşık 4,5 kat daha öngörülebilir hale getirdi — çünkü sabit lisans yerine token başına ücretlendirme modelinin TL karşılığı kur dalgalanmasıyla doğrudan büyüyordu. SLM seçeneğini değerlendirmek için sorulacak soru şu: satıcı, modelin yerel konuşlandırmasını destekliyor mu, yoksa yalnızca kendi bulut ortamında mı çalışıyor? Yanıt ikincisiyse, bu bir bağımlılık maliyetidir ve seçim matrisine sayısal olarak girilmelidir.Dördüncü boyut: BI katmanında AI yorumunun güvenilirlik sınırı. BI araçlarındaki ‘doğal dil sorgulama’ ve ‘otomatik içgörü’ özellikleri, analistlerin sorgulama yükünü azaltmak açısından kullanışlı — bunu inkâr etmiyorum. Ama bu araçların bir sınırı var ve satıcılar bunu slaytlara yazmıyor: model, verinin ne anlama geldiğini değil, verinin nasıl göründüğünü yorumluyor. İzmir’deki bir perakende zincirinin (temsili vaka) BI pilotunda, sistem ‘satış düşüşünü’ otomatik olarak ‘mevsimsel etki’ olarak etiketledi — oysa o haftaki düşüşün gerçek nedeni, lojistik aksaklığından kaynaklanan bir stok boşluğuydu. Model bunu bilemezdi çünkü tedarik zinciri verisi BI katmanına entegre edilmemişti. Ders şu: AI yorumu ancak veri entegrasyon genişliğiyle orantılı doğrulukta çalışır. Pilot aşamasında ‘otomatik içgörü’ özelliğini değerlendirirken mutlaka bilinen bir anomaliyi kasıtlı olarak besleyin ve sistemin bunu nasıl yorumladığını gözlemleyin. Güvenilirlik testi bu şekilde yapılır, demo sırasında değil.Seçim sürecinde uygulanabilir çerçeveyi şöyle özetleyebilirim. Birinci adım: satıcıya AI mimarisini yazılı olarak belgeletmesini isteyin — ‘RAG mı, fine-tuned model mi, SLM mi, bulut API bağlantısı mı?’ Sözlü yanıt yeterli değil; teknik veri sayfası veya mimari diyagram talep edin. İkinci adım: pilot verisi olarak gerçek kirli verinizi kullanın, satıcının hazırladığı temiz örnek setini değil. Üçüncü adım: EU AI Act risk sınıflandırmasını satıcıdan yazılı olarak talep edin; bu belge hem hukuki hem de operasyonel due diligence için zorunlu. Dördüncü adım: ajan özelliklerini ‘öneri’ ve ‘icra’ olarak ikiye ayırın; icra yetkisi olan her bileşen için sorumluluk maddesi sözleşmede açıkça yer almalı. Beşinci adım: veri egemenliği kararını vermeden önce token başına maliyet modelini TL bazında 24 aylık kur senaryosuna göre hesaplayın. Bir Kayseri üretim firması bu beş adımı sistematik biçimde uyguladıktan sonra ilk favori satıcıyı eledi — çünkü mimari belgesi yoktu. İkinci favori hayatta kaldı çünkü SLM konuşlandırması ve sözleşme sorumluluk maddesi hazırdı. Seçim kriteri olmadan bu ayrımı görmek mümkün değildi; ambalaj firması da demo ekranında o farkı göremezdi.

    7 dk

  • AI Agents ve KOBİ’ler: Büyük Şirket Teknolojisi Küçük Şirket Değerine Dönüşür mü?

    AI Agents sorusu yanlış kurulmuş bir sorudur. ‘KOBİ bu teknolojiyi kullanabilir mi?’ diye soruyorsanız, cevap neredeyse her zaman ‘teknik olarak evet’tir. Ama asıl soru şudur: hangi KOBİ, hangi ajanı, hangi süreç olgunluğuyla? Gaziantep’te orta ölçekli bir gıda işleme fabrikası düşünün — 312 çalışanı var, ihracat yapıyor, tedarik zinciri beş farklı ülkeye yayılıyor. Yönetim ekibi 2025’ten bu yana ajan platformlarını araştırıyor; satıcılar muhteşem demolar sunuyor. Ama fabrika müdürü aylardır aynı soruyla masaya geliyor: ‘Demoda çalışıyor, bizde neden çalışmadı?’ Bu sorunun cevabı teknolojide değil, onun altındaki temelde yatıyor.AI Agents’ın operasyonel tanımını netleştirerek başlayalım: bir ajan, belirli bir hedefe ulaşmak için araçları sıralayan, ortamdaki değişikliklere tepki veren ve insan onayı olmadan ya da minimum onayda adım atan yazılım birimidir. 2024-2025 döneminde bu kategori olgunlaştı; artık satın alınabilir, SaaS modelde erişilebilir ajan altyapıları mevcut. Microsoft Copilot Studio, Salesforce Agentforce, Anthropic Claude’un API tabanlı ajan çerçeveleri ve bir dizi açık kaynak platform, kurumsal BT departmanı olmayan bir şirkete bile ajan inşa etme imkânı sunuyor. Bu demokratikleşme gerçek. Ancak ‘erişim kolay’ ile ‘değer üretiyor’ arasındaki mesafe hâlâ çok açık.Bir ajanın gerçekten değer üretmesi için üç koşulun aynı anda sağlanmış olması gerekiyor. Birincisi, süreç belgelenmiş olmalı: ajan taklit ettiği iş adımlarını açık, tekrarlanabilir kurallara çevirebilmelidir. İkincisi, veri erişilebilir ve güvenilir olmalı: ajan temiz veri olmadan halüsinasyon üretir, bu sefer hızlı ve otomatik biçimde. Üçüncüsü, başarı ölçülebilir olmalı: ‘iyi çalışıyor’ gibi subjektif değerlendirme yerine, ajanın ürettiği sonuç somut bir metrikle izlenebilmelidir. Bu üç koşulun tamamı kurumsal şirketlerde zaten olgunlaşmış durumdadır; KOBİ’lerde ise en az biri — çoğunlukla üçü birden — eksiktir. Temel tezim budur: AI Agents KOBİ için erişilebilir hale geldi, ama faydalı hale gelmesi için KOBİ’nin önce kendi süreç ve veri altyapısını hazır hale getirmesi zorunludur.Gaziantep’teki gıda fabrikasına geri dönelim. Fabrika, tedarikçilerden hammadde alım onaylarını e-posta yoluyla yönetiyor; bu e-postalar üç farklı çalışanın gelen kutusuna dağılıyor, kimi zaman kaybolduğu oluyor, kimi zaman aynı onay iki kez veriliyor. Ajan bu sürece teorik olarak uygun görünüyor: e-postayı oku, tedarikçi bilgisini doğrula, ERP’deki stok durumunu kontrol et, eşiğin altındaysa onay isteği gönder. Ama fabrika bu süreci hiçbir yerde belgelemiş değil. Her çalışan kendi yöntemiyle ilerliyor; ERP’deki tedarikçi kayıtlarının büyük bölümü güncel değil; onay eşikleri yazılı değil, patronun zihninde. Bu koşulda ajan kurulumu, belgesiz bir süreci daha hızlı yanlış yapmaktan ibaret kalır. Önce süreci belgele, ERP kayıtlarını güncelle, onay mantığını kural olarak yaz — sonra ajan tartışmasını aç. Bu sıralamayı tersine çeviren proje, Türkiye’de son iki yılda defalarca başarısız oldu.Peki hangi KOBİ senaryoları gerçekten işe yarıyor? Bursa’da bir otomotiv yan sanayi firması — 445 çalışan, Tier 2 tedarikçi konumunda — müşteri sipariş onay sürecine bir ajan entegre etti. Süreç zaten ERP içinde tanımlıydı, onay kuralları yazılıydı, müşteri verileri temizdi. Ajan; gelen sipariş talebini okuyup kapasiteyle karşılaştırıyor, uyumluysa ön onay üretiyor, çatışma varsa sorumlu mühendise özetli bir bildiri gönderiyor. Ortalama onay süresi 4,5 iş gününden 6 saate indi. Bu ölçüm gerçek, bağımsız denetlenebilir. Ama bu sonuç ‘ajan güçlü olduğu için’ değil, ‘süreç zaten hazırdı’ çünkü mümkün oldu. Başka bir örnek: İzmir’de e-ticaret yapan orta ölçekli bir tekstil markası, müşteri iletişim ajanı kurdu. İlk üç haftada müşteri şikâyetleri artı yönde etkilenen taleplerin %53’ünü halletti. Ama dikkat: kalan %47 hâlâ insan müdahalesi gerektiriyor — ajan sınırını biliyor, kendi yetersiz kaldığı durumlarda eskalasyon yapıyor. Bu ‘başarı’ ancak ajan sınırı doğru çizildiğinde geçerli.EU AI Act uyumu 2026 itibarıyla Türkiye’deki ihracatçı KOBİ’ler için yeni bir operasyonel yük. Yüksek riskli sistemler kategorisine giren ajan kullanımlarında — insan kaynakları, kredi değerlendirme, müşteri segmentasyonu — uyumluluk dokümantasyonu zorunlu hale geliyor. Türkiye AB pazarına ihracat yapan bir gıda veya tekstil KOBİ’si, bu şartları fiilî müşteri talebi olarak alıyor; yalnızca regülasyon meselesi değil, ticaret meselesi. Yerel veri egemenliği tartışması da bu bağlamda keskinleşiyor: bulut tabanlı ajan servisleri üretim verisini hangi coğrafyada işliyor? Yerli SLM alternatifleri hız ve maliyet açısından rekabetçi mi? Bu soruların somut yanıtları henüz yerleşmedi — ve ‘bekleyin, netleşsin’ stratejisi, AB müşterisi olan KOBİ için artık bir seçenek değil.Pazartesi sabahı ne yapmalısınız? Üç adım: birincisi, ajan adayı olarak tanımladığınız süreci kâğıda döküp en son ne zaman değiştiğine bakın — altı aydan eski, belgesiz veya çalışana göre değişen bir süreç ajan için hazır değildir, önce orayı sabitleyın. İkincisi, o sürece akan verinin kalitesini ölçün: ERP ya da CRM’inizdeki kayıtların kaçta kaçı güncel ve eksiksiz? Bu oran %71’in altındaysa ajan kurulumu öncesinde veri temizleme projesi açın; aksi hâlde ajan temiz olmayan veriyi daha hızlı yanlış işler. Üçüncüsü, ‘başarı’ için bir sayı belirleyin: hangi metrik, hangi zaman diliminde, ne kadar iyileşirse bu yatırım mantıklıydı diyeceksiniz? Bu sayıyı projenin başında yazmak, altı ay sonra ‘sanırım işe yaradı’ tuzağına düşmekten korur. AI Agents büyük şirket teknolojisi olmaktan çıktı — ama küçük şirket değerine dönüşmesi hâlâ otomatik değil. Bursa’daki otomotiv firması bu dönüşümü başardı çünkü sürecini biliyordu. Gaziantep’teki fabrika henüz başaramadı çünkü başlamadan önce farklı bir işi yapması gerekiyor.

    6 dk

  • Generative AI ROI’si 2026’da Nasıl Daha Net Ölçülür?

    Çoğu şirket Generative AI ROI’sini ölçemiyor diye yakınıyor. Bu doğru değil — ölçüyor, ama yanlış şeyi ölçüyor. İşte bu yüzden analizler yapay pozitif ya da açıklanamaz negatif çıkıyor. 2023’te pilot başlatıp 2024’te ölçmeye çalışan ekiplerin büyük çoğunluğu çıktı verimini saydı: kaç belge üretildi, kaç e-posta yazıldı, bir görev kaç dakika kısaldı. Bu metrikler gerçek ama yetersiz. Karar kalitesi değişti mi? Hata maliyeti ne kadar düştü? Çalışanın dikkat kapasitesi yüksek değerli işe mi kaydı? Bu sorular cevaplanmadan hesaplanan ROI, bir muhasebe satırı değil; güzel bir tahmindir.İzmir’deki orta ölçekli bir sigorta aracılık şirketini ele alalım — 312 çalışan, yedi şehirde acentesi var. Şirket 2024 başında RAG tabanlı bir poliçe sorgulama sistemi kurdu. İlk altı ayın ölçümü şunu gösterdi: müşteri temsilcisinin poliçe bilgisine erişim süresi 4,5 dakikadan 48 saniyeye indi. Güzel bir rakam. Ama sistem müdürü bu rakamı CFO’ya sunduğunda ilk soru şu oldu: ‘Peki müşteri memnuniyeti ne oldu? Hata oranı düştü mü? Temsilcinin kazandığı 4 dakikayı ne yapıyor?’ Üç sorudan ikisine cevap yoktu. Taban çizgisi kurulmamıştı; kazanılan zamanın nereye gittiği izlenmemişti. Bu eksiklik, harika operasyonel verinin yönetim kararına dönüşememesi demektir.Taban çizgisi disiplini — baseline discipline — AI ROI hesabının en zayıf halkası olmaya devam ediyor. Bunun nedeni teknik değil, organizasyonel: birisi AI sistemi devreye girmeden önce ‘şu anda bu süreci nasıl yapıyoruz ve bunu nasıl ölçüyoruz?’ sorusunu sormalı. Çoğu KOBİ’de bu soruyu soran yoktur, çünkü ölçüm kültürü oturmamıştır. Bir Ankara’lı inşaat malzemeleri toptancısı — 445 çalışan, yurt içi B2B satış — 2025 ortasında müşteri tekliflendirme sürecine LLM destekli bir öneri motoru ekledi. Proje başlamadan önce teklif hazırlama süresinin kaydı yoktu; tahminler ‘yaklaşık iki saat’ diye konuşuyordu. Sistem devreye girdikten sonra ‘yüzde kaç iyileştirme?’ sorusu yanıtsız kaldı. Gerçek sonuç muhtemelen iyiydi, ama ölçülemedi. Burası teselli değil, öğretici nokta: AI projesinin bütçesi onaylanmadan önce ölçüm altyapısı kurulmuyorsa ROI analizi başlamadan kapanmış demektir.Ajan bazlı sistemler değer atıfını daha da karmaşık hale getirdi. 2025-2026 döneminde kurumsal kullanımı hız kazanan AI ajanları çoğu zaman bir insan iş akışının ortasına giriyor; bir kısmını otomatikleştiriyor, bir kısmını hızlandırıyor, bir kısmını ise insana geri gönderiyor. Bu hibrit modelde ‘bu ajanın katkısı neydi?’ sorusu düzgün yanıtlanmak istiyorsa değer atıf modeli kurulmak zorunda. Bir Bursa’lı otomotiv yedek parça ihracatçısı — 378 çalışan, Almanya ve Polonya’ya doğrudan satış — dış ticaret belgelerini hazırlayan bir ajan sistemi 2025 sonunda devreye aldı. İlk üç ayda ajanın işlediği belge sayısı ve insan düzeltmesi gerektiren oranı kayıt altına alındı. Dört ay sonra düzeltme oranı ilk ölçüme göre yüzde on yedi düşmüştü. Bu rakam hem sistem öğrenmesini hem gerçek operasyonel değeri gösteriyor. Kilit fark şu: şirket devreye almadan önce atıf mekanizmasını tasarlamıştı; ‘insan ne yaptı, ajan ne yaptı, hata neredeydi’ ayrımı sistemin içine kodlanmıştı. Ajanı kurup sonra ‘ne kadar kazandırdı?’ diye sormak, fabrikayı açıp sonra sayaç takmaya çalışmak gibidir.Portföy yaklaşımı 2026’da artık bir lüks değil, zorunluluk. Generative AI projeleri artık tek tek pilot değil; birden fazla ajan, birden fazla LLM bağlantısı, birden fazla iş sürecini etkileyen bir sistem ailesi olarak işliyor. Bu karmaşıklıkta tek proje bazlı ROI hesabı yanıltıcı olabiliyor — bir ajan başka bir ajanın çıktısını kullanıyorsa kimin katkısı nedir? Türkiye’de finansal hizmetler ve büyük perakende zincirlerinde bu sorunun tam ortasında olan ekiplerle çalışıyorum. Gördüğüm olgun yaklaşım şu: AI portföyünü iki kova olarak yönet. Birinci kova — verimlilik ajanları: belgelenmiş süre ve hata tasarrufu, haftalık izleme, net ROI eşiği var. İkinci kova — karar destek sistemleri: kısa vadeli ROI belirsiz, değer ufku 12-18 ay, başarı kriteri ‘karar kalitesindeki değişim’. Bu iki kovanın aynı metrikle ölçülmesi hem birincisini hafife alır hem ikincisini haksız yere öldürür. EU AI Act’ın yüksek riskli sistem sınıflandırması da bu ayrımı güçlendiriyor: karar destek sistemleri farklı yönetişim yükümlülükleri taşıyor, dolayısıyla farklı ölçüm çerçeveleri gerektiriyor.Pazartesi sabahı ne yapacaksınız? Birinci adım: önümüzdeki üç ayda başlatacağınız veya hâlihazırda çalışan her AI projesine bir taban çizgisi zorunluluğu koyun — sistem devreye girmeden önce mevcut sürecin ‘şu anda nasıl çalışıyor ve bunu nasıl ölçüyoruz’ sorusu iki sayfa cevabını bulmuş olmalı. İkinci adım: ajan sistemleri için değer atıf mekanizmasını teknik ekiple birlikte sistem içine kodlayın — ‘insan adımı’, ‘ajan adımı’ ve ‘hata/düzeltme’ ayrımı kayıt altına alınmadan ROI sorusu cevaplanamaz. Üçüncü adım: AI projelerinizi iki kovaya ayırın, her kovaya farklı ölçüm ritmi ve başarı eşiği tanımlayın; CFO sunumunuzu ‘bu proje ne kadar kâr etti?’ değil ‘bu proje hangi kovada, o kovanın kriterini karşılıyor mu?’ sorusu etrafında kurun. Generative AI’nin üç yıllık kurumsal deneyinin bize öğrettiği şeyi tek cümleyle söyleyeyim: ROI sorunu ölçüm problemidir, teknoloji problemi değil. Sistemi kurmak zor; neyi, ne zaman, neyle kıyaslayarak ölçeceğini bilmek daha zor. Ve Türkiye’de bunu doğru yapan şirketlerin sayısı hâlâ bir elin parmaklarını geçmiyor.

    6 dk

  • AI Operating Model: Yapay Zekâyı İşletim Katmanına Gömmek İçin Gerçek Bir Çerçeve

    Yapay zekâ bütçesi onaylayan ama bir yıl sonra hiçbir çıktısını ölçemeyen şirketlerin sayısı, Türkiye’de artık saymakla bitmez hale geldi. Konya’da 312 çalışanlı bir gıda işleme tesisini ele alalım: Fabrika müdürü 2024 sonunda üç farklı SaaS AI çözümü için onay aldı — talep tahmin modülü, kalite kontrol görüntü işleme ve tedarikçi risk skoru. On dört ay sonra bu araçlardan yalnızca biri üretim akışına gerçek anlamda entegre olmuş durumda; diğer ikisi hâlâ ‘değerlendirme aşamasında’. Sorun araçların kalitesiyle değil, bu araçların kimin sorumluluğunda olduğu, hangi kararı etkilediği ve nasıl ölçüleceği sorusunun hiçbir zaman yanıtlanmamış olmasıyla ilgili. Yapay zekâyı satın almak işletim modeli kurmak değildir — bu ikisini karıştırmak, pilot mezarlığının tek nedenidir.AI Operating Model, bir teknoloji mimarisi belgesi değildir. Şirketteki her yapay zekâ kullanımı için üç soruyu net yanıtlayan bir yönetim çerçevesidir: Bu karar kimin yetkisinde? Bu sürecin sahibi kim? Bu çıktının performansı hangi metrikle izleniyor? Karar hakları (decision rights) meselesi, Türkiye KOBİ yapısında özellikle kritik çünkü burada ‘patron onayı’ hâlâ en güçlü mekanizma. Bir AI ajanı bir tedarikçiye otomatik sipariş gönderdiğinde bu kararı kim aldı? Ajan mı, sistemi kuran IT danışmanı mı, yoksa satın alma müdürü mü? Bu soru yanıtsız kaldığında ilk hata anında herkes sorumluluğu reddeder — ve sistem ya devre dışı bırakılır ya da sonuçlarına güvensizlikle bakılır.Süreç entegrasyonu meselesi, çoğu şirketin sandığından daha katmanlıdır. Konya’daki gıda fabrikasına geri dönelim: Talep tahmin modülü teknik olarak çalışıyor. Modelin öngördüğü hammadde miktarları doğru geliyor. Ama satın alma ekibi bu çıktıya güvenmiyor çünkü modelin mantığını anlamıyor ve tahminlerin nasıl üretildiğini sorgulayamıyor. Burada RAG mimarisiyle desteklenen bir açıklanabilirlik katmanı devreye girebilir — modelin her öngörüsünü geçmiş sipariş verileri ve stok hareketi bağlamıyla birlikte sunan, satın alma müdürünün ‘neden bu kadar?’ sorusunu yanıtlayan bir arayüz. Ancak bu teknik çözümü hayata geçirmek yetmiyor; satın alma sürecinin adımlarının da yeniden tanımlanması gerekiyor. Hangi adımda modelin çıktısı devreye giriyor, hangi adımda insan kararı zorunlu, hangi adımda çıktı geçersiz sayılarak eskalasyon tetikleniyor? Bunu yazılı hale getirmeyen şirketler, teknik entegrasyon tamamlansa bile operasyonel kaosla karşılaşıyor.EU AI Act’ın 2025’te yürürlüğe girmesiyle birlikte bu soruların yanıtlanması artık tercihten çıktı — AB pazarına ihracat yapan ya da AB merkezli iş ortaklarıyla veri paylaşan Türk şirketleri için uyum zorunluluğu haline geldi. Act’ın ‘yüksek riskli AI sistemi’ sınıflandırması, işe alım, kredi kararları, üretim kalite kontrol ve medikal teşhis gibi alanlarda doğrudan devreye giriyor. Bir Türk gıda ihracatçısı AB alıcısıyla sözleşme imzaladığında artık ‘AI sistemleriniz için insan gözetim mekanizmanız var mı?’ sorusunu alıyor. Bu sorunun yanıtı birer teknik doküman değil, AI Operating Model’in bizzat kendisidir: kimin denetlediği, neyin loglandığı ve hangi eşikte otomatik kararın durdurulduğu. Konya fabrikasındaki kalite kontrol görüntü işleme sistemi tam da bu yüzden ‘değerlendirme aşamasında’ kaldı — AB alıcısının talep ettiği denetim dokümantasyonu henüz hazır değil.Performans yönetimi meselesi, AI Operating Model’in en çok ihmal edilen katmanıdır. Şirketler AI çözümleri için başarı metriği tanımlamakta zorlandığında genellikle iki hata yapıyor. Birincisi, araçların teknoloji metriğiyle ölçülmesi: model doğruluk oranı, API çağrı süresi, uptime yüzdesi. Bunlar IT operasyonunu ilgilendiren metriklerdir; iş değeri metriği değil. İkincisi, sonuç beklentisinin araçtan değil bütçeden belirlenmesi: ‘X TL harcadık, X TL tasarruf etmeli.’ Bu yaklaşım, yapay zekânın nasıl değer ürettiğini anlamamaktan kaynaklanır. Doğru metrik tasarımı şöyle kurulur: AI ajanı hangi süreç adımını etkiliyor — o adımın mevcut süresi ve hata oranı nedir — ajan devreye girdikten sonra bu iki göstergede ölçülebilir değişim var mı? Konya fabrikasında çalışan talep tahmin modülünün gerçek katkısı şu şekilde ölçüldü: manuel talep planlamasına ayrılan haftalık iş saati %48 azaldı ve acil tedarikçi siparişlerinin sayısı yıllık bazda 23’ten 9’a indi. Bu iki rakam IT metriği değil, iş metriği — ve bunlar karar vericiye modelin değerini somut olarak gösteriyor.Şunu açıkça söylemek gerekiyor: AI Operating Model, her KOBİ için aynı karmaşıklıkta kurulmamalıdır. Beş yapay zekâ kullanımı olan orta ölçekli bir gıda fabrikası için yeterli olan şey; bir A4 sayfasına sığan karar hakları matrisi, her kullanım için iki-üç iş metriği ve aylık kısa bir gözden geçirme döngüsüdür. SLM tabanlı bir içerik üretim ajanı için gerekli denetim mekanizması, yüksek riskli bir kalite kontrol sistemi için gerekenden tamamen farklıdır — bunları aynı yönetim çerçevesine sokmak hem gereksiz bürokratik yük hem de gerçek riskleri gizleme tehlikesi taşır. ‘Herkese uyan tek çerçeve’ iddiasıyla satılan AI governance paketlerine bu yüzden şüpheyle bakın; ölçeği ve riski olmayan bir çerçeve, uyumluluk oyunculuğuna dönüşür.Konya’daki fabrika müdürü bugün elindeki çalışan aracı için şunu biliyor: kimin onayladığını, neyi ölçtüğünü ve ne zaman durduracağını. Diğer iki araç hâlâ beklemede — ama artık nedeni belli: biri için karar hakları tanımlanmamış, diğeri için iş metriği yok. Bu netlik küçük bir ilerleme gibi görünebilir. Yapay zekâ konuşmalarında ‘dönüşüm’ kelimesinin sık geçtiği bu dönemde, hangi aracın çalıştığını ve neden çalıştığını bilen bir fabrika müdürü, on beş pilot başlatıp hiçbirini ölçemeyen rakibinden çok daha sağlam bir zeminde duruyor. AI Operating Model’i kurmak sizi ileriye taşımaz — ama kurmazsanız geriden bakmak zorunda kalırsınız.

    6 dk

  • 2026’da Yapay Zekâ: Proje Portföyünden AI İşletim Modeline Geçiş

    Yapay zekâ proje sayısını başarı metriği olarak kullanan şirketler yanlış soruyu soruyordur. Yanlış soru şu: ‘Kaç AI projemiz var?’ Doğru soru şu: ‘Bu sistemler Pazartesi sabahı kaç süreç kararını insansız veriyor, hangisini neden insana teslim ediyor ve bu kararların hangisi denetim altında?’ İki sorunun arasındaki mesafe, 2026 itibarıyla Türkiye’deki kurumların büyük çoğunluğunun hâlâ geçemediği bir eşiği tanımlıyor. Deneysel dönem kapandı — en azından bu konuyu ciddiye alan şirketler için. Ama deneysel dönemin kapanması, operasyonel olgunluğun otomatikman başladığı anlamına gelmiyor. Bu iki aşama arasında oldukça geniş ve tehlikeli bir boşluk var: projeyi teslim etmişsiniz, demo başarılı, yönetim kurulu memnun; ama sistem gerçek iş yüküyle karşılaştığında ya sessizce başarısız oluyor ya da insan denetimi olmadan yanlış kararlar alıyor.Deneysel AI döneminin Türkiye’deki mirası karışık. 2023-2024 yıllarında pek çok orta ölçekli şirket pilot projeler başlattı — bazıları fatura işleme, bazıları müşteri segmentasyonu, bir kısmı üretim hattı kalite kontrolü alanında. Bu pilotların önemli bir bölümü gerçekten çalıştı, ölçülebilir iyileştirmeler sağladı. Sorun pilotun kendisinde değildi. Sorun şuydu: pilot, kurumun geri kalanından izole bir başarı olarak kaldı. Veri akışı başka departmanlara bağlı değildi. Modelin kararları herhangi bir süreç belgesiyle ilişkilendirilmemişti. Kim sorumluydu, kim itiraz edebilirdi, model ne zaman güncellenecekti — bunların hiçbirinin net cevabı yoktu. Şu anda İzmir’de plastik hammadde üretimi yapan, 312 çalışanlı bir kimya firmasının operasyon direktörüyle konuştuğumda tam da bu tabloyu anlattı: ‘Pilot harika gitti. Sonra sistemi genele açtık, üç ay sonra kimse kullanmıyordu.’ Nedeni araştırdıklarında modelin çıktıları hangi kararla ilişkilendirileceğini saha ekibinin bilmediğini buldular. Entegrasyon değil benimseme sorunuydu — ama kökü, projenin başından beri işletim modelinin kurulmamasındaydı.AI işletim modeli soyut bir kavram değil. Üç somut bileşenden oluşuyor: hesap verebilirlik haritası, karar sınırı tanımı ve ölçüm döngüsü. Hesap verebilirlik haritası şunu belirliyor: hangi AI kararında hangi insan onay yetkisi var, hata durumunda süreç kime ulaşıyor? Karar sınırı tanımı şunu belirliyor: bu sistem neyi kendi başına yapabilir, neyi insan onayına sunmak zorunda? Ölçüm döngüsü şunu soruyor: modelin performansı hangi sıklıkta, hangi veriyle yeniden değerlendiriliyor? Bu üçü yazılı değilse — sadece zihinde değil, belgede — AI sisteminiz işletiyor değil tesadüfen çalışıyordur. Pratik örnek: İzmir kimya firması bu dersten sonra aynı modeli yeniden hayata geçirdi. Bu kez tedarikçi sipariş önerisi için bir karar sınırı koydular: 50.000 TL altındaki sipariş önerileri sistem onaylar ve satın alma birimine bildirir; üstündeki öneriler satın alma sorumlusunun ekranında onay bekler. Benimseme oranı sekiz hafta içinde sahadaki tüm satın alma personelinin yüzde seksenini aştı. Fark, teknoloji değil sorumluluk netliğiydi.Bu noktada Türkiye’nin özgün bir sorunu devreye giriyor. EU AI Act’ın 2025 itibarıyla aşamalı yürürlüğe girmesiyle birlikte, AB pazarına ihracat yapan veya AB kökenli tedarikçilerle çalışan Türk şirketleri uyum baskısıyla yüzleşiyor. Yüksek riskli AI sistemleri için insan denetim zorunluluğu, log tutma yükümlülüğü ve şeffaflık gereklilikleri — bunlar artık soyut politika tartışması değil, ihracat kontratlarına giren ön koşullar haline geliyor. KVKK ile çakışma noktası ise farklı ama eş derecede somut: bir RAG (Retrieval-Augmented Generation) mimarisiyle çalışan müşteri hizmetleri ajanı, sorgu sırasında kişisel veri içeren belgeleri bağlam olarak çekiyorsa KVKK kapsamında veri işleme sayılıyor. Peki bu işleme için açık rıza var mı, saklama süresi tanımlı mı, hangi belge hangi kullanıcıya açık? Bu soruları yanıtlamadan AB pazarında faaliyet gösteren bir şirketin hukuki riski ciddi. Gaziantep’te tekstil ihracatı yapan, 378 çalışanlı bir konfeksiyon firması bu gerilimi geçen yıl yaşadı: Alman alıcı, müşteri iletişiminde kullanılan yapay zekâ sisteminin EU AI Act uyumunu belgeleyen bir teknik dosya istedi. Şirket böyle bir dosyanın varlığından habersizdi. Sözleşme yenileme gecikti, yedi haftaya yayılan teknik düzeltme süreci başladı.SLM’lerin (küçük dil modelleri) bu tablodaki rolüne ayrıca değinmek gerekiyor, çünkü yanlış anlaşılıyor. SLM’ler büyük bulut modellerinin ucuz versiyonu değil, farklı bir mimari tercih. Veri egemenliği sorunu olan sektörler için — ilaç, finans, savunma tedariki — kendi altyapısında çalışan, dışarıya veri sızdırmayan ve belirli bir domain için ince ayar yapılmış küçük modeller operasyonel olarak anlamlı avantaj sunuyor. Türkiye’de bu tercih kur baskısıyla da örtüşüyor: büyük bulut API’larına ödenen dolar bazlı fatura, TL geliri olan bir KOBİ için sürdürülebilir olmayan bir maliyet kalemi haline gelebiliyor. Yerelde konuşlandırılan, sınırlı ama iyi tanımlanmış bir görev için eğitilmiş SLM, maliyet-performans dengesinde çoğu zaman daha elverişli. Ama burada da sınırı net çizmek gerekiyor: SLM genel amaçlı asistan değil, dar bir görevin uzmanı. Bunu karıştıran şirketler hayal kırıklığıyla karşılaşıyor. Bir modelin ‘küçük ama güçlü’ olması, her soruya cevap vereceği anlamına gelmiyor — doğru soruya tutarlı cevap vermesi, işletim katmanında zaten yeterli.Nasıl ölçersiniz? Bu soruyu yanıtsız bırakmak, AI yatırımını kör bir harcamaya dönüştürür. İşletim katmanına geçen her AI bileşeni için üç metrik tanımlanmalı: birincisi karar doğruluğu — sistemin ürettiği kararların insan uzman kararıyla örtüşme oranı, altı haftada bir yeniden ölçülmeli; ikincisi geri devir oranı — sistem önerilerinin insan tarafından ne sıklıkla reddedildiği, yüksekse ya model performansı düşmüş ya da karar sınırı yanlış çizilmiş; üçüncüsü müdahale gecikmesi — bir anormallik tespit edildiğinde sorumlu kişiye ulaşma süresi. Bu üç metrik spreadsheet’te değil, sisteminizin ürettiği loglardan otomatik okunabiliyorsa işletim modeliniz çalışıyor demektir. Okuyamıyorsanız, pilot dönemde takılı kalmışsınızdır.İzmir’deki kimya firmasının operasyon direktörü konuşmamızın sonunda şunu söyledi: ‘Artık AI projem var demiyorum. AI ile ne karar alıyorum, hangisini neden alamıyorum, bunu söylüyorum.’ Bu cümle, 2026’da kurumsal AI olgunluğunun tam karşılığı. Teknoloji satın almak bir başlangıç noktası, işletim modeli kurmak ise asıl iş. Kuruluşunuzun bu iki nokta arasında nerede durduğunu anlamak için tek bir soru yeterli: Yapay zekâ sisteminiz bir hafta boyunca sessizce yanlış karar verse, kaçıncı günde fark ederdiniz?

    7 dk

  • Yapay Zekâ Asistanından Yapay Zekâ Çalışma Arkadaşına: Araç Kullananın Değil, Yetki Devredenin Sorusu

    Bir paradoksla başlayalım. Ankara’da 312 çalışanı olan bir medikal cihaz distribütörü geçen yıl ekibine beş farklı AI aracı ekledi: müşteri e-postalarını özetleyen bir asistan, fiyat tekliflerini taslak haline getiren bir araç, toplantı notlarını düzenleyen bir başkası. Altı ay sonra çalışanların büyük çoğunluğu ‘daha çok ekranda zaman geçirdiklerini’ söylüyordu. Araçlar çoğalmıştı, ama iş yükü azalmamıştı. Tam tersi: her aracın çıktısını kontrol etmek, onaylamak ve düzeltmek yeni bir iş kalemi olmuştu. Bu sonuç bir uygulama hatası değildir. Asistan modelinde yapısal bir sınırın kaçınılmaz sonucudur. AI asistanından AI çalışma arkadaşına geçiş; araç değiştirmek değil, karar yetkisini yeniden haritalamanın ta kendisidir. Ve çoğu organizasyon bu haritayı çizmeden geçişi denemiştir.Sektörde iki zıt görüş giderek keskinleşiyor. İlk görüşe göre agentic AI sistemleri çalışanların iş yükünü gerçek anlamda azaltıyor: görev akışlarını devralan, bağlamı oturumlar arasında taşıyan ve insan onayı beklemeden belirli eşiklerin altındaki kararları uygulayan sistemler artık pilot aşamasını geçti. İkinci görüşe göre ise bu sistemler sorumluluğu değil, sadece görünür çabayi azaltıyor — hataların sahibi hâlâ insandır ve hesap verebilirlik belirsizleşince risk artar. Her ikisi de kısmen doğrudur. Agentic AI sistemleri, iyi tanımlanmış kural sınırları içinde gerçekten otonom işlem yapabiliyor. Ama ‘iyi tanımlanmış’ kısmını kurumun kendisi tanımlamak zorundadır; yazılım sağlayıcısı tanımlayamaz. Asıl gerilim burada başlıyor.AI asistanı ile AI çalışma arkadaşını birbirinden ayıran tek kriter, sistemin bağlamı taşıyıp taşımadığı ve görev devri yapıp yapamadığıdır. Asistan her oturumda sıfırdan başlar; insan her seferinde bağlamı yeniden kurar. Çalışma arkadaşı ise önceki kararları, şirketin tercih profilini, müşterinin geçmişini ve devam eden görev ağını bellekte tutar; yeni bir talebi bu birikimin üzerine oturtur. RAG mimarisiyle şirket bilgi tabanına bağlanan ve görev zincirlerini (task chain) yönetebilen ajan sistemleri tam olarak bu farkı yaratıyor. Ancak Türkiye medikal cihaz dağıtım sektörüne bakıldığında, bu farkı gerçek operasyonda kuran firma sayısı son derece sınırlı. Sınırlı kalmasının nedeni teknik değil: hangi kararın devredilebileceğini kurumun içsel olarak belirlememesi.Türkiye KOBİ bağlamında bu geçişin ayrı bir boyutu daha var. SaaS AI hizmetleri artık erişilebilir fiyat noktalarında. Ama erişilebilirlik, kullanılabilirlik demek değildir. Ankara’daki medikal cihaz örneğine dönersek: distribütörün en büyük operasyonel sorunu, müşteri sipariş sürecindeki onay halkalarının şirket içi prosedür belgelerine değil, patronun sözlü tercihine dayalı olmasıydı. Yapay zekâ çalışma arkadaşına devredilmesi düşünülen karar sınıfları, önce bu örtük bilginin açık kurala dönüştürülmesini gerektiriyordu. Bu dönüşüm gerçekleşmeden ajan sistemi kurulursa ortaya şu çıkıyor: sistem, daha önce patronun onayladığı ama hiçbir yerde yazılmamış koşulları zaman zaman ihlal ediyor. İlk haftada onaylanan sipariş, üçüncü haftada ‘neden ajan bunu benden sormadı’ sorusuna dönüşüyor. Sorun ajan değil, devredilen kararın sınırının hiç çizilmemiş olmasıdır.Hangi koşulda AI asistanı yeterlidir, hangi koşulda çalışma arkadaşı modeli gereklidir? Pratik ayrım şudur: karar sıklığı yüksek, bağlam tekrarlayan ve hata maliyeti geri döndürülebilir nitelikteyse ajan sistemi anlamlı değer üretir. Aynı distribütörün teknik destek sürecini düşünün: servis ekibinin günde ortalama 55 tekrar eden müşteri sorusunu yanıtladığını varsayın. Bu soruların cevabı şirketin bilgi tabanında yazılıdır, onay gerektirmez ve yanlış cevabın etkisi anında düzeltilebilir. Burası ajan sisteminin ölçülebilir katkı yaptığı alandır. Ölçüm yöntemi de nettir: ajan devreye girmeden önceki yanıt süresi ve müşteri memnuniyeti skoru ile sonrasını karşılaştırırsınız. Aynı firmada hukuki içerik gerektiren tedarikçi sözleşmesi değerlendirmesi veya fiyatlama istisnası kararı ajan sistemine devredilmez — çünkü bu kararların hatası geri döndürülemez ve hesap verebilirlik belirsizleşirse sorumlu bulunamaz. EU AI Act’ın yüksek riskli karar sınıflaması tam olarak bu mantıkla çalışıyor: otomasyonun değil, hatanın etkisini esas alıyor.Çalışma arkadaşı modeline geçişin yetkinlik gereksinimleri, araç kullanımından niteliksel olarak farklıdır. Araç kullanmak için prompt yazmayı öğrenmek yeterlidir. Ajan sistemiyle çalışmak için üç şeyi bilmek gerekir: sistemin hangi kararları hangi sınır koşullarında alabileceğini tanımlamak, sistemin ürettiği çıktıyı salt içerik olarak değil karar geçmişi olarak okumak ve sistemin hatalı karar verdiği senaryoyu tespit edip sınırı yeniden çizmek. Bu üç yetkinlik bir arada ‘AI gözetim yetkinliği’ olarak adlandırılıyor. Ankara distribütörü bu süreçte somut bir adım attı: müşteri ilişkileri ekibinden bir çalışan, ajan sisteminin karar günlüklerini (decision log) haftalık olarak incelemek ve anomali raporlamak üzere görevlendirildi. Bu rol sekiz haftada ekibin geri kalanına yayıldı. Ölçüm şöyle yapıldı: haftada kaç kez ajan kararı insan tarafından düzeltildi, bu düzeltmelerin kaçı sistemin kural sınırında belirsizlikten mi yoksa müşteri bağlamı eksikliğinden mi kaynaklandı. İki ayrı hata kategorisi, iki ayrı çözüm gerektiriyor.AI asistanından AI çalışma arkadaşına geçişi bir araç yükseltmesi olarak gören organizasyonlar, geçişin ilk altı ayında genellikle hayal kırıklığıyla karşılaşıyor. Ankara distribütörünün başlangıçta yaşadığı yorgunluk tam olarak buydu: araç çoğalmıştı ama karar haritası çizilmemişti. Geçişin çalışması için önce şu soruyu yanıtlamak gerekiyor: ‘Bu karar sınıfında hata olursa hesap kim verir ve bu hesabı verebilecek bir insan hâlâ süreçte mi?’ Cevap nettir: evet ise ajan devir alabilir; hayır ise ajan sadece asistan olarak konumlanmalıdır. Bu çizgiyi çizmek ne teknik bir iş ne de IT’nin sorumluluğudur — bu çizgiyi iş birimi yöneticisinin çizmesi gerekir. Bunu yapamayan organizasyonlar, sistemleri ne kadar gelişmiş olursa olsun, AI asistanı aşamasında kalmaya devam edecektir.

    6 dk

  • LLM, SLM ve RAG: Şirketler Hangi Yapay Zekâ Mimarisini Seçmeli?

    Şirketlerin büyük dil modellerine (LLM) bağlanan bir RAG katmanı kurarak sorunlarını çözdüğünü varsayması, 2025 yılının en yaygın ve en pahalı yanlış anlaşılmasıdır. Bu mimarinin satış konuşmaları son derece çekici: kurumsal verilerinizi modele bağlıyorsunuz, model bilgiye erişiyor, tutarlı yanıtlar üretiyor. Demo ortamında bu genellikle işe yarıyor. Üretim ortamında ise tablonun yarısı eksik çıkıyor. Sorun teknolojinin kendisinde değil; seçim sürecinin modelden değil kullanım senaryosundan ve veri olgunluğundan başlamamasında. Bu makale tek bir tez üzerine kurulu: LLM, SLM ve RAG kombinasyonlarını değerlendirirken doğru soru ‘hangi model daha güçlü?’ değil, ‘hangi veri hazırlığımız var ve bu işi kim denetleyecek?’ sorusudur.Tanımları operasyonel düzeyde netleştirmek gerekiyor; çünkü pazarlama materyalleri bu kavramları birbirine karıştırıyor. LLM (Large Language Model), milyarlarca parametreyle eğitilmiş, geniş bir genel bilgi tabanı taşıyan modeldir — GPT-4 serisi, Gemini ailesi veya Llama-3 tabanlı modeller bu kategoriye girer. Güçlü yanı geniş konu yelpazesinde makul çıktı üretmesidir; zayıf yanı ise şirketin kendi verisini bilmemesi, halüsinasyona açık olması ve API üzerinden çalışması durumunda veri sızıntısı riskidir. SLM (Small Language Model) ise parametre sayısı 1-7 milyar aralığında kalan, genellikle belirli bir görev veya alan için ince ayar yapılmış (fine-tuned) modeldir. Phi-3, Mistral 7B ve benzer modeller bu kategoride değerlendirilebilir; ancak hangi modelin hangi sınıra girdiği hâlâ tartışmalıdır. Önemli olan özelliği: düşük hesaplama maliyetiyle çalışabilmesi ve şirket sunucusuna kurulabilmesidir. RAG (Retrieval-Augmented Generation) ise bir model seçimi değil, bir bilgi erişim desenidir. Model yanıt üretmeden önce bir belge deposuna veya vektör veritabanına sorgu atarak bağlam parçaları çeker; bu parçalarla yanıt oluşturur. LLM veya SLM ile birlikte çalışabilir — bu seçimi değiştirmez.Ankara’daki orta ölçekli bir sigorta aracı kurumunu ele alalım; 378 çalışanı var, yaklaşık 12 ofisi Anadolu genelinde. Bu kurum müşteri hizmetleri sürecini otomatize etmek istiyor: poliçe sorgulama, hasar başvurusu takibi ve iç eğitim materyallerine hızlı erişim. İlk bakışta klasik bir LLM+RAG projesi gibi görünüyor. Ama şu soruyu sormak gerekiyor: belge deposunun yapısı ne durumda? Eğer poliçe dokümanları PDF olarak paylaşılan klasörlerde dağınık hâldeyse, hasar raporları Excel’e elle girilen verilerden oluşuyorsa ve tarihsel iletişim arşivi e-posta kutularında yaşıyorsa, RAG katmanı bu kaosa bağlanıp ‘zeki’ yanıtlar üretemez. Ürettiği yanıtlar eksik ve tutarsız olur — ve müşteri bu tutarsızlığı poliçe bilgisi olarak yorumlar. Bu kurumun önce veri envanteri çıkarması, yapılandırılmamış kaynakları temizlemesi ve erişim kontrollerini tanımlaması gerekiyor. Teknoloji seçimi bu adımdan sonra gelmelidir. Şu an LLM API’ye ödenen aylık maliyet, gerçek değer üretmeden tükenebilir.Hangi mimari hangi koşulda uygun? Pratik bir eşleştirme çerçevesi sunuyorum. Eğer şirket genel amaçlı içerik üretimi yapıyorsa — pazarlama metni, toplantı özeti, kod asistanı gibi — ve veri hassasiyeti düşükse, LLM API’ye doğrudan erişim yeterli ve maliyet açısından mantıklıdır. Eğer şirkete özgü bilgi tabanına dayalı sorgulama yapılıyorsa — iç prosedürler, ürün katalogları, teknik kılavuzlar — o zaman RAG deseni anlam kazanır; ancak belge deposunun temiz ve yapılandırılmış olması şarttır. Eğer veri hassasiyeti yüksekse — hasta kaydı, müşteri sözleşmesi, finansal tahmin — ve KVKK ile EU AI Act uyum yükümlülükleri varsa, o zaman SLM seçeneği masaya gelir. Şirket sunucusunda çalışan, ağ dışına veri çıkarmayan, belirli bir görev için ince ayarlı bir model hem uyum hem maliyet açısından daha savunulabilir bir pozisyon oluşturur. Bu üç seçenek birbirinin rakibi değil, farklı kullanım senaryolarının doğal karşılığıdır.Veri egemenliği meselesi Türkiye için ayrı bir boyut taşıyor. 2025 itibarıyla AB pazarında iş yapan Türk şirketleri EU AI Act uyumunu ciddiye almak zorunda — özellikle ‘yüksek riskli’ kategoriye giren uygulamalar için. Bir İzmir gıda ihracatçısı AB alıcılarına sunduğu tedarik zinciri takip sistemine LLM entegre edecekse, bu modelin hangi veriyi nerede işlediğini belgelemek artık tercihe değil zorunluluğa bağlıdır. KVKK’nın 12. maddesi kişisel verinin üçüncü taraf sistemlere aktarımında veri işleme sözleşmesi şart koşuyor; yabancı LLM API’leri bu sözleşmeyi karşılayan koşullarda çalışmıyor olabilir. Burada SLM seçeneğinin cazibesi sadece maliyet değil, yönetişim: model şirket sınırları içinde çalışıyor, hangi sorgunun ne yanıt aldığı kayıt altına alınabiliyor, denetim izi (audit trail) oluşturulabiliyor. Gaziantep’teki bir ilaç hammadde tedarikçisi bu yaklaşımı benimsedi ve iç dokümantasyon asistanı olarak Mistral ailesinden 7B parametreli bir modeli kendi sunucusunda çalıştırmayı değerlendiriyor — veriyi dışarı çıkarmadan, aylık API maliyeti olmadan. Doğrulama süreci henüz tamamlanmadı, bu nedenle rakam vermiyorum; ama mimari gerekçe sağlam.Şimdi somut karar çerçevesi: pazartesi sabahı ne yapmalı? Birinci adım, kullanım senaryosunu ve beklenen çıktı kalitesini tanımlamak. ‘Yapay zeka kullanalım’ değil, ‘hangi süreçte, hangi kullanıcı için, ne tür bir çıktı bekleniyor?’ sorusunu net yazılı hale getirmek. İkinci adım, veri envanteri çıkarmak: ilgili belgeler nerede, ne formatta, kim erişiyor, güncelleme sıklığı ne? Eğer bu envanter yoksa RAG kurmanın anlamı yok. Üçüncü adım, hassasiyet sınıflandırması yapmak — verilerin hangisi genel bilgi, hangisi ticari sır, hangisi kişisel veri kapsamına giriyor? Bu sınıflandırma hem mimari seçimi hem uyum çerçevesini belirliyor. Dördüncü adım, bir pilot tasarlamak ve başarıyı ölçülür biçimde tanımlamak. Örneğin: ‘müşteri hizmetleri temsilcisi başına ortalama sorgu çözüm süresi 6 dakikadan 3,5 dakikaya indi mi?’ gibi. Beşinci adım ise pilotun sonucunu üretim kararından önce değerlendirmek — demo başarısı üretim başarısı değildir. Bu beş adımı atlamadan mimari seçim yapmak, satıcının demo ortamına teslim olmaktır.Sigorta kurumuna geri dönelim. Belge deposu temizlendi, poliçe dokümanları yapılandırıldı, erişim rolleri tanımlandı varsayalım. Şimdi RAG deseni anlamlı hâle geliyor. Ama hangi model? Müşteriye dönük sorgulama düşük gecikme gerektiriyor ve veri sızıntısı riski var; burada SLM+RAG kombinasyonu daha savunulabilir. İç eğitim asistanı için veri hassasiyeti düşük ve içerik çeşitliliği yüksek; burada LLM API mantıklı olabilir. Aynı şirket içinde iki farklı mimari, iki farklı use case için. Bu seçimi ‘hangi model daha akıllı?’ sorusuyla yapan ekipler hep yanılır. Yanıtı belirleyen soru şudur: bu sistemin çıktısında hata olursa kim hesap verecek ve nasıl düzeltilebilecek? Hesap verebilirlik hattı kurulmadan mimari seçim yapılmaz.

    7 dk

  • RAG Mimarisi Kurumsal Bilgiyi Nasıl Dönüştürür — ve Nerede Biter?

    Piyasada RAG mimarisi çoğu zaman tek bir vaatli cümleyle satılıyor: ‘modele kendi belgelerinizi öğretin, halüsinasyonlar biter.’ Bu cümle hem doğru hem yanıltıcı — ve bu gerilimi anlamadan RAG projesine bütçe ayıran her şirket, aynı hayal kırıklığıyla karşılaşıyor. Konya’da makine imalatı yapan, 295 çalışanlı bir üretici geçen yıl RAG tabanlı bir teknik destek asistanı kurdu. Altı ay sonra sistemin kullanım oranı beklenenin çok altındaydı. Teknik altyapı sağlamdı. Sorun başka bir yerdeydi.RAG’ın açılımı ‘Retrieval-Augmented Generation’ — erişim destekli üretim. Sistem iki parçadan oluşuyor: bir arama katmanı (retrieval) ve bir üretim katmanı (generation). Kullanıcı soru sorduğunda model, önce kurumun kendi belgelerini — teknik kılavuzlar, bakım prosedürleri, geçmiş proje notları, tedarikçi anlaşmazlık kayıtları — tarayarak ilgili pasajları bulur; ardından bu pasajları bağlam olarak kullanarak yanıt üretir. Bu yaklaşım iki somut sorunu çözüyor: modelin eğitim kesim tarihinden sonraki bilgiye erişmesi ve kuruma özgü gizli bilgiyi genel modelin içine gömmek yerine kontrollü biçimde sunması. İkincisi özellikle kritik — zira genel LLM’ye özel belge eğitimi hem maliyetli hem KVKK açısından riskli.Konya’daki makine üreticisine dönersek: şirketin teknik belge arşivi 11 yıllık PDF yığınından oluşuyordu. Taranmış el kitapları, birbirini çelen revizyon notları, farklı mühendisler tarafından farklı formatlarda oluşturulmuş bakım kılavuzları. RAG sistemi bu belgeleri vektör veritabanına dönüştürdü ve sorgulamaya açtı. Ne var ki retrieval katmanı alakasız pasajları sık sık üst sıraya taşıyordu çünkü belgeler arasında tutarsız terminoloji vardı: aynı parça üç farklı isimle anılıyordu. Sistem teknik olarak çalışıyordu — ama çıktıların %63’ü teknik servis ekibinin doğrulama yapmadan kullanamayacağı yanıtlar içeriyordu. Mühendisler sistemi terk etti. Arıza değil; veri kalitesi sorunu.Bu örnek RAG mimarisinin en sık yanlış anlaşılan boyutunu gösteriyor: değer, modelde değil, belge katmanının nasıl yapılandırıldığında yatıyor. Retrieval kalitesi doğrudan chunk stratejisine, belge temizliğine ve metadata zenginliğine bağlı. Pratik adımlar şunlar: ilk olarak belge envanteri yapın — hangi belgeler güncel, hangisi eskimiş, hangi terminoloji standardı benimseniyor? İkinci adım, chunk boyutunu içerik türüne göre ayarlayın; prosedürel metinler için daha küçük (256-512 token), bağlamsal belgeler için daha büyük parçalar genellikle daha iyi retrieval skoru veriyor. Üçüncü adım, her chunk’a sektöre özgü metadata etiketleyin: ‘makine tipi’, ‘revizyon tarihi’, ‘uygulanan standart’ gibi alanlar. Bu etiketler, hybrid search — hem anlamsal hem anahtar kelime bazlı — stratejisinde filtreleme gücü sağlar. Dördüncü adım, retrieval çıktısını ölçün: her sorgu için ilk üç pasajın ilgili olup olmadığını bir değerlendirme veri setiyle düzenli test edin. Bu adım atlanırsa sistem çürüyor ama kimse fark etmiyor.Tedarik zinciri bağlamında RAG’ın en somut değer ürettiği alan, tedarikçi yönetimi bilgisidir. Türkiye’deki üretim şirketlerinin büyük çoğunluğu tedarikçi iletişim geçmişini e-posta arşivlerinde, kalite raporlarını ayrı bir klasörde, sözleşme şartlarını farklı bir sistemde tutuyor. Bir satın alma uzmanı gecikmeli teslimat için tedarikçiye başvurduğunda, geçmişi aramak için üç farklı kaynağa bakması gerekiyor. RAG bu dağınıklığı çözebilir — ama yalnızca belgeler sisteme düzgün beslenmişse. Örnek bir yapıda: tedarikçi başına ayrı bir koleksiyon, her koleksiyonda sözleşme, kalite kayıtları ve iletişim özetleri ayrı chunk grupları olarak tanımlı. Bu yapı kurulduğunda ‘Bu tedarikçi geçen yıl kaç kez gecikti, gecikme nedenleri nelerdi?’ sorusu saniyeler içinde yanıt alıyor — ve yanıt, modelin yarattığı değil, şirketin kendi verisinden derlenen bir özet oluyor. Ölçüm basit: kullanıcıların yanıtı doğrulamak için başka bir kaynağa gidip gitmediğini takip edin. Gitmiyorlarsa retrieval işe yarıyor demektir.Şimdi dürüst bir çekince: RAG her kurumsal bilgi sorununu çözmez. Bunu açıkça söylemek gerekiyor, çünkü vendor sunumlarında bu sınır nadiren görünür. Yapılandırılmamış, birbiriyle çelişen ve güncellenmemiş belge tabanında RAG yalnızca pahalı bir arama motoruna dönüşür — üstelik yanıtı mantıklı bir cümleyle sunan, bu yüzden yanlışı daha inandırıcı hissettiren bir motor. EU AI Act’ın 2025’teki yürürlük süreciyle birlikte, yüksek riskli iş akışlarında AI çıktısının insan denetimiyle kontrol edilmesi zorunluluğu pratikte daha fazla önem kazandı. Üretim ortamında bir bakım talimatı yanlışsa makine durabilir; bir tedarikçi termin tarihi hatalıysa hat bekleyebilir. Bu nedenle RAG çıktılarını ham yanıt olarak değil, ‘araştırma taslağı’ olarak konumlandıran şirketler, kullanıcı güvenini daha sağlıklı kuruyorlar. Ayrıca veri egemenliği sorusu: Türkiye’deki şirketlerin büyük bölümü belge verisini offshore bulut ortamına göndermek istemiyor. Bu noktada on-premise veya Türkiye veri merkezi seçeneklerinin maliyet farkı ciddi — ve 2025 itibarıyla bu farkı karşılayabilecek yerel model seçenekleri büyüyor, ama henüz her ölçek için uygun değil.RAG’ın gerçek testi şu soruyu yanıtlamaktır: bu sistemin olmadığı haftayla olduğu haftayı karşılaştırabilir misiniz? Eğer farkı ölçemiyorsanız — kaç sorgu yanıtlandı, kaçı eskalasyon gerektirdi, ortalama yanıt doğruluğu ne oldu — sisteminiz üretimde değil, gösterimde yaşıyor demektir. Konya’daki makine üreticisi ikinci çeyrekte belge standardizasyonu projesine başladı; tek terminoloji sözlüğü oluşturdu, eski PDF’leri yeniden işledi ve her belgeye zorunlu metadata alanı tanımladı. Altı ay sonra aynı RAG altyapısıyla retrieval isabeti %72’ye çıktı ve teknik servis ekibi sistemi günlük iş akışına entegre etti. Mimari değişmemişti. Veri değişmişti.

    6 dk

  • Girişimcilik Ruhu Kurumsal İşte Nasıl Yaşatılır?

    Bir kurumsal şirket yöneticisi toplantıda ‘girişimcilik ruhuyla hareket edin’ dedikten iki hafta sonra aynı ekip üyesini müşteriyle bağımsız iletişim kurduğu için uyarıyorsa, ortada kültür sorunu değil yönetim çelişkisi var. Bu çelişki Türkiye’nin büyük ve orta ölçekli şirketlerinde çok tanıdık bir örüntü: söylem sahiplik istiyor, sistem itaat ödüllendiriyor. Ve bu ikilik, kurumsal ortamda girişimcilik ruhunu körelten tek bir mekanizmanın ürünüdür — karar yetkisi verilmeden sorumluluk beklenmesi. Benim tezim şu: girişimcilik ruhu kurumsal şirketlerde ancak hata maliyetini gerçekten üstlenen insana orantılı karar yetkisi tanındığında hayatta kalır. Aksi hâlde ‘inovasyon kültürü’ adı verilen şey, performans değerlendirme dönemine kadar hayatta kalan bir slogandır.İki tarafın da argümanı kısmen doğru. Kurumsal yöneticiler şunu söylüyor: öngörülemeyen hareket organizasyonu zorlaştırır, müşteri deneyimini tutarsız hale getirir, riski yönetmek güçleşir. Bu kaygılar gerçek. Öte yandan girişimci ruhlu çalışanlar şunu söylüyor: onay mekanizmaları her fırsatı 11 haftaya çekiyor, müşteri o sürede rakibe geçiyor, enerji projeye değil prosedüre akıyor. Bu da gerçek. Sorun şu: her iki taraf aynı olguyu tarif ediyor ama çözümü zıt yönlerde arıyor. Yönetim sistemi yetkiyi yukarıda tutmayı güvenlik mekanizması olarak görüyor; girişimci ruhlu kişi ise her prosedürü aşılması gereken engel olarak yaşıyor. Bu gerilim ancak hesap verebilirlik mimarisi kurulduğunda çözüme yaklaşıyor — ne tam özgürlük, ne tam kontrol. İkisi arasındaki köprüyü kim inşa edecek sorusu ise hâlâ çoğu şirkette yanıtsız duruyor.Ankara’da yazılım ve BT hizmetleri veren, 261 çalışanlı orta ölçekli bir şirkette 2024 sonunda yapılan bir iç değerlendirme bu gerilimi somutlaştırıyor. Ürün geliştirme ekibindeki yedi kişilik bir takım, bir müşterinin süreç darboğazına kendi inisiyatifiyle çözüm geliştirdi ve bunu sunmak için onay beklemeye başladı. Onay döngüsü 11 hafta sürdü. Müşteri o sürede başka bir sağlayıcıyla pilot başlattı. Yönetim ‘neden önceden haber vermediniz’ dedi; ekip ‘verdik ama yanıt alamadık’ dedi. Her iki taraf haklıydı, çünkü sistem fırsatı değerlendirmek için değil, riski kontrol etmek için tasarlanmıştı. Bu anonim kurumsal vaka, girişimcilik ruhunun neden kurumsal ortamda susup gittiğini tek bir örnekte özetliyor. Ekip dağılmadı, moral bozulmadı, kimse istifa etmedi — sadece bir daha o müşteri için kendi inisiyatifiyle bir adım atmadı.Ama şunu açıkça söylemek gerekiyor: girişimcilik ruhu her iş fonksiyonunda ve her kültürel zeminde aynı biçimde işlemez. Muhasebe, hukuk veya regülasyon uyumu gibi alanlarda geniş hareket alanı değil, aksine net protokol gerektiren bir iş disiplini var. ‘Girişimci gibi davran’ talimatını bu alanlara ayrım gözetmeksizin uygulamak sadece kargaşa üretir. Finans sektöründe faaliyet gösteren bir şirkette BDDK veya SPK bildirimi gerektiren bir süreçte ‘inisiyatif al’ demek hem düzenleyici riskle hem de ciddi itibar riskiyle sonuçlanır. Dolayısıyla soru ‘kurumsal ortamda girişimcilik ruhu yaşayabilir mi’ değil; ‘hangi alanda, hangi ölçekte, hangi hesap verebilirlik yapısıyla’ sorusu olmalı. Bu ayrımı yapmayan şirketler ya girişimci ruhu tamamen boğuyor ya da yapısal risk yaratıyor — ikisi de yönetim başarısızlığı.Pratik çerçeve üç unsur üzerine kurulabilir. Birinci adım: yetki eşiğini kalem kalem tanımlayın. Hangi karara kim, hangi bilgiye dayanarak, hangi süre içinde sahip olabilir? Bunu belirsiz bırakmak, çalışanın ya her şeyi onaya taşımasına ya da tamamen bağımsız hareket etmesine neden olur; her ikisi de istenmeyen davranış. İkinci adım: deney bütçesini ölçülebilir hale getirin. Yılda bir kez inovasyon toplantısı yapmak kültür üretmez. Haftada kaç saat, çeyrekte kaç pilot, başarısız denemede ne kadar kayıp tolere edilebilir — bunları sayısallaştırmadan girişimcilik ruhu performans dönemine kadar hayatta kalamaz. Üçüncü adım: başarısızlığı yapılandırın. Türkiye’deki kurumsal yapıların büyük bölümünde başarısız bir deney, performans değerlendirmesinde hâlâ negatif etiket taşıyor. Ankara’daki o yazılım şirketinde 11 haftalık onay döngüsü bir yönetim kararıyla 5 iş gününe indirildi; buna karşın sözleşme değeri 500 bin TL’nin üzerindeki kararlar yönetim kurulu onayına tabi tutulmaya devam etti. Fark küçük görünüyor ama ölçülebilir: aynı ekip 6 ay içinde üç yeni müşteri pilotunu tamamladı. Girişimcilik ruhu bu mimarinin içinde yaşadı, sloganın içinde değil.2025 itibarıyla bu tartışmaya yeni bir boyut eklendi. Yapay zekâ araçlarının rutin karar destek işlevlerini üstlenmesiyle birlikte insan çalışanın asıl değeri yargıya dayalı kararlar, bağlamsal muhakeme ve belirsizlik toleransında yoğunlaşıyor. Bu tam olarak girişimci zihniyetin beslendiği alan. Ancak burada bir gerçek risk var: şirketler AI ajanlarına belirli iş akışlarında karar yetkisi verirken insana hesap sorma pratiğini de tutarlı biçimde dönüştürmek zorunda. Yetki mimarisi AI sistemleri için de, insan ekipler için de ayrı ama tutarlı çizilmeli. Aksi hâlde ‘ajanın önerisi buydu’ ile ‘yönetici onayı lazımdı’ arasında yeni bir sorumluluk boşluğu doğuyor. EU AI Act’ın 2025’te aşamalı yürürlüğe girmesiyle bu sorumluluk boşluğu artık yasal riske de dönüşüyor — özellikle AB pazarına ihracat yapan veya AB menşeli müşterilerle çalışan Türk şirketleri için.Girişimcilik ruhu kurumsal ortamda yaşatmak, motivasyon konuşmalarından değil onay süreçlerini yeniden çizmekten başlar. Ankara’daki o yazılım şirketi 11 haftalık onay döngüsüyle girişimci ruhu söylemde tutuyordu, uygulamada öldürüyordu. Küçük bir yapısal değişiklik üç pilot dönüştürdü. Sizin şirketinizde bir çalışan bugün bir fırsat gördüğünde ne kadar sürede aksiyon alabiliyor? Ve o süreyi belirleyen kural mı, yoksa kimsenin sorgulamadığı alışkanlık mı?

    6 dk

  • AI Ajanlarında Yetki Var, Sınır Yoksa: Neden Başarısız Oluyorlar?

    Bir finansal hizmetler şirketinin satın alma ajana yetki verirken düşündüğü şey şudur: ‘Artık bu işi ajan halleder.’ Düşünmediği şey ise şudur: ‘Ajan hangi noktada durmalı, hangi karar insana dönerek sorulmalı, hata yaptığında sistem nasıl davranmalı?’ İstanbul merkezli orta ölçekli bir sigorta aracılık şirketi, 2024 yılı sonunda 312 çalışanıyla otomasyona yatırım yaparken tam bu boşluğa düştü. Poliçe yenileme süreçlerini bir ajan üzerinden otomatize etmek istediler. Ajana müşteri verilerine erişim, e-posta gönderme ve poliçe parametrelerini güncelleme yetkisi verildi. Sonuç: ajan, yenilenmemesi gereken 47 poliçeyi süre dolmadan önce yeniledi ve bazılarına yanlış prim hesabı uyguladı. Sistem hata vermedi. Ajan görevi tamamladı. Sorun, yetkinin sınırsız tanımlanmış olmasıydı.Bu makaledeki tez tartışmalı ama ölçülebilir: Yapay zeka ajanlarının başarısızlığı büyük oranda teknik bir sorun değildir. Yönetim boşluğunun sonucudur. Kurumlar ajana ne yapabileceğini söylüyor; ne yapamayacağını, ne zaman durması gerektiğini ve başarısız olduğunda nasıl davranacağını tanımlamıyor. Bu ikisi arasındaki farkı görmezden gelen her ajan dağıtımı, kısa sürede operasyonel bir risk kaynağına dönüşüyor. Ajana güvenmek, ajana sınır çizmek demek değildir. Ve bu ayrım 2025’te Türkiye’deki kurumların çoğunun henüz tam anlamıyla kavramadığı noktadır.Yetki matrisi (authority matrix) kavramı yeni değil. İnsan organizasyonlarında onlarca yıldır kullanılıyor: kim ne kadar tutarda harcama onaylayabilir, hangi kararlar üst yönetim imzası gerektirir, hangi işlem limit aşımında dondurulur. AI ajanları söz konusu olduğunda bu çerçeve çoğu kurumda ya yoktur ya da sistem konfigürasyonuna değil sadece prompt metnine gömülüdür. Prompt tabanlı sınır koyma ise ajanlı sistemlerde güvenilir bir yönetim mekanizması sayılmaz; çünkü model bağlamı kaybolduğunda, zincir uzadığında ya da beklenmedik bir girdi geldiğinde bu sınırlar çöker. Bir sigorta aracısının BT müdürü bunu şöyle tanımladı: ‘Ajanın ne yapmaması gerektiğini yazdık. Ama yazılanı sistemin nereye baktığını kontrol etmedik.’ Yetki matrisi bir belge değildir. Sistemin çalışma zamanında okuduğu, uyguladığı ve kayıt altına aldığı bir konfigürasyondur.Eskalasyon kuralları bu tablonun ikinci eksik parçasıdır. İyi tasarlanmış bir ajan mimarisi her görevi kendi içinde tamamlamaz; belirli koşullarda insan kararına döner. Ankara’daki bir factoring şirketinin müşteri itiraz yönetim ajanını düşünün: ajan, itirazı sınıflandırıyor, standart yanıt kümesinden eşleştirme yapıyor ve müşteriye otomatik yanıt gönderiyor. Eskalasyon kuralı tanımlı değilse ajan yüksek riskli bir müşteri itirazını da — örneğin hukuki süreç başlatma tehdidi içeren bir mesajı — standart yanıtla kapatır. Burada teknik bir hata yoktur. Sistemin görev tanımı yerine getirilmiştir. Ancak iş sonucu felaket boyutunda olabilir. Eskalasyon kuralı; sınıflandırma güven skoru eşiği, içerik duygu analizi uyarısı veya belirli anahtar kelime tetikleyicileri üzerinden kurulabilir. Kritik nokta şudur: bu eşiklerin tasarlanması, ölçülmesi ve zaman içinde güncellenmesi gerekiyor. Ajan bir kez kurulup bırakılacak bir sistem değildir.Güvenli başarısızlık tasarımı (fail-safe design) ise en az konuşulan ama en kritik katmandır. Bir ajanın başarısız olması kaçınılmazdır. Dil modelinin bağlam penceresinin dolması, dış API’nin zaman aşımına uğraması, veri akışında beklenmez bir format gelmesi — bunların hepsi ajanın görevi yarıda bırakabileceği anlamına gelir. Sorulması gereken soru ‘ajan neden başarısız oldu’ değildir. Soru şudur: ‘Başarısız olduğunda sistem ne yaptı?’ İzmir’deki bir muhasebe yazılımı sağlayıcısı, müşterilerine sunduğu ajan destekli uzlaştırma aracında bu soruyu gecikmeli sormak durumunda kaldı. Ajan banka ekstresi çekimine ulaşamadığında görevi ‘tamamlandı’ olarak işaretliyordu — çünkü hata durumu için farklı bir çıkış kodu tanımlanmamıştı. Muhasebeciler haftalar boyunca eksik uzlaştırmalar üzerinde çalıştıklarını fark edemedi. Güvenli başarısızlık tasarımı, hata kodlarını ayrıştırmayı, başarısız işlemleri ayrı bir kuyruğa almayı ve bu kuyruğun düzenli insan incelemesinden geçmesini gerektiriyor. Bunu ‘yapay zekanın sınırı’ olarak değil, operasyonel süreç olgunluğunun parçası olarak ele almak gerekiyor.EU AI Act’ın 2025 yılında yürürlüğe girmesiyle birlikte bu mesele salt operasyonel bir tercih olmaktan çıktı. Yüksek riskli olarak sınıflandırılan uygulamalarda — sigorta puanlama, kredi kararları, işe alım araçları — insan denetimi zorunlu hale geldi. Türkiye’deki kurumlar AB pazarına açık olduğu sürece bu uyum yükünü taşımak zorunda. Ancak daha önemli bir nokta var: EU AI Act uyumunu bir kontrol listesi olarak değil, yetki matrisi ve eskalasyon tasarımı için bir çerçeve olarak kullanan kurumlar iki işi birden yapıyor. Uyum sağlarken operasyonel olgunluk da kazanıyorlar. Sigorta aracılık şirketinin örneğine geri dönersek: o şirket düzeltme sürecine girdiğinde yetki matrisini üç kategoriye ayırdı — ajana tam yetki, ajana öneri/insan onayı ve ajana yasak. Bu üçüncü kategori çoğu kurumun atladığı kısımdır. Hangi kararlar hiçbir koşulda ajana bırakılamaz? Bu soruyu poliçe yenileme vakasından önce sormak 47 hatalı yenilemenin önüne geçerdi.Pazartesi sabahı ne yapılabilir? Önce mevcut ajan dağıtımlarınızı listeleyin ve her biri için şu üç soruyu yanıtlayın: ajanın yetkisi yazılı bir konfigürasyonda mı tanımlı, yoksa yalnızca prompt metninde mi? Hangi koşulda insan kararına dönüyor ve bu koşul ölçülebilir bir eşiğe dayalı mı? Başarısız olduğunda sistem ne yapıyor ve bu durum kayıt altında mı? Eğer bu üç sorudan birine net yanıt veremiyorsanız, o ajan sistemi yönetiliyor değil, sadece çalışıyor demektir. İstanbul’daki sigorta aracılık şirketi bu sorulardan hareketle yetki matrisini yeniden kurdu, eskalasyon eşiklerini tanımladı ve hata kuyruğu için haftalık bir insan inceleme döngüsü oluşturdu. Süreç iyileştirmesi için 11 hafta harcadılar. Bir sonraki hatalı poliçe serisinden kaçınmak için bu 11 hafta ucuz bir bedeldir.

    6 dk

  • Dayanıklılık Bireysel Değil Sistemsel Bir Tasarım Sorunudur

    Antalya’nın batı yakasında faaliyet gösteren, 284 çalışanı ve üç ayrı konsepti olan bir otel zincirinin genel müdürü geçen Kasım ayında şöyle bir şey söyledi: ‘Ekibimize dayanıklılık eğitimi verdirdik, mindfulness atölyeleri yaptırdık, koç tuttuk. Sonra Ocak’ta kriz geldi — rezervasyonların %57’si iptal oldu, iki kilit yöneticimiz ayrıldı, tedarikçimiz fiyatı revize etti. Eğitimden geçmiş ekip paniklemedi. Ama sistemi idare edemedi.’ Bu cümle, dayanıklılık konusundaki en yaygın yanılgıyı tek bir sahneye sıkıştırıyor.Dayanıklılık programları iş dünyasında son birkaç yılda neredeyse zorunlu bir yönetim aracına dönüştü. Refahı iyileştirdiği, tükenmişliği azalttığı, çalışan bağlılığını artırdığı söyleniyor. Bunların bir kısmı doğru. Ama asıl sorun şu: Bu programlar bireyi güçlendirme görüntüsü altında, organizasyonun kırılganlığını çalışanın sırtına yüklemek için kullanılıyor. ‘Sen daha güçlü ol’ söylemi, ‘biz seni daha iyi koşullarda tutamıyoruz’ söyleminin yerini alıyor. Ve bu iki şey birbirinden çok farklı.Tezim şu: Gerçek dayanıklılık bireysel bir karakter özelliği değil, sistemsel bir tasarım sorunudur. Bir organizasyon süreçlerini, karar akışlarını ve bilgi paylaşım mimarisini kırılganlıklara göre tasarlamışsa, en güçlü karakterli çalışan bile kısa sürede törpülenir. Tersine, sistem sağlıklı tasarlanmışsa ortalama dayanıklılıktaki bir ekip olağanüstü koşullarda bile yolunu buluyor. Bu ayrımı görmeden yapılan her yatırım, semptomla savaşıp hastalığı beslemektir. Sınırlılığını da hemen belirteyim: Sistemsel tasarım her şeyin çözümü değil. İnsan faktörü, liderlik kalitesi ve bireysel yetkinlik gerçek fark yaratıyor — ama ancak sağlıklı bir sistem zemininde.Sistemi dayanıklı kılan üç unsur somutlaştırılabilir ve ölçülebilir: bilgi akışının şeffaflığı, karar yetkisinin dağılımı ve geri bildirim hızı. Antalya örneğine dönersek: Otel zincirinin rezervasyon iptali krizinde ekip neden tökezledi? Çünkü iki kilit yöneticinin ayrılmasıyla birlikte kritik bilgi o iki kişinin kafasında kaldı. Süreç dokümantasyonu yoktu, yetki devri tanımlanmamıştı, müşteri ilişkileri tamamen kişisel bağa dayanıyordu. Mindfulness eğitimi bunu telafi edemez. Peki bunu nasıl ölçersiniz? Basit bir test: Bir kilit pozisyon bugün boşalsa, o kişinin işinin %73’ü 72 saat içinde başka biri tarafından yürütülebilir mi? Çoğu Türkiye KOBİ’sinde cevap hayır. Bu, bireysel dayanıklılık eksikliği değil; sistem tasarımı eksikliğidir.Esneklik meselesine gelince — bu kavram dayanıklılıkla karıştırılıyor ama ikisi farklı şeyler. Dayanıklılık, baskıya rağmen işlev görme kapasitesidir. Esneklik ise değişen koşullara tepki biçimini yeniden şekillendirebilme kapasitesidir. Bir Gaziantep mobilya ihracatçısını düşünün: 312 aktif müşterisi olan, Avrupa’ya ihracat yapan, döviz kuruna bağımlı bir yapı. Pandemi sonrası dönemde ham madde fiyatları dönem dönem sert oynadı, navlun maliyetleri öngörülemez hale geldi. Bu firmanın sahası dayanıklılık değil esneklik gerektiriyordu: tedarikçi yapısını çeşitlendirmek, fiyatlama modelini dolar değil sepet bazına çevirmek, müşteri portföyünü coğrafi olarak dağıtmak. Bunları yapan firmalar hayatta kaldı. Yapmayan firmalar ise çalışanlarına ‘zor günlerde güçlü olun’ mesajı verip hazırlıksız bekledi. Esnekliği ölçmenin en kaba ama etkili yolu şu: Son iki yılda stratejik bir kararı kaç haftada revize edebildiniz? Cevap altı ayın üzerindeyse, organizasyon esneklik değil katılık üzerine kurulu.2025 yılının özgün bağlamı bu tartışmayı daha da somutlaştırıyor. Türkiye’de AI tabanlı iş zekası araçlarının KOBİ’lere erişimi hızlandı; basit RAG mimarileri üzerine kurulu raporlama çözümleri artık orta ölçekli şirketlerin bütçesinde. Bu araçlar dayanıklılık tartışmasına nerede giriyor? Şöyle: Bir sistemde bilgi akışı şeffafsa ve kararlar veriye dayalıysa, AI destekli raporlama o şeffaflığı hızlandırır ve kriz sinyallerini erken gösterir. Ama bilgi birkaç kişinin kafasında kilitliyse, RAG tabanlı araç da o kilitli bilgiye ulaşamaz — boş bir sistem üzerine zeki bir eklenti koymak sonucu değiştirmiyor. EU AI Act’ın 2025 itibarıyla yürürlükte olması ve AB pazarına açık Türk şirketlerin uyum yükümlülüğüyle karşılaşması, aslında dayanıklılık tartışmasının yeni bir boyutunu açıyor: AI sistemlerinde hesap verebilirlik, veri egemenliği ve risk sınıflandırması artık yönetim karar süreçlerinin içine girmek zorunda. Bunu ‘ileride çözeriz’ kategorisine koyan şirketler, sistem kırılganlıklarını farkında olmadan derinleştiriyor.Peki Pazartesi sabahı ne yapılmalı? Üç somut adım var. Birincisi: Organizasyondaki bilgi bağımlılık haritasını çıkarın. Hangi süreç, hangi kişiye bağlı? Bu kişi yarın gitse ne olur? Bu soruyu sormak zor çünkü cevap rahatsız edici çıkıyor — ama görmeden çözemezsiniz. İkincisi: Son altı ayda aldığınız kararların kaçında gerçek zamanlı veri kullandınız, kaçında geçmiş deneyime dayandınız? Bu oran size hem sistem olgunluğunu hem esneklik kapasitesini gösterir. Üçüncüsü: Bir sonraki dayanıklılık ya da mindfulness eğitimini satın almadan önce şunu sorun: Bu program çalışanı mı güçlendirecek, yoksa sistemin çözmemiş olduğu bir sorunu bireye mi yükleyecek? Eğer ikincisiyse, bütçeyi süreç tasarımına aktarın. Antalya’daki genel müdür bu soruyu sormadı. Ama şimdi soruyor — ve bu, uzun yolda ayakta kalmanın ilk adımı.

    6 dk

  • 2024 Teknoloji Gündeminin Ortak Mesajı: Araç Değil, Çerçeve

    2024 teknoloji gündeminin dört büyük başlığını yan yana koyduğunuzda şunu fark ediyorsunuz: AI Governance, SLM, Zero Trust ve Hyperautomation birbirinden kopuk trendler değil. Hepsinin altında aynı gerilim var. Şirketler araç edinmeyi öğrendi; ama o aracı çevreleyen yönetim katmanını kurmayı hâlâ öğrenemiyor. Araç olmadan değer üretilmiyor, doğru — ama çerçeve olmadan araç, yalnızca maliyet kalemi olarak kalıyor. Bu makaledeki tez şu: 2024’te teknoloji yatırımının gerçek değeri, satın alınan sistemin kendisinden değil, o sistemin etrafına örülen hesap verebilirlik, segmentasyon ve süreç olgunluğu katmanından geliyor. Bu katmanı kurmadan AI da, SLM da, Zero Trust da bütçe yakıyor.AI Governance meselesini somutlaştırmak için Ankara’da sigorta aracılık sektöründe faaliyet gösteren, 312 çalışanlı bir şirketi ele alalım. Şirketin operasyon ekibi, Nisan 2024’te AB’nin AI Yasası’nın (EU AI Act) Resmi Gazete’de yayımlandığını haberlerde izledi. İlk tepki: ‘Bizi ilgilendirmez, Türkiye’deyiz.’ Ama şirketin acentelerinin yaklaşık üçte biri Alman ve Hollandalı ortaklarla çalışıyor; yani AB pazarına dokunan her iş akışı bu yasanın kapsamına giriyor. Sigorta teklif üretiminde kullanılan kural motoru, yasa taslağının risk sınıflandırması çerçevesinde ‘yüksek riskli AI sistemi’ tanımına düşüyor. Hesap verebilirlik hattı tanımlı değilse — hangi karar otomatik alınıyor, hangi karar insan onayına gidiyor, hata durumunda kim sorumlu — o sistem Avrupa ortağına gösterilemez. Yönetişim bir uyum belgesi değil; iş sürekliliğinin ön koşulu haline geldi. Ölçütünüz şu olsun: AI sisteminizin aldığı her karar için bir hesap verebilirlik hattı çizebiliyor musunuz? Hayırsa, o sistemi üretime almak için henüz erken.SLM — küçük dil modelleri — tartışmasının Türkiye’deki karşılığı, Batı medyasından çok farklı bir noktada duruyor. Batı’da ‘GPT-4 yerine Llama-3 mı kullanayım’ sorusu gündemdeyken, Türkiye’deki orta ölçekli şirket yöneticisinin sorusu daha temel: ‘Müşteri verisini bulut API’sine göndermeden, kendi altyapımda çalıştırabilir miyim?’ Veri egemenliği kaygısı, SLM’yi Türkiye KOBİ gündemine taşıyan asıl kaldıraç. Denizli’deki bir tekstil ihracatçısının (295 çalışan) satın alma ekibi, tedarikçi yazışmalarını analiz etmek için yerel kurulumlu bir SLM denemesi başlattı. Şirket, müşteri e-postalarını ve sözleşme taslak metinlerini harici bir LLM API’sine göndermek istemiyordu — hem KVKK kaygısı hem de ticari sır hassasiyeti nedeniyle. 7 milyar parametreli yerel model, tedarikçi yazışmalarındaki teslimat taahhütlerini %79 doğrulukla işaretledi; bu rakam pilot için yeterliydi, üretime geçmek için değil. SLM’nin sınırı şu: bağlam penceresi kısa, çok adımlı akıl yürütme zayıf. Üretime geçmeden önce hata maliyetini hesaplayın — müşteri e-postasındaki teslimat tarihini yanlış okumak ne kadar pahalıya patlıyor?Zero Trust mimarisini ‘sıfır güven ağ güvenliği’ olarak anlatmak, konuyu teknik ekibe bırakmak gibi hissettiriyor. Oysa Zero Trust, 2024 itibarıyla bir ağ tasarım kararı olmaktan çıkıp bir operasyon modeli kararına dönüştü. Şöyle açıklayayım: Eskişehir’de makine imalatı yapan, 378 çalışanlı bir fabrika düşünün. Şirketin ERP sistemi bulutta, üretim hattındaki SCADA sistemi şirket içinde ve saha teknisyenlerinin büyük çoğunluğu kendi cihazlarıyla bağlanıyor. Klasik ‘şirket ağının içi güvenlidir’ varsayımı bu yapıda anlamsız. Zero Trust’ın pratik karşılığı şu: her erişim isteği, kaynağından bağımsız olarak doğrulanır; kullanıcıya yalnızca o anda ihtiyaç duyduğu kaynağa erişim verilir. Bu karar bir BT teknik tercihi değil; üretim hattı veri bütünlüğünü ve müşteri teslimat taahhütlerini doğrudan etkileyen operasyonel bir seçim. Ölçüm kriteri: yetki ihlali girişimlerinden kaç tanesi gerçek zamanlı olarak izole ediliyor? Bu sayıyı bilmiyorsanız, mimarinin çalışıp çalışmadığını da bilmiyorsunuzdur.Hyperautomation tartışması 2019’dan bu yana birikmekte olan bir hayal kırıklığını da taşıyor. Türkiye’nin büyük şirketleri RPA projelerine 2020-2022 arasında ciddi yatırım yaptı. Bazıları gerçek verimlilik kazanımı elde etti; pek çoğu ise bakım yükü yüksek, kırılgan bot envanteri biriktirdi. Hyperautomation’ın 2024’teki anlamı, salt bot sayısından farklı: süreç madenciliği (process mining) ile hangi süreçlerin gerçekten otomasyona hazır olduğunu tespit etmek, ardından RPA, düşük kod platformları ve AI karar motorlarını birleştirmek. Buradaki kritik ayrım şu: otomasyon olgunluğu yokken AI katmanı eklemek, işlev bozukluğunu daha hızlı üretir. Ankara’daki sigorta aracılık şirketine dönelim. Şirket, hasar ihbar akışını otomatikleştirmeye çalışırken süreç madenciliği analizinin ortaya koyduğu bulgu şuydu: sürecin 48 saatlik gecikmesinin %64’ü, tek bir manuel onay adımından kaynaklanıyordu. Bot kurmadan önce o onay adımını yeniden tasarlamak, tek başına süreyi 11 saate indirdi. Otomasyon bu noktadan sonra anlamlı hale geldi.Dört gündemin ortak mesajını tek cümleye sığdırmak gerekirse: 2024’te teknolojiyi işleten şirketleri, teknolojiyi satın alan şirketlerden ayıran şey, yönetim katmanının olgunluğudur. AI Governance hesap verebilirlik hattı talep ediyor. SLM, veri egemenliğini ön koşul olarak sunuyor. Zero Trust, ‘içerisi güvenlidir’ varsayımını ortadan kaldırıyor. Hyperautomation, süreç olgunluğunu otomasyon öncesi zorunlu adım olarak tanımlıyor. Hepsi aynı yönü işaret ediyor: önce yapıyı kur, sonra aracı çalıştır. Bunu tersine yapmak — önce araç, sonra yapı — Türkiye KOBİ’lerinin son beş yılda tekrar tekrar öğrendiği pahalı bir ders. Üstelik bu sıralamayı tersine çevirmek, teknik bir sorun değil; önce bir yönetim kararı meselesi.Peki, yönetici olarak pazartesi sabahı nereden başlayacaksınız? İlk adım envanter: elinizdeki dört alanda — AI sistemleri, model altyapısı, ağ erişim mimarisi, otomasyon portföyü — kaç tane ‘çerçevesiz araç’ var? İkinci adım, her sistem için hesap verebilirlik hattını bir sayfa üzerinde çizmek: karar kim alıyor, hata kim takip ediyor, sonuç kim raporluyor? Üçüncü adım, en kırılgan noktaya odaklanmak — AB pazarına dokunan AI sistemi, yetkisiz erişim riskinin en yüksek olduğu bağlantı noktası veya bakım yükü en ağır bot. Bu üç adım, teknoloji satın almayı değil, mevcut yatırımın değerini artırıyor. 2024’ün teknoloji gündeminde en pahalı hata, yeni araç almak değil; elindeki araçların etrafındaki çerçeveyi bir yıl daha ertelemek.

    6 dk

  • Data First Yol Haritası: Veri Kalitesi, Sahiplik ve Veri Ürünü Nasıl Kurulur

    Veri kalitesi projesi çoğu zaman teknik bir temizlik görevi olarak başlar ve organizasyonel bir çatışmayla biter. Konya’da gıda ambalaj malzemesi üreten, 312 çalışanlı bir imalat şirketi düşünün: BT ekibi geçen yılın sonunda müşteri verilerini ERP, CRM ve lojistik modülü arasında standardize etmek için altı haftalık bir temizleme projesi başlattı. Yinelenen kayıtları birleştirdiler, eksik alanları tamamladılar, adres formatlarını normalize ettiler. Proje başarıyla kapandı; raporlar üzerinde doğru çalışmaya başladı. Dört ay sonra, aynı kirlilik geri döndü. Nedeni basitti: veriyi kirleten süreç — sipariş girişinde her departmanın kendi notasyon alışkanlığı — olduğu gibi duruyordu. Teknik temizlik, organizasyonel sorunun üstüne sürülmüş bir boya katmanıydı. Bu yazı, o döngüyü kıran üç yapı taşını ve bunların sıralanmasının neden bu kadar önemli olduğunu ele alıyor.Tezimi doğrudan söyleyeyim: Veri kalitesi programı başlatmadan önce sahiplik modeli kurmayan şirketler, temizlik çalışmasını en geç altı ay içinde sıfırdan tekrarlamak zorunda kalır. Çünkü kirli veriyi üreten süreç hâlâ yerinde durmaktadır ve temizleyecek sorumlusu yoktur. Bu, BT’nin kötü iş çıkardığı anlamına gelmiyor; mülkiyet tanımlanmadan işletilen her veri alanı doğası gereği bozunur. ‘Data First’ denilen yaklaşımın Türkiye’deki en yaygın yanlış uygulaması tam da buradadır: şirketler teknik araçla (kalite taraması, MDM platformu, veri kataloğu) başlar, ama bu araçları kimin işleteceğini, kimin hesap vereceğini ve hangi ölçütle başarıyı tanımlayacaklarını belirlemeyi erteleyerek bırakır. Sıralama yanlış olunca, araç yatırımı değil süreç yatırımı kaybolur.Doğru sıralama şöyledir: sahiplik önce, kalite programı ikinci, veri ürünü üçüncü. Sahiplik modeli, her kritik veri alanı için tek bir ‘data owner’ — veri sahibi — belirlemekle başlar. Bu kişi BT’den değil, o verinin iş sonucunu yaratan birimden gelir: müşteri verisi için satış direktörü, ürün verisi için üretim planlama müdürü, tedarikçi verisi için satın alma sorumlusu. ‘Sahiplik’ kelimesi burada teknik erişim yetkisi değil, tanım otoritesi anlamına geliyor. Veri sahibi şu üç soruyu yanıtlamak zorundadır: bu alanın doğru değeri nedir, kim girebilir, ve kalite düşünce nasıl ölçülür? Bu üç soruyu yanıtlamadan açılan her kalite projesi, sorumlusuz bir temizlik kampanyasına dönüşür. Konya örneğine dönecek olursak, o şirkette sipariş verilerinin ‘sahibi’ yoktu; satış, lojistik ve muhasebe her biri alanı kendi ihtiyacına göre dolduruyordu. Sahiplik atandıktan sonra veri giriş kuralları iki haftada yazıldı ve bu sefer tutuldu.Sahiplik modeli kurulduktan sonra kalite programını başlatmak anlamlı hale gelir. Kalite, genellikle dört boyutta ölçülür: doğruluk, tamlık, tutarlılık ve zamanlılık. Ancak bu dört boyut her şirkette aynı ağırlıkla önemli değildir. İzmir’deki bir soğuk zincir lojistik firması için zamanlılık hayatta kalma meselesidir — teslimat zamanı verisi altmış dakika gecikirse iş kaybı doğrudandır. Aynı firmanın müşteri adres formatı tutarlılığı ise ikincil öneme sahiptir. Kalite programını doğru boyutlandırabilmek için her veri alanına ‘kalite boyutu ağırlığı’ atanmalı, ve bu ağırlık iş etkisiyle bağlanmalı. Ölçüm için basit bir başlangıç noktası: ERP’den haftalık otomatik çıktı alan bir kontrol panosu. Sahada gördüğüm tablo şu: Türkiye’deki KOBİ’lerin büyük çoğunluğu kalite ölçümünü ya hiç yapmıyor ya da yalnızca hata şikâyeti gelince geriye dönük yapıyor. Proaktif kalite izleme, yani alarmın yangın çıktıktan sonra değil duman görününce çalışması, gerçek programın ayırt edici özelliğidir. Bunu kurmak için veri ambarı veya sofistike araç şart değil; ERP’nin standart raporlama modülü ile başlanabilir, koşul yeter ki ölçütler veri sahibiyle birlikte yazılmış olsun.Üçüncü yapı taşı olan ‘veri ürünü’ kavramı Türkiye’de henüz az kullanılıyor, ama 2024 itibarıyla kurumsal ERP dönüşümü tartışmalarında giderek daha fazla yer buluyor. Veri ürünü (data product), belirli bir kullanım amacına göre paketlenmiş, kalitesi tanımlanmış, sorumlusu belli ve tüketilebilir bir veri varlığıdır. Klasik veri ambarı anlayışından farkı şudur: veri ambarı ‘depolar’, veri ürünü ‘teslim eder’. Ankara’daki orta ölçekli bir ilaç distribütörü, satış ekibine ve finans birimine ayrı veri ürünleri tanımlamış durumda: biri bölge bazında haftalık satış performansı, diğeri tedarikçi bazında ödeme dönüşüm süresi. Her ürünün bir sahibi, bir SLA’sı (servis düzeyi anlaşması) ve bir güncelleme sıklığı var. Satış ekibi sabah raporu açtığında verinin iki günden eski olmadığından emin. Bu güveni sağlayan teknik altyapı karmaşık değil: otomatik veri çekme + basit dönüşüm + güncel kontrol timestamp’i. Ama bu güveni veren sahip tanımı ve SLA kavramı olmadan aynı teknik altyapı salt bir rapor üretici olarak kalır, veri ürünü olmaz. EU AI Act’ın Nisan 2024’te kabul edilmesiyle birlikte bir başka boyut daha ekleniyor: AB pazarına açık Türk şirketleri için ‘yüksek riskli’ AI uygulamalarında kullanılan verinin kalite belgesi artık denetim kapsamına giriyor. Veri ürünü yaklaşımı, bu belgeleme yükümlülüğü için de hazırlık zemini oluşturuyor.Peki bu üç yapı taşını kurmanın önündeki gerçek engeller neler? İlki, sahiplik tartışmasının kısa sürede siyasi bir gerilime dönüşmesidir. ‘Bu veri kimin?’ sorusu, ‘bu veri üzerindeki güç kimin?’ sorusuna kayar; departmanlar direnir. Bu gerilimi yönetmenin yolu, sahipliği ayrıcalık değil sorumluluk olarak çerçevelemektir: veri sahibi olmak, o veriyle ilgili sorunlarda birinci muhatap olmak demektir, ek kaynak veya yetki değil. İkinci engel, kalite standartlarının gerçekçi sınırının çizilmemesidir. Türkiye’deki bir KOBİ’nin ERP’deki her alanı yüzde yüz kalitede tutması mümkün ve gerekli değildir. Bütün alanları eşit önemsemek, hiçbirini önemsememekle aynı sonucu verir. Üçüncü engel: mevcut BT ekibinin kapasitesi. Çoğu KOBİ’de bir ya da iki kişilik BT kadrosu, veri kalitesi izlemesini günlük işletilebilir görev olarak taşıyamaz. Bu durumda otomasyona veya çözüm ortağı desteğine ihtiyaç vardır; ancak burada dikkat edilmesi gereken nokta şudur: otomasyon, sahibi olmayan bir veri alanının kalite sorununu çözmez, yalnızca onu daha hızlı üretir. Sıralama yine kritik: önce sahip, sonra otomasyon.Pazartesi sabahı ne yapmalısınız? İlk adım, şirketinizdeki en kritik beş veri alanını listeleyin — satış siparişleri, müşteri kaydı, ürün tanımı, tedarikçi bilgisi, stok hareketleri başlangıç için yeterli. İkinci adım, her alan için tek bir isim yazın: bu veriyi doğru tutmaktan birinci derecede sorumlu kim? Bu isim BT’den gelemez; ilgili iş biriminden gelmelidir. Üçüncü adım, o veri sahibiyle otuz dakikalık bir toplantı yapın ve tek bir soru sorun: ‘Bu alanın kabul edilebilir kalite eşiği nedir ve bunu nasıl ölçeriz?’ Cevabı not edin, ERP’den haftalık tek bir kontrol raporu çekin. Dördüncü adım, altı hafta boyunca bu raporu aynı toplantıda gözden geçirin. Altı hafta sonra eğer sahip bağlılığı sürdüyse, kalite programının çekirdeği çalışıyor demektir; veri ürünü tanımına geçmeye hazırsınız. Bu sıra basit görünüyor. Ama Konya’daki o gıda ambalaj şirketi, teknik temizlikten önce bu dört adımı atsaydı, ikinci temizlik projesine hiç gerek kalmazdı. Veri sorunlarının büyük çoğunluğu teknik değil örgütseldir; bu gerçeği kabul etmeden başlanan her ‘Data First’ girişimi araç alır, sonuç almaz.

    7 dk

  • AI Governance Olmadan AI First Olmak Mümkün mü?

    AI First ilan etmek, yönetim kuruluna slayt sunmak kadar hızlı gerçekleşiyor. AI Governance altyapısı kurmak ise kurumsal bir inşaat projesi. Çoğu şirket bu ikisi arasındaki boşluğu ya görmezden geliyor ya da ‘sonradan düzeltiriz’ diye erteliyor. Ertelediğinde olan şey şu: birkaç başarılı pilot sonrasında sistem ölçeklenmeye başlıyor, ardından ilk ciddi karar hatasıyla birlikte tüm güven çöküyor ve şirket ‘yapay zeka çalışmıyor’ sonucuna varıyor. Oysa sorun yapay zekada değil, altyapısız hızda. Temel tez şudur: AI First stratejisi, AI Governance olmadan yalnızca hız kazandırır — ama ölçek kaybettirir. Güven altyapısı yapay zekayı yavaşlatmıyor; sürdürülebilir ölçeklenmenin ön koşulunu oluşturuyor.Ankara’da faaliyet gösteren, 312 çalışanlı orta ölçekli bir sigorta aracılık şirketini düşünün. Şirket, 2023 sonunda müşteri taleplerini sınıflandırmak için bir LLM tabanlı sistem devreye aldı. İlk altı haftada sonuçlar umut vericiydi: operatör başına düşen işlem süresi belirgin biçimde kısaldı, müşteri memnuniyet skorları yükseldi. Yönetim, sistemi hasar tespiti ve poliçe yenileme süreçlerine de genişletmeye karar verdi. Dokuz hafta sonra ortaya çıkan tablo farklıydı: model, iki farklı müşteri segmentini yanlış sınıflandırıyor ve sigorta sigortacılık mevzuatıyla çelişen öneriler üretiyordu. Kim onaylamıştı? Kim sorumluydu? Hangi verilerle eğitilmişti? Bunların hiçbirine yazılı yanıt yoktu. Şirket sistemi durdurdu — ama asıl hasar itibarsa zaten gerçekleşmişti. Bu, yönetişimsiz hızın tipik faturasıdır.AI Governance denildiğinde akla ‘uyum departmanının yeni meşgalesi’ geliyor. Bu algı yanlış, hatta tehlikeli. Yönetişim bir denetim katmanı değil; kimin hangi kararı hangi yetkiyle aldığını, modelin hangi veriyle çalıştığını, çıktıların nasıl izlendiğini ve bir şey ters gittiğinde hesap sorulabilecek insanın kim olduğunu tanımlayan operasyonel bir çerçevedir. Nisan 2024’te Avrupa Parlamentosu’nun kabul ettiği EU AI Act bu çerçeveyi artık yasal zemine taşıdı. AB pazarına hizmet satan Türk şirketleri — yazılım, finans, sağlık, lojistik — 2025’ten itibaren bu gereklilikleri fiilen karşılamak zorunda. ‘Bizi etkilemez’ diyen bir Türk yazılım şirketi, AB’li bir kurumsal müşteriden ‘sisteminizin risk sınıflandırması nedir?’ sorusunu aldığında ne yanıt verecek? Bu soru artık satış görüşmelerinde soruluyor.Governance altyapısını ‘sonradan eklerim’ diyenler iki şeyi yanlış hesaplıyor. Birincisi teknik borç: modeli üretimde çalıştıktan sonra veri kökeni takibi, model versiyonlama ve karar izlenebilirliği eklemek, sıfırdan kurmaktan ortalama üç kat daha pahalı. Bunun nedeni teknik değil; sistemin artık gerçek veriyle, gerçek kararlarla ve gerçek beklentilerle dolanık hale gelmiş olmasıdır. İkincisi güven borcu: bir model ilk ciddi hatasını yaptığında kurumun ‘bu kararı neden verdi’ sorusuna yanıt verebilmesi gerekiyor. Yanıt yoksa müşteri, düzenleyici kurum veya ortaklık tarafı güveni geri almaz. Bu güveni yeniden kazanmak teknik sorunu çözmekten çok daha uzun sürer. İzmir’deki bir lojistik yazılımı şirketinin 2023’te yaşadığı deneyim bu ikinci riski somutlaştırıyor: 445 çalışanlı şirket, rota optimizasyon önerilerini operasyonlara entegre etti, ancak modelin hangi koşullarda güvenilmez çıktı ürettiğini belgeleyen bir kural seti oluşturmamıştı. İlk büyük operasyonel aksaklık sonrasında müşterinin güveni 14 ay süren yoğun bir iyileştirme sürecine rağmen tam olarak tesis edilemedi.Peki yönetişim altyapısı pratik olarak neyi kapsar? Dört temel bileşen var. İlki hesap verebilirlik haritası: her AI kararı için ‘bu çıktıdan kim sorumlu’ sorusunun yazılı yanıtı. Model bir yanlış sınıflandırma ürettiğinde bunu düzeltme yetkisi ve sorumluluğu kimin elinde? İkincisi veri kökeni kaydı: modelin hangi veriyle, hangi tarih aralığında eğitildiğinin ve üretim verisinin bu eğitimden ne kadar saptığının izlenmesi. Üçüncüsü çıktı izleme protokolü: modelin üretimde davranışını ölçen metrikler ve bu metriklerin hangi eşiği aştığında müdahale tetikleneceğine dair kural seti. Dördüncüsü ise sınır tanımları: modelin hangi karar türlerinde otonom çalışabileceği, hangilerinde insan onayı gerektirdiği ve hangilerinde hiç kullanılmayacağına dair açık çerçeve. Bu dördü olmadan ‘AI First’ ilan etmek, yalnızca hızı ilan etmek anlamına gelir — kontrolü değil.Bu noktada bir çekince eklemek gerekiyor: yönetişim çerçevesini hatalı kurmak da en az yokluğu kadar riskli. Türkiye’de görülen yaygın hata şu: şirketler bir ‘AI Politikası’ belgesi hazırlıyor, imzalıyor ve dolaba koyuyor. Belge varlığı yönetişimle eşitleniyor. Oysa yönetişim bir belge değil, bir işletim rutinidir. Model çıktıları haftalık gözden geçiriliyor mu? Veri seti güncellemeleri versiyonlanıyor mu? İnsan denetimi gerçekten yapılıyor mu, yoksa ‘onayla’ düğmesine otomatik mi basılıyor? Bu soruların yanıtı ‘evet’ ise yönetişim çalışıyor demektir. ‘Belgemiz var’ yanıtı bu soruların hiçbirini karşılamaz.AI First olmak mümkün — ama yalnızca AI Governance’ın onu mümkün kıldığı koşullarda. Ankara’daki sigorta şirketi sistemi durdurduğunda kaynaklara değil, cevap veremediği sorulara takılmıştı. Bu soruları önceden yanıtlamak, hızı engellemez; sürekliliği garanti eder. Pazartesi sabahı yapılacak iş şudur: organizasyondaki her aktif AI uygulaması için hesap verebilirlik haritasını bir sayfalık belgede çıkarın. Kimin sorumlu olduğu yazılı değilse, o uygulama operasyonel değil — denemedir. Ve deneme ölçeklenmez.

    6 dk

  • Karar Verirken Hangi Modda Olduğunuzu Biliyor musunuz?

    Bir inşaat firmasının genel müdürü düşünün — Kayseri merkezli, 284 çalışanı, yılda yaklaşık 12 proje teslim eden orta ölçekli bir firma. Geçen Ekim ayında firmanın proje analiz sistemi, Ankara’da açılacak karma kullanımlı bir yapı için ‘devam etme’ sinyali verdi: talep verileri güçlüydü, maliyet modeli tutarlıydı, nakit akış projeksiyonu yeterliydi. Genel müdür yine de imzalamadı. ‘İçimde bir şey tamam demedi’ dedi. İki ay sonra o bölgede benzer konseptte rakip bir proje duyuruldu; onlar daha önce hareket etmişti. Bu hikayeyi anlatan kişi genel müdürün kendisiydi — ve ‘sezgim haklı çıktı mı, yoksa kaçırdım mı?’ sorusunun yanıtını hâlâ bilmiyordu.Karar vermede veri-sezgi dengesi tartışması, yönetim literatüründe onlarca yıldır süregelen bir konu. Ama 2024’te bu tartışmanın çerçevesi köklü biçimde değişti. Artık pek çok organizasyonda karar destek sistemleri, AI destekli talep tahmin modelleri ve gerçek zamanlı dashboard’lar var. Sorun veriye erişim değil. Asıl sorun şu: yöneticilerin büyük çoğunluğu veriyi kararı doğrulamak için kullanıyor, vermek için değil. Yani karar zaten verilmiş oluyor — sezgiyle, ilk izlenimle ya da statükoya güvenle — ve veri sonradan o kararın arkasına yerleştiriliyor. Bu, veri okuryazarlığı sorunu değil. Bu, karar farkındalığı sorunudur. Ve bu iki şeyin birbirinden ayırt edilmemesi, hem veri yatırımlarını hem de kurumsal öğrenmeyi zayıflatıyor.Tezimi net söyleyeyim: Veri ile sezgiyi dengelemek yöneticinin görevi değil. Asıl görev, hangi modda karar verdiğini bilmek ve bunu kayıt altına almaktır. Sezgiyle karar veriyorsanız, bunu açıkça ifade edin. Veriyle karar veriyorsanız, hangi verinin neyi temsil ettiğini ve hangi varsayımın modelin içine gömüldüğünü anlayın. Kayıt yoksa hesap verebilirlik de yoktur. Hesap verebilirlik yoksa kurumsal öğrenme başlamaz. Bu çerçeve, yöneticilerin ‘veri mi sezgi mi?’ ikilemine sıkışmasını engelleyen tek pratik çıkıştır.Sezginin kötü bir itibarı var — özellikle veri bilimcilerin yoğun olduğu organizasyonlarda. Oysa sezgi, beynin yıllarca biriktirdiği örtük örüntü tanıma kapasitesidir. Kayseri’deki o genel müdür belki rakip firmanın o bölgede arsa alım faaliyetini sezmiş, belki yerel bir müteahhitin tutumundaki değişimi fark etmişti — ve bu sinyalleri hiçbir CRM kaydına ya da dashboard’a yansıtmamıştı. Sorun sezgiyi kullanmak değil; sezgiyi sistemsiz, izlenemez ve tartışılamaz biçimde kullanmak. Bir yönetici ‘içimde bir şey tamam demedi’ dediğinde, en az iki soru sorulabilir olmalı: Bu his daha önce haklı çıktı mı? Ve hangi koşulda tetiklendi? Bu iki soruyu yanıtlayacak kurumsal bellek çoğu Türk KOBİ’sinde yoktur — verim, tam bu noktada kaybolur. İnşaat, turizm veya lojistik gibi döngüsel ve ilişki yoğun sektörlerde tecrübe birikimi gerçek bir varlıktır; ama bu varlık ancak izlenebilir hale geldiğinde kurumsal değere dönüşür.Öte yandan verinin de kendine has körlükleri var. Veriye güvenen yöneticilerin düştüğü en yaygın tuzak, modelin neyi ölçtüğünü değil neyi temsil ettiğini sormayı atlamaktır. Bir talep tahmin modeli geçmiş davranışı öğrenir; piyasa kırılmalarını, yeni bir rakibin girişini ya da tüketici tercihindeki sessiz kaymaları öğrenemez — en azından bu değişiklikler veri izine yansıyana kadar. Türkiye’de 2023 yılı boyunca perakende ve inşaat sektörlerinde birçok firma, enflasyon ortamında oluşan geçici talep artışını sürdürülebilir büyüme sinyali olarak okudu; modeller de bunu destekledi. Kura ve hammadde maliyetine duyarlılığı sistematik biçimde içermeyen modeller, yöneticilere ‘devam et’ dedi — ve bir kısmı zor çeyreklerle yüzleşmek zorunda kaldı. Veri doğruydu, ama bağlam eksikti. İşte bu tam da AI destekli karar destek sistemlerinin 2024 itibarıyla en sık düştüğü tuzaktır: modelin güven aralığını, eğitim verisinin tarihselliğini ve dışsal şokları içermediğini yöneticiye aktaramama. RAG mimarisi bu boşluğu kısmen kapatıyor — bilgi tabanını canlı tutarak modelin bağlamını güncellemeye imkan veriyor — ama sorguyu doğru soran hâlâ insandır.Peki ne yapmalı? Pazartesi sabahı, bu konuyu somuta indirgemek isteyenler için üç adım öneriyorum. Birincisi: Bir sonraki önemli kararınızda karar günlüğü tutun. Kararı vermeden önce şunu not edin — ‘Bu kararı hangi modda veriyorum? Veriye mi, sezgiye mi, yoksa ikisinin birleşimine mi dayanıyorum?’ Bu iki cümle, altı ay sonra geriye döndüğünüzde kurumsal öğrenmenin ham maddesi olur. İkincisi: AI destekli bir karar destek aracı kullanıyorsanız, modelin neyi ölçtüğünü değil neyi dışarıda bıraktığını ekibinizle en az altı haftada bir gözden geçirin. Türkiye’deki KOBİ ölçeğinde bu, genellikle dış muhasebe veya danışmanlık desteğiyle yapılabilir bir süreçtir. Üçüncüsü: Karar sonuçlarını ‘doğru çıktı / yanlış çıktı’ ikiliğiyle değil, ‘hangi varsayım tuttu, hangisi tutmadı’ sorusuyla takip edin. Bu, hem veri modelinin hem de yöneticinin sezgi kalitesinin gerçek anlamda geliştiği zemin olur.Kayseri’deki genel müdür sonunda o projeyi iki çeyrek sonra farklı bir konseptle hayata geçirdi — rekabeti görerek. Sezgisi onu durdurdu, ama neden durdurduğunu kayıt altına almamıştı; dolayısıyla ne öğrendiğini de tam olarak bilemedi. Veri ile sezginin doğru dengesi aslında bir yetenek değil, bir pratiktir. Ve her pratik gibi, ancak kasıtlı, izlenebilir ve tekrarlanabilir yapıldığında kurumsal hafızaya dönüşür. Hangi modda karar verdiğinizi bilmek, en az kararın doğru çıkması kadar önemlidir.

    6 dk

  • Dijital Ekiplerde Empati: Mesajın Arkasındaki İnsanı Görmek

    Bir Slack mesajı iki saat içinde yanıtsız kaldığında ne düşünüyorsunuz? ‘Meşguldür’ mü, ‘beni görmezden mi geliyor’, yoksa ‘bir şeyler yanlış mı gitti?’ Büyük ihtimalle saniyeler içinde bir yorum yaptınız — ve o yorum, mesajı yazan kişinin o an ne yaşadığından bihaber, sizin o günkü duygu durumunuzun süzgecinden geçti. Dijital ekiplerde empati sorunu tam burada başlar: araçlar bize hız kazandırdı ama bağlamı törpüledi. Asıl tartışmalı önerme şudur: dijital ekiplerde empati bir karakter meselesi değil, bir süreç meselesidir. İnsanları daha duyarlı yapmaya çalışmak yerine mesajın arkasındaki sinyalleri görünür kılan iletişim protokolleri inşa etmezseniz, en iyi niyetli lider de sonunda yanlış okur.İzmir’de yazılım geliştirme ve sistem entegrasyon hizmeti veren orta ölçekli bir teknoloji şirketini ele alalım — 312 çalışanı var, yaklaşık 60’ı farklı şehirlerde ya da hibrit düzende çalışıyor. Proje yöneticileri 2023 sonunda ciddi bir sorunla geldi danışmanlık masasına: deneyimli mühendisler toplantılara sessiz katılıyor, sprint review’larda söz almıyor, retrospektif notları tek kelimelik yanıtlardan oluşuyor. Kurumun ilk tepkisi bir ’empati eğitimi’ satın almak oldu. Eğitimi verdiler, anket puanları kısa süre için yükseldi. Altı hafta sonra aynı örüntü geri döndü. Sorun liderlerin empati kapasitesinde değildi; sorun, sistemin insanların yorgunluk, belirsizlik ya da hayal kırıklığı sinyallerini iletmesine izin vermemesindeydi. Asenkron kanallar bağlamı yutuyordu, kimse durumu okuyamıyordu — çünkü okuyacak veri yoktu ortada.Bu noktada AI araçlarına dair bir yanılgıyı da adlandırmak gerekiyor. 2024 itibarıyla pek çok kurumun Slack, Teams veya Notion ekosistemlerine yerleştirdiği LLM destekli asistan araçları, mesaj tonunu analiz ettiğini, ‘ekip ruh halini’ raporladığını iddia ediyor. Bu araçların bir kısmı gerçekten kullanışlı: toplantı özetleri, eylem maddesi takibi, tekrarlayan koordinasyon yükünü azaltmak. Ama ‘ton analizi’ ile ’empati’ arasındaki mesafeyi görmezden gelmek tehlikeli. Bir RAG mimarisine dayalı asistan, geçmiş konuşmalardaki kelime örüntülerini tarar ve ‘bu mesajda negatif duygu var’ diyebilir. Peki o mesajı yazan kişinin annesi hastanede mi, yoksa sadece yorgun mu, yoksa başka bir ekip arkadaşından aldığı haksız bir geri bildirim mi o tonu yarattı? Bunları sistem bilmez. AI burada sinyal üretebilir; yorumu ise her zaman insan yapmak zorunda. Bu sınırı açıkça koymazsanız, ‘araç zaten uyardı, ben gördüm’ yanılgısıyla gerçek empati pratiği tamamen devre dışı kalır.Peki süreç olarak empatinin pratik karşılığı ne? İzmir’deki o şirkette sonunda işe yarayan yaklaşım şuydu: sprint başlangıçlarına, toplantılara değil, pull request açıklamalarına yapılandırılmış bir ‘bağlam notu’ alanı eklendi. Zorunlu değil, teşvik edilen bir alan — ‘bu haftaki kapasitem, odaklanmakta zorlandığım bir konu var mı?’ İlk ay yarısından azı doldurdu. Üçüncü ayda doluluk oranı üçte ikiye çıktı. Daha önemlisi proje yöneticileri bu alanı okumaya başladığında birdenbire retrolardaki sessizliğin nereden geldiğini gördüler: iki kıdemli mühendis aynı anda yüksek baskı altındaydı, biri yeni bir teknik sorumlulukla boğuşuyordu, diğerinin rolü belirsizleşmişti. Bu bilgi sisteme girmeseydi hiç görünür olmayacaktı. Empati burada bir duygu değil, veri akışı tasarımıdır.Kurumların bu yaklaşımı nasıl ölçebileceğine dair somut adımları şöyle sıralamak mümkün. Birinci adım: asenkron kanallarda ‘bağlam sinyali’ alanlarını tanımlayın — bunlar kişisel değil, operasyonel; ‘bu iş için ne kadarlık dikkat kapasitem var?’ sorusuna yanıt veren yapılandırılmış alanlar. İkinci adım: lider davranışını değerlendirmek için tek yönlü anket değil, eylem izleme kullanın — lider o sinyalleri aldıktan sonra ne yaptı? Görev yeniden dağıttı mı, bir birebir ayarladı mı, ya da salt onayladı ve devam etti mi? Üçüncü adım: sprint veya proje döngüsü başında ekiple kısa bir ‘kapasite haritası’ yapın; bu bir terapi seansı değil, kaynak planlaması gibi davranılan beş dakikalık bir check-in. Dördüncü adım: altı haftada bir bu protokollerin ne kadarının gerçekten kullanıldığını ölçün — kullanım oranı düşüyorsa sorun araçta değil, yönetim tepkisindedir. Sinyaller gönderildi ama karşılık gelmedi, sistem güvenilirliğini kaybetti demektir. Burada bir sınır da koymak gerekiyor: bu adımlar büyük ölçekli kurumsal dönüşüm programları gerektirmiyor. KOBİ ölçeğinde, BT desteği sınırlı ortamlarda, mevcut proje yönetim araçlarının içine eklenen küçük yapısal değişikliklerle hayata geçirilebilir. Ama yönetim katmanı bu sinyallere fiilen yanıt vermezse — ve bunu ölçmezse — protokol kağıt üzerinde kalır.İzmir’deki o şirkete geri dönelim. Altı aylık uygulamanın sonunda ekip memnuniyet puanları değil, daha anlamlı bir metrik değişti: sprint ortasında yapılan kapsam revizyonları 36 puan azaldı. Bu rakam, empati eğitiminin değil, sinyal görünürlüğünün getirdiği bir operasyonel kazanımdı. Proje yöneticileri artık projenin yarısında sürprizle karşılaşmıyordu; bağlam erken görünür hale geldiği için kararlar daha önceden veriliyordu. Empatiyi duygusal bir eğitim başlığından çıkarıp iletişim altyapısının bir tasarım kararı olarak görmeye başladığınızda, hem ölçmek kolaylaşır hem de sürdürülebilir olur. Dijital ekiplerde mesajın arkasındaki insanı görmek istiyorsanız tek yapmanız gereken o insanın kendini görünür kılabileceği bir alan açmaktır — ve o alana gerçekten bakmak.

    6 dk

  • İnovasyon Kültürü: Fikir Toplamak Değil, Denemeye Alan Açmak

    Daha fazla fikir kutusu açtıkça neden inovasyon durdu? Konya’da metal ve makine imalatı yapan, 378 kişinin çalıştığı orta ölçekli bir fabrikada 2023 yılı sonunda tam bu soruyla karşılaştım. Yönetim kurulu iki yıl önce ‘inovasyon komitesi’ kurmuş, çeyrek dönemde fikir toplama toplantıları organize etmiş, hatta bir yazılım satın alarak çalışanlara dijital öneri kartı doldurtmaya başlamıştı. Sonuç: 14 ay içinde 412 fikir kartı, 3 uygulama, 1 başarısız pilot. Mühendisler artık toplantılara girmiyor, formu ‘hava durumu dolduruyor’ gibi dolduruyordu. Sorun fikirlerin kalitesiyle ilgili değildi. Sorun, deneyin kendisinin pahalıya mal olmasıydı.Bu makaldeki tez şu: İnovasyon kültürü fikir toplama mekanizması değil, başarısızlık maliyetini düşürme disiplinidir. Fikir kutusu, anket, hackathon ve inovasyon komitesi — bunların hepsi semptom yönetimidir. Asıl engel ortada durmaktadır: bir çalışan ‘bu işi farklı yapalım’ dediğinde kaybedeceklerinin kazanacaklarından fazla olduğunu hissediyorsa, ne kadar iyi fikri olursa olsun o fikri sessizce cebine koyar. Bunu ölçmek de mümkündür; 2024 itibarıyla ‘psikolojik güvenlik’ (psychological safety) araştırmacıları Amy Edmondson’ın çerçevesini şirket içi veri analiziyle birleştiren ekipler, hangi takımlarda sessizlik normunun yerleştiğini sprint retrospektif verileri ve Slack mesaj örüntüleriyle artık tespit edebiliyor.Konuya bu çerçeveden bakınca iki farklı yönetim yaklaşımı arasındaki gerilim netleşiyor: fikir odaklı inovasyon mu, deney odaklı inovasyon mu? Fikir odaklı yaklaşım ‘ne yapalım’ sorusunu merkeze alır; harika fikirler yeterince birikirse bir inovasyon çıkacağını varsayar. Deney odaklı yaklaşım ise soruyu tersine çevirir: ‘Bu fikrin yanlış olduğunu en ucuza nasıl öğreniriz?’ İkisi arasındaki fark kültürel değil yapısaldır. Birincisinde başarısızlık gizlenir çünkü maliyeti yüksektir; ikincisinde başarısızlık paylaşılır çünkü tasarım gereği küçük tutulmuştur. Türkiye’de KOBİ yöneticileri çoğunlukla birincisini uygulayıp ikincisinin sonucunu beklediği için inovasyon girişimleri tiyatroya dönüşür.Ama burada bir çekince konmadan geçilemez: Deney kültürü her sektörde aynı hızda ve aynı biçimde inşa edilemez. Konya’daki fabrikada üretim hattı üzerinde ‘hızlı deney’ yapmak, yanlış yapılandırıldığında iş güvenliği riskine dönüşür — ve bu risk gerçektir. Ankara’da faaliyet gösteren, 295 çalışanı olan bir farmasötik hammadde tedarikçisinde müdürlerden biriyle konuştuğumda tam bu noktayı dile getirdi: ‘Biz deney yaparken GMP (Good Manufacturing Practice) sınırları içinde kalmak zorundayız. Her deneme kayıt altına alınmak ve onay zincirinden geçmek zorunda.’ Bu gerçeği görmezden gelen ‘fail fast’ danışmanlık söylemi Türkiye imalat sektöründe zemin tutmuyor. Deney alanı, sektörün kısıtları içinde, kontrollü biçimde tasarlanmak zorunda.Peki deneme maliyetini düşürmek uygulamada ne anlama geliyor? Birkaç somut çerçeve var. İlki ‘küçük bahis’ (small bet) yapısıdır: bir fikir tam bütçeyle hayata geçmeden önce 4-6 haftalık, düşük kaynaklı, tek bir metrikle ölçülen bir ön deney aşamasından geçer. Konya fabrikasındaki ekip bu yapıyı 7 haftalık sprint döngüleriyle denedi; depo yerleşim optimizasyonuna ilişkin bir önerinin tam uygulamaya taşınmadan önce yalnızca tek bir koridorda test edilmesi, hem fiziksel riski hem maliyet endişesini ortadan kaldırdı. Sonuç, tam uygulama kararı almak için yeterli veriye 3 haftada ulaşılmasıydı. Buradaki kritik nokta şudur: başarısız da olsaydı bu 3 hafta kayıp sayılmazdı — yanlış fikri erkenden elemenin bedeli ödenmiş olurdu. İkinci çerçeve ‘öğrenme hedefi’ (learning goal) tanımıdır: her deneyin başında ‘neyin doğru olduğunu kanıtlamak istiyoruz’ değil, ‘neyin yanlış olduğunu en ucuz şekilde öğrenmek istiyoruz’ sorusu sorulur. Soru yönü değişince ekip psikolojisi de değişir; başarısızlık artık ‘suç’ değil ‘veri’ olur. Üçüncü çerçeve ise sonuçtan bağımsız ödüllendirmedir: deneyi tasarlayan ve yürüten kişi, sonuç olumsuz çıksa bile bu girişimi nedeniyle değerlendirilir. Aksine, deneme sürecini atlamak veya gizlemek olumsuz not getirir. Bu üç çerçeve birlikte uygulanmadığında herhangi biri tek başına yeterli olmaz.Türkiye’deki şirketler bu konuya 2024 itibarıyla farklı bir baskıyla da yaklaşıyor: AI araçlarının iş süreçlerine entegrasyonu. Generative AI tabanlı araçların hızla yaygınlaştığı bu dönemde, inovasyon kültürü olmayan şirketler araçları alıyor ama dönüşümü gerçekleştiremiyor. Bunun nedeni teknik değil kültüreldir: ekipler ‘bu aracı nasıl kullansak’ sorusunu sormadan önce ‘bu aracın beklentimizi karşılamadığını söylersek ne olur’ kaygısını taşıyor. Küçük deneyleri güvenli kılan yapı olmadığında, AI pilot projeleri de aynı kaderi paylaşıyor — bütçe onaylanıyor, araç satın alınıyor, 3 ayda sonuç bekleniyor, hayal kırıklığı yaşanınca ‘yapay zeka bu işe yaramıyor’ kararı çıkıyor. Oysa sorun araçla değil, deneme kapasitesiyle ilgilidir. Bir RAG mimarisi üzerinde çalışan Gaziantep’teki bir lojistik firması bu döngüyü ‘pilot başarısızlığını’ sonunda paylaşmayı seçerek kırdı: tüm ekip neyin işe yaramadığını öğrendi ve ikinci pilot ilk denemeden tam 53 gün daha kısa sürede tamamlandı. Paylaşılan başarısızlık, gizlenen başarısızlıktan her zaman daha üretkendir.Konya fabrikasına dönelim. On dört ayda 412 fikir kartı biriken o sistemin bugün hâlâ çalışıp çalışmadığını bilmiyorum. Ama şunu biliyorum: o sistemin işe yaramamasının nedeni mühendislerin fikir üretememesi değildi. Nedeni, fikrin yanlış çıkmasının kime fatura edileceğinin belirsiz olmasıydı. Denemeye alan açmak, belirsizliği yönetmek demektir — hem riskin hem öğrenmenin kime ait olduğunu net kılmak demektir. Bunu yapısal olarak çözmeden inovasyon kültürü kurmaya çalışmak, toprak hazırlamadan tohum ekmek gibidir: tohum güzel olsa da çıkmaz. Şirketinizde bir sonraki inovasyon toplantısını planlamadan önce şu soruyu sormaya değer: Birisi o toplantıda yanlış bir fikir önerdiğinde ne oluyor? Cevap ‘pek bir şey olmaz’ değilse, problem fikir toplama mekanizmasında değil, başarısızlık maliyetindedir.

    6 dk

  • Generative AI’da Pilot-Değer Açığı: 2024’te Ölçülemeyen Şey Yönetilemez

    2023’te başlatılan generative AI pilotlarının büyük çoğunluğu kurumsal raporlarda ‘başarılı’ olarak işaretlendi. Bu iddia doğrulanabilir mi? Sahada gördüğüm tablo başka bir şey anlatıyor: o pilotların ancak küçük bir kısmı 2024 başında üretim ortamında çalışıyor. Geri kalanlar hâlâ sunum klasöründe ya da yönetim kurulu için hazırlanmış bir demo kaydında. Asıl mesele şu değil: şirketler denemedi. Asıl mesele şu: çoğu şirket AI başarısını ERP go-live metriğiyle ölçtü — sistem ayakta mı, kullanıcılar giriş yapıyor mu? Bu iki sorunun yanıtı ‘evet’ olunca pilot ‘başarılı’ sayıldı. Oysa üretken yapay zekânın değeri, sistemin ayakta olmasında değil, iş çıktısında yatar. 2024’ün yönetim görevi, bu açığı kapatmak.Kayseri’de 312 çalışanıyla metal aksam üreten ve beş ülkeye ihracat yapan orta ölçekli bir imalat firmasının 2023 ortasında başlattığı RAG tabanlı teknik dokümantasyon asistanını ele alalım. Temsili değil, bu sektörde sık karşılaştığım bir vaka tipi. Pilot sekiz haftada tamamlandı; demo eksiksiz çalıştı; IT müdürü yönetim kuruluna sistemi tanıttı. Fakat üç ay sonra sahaya indiğimde mühendislerin yarısından fazlasının sistemi düzenli kullanmadığını gördüm. Neden? Çünkü teknik dokümanların yüzde kırkından fazlası sisteme giren veri tabanıyla eşleşmiyordu — kağıt arşiv henüz dijitalleştirilmemişti. RAG mimarisi veriyi doğru biçimde indekslemişti; ancak verinin kendisi eksikti. Demo başarılıydı çünkü demo verisi özenle seçilmişti. Prodüksiyon farklı bir şeydi.Bu örneğin öğrettikleri, generative AI yönetiminin 2024’teki iki temel sorusunu doğuruyor. Birincisi: doğru veriyi sisteme soktunuz mu? İkincisi: başarıyı neyle ölçüyorsunuz? Bu iki soruya net yanıt verilmeden başlatılan her pilot, bütçe tüketir ama değer üretmez. RAG mimarisi son derece güçlü bir araçtır — kurumun kendi bilgi tabanını LLM’e bağlar, halüsinasyon riskini düşürür, KVKK kapsamındaki verilerin dışarı çıkma riskini azaltır. Ama bu araç yalnızca altındaki verinin kalitesiyle orantılı sonuç verir. Veri kalitesini ölçmeden RAG kuran şirket, temelsiz bir binanın üst katını inşa ediyor demektir.Ölçüm sorunu burada başlıyor. Aynı Kayseri vakasında, doğru soruları sorsaydık şunu ölçerdik: mühendis başına teknik doküman arama süresi haftada kaç saat? Bu süre altı hafta sonra değişti mi? Yanlış parçayla üretim hatası oranı düştü mü? Bu soruları sormadıklarında ellerinde tek bir veri vardı: sistem çalışıyor. Sistem çalışmasıyla değer yaratılması arasındaki mesafe tam da pilot-değer açığının genişlediği yerdir. 2024’te bu açığı kapatmak için her AI girişiminin başında üç şeyin yazılı olması gerekiyor: hangi iş metriği değişmeli, ne kadar değişmeli ve sekiz haftada değişmezse ne yapılacak. Bu üç maddeyi yazamıyorsanız pilot henüz hazır değil.Türkiye’nin özgün dinamikleri bu tabloyu daha da karmaşıklaştırıyor. Nisan 2024’te kabul edilen AB AI Yasası, 2025’ten itibaren aşamalı yürürlüğe girecek. AB pazarına ihracat yapan Türk şirketleri — özellikle tekstil, otomotiv yan sanayi ve gıda ihracatçıları — bu uyum süreciyle ilk kez yüz yüze gelecek. Ankara merkezli bir finans yazılımı firması bu riski erken fark etti ve müşterilerine yönelik AI özelliklerini risk sınıflandırması yaparak geliştiriyor; AB müşterileri için yüksek riskli sayılan karar destek modülleri ayrı onay süreçlerinden geçiyor. Bu karar salt uyum zorunluluğundan değil, müşteri güvenini yönetme ihtiyacından doğdu — ki bu ikisi aynı şey değil. Öte yandan KVKK ile AI eğitim verisi kullanımı arasındaki gerilim hâlâ netlik kazanmış değil; Kişisel Verileri Koruma Kurumu’nun sektöre özgü kılavuzları 2024 içinde bekleniyor. Bu belirsizlik, müşteri verisiyle fine-tuning yapacak şirketlerin planlarını bekle-gör modunda tutmasına yol açıyor.SLM’ler — küçük dil modelleri — bu bağlamda pratik bir çözüm olarak öne çıkıyor, ama dikkatli bir değerlendirme gerektiriyor. 7B veya 13B parametreli modeller şirket içi sunucularda çalışabilir, buluta veri göndermez, KVKK açısından daha savunulabilir bir pozisyon sunar. Fakat kapasiteleri sınırlı: çok adımlı akıl yürütme, uzun bağlam gerektiren hukuki veya teknik analiz, karmaşık çok dilli çıktı — bu görevler için büyük modellere ihtiyaç var. Sanayi ihracatçısının teknik doküman asistanı için SLM yeterliydi; ancak aynı firmanın müşteri sözleşmelerini analiz etmesi için GPT-4 sınıfı bir model gerekiyor. Bu ayrımı ‘en iyisini alalım’ mantığıyla değil, her görev için hangi model yeterli sorusuyla yapmak, hem maliyet hem de veri güvenliği açısından doğru yoldur. Kur baskısı göz önüne alındığında — büyük model API maliyetleri dolar bazlı — bu ayrım 2024’te stratejik değil, finansal bir zorunluluk haline geliyor.AI ajanları konusunda ise daha temkinli olmak gerekiyor. Piyasada ajan çözümleri iddialı biçimde pazarlanıyor; bazı satıcılar ‘tamamen otomatik süreç’ vaadi sunuyor. Gerçekte, bir AI ajanının ne yapabileceği, hangi sistemlere ne yetki düzeyinde bağlandığına ve hata durumunda devreye girecek insan denetim katmanına bağlı. 2024’te doğru soru şu: bu ajan neyi tek başına yapabilir, nerede mutlaka insan onayı gerekli ve hata durumu nasıl kayıt altına alınıyor? Bu üç soruya yanıt verilmeden kurulan ajan sistemi, denetim boşluğu yaratır. Denetim boşluğu ise AB AI Yasası kapsamında yüksek riskli kategori anlamına gelebilir. Deneysel dönem bitti; şimdi her sistemin hesap verebilirlik hattı net çizilmiş olmak zorunda. Pilottan ölçülebilir değere giden yol, iyi niyetle değil, iyi tasarlanmış ölçüm çerçevesiyle döşeniyor.

    6 dk