LLMOps Nedir? Kurumsal Yapay Zekâ Yönetimi Rehberi

LLMOps neden ortaya çıktı?

MLOps yıllardır makine öğrenmesi modellerinin veri hazırlama, eğitim, sürümleme, deployment ve monitoring süreçlerini yönetmek için kullanılıyor. Büyük dil modelleri ise bu yapıya yeni değişkenler ekledi.

Bir üretken yapay zekâ uygulamasında davranış yalnızca model koduyla belirlenmez. Sonuç üzerinde şu bileşenlerin tamamı etkili olabilir:

• kullanılan model ve model sürümü,
• system prompt,
• kullanıcı promptu,
• model parametreleri,
• RAG ile getirilen bağlam,
• embedding modeli,
• chunking stratejisi,
• vektör veritabanındaki içerikler,
• kullanılan araçlar ve API'ler,
• güvenlik politikaları,
• çıktı sonrası işleme adımları.

Örneğin model değiştirilmeden yalnızca system promptun güncellenmesi bile uygulamanın davranışını değiştirebilir. Benzer şekilde RAG sistemindeki belge koleksiyonunun güncellenmesi cevap kalitesini etkileyebilir.

Bu nedenle üretim ortamındaki LLM uygulamalarında yalnızca kod sürümünü takip etmek yeterli değildir.

LLMOps, MLOps ve DevOps arasındaki fark nedir?

Bu kavramlar birbirinin alternatifi değildir. Genellikle aynı sistem içerisinde birlikte kullanılırlar.

Microsoft, üretken yapay zekâ operasyonlarını MLOps'un uzmanlaşmış bir uzantısı olarak ele alırken güncel terminolojide GenAIOps ifadesini de kullanmaktadır [1]. Bu nedenle sektörde LLMOps ve GenAIOps terimleri bazı bağlamlarda birbirinin yerine kullanılabilir.

LLMOps ise özellikle büyük dil modeli tabanlı sistemlere odaklanan daha dar bir kavramdır.

LLMOps yaşam döngüsü nasıl çalışır?

Tek bir evrensel LLMOps mimarisi bulunmaz. Ancak kurumsal sistemlerde yaşam döngüsü genellikle birkaç temel aşamadan oluşur.

1. Kullanım senaryosunun tanımlanması

İlk adım model seçmek değil, sistemin neyi başarması gerektiğini tanımlamaktır.

Örneğin:

• müşteri sorularını yanıtlamak,
• teknik dokümanlardan bilgi bulmak,
• sözleşmeleri sınıflandırmak,
• yazılım geliştirme ekiplerine yardımcı olmak,
• kurumsal veriler üzerinden soru-cevap yapmak.

Başarı kriterleri kullanım senaryosuyla birlikte belirlenmelidir.

“Cevapları iyi olsun” ölçülebilir bir kriter değildir.

Bunun yerine şu sorular cevaplanabilir:

• Yanıt hangi kaynaklara dayanmalı?
• Hangi sorulara cevap verilmemeli?
• Maksimum kabul edilebilir gecikme nedir?
• İnsan onayı hangi işlemlerde zorunlu?
• Bir isteğin maksimum maliyeti ne olabilir?

2. Model seçimi

En büyük veya en yeni model her kullanım senaryosu için doğru seçim olmayabilir.

Model seçerken birlikte değerlendirilmesi gereken değişkenler vardır:

• görev başarısı,
• gecikme,
• maliyet,
• bağlam penceresi,
• araç kullanma yetenekleri,
• veri işleme koşulları,
• güvenlik gereksinimleri,
• sağlayıcı bağımlılığı.

Bu nedenle model seçimi yalnızca benchmark sonuçlarına göre yapılmamalıdır. Kurumun kendi kullanım senaryolarından oluşturduğu değerlendirme veri seti üzerinde test edilmelidir.

3. Prompt yönetimi

Promptlar üretken yapay zekâ uygulamalarında kod kadar kritik bir konfigürasyon katmanı hâline gelebilir.

Üretimde kullanılan promptların mümkün olduğunca sürümlenmesi gerekir.

Örneğin:

