BİGR uyumlu yapay zeka mimarisi: kamu kurumlarında veri sınıfına göre model seçimi

BİGR uyum ve denetim yetkisi artık Siber Güvenlik Başkanlığı'nda

Bilgi ve İletişim Güvenliği Rehberi'nin (BİGR) uyum, denetim ve gözetim faaliyetleri Siber Güvenlik Başkanlığı bünyesinde yürütülmektedir. Kamu kurumlarının bilgi işlem birimlerine Şubat 2026'da duyurulduğu üzere, bu faaliyetler daha önce Cumhurbaşkanlığı Dijital Dönüşüm Ofisi tarafından koordine ediliyordu; devir işleminin dayanağı olarak 177 sayılı Cumhurbaşkanlığı Kararnamesi ve 7545 sayılı Siber Güvenlik Kanunu gösterilmiştir. Rehber uyum çalışmalarının izlendiği BİGDES sistemi ise hizmet vermeye devam etmektedir. Piyasadaki birçok danışmanlık içeriği hâlâ eski kurumu adres gösterdiği için, kurumların yazışma ve denetim muhatabını güncellemesi gerekir.

Rehberin kapsamı yapay zeka projelerini doğrudan ilgilendirir. Rehber kendi ifadesiyle "bilgi işlem birimi barındıran veya bilgi işlem hizmetlerini sözleşmeler çerçevesinde üçüncü taraflardan alan, devlet teşkilatı içerisinde yer alan kurum ve kuruluşlar ile kritik altyapı hizmeti veren işletmeleri" kapsar. Yapay zeka yazılımı kiralama veya hizmet alımı yoluyla dışarıdan temin edilen bir çözüm de, kurum içinde geliştirilen bir çözüm de bu kapsamın dışında değildir.

BİGR, yapay zeka veya büyük dil modeli başlığı taşıyan ayrı bir bölüm içermez. Bu bir boşluk değil, tasarım tercihidir: Rehberin hedefleri arasında "güvenlik tedbirlerinin ürün ve teknoloji bağımsız olarak uygulanabilir olması" açıkça sayılmıştır. Dolayısıyla bir LLM entegrasyonu, kendisine özgü yeni bir tedbir seti aramak yerine mevcut tedbir başlıkları altına yerleştirilerek değerlendirilir: Bulut Bilişim Güvenliği, Kişisel Verilerin Güvenliği, Uygulama ve Veri Güvenliği, Yeni Geliştirmeler ve Tedarik, Tedarikçi İlişkileri Güvenliği ile İz ve Denetim Kayıtlarının Tutulması ve İzlenmesi başlıkları bu iş için yeterlidir.

Rehber yaşayan bir doküman olarak sürekli güncellenmektedir. Bu yazıda tedbir madde numaraları yerine tedbir başlık adları kullanılmıştır; kurumlar uygulayacakları sürümü ve o sürümdeki madde numaralandırmasını Siber Güvenlik Başkanlığı'ndan teyit etmelidir.

• Uyum, denetim ve gözetim muhatabı: Siber Güvenlik Başkanlığı
• Devrin dayanağı olarak gösterilen mevzuat: 177 sayılı Cumhurbaşkanlığı Kararnamesi ve 7545 sayılı Siber Güvenlik Kanunu
• Rehberin kaynağı olan düzenleme: 6 Temmuz 2019 tarih ve 30823 sayılı Resmî Gazete'de yayımlanan 2019/12 sayılı Cumhurbaşkanlığı Genelgesi
• Rehber uyum çalışmalarının izlendiği sistem: BİGDES
• Rehberin hazırlık sürecinde 16 Bakanlık ile 51 kurum ve kuruluştan 240 uzmanın katkısı alınmıştır

Veri gizlilik derecesine göre yapay zeka mimarisi eşlemesi

