Compliance by Construction Nedir?

Compliance by construction, düzenleyici zorunlulukların sistem tamamlandıktan sonra eklenen politika veya kontrol noktaları olarak değil, veri ve karar akışının zorunlu mimari katmanları olarak tasarlanması yaklaşımıdır; böylece belirli uyumsuz davranışlar yalnız yasaklanmaz, teknik olarak gerçekleştirilemez hâle getirilir.

Çalışmanın temel farkı buradadır. Geleneksel yaklaşımda sistem çalışır, ardından compliance ekipleri neyin izinli olup olmadığını kontrol eder. Bu mimaride ise veri, regülasyon gereği geçmesi gereken kapılardan fiziksel olarak geçmeden LLM’e ulaşamaz.

Benzer biçimde üretim durumunu değiştirecek eylemler için sadece “model bunu yapmamalı” şeklinde prompt kuralı yoktur. Sisteme bu işlemleri yapabilecek credential, tool binding veya execution path hiç verilmez.

Böylece bazı kontroller davranışsal değil yapısal hâle gelir.

Bankalarda LLM Destekli Incident Response Neden Farklıdır?

Bankalardaki LLM destekli olay müdahalesi; üretim loglarının hassas finansal veri içerebilmesi, prompt değişikliklerinin kontrollü değişiklik süreçlerine tabi olması, modellerin bağımsız doğrulama gerektirmesi, üçüncü taraf sağlayıcı riskinin yönetilmesi ve AI hizmeti kullanılamadığında operasyonun insanlarla devam edebilmesi zorunlulukları nedeniyle genel teknoloji şirketlerindeki uygulamalardan daha sıkı mimari sınırlar gerektirir.

SOX: Prompt da kontrollü değişikliktir

Kaynak, finansal raporlamayı etkileyebilecek sistemlerde kullanılan prompt şablonlarının sıradan metin değil, kontrollü üretim konfigürasyonu gibi ele alınması gerektiğini savunmaktadır.

Bu yaklaşımda:

• Her prompt sürümü kayıt altına alınır.
• Onay mekanizmasından geçer.
• Üretim dışı ortamda test edilir.
• Rollback planı bulunur.
• LLM etkileşimleri uzun süreli audit kayıtlarına girer.

PCI DSS: Telemetri hassas veri taşıyabilir

Kaynağa göre ödeme sistemlerinin logları PAN, CVV, authentication token, hesap numarası ve benzeri hassas içerik barındırabilir.

Bu nedenle LLM katmanından önce bağımsız bir sanitizasyon sınırı gerekir.

Kaynak buradaki hedefi “hassas veriyi azaltmak” değil, yetkisiz inference katmanına sıfır hassas veri geçirmek olarak tanımlamaktadır.

SR 11-7: LLM model risk yönetimine girebilir

Yazar, incident classification veya root-cause analysis yapan LLM’in model risk yönetimi kapsamında değerlendirilmesi gerektiğini savunmaktadır.

Bunun sonuçları:

• Teorik temel ve sınırlılıkların belgelenmesi.
• Hallüsinasyon davranışlarının tanımlanması.
• Bağımsız validation.
• Model inventory kaydı.
• Risk tiering.
• Sürekli performans monitoring.

FFIEC: Sistem LLM olmadan da çalışmalıdır

Kaynak, LLM’in olay müdahalesi için bir iyileştirici araç olması gerektiğini, operasyonun bağımlılık noktası olmaması gerektiğini savunmaktadır.

LLM API erişimi kesildiğinde veya model davranışı bozulduğunda sistem insan-only mode’a geçebilmelidir.

Prompt injection neden doğrudan güvenlik sorunudur?

Olay verisinin kendisinin saldırgan tarafından manipüle edilmiş olabileceği varsayılmaktadır.

Örneğin saldırgan, triage sistemine gireceğini bildiği bir hata mesajına AI’ya yönelik gizli talimat ekleyebilir.

Bu nedenle input validation, output sandboxing ve adversarial test, makalede opsiyonel iyileştirme değil launch requirement olarak ele alınmaktadır.

Altı katmanlı referans mimari

Kaynağın 5. sayfasındaki Şekil 1, sistemi altı ana katmana ayırmaktadır:

1. Signal Ingestion & Normalization
2. Data Sanitization Pipeline
3. Prompt Construction
4. LLM Inference
5. Human-in-the-Loop Decision Gate
6. Audit Trail

Altı Katmanlı Mimari Nasıl Çalışır?

