LLM Gözlemlenebilirliği: OpenTelemetry GenAI, Langfuse ve KVKK Uyumlu İçerik Loglama (2026)

TL;DR — 2026, LLM gözlemlenebilirliğinin (observability) "nice-to-have"tan zorunluluğa döndüğü yıl oldu. OpenTelemetry'nin GenAI Semantic Conventions'ı, LLM operasyonlarının nasıl kaydedileceğini standartlaştırdı: hangi model çağrıldı, kaç girdi/çıktı token'ı harcandı, araç çağrıları ve tamamlamalar nasıl gitti. Mart 2026 itibarıyla çoğu GenAI semantic convention hâlâ deneysel (experimental) statüde ama Datadog, New Relic ve Dynatrace bunları yerel olarak destekliyor; OTel ile enstrümante edilen ajan kodu, SDK değişikliği olmadan bu platformlara veri gönderiyor. Langfuse ise ClickHouse tarafından 16 Ocak 2026'da satın alındı ve 2.000'den fazla ödeme yapan müşteri ile ayda on milyonlarca SDK kurulumu bildiriyor. Bu yazıda LLM gözlemlenebilirliğinin neden farklı olduğunu, GenAI semantic conventions'ın ne getirdiğini, bir gözlemlenebilirlik hattını nasıl kuracağınızı ve maliyet-gecikme-kalite üçgenini nasıl yöneteceğinizi KVKK bağlamıyla anlatıyorum.

Yıllardır yazılım sistemlerini metrik, log ve trace ile izliyoruz. CPU, bellek, gecikme, hata oranı — bunlar tanıdık. Ama LLM sistemleri, klasik gözlemlenebilirliğin görmediği yeni bir katman getiriyor: anlamsal katman. Bir HTTP endpoint'i ya 200 ya 500 döner; ölçmesi kolay. Bir LLM ise 200 döner ama cevap tamamen yanlış olabilir. Sistem "sağlıklı" görünürken kullanıcıya saçmalıyor olabilir.

İşte bu yüzden LLM gözlemlenebilirliği farklı. Sadece "sistem ayakta mı" değil, "sistem doğru mu, kaliteli mi, ne kadara mal oluyor" sorularını da cevaplaması gerekiyor. Klasik metrikler (gecikme, hata) hâlâ gerekli ama yeterli değil. LLM'e özgü yeni boyutlar var: token kullanımı, maliyet, halüsinasyon oranı, cevap sadakati, prompt versiyonu, model versiyonu, araç çağrı başarısı.

Sahada gördüğüm en tehlikeli durum, "sistem çalışıyor gibi" güveni. Ekip metrikleri izler, gecikme normal, hata oranı düşük, herkes rahat. Ama kimse çıktı kalitesini izlemiyor. Sonra bir müşteri "bu chatbot bana yanlış bilgi verdi ve ben ona göre karar aldım" der ve kimsenin haberi olmadan haftalardır bir kalite sorunu yaşandığı anlaşılır. LLM gözlemlenebilirliği, tam da bu kör noktayı aydınlatmak için var.

Yıllarca herkes LLM izlemeyi kendi tescilli formatıyla yaptı. Her araç farklı alan adları kullanıyordu, veriler taşınmıyordu, bir platformdan diğerine geçmek her şeyi baştan yazmak demekti. OpenTelemetry'nin GenAI Semantic Conventions'ı bu kaosu bitirdi: GenAI operasyonlarının nasıl kaydedileceğine dair ortak bir standart.

Bu standart neyi kaydediyor? Çağrılan modeli, girdi ve çıktı token sayılarını, ve (opt-in yapıldığında) prompt'ların, tamamlamaların, araç çağrılarının ve araç sonuçlarının tam içeriğini. Somut alanlar örneğin şunlar: gen_ai.request.model (kullanılan model), gen_ai.usage.input_tokens ve gen_ai.usage.output_tokens (her LLM çağrısı için token sayıları), gen_ai.response.finish_reasons (modelin neden üretmeyi durduğu).

