Startup LLM Güvenliği: Ürünün İlk 90 Günü İçin Plan

Startup LLM güvenliği ilk 90 günde neyi hedeflemeli?

Hedef mükemmel güvenlik değil, savunulabilir bir başlangıç noktasıdır. Müşteriye, yatırımcıya ve ileride bir denetçiye "neyi neden yaptık" diye gösterebileceğiniz kanıtlar üretilir. Aşağıdaki plan, iki ya da üç kişilik bir mühendislik ekibinin haftada birkaç saat ayırarak yürütebileceği şekilde kurgulanmıştır.

İngiltere NCSC'nin Kasım 2023'te yayımladığı güvenli yapay zekâ sistemi geliştirme yönergeleri de yaşam döngüsünü dört aşamada ele alır: güvenli tasarım, güvenli geliştirme, güvenli dağıtım ve güvenli işletim. 90 günlük plan bu dört aşamanın küçük bir ekibe uyarlanmış halidir.

Mimari kararları baştan almak ucuzdur. Ajanın araç erişimini sonradan daraltmak, en baştan dar kurmaktan çok daha pahalıdır.

İlk 30 günde tehdit modeli nasıl yazılır?

Tehdit modeli, ürünün neyi, kimden ve nasıl koruduğunu yazar. Küçük ekip için bir sayfa yeterlidir. Dört soruyla başlayın: Ne üzerinde çalışıyoruz? Ne ters gidebilir? Buna karşı ne yapacağız? Yeterince iyi yaptık mı?

LLM ürünlerinde saldırı yüzeyini büyük ölçüde güven sınırları belirler. Kullanıcı girdisi talimat taşıyabilir. Belgeler, e-postalar ve web sayfaları dolaylı talimat taşıyabilir. Model, araç çağrısıyla gerçek eylem yapar.

Daha sistematik bir yöntem arıyorsanız STRIDE-LLM tehdit modelleme yazısı klasik STRIDE'ı LLM risklerine bağlar. Aynı ay içinde veri sınıflandırmasını da yapın: herkese açık, dahili, müşteri verisi ve özel nitelikli kişisel veri. Her sınıf için hangi verinin modele gidebileceğini yazın.

Hangi asgari kontroller 60. güne kadar kurulmalı?

Asgari kontroller, kısa sürede kurulabilen ve riski en çok azaltan önlemlerdir. Önerilen sıra:

1. Sırları koddan çıkarın, sır yönetim hizmeti kullanın, API anahtarlarını ortam ve servis bazında ayırın.
2. Modelin eriştiği her aracı ve veri kaynağını listeleyin, gerekmeyeni kapatın.
3. Para hareketi, silme ve dış paylaşım gibi kritik işlemleri insan onayına bağlayın.
4. Model çıktısını doğrudan çalıştırmayın, araç parametrelerini sunucu tarafında şemaya göre doğrulayın.
5. Kullanıcı ve oturum başına istek ve token sınırı koyun, harcama uyarısı tanımlayın.
6. İstem ve yanıt kayıtlarını açın, kişisel veriyi kayda yazmadan önce maskeleyin.
7. Sağlayıcının veri saklama ve eğitim kullanımı şartlarını okuyun ve yazılı teyit alın.

Ajan yapılarında en büyük risk, modelin gereğinden fazla yetkiyle çalışmasıdır. Kimlik ve yetki tasarımı için ajan yetki matrisi ve en az ayrıcalık yazısından yararlanabilirsiniz. Hazır bir güvenlik ürünü almak ile kendiniz kurmak arasındaki seçim de bu dönemde gündeme gelir. Karar çerçevesi için LLM güvenliğinde build vs buy yazısına bakın.

Kişisel veri ve yurt dışı sağlayıcı konusu neden erken çözülmeli?

Ürün kişisel veri işliyorsa ve model yurt dışındaki bir sağlayıcıda çalışıyorsa, her istek potansiyel bir yurt dışı aktarımdır. Bu durum 6698 sayılı Kanun'un 2024'te değişen 9. maddesine tabidir. Yeterlilik kararı yoksa standart sözleşme gibi uygun güvencelerden biri gerekir. Standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kurul'a bildirilir. Bu adımlar ürün yayına girdikten sonra fark edilirse geriye dönük düzeltmek zordur.