Kamu kurumları tek bir yapay zeka mimarisi kararı veremez. BİGR'nin çalışma mantığı, aynı kurumun farklı veri sınıfları için farklı güvenlik tedbirleri uygulamasını gerektirir; bu mantık model erişim mimarisine doğrudan yansır. Rehberin tanımlar bölümü gizlilik dereceli bilgi/veriyi "bilmesi gereken kişiler dışındakilere açıklanması veya verilmesi, millî güvenlik ve ülke menfaatleri bakımından sakıncalı görülen ve haiz olduğu önem derecelerine göre 'ÇOK GİZLİ', 'GİZLİ', 'ÖZEL' veya 'HİZMETE ÖZEL' şeklinde sınıflandırılan bilgi/veri" olarak tanımlar. Bu dört derece, artı gizlilik derecesi taşımayan kişisel veri, tasnif dışı veri ve anonim veri, pratikte yedi ayrı mimari kararı üretir.

Eşlemenin dayanağı Rehberin Bulut Bilişim Güvenliği bölümüdür. Bu bölümdeki "Bulut Hizmeti Kullanımı" tedbiri şu ifadeyle başlar: "Kritik verilerin yurt içinde depolandığı ve yurt dışında barındırılmayacağı garanti altına alınmalıdır." Aynı bölüm ayrıca kritik veri barındıran bulut sistemlerinde kaynakların kurum dışı kaynaklarla aynı fiziksel cihaz üzerinde bulundurulmamasını, şifreleme anahtarlarının hizmeti alan kurum tarafından yönetilmesini ve operatör erişimlerinde trafiğin yurt içinde kalmasına yönelik tedbirler uygulanmasını arar. Bir LLM çağrısı, verinin başka bir tarafın işlem ortamına aktarılması anlamına geldiği için bu tedbirlerin kapsamındadır.

Aşağıdaki tablo, kurumların kendi sınıflandırma politikalarını model mimarisine çevirirken kullanabileceği bir çalışma çerçevesidir. Hukuki bir tespit değildir; her satırın kurumun kendi varlık grubu kritiklik derecelendirmesi ve hukuk biriminin değerlendirmesiyle doğrulanması gerekir.

Varlık grubu kritiklik derecelendirmesini yapay zeka projesine uygulama

BİGR uyumu, tedbir listesini baştan sona uygulamakla değil, her varlık grubunun kritiklik derecesine karşılık gelen tedbir seviyesini uygulamakla sağlanır. Rehber şunu belirtir: "Her bir varlık grubunun kritiklik derecesi, işlenen verinin gizlilik, bütünlük ve erişilebilirlik açısından kritikliği ile oluşabilecek güvenlik ihlallerinin etki alanları dikkate alınarak belirlenecektir." Bir yapay zeka projesinde bu cümlenin pratik karşılığı şudur: modelin ne kadar yetenekli olduğu değil, modele giden verinin ne olduğu ve ihlal hâlinde kimin etkileneceği belirleyicidir.

Rehber altı varlık grubu ana başlığı tanımlar: Ağ ve Sistemler, Uygulamalar, Taşınabilir Cihaz ve Ortamlar, Nesnelerin İnterneti (IoT) Cihazları, Fiziksel Mekânlar ve Personel. Bir LLM entegrasyonu neredeyse her zaman Uygulamalar ana başlığı altında konumlanır; modeli çağıran servis, kurum içi bir uygulamadır. Rehberin kendi örneklerinde uygulama varlık grupları "kritik veri işleyen kurum içi uygulama" ile "kritik veri işlemeyen kurum içi uygulama" olarak ayrılmıştır. Yapay zeka projelerinde de doğru yaklaşım tek bir "yapay zeka uygulaması" varlık grubu tanımlamak değil, işlenen veri sınıfına göre en az iki ayrı varlık grubu tanımlamaktır.

Kritiklik derecesi, Rehberin ekinde yer alan sekiz soruluk Varlık Grubu Kritiklik Derecelendirme Anketi ile hesaplanır. Anket puanı 18'den küçükse Derece 1, 18 ile 28 arasındaysa Derece 2, 28 ve üzerindeyse Derece 3 belirlenir. Anket, gizlilik, bütünlük ve erişilebilirlik boyutlarının yanında bağımlı varlıklar, etkilenen kişi sayısı, kurumsal sonuçlar, sektörel etki ve toplumsal sonuçlar boyutlarını da ölçer. Rehber anketin Delfi metodu ile, varlık sahipleri ve sistem yöneticilerinin katılımıyla doldurulmasını önerir.