support-system-prompt-v1.3
invoice-extraction-prompt-v2.1
product-assistant-prompt-v4.0

Her değişiklik için en azından şu bilgiler tutulabilir:

• prompt sürümü,
• değişiklik tarihi,
• değişikliğin amacı,
• kullanılan model,
• değerlendirme sonucu,
• production deployment tarihi.

Böylece kalite düşüşü görüldüğünde hangi değişikliğin etkili olduğu araştırılabilir.

Evaluation: LLMOps'un merkezindeki süreç

LLM sistemlerinde en kritik problemlerden biri “Bu sürüm gerçekten daha iyi mi?” sorusudur.

Bir geliştiricinin birkaç örnek prompt deneyip cevapları beğenmesi yeterli bir test yöntemi değildir.

Üretime çıkmadan önce temsil edici bir evaluation dataset oluşturulmalıdır.

Bu veri seti gerçek kullanım senaryolarını temsil eden girdiler içermelidir.

Örneğin kurumsal bilgi asistanında:

Soru:
İade süresi kaç gündür?

Beklenen kaynak:
iade-politikasi.pdf

Değerlendirme kriterleri:
- doğru kaynağı kullanıyor mu?
- süreyi doğru söylüyor mu?
- kaynakta olmayan bilgi ekliyor mu?
- yanıt anlaşılır mı?

Google Cloud'un üretken yapay zekâ değerlendirme yaklaşımında da değerlendirme süreçleri model değişiklikleri, prompt düzenlemeleri ve fine-tuning gibi geliştirme faaliyetlerinin ölçülmesinde kullanılmaktadır [3].

Değerlendirmeler üç ana yöntemle yapılabilir.

Programatik değerlendirme

Belirli çıktılar kodla doğrulanabilir.

Örneğin:

• JSON formatı geçerli mi?
• zorunlu alanlar mevcut mu?
• yasaklı kelimeler bulunuyor mu?
• cevap belirli bir formatı takip ediyor mu?

LLM-as-a-judge

Başka bir model, çıktıyı tanımlanan rubriğe göre değerlendirebilir.

Örneğin:

• doğruluk,
• alaka,
• kaynakla uyum,
• talimatlara uyum,
• üslup.

Ancak LLM tabanlı değerlendiriciler de hatalı sonuç verebildiğinden kritik uygulamalarda tek kontrol mekanizması olarak kullanılmamalıdır.

İnsan değerlendirmesi

Özellikle yüksek riskli veya uzmanlık gerektiren kullanım senaryolarında insan değerlendirmesi önemini korur.

NIST'in üretken yapay zekâ risk yönetimi profili, üretken yapay zekâ sistemlerinin yaşam döngüsü boyunca risklerin tanımlanmasını, ölçülmesini, yönetilmesini ve izlenmesini öneren kapsamlı bir çerçeve sunmaktadır [4].

Production monitoring nasıl yapılır?

LLM uygulamasını üretime almak operasyonun sonu değil, başlangıcıdır.

Google Cloud, üretken yapay zekâ uygulamalarının yalnızca altyapı seviyesinde değil, uygulamanın girdileri, çıktıları ve ara bileşenleri dahil olmak üzere uçtan uca izlenmesini önermektedir [5].

Tipik olarak izlenebilecek metrikler şunlardır:

Teknik metrikler

• istek sayısı,
• hata oranı,
• timeout oranı,
• model latency,
• retrieval latency,
• tool çağrı süreleri.

Kullanım metrikleri

• input token,
• output token,
• model çağrısı sayısı,
• tool çağrısı sayısı,
• kullanıcı başına kullanım.

Kalite metrikleri

• görev başarı oranı,
• kaynakla uyumluluk,
• instruction adherence,
• kullanıcı geri bildirimi,
• retrieval başarısı,
• başarısız cevap kategorileri.

Maliyet metrikleri

• istek başına maliyet,
• kullanıcı başına maliyet,
• görev başına maliyet,
• model bazında toplam tüketim.

Bu metriklerin tek başına izlenmesi yeterli değildir. Belirli eşikler için alarm mekanizmaları kurulmalıdır.

Örneğin:

p95 latency > belirlenen SLA
→ uyarı

