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
LLM güvenliğinde en pahalı hata, kararı sezgiyle vermektir. "Kendi guardrail'imizi yazarız" cümlesi ilk gün ucuz görünür; gizli maliyet kalemleri altı ay sonra ortaya çıkar. Bu rehber, hazır çözümle kendi çözümünü kıyaslamak için Türkçe'de az işlenen somut bir karar matrisi sunuyor.
Build vs Buy Nedir? Guardrail Kararının Tanımı
LLM güvenliğinde build vs buy, bir uygulamanın giriş/çıkış güvenlik katmanını (guardrail veya LLM firewall) kurum içinde sıfırdan geliştirme (build) ile hazır bir ürün/servis satın alma (buy) arasındaki stratejik seçimdir. Guardrail; prompt injection, veri sızıntısı, zararlı içerik ve yetki aşımı gibi saldırıları model çağrısının önünde ve arkasında filtreleyen kontrol katmanıdır. "Build" tarafında kural motorunu, sınıflandırıcıyı ve bakım hattını siz sahiplenirsiniz; "buy" tarafında bunları bir sağlayıcıdan API veya on-prem paket olarak kiralarsınız.
Karar, popüler inanışın aksine öncelikle bütçe kalemi değildir. Üç mühendislik değişkenine indirgenir: (1) kuralları güncel tutacak sürekli bakım kapasiteniz var mı, (2) Türkçe morfolojisi gibi dile özel bir saldırı yüzeyiniz baskın mı, (3) makine öğrenmesi (ML) modeli barındırma ve ayarlama iştahınız var mı? Bu üç sorunun cevabı, aşağıdaki matriste hangi tarafa oturduğunuzu belirler.
Build vs Buy Karar Matrisi
Aşağıdaki matris, kararı duygusal ("kendimiz yaparız daha iyi olur") değil, ölçütsel hale getirir. Bir satırda net biçimde bir tarafa yaslanıyorsanız o kolon lehine puan sayın; çoğunluk kazanır.
| Karar Ölçütü | Build (kendin yaz) lehine | Buy (hazır al) lehine |
|---|---|---|
| Ekipte adanmış güvenlik/ML mühendisi | Var, kalıcı | Yok veya paylaşımlı |
| Kural bakım döngüsü | Haftalık iterasyon yapabiliyoruz | Bakımı devretmek istiyoruz |
| Dile özel ihtiyaç (Türkçe morfoloji) | Çok özel, standart araç karşılamıyor | Sağlayıcı lokalize denetim sunuyor |
| Time-to-market baskısı | Düşük, öğrenerek ilerleyebiliriz | Yüksek, haftalar içinde canlı olmalı |
| Regülasyon/veri yerelliği (KVKK) | Tam kontrol şart, veri dışarı çıkmamalı | On-prem/self-host sunan ürün var |
| Toplam sahip olma maliyeti ufku | 3+ yıl amortize edilebilir | Sabit operasyonel gider tercihi |
| ML barındırma iştahı | GPU/inference işletebiliyoruz | Barındırmayı sağlayıcıya bırakırız |
Matrisin kritik dersi şudur: tek bir doğru cevap yoktur. Aynı kurum, düşük riskli bir iç aracı için "build" ederken müşteriye dokunan üretim sistemi için "buy" seçebilir. Karar, sistem başına verilir.
Kendi Guardrail'ini Yazmanın Gizli Maliyet Kalemleri
"Build" seçeneğinin ilk gün maliyeti aldatıcıdır: birkaç regex ve bir prompt ile çalışan bir prototip bir haftada ortaya çıkar. Gerçek maliyet, o prototipi üretime dayanıklı hale getirme yolculuğunda birikir. AltaySec'te geliştirdiğimiz Guardian guardrail motorunu, tek katmanlı regex'ten 114 testlik hibrit (regex + ML) bir mimariye (v3.1.0) taşırken karşılaştığımız kalemleri, dürüst bir maliyet haritası olarak paylaşıyoruz.
| Gizli Maliyet Kalemi | Neden ilk günde görünmez | Zamanla ne getirir |
|---|---|---|
| Kural bakımı | İlk 20-30 kural saldırıları yakalar gibi görünür | Her yeni jailbreak kalıbı yeni kural + regresyon testi ister; kural seti çürür |
| Türkçe morfoloji | İngilizce kalıp Türkçe'de birebir çalışmaz sanılır | Ekler, casefold, birleşik yazım ve varyantlar ayrı ayrı ele alınmalı |
| Over-refusal (aşırı reddetme) ayarı | Sıkı kural = güvenli sanılır | Masum istekleri bloklamak ürünü kullanılamaz kılar; hassas eşik ayarı sürekli iş |
| ML barındırma | Model bir kez eğitilir sanılır | Inference altyapısı, gecikme bütçesi, sürüm yönetimi ve GPU/CPU maliyeti kalıcı gider |
| Test/regresyon hattı | "Çalışıyor" gözlemi yeterli sanılır | Her değişiklik eski davranışı bozmasın diye kalıcı bir test seti (bizde 114 test) gerekir |
| Kaçırma/yanlış-pozitif ölçümü | Metrik olmadan da güvende hissedilir | Ölçmediğiniz kaçırma oranını iyileştiremezsiniz; kıyas veri seti kurmak gerekir |
Buradaki mesele "build imkânsız" demek değildir. Guardian'ın kendisi bir build çıktısıdır. Mesele, kararı verirken bu kalemlerin tamamının maliyet tablosunda görünür olmasıdır. Prototipi bir hafta sonu çıkaran ekip, o prototipin üretim guardrail'i olmadığını fark ettiğinde geri dönüş maliyeti yüksektir.
"Buy" Seçeneğinin Görünmeyen Tuzağı: Lokalizasyon Denetimi
Hazır çözüm satın almak "build" maliyetlerinin çoğunu ortadan kaldırır; ama kendi tuzağını taşır. Piyasadaki guardrail ve sınıflandırıcıların büyük çoğunluğu İngilizce veriyle eğitilmiştir. Türkçe saldırılar ise yalnızca çeviri değildir: morfolojik varyantlar, Türkçe casefold davranışı, kod-karıştırma (TR-EN) ve kültürel manipülasyon kalıpları farklı bir yüzey oluşturur.
AltaySec'in kendi ölçümünde (guardrail-arena, iki eksenli EN+TR guardrail kıyaslaması) hazır jailbreak sınıflandırıcılarının Türkçe saldırıların önemli bir bölümünü — ölçümümüzde yaklaşık %83'ünü — kaçırdığını gözlemledik. Bu, tek bir aracın zayıflığı değil, İngilizce-birinci eğitim setinin yapısal sonucudur. Pratik çıkarım nettir: "buy" kararı verirken sağlayıcının aracını kendi dilinizdeki gerçek saldırılarla denetlemeden imza atmayın. Lokalizasyon denetimi, satın alma sürecinin opsiyonel değil zorunlu adımıdır.
Bu ölçüm AltaySec'in kendi Türkçe morfolojik bypass ve Türkçe prompt injection kalıpları çalışmalarıyla tutarlıdır; genel-geçer bir sektör istatistiği olarak değil, denetlenebilir bir iç kıyas verisi olarak sunulmalıdır.
Üçüncü Yol: Satın Al ve Üzerine İnşa Et (Open-Core / Augment)
Build ve buy'ı ikili bir seçim gibi sunmak yanıltıcıdır. Olgun ekipler çoğu zaman üçüncü bir yolu tercih eder: çekirdeği satın al veya açık-kaynaktan al, dile özel katmanı kendin yaz.
- Hazır çözümü omurga yap: ML sınıflandırıcı, altyapı, gecikme yönetimi ve genel saldırı imzaları sağlayıcıdan gelsin.
- Türkçe katmanı içeride tut: morfolojik varyantlar, KVKK'ya özel PII maskeleme ve kurumunuza özel iş kuralları sizin sahipliğinizde kalsın.
- Sürekli ölç: hangi yolu seçerseniz seçin, kaçırma ve yanlış-pozitif oranını kendi kıyas setinizle düzenli ölçün. Ölçüm olmadan hiçbir guardrail "güvenli" ilan edilemez.
Bu hibrit yaklaşım, hazır çözümün hız avantajını korurken "buy" seçeneğinin lokalizasyon tuzağını kapatır. AltaySec'in Guardian yaklaşımı da bu felsefeye yakındır: hibrit (regex + ML) mimari, dile özel katmanı çekirdek motora yedirir.
Hangi Durumda Ne Seçmeli? Pratik Karar Rehberi
Matristen somut senaryolara inelim:
- Erken aşama ürün, küçük ekip, hızlı çıkış: Buy. Guardrail'i sıfırdan yazmak zamanınızı en yanlış yere harcamaktır; hazır çözüm alın, Türkçe denetimini yapın.
- KVKK/veri yerelliği kritik, veri dışarı çıkamaz: On-prem/self-host sunan bir çözümü buy edin ya da build'e hazırlanın. Bulut-yalnızca API'ler bu senaryoda elenir. Bkz. KVKK ve LLM güvenliği.
- Türkçe saldırı yüzeyi baskın ve çok özel: Hibrit yol. Çekirdeği alın, Türkçe morfoloji katmanını içeride sahiplenin.
- Adanmış güvenlik/ML ekibi, uzun ufuk, tam kontrol isteği: Build savunulabilir — ama gizli maliyet tablosunu bütçeye baştan yazın.
- Riski düşük iç araç: Basit bir build veya açık-kaynak guardrail yeterli; üretim seviyesi yatırım gereksizdir.
Kararınızı verdikten sonra guardrail'inizin gerçekten çalışıp çalışmadığını doğrulamak ayrı bir disiplindir; LLM red-teaming playbook'u ile kendi çözümünüzü kendi dilinizdeki saldırılarla test edin. AltaySec olarak, hem Guardian LLM firewall'ı hem de bağımsız guardrail denetimi tarafında bu kararı veren ekiplere destek veriyoruz — özellikle satın alınan çözümlerin Türkçe lokalizasyon denetiminde.