Kritiklik derecesi doğrudan tedbir seviyesine çevrilir. Rehberin ifadesiyle: Derece 1 olan varlık gruplarına temel seviye tedbirler; Derece 2 olanlara temel seviyeye ek olarak orta seviye tedbirler; Derece 3 olanlara temel ve orta seviyeye ek olarak ileri seviye tedbirler uygulanır. Kritik bilgi/veri tanımı da bu zincire bağlıdır: Rehber, kritiklik derecesi 3 olarak hesaplanan varlıkların işlediği verileri ve 6698 sayılı Kanun'da tanımlanan özel nitelikli kişisel verileri kritik veri sayar. Bir yapay zeka uygulaması Derece 3 çıkıyorsa, Bulut Bilişim Güvenliği bölümünün ileri seviye tedbiri devreye girer ve kritik verinin kurum dışı kaynaklarla aynı fiziksel cihazda bulunmaması aranır. Bu tek cümle, çok kiracılı bir yurt dışı çıkarım hizmetini pratikte devre dışı bırakır.

• Adım 1: Yapay zeka çözümünü Uygulamalar varlık grubu ana başlığı altında konumlandırın
• Adım 2: İşlenen veri sınıfına göre ayrı varlık grupları tanımlayın, tek bir grup altında toplamayın
• Adım 3: Her grup için sekiz soruluk kritiklik anketini paydaş katılımıyla doldurun
• Adım 4: Puanı 18 ve 28 eşiklerine göre Derece 1, 2 veya 3'e çevirin
• Adım 5: Dereceye karşılık gelen temel, orta ve ileri seviye tedbirleri listeleyin
• Adım 6: Bulut Bilişim Güvenliği ile Kişisel Verilerin Güvenliği başlıklarını uygulanabilirlik matrisinde işaretleyin

LLM entegrasyonunda varlık envanterine ve iz kaydına girmesi gerekenler

Kamu kurumları bir LLM entegrasyonunu tek bir yazılım kalemi olarak envantere yazamaz. Rehberin Yazılım Varlıklarının Envanter Yönetimi başlığı, envanterde en az yazılımın adı, sürümü, yayımcısı, destek alınan tedarikçi sözleşme bilgileri, lisans bilgileri, edinim tarihi ve yazılımın yüklendiği donanımların kayıt altına alınmasını ve envanterdeki değişikliklerin izlenebilir olmasını ister. Bir dil modeli entegrasyonunda bu alanların karşılıkları alışılmışın dışındadır: sürüm bilgisi model kimliğidir, yayımcı model sağlayıcısıdır, edinim tarihi ise modelin kataloğa alındığı tarihtir. Model sürümleri sağlayıcı tarafından güncellendiği için, envanterin hangi model kimliğinin hangi tarihte kullanıldığını gösterecek şekilde tutulması gerekir.

İz kaydı tasarımı bu yazının en çok hata yapılan başlığıdır. Rehber iz kaydını "operasyonel bir işlemin başlangıcından bitişine kadar adım adım takip edilmesini sağlayacak kayıtlar", denetim kaydını ise "bir bilgi varlığına kimin eriştiğini veya erişmeye çalıştığını ve erişim sağlayan kullanıcının hangi işlemleri gerçekleştirdiğini gösteren kayıtlar" olarak tanımlar. Detaylı kayıt tutulmasına ilişkin tedbir; olay açıklaması, olay kaynağı, olay zamanı, kullanıcı/sistem bilgisi, kaynak adresleri, hedef adresleri ve işlem detaylarının tutulmasını ve bütünlüğün zaman damgası ile korunmasını arar.