istek başına token tüketimi > maliyet eşiği
→ uyarı

evaluation başarısı < kabul kriteri
→ deployment durdur

retrieval başarısızlığı > belirlenen oran
→ RAG pipeline incele

Observability neden klasik monitoring'den daha önemlidir?

Monitoring sistemin sağlıklı olup olmadığını gösterirken observability, sistemin neden belirli şekilde davrandığını anlamaya yardımcı olur.

Bir LLM uygulamasında tek kullanıcı isteği şu zinciri oluşturabilir:

Kullanıcı
↓
API
↓
Prompt oluşturma
↓
Embedding
↓
Vector search
↓
Reranking
↓
LLM
↓
Tool çağrısı
↓
LLM
↓
Final cevap

Yalnızca final cevabı loglamak, hatanın nerede oluştuğunu anlamaya yetmeyebilir.

Bu nedenle trace üzerinde şu bilgiler tutulabilir:

request_id
model_version
prompt_version
retrieved_documents
tool_calls
latency
token_usage
evaluation_score

Google Cloud'un güncel observability dokümantasyonu da LLM ve agent sistemlerinde log, metric ve trace verilerinin hata analizi, maliyet takibi ve davranış incelemesi için birlikte kullanılmasını önermektedir [6].

RAG sistemlerinde LLMOps

Retrieval-Augmented Generation kullanılan sistemlerde operasyon yükü daha da artar.

Çünkü yalnızca LLM değil, retrieval pipeline da yönetilmelidir.

İzlenebilecek bileşenler arasında şunlar bulunur:

• embedding modeli,
• chunk boyutu,
• chunk overlap,
• vektör veritabanı,
• metadata filtreleri,
• retrieval algoritması,
• reranker,
• top-k değeri,
• kaynak belgeler.

Örneğin bir chatbot yanlış cevap verdiğinde sorun modelden kaynaklanmayabilir.

Asıl hata:

yanlış belge
↓
yanlış chunk
↓
yanlış context
↓
yanlış cevap

zincirinde oluşmuş olabilir.

Bu nedenle RAG uygulamalarında evaluation iki seviyede düşünülmelidir:

Doğru belgeler getiriliyor mu?

Generation evaluation

Model getirilen belgeleri doğru kullanıyor mu?

Bu ayrım yapılmadığında ekipler retrieval problemine model problemi gibi yaklaşabilir.

Model ve prompt değişiklikleri nasıl yönetilmeli?

LLM sağlayıcıları zaman içinde yeni model sürümleri yayımlayabilir veya mevcut modelleri değiştirebilir. Aynı şekilde kurum kendi promptlarını, retrieval altyapısını veya tool setini güncelleyebilir.

Bu nedenle değişiklikler doğrudan production ortamına gönderilmemelidir.

Daha güvenli bir pipeline şu şekilde kurulabilir:

Değişiklik
↓
Offline Eval
↓
Güvenlik Testleri
↓
Staging
↓
Canary / Kontrollü Trafik
↓
Production
↓
Continuous Monitoring

Deployment öncesinde eski ve yeni sürüm aynı evaluation dataset üzerinde karşılaştırılabilir.

Örneğin:

Model A + Prompt v4
vs.
Model B + Prompt v5

Karşılaştırmada yalnızca kalite değil;

• latency,
• token tüketimi,
• maliyet,
• güvenlik,
• tool başarısı

gibi kriterler de değerlendirilmelidir.

Güvenlik LLMOps'un neden parçasıdır?

LLM tabanlı uygulamalar klasik web uygulamalarından farklı saldırı yüzeylerine sahiptir.

OWASP'ın 2025 LLM uygulamaları risk listesinde prompt injection, hassas bilgi ifşası, supply-chain riskleri, data/model poisoning, improper output handling, excessive agency, system prompt leakage, vector/embedding zafiyetleri, misinformation ve unbounded consumption gibi riskler yer almaktadır [7].

Özellikle agent sistemlerinde risk daha yüksektir.

Bir model yalnızca metin üretmek yerine:

• e-posta gönderebiliyor,
• veritabanına yazabiliyor,
• dosya silebiliyor,
• API çağırabiliyor,
• ödeme süreci başlatabiliyorsa,