Mimari; monitoring, tracing, logging ve incident-management kaynaklarından gelen sinyalleri normalize ederek başlar, hassas bilgileri sanitizasyon katmanında kaldırır, yalnız temizlenmiş bağlamla prompt oluşturur, sağlayıcıdan bağımsız LLM inference çalıştırır, sonucu insan-denetimli karar kapısından geçirir ve bütün süreci değiştirilemez audit kaydına yazar.

1. Signal Ingestion & Normalization

Alert, metric, trace ve log verileri ortak bir incident-context nesnesine dönüştürülür.

Bu katmanda:

• Deduplication
• Signal correlation
• Initial severity scoring

gerçekleştirilir.

2. Data Sanitization Pipeline

Kaynak bu katmanı sistemin uyumluluk açısından en kritik bölümü olarak tanımlamaktadır.

Örnek placeholder:

[REDACTED:PAN]

Bu yaklaşım LLM’e semantik olarak “burada kart numarası vardı” bilgisini korurken gerçek değeri göndermez.

3. Prompt Construction

Kaynak prompt mimarisini üç parçaya ayırmaktadır:

• System prompt: Rol, sınırlar ve çıktı formatı.
• Dynamic context: Sanitized incident verisi ve geçmiş olaylar.
• Task instruction: Classify, diagnose veya recommend gibi görevler.

RAG corpus’una yalnız root cause’u post-incident review ile doğrulanmış olayların alınması önerilmektedir.

Amaç, yanlış teşhis edilmiş eski vakaların yeni model önerilerini kirletmesini önlemektir.

4. LLM Inference

Model sağlayıcısı provider-independent API arkasında soyutlanmaktadır.

Bunun gerekçeleri:

• Vendor concentration risk.
• Model değiştirebilme.
• Shadow A/B testing.
• Farklı incident türlerini farklı modellere yönlendirebilme.

Beklenen schema’ya uymayan çıktı human-only fallback’i tetikler.

5. Human-in-the-Loop Decision Gate

Kaynak üç ayrı autonomy tier önermektedir:

Tier 3’te yalnız politika yasağı yoktur. Tool binding, credential ve execution path bulunmaz.

Bu nedenle başarılı bir prompt injection dahi üretim durumunu değiştirecek işlem yaptıramaz.

6. Audit Trail

Her etkileşim için aşağıdaki alanlar saklanmaktadır:

• Sanitizasyon sonrası input context
• Tam prompt
• Model response
• Confidence score
• İnsan kararı
• Nihai incident sonucu

Depolama append-only ve kriptografik bütünlük kontrolüne sahip olarak tasarlanmıştır.

Progressive Trust Nedir?

Progressive trust, LLM destekli olay müdahalesini doğrudan aktif üretim kararlarına bağlamak yerine önce shadow mode, sonra advisory mode ve en son standart iş akışına entegrasyon olmak üzere aşamalı biçimde devreye alma yaklaşımıdır.

Shadow mode

Model bütün incident’ları insanlarla paralel işler fakat çıktıları operasyon ekibine gösterilmez.

Kaynakta shadow run yaklaşık dokuz hafta sürmüştür.

Advisory mode

Öneriler görünür hâle gelir fakat bağlayıcı değildir.

Operatör:

• Kabul edebilir.
• Değiştirebilir.
• Reddedebilir.

Integrated mode

Araç standart workflow’un parçasına dönüşür ancak Tier 2 ve Tier 3 sınırları korunur.

Sentetik Benchmark Nasıl Kurulmuştur?

Çalışma, üretim bankacılık verisini yayımlamadan değerlendirme yapabilmek için kamuya açık banka kesintileri, ödeme sağlayıcılarının post-mortem'ları ve dağıtık sistem arıza örüntülerinden türetilmiş sentetik incident senaryolarını dört karmaşıklık düzeyinde sınıflandırmaktadır.

LLM Performansı Karmaşıklık Arttıkça Nasıl Değişti?

Kaynağın sentetik değerlendirmesinde olay karmaşıklığı arttıkça sınıflandırma, root-cause ve remediation performansı düzenli biçimde düşerken hallüsinasyon oranları yükselmiş; ayrı ve yapısal sanitizasyon katmanı ise bütün karmaşıklık seviyelerinde %100 tamlık göstermiştir.

Yazar, Level 3 ve Level 4 olaylarda aracın rolünü “doğru cevabı verme”den çok araştırmacının arama alanını daraltan bir başlangıç noktası üretmek olarak tanımlamaktadır.

Compliance validation sonuçları

Bu sonuçlar kaynak yazarının tanımladığı sistem ve test düzenine aittir.

Mimari Neden Sanitizasyona LLM'den Daha Fazla Önem Veriyor?