Bunun neden devrim olduğunu anlamak için lock-in perspektifine bakın. Standart öncesi, izleme aracınızı değiştirmek tüm enstrümantasyonu yeniden yazmak demekti. Standart sonrası, OTel ile bir kez enstrümante edersiniz ve bu veriyi destekleyen herhangi bir platforma gönderebilirsiniz. Datadog, New Relic ve Dynatrace artık GenAI semantic conventions'ı yerel destekliyor — yani OTel ile enstrümante edilmiş ajan kodunuz, hiçbir SDK değişikliği olmadan bu platformlara veri gönderiyor. Bu, tedarikçi kilidini kıran güçlü bir mimari karar.

"

Önemli uyarı: Mart 2026 itibarıyla çoğu GenAI semantic convention hâlâ deneysel statüde. Bu, alan adlarının ve yapının değişebileceği anlamına gelir. Yine de standarda göre enstrümante etmek, tescilli formata göre enstrümante etmekten çok daha güvenli — çünkü standart olgunlaştıkça sizinle birlikte gelişecek, tescilli format ise sizi geride bırakabilir.

LLM gözlemlenebilirliğinin en görünür oyuncularından Langfuse, OTel GenAI semantic conventions ile uyumlu olmayı ve büyük LLM enstrümantasyon framework'lerini desteklemeyi hedefliyor. Bir OpenTelemetry backend'i olarak çalışabiliyor: OTLP endpoint'i üzerinden trace alıyor. Bu, Langfuse'un SDK'ları ve yerel entegrasyonlarının ötesinde, framework, kütüphane ve dillerle uyumluluğu artırmak için tasarlanmış.

Langfuse, aldığı OTel trace'lerini kendi veri modeline eşliyor ve OTel GenAI ekosisteminde popüler ek alanları destekliyor. Semantic conventions hâlâ evrildiği için bu esneklik önemli: standart değişse bile Langfuse veriyi anlamlandırmaya devam ediyor.

Sektörün bu alana verdiği önemi gösteren bir işaret: ClickHouse, Langfuse'u 16 Ocak 2026'da satın aldı. Langfuse, 2.000'den fazla ödeme yapan müşteri ve ayda on milyonlarca SDK kurulumu bildiriyor. Bu rakamlar, LLM gözlemlenebilirliğinin artık niş bir konu değil, kurumsal bir gereklilik olduğunu gösteriyor. Açık kaynak bir aracın büyük bir veri altyapısı şirketi tarafından satın alınması, bu katmanın stratejik önemini teyit ediyor.

Teoriyi bırakıp pratiğe geçelim. Bir LLM gözlemlenebilirlik hattı üç aşamada kurulur: enstrümantasyon, toplama, analiz.

Aşama 1 — Enstrümantasyon. LLM çağrılarınızı OTel GenAI semantic conventions'a göre enstrümante edin. Her çağrıda modeli, token sayılarını, gecikmeyi, prompt versiyonunu ve (KVKK izin veriyorsa) içeriği kaydedin. Ajan sistemlerinde her adımı bir span olarak izleyin: araç çağrıları, alt-ajan delegasyonları, yeniden planlamalar. Amaç, bir isteğin uçtan uca yolculuğunu görebilmek.

Aşama 2 — Toplama. Enstrümante edilmiş veriyi bir backend'e gönderin: Langfuse, Datadog, New Relic ya da kendi barındırdığınız bir OTel toplayıcı. OTel kullandığınız için bu seçim taşınabilir — backend'i değiştirmek enstrümantasyonu değiştirmiyor.

Aşama 3 — Analiz. Topladığınız veriden içgörü çıkarın. Hangi prompt'lar en çok token yakıyor? Hangi model çağrıları en yavaş? Halüsinasyon oranı hangi senaryolarda yükseliyor? Maliyet hangi kullanıcı segmentinde patlıyor? Bu analiz, sistemi iyileştirmenin haritası.

Bu üç aşama, bir kerelik kurulum değil, sürekli işleyen bir döngü. Sistem değiştikçe enstrümantasyon güncellenir, yeni metrikler eklenir, yeni analizler yapılır. Gözlemlenebilirlik bir proje değil, bir pratiktir.