model çıktısı doğrudan sistem aksiyonuna dönüşebilir.

Bu nedenle kritik araçlarda:

• least privilege,
• allowlist,
• işlem limitleri,
• insan onayı,
• audit log,
• sandboxing

gibi kontroller uygulanmalıdır.

Veri gizliliği ve KVKK

LLMOps yalnızca teknik operasyon değildir. Veri yönetişimi de yaşam döngüsünün parçasıdır.

Türkiye'de Kişisel Verileri Koruma Kurumu, üretken yapay zekâ sistemlerinin kişisel veri işleme faaliyetlerini 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında ele alan özel bir rehber yayımlamıştır. Rehber; üretken yapay zekâ sistemlerinin yaşam döngüsü boyunca kişisel veri işleme faaliyetlerinin değerlendirilmesini, mahremiyetin korunmasını ve veri sorumlularının yükümlülüklerini ele almaktadır [8].

Bu nedenle production loglarına kontrolsüz biçimde prompt ve response kaydetmek riskli olabilir.

Örneğin prompt içerisinde:

müşteri adı
telefon
e-posta
TC kimlik numarası
sağlık bilgisi
finansal veri

bulunabilir.

Loglama politikası oluşturulurken:

• hangi verilerin kaydedileceği,
• hangi alanların maskeleneceği,
• logların ne kadar tutulacağı,
• kimlerin erişebileceği,
• hangi sistemlere aktarılacağı

açık biçimde belirlenmelidir.

Avrupa Birliği AI Act ve LLMOps

Avrupa Birliği AI Act kapsamında general-purpose AI (GPAI) sağlayıcılarına yönelik yükümlülükler 2 Ağustos 2025'te uygulanmaya başladı. Bunlar arasında teknik dokümantasyon, downstream sağlayıcılara bilgi sağlanması, telif politikaları ve eğitim içeriğine ilişkin özet yayımlanması gibi yükümlülükler bulunuyor. Sistemik risk taşıyan GPAI modelleri için risk değerlendirmesi, olay raporlama ve siber güvenlik gibi ek yükümlülükler söz konusu [9].

Avrupa Komisyonunun bu yükümlülükleri uygulama yetkileri ise 2 Ağustos 2026 itibarıyla devreye girdi [10].

Bu hükümler her LLM kullanan şirketin otomatik olarak bir GPAI sağlayıcısı olduğu anlamına gelmez. Kurumun AI Act kapsamındaki rolü ve yükümlülükleri kullanım biçimine göre ayrıca değerlendirilmelidir.

Ancak operasyonel açıdan bakıldığında model envanteri, teknik dokümantasyon, risk kayıtları, değerlendirme sonuçları ve değişiklik geçmişi tutmak regülasyonlara hazırlık açısından önemli bir LLMOps pratiğidir.

LLMOps maliyet yönetimi

LLM sistemlerinin maliyet yapısı klasik uygulamalardan farklı olabilir.

Maliyet yalnızca sunucu kapasitesinden oluşmaz.

Toplam maliyet içerisinde şunlar bulunabilir:

LLM inference
embedding
vector database
reranking
tool/API çağrıları
observability
evaluation
storage
network

Özellikle agent sistemlerinde tek kullanıcı isteği birden fazla model çağrısı oluşturabilir.

Bu nedenle yalnızca “aylık API faturası” izlemek yerine birim ekonomi takip edilmelidir.

Örneğin:

müşteri talebi başına maliyet
başarılı görev başına maliyet
kullanıcı başına maliyet
1.000 işlem başına maliyet

Bu yaklaşım farklı modellerin ekonomik etkisini karşılaştırmayı kolaylaştırır.

Kurumsal LLMOps mimarisi nasıl kurulabilir?

Tipik bir yapı aşağıdaki katmanlardan oluşabilir:

Kullanıcı / Uygulama
        ↓
AI Gateway
        ↓
Prompt / Agent Layer
        ↓
Model Router
   ↙            ↘
Model A        Model B
        ↓
RAG / Tools / APIs
        ↓
Observability
        ↓