Bu gereklilikler prompt metninin loglanmasını gerektirmez. Aksine, prompt gövdesinin kullanım veya faturalama veri tabanına yazılması yeni bir risk üretir: gizlilik dereceli veri, sınıflandırma etiketini kaybederek düşük korumalı bir log deposuna kopyalanmış olur. Rehberin kayıtların saklama süresi boyunca yetkisiz erişime ve değişime karşı korunmasını isteyen tedbiri, bu durumda log deposunun da kaynak sistemle aynı kritiklik derecesine çekilmesini gerektirir. Doğru tasarım, denetim izini içerikten ayırmaktır: kim, ne zaman, hangi model kimliğiyle, kaç token ve hangi maliyetle çağrı yaptı sorularının cevabı kayda geçer; ne yazdığı geçmez.

Prompt içeriğinin incelenmesi gereken durumlar için ayrı bir mekanizma kurulmalıdır. Bir güvenlik olayı incelemesi veya model kalitesi değerlendirmesi içerik gerektiriyorsa, bu içerik kaynak uygulamanın kendi kritiklik derecesine sahip ayrı bir depoda, sınırlı saklama süresiyle ve ayrı yetkilendirmeyle tutulmalıdır. Kullanım ve faturalama akışıyla aynı yerde tutulması, en düşük korumaya sahip sistemin veri sınıfını belirlemesine yol açar.

• Envantere girmeli: model kimliği ve sürümü, sağlayıcı adı, kataloğa alınma tarihi, sözleşme ve destek kapsamı
• Envantere girmeli: gateway veya aracı servisin kendisi, çalıştığı sunucu ve ağ segmenti
• Envantere girmeli: her birim için tanımlanmış API anahtarları, sahipleri ve geçerlilik durumu
• Envantere girmeli: prompt şablonları ve bunları güncelleme yetkisi olan personel
• İz kaydına girmeli: çağrı zamanı, çağıran birim ve kullanıcı kimliği, model kimliği, token sayıları, maliyet, hata kodu
• İz kaydına girmemeli: prompt metni, model yanıt gövdesi, yüklenen dosya içerikleri
• Ayrı ve daha korumalı depoda tutulmalı: olay incelemesi için gereken içerik örnekleri

Tedarikçi değerlendirmesi: yapay zeka sağlayıcısına sorulacak sorular

BİGR, tedarikçi ilişkilerini denetlenebilir bir başlık olarak ele alır. Tedarikçi İlişkileri Güvenliği başlığı; tedarikçilerin kurum varlıklarına erişimiyle ilgili riskleri azaltacak bir politika tanımlanmasını, kurum varlıklarına erişebilen, işleyebilen, depolayabilen veya iletebilen her tedarikçiyle yapılacak sözleşmelere bilgi güvenliği gereksinimlerinin eklenmesini, tedarik zinciri güvenliğinin temin edileceğine dair yazılı belge alınmasını ve kabul kriterlerinin önceden belirlenerek yüklenici ile üzerinde anlaşılmasını ister. Demo ve kavram ispatı çalışmaları için ayrıca gizlilik taahhütnamesi imzalanmasını arar; bu, yapay zeka pilotlarında sık atlanan bir adımdır.

Yeni Geliştirmeler ve Tedarik başlığı, alınan ürünün sorumlu birimin onayıyla envantere eklenmesini, fonksiyonel ve fonksiyonel olmayan testlere yönelik süreçlerin tanımlı olmasını ve alt yüklenici ile çalışılması hâlinde işletilecek politikaların belirlenmiş olmasını gerektirir. Aynı başlık, tedarik edilen ürünlerde Türkçe dil desteği olanların tercih edilmesini de arar. Yapay zeka hizmet alımlarında alt yüklenici sorusu özellikle önemlidir: bir gateway sağlayıcısı, model sağlayıcılarını fiilen alt yüklenici konumunda kullanır ve bu zincirin sözleşmede görünür olması gerekir.

Bulut Bilişim Güvenliği bölümünün denetim soruları, tedarikçi görüşmesinde doğrudan kullanılabilecek bir soru seti sunar. Rehberin önerdiği denetim yöntemleri mülakat, gözden geçirme, güvenlik denetimi, sızma testi ve kaynak kod analizi olmak üzere beş başlıkta tanımlanmıştır; yapay zeka tedarikinde ilk üçü çoğu durumda uygulanabilir. Aşağıdaki sorular bu tedbir başlıklarından türetilmiştir ve teknik şartnameye taşınabilir.