Klasik gözlemlenebilirlikten gelen kavramlar — trace ve span — LLM dünyasında da geçerli ama yeni bir anlam kazanıyor. Bir trace, bir kullanıcı isteğinin uçtan uca yolculuğu. Bir span, bu yolculuktaki tek bir adım. Klasik bir web isteğinde span'ler HTTP çağrıları, veritabanı sorgularıdır. Bir LLM ajanında span'ler LLM çağrıları, araç çağrıları, getirme adımları, yeniden planlamalar.

Bir ajan trace'ine baktığınızda görmeniz gereken şey: kullanıcı isteği geldi, ajan şu planı yaptı, şu aracı çağırdı (bu kadar sürdü, bu kadar token), şu getirmeyi yaptı, şu cevabı üretti. Bu iç görünürlük, "ajan neden yavaş" ya da "ajan neden yanlış cevap verdi" sorularını tahminden çıkarıp teşhise çeviriyor. Bir span'in yavaş olduğunu görürseniz oraya odaklanırsınız; bir getirme adımının boş döndüğünü görürseniz RAG hattınızı düzeltirsiniz.

GenAI semantic conventions'ın güzelliği, bu span'lere standart alanlar eklemesi. gen_ai.usage.input_tokens her span'de aynı isimle durur, hangi araçla enstrümante ettiğinizden bağımsız. Bu standartlık, farklı ekiplerin, farklı sistemlerin ve farklı platformların aynı dili konuşmasını sağlar. Bir mühendis bir trace'e baktığında, hangi aracın ürettiğini bilmeden anlayabilir.

LLM gözlemlenebilirliğinin en pratik faydası maliyet görünürlüğü. Token bazlı fiyatlandırma, maliyeti görünmez ve öngörülemez kılabilir. Bir prompt'a fazladan bir paragraf eklemek, milyonlarca çağrıda binlerce dolara mal olabilir ve kimse fark etmez — ta ki fatura gelene kadar.

Gözlemlenebilirlik bunu çözer. Her çağrının token kullanımını ve maliyetini izlerseniz, şu soruları cevaplayabilirsiniz: Hangi özellik en pahalı? Hangi kullanıcı en çok maliyet üretiyor? Hangi prompt gereksiz uzun? Bağlam penceremiz şişiyor mu? Bu görünürlük, maliyet optimizasyonunun temeli.

Sahada gördüğüm tipik kazanımlar: gereksiz uzun sistem prompt'larını kırpmak, tekrar eden bağlamı prompt caching ile önbelleğe almak, basit görevleri ucuz modele yönlendirmek, ve bağlam sıkıştırma ile token kullanımını azaltmak. Bunların hepsi ancak maliyeti görebiliyorsanız mümkün. Ölçmeden optimize edemezsiniz. Ve LLM maliyetleri, ölçülmediğinde sessizce büyüyen bir gider kalemi.

Burada Türk şirketleri için kritik bir ikilem var. Gözlemlenebilirlik, en çok değeri prompt ve cevap içeriğini logladığınızda verir — bir sorunu teşhis etmek için ne sorulduğunu ve ne cevaplandığını görmeniz gerekir. Ama bu içerik, sıklıkla kişisel veri içerir. GenAI semantic conventions içerik loglamayı opt-in yapıyor, tam da bu yüzden.

KVKK bağlamında içerik loglama dikkatli tasarlanmalı. Bir müşteri destek konuşmasını loglamak, o müşterinin kişisel verilerini bir gözlemlenebilirlik sistemine kopyalamak demek. Bu, veri minimizasyonu, amaç sınırlaması ve saklama süresi ilkelerini tetikler. Çözüm, körlemesine "her şeyi logla" ya da "hiçbir şeyi logla" değil, dengeli bir yaklaşım.

"

Pratik desen: metadata'yı (model, token, gecikme, prompt versiyonu) her zaman logla; içeriği (prompt, cevap) ise maskeleyerek, örnekleyerek ya da kişisel veriyi anonimleştirerek logla. Hassas alanları (TC kimlik, sağlık, finans) log öncesi tespit edip redaksiyon uygula. Ve log saklama süresini KVKK'ya uygun sınırla. Böylece hem teşhis yeteneğini korur hem uyumlu kalırsınız.