Evaluation
        ↓
Governance & Security

Buradaki önemli nokta belirli bir ürünü kullanmak değil, operasyonel sorumlulukların ayrıştırılmasıdır.

Model sağlayıcısının değişmesi durumunda bütün sistemin yeniden yazılmasını gerektiren mimariler uzun vadede sağlayıcı bağımlılığını artırabilir.

LLMOps için hangi roller gerekir?

Ekibin büyüklüğü projeye göre değişir. Küçük ekiplerde aynı kişi birden fazla sorumluluğu üstlenebilir.

Tipik sorumluluk alanları şunlardır:

AI/ML Engineer

Model entegrasyonu, evaluation, RAG ve model davranışı.

Software Engineer

API, backend, deployment ve uygulama entegrasyonları.

Data Engineer

Veri pipeline'ları, veri kalitesi ve retrieval altyapısı.

Platform/DevOps Engineer

CI/CD, altyapı, monitoring ve güvenilirlik.

Security / Compliance

Erişim, veri güvenliği, risk ve mevzuat kontrolleri.

Domain Expert

Model cevaplarının gerçek iş bağlamındaki doğruluğunu değerlendirir.

Özellikle değerlendirme veri setlerinin hazırlanmasında domain uzmanlarının katılımı önemlidir.

Temsili kurumsal senaryo

Aşağıdaki örnek tamamen temsili bir senaryodur.

Bir üretim şirketinin teknik dokümanlardan soru cevaplayan bir yapay zekâ asistanı geliştirdiğini düşünelim.

İlk PoC aşamasında ekip birkaç PDF'i vektör veritabanına yükler ve bir LLM'e bağlar.

Demo başarılı görünür.

Ancak production kullanımında:

• bazı belgeler güncellenir,
• eski dokümanlar sistemde kalır,
• kullanıcılar beklenmeyen sorular sorar,
• model sağlayıcısı değiştirilir,
• token tüketimi yükselir.

LLMOps uygulanmadığında ekip hangi değişikliğin kaliteyi etkilediğini anlamakta zorlanabilir.

Daha kontrollü yapı şu şekilde kurulabilir:

Doküman güncellemesi
↓
Versiyonlama
↓
Index oluşturma
↓
Retrieval Eval
↓
Generation Eval
↓
Staging
↓
Production
↓
Monitoring

Her production isteğinde model, prompt ve retrieval sürümü trace edilebilir.

Bir hata raporlandığında ekip:

request_id
→ prompt
→ retrieved chunks
→ model
→ tool calls
→ response

zincirini inceleyebilir.

Böylece problem yalnızca “model yanlış cevap verdi” seviyesinde kalmaz; hatanın hangi katmanda oluştuğu araştırılabilir.

Başarı nasıl ölçülür?

LLMOps başarısı yalnızca uptime ile ölçülmemelidir.

Dört farklı boyut birlikte takip edilebilir.

Önemli olan kurum için kabul kriterlerinin deployment öncesinde tanımlanmasıdır.

Sık yapılan LLMOps hataları

Yalnızca model çıktısını izlemek

Hatanın retrieval, prompt veya tool katmanında oluşabileceği gözden kaçar.

Promptları sürümlememek

Bir değişiklikten sonra performans düşerse hangi sürümün soruna neden olduğu belirlenemez.

Eval dataset oluşturmamak

Model değişiklikleri sistematik olarak karşılaştırılamaz.

Sadece ortalama latency izlemek

p95 ve p99 gibi yüksek yüzdelik değerler kullanıcıların yaşadığı gecikmeleri daha iyi gösterebilir.

Production loglarına kontrolsüz veri yazmak

Prompt ve cevaplar kişisel veya ticari açıdan hassas bilgiler içerebilir.

Her problemde daha büyük modele geçmek

Kalite problemi retrieval veya prompt kaynaklıysa daha pahalı model kullanmak temel problemi çözmeyebilir.

Model değişikliğini yazılım güncellemesinden bağımsız görmek

Model sürümü değişikliği de production davranışını değiştiren bir deployment olarak değerlendirilmelidir.

LLMOps hangi durumlarda gereksiz olabilir?