• İstek ve yanıt verileri hangi ülkede işleniyor? Türkiye'de barındırılan modeller için işlemenin yurt içinde kaldığı sözleşmeyle taahhüt ediliyor mu?
• Prompt metni ve model yanıtı sağlayıcının kullanım, faturalama veya analiz veri tabanlarına yazılıyor mu? Yazılmıyorsa bu, denetlenebilir bir teknik açıklamayla belgeleniyor mu?
• Girdiler model eğitiminde kullanılıyor mu? Kullanılmıyorsa bu taahhüt sözleşmede yer alıyor mu?
• Müşteri API anahtarları nasıl saklanıyor? Düz metin mi, özet (hash) değeri olarak mı tutuluyor?
• Her birim için ayrı anahtar, ayrı kullanım tavanı ve ayrı kullanım raporu tanımlanabiliyor mu?
• Alt yüklenici zinciri nedir? Hangi model sağlayıcıları devrede ve bu liste değiştiğinde kurum bilgilendiriliyor mu?
• Hizmet sonlandırıldığında kuruma ait tanımlar ve veriler geri getirilemeyecek şekilde siliniyor mu?
• Kurumun kendi denetiminde talep edebileceği kullanım kaydı formatı nedir ve hangi alanları içerir?
• Hizmet seviyesi taahhütleri ölçülüyor ve raporlanabiliyor mu?

LLMTR'nin veri sınıfına göre model seçimindeki yeri

LLMTR, bu yazıdaki eşleme tablosunun tek bir entegrasyon üzerinden uygulanabilmesini hedefleyen bir gateway platformudur. Kurumun asıl mimari zorluğu, farklı veri sınıfları için farklı model barındırma modellerine ihtiyaç duyulması ve her biri için ayrı entegrasyon, ayrı anahtar yönetimi, ayrı kullanım raporu kurulmasının maliyetidir. LLMTR'de Türkiye'de barındırılan modeller ile global sağlayıcı modelleri aynı OpenAI uyumlu /v1 yüzeyinden çağrılır; kurum bir veri sınıfını yurt içi modele, diğerini global modele yönlendirirken yalnızca model kimliğini değiştirir.

Türkiye'de barındırılan model kataloğu şu an sekiz modeli içerir: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/medgemma-4b, llmtr/trendyol-7b, llmtr/magibu-11b-v8, llmtr/embeddinggemma-300m, llmtr/qwen3-5-4b ve llmtr/ornith-1-35b. Bu modellerin çıkarımı Türkiye'de işlenir. Bu, kurumun kendi kritiklik derecelendirmesinin yerine geçmez; ancak yurt içi işleme gerektiren veri sınıfları için değerlendirilebilir bir seçenek sunar ve aynı katalogda kalarak tasnif dışı veri için global modele geçiş imkânını korur.

Denetim izi tarafında platformun tasarımı bu yazıdaki ayrımı izler. Kullanıcı promptları ve model yanıt gövdeleri kullanım ve faturalama veri tabanına yazılmaz; kayıt, hangi anahtarın hangi modeli hangi token miktarıyla ve hangi maliyetle çağırdığı bilgisini taşır. Müşteri API anahtarları düz metin olarak değil SHA-256 özet değeri olarak saklanır, sağlayıcı API anahtarları yalnızca ortam değişkeninde tutulur. Her birim ayrı bir API anahtarı, kendi hız sınırı, kendi harcama tavanı ve kendi kullanım raporunu alabilir; bu, iç denetimin birim bazında kullanım sorgulamasını mümkün kılar.

Ticari model açısından tek not şudur: kredi yüklemede %8 platform marjı uygulanır, model fiyatlarına marj eklenmez. Bu ayrım, yapay zeka yazılımı kiralama veya hizmet alımı kalemlerinde maliyet öngörüsü yapan satın alma birimleri için önemlidir; birim maliyet sağlayıcının ilan ettiği token fiyatıdır.

Aşağıdaki örnek, veri sınıfına göre yönlendirmenin ve prompt gövdesi taşımayan denetim kaydının uygulama tarafında nasıl göründüğünü gösterir.