Bir başka önlem: içerik loglama için erişim kontrolü. Herkes her trace'in içeriğini göremesin; sadece teşhis için gereken kişiler, gerektiği kadar. Bu, hem KVKK'yı hem iç veri güvenliğini güçlendirir. Gözlemlenebilirlik güçlü bir araç ama gücüyle orantılı bir veri sorumluluğu getiriyor.

Gözlemlenebilirlik "üretimde ne oluyor" sorusunu cevaplar; değerlendirme (eval) "sistem ne kadar iyi" sorusunu. İkisi birlikte çalıştığında güçlüdür. Üretim trace'lerinden ilginç ya da başarısız vakaları toplayıp bir eval setine eklersiniz. Bu set, sonraki iyileştirmeleri ölçmenin temeli olur. Yani gözlemlenebilirlik, eval setinizi sürekli besleyen bir kaynak.

Olgun bir hat şöyle işler: üretimde bir kullanıcı düşük puan verir ya da bir cevap şüpheli görünür → o trace işaretlenir → bir insan gözden geçirir → eğer gerçekten hataysa eval setine eklenir → sonraki model/prompt değişikliği bu vakaya karşı test edilir. Bu döngü, sistemi zamanla iyileştiren bir öğrenme makinesi. Gözlemlenebilirlik olmadan bu döngü kurulamaz çünkü hangi vakaların sorunlu olduğunu göremezsiniz.

Bu yüzden ben gözlemlenebilirlik ve eval'ı ayrı projeler olarak değil, tek bir kalite altyapısının iki yüzü olarak kuruyorum. Biri "ne oluyor"u, diğeri "ne kadar iyi"yi ölçer; ikisi birlikte "nasıl iyileştiririm"i cevaplar.

Hata 1 — Sadece klasik metrikleri izlemek. Gecikme ve hata oranı gerekli ama LLM için yetmez. Kalite, maliyet ve token boyutlarını da izleyin.

Hata 2 — Tescilli formata kilitlenmek. Bir izleme aracının kendi formatına gömülmek, geçişi imkânsız kılar. OTel GenAI semantic conventions'a göre enstrümante edin, taşınabilir kalın.

Hata 3 — İçeriği düşünmeden loglamak. KVKK bağlamında körlemesine içerik loglamak bir ihlal riski. Metadata her zaman, içerik dengeli ve redakte.

Hata 4 — Gözlemlenebilirliği sonradan eklemek. Sistem üretime girdikten sonra enstrümantasyon eklemeye çalışmak zordur. Baştan gömün.

Hata 5 — Gözlemlemek ama harekete geçmemek. Veri toplamak yetmez; o veriden içgörü çıkarıp sistemi iyileştirmezseniz, gözlemlenebilirlik sadece pahalı bir depolama gideri olur.

LLM sisteminiz üretimdeyse ve gözlemlenebilirliğiniz yoksa, bu hafta başlayın. Önce en kritik hattı OTel GenAI semantic conventions'a göre enstrümante edin — token, maliyet, gecikme, model versiyonu. Bir backend seçin (Langfuse iyi bir açık kaynak başlangıç). İlk trace'leri görün ve şu üç soruyu cevaplayın: En pahalı özelliğim ne? En yavaş adımım ne? Kalite kör noktam nerede?

Bu ilk kurulum, sizi "sistem çalışıyor gibi" güveninden "sistemi ölçüyorum, biliyorum" konumuna taşır. 2026'da LLM gözlemlenebilirliği artık lüks değil; üretim LLM sisteminin temel altyapısı. Standart olgunlaştı, araçlar olgunlaştı, ekosistem birleşti. Geriye disiplinli uygulama kalıyor. Ve KVKK bağlamında, dengeli içerik loglama ile hem teşhis yeteneğinizi hem uyumunuzu koruyabilirsiniz. Sahadan en net tavsiyem: ölçmediğiniz şeyi yönetemezsiniz, ve LLM sistemlerinde yönetilmeyen şey — maliyet, kalite, güvenlik — sessizce büyüyerek sizi bir gün şaşırtır. Gözlemlenebilirlik, o sürprizi önleyen sigortadır.

Gözlemlenebilirlik pasif değil, aktif olmalı. Veri toplamak bir başlangıç ama asıl değer, bir şey ters gittiğinde sizi uyarmasında. Klasik yazılımda SLO (Service Level Objective) tanımlarız: "%99.9 uptime", "p95 gecikme 200ms altında". LLM sistemlerinde de SLO'lar gerekli ama farklı boyutlarda.