Her LLM denemesi için kapsamlı bir LLMOps platformu kurmak gerekli değildir.

Örneğin:

• kısa süreli prototipler,
• kişisel deneyler,
• production'a çıkmayacak PoC'ler,
• hassas veri içermeyen düşük riskli testler

için ağır operasyon altyapısı gereksiz olabilir.

Ancak sistem gerçek kullanıcılarla buluşuyor, kurumsal veri kullanıyor, otomatik aksiyon alıyor veya iş süreçlerini etkiliyorsa izleme ve değerlendirme ihtiyacı hızla artar.

LLMOps uygulama kontrol listesi

Production'a çıkmadan önce aşağıdaki sorular cevaplanabiliyor olmalıdır:

• Kullanım senaryosunun ölçülebilir başarı kriterleri tanımlandı mı?
• Production modelinin ve sürümünün kaydı tutuluyor mu?
• Promptlar sürümleniyor mu?
• Temsil edici evaluation dataset mevcut mu?
• Deployment öncesi eval otomatik çalışıyor mu?
• RAG kullanılıyorsa retrieval ayrıca değerlendiriliyor mu?
• Token ve maliyet ölçülüyor mu?
• Latency ve hata oranları izleniyor mu?
• Prompt injection testleri yapılıyor mu?
• Hassas veriler loglarda maskeleniyor mu?
• Tool yetkileri minimum seviyede mi?
• Kritik işlemlerde insan onayı bulunuyor mu?
• Her isteğin trace edilebilir bir request ID'si var mı?
• Model değişiklikleri kontrollü deployment sürecinden geçiyor mu?
• Rollback mekanizması mevcut mu?
• Production çıktılarından sürekli evaluation yapılabiliyor mu?
• Incident müdahale prosedürü tanımlandı mı?

Bu soruların önemli bölümü cevaplanamıyorsa sistem teknik olarak production'da çalışıyor olsa bile operasyonel olgunluğu sınırlı olabilir.

Sonuç

LLMOps, büyük dil modeli tabanlı uygulamaları bir prototipten sürdürülebilir üretim sistemine dönüştüren operasyon disiplinidir.

Temel amaç yalnızca modeli çalıştırmak değildir. Model, prompt, veri, retrieval, araçlar ve uygulama katmanının birlikte nasıl davrandığını ölçmek; değişiklikleri kontrollü biçimde yayımlamak ve sistemin kalite, maliyet, güvenlik ve mevzuat gereksinimlerini zaman içinde koruyabilmektir.

Küçük bir PoC için kapsamlı bir LLMOps altyapısı gerekmeyebilir. Ancak gerçek kullanıcıları, kurumsal verileri veya otomatik aksiyonları içeren sistemlerde değerlendirme, gözlemlenebilirlik, sürümleme ve yönetişim artık ikincil operasyon işleri değil, sistem tasarımının parçasıdır.

Sık Sorulan Sorular

LLMOps nedir?

LLMOps, büyük dil modeli tabanlı uygulamaların geliştirme, test, deployment, değerlendirme, monitoring, güvenlik ve sürekli iyileştirme süreçlerini yöneten yöntem ve araçlar bütünüdür.

LLMOps ile MLOps arasındaki fark nedir?

MLOps genel makine öğrenmesi sistemlerine odaklanırken LLMOps; prompt yönetimi, üretken çıktı değerlendirmesi, RAG, token maliyetleri ve LLM'e özgü güvenlik riskleri gibi ek süreçleri kapsar.

LLMOps için özel bir platform kullanmak zorunlu mu?

Hayır. LLMOps belirli bir ürün değil, operasyon yaklaşımıdır. Git, CI/CD, logging, tracing ve evaluation araçları birleştirilerek de uygulanabilir.

LLM uygulamalarında monitoring neden yeterli değildir?

Monitoring sistemin hata, latency ve kaynak tüketimini gösterebilir. Ancak LLM sistemlerinde model, prompt, retrieval ve tool davranışlarının neden belirli bir sonuç ürettiğini anlayabilmek için daha ayrıntılı observability ve tracing gerekir.

Promptlar neden sürümlenmelidir?

