Ekibinizde bugün biri bir stack trace'i, biri bir SQL şemasını, biri de müşteri şikâyetinin tam metnini bir AI aracına yapıştırdı. Hangi araca, hangi hesapla, hangi sözleşme şartlarıyla yapıştırdığını bilmiyorsanız şirketinizin AI politikası şu anda "herkes en yakındaki aracı kullanır" cümlesinden ibaret. Bu yazı o cümleyi bir sayfalık, uygulanabilir ve teknik olarak zorlanan bir kural setine çevirmek için.
Bir not: burada anlattıklarımız mühendislik yönetişimidir, hukuki görüş sayılmaz. İşleme şartının belirlenmesi, yurt dışına aktarım mekanizması, veri işleyen sözleşmeleri, ihlal bildirimi kararı ve EU AI Act sınıflandırması hukuk ve uyum ekibinizin işidir. Biz onlara götüreceğiniz soruları ve mühendislik tarafında kuracağınız düzeni yazıyoruz.
Örnek olarak kurgusal bir seyahat rezervasyon şirketi kullanacağız: Rota. Kırk mühendis, mobil ve backend ekipleri, ödeme alan bir ürün.
"Politikamız yok" da bir politikadır
Rota'da bir backend geliştirici pazartesi sabahı prod'daki bir hatayı çözmeye çalışıyor ve kişisel hesabıyla açık duran sohbet aracına şunu yapıştırıyor:
Şu hatayı çözer misin? Prod'da bazı kullanıcılar ödeme sonrası 500 alıyor.
2026-09-28T09:14:03Z ERROR PaymentController orderId=RT-48213
user={"name":"Ayşe Yılmaz","email":"ayse.yilmaz@example.com","phone":"+90 532 000 00 00"}
card=5400 00** **** 1234
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
DB_URL=postgres://rota_app:S3cr3t!@prod-db.rota.internal:5432/booking
Kötü niyet yok, tembellik de yok. İşini hızlı bitirmek isteyen biri var ve önünde onu durduracak ya da doğru araca yönlendirecek hiçbir şey yok. Tek yapıştırmada bir müşterinin kişisel verisi, geçerli bir oturum token'ı ve bir veritabanı parolası, şirketin sözleşmesi olmayan bir sağlayıcıya gitti. Bu tablonun adı shadow AI ve büyük ekiplerde sık gördüğümüz bir durum. KVKK'nın Mart 2026 tarihli "İş Yerlerinde Üretken Yapay Zekâ Araçlarının Kullanımı" dokümanı da aynı noktaya basıyor: araçlar çoğu zaman kurumsal bir politika çerçevesinde tanımlanmadan, çalışanların bireysel tercihleriyle kullanılıyor ve bu yüzden kurum düzeyinde izlenmesi zorlaşıyor.
Refleks cevap topyekûn yasaktır ve işe yaramaz. Yasak kullanımı durdurmaz, yalnızca kişisel telefona ve ev bilgisayarına taşır. Elinizde ne log kalır ne de bir şey ters gittiğinde size haber verecek bir çalışan. Bizim önerdiğimiz yol tersinden başlar: önce iyi bir onaylı araç verin, sonra onun dışını kapatın.
İnsanlar en az sürtünmeli aracı kullanır. Politikanın işi, en az sürtünmeli aracın aynı zamanda onaylı araç olmasını sağlamaktır.
Araçları ayıran şey sözleşmedir
Aynı model, hangi kapıdan girdiğinize göre verinize farklı davranır. Bir aracı değerlendirirken sorduğumuz sorular şunlar ve cevaplarını sağlayıcının kendi veri kullanımı dokümanından alıyoruz, pazarlama sayfası kaynak sayılmaz.
Girdiler eğitim için kullanılıyor mu? Ayrım çoğu sağlayıcıda tüketici ve ticari şartlar arasından geçer. Anthropic'in veri kullanımı sayfasına göre Free, Pro ve Max hesaplarında bu bir kullanıcı ayarıdır ve ayar açıksa veri model eğitiminde kullanılır. Team, Enterprise ve API tarafında ise müşteri açıkça katılmadıkça kullanılmaz. Google'ın Gemini API şartlarında ücretsiz kotada gönderilen içerik ürün geliştirmede kullanılır ve insan değerlendiriciler tarafından okunabilir, ücretli kullanımda kullanılmaz (AEA, İsviçre ve Birleşik Krallık'taki kullanıcılara ücretsiz kotada da ücretli şartlar uygulanır). OpenAI'ın platform dokümanı API verisinin, müşteri açıkça paylaşmayı seçmedikçe eğitimde kullanılmadığını yazar. GitHub'ın model barındırma sayfası bireysel abonelerin etkileşim verisinin model eğitiminde kullanılabileceğini ve bundan çıkabileceklerini belirtir. Çıkarım basit: kişisel hesap ile şirket hesabı aynı ürün gibi görünür ama aynı sözleşme değildir.
Ne kadar süre saklanıyor? "Eğitimde kullanılmıyor" cümlesi "saklanmıyor" anlamına gelmez. OpenAI API tarafında kötüye kullanım izleme log'ları varsayılan olarak 30 güne kadar tutulur, bazı endpoint'ler (konuşma ve thread saklayanlar) veriyi siz silene kadar tutar. Anthropic ticari tarafta standart saklama süresini 30 gün olarak verir, kullanım politikası ihlali olarak işaretlenen girdi ve çıktılar için bu süre iki yıla kadar uzar. Tüketici hesabında eğitime izin verildiyse süre beş yıldır. Bu sayılar değişir, politikanıza sayı yerine kontrol edeceğiniz sayfanın bağlantısını yazın.
Sıfır saklama (zero data retention) var mı ve size açık mı? Var olması yetmez. OpenAI'da ZDR ve değiştirilmiş kötüye kullanım izleme ön onay gerektirir. Anthropic'te ZDR standart Enterprise planına dahil olmaz, uygun hesaplar için organizasyon bazında açılır. Satış görüşmesinde "ZDR destekliyoruz" cümlesini duyduğunuzda soracağınız şey, sizin hesabınızda bugün açık olup olmadığıdır.
Veri nerede işleniyor? Bölge seçimi sunan sağlayıcılar var, ancak bölge çoğu zaman ek onay ya da ek sözleşme ister ve her özelliği kapsamaz. Araya giren katmanlara da bakın: IDE asistanınız isteği kendi sunucusuna, o da model sağlayıcısına gönderiyor olabilir. GitHub'ın sayfası Copilot'ta modelin kimde barındırıldığının modele göre değiştiğini ve her sağlayıcıyla ayrı saklama taahhütleri olduğunu listeliyor. Zincirdeki her halka sizin için bir alt işleyendir.
Sağlayıcıda kim görebiliyor? Güvenlik ve kötüye kullanım incelemesi için insan erişimi çoğu sözleşmede saklı tutulur. Geri bildirim düğmeleri ayrı bir kanaldır: Claude Code'da /feedback komutu konuşma geçmişini kod dahil gönderir ve bu kayıt beş yıl saklanır. "Başparmak aşağı" tuşunun da bir veri aktarımı olduğunu ekibinize söyleyin.
IDE asistanları ve coding agent'lar ne gönderir
Sohbet penceresinde ne gönderdiğinizi görürsünüz. IDE asistanında görmezsiniz. Kod tamamlama, imlecin çevresindeki kodu ve açık sekmelerden alınan parçaları bağlam olarak gönderir. Agent'lar daha ileri gider: okudukları her dosya, çalıştırdıkları her komutun çıktısı ve bağlı her MCP sunucusundan dönen her yanıt konuşmanın parçası olur ve modele gider. Agent env çalıştırırsa ortam değişkenleriniz, cat .env.production çalıştırırsa prod parolanız prompt'a girmiştir. Yerelde de iz kalır: Claude Code oturum transkriptlerini varsayılan olarak 30 gün boyunca ~/.claude/projects/ altında düz metin saklar.
Dosya hariç tutma özelliklerine de körü körüne güvenmeyin. GitHub'ın dokümantasyonu content exclusion'ın Copilot CLI'da ve IDE'lerdeki agent modunda desteklenmediğini açıkça yazıyor. Kendi aracınızda aynı cümleyi arayın.
Tarayıcı eklentileri ve toplantı asistanları
Mühendislik ekipleri bu ikisini genelde atlar. Sayfa içeriğini okuma izni olan bir AI eklentisi, açık olan admin panelinizi, müşteri destek ekranınızı ve iç wiki'nizi de okuyabilir. Toplantı asistanı ise ses kaydı, transkript ve katılımcı listesini üçüncü bir tarafa taşır, üstelik müşteri görüşmesinde karşı tarafın verisini de. İkisini de onaylı araç sürecinden geçirin, tarayıcı eklentilerini MDM üzerinden izin listesiyle yönetin.
On saniyede uygulanan veri sınıflandırması
Yirmi sayfalık bir sınıflandırma standardı kimsenin prompt yazarken açacağı bir şey olamaz. Dört sınıf yeter ve her biri için tek bir test sorusu vardır.
| Sınıf | Ne girer | On saniyelik test |
|---|---|---|
| Açık | Yayınlanmış doküman, açık kaynak kod, pazarlama metni | Web sitemizde yayınlasak sorun olur mu? Olmaz. |
| Dahili | Toplantı notu, iç süreç, kişisel veri içermeyen ticket | Rakip görse canımız sıkılır ama zarar görmeyiz. |
| Gizli | Kaynak kod, mimari, yayınlanmamış roadmap, sözleşmeler | Sızarsa rekabet ya da güvenlik zararı doğar. |
| Kısıtlı | Secret ve credential, müşteri kişisel verisi, ödeme ve sağlık verisi | Sızarsa birini aramamız ya da bir kuruma bildirmemiz gerekir. |
Araçları da dört kademeye ayırıyoruz:
T0 Kişisel/tüketici hesap, ücretsiz kota, onaysız eklenti
T1 Onaylı kurumsal hesap: SSO, sözleşmeyle eğitim kapalı, veri işleyen sözleşmesi imzalı
T2 T1 + sıkılaştırılmış şartlar: sıfır/kısa saklama, bölge sabit, iç gateway üzerinden erişim
T3 Kendi altyapınızda ya da kendi bulut hesabınızda çalışan model, cihaz üstü model
| Sınıf | T0 | T1 | T2 | T3 |
|---|---|---|---|---|
| Açık | Evet | Evet | Evet | Evet |
| Dahili | Hayır | Evet | Evet | Evet |
| Gizli (kod, mimari) | Hayır | Evet, kod için onaylı araçlarla | Evet | Evet |
| Kısıtlı: kişisel veri | Hayır | Hayır | Maskelenmiş ve tanımlı bir amaç için | Evet, tanımlı bir amaç için |
| Kısıtlı: ödeme ve sağlık verisi | Hayır | Hayır | Hayır | Yalnızca uyum ekibinin onayıyla |
| Kısıtlı: secret, credential | Hayır | Hayır | Hayır | Hayır |
Tablonun kararı şu: kaynak kodu T1'e açıyoruz, çünkü kodu AI'dan saklayan ekip kısa sürede T0'da çalışan bir ekibe dönüşür. Secret'ların ise gidebileceği bir kademe yoktur, kendi sunucunuzdaki model dahil. Secret'ın yeri secret manager'dır, prompt'a girmesi için hiçbir meşru neden bulunmaz.
Kod için kurallar
Secret asla. Prompt'a, agent'ın okuyabildiği dosyaya, agent'ın çalıştırdığı shell'in ortamına girmez. Bir secret prompt'a girdiyse sızmış sayılır ve döndürülür.
Sorumluluk commit'i atandadır. "AI yazdı" bir gerekçe olarak kabul edilmez. AI çıktısına yeni başlamış bir meslektaşın işi gibi davranıyoruz: hızlı, çoğu zaman işe yarar ve mutlaka okunur. Kodun yazarı onu satır satır okumuş ve çalıştırmış kişidir.
PR'da beyan. Beyanın amacı reviewer'a nereye daha dikkatli bakacağını söylemektir, kimse suçlanmaz. Bizim kullandığımız şablon bölümü:
## AI kullanımı
- [ ] Bu PR'da AI aracı kullanılmadı
- [ ] Kullanıldı: (araç adı, hangi dosyalar ya da kısımlar)
- [ ] Üretilen kodu satır satır okudum, testleri kendi makinemde çalıştırdım
- [ ] Yeni bağımlılık eklendiyse paketin gerçekten var olduğunu ve lisansını kontrol ettim
- [ ] Prompt'lara gizli sınıfın üstünde veri girmedi
Dördüncü madde süs değil. Modellerin var olmayan paket adları uydurduğu bilinen bir hata türü ve o adı sonradan birinin kayıt etmesi bir tedarik zinciri saldırısıdır.
Lisans ve köken. Üretilen kod, eğitim verisindeki lisanslı bir kodu uzun parçalar hâlinde tekrar edebilir. Kuralımız: kendi yazmadığınız, yirmi otuz satırı aşan ve "fazla iyi" görünen bloklar için köken araması yapın, aracınız açık kodla eşleşen önerileri filtreleme ya da kaynağını gösterme ayarı sunuyorsa açın. Üretilen kodun telif durumu ve sağlayıcının tazminat taahhüdü hukuk ekibinizin okuyacağı maddelerdir.
Review gevşemez. AI ile yazılan kod için insan review'u şartı aynen geçerlidir, AI review ise insan review'unun yerine geçmez, önüne eklenir. Bunu nasıl kurduğumuzu AI ile code review yazımızda anlatıyoruz.
Agent en az yetkiyle çalışır. Agent, geliştiricinin tüm yetkisini devralmış bir süreç olmamalı. Prod credential'ı olan bir shell'de agent çalıştırılmaz, cloud CLI oturumu açık bir terminalde de. Çalışma dizini dışına yazamaz, izin listesindeki domain'ler dışına ağ çıkışı yapamaz, git push ve deploy komutları insan onayı ister. Uzaktan çalışan agent'lar yalnızca ilgili repoya, kısa ömürlü ve dar kapsamlı token'la erişir. Bunu araç düzeyinde nasıl zorladığımızı aşağıda gösteriyoruz.
Müşteri verisi ve kişisel veri
Buradaki ilk kural hukuki olmaktan önce mühendislik kuralıdır: modele göndermediğiniz veri sızmaz. KVKK'nın 4. maddesindeki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesi ile GDPR'ın 5. maddesindeki veri minimizasyonu aynı şeyi söyler. Bir hatayı çözmek için müşterinin adına ihtiyacınız yoktur, hatanın şekline ihtiyacınız vardır.
Hukuk ekibinize götüreceğiniz üç soru var. Birincisi işleme şartı: müşteri verisini bir AI aracına göndermek yeni bir işleme faaliyetidir ve KVKK madde 5 ya da GDPR madde 6 kapsamında bir dayanağa, aydınlatma metninde de bir karşılığa ihtiyaç duyar. İkincisi yurt dışına aktarım: model sağlayıcılarının çoğu veriyi Türkiye dışında işler. KVKK'nın 2024'te değişen 9. maddesi yeterlilik kararı, o yoksa uygun güvencelerden birini arar ve standart sözleşme kullanılıyorsa imzadan sonra beş iş günü içinde Kuruma bildirilmesini ister. GDPR tarafında karşılığı V. bölümdür (yeterlilik kararı, standart sözleşme maddeleri). Üçüncüsü veri işleyen ilişkisi: sağlayıcı sizin adınıza veri işliyorsa GDPR madde 28 yazılı bir sözleşme ister, KVKK madde 12 ise güvenlik tedbirleri konusunda veri işleyenle birlikte müştereken sorumlu olduğunuzu söyler. Tüketici hesabında bu sözleşmelerin hiçbiri yoktur ve T0'ın kişisel veriye kapalı olmasının nedeni budur. KVKK'nın üretken yapay zekâ rehberini hukuk ekibinizle birlikte okumanızı öneririz.
Prompt'tan önce maskeleme
Müşteri verisine dokunan her model çağrısının geçtiği tek bir nokta olsun ve maskeleme orada yapılsın:
data class Redacted(val text: String, val counts: Map<String, Int>)
// Sıra önemli: uzun ve belirgin kalıplar önce
private val rules = listOf(
"IBAN" to Regex("""\bTR\d{2}(?:\s?\d{4}){5}\s?\d{2}\b"""),
"KART" to Regex("""(?<!\d)(?:\d[ -]?){13,19}(?!\d)"""),
"JWT" to Regex("""\beyJ[\w-]+\.[\w-]+\.[\w-]+"""),
"EPOSTA" to Regex("""[\w.+-]+@[\w-]+(?:\.[\w-]+)+"""),
"TELEFON" to Regex("""(?<!\d)(?:\+90|0)?\s?5\d{2}\s?\d{3}\s?\d{2}\s?\d{2}(?!\d)"""),
"TCKN" to Regex("""(?<!\d)[1-9]\d{10}(?!\d)"""),
)
fun redact(input: String): Redacted {
val counts = mutableMapOf<String, Int>()
val text = rules.fold(input) { acc, (label, regex) ->
regex.replace(acc) {
counts.merge(label, 1, Int::plus)
"[$label]"
}
}
return Redacted(text, counts)
}
Bu kod biçimi belli tanımlayıcıları yakalar. İsimleri, adresleri ve serbest metne gömülü sağlık bilgisini yakalamaz. Bu yüzden maskeleme ikinci savunma hattıdır, birincisi alanı hiç göndermemektir: modele customer nesnesinin yalnızca işe yarayan üç alanını verin. Ürün içinde müşteri verisiyle çalışan bir asistan kuruyorsanız erişim kontrolü tarafını RAG ile iç bilgi asistanı yazımızda ele alıyoruz.
Prompt'u loglamadan prompt'u loglamak
Denetim için kimin, ne zaman, hangi aracı, hangi veri sınıfıyla kullandığını bilmeniz gerekir. Prompt'un kendisini düz metin saklarsanız en hassas verinizin ikinci bir kopyasını, üstelik daha gevşek korunan bir yerde üretmiş olursunuz. Bizim tuttuğumuz kayıt şöyle:
data class PromptAudit(
val requestId: String,
val userId: String, // çalışanın SSO kimliği
val tool: String, // "gateway/chat", "ide-assistant"
val model: String,
val dataClass: String, // "dahili", "gizli", "kisitli-maskeli"
val promptChars: Int,
val promptSha256: String, // maskelenmiş metnin özeti, tekrarları bulmak için
val redactions: Map<String, Int>, // {"EPOSTA": 2, "TELEFON": 1}
val timestamp: Instant,
)
redactions alanı aynı zamanda erken uyarıdır: bir ekibin prompt'larında her gün onlarca kart numarası maskeleniyorsa o ekip yanlış veriyle çalışıyordur ve bunu ihlal olmadan öğrenmişsinizdir. Hata ayıklama için tam metin gerekiyorsa maskelenmiş hâlini kısa süreli ve erişimi kısıtlı ayrı bir depoda tutun.
Kendi ürününüzdeki AI özellikleri
Araç kullanımı ile ürününüze AI koymak ayrı başlıklardır, politikada ikisi de yer almalı. Üç kural yazıyoruz. Kullanıcı bir AI sistemiyle konuştuğunu bilir ve üretilen içerik öyle etiketlenir. Kullanıcı için sonuç doğuran çıktılar (iade reddi, fiyat farkı, hesap kısıtlama) bir insanın onayından geçer ya da en azından kullanıcıya bir insana itiraz yolu sunulur. Model çıktısı güvenilmeyen girdi olarak ele alınır: doğrulanmadan bir SQL sorgusuna, bir shell komutuna ya da bir ödeme işlemine dönüşmez.
AB'de kullanıcınız varsa EU AI Act'e de bakmanız gerekir. Tüzük risk temelli çalışır: kabul edilemez risk taşıyan uygulamalar yasaktır, yüksek riskli sistemler sıkı yükümlülüklere tabidir, belirli sistemler için şeffaflık yükümlülükleri vardır ve geri kalan çoğunluk için özel bir yükümlülük öngörülmez. Avrupa Komisyonu'nun sayfasına göre takvim şöyle: tüzük 1 Ağustos 2024'te yürürlüğe girdi, yasaklar ve AI okuryazarlığı yükümlülüğü 2 Şubat 2025'ten, genel amaçlı model yükümlülükleri 2 Ağustos 2025'ten, 50. maddedeki şeffaflık kuralları 2 Ağustos 2026'dan beri uygulanıyor. Yüksek riskli sistemlere ilişkin yükümlülükler, 27 Temmuz 2026'da yürürlüğe giren AI Omnibus düzenlemesiyle ertelendi: belirli yüksek risk alanları için 2 Aralık 2027, ürünlere gömülü sistemler için 2 Ağustos 2028. Bir müşteri destek chatbot'u büyük olasılıkla şeffaflık kategorisine düşer, işe alım ya da kredi değerlendirmesi yapan bir sistem yüksek riske girebilir. Sınıflandırmayı hukuk ekibiniz yapar, mühendisliğin işi ona ürünün ne yaptığını eksiksiz anlatmaktır.
Onaylı araç listesi ve yeni araç nasıl onaylanır
Liste kısa olsun ve her satırında araç, plan, izin verilen en yüksek veri sınıfı ve sahibi yazsın. Sohbet, IDE asistanı, coding agent ve toplantı notu için birer onaylı seçenek çoğu ekibe yeter. Yeni araç talebi için kullandığımız giriş formu:
Araç ve plan adı:
Talep eden / sahibi olacak kişi:
Hangi iş için, hangi veri sınıfıyla kullanılacak:
1. Kurumsal plan ve SSO var mı? Hesaplar işten ayrılışta kapatılabiliyor mu?
2. Girdiler eğitimde kullanılıyor mu? Varsayılan ne, sözleşmede ne yazıyor? (bağlantı)
3. Saklama süresi ne? Sıfır saklama bizim planımızda açık mı?
4. Veri hangi ülkede işleniyor? Alt işleyenler kim? (bağlantı)
5. Veri işleyen sözleşmesi ve aktarım mekanizması imzalanabiliyor mu?
6. Araç makinede neye erişiyor: dosyalar, terminal, tarayıcı, pano, mikrofon?
7. Yönetici kontrolleri: denetim log'u, özellik kapatma, dosya hariç tutma?
8. Geri bildirim ve telemetri kanalları kapatılabiliyor mu?
9. Çıkış: verimizi silebiliyor ve silindiğini teyit ettirebiliyor muyuz?
Karar: onay / ret / koşullu Sınıf üst sınırı: Gözden geçirme tarihi:
Formun asıl değeri hızdır. Talebe iki hafta içinde cevap vermezseniz ekip beklemez ve aracı T0'da kullanmaya başlar. Güvenlik, hukuk ve bir mühendislik temsilcisinden oluşan üç kişilik bir grup ve on iş günlük bir cevap süresi öneririz.
Politikayı PDF olmaktan çıkaran teknik zorlama
SSO ile yönetilen kurumsal hesaplar. Onaylı araçlara yalnızca şirket kimliğiyle girilir. Böylece sözleşme şartları herkese uygulanır, ayrılan kişinin erişimi kapanır ve denetim log'unda bir isim olur.
Secret scanning, iki katman. Geliştirici makinesinde pre-commit hook, sunucuda push koruması. Gitleaks için pre-commit yapılandırması:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.24.2 # güncel sürümü projenin release sayfasından alın
hooks:
- id: gitleaks
Hook yerelde atlanabilir, bu yüzden sunucu tarafı şarttır. GitHub'ın push protection özelliği secret içeren push'ları repoya ulaşmadan engeller, atlatılması mümkündür ama her atlatma bir gerekçe ister, uyarı üretir ve denetim log'una düşer. GitLab ve Bitbucket'ta eşdeğer özellikler var. Secret'ı repoya sokmamak, agent'ın onu okuyup modele taşıma ihtimalini de azaltır.
Agent izinleri repoda yaşar. Claude Code'da bunu projeye commit'lenen ayar dosyası yapar. Diğer agent'ların kendi izin dosyaları vardır, ilke aynıdır:
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.*)",
"Read(secrets/**)",
"Bash(git push *)",
"Bash(curl *)"
]
},
"sandbox": {
"enabled": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"denyRead": ["~/.ssh", "~/.aws", "~/.kube"]
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}
İki katmanın farkını bilin. Dokümantasyona göre Read deny kuralları yerleşik dosya araçlarını ve cat gibi tanınan komutları kapsar, kendi başına dosya açan bir Python script'ini kapsamaz. Onu işletim sistemi düzeyinde çalışan sandbox durdurur. Sandbox da yalnızca shell komutlarını sarar, MCP sunucuları onun dışında çalışır. Bu ayarları merkezi olarak dağıtılan managed settings'e koyarsanız geliştirici kendi makinesinde gevşetemez.
Agent'a kuralları söyleyen talimat dosyası. Birçok aracın okuduğu ortak biçim AGENTS.md'dir (Claude Code CLAUDE.md okur, aracınızın dosya adını dokümantasyonundan teyit edin):
# AGENTS.md
## Veri kuralları
- .env*, secrets/ ve *.pem dosyalarını okuma, içeriklerini çıktıya yazma.
- Prod veritabanına, prod API'lerine ve müşteri verisi içeren dump'lara bağlanma.
Test için yalnızca fixtures/ altındaki sentetik veriyi kullan.
- Log ya da hata çıktısında e-posta, telefon, kart ya da token görürsen
aynen tekrar etme, [MASKELENDİ] yaz ve kullanıcıyı uyar.
## Çalıştırma kuralları
- git push, deploy, migration ve paket yayınlama komutlarını çalıştırma. Komutu öner, insan çalıştırsın.
- Yeni bağımlılık eklemeden önce dur ve gerekçesiyle birlikte sor.
- Görev tanımının dışındaki dosyalara dokunma. Gerekli görüyorsan önce söyle.
Bu dosya bir ricadır, zorlama sayılmaz. Model talimatı unutabilir ya da bir prompt injection ile ikna edilebilir. Kuralın tutması gereken her yerde arkasında yukarıdaki izin ve sandbox katmanı bulunmalı.
Çıkış kontrolü ve iç gateway. Ağ tarafında iki seçenek var. Ucuz olanı, kurumsal cihazlarda onaysız AI servislerinin tüketici uç noktalarını proxy ya da DNS düzeyinde engellemek ve engel sayfasında onaylı aracı göstermektir. Daha sağlam olanı, model erişimini tek bir iç gateway üzerinden geçirmektir: geliştiriciler ve servisler sağlayıcı API anahtarını hiç görmez, gateway kimliği SSO'dan alır, maskelemeyi uygular, PromptAudit kaydını yazar ve hangi modelin hangi veri sınıfını alabileceğini tek yerden yönetir. Sağlayıcı değiştirmek de tek bir yapılandırma değişikliğine iner. Kırk kişilik bir ekipte engelleme ile başlamanızı, ürün içinde model çağrısı yapmaya başladığınız gün gateway'i kurmanızı öneririz.
Denetim log'ları. Kurumsal planların sunduğu log'ları SIEM'inize alın ve çeyrekte bir gerçekten bakın: kim hangi aracı kullanıyor, hangi onaylı araç hiç kullanılmıyor (bu, insanların başka bir şey kullandığının işaretidir), kaç secret push'u engellendi.
Yanlış araca kısıtlı veri gittiğinde
Olacak. Politikanın bu bölümü, olduğunda kişinin bunu saklamak yerine beş dakika içinde yazmasını sağlamak için var.
1. Bildir. #security kanalına yaz: ne, hangi araca, hangi hesapla, ne zaman.
Bildiren kişi için yaptırım yok. Saklamanın yaptırımı var.
2. Secret ise hemen döndür. Sohbeti silmek secret'ı geri almaz.
3. Araçtaki konuşmayı sil, sağlayıcının silme ve saklama süresini not et.
Kurumsal hesapsa yöneticiden silme talebi açtır.
4. Kişisel veri varsa veri koruma sorumlusuna ve hukuka haber ver.
Bunun bildirim gerektiren bir ihlal olup olmadığına onlar karar verir.
5. Kaydı tut: hangi veri, kaç kişi, hangi sınıf, alınan aksiyonlar.
6. Nedeni düzelt: araç mı eksikti, log mu fazla veri basıyordu, engel mi yoktu?
Dördüncü adımda hız önemlidir. GDPR madde 33 denetim otoritesine bildirimi, ihlalin öğrenilmesinden sonra mümkünse 72 saat içinde ister. KVKK madde 12 "en kısa sürede" der ve Kurul bu süreyi 2019/10 sayılı kararıyla 72 saat olarak yorumlamıştır. Saat siz öğrendiğinizde başlar, bu yüzden mühendisin cuma akşamı yaşadığı şeyi pazartesi söylemesi hukuk ekibinizin süresini yer. Arayüzde silmenin sunucudan anında silme anlamına gelmediğini de bilin: sağlayıcının saklama süresi işlemeye devam eder.
Altıncı adım için Rota örneğine dönelim: asıl hata, kişisel veriyi ve Authorization başlığını düz metin basan log satırındaydı. Yapıştıran kişi yalnızca onu taşıdı. Log'larınızı temizlemek, AI politikanızın en ucuz maddesidir.
Tek sayfalık politika şablonu
AI KULLANIM POLİTİKASI v1.0 Sahibi: (isim) Sonraki gözden geçirme: (tarih)
1. KAPSAM
Şirket işi için kullanılan tüm AI araçları: sohbet, IDE asistanı, coding agent,
tarayıcı eklentisi, toplantı asistanı ve ürünlerimizdeki AI özellikleri.
2. ONAYLI ARAÇLAR
Güncel liste: (bağlantı). Listede olmayan araç şirket verisiyle kullanılamaz.
Onaylı araçlara yalnızca şirket SSO hesabıyla girilir. Kişisel hesap T0'dır.
3. VERİ SINIFLARI VE ARAÇ KADEMELERİ
Açık: her araç. Dahili: T1 ve üstü. Gizli (kod, mimari): T1 ve üstü, kod için onaylı araçlar.
Kısıtlı / kişisel veri: yalnızca T2-T3, maskelenmiş, tanımlı amaçla.
Kısıtlı / ödeme ve sağlık: yalnızca T3, uyum onayıyla.
Secret ve credential: hiçbir araç.
4. KOD
Commit'i atan kişi kodun sahibidir. PR'da AI kullanımı beyan edilir.
İnsan review'u zorunludur. Yeni bağımlılığın varlığı ve lisansı doğrulanır.
5. AGENT'LAR
En az yetki. Prod credential'ı yok. Sandbox açık. Push, deploy ve migration insan onayıyla.
6. KİŞİSEL VERİ
Önce gönderme, sonra maskele. Yeni bir kullanım amacı hukuk onayı olmadan başlamaz.
Prompt log'larında kişisel veri tutulmaz.
7. ÜRÜNLERİMİZDEKİ AI
Kullanıcı AI ile etkileşimde olduğunu bilir. Sonuç doğuran çıktılar insan onayından geçer.
Yeni AI özelliği yayına çıkmadan hukuk ve güvenlik incelemesinden geçer.
8. YENİ ARAÇ VE İSTİSNA
Giriş formu: (bağlantı). Cevap süresi: 10 iş günü.
İstisnalar yazılı, süreli (en çok 90 gün) ve sahibi belli olur.
9. OLAY
Yanlış araca veri gittiyse hemen #security. Bildirene yaptırım uygulanmaz.
10. GÖZDEN GEÇİRME
Çeyrekte bir ve sağlayıcı şartı, mevzuat ya da olay tetiklediğinde.
Yaygınlaştırma: eğitim, istisnalar, gözden geçirme
Dört haftalık bir plan çoğu ekipte işliyor. İlk hafta envanter: isimsiz bir anketle ve proxy log'larıyla bugün hangi araçların kullanıldığını öğrenin. Anketin isimsiz olması şart, aksi hâlde yalnızca onaylı araçları duyarsınız. İkinci hafta onaylı araçları alın, lisansları dağıtın ve politikayı yayınlayın. Sıra önemli: alternatifi vermeden kural koyarsanız kuralı kimse takmaz. Üçüncü hafta kırk beş dakikalık bir eğitim yapın ve slayt yerine yukarıdaki log örneği gibi gerçekçi vakalar üzerinden "bu hangi sınıf, hangi araca gider" alıştırması yaptırın. Dördüncü hafta teknik zorlamayı açın: push koruması, engel listesi, agent ayar dosyaları. AI araçlarını geliştirme sürecine nasıl yerleştirdiğimizi AI ile SDLC dönüşümü yazımızda daha geniş anlatıyoruz.
İstisnalar olacak ve olmalı. İstisnasız politika, gizli istisnalarla çalışan politikadır. Her istisnanın bir sahibi, bir gerekçesi ve bir bitiş tarihi olsun, kayıtları onaylı araç listesiyle aynı yerde dursun. Aynı istisna üçüncü kez isteniyorsa politikayı değiştirmenin zamanı gelmiştir.
Gözden geçirmeyi çeyreklik yapın. Bu alanda sağlayıcı şartları yılda birkaç kez değişiyor ve bir e-postayla gelen "şartlarımızı güncelledik" bildirimi, onaylı listenizdeki bir aracın kademesini değiştirebilir. Sağlayıcıların şart değişikliği bildirimlerinin, politika sahibinin de üye olduğu bir dağıtım listesine gitmesini sağlayın.
Kontrol listesi
- Bugün ekipte hangi AI araçlarının hangi hesaplarla kullanıldığı isimsiz anket ve ağ log'larıyla çıkarıldı.
- Sohbet, IDE asistanı ve coding agent için en az birer onaylı kurumsal araç var ve SSO ile giriliyor.
- Her onaylı araç için eğitim kullanımı, saklama süresi, işleme bölgesi ve alt işleyenler sağlayıcının kendi dokümanından okundu, bağlantıları listeye yazıldı.
- Dört veri sınıfı ve araç kademesi tablosu yayınlandı, ekip gerçek örneklerle alıştırma yaptı.
- Secret scanning hem pre-commit'te hem sunucu tarafında açık, atlatmalar izleniyor.
- Agent izin ve sandbox ayarları repoda ya da merkezi yönetilen ayarlarda, prod credential'ı olan ortamda agent çalışmıyor.
- Repolarda agent talimat dosyası veri ve çalıştırma kurallarını içeriyor.
- Müşteri verisine dokunan model çağrıları tek bir noktadan geçiyor, maskeleme ve denetim kaydı orada.
- Log'lar kişisel veri ve token basmıyor.
- Hukuk ekibi işleme şartını, yurt dışına aktarım mekanizmasını ve veri işleyen sözleşmelerini onayladı.
- Ürün içi AI özellikleri kullanıcıya açıklanıyor, sonuç doğuran çıktılarda insan onayı var, AI Act sınıflandırması yapıldı.
- Olay adımları yazılı, bildirim kanalı belli, "bildirene yaptırım yok" cümlesi politikada duruyor.
- Politikanın bir sahibi ve takvimde çeyreklik bir gözden geçirme tarihi var.
Bu konuda desteğe mi ihtiyacınız var?
Uygulamanızda bu kontrollerin doğru kurulup kurulmadığını birlikte inceleyelim. Güvenlik denetimi ya da danışmanlıkla buradayız.
Kaynaklar
- KVKK · İş Yerlerinde Üretken Yapay Zekâ Araçlarının Kullanımı
- KVKK · Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)
- KVKK · 6698 sayılı Kişisel Verilerin Korunması Kanunu (İngilizce metin)
- EUR-Lex · Regulation (EU) 2016/679 (GDPR)
- European Commission · AI Act
- OpenAI · Data controls in the OpenAI platform
- Anthropic · Claude Code data usage
- Google · Gemini API Additional Terms of Service
- GitHub · Hosting of models for GitHub Copilot
- GitHub · About push protection
Yorumlar ve sorular
Katılmadığınız bir nokta ya da projenizde takıldığınız bir yer mi var? Yazın, konuşalım.