LLM'e özgü SLO örnekleri: "cevap sadakati %95'in üstünde", "ortalama token maliyeti istek başına şu sınırın altında", "halüsinasyon işaretleme oranı %2'nin altında", "p95 ilk-token gecikmesi şu saniyenin altında". Bu SLO'lar ihlal edildiğinde otomatik uyarı gitmeli. Böylece bir kalite düşüşünü müşteri şikâyetinden değil, sisteminizden öğrenirsiniz.

Sahada gördüğüm olgun bir desen: prompt ya da model değişikliğinden sonra kalite metriklerini yakından izlemek. Yeni bir model versiyonuna geçtiniz diyelim — maliyet düştü ama sadakat de düştü mü? Gözlemlenebilirlik hattı bunu anında gösterir. Uyarısız bir sistemde bu regresyonu haftalar sonra, kullanıcı kaybıyla öğrenirsiniz. Uyarılı bir sistemde ise dakikalar içinde fark eder, geri alırsınız. Fark, proaktif ile reaktif arasındaki fark.

Gözlemlenebilirliğin sıklıkla atlanan ama kritik bir boyutu: her trace'i hangi prompt ve model versiyonunun ürettiğini bilmek. Prompt'lar değişir, modeller güncellenir ve bu değişiklikler kaliteyi hem iyi hem kötü yönde etkiler. Eğer her trace'e prompt versiyonunu ve model versiyonunu etiketlemezseniz, "kalite neden düştü" sorusunu asla cevaplayamazsınız.

Somut bir örnek: bir pazartesi kalite metrikleriniz düşüyor. Gözlemlenebilirlik hattınız her trace'i versiyonladıysa, hemen görürsünüz: "cuma günü prompt v12'den v13'e geçmişiz ve düşüş o zaman başlamış." Teşhis anında. Versiyonlamadıysanız, günlerce körlemesine ararsınız. Bu yüzden prompt ve model versiyonlama, gözlemlenebilirliğin bir lüksü değil, temel gereği.

İyi bir uygulama: prompt'ları kod gibi versiyonlayın, her dağıtımı etiketleyin ve gözlemlenebilirlik hattında bu etiketleri filtrelenebilir tutun. Böylece "v13 vs v12" karşılaştırması bir tık uzağınızda olur. Langfuse gibi araçlar prompt yönetimini gözlemlenebilirlikle birleştirdiği için bu iş akışını doğal kılar — prompt'u yönetirsiniz, aynı yerde etkisini ölçersiniz.

Tek bir LLM çağrısını izlemek görece basit. Ama bir orkestratör-işçi ajan filosunda, bir kullanıcı isteği onlarca span, birden çok ajan ve birçok araç çağrısına yayılır. İşte burada dağıtık izleme (distributed tracing) hayati. Bir trace, tüm bu dağınık adımları tek bir görünümde birleştirmeli ki "istek nerede yavaşladı, hangi ajan hata yaptı" görülebilsin.

OTel'in gücü tam burada parlıyor. OTel zaten dağıtık izleme için tasarlandı; GenAI semantic conventions bunun üzerine LLM'e özgü alanları ekliyor. Yani bir ajan filosunu OTel ile enstrümante ederseniz, hem klasik dağıtık izleme (hangi servis, hangi çağrı) hem LLM'e özgü boyutlar (hangi model, kaç token) tek bir tutarlı görünümde birleşir. Bu, karmaşık ajan sistemlerini hata-ayıklanabilir kılan şey.

Sahada karmaşık bir ajan sistemi kurduğunuzda, dağıtık izleme olmadan hata ayıklamak neredeyse imkânsız. Bir istek başarısız olur ama neden? Hangi ajanda? Hangi araç çağrısında? Dağıtık trace, bu soruların cevabını tek bir zaman çizelgesinde gösterir. Bu görünürlük, ajan filolarını üretimde yönetilebilir kılan temel altyapı.