Prompt değişiklikleri uygulamanın davranışını doğrudan değiştirebilir. Sürümleme sayesinde hangi promptun hangi model ve evaluation sonuçlarıyla production'a çıktığı takip edilebilir.

LLM evaluation nasıl yapılır?

Programatik testler, LLM tabanlı değerlendiriciler ve insan değerlendirmesi birlikte kullanılabilir. Test veri setinin gerçek kullanım senaryolarını temsil etmesi gerekir.

RAG sistemlerinde ayrıca LLMOps gerekir mi?

Evet. RAG uygulamalarında modelin yanında embedding, chunking, retrieval, reranking ve kaynak belgeler de production davranışını etkiler. Bu nedenle retrieval ve generation ayrı ayrı değerlendirilmelidir.

Küçük şirketlerin LLMOps kurması gerekir mi?

LLMOps'un kapsamı sistemin riskine göre ayarlanabilir. Küçük bir ekip basit sürümleme, evaluation, logging ve maliyet takibiyle başlayabilir; sistem büyüdükçe otomasyon seviyesi artırılabilir.

Kaynaklar

[1] Microsoft — MLOps and GenAIOps for AI Workloads on Azure — Son güncelleme: 18 Kasım 2024
Microsoft Learn – MLOps and GenAIOps for AI Workloads on Azure
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Üretken yapay zekâ iş yüklerinin nondeterministik yapısı, GenAIOps/MLOps ilişkisi, otomasyon ve monitoring gereksinimleri.

[2] Microsoft — LLMOps: Operational Management of LLMs
Microsoft Learn – LLMOps Operational Management of LLMs
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: LLMOps tanımı ve LLM uygulamalarının geliştirme, deployment ve bakım yaşam döngüsü.

[3] Google Cloud — Gen AI Evaluation Service Overview
Google Cloud – Gen AI Evaluation Service Overview
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Üretken yapay zekâ modellerinin veri odaklı değerlendirilmesi; prompt değişiklikleri, model geçişleri ve fine-tuning süreçlerinde evaluation kullanımı.

[4] NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) — 26 Temmuz 2024; güncelleme: 8 Nisan 2026
NIST – Generative Artificial Intelligence Profile
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Üretken yapay zekâ yaşam döngüsü boyunca risk tanımlama, değerlendirme ve yönetim yaklaşımı.

[5] Google Cloud — Deploy and Operate Generative AI Applications
Google Cloud – Deploy and Operate Generative AI Applications
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Üretken yapay zekâ uygulamalarında uçtan uca logging, monitoring, lineage ve continuous evaluation.

[6] Google Cloud — Observability in Google Cloud
Google Cloud – Observability in Google Cloud
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: LLM ve agent uygulamalarında log, metric, trace, token kullanımı ve latency üzerinden gözlemlenebilirlik.

[7] OWASP GenAI Security Project — OWASP Top 10 for LLM Applications 2025 — 17 Kasım 2024
OWASP – Top 10 for LLM Applications 2025
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Prompt injection, sensitive information disclosure, excessive agency, vector/embedding zafiyetleri ve diğer LLM güvenlik riskleri.

[8] Kişisel Verileri Koruma Kurumu — Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)
KVKK – Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: Üretken yapay zekâ yaşam döngüsünde kişisel veri işleme, veri sorumluluğu, mahremiyet ve 6698 sayılı Kanun çerçevesindeki değerlendirmeler.

[9] European Commission — General-purpose AI Obligations under the AI Act
European Commission – General-purpose AI Obligations under the AI Act
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: GPAI sağlayıcılarının teknik dokümantasyon, telif politikası ve eğitim içeriği özeti yükümlülükleri ile sistemik riskli modeller için ek gereksinimler.

[10] European Commission — Guidelines on Obligations for General-Purpose AI Providers
European Commission – Guidelines on GPAI Provider Obligations
Erişim tarihi: 28 Eylül 2026
Desteklediği konu: GPAI yükümlülüklerinin 2 Ağustos 2025'te uygulanmaya başlaması ve Avrupa Komisyonunun tam uygulama yetkilerinin 2 Ağustos 2026 itibarıyla devreye girmesi.