01

Veri yerleşimi ve veri akışı

Kurumsal değerlendirmenin ilk sorusu her zaman aynıdır: veri nereye gidiyor? Cevap mimari düzeyde verilir, taahhüt düzeyinde değil.

Kurulum bulutta mı olmak zorunda?

Hayır. Şirket içi kurulum mümkündür. Tamamen internetsiz (air-gap) çalışma desteklenir — platform, dışarıya hiçbir bağlantı açılmayan bir ağda çalışabilir.

on-premair-gap

Verinin makineden çıkmadığının teknik garantisi nedir?

localOnly modunda bulut modelleri model listesinde hiç görünmez. Bir bulut modeli açıkça istenirse istek kategorik olarak reddedilir — çağrı yapılmaz. Bu bir politika tercihi değil, çalışma zamanı kısıtıdır.

localOnly

Bulut sağlayıcı anahtarlarını kim görebilir?

Sağlayıcı anahtarları platform yöneticisi tarafında kalır ve müşteri alanına inmez. Yönetim panelinde her zaman maskeli görünür; hiçbir arayüzde açık değer gösterilmez.

Bulut ve yerel modeli birlikte kullanabilir miyiz?

Evet. Hassas iş yükleri yerel modelle, hassas olmayanlar bulut modelleriyle çalıştırılabilir; seçim model ve agent düzeyinde tanımlanır. 17 AI sağlayıcı desteklenir ve sağlayıcı değişimi konfigürasyon meselesidir.

02

Çok müşterili yalıtım (multi-tenancy)

Paylaşımlı bir altyapı söz konusuysa, yalıtımın hangi katmanda uygulandığı sorulur. Yalıtım depolama, şifreleme, entegrasyon, olay dağıtımı ve yetkilendirme katmanlarının hepsinde ayrı ayrı vardır.

Kullanım ve maliyet verileri nerede tutulur?

Her müşteri alanının kendi dizininde tutulur. Alanlar arası erişim yoktur — bir müşterinin kullanım kaydı başka bir alandan okunamaz.

Bağlantı ve sağlayıcı anahtarları nasıl saklanıyor?

Alan bazında AES-256 ile şifrelenir. Düz metin saklama yoktur.

AES-256

Entegrasyonlar müşteriler arasında paylaşılıyor mu?

Hayır. Entegrasyon bağlantıları alan bazında yalıtılır; her müşteri kurumu yalnızca kendi tanımladığı bağlantıları görür ve kullanır.

Kanal olayları başka bir müşteriye taşabilir mi?

Hayır. Kanal olay dağıtımında alan koruması vardır; bir olay yalnızca ait olduğu alanın aboneliklerine iletilir.

Kurulumlar kriptografik olarak birbirinden ayrı mı?

Evet. Her müşteri kurulumu kendi RSA-2048 anahtar çiftine sahiptir. Yetkilendirme, o kuruluma ait imzalı manifest ile taşınır; başka bir kurulumun manifesti geçerli olmaz.

RSA-2048imzalı manifest
03

Kimlik doğrulama ve erişim

Kritik ayrım şudur: kurumsal yetki modeli yalnızca kullanıcıya değil, AI'a da uygulanır. AI, kullanıcının göremediği veriyi göremez.

361 Erişim Kontrolü ekranı — AI kaynak izinleri ve erişim politikaları, izin/ret kuralları
Erişim Kontrolü (RBAC). AI kaynak izinleri politika olarak tanımlanır: ajan, bilgi tabanı, prompt, sağlayıcı ve özellik düzeyinde izin/ret. Varsayılan davranış ve zorunluluk açıkça görünür.

AI, yetkisi olmayan veriyi görebilir mi?

Hayır. Rol bazlı erişim kontrolü ve satır bazlı erişim güvenliği kullanıcıya olduğu gibi AI'a da uygulanır. AI, isteği yapan kullanıcının yetki bağlamıyla çalışır.

RBACsatır bazlı güvenlik

Hassas alanlar (örneğin maaş) AI'a nasıl kapatılır?

Rol farkındalıklı alan filtreleme: AI'a sunulan entity alanları kullanıcının rolüne göre süzülür. Maaş alanı yalnızca İK rolüne görünür; diğer rollerde alan modele hiç iletilmez.