Türkiye'de bir SaaS şirketiyle çalışırken klasik bir "sessiz maliyet sızıntısı" vakası yaşadık. Şirketin LLM faturası aylık olarak yavaşça ama istikrarlı büyüyordu ve kimse sebebini bilmiyordu. Kullanıcı sayısı sabit, özellik seti aynı, ama fatura tırmanıyordu. Yönetim endişeliydi.

Gözlemlenebilirlik hattı kurduğumuzda sebep bir haftada ortaya çıktı. Bir özellikte, konuşma geçmişi hiç sıkıştırılmadan her çağrıya ekleniyordu. Kullanıcı bir konuşmayı ne kadar uzatırsa, her yeni mesaj o kadar çok token yüklüyordu. Uzun konuşmalarda tek bir mesaj, gereğinden on kat fazla token harcıyordu. Kimse fark etmemişti çünkü kimse token kullanımını izlemiyordu.

Çözüm basitti: bağlam sıkıştırma. Belirli bir uzunluktan sonra konuşma geçmişini özetleyip yerine özeti koyduk. Sonuç: o özelliğin maliyeti belirgin biçimde düştü, kalite ise korundu çünkü özet, konuşmanın özünü taşıyordu. Bu vakanın dersi net: göremediğiniz maliyeti optimize edemezsiniz. Gözlemlenebilirlik, bu sızıntıyı görünür kıldı ve düzeltmeyi mümkün kıldı.

İki dünyayı yan yana koymak, farkı netleştirir.

Boyut	Klasik Gözlemlenebilirlik	LLM Gözlemlenebilirlik
Temel soru	Sistem ayakta mı?	Sistem doğru ve kaliteli mi?
Metrikler	CPU, bellek, gecikme, hata	+ token, maliyet, sadakat, halüsinasyon
Başarı sinyali	HTTP 200	200 + doğru içerik
Birim	İstek	İstek + prompt/model versiyonu
İçerik	Genelde loglanmaz	Loglanabilir (KVKK dikkatiyle)
Standart	OTel (olgun)	OTel GenAI (deneysel, hızla olgunlaşıyor)

Bu tablo şunu gösteriyor: LLM gözlemlenebilirliği klasik gözlemlenebilirliğin yerine değil, üstüne geliyor. Klasik metrikleri hâlâ izlersiniz; sadece yeni, anlamsal bir katman eklersiniz. Ve bu katman, LLM sistemlerinin en tehlikeli kör noktasını — "çalışıyor gibi ama yanlış" durumunu — aydınlatır.

"Küçük bir ekibiz, bu altyapı bize fazla mı?" Hayır. Açık kaynak araçlarla (Langfuse gibi) minimal bir gözlemlenebilirlik hattı bir günde kurulur. Token ve maliyet izlemek bile başlangıçta büyük değer verir. Küçüklük, kör uçmak için bahane değil.

"Hangi metrikle başlamalıyım?" Token ve maliyetle. En hızlı geri dönüşü bunlar verir ve KVKK açısından da en az hassas olanlardır (içerik değil, sayı). Sonra gecikme, sonra kalite metrikleri.

"OTel deneysel demiştin, güvenli mi?" Deneysel, alan adlarının değişebileceği anlamına gelir ama tescilli formattan yine de daha güvenli. Standart, sizinle birlikte gelişir; tescilli format sizi kilitler. Deneysel bir standart, olgun bir kilitten iyidir.

"İçeriği hiç loglamasak olmaz mı?" Metadata (token, maliyet, gecikme) çoğu operasyonel soruyu cevaplar. Ama kalite teşhisi için bir miktar içerik görünürlüğü gerekir. Çözüm, dengeli ve redakte içerik loglama — hiç değil ya da her şey değil, kontrollü bir orta yol.

Gözlemlenebilirlik, 2026'da LLM mühendisliğinin sessiz kahramanı. Etkileyici demolar model gücünden gelir ama üretim güvenilirliği gözlemlenebilirlikten. Ölçen ekip iyileştirir; ölçmeyen ekip tahmin eder ve tahmin, üretimde pahalı bir para birimidir. Bugün en kritik hattınızı enstrümante edin, ilk trace'lerinizi görün ve o "aha" anını yaşayın: meğer sistemim hakkında ne kadar az şey biliyormuşum. O an, iyi mühendisliğin başladığı andır.