İki süre daha tasarımı etkiler. İlgili kişi başvuruları, Kanun'un 13. maddesine göre en geç otuz gün içinde sonuçlandırılır. Bu yüzden bir kullanıcının konuşma geçmişini bulup silebilmeniz gerekir. Kişisel veri ihlali ise 12. maddeye göre "en kısa sürede" Kurul'a bildirilir. Kurul'un 2019/10 sayılı kararı bu süreyi ihlalin öğrenilmesinden itibaren en geç 72 saat olarak yorumlar.

En ucuz güvenlik önlemi veri minimizasyonudur. Sağlayıcıya göndermediğiniz veri orada sızmaz. Modele yalnızca görevin gerektirdiği alanları gönderin, kimlik ve iletişim bilgilerini maskeleyin, konuşma geçmişini gerekenden uzun tutmayın. Sağlayıcıların saklama ve eğitim politikalarını karşılaştırmak için LLM sağlayıcısı veri saklama politikası yazısına bakın. Kişisel veri işleyen her ürün için hukuk desteği alın.

Ürün çıkmadan önce hangi testler yapılmalı?

Yayın öncesi test, OWASP'ın LLM uygulamaları için 2025 listesindeki maddelerden ürününüze uyanları kapsamalıdır. Küçük bir ekip için en az şu senaryolar denenir:

• Doğrudan ve dolaylı istem enjeksiyonu (LLM01:2026).
• Hassas bilgi ifşası, özellikle başka kullanıcının verisi (LLM02:2026).
• Aşırı yetki: modelin araçlarla izin verilmeyen bir işlem yapması (LLM03:2026).
• Sistem istemi sızıntısı (LLM08:2026).
• Sınırsız tüketim: maliyeti patlatan uzun ya da tekrarlı istekler (LLM06:2026).

Her saldırıyı birkaç kez deneyin, çünkü model aynı girdiye her seferinde aynı yanıtı vermez. Bulguları kaydedin, kritik olanları yayından önce kapatın. Başarılı saldırıları küçük bir regresyon kümesine dönüştürün ve her model ya da istem değişikliğinde yeniden çalıştırın.

Olay planı bir sayfaya nasıl sığar?

Küçük ekip için olay planı bir sayfadır ve şu soruları cevaplar: Olayı kim yönetir? Sağlayıcı anahtarını kim, nasıl iptal eder? Hangi kayıtlara bakılır ve kayıtlar ne kadar tutulur? Müşteriye ne zaman, hangi kanalla bilgi verilir? Kişisel veri ihlalinde Kurul bildirimini kim hazırlar?

Planı en az bir kez, iki saatlik bir masa başı tatbikatla deneyin. Senaryo olarak gerçek ürününüzü kullanın, örneğin asistanın başka bir müşterinin verisini göstermesi. Tatbikatın nasıl kurulacağı yapay zekâ olay tatbikatı yazısında anlatılır.

Yatırımcı ve kurumsal müşteri hangi soruları sorar?

Teknik inceleme ve kurumsal satış görüşmelerinde benzer sorular gelir:

• Müşteri verisi hangi sağlayıcılara ve hangi ülkelere gidiyor?
• Veri model eğitiminde kullanılıyor mu?
• Tek sağlayıcıya bağımlılık nasıl yönetiliyor, yedek plan var mı?
• Ürün öncesi güvenlik testi yapıldı mı, kritik bulgular kapatıldı mı?
• Olay planı var mı, en son ne zaman denendi?
• Ajan işlemlerinde insan onayı nerede devreye giriyor?
• KVKK ve AB pazarı için hangi yükümlülükler takip ediliyor?

Cevapları iki sayfalık bir güvenlik özeti dosyasında toplayın. Yapılan işi, açık kalan riskleri ve planlanan adımları dürüstçe yazın. Olmayan bir kontrolü var gibi göstermek, ilk teknik incelemede itibar kaybına dönüşür.

90. günün sonunda elde ne olmalı?

Üçüncü ayın sonunda şu kontrol listesinin tamamı işaretlenmiş olmalıdır:

• Tehdit modeli yazıldı ve ekip tarafından okundu.
• Veri sınıfları belirlendi, sağlayıcıya giden veri sınırlandı.
• Sırlar kodun dışında, anahtarlar en dar yetkili.
• Modelin araç ve veri erişimi listelendi, gereksizler kapatıldı.
• Kritik işlemler insan onayına bağlı.
• Kayıt tutma açık, kişisel veri kayıtta maskeli.
• Yurt dışı aktarım ve sağlayıcı sözleşmesi hukukla değerlendirildi.
• Ürün öncesi test yapıldı, kritik bulgular kapatıldı, regresyon kümesi hazır.
• Olay planı yazıldı ve bir kez denendi.
• Yatırımcı ve müşteri soruları için güvenlik özeti hazır.