Veri sınıfına göre model yönlendirme ve prompt içermeyen denetim kaydı

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://llmtr.com/v1",
    api_key=os.environ["LLMTR_API_KEY"],  # birim bazlı anahtar
)

# Eşleme kurumun sınıflandırma politikasından gelir, kodda sabitlenmez.
MODEL_BY_DATA_CLASS = {
    "hizmete_ozel": "llmtr/gemma-4",        # Türkiye'de barındırılan
    "kisisel_veri": "llmtr/qwen3-6-35b",    # Türkiye'de barındırılan
    "tasnif_disi": os.environ["GLOBAL_MODEL_ID"],
}

BLOCKED = {"cok_gizli", "gizli", "ozel"}


def complete(data_class: str, messages: list) -> str:
    if data_class in BLOCKED:
        raise PermissionError(
            "Gizlilik dereceli veri dış model çağrısına gönderilemez."
        )

    response = client.chat.completions.create(
        model=MODEL_BY_DATA_CLASS[data_class],
        messages=messages,
    )

    # Denetim izi: model, token ve maliyet yazılır; prompt gövdesi yazılmaz.
    write_audit_record(
        unit=os.environ["UNIT_CODE"],
        data_class=data_class,
        model=response.model,
        prompt_tokens=response.usage.prompt_tokens,
        completion_tokens=response.usage.completion_tokens,
    )

    return response.choices[0].message.content

Kaynaklar

Bu yazıdaki mevzuat referansları aşağıdaki birincil kaynaklardan doğrulanmıştır. Son kontrol: 13 Ağustos 2026.

Bilgi ve İletişim Güvenliği Rehberi yaşayan bir doküman olarak güncellenmektedir. Bu yazıda tedbir madde numaraları yerine tedbir başlık adları kullanılmıştır; kurumlar uygulayacakları güncel sürümü ve o sürümdeki madde numaralandırmasını Siber Güvenlik Başkanlığı'ndan teyit etmelidir.

Bu içerik bilgilendirme amaçlıdır, hukuki görüş niteliği taşımaz. Nihai değerlendirme kurumun uyum ve hukuk birimlerinin kararıdır.

• Bilgi ve İletişim Güvenliği Rehberi, tam metin — mevzuat.comu.edu.tr
• BİGR uyum, denetim ve gözetim faaliyetlerinin Siber Güvenlik Başkanlığı'na devredilmesi duyurusu — bid.deu.edu.tr
• Bilgi ve İletişim Güvenliği Rehberi ile formlar ve şablonlar sayfası — siberguvenlik.gov.tr
• 7545 sayılı Siber Güvenlik Kanunu metni — tbmm.gov.tr
• 2019/12 sayılı Cumhurbaşkanlığı Genelgesi, 6 Temmuz 2019 tarih ve 30823 sayılı Resmî Gazete — resmigazete.gov.tr
• BİGDES rehber uyum izleme sistemi — bigdes.cbddo.gov.tr
• 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin yurt dışına aktarılmasını düzenleyen 9. madde — kvkk.gov.tr

BİGR perspektifinden bir yapay zeka projesini değerlendirme

Kamu kurumlarının bir büyük dil modeli entegrasyonunu Bilgi ve İletişim Güvenliği Rehberi'nin varlık grubu ve kritiklik derecelendirme mantığıyla değerlendirmesi için izlenecek adımlar.