Gözlemlenebilirlik hattı kurarken bir karar noktası da mimari sahiplik: aracı kendiniz mi barındıracaksınız yoksa yönetilen bir hizmet mi alacaksınız? Bu karar, hem maliyet hem KVKK açısından önemli.

Kendi barındırma (self-hosting), veriyi kendi altyapınızda tutmanızı sağlar — KVKK açısından güçlü bir avantaj, çünkü prompt ve cevap içeriği hiçbir zaman dışarı çıkmaz. Langfuse gibi açık kaynak araçlar bunu mümkün kılıyor. Bedeli, işletme yükü: sunucu, güncelleme, ölçekleme sizin sorumluluğunuzda. Küçük ekipler için bu yük ağır gelebilir.

Yönetilen hizmet (managed), işletme yükünü ortadan kaldırır ama veriyi bir üçüncü tarafa gönderir. KVKK açısından bu, veri işleyen sözleşmesi, veri yerleşimi ve yurt dışı aktarım hükümlerini tetikler. Türk şirketleri için soru şu olur: gözlemlenebilirlik verisi (özellikle içerik loglanıyorsa) AB'de mi, ABD'de mi, nerede işleniyor? Bu, model seçiminde olduğu gibi, bir uyum kararı.

Sahada gördüğüm dengeli yaklaşım: OTel ile enstrümante edin (taşınabilir kalın), metadata'yı yönetilen bir hizmete gönderebilirsiniz ama hassas içeriği kendi barındırdığınız katmanda tutun. Bu hibrit, hem işletme kolaylığını hem KVKK uyumunu dengeler. Ve OTel kullandığınız için, yarın karar değişirse geçiş enstrümantasyonu yeniden yazmayı gerektirmez — sadece hedefi değiştirirsiniz.

LLM sistemleri güçlü ama opak. Bir HTTP servisi gibi "ya çalışır ya çalışmaz" değil; sessizce, sinsice yanlış olabilir. Bu opaklığı kıran tek şey gözlemlenebilirlik. Token, maliyet, gecikme, kalite, versiyon — bu boyutları görebilen ekip sistemini yönetir; göremeyen ekip ise sistemin insafına kalır.

2026'da bu alan olgunlaştı. OTel GenAI semantic conventions bir standart getirdi, büyük platformlar bunu benimsedi, açık kaynak araçlar erişilebilir oldu ve ekosistem birleşti. Artık teknik engel yok; geriye sadece disiplin kalıyor. En kritik hattınızı enstrümante edin, metadata'yı her zaman logla, içeriği KVKK dengesiyle logla, prompt ve modeli versiyonla, SLO'lar tanımla ve uyarıları kur. Bu adımları atan şirket, LLM sistemlerini bir kara kutu olmaktan çıkarır ve yönetilebilir bir mühendislik varlığına dönüştürür.

Sahadan son sözüm şu değil ama son ilkem şu: iyi mühendislik, görebildiğin şeyi yönetmekle başlar. LLM dünyasında görmek, gözlemlenebilirlik demek. Bugün ölçmeye başlayın; çünkü ölçtüğünüz gün, sistemi gerçekten anlamaya başladığınız gündür ve o anlayış, hem maliyetinizi hem kalitenizi hem de kullanıcınızın güvenini korur.

Unutmayın: gözlemlenebilirlik bir kerelik kurulum değil, işleyen bir kültürdür. En iyi ekipler, her yeni özelliği enstrümantasyonla birlikte tasarlar, her regresyonu bir uyarıyla yakalar ve her üretim vakasını bir öğrenmeye çevirir. Bu kültürü kuran şirket, LLM sistemlerini büyütürken kontrolü asla kaybetmez. Kurmayan ise her ölçek artışında yeni bir kör noktayla yüzleşir. Seçim sizin: sistemi ölçen mi olacaksınız, yoksa sistemin sizi şaşırtmasını mı bekleyeceksiniz? Sahada kazananlar her zaman ölçenler oldu. Ve bu ölçüm kültürünü bugün, sistem henüz küçükken kurmak, yarın devasa bir sistemde sonradan eklemekten çok daha kolay ve çok daha ucuzdur.