Kaynağın yaklaşımında yanlış bir LLM önerisi insan denetimiyle durdurulabilirken hassas finansal verinin yetkisiz bir inference sağlayıcısına sızması doğrudan uyumluluk ihlali doğurabileceği için sanitizasyon katmanı, LLM entegrasyonundan bile daha yüksek test önceliğine sahip olmalıdır.

Yazar, ekiplerin sanitizasyon katmanına orantısız ölçüde yatırım yapmasını önermektedir.

Sanitizasyonun bedeli

Muhafazakâr sanitizasyon, bazı teşhis bilgilerini kaybettirir.

Bazen redakte edilen değer root cause’u daha hızlı bulmayı sağlayabilecek kritik sinyal olabilir.

Kaynak, bu nedenle privacy ile diagnostic utility arasında çözülmemiş bir gerilim bulunduğunu kabul etmektedir.

Bu Sistem İnsan Incident Commander'ın Yerini Alıyor mu?

Hayır. Çalışmanın mimarisinde LLM özellikle yüksek karmaşıklık seviyelerinde karar verici değil, hipotez üreten ve arama alanını daraltan yardımcıdır; üretim durumunu değiştiren Tier 3 eylemleri sistem tarafından gerçekleştirilemez.

Bu nedenle insan accountability mimarinin merkezinde kalmaktadır.

Prompt governance

Kaynakta önerilen prompt ilkeleri şunlardır:

• Model eksik bağlam varsa bunu açıkça söylemelidir.
• Yetersiz bilgiyle tahmin üretmek yerine hangi ek verinin gerektiğini belirtmelidir.
• Her öneri ilgili log, metric veya historical incident ID ile kanıtlanmalıdır.
• Out-of-scope sistemlere yönelik öneriler otomatik flag edilmelidir.

Auditor için tasarım

Makale sistemin iki ayrı kullanıcı grubu olduğunu vurgulamaktadır:

• Gece 03.00'te hızlı öneri isteyen incident commander.
• Aylar sonra belirli kararın neden verildiğini soran auditor.

Bu nedenle audit interface, debug logunun sonradan güzelleştirilmiş versiyonu olmamalı; en baştan ayrı bir ürün yüzeyi gibi tasarlanmalıdır.

Bu Mimari Bankacılık Dışında Kullanılabilir mi?

Kaynağa göre temel ilke diğer yüksek düzenlemeli sektörlere aktarılabilir; ancak hassas veri türleri, değişiklik yönetimi ve denetim gereksinimlerine göre katmanların ayrıntıları değişmelidir.

Örnek olarak:

• Sağlık: HIPAA ve PHI sanitizasyonu.
• Enerji: NERC CIP değişiklik yönetimi.
• Kamu: FedRAMP, FISMA ve veri egemenliği.
• AB yüksek riskli AI sistemleri: AI Act ile örtüşen yönetişim ihtiyaçları.

Çalışmanın desteklediği sonuçlar

• Düzenleyici gereksinimler LLM sistem mimarisini temel düzeyde değiştirebilir.
• Sanitizasyon inference'dan bağımsız bir katman olarak kurulabilir.
• Tier 3 işlemlerin teknik olarak imkânsız olması prompt tabanlı yasağa göre daha güçlü kontroldür.
• Shadow mode, validation için önemli kanıt üretir.
• Model-provider abstraction concentration riskini azaltabilir.
• Audit trail hem compliance hem post-incident review için değerlidir.
• Karmaşık incident’larda LLM performansı düşse bile hipotez daraltma değeri sağlayabilir.

Çalışmanın desteklemediği sonuçlar

• LLM'in incident response'u tamamen otomatikleştirmesi önerilmemektedir.
• Sentetik benchmark sonuçları bütün bankalara veya bütün LLM'lere otomatik olarak genellenemez.
• %100 sanitization sonucu gerçek dünyada hiçbir veri kaçağı olmayacağının evrensel garantisi değildir.
• Tier 3 otonomisinin bugün güvenli olduğu savunulmamaktadır.
• Regülasyonların gelecekte değişmeden kalacağı varsayılmamaktadır.
• Üretim verisindeki accuracy kaybı bu çalışma tarafından doğrudan ölçülmemiştir.

Açık problemler

Kaynak üç önemli problemi çözülmemiş bırakmaktadır:

1. Sanitizasyonun teşhis doğruluğunda ne kadar bilgi kaybettirdiği.
2. Production-modifying AI eylemlerinin ne zaman güvenli biçimde genişletilebileceği.
3. Geleneksel Model Risk Management çerçevelerinin non-deterministic ve emergent LLM sistemlerine nasıl uyarlanacağı.