Bu noktadan sonra güvenlik bir süreklilik işidir. Her yeni özellik, araç ya da model değişikliği tehdit modelini etkiler. Değişiklik yönetimi ve regresyon testi, hızlı ürün geliştirmede güvenliği korumanın en ucuz yoludur.

Sık Sorulan Sorular

Startup LLM ürününde ilk güvenlik adımı nedir?

İlk adım bir sayfalık tehdit modelidir: ürün hangi veriyi işliyor, model hangi araçlara erişiyor, dış içerik nereden giriyor ve en kötü senaryo nedir? Bu çalışma iki saatlik bir toplantıyla çıkarılabilir. Sonraki tüm kontrollerin önceliğini belirler ve gereksiz araç alımını önler. Her yeni araç ya da veri kaynağı eklendiğinde güncellenir.

Küçük bir ekip güvenlik için neye öncelik vermeli?

Önce sır yönetimi, modelin araç ve veri erişimini daraltmak, kritik işlemler için insan onayı, araç parametrelerinin sunucuda doğrulanması, istek ve token sınırı ve kişisel veriyi maskeleyen kayıt tutma gelir. Bunlar düşük maliyetli ve yüksek etkili kontrollerdir. Gelişmiş izleme ve hazır güvenlik ürünleri bu temel kurulduktan sonra değerlendirilir.

Yurt dışındaki bir LLM API'sine kişisel veri göndermek sorun mu?

Kişisel veri yurt dışındaki bir sağlayıcıya gidiyorsa bu, 6698 sayılı Kanun'un 9. maddesi kapsamında yurt dışına aktarımdır. Yeterlilik kararı yoksa standart sözleşme gibi bir uygun güvence gerekir ve standart sözleşme imzadan sonra beş iş günü içinde Kurul'a bildirilir. En kolay yol, kişisel veriyi modele göndermeden önce maskelemek ve hukuk desteği almaktır.

Yatırımcılar yapay zekâ güvenliği hakkında ne sorar?

Sık sorulanlar şunlardır: müşteri verisi hangi sağlayıcılara gidiyor, veri eğitimde kullanılıyor mu, tek sağlayıcıya bağımlılık nasıl yönetiliyor, ürün öncesi güvenlik testi yapıldı mı, olay planı var mı ve ajan işlemlerinde insan onayı nerede devreye giriyor? Cevapları bir güvenlik özeti dosyasında toplayın. Olmayan bir kontrolü var gibi göstermeyin.

Güvenlik testi ürün çıkmadan önce yapılmalı mı?

Evet, en azından temel bir test yapılmalıdır. Doğrudan ve dolaylı istem enjeksiyonu, sistem istemi sızıntısı, hassas bilgi ifşası, aşırı yetki ve sınırsız tüketim senaryoları denenir. Bulgular kayda geçer, kritik olanlar yayından önce kapatılır. Aynı testler küçük bir regresyon kümesine dönüştürülür ve her model ya da istem değişikliğinde yeniden çalıştırılır.

Kaynaklar

• NCSC: Guidelines for secure AI system development
• OWASP GenAI Security Project: Top 10 for LLM Applications 2025
• Mevzuat Bilgi Sistemi: 6698 sayılı Kişisel Verilerin Korunması Kanunu
• KVKK: Veri İhlali Bildirimi ve 2019/10 sayılı Kurul Kararı

İlgili Yazılar

• STRIDE-LLM: Yapay Zeka Sistemleri İçin Tehdit Modelleme Çerçevesi Klasik STRIDE'ı OWASP LLM Top 10, ASI Top 10 ve MITRE ATLAS'a bağlamak
• LLM Güvenliğinde Build vs Buy: Kendi Guardrail'ini Yazmak mı, Hazır Çözüm mü? Gerçek mühendislik verisiyle 2026 karar rehberi
• AI Güvenlik Olgunluk Modeli: Kurumunuzun Yapay Zeka Güvenliği Hangi Seviyede? 5 seviye x 6 boyut: AltaySec çerçevesiyle öz-değerlendirme
• LLM Sağlayıcı Veri Saklama Politikaları Karşılaştırması