1. İşlenecek veriyi gizlilik derecesine göre sınıflandırın. Projede modele gidecek her veri akışını ÇOK GİZLİ, GİZLİ, ÖZEL, HİZMETE ÖZEL, gizlilik derecesi taşımayan kişisel veri, tasnif dışı kurumsal veri ve anonim veri başlıkları altında ayrıştırın. Bu ayrım tek bir tabloya yazılmalı; sonraki tüm adımlar bu tablodan türer. Aynı uygulamanın farklı ekranlarının farklı sınıfa girebileceğini varsayarak akış bazında çalışın.
2. Yapay zeka bileşenlerini varlık grubu ana başlıkları altına yerleştirin. Modeli çağıran servisi Uygulamalar, modeli veya gateway'i barındıran altyapıyı Ağ ve Sistemler, prompt şablonlarını güncelleyen ve çıktıyı değerlendiren personeli Personel ana başlığı altında konumlandırın. İşlenen veri sınıfı farklıysa aynı ana başlık altında birden fazla varlık grubu tanımlayın; farklı güvenlik seviyesi gerektiren varlıkları aynı grupta toplamayın.
3. Her varlık grubu için kritiklik derecelendirme anketini uygulayın. Rehberin ekinde yer alan sekiz soruluk Varlık Grubu Kritiklik Derecelendirme Anketini, varlık sahipleri, sistem yöneticileri, geliştiriciler ve kullanıcı temsilcilerinin katılımıyla doldurun. Rehber, uzlaşıya varılana kadar Delfi metodunun tekrarlanmasını önerir. Anket puanını 18 ve 28 eşiklerine göre Derece 1, 2 veya 3'e çevirin ve sonucu Rehberin ilgili formuna kaydedin.
4. Tedbir seviyesini belirleyin ve uygulanabilirlik matrisini doldurun. Derece 1 için temel, Derece 2 için temel ve orta, Derece 3 için temel, orta ve ileri seviye tedbirleri listeleyin. Her varlık grubu için Bulut Bilişim Güvenliği, Kişisel Verilerin Güvenliği, Kripto Uygulamaları Güvenliği ve Yeni Geliştirmeler ve Tedarik başlıklarının uygulanabilir olup olmadığını işaretleyin. Mevcut durumu tamamen, çoğunlukla, kısmen, hiç veya uygulanamaz olarak değerlendirip boşluk analizini çıkarın.
5. Model erişim mimarisini veri sınıfına göre ayrıştırın. Sınıflandırma tablosundaki her satır için hedef mimariyi yazın: kapalı ağda çalışan model, kurum veri merkezinde barındırılan model, Türkiye'de barındırılan hizmet veya global sağlayıcı. Uygulama katmanında bu ayrımı teknik olarak zorunlu kılın; gizlilik dereceli akışların dış çağrı yoluna hiç girememesi için istek yönlendirmesine engelleyici kontrol koyun. Kararların gerekçesini kayda geçirin.
6. İz kaydı tasarımını, tedarikçi sözleşmesini ve kabul kriterlerini yazın. Denetim izinin hangi alanları taşıyacağını netleştirin: çağrı zamanı, birim, kullanıcı kimliği, model kimliği, token sayıları, maliyet ve hata kodu. Prompt gövdesinin kullanım ve faturalama kaydına yazılmayacağını yazılı hâle getirin. Tedarikçi sözleşmesine bilgi güvenliği gereksinimlerini, veri yerleşimi taahhüdünü, alt yüklenici zincirinin bildirimini ve hizmet sonlandırmada silme yükümlülüğünü ekleyin; kabul kriterlerini ve doğrulama yöntemlerini yüklenici ile önceden anlaşın.

Sık sorulan sorular

BİGR uyum, denetim ve gözetim faaliyetlerini hangi kurum yürütüyor?

Bilgi ve İletişim Güvenliği Rehberi'nin uyum, denetim ve gözetim faaliyetleri Siber Güvenlik Başkanlığı bünyesinde yürütülmektedir. Bu faaliyetler daha önce Cumhurbaşkanlığı Dijital Dönüşüm Ofisi tarafından koordine ediliyordu; devir kamu kurumlarının bilgi işlem birimlerine Şubat 2026'da duyurulmuş ve dayanak olarak 177 sayılı Cumhurbaşkanlığı Kararnamesi ile 7545 sayılı Siber Güvenlik Kanunu gösterilmiştir. Rehber uyum çalışmalarının izlendiği BİGDES sistemi hizmet vermeye devam etmektedir.

Bilgi ve İletişim Güvenliği Rehberi yapay zeka için ayrı bir bölüm içeriyor mu?