Bir agent'ı kimlerin kullanabileceğini sınırlayabilir miyiz?

Evet. Agent bazında izinli rol listesi tanımlanabilir; listede olmayan roller o agent'ı çağıramaz.

API anahtarları nasıl korunuyor?

API anahtarları özet (hash) olarak saklanır — açık değer sistemde tutulmaz. Rotasyon için geçiş penceresi, IP beyaz listesi, dakika bazlı hız sınırı ve günlük kota tanımlanabilir.

hashIP beyaz listehız sınırı

Dış sistemlere bağlanırken hangi kimlik doğrulama tipleri destekleniyor?

Altı tip: kimlik doğrulamasız, Basic, Bearer, API anahtarı, OAuth 2.0 (üç akış) ve Digest.

04

AI yönetişimi ve guardrail

AI'ın ne yapabileceği, neyi onaysız yapamayacağı ve nasıl durdurulacağı tanım düzeyinde belirlenir.

361 Guardrail ekranı — agent listesi ve koruma durumu, kişisel veri ve komut enjeksiyonu koruması
Guardrail kuralları. Her agent'ın koruma durumu ayrı görünür: korumalı mı, yapılandırılmamış mı. Kişisel veri maskeleme, komut enjeksiyonu koruması ve günlük maliyet limiti agent bazında tanımlanır.
361 Onay İşlemleri ekranı — bekleyen, onaylanan ve reddedilen AI eylemleri
Onay kuyruğu. Riskli AI eylemleri insan onayı bekler. Bekleyen, onaylanan ve reddedilen talepler ayrı ayrı izlenir; karar geçmişi kayıtta kalır.

Model çıktısı hangi kontrollerden geçiyor?

4 detektör + guardrail hattı devrededir:

  • Kişisel veri (PII) tespiti
  • Halüsinasyon tespiti
  • Komut enjeksiyonu (prompt injection) tespiti
  • Maliyet limiti
4 detektörguardrail hattı

Riskli araçlar ayırt ediliyor mu?

Evet. Araçlar risk seviyesiyle etiketlidir — düşük, orta, yüksek, kritik — ve seviyesine göre onay gerektirebilir.

İnsan onayı akışı nasıl işliyor?

Onay akışı üç durumludur: bekliyor → onaylandı veya reddedildi. Onay politikası agent bazında tanımlanır: hangi araçların onay isteyeceği ve otomatik onay süresi ayarlanabilir.

AI'ı acil durumda nasıl durdururuz?

Acil durdurma (break-glass) kalıcıdır: sunucu yeniden başlasa bile durdurma korunur, kendiliğinden açılmaz. Tüm otonom işlemler denetim kaydına yazılır.

break-glasskalıcı

Maliyet kontrolden çıkabilir mi?

Maliyet limiti guardrail detektörlerinden biridir. İstek, gün ve maliyet tavanları tanımlanır; eşiğe yaklaşıldığında bildirim üretilir.

05

Denetim ve gözlemlenebilirlik

Denetlenebilirlik sonradan eklenen bir rapor değil, çalışma zamanının parçasıdır.

361 agent çalışma izleri — adım ağacı, süre, token ve maliyet
Agent çalışma izleri. Her çalıştırma adım adım açılır: kaç adım koştu, ne kadar sürdü, kaç token harcadı. Bir kararın nasıl üretildiği geriye doğru izlenebilir.
361 AI işlem kayıtları — istek, yanıt, durum, sağlayıcı ve maliyet filtreleri
İşlem kayıtları. Her AI işleminin kaydı tutulur: ne istendi, ne yanıt geldi, kaça mal oldu. Duruma, sağlayıcıya ve tarihe göre filtrelenir; hata satırından kök nedene inilir.

Denetim kaydı sonradan değiştirilebilir mi?

Denetim kaydı zinciri özet (hash) ile bağlanır; kayıtlar birbirine zincirlendiği için araya girilmiş bir değişiklik zinciri bozar ve tespit edilebilir.

AI araç çağrıları kayıt altına alınıyor mu?

Her MCP araç çağrısı günlük JSONL dosyasına yazılır: zaman damgası, anahtar kimliği, araç adı, argümanlar, başarı durumu ve süre. Parola, token ve anahtar gibi alanlar kayıt sırasında maskelenir.

JSONLmaskeleme

Bir AI çalıştırmasının içini görebilir miyiz?

Evet. AI çalıştırmalarında izleme (trace) tutulur: adım adım kayıt, kullanılan token, süre ve maliyet. Hangi adımda ne olduğu geriye dönük incelenebilir.

Mevcut gözlemlenebilirlik yığınımıza bağlanır mı?

Evet. OpenTelemetry ile mevcut izleme ve metrik altyapınıza bağlanır; ayrı bir konsol zorunluluğu yoktur.

OpenTelemetry

Kişisel veri loglara sızabilir mi?

Kişisel veri maskeleme ve log temizleme uygulanır; hassas alanlar kayıt katmanında maskelenerek yazılır.

06

Ağ ve saldırı yüzeyi

AI'ın araç kullanabilmesi, saldırı yüzeyinin genişlemesi anlamına gelmez — araçların sınırları çalışma zamanında zorunlu kılınır.

AI iç ağımıza istek atabilir mi?

Hayır. HTTP isteği aracında SSRF koruması vardır: localhost, 127.0.0.1, ::1, 10.x, 172.16-31.x, 192.168.x ve 169.254.x adreslerine çağrı engellenir.

SSRF koruması

AI veritabanında değişiklik yapabilir mi?

Veritabanı araçları yalnızca okuma yapabilir. SELECT, WITH, SHOW, DESCRIBE ve EXPLAIN serbesttir; yazma ve şema komutları engellidir. 22'den fazla tehlikeli komut kara listededir ve SQL yorumları temizlenir — yorum içine gizlenmiş komut enjeksiyonu bu şekilde engellenir.

salt okunurkara liste

Bağlantı bilgileri (connection string) sızabilir mi?

Hayır. Bağlantı bilgileri API yanıtlarına, log kayıtlarına veya AI'a asla verilmez.

Değerlendirme sırasında yazma işlemlerini tamamen kapatabilir miyiz?

Evet. Veritabanı yöneticisinde salt-okunur kilit vardır: kilit açıkken tüm değiştirici işlemler gönderilmeden önce reddedilir.

Giden webhook'ların doğruluğu nasıl kanıtlanıyor?

Webhook'lar HMAC ile imzalanır; alıcı taraf imzayı doğrulayarak isteğin gerçekten platformdan geldiğini kanıtlayabilir.

HMAC
07

Uyumluluk

361 Uyumluluk ekranı — veri saklama ayarları, denetim izi ve veri hakları sekmeleri
Uyumluluk paneli. Veri saklama süreleri kurumunuza göre ayarlanır, denetim izinden kim-ne-yaptı izlenir, veri hakları talepleri aynı yerden işletilir.

KVKK ve sertifikasyon durumu nedir?

KVKK uyumu sağlanır. Bilgi güvenliği tarafında ISO 27001 sertifikası mevcuttur; belgelerin güncel listesi güvenlik sayfasında yayımlanır.

KVKKISO 27001

Silme talebi geldiğinde ne oluyor?

Silme talebinde 30 günlük geri alma süresi işler; sürenin ardından deterministik anonimleştirme uygulanır — kayıt kimliği geri döndürülemez biçimde ayrıştırılır.

Denetim izi kurumsal beklentiyi karşılıyor mu?

Kurumsal loglama ve denetim izi standarttır; kim, ne zaman, hangi veriye, hangi işlemle eriştiği kayıt altındadır.

08

Süreklilik ve operasyon

Yerel model çökerse platform durur mu?

Hayır. Yerel model ayrı süreçte çalışır; model çökmesi platformu durdurmaz. Çökme döngüsü koruması vardır — sürekli yeniden başlayan bir süreç sistemi meşgul etmez.

Şema değişikliği kesinti gerektiriyor mu?

Hayır. Şema değişikliği yeniden başlatma gerektirmez; tanım güncellenir, çalışma zamanı ayakta kalır.

Bağlantı koptuğunda çift kayıt oluşur mu?

Hayır. Çevrimdışı istemci kuyruğunda istek tekilleştirme uygulanır; 24 saatlik pencerede aynı istek yeniden gönderilse bile ikinci bir kayıt oluşmaz.

idempotent kuyruk

361 AI İşletim Sistemi — IT Onay Paketi · 361.com.tr/it-onay-paketi.html