Hayır. Rehber yapay zeka veya büyük dil modeli başlığı taşıyan ayrı bir bölüm içermez. Rehberin tanımlı hedefleri arasında güvenlik tedbirlerinin ürün ve teknoloji bağımsız olarak uygulanabilir olması yer alır. Bu nedenle bir LLM entegrasyonu mevcut tedbir başlıkları altında değerlendirilir: Bulut Bilişim Güvenliği, Kişisel Verilerin Güvenliği, Uygulama ve Veri Güvenliği, Dış Sistem Entegrasyonlarının Güvenliği, Tedarikçi İlişkileri Güvenliği ile Yeni Geliştirmeler ve Tedarik başlıkları bu değerlendirme için kullanılır.

Gizlilik dereceli veri yurt dışındaki bir dil modeline gönderilebilir mi?

Rehberin Bulut Bilişim Güvenliği bölümündeki bulut hizmeti kullanımına ilişkin tedbir, kritik verilerin yurt içinde depolandığının ve yurt dışında barındırılmayacağının garanti altına alınmasını ister. Gizlilik dereceli veri işleyen bir varlık grubu tipik olarak yüksek kritiklik derecesine sahip olduğundan, bu sınıfta yurt dışı model çağrısı pratikte değerlendirme dışında kalır. Nihai değerlendirme kurumun kendi kritiklik derecelendirmesine ve hukuk biriminin kararına bağlıdır.

Bir LLM entegrasyonu hangi varlık grubu ana başlığı altında değerlendirilir?

Bir LLM entegrasyonu çoğunlukla Uygulamalar varlık grubu ana başlığı altında değerlendirilir, çünkü modeli çağıran bileşen kurum içi bir uygulamadır. Rehberin varlık grubu örneklerinde uygulamalar kritik veri işleyen ve işlemeyen olarak ayrılmıştır. Yapay zeka projelerinde de tek bir varlık grubu tanımlamak yerine, işlenen veri sınıfına göre en az iki ayrı varlık grubu tanımlanması önerilir; modeli barındıran altyapı ayrıca Ağ ve Sistemler ana başlığı altında ele alınır.

Prompt metni iz kaydına yazılmalı mı?

Rehberin detaylı kayıt tutulmasına ilişkin tedbiri; olay açıklaması, olay kaynağı, olay zamanı, kullanıcı/sistem bilgisi, kaynak ve hedef adresleri ile işlem detaylarının tutulmasını ister. Bu gereklilikler prompt gövdesinin loglanmasını gerektirmez. Prompt metninin kullanım veya faturalama veri tabanına yazılması, gizlilik dereceli verinin sınıflandırma etiketini kaybederek daha düşük korumalı bir depoya kopyalanmasına yol açar. Denetim izi kim, ne zaman, hangi model, kaç token ve hangi maliyet bilgilerini taşımalı; içerik gerekiyorsa ayrı yetkilendirmeli ve sınırlı saklama süreli ayrı bir depoda tutulmalıdır.

Kritiklik derecesi 3 olan bir varlık grubunda hangi tedbir seviyeleri uygulanır?

Rehberde Bölüm 3, 4 ve 5 altındaki her güvenlik tedbiri temel, orta ve ileri seviye olarak derecelendirilmiştir. Kritiklik derecesi 1 olan varlık gruplarına temel seviye tedbirler, derecesi 2 olanlara temel seviyeye ek olarak orta seviye tedbirler, derecesi 3 olanlara ise temel ve orta seviyeye ek olarak ileri seviye tedbirler uygulanır. Kritiklik derecesi, sekiz soruluk Varlık Grubu Kritiklik Derecelendirme Anketi puanına göre belirlenir: 18'in altı Derece 1, 18 ile 28 arası Derece 2, 28 ve üzeri Derece 3.

İlgili yazılar

• Kamu verisi bulutta saklanabilir mi? 2019/12 sayılı Genelge ve yapay zeka
• KVKK kamu kurumları uyum rehberi ve yapay zeka: Mart 2026 rehberi projeye nasıl uygulanır

• Türkiye'de barındırılan ve global model kataloğu
• Güvenlik ve veri işleme dokümanı
• Kullanım ve faturalama kayıtları
• Birim bazlı API anahtarı yönetimi