Şirketler İçin AI Yönetişimi: Pratik Başlangıç Rehberi

Kısa özet

Şirketinde birileri zaten AI kullanıyor. Geliştiriciler kodlama asistanıyla çalışıyor, satış ekibi e-postalarını bir sohbet aracına yazdırıyor, ürün ekibi müşteri destek botuna bir LLM API'si bağlamış, birisi de geçen hafta CRM'e erişen bir ajan denedi. Soru "AI kullanacak mıyız?" değil; "kim, neyi, hangi veriyle, hangi riskle kullanıyor ve bunu biliyor muyuz?"

AI yönetişimi bu soruya düzenli olarak cevap verebilmenin adıdır: hangi AI sistemlerinin kullanıldığını kayıt altına almak, her birinin riskini sınıflandırmak, risk seviyesine göre kural ve kontrol koymak, olanları izlemek ve gerektiğinde kanıt gösterebilmek.

Bu rehber küçük ve orta ölçekli şirketler için yazıldı: tam zamanlı bir uyum ekibi olmayan, ama AB'ye satış yapan, kurumsal müşterilerden güvenlik anketi alan ya da kişisel veri işleyen ekipler. Önerilen kurulumun özeti:

1. Envanter      → Hangi AI sistemleri var? (tek bir YAML/tablo)
2. Sınıflandırma → Her biri hangi risk sınıfında? (karar ağacı)
3. Politika      → Kim neyi, hangi veriyle kullanabilir? (1-2 sayfa)
4. Dokümantasyon → Sistem kartı, veri notu, karar kaydı
5. Teknik kontrol→ PII maskeleme, guardrail, insan onayı, log, eval, ajan izinleri
6. Tedarikçi     → LLM API sağlayıcısını kontrol listesiyle değerlendir
7. İzleme        → Olay kaydı, periyodik gözden geçirme, iç denetim

Önemli not: Bu rehber hukuki danışmanlık değildir. Mevzuat bilgileri Ekim 2026 itibarıyla birincil kaynaklardan (EUR-Lex, AB Komisyonu, KVKK, TBMM, NIST, ISO) kontrol edildi; kaynaklar en sonda. Mevzuat hızlı değişiyor ve somut durumun için bir hukukçuyla çalışman gerekir. Rehberin amacı mühendislik ve ürün tarafının yapması gereken işi düzenlemek.

Neden şimdi?

Üç ayrı baskı aynı anda geliyor:

1. Düzenleme takvimi işliyor. AB Yapay Zekâ Yasası'nın (EU AI Act) yasak uygulamalar ve AI okuryazarlığı hükümleri Şubat 2025'ten, genel amaçlı AI modeli (GPAI) yükümlülükleri Ağustos 2025'ten, şeffaflık yükümlülükleri Ağustos 2026'dan beri uygulanıyor. Yüksek riskli sistemlere ilişkin büyük blok ertelendi ama iptal edilmedi. AB dışındaki bir şirket de, AI sisteminin çıktısı AB'de kullanılıyorsa kapsama girebiliyor.

2. Gerçek olaylar yaşanıyor. Kamuya yansıyan tipik vakalar hep aynı kalıpları tekrarlıyor:

• Çalışanların gizli kaynak kodunu ya da müşteri verisini halka açık bir sohbet aracına yapıştırması.
• Bir müşteri destek botunun var olmayan bir iade politikası uydurması (halüsinasyon) ve şirketin bundan sorumlu tutulması.
• Bir web sayfasına ya da belgeye gömülü talimatlarla ajanın veri sızdırmaya yönlendirilmesi (prompt injection).
• Geniş yetkilerle çalışan bir kodlama ajanının dosya ya da veritabanı silmesi.

Bunların hiçbiri egzotik bir model hatası değil; envanter, yetki, onay ve log eksikliği.

3. Müşteriler soruyor. Kurumsal satışta güvenlik anketlerine artık "AI kullanıyor musunuz, hangi sağlayıcılarla, verimiz modele eğitim için gidiyor mu, insan denetimi var mı?" soruları ekleniyor. Cevabı hazır olan şirket satışı hızlandırır; olmayan haftalarca yazışır.

İyi haber: küçük bir şirket için gereken yönetişim, büyük bir bürokrasi değil. Bir envanter dosyası, iki sayfalık bir politika, birkaç teknik kontrol ve üç ayda bir yapılan bir gözden geçirme ile başlanabilir.

Düzenleyici harita (Ekim 2026)

Bu bölüm "hangi kural bana dokunuyor?" sorusuna kaba bir yön vermek için var. Her başlıkta yürürlükte olan ile önerilen ama kabul edilmemiş düzenlemeleri ayırıyoruz.

AB Yapay Zekâ Yasası (EU AI Act)

EU AI Act (Regulation (EU) 2024/1689) 1 Ağustos 2024'te yürürlüğe girdi ve kademeli olarak uygulanıyor. Risk temelli bir yapısı var:

Ek III'teki alanlar: biyometri, kritik altyapı, eğitim ve mesleki eğitim, istihdam ve çalışan yönetimi, temel özel ve kamu hizmetlerine erişim (kredi değerliliği, hayat ve sağlık sigortası dahil), kolluk, göç ve sınır yönetimi, adalet ve demokratik süreçler. Ek III'teki bir sistem, kişilerin sağlığına, güvenliğine ya da temel haklarına önemli bir zarar riski taşımıyorsa md. 6(3) kapsamında yüksek risk sayılmayabilir; ama bu değerlendirmenin belgelenmesi gerekir.

Rolün önemli: Yasa, AI sistemini geliştirip kendi adıyla piyasaya süren sağlayıcı (provider) ile onu kendi işinde kullanan kullanıcı/uygulayıcı (deployer) arasında ayrım yapar. Bir LLM API'si üzerine ürün kurup kendi markanla satıyorsan o ürünün sağlayıcısı sensin. Yalnızca hazır bir aracı iç süreçlerinde kullanıyorsan deployer'sın. Bir sistemi önemli ölçüde değiştirir ya da kullanım amacını yüksek riskli bir alana çevirirsen deployer'dan sağlayıcıya dönüşebilirsin (md. 25).

AB dışındaki şirketler: Yasa, AB'de piyasaya sürülen sistemlerin sağlayıcılarına, nerede kurulu olduklarından bağımsız olarak uygulanır; ayrıca üçüncü ülkede kurulu sağlayıcı ve deployer'lara, sistemin ürettiği çıktı AB'de kullanılıyorsa uygulanır (md. 2(1)). AB'ye yazılım satan bir Türk şirketi için bu, "biz AB'de değiliz" cevabının yetmediği anlamına geliyor.

GPAI modelleri: LLM gibi genel amaçlı modellerin sağlayıcılarına (OpenAI, Anthropic, Google, Mistral gibi) teknik dokümantasyon, aşağı yönlü sağlayıcılara bilgi, telif hakkı politikası ve eğitim verisi özeti yükümlülükleri 2 Ağustos 2025'ten beri uygulanıyor. Komisyon'un bu yükümlülüklere uyumu kolaylaştırmak için hazırladığı GPAI Uygulama Kuralları (Code of Practice) 10 Temmuz 2025'te yayımlandı; şeffaflık, telif ve emniyet/güvenlik olmak üzere üç bölümü var. Bir API'yi yalnızca kullanan şirket GPAI sağlayıcısı değildir; ama modeli önemli ölçüde değiştirirsen (örneğin kapsamlı fine-tuning) sağlayıcı yükümlülükleri gündeme gelebilir. Burada Komisyon'un GPAI rehberine bakmak gerekir.

Takvim, Digital Omnibus sonrası (yürürlükte): AI Act'i değiştiren Regulation (EU) 2026/1744 ("Digital Omnibus on AI") 8 Temmuz 2026'da kabul edildi, 27 Temmuz 2026'da yürürlüğe girdi. Güncel takvim:

Omnibus ayrıca KOBİ'lere tanınan bazı kolaylıkları "küçük orta ölçekli şirketlere" (small mid-caps, SMC) genişletti ve AI okuryazarlığı maddesini yeniden yazdı: yükümlülük sağlayıcı ve deployer'larda kalıyor, Komisyon ve üye devletlerin özellikle KOBİ'leri desteklemesi ekleniyor.

Cezalar (md. 99): Yasak uygulamalar için 35 milyon avroya ya da dünya çapındaki yıllık cironun %7'sine kadar; diğer yükümlülüklerin çoğu için 15 milyon avro ya da %3; yetkililere yanlış/yanıltıcı bilgi için 7,5 milyon avro ya da %1 (her durumda hangisi yüksekse). KOBİ'ler için tutar ile yüzdeden düşük olan uygulanır. GPAI sağlayıcıları için Komisyon 15 milyon avro ya da %3'e kadar ceza verebilir (md. 101).

GDPR

AI sistemin kişisel veri işliyorsa (AB'deki kişilere hizmet ya da onların davranışını izleme) GDPR zaten geçerli ve AI'ye özel bir istisnası yok. Pratikte en sık karşılaşılan maddeler:

Cezalar md. 83'e göre iki kademeli: 10 milyon avro ya da %2, ağır ihlallerde 20 milyon avro ya da %4 (hangisi yüksekse).

Önerilen, kabul edilmemiş: Komisyon 19 Kasım 2025'te GDPR'ı da değiştiren daha geniş bir "Digital Omnibus" önerisi (COM(2025) 837) sundu. Öneride AI geliştirme ve işletimi için meşru menfaatin hukuki dayanak olarak kullanımını netleştiren hükümler var. Ekim 2026 itibarıyla Avrupa Parlamentosu'nun yasama takibine göre bu dosya hâlâ görüşme aşamasında; kabul edilmiş değil. Uyum planını bu öneriye göre değil, yürürlükteki GDPR'a göre yap.

KVKK ve Türkiye

Türkiye'de AI'ye özgü yürürlükte bir kanun yok. Bugün geçerli olan çerçeve 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK):

• md. 11(1)(g): İlgili kişi, işlenen verilerinin münhasıran otomatik sistemlerle analiz edilmesi sonucu aleyhine bir sonuç doğmasına itiraz edebilir. AI destekli karar süreçlerinde bu itirazı alacak ve bir insanın inceleyeceği bir kanal olmalı.
• md. 12(5): Veri ihlalinde veri sorumlusu ilgili kişiye ve Kurul'a "en kısa sürede" bildirim yapar.
• md. 9 (yurt dışına aktarım): 7499 sayılı Kanun'la değişti, 1 Haziran 2024'ten beri yeni rejim geçerli: yeterlilik kararı, uygun güvenceler (standart sözleşme, bağlayıcı şirket kuralları, taahhütname) ve arızi aktarım halleri. Standart sözleşme imzalandıktan sonra beş iş günü içinde Kurum'a bildirilmelidir. Prompt'larda kişisel veri yurt dışındaki bir LLM API'sine gidiyorsa bu bir yurt dışı aktarımdır.
• Rehber: KVKK 24 Kasım 2025'te "Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)"nı yayımladı. Üretken AI'nin yaşam döngüsü, riskleri ve 6698 kapsamındaki değerlendirmeleri ele alıyor; bağlayıcı bir düzenleme değil, ama Kurum'un bakışını gösteriyor.

Önerilen, kabul edilmemiş: 24 Haziran 2024'te TBMM'ye sunulan 2/2234 esas numaralı Yapay Zekâ Kanun Teklifi TBMM kayıtlarına göre hâlâ komisyonda. Kanunlaşmış bir AI düzenlemesi yok; teklifler üzerinden uyum planı yapma.

AB'ye satan Türk şirketi için pratik sonuç: Hem KVKK'ya (Türkiye'de işlenen veri) hem GDPR'a (AB'deki kişilerin verisi) hem de AI Act'e (çıktısı AB'de kullanılan sistemler) aynı anda tabi olabilirsin. İyi haber: üçü için gereken temel işler (envanter, veri haritası, risk değerlendirmesi, sözleşmeler, log) büyük ölçüde örtüşüyor.

ABD: NIST AI RMF ve eyalet yasaları

NIST AI RMF 1.0 (NIST AI 100-1) 26 Ocak 2023'te yayımlandı ve gönüllü bir çerçeve. Dört fonksiyonu var: Govern (yönet), Map (bağlamı çıkar), Measure (ölç), Manage (yönet/azalt). 26 Temmuz 2024'te üretken AI'ye özgü riskleri ele alan Generative AI Profile (NIST AI 600-1) yayımlandı. NIST, AI RMF 1.0'ın revize edildiğini duyuruyor; Ekim 2026 itibarıyla yerine geçen yeni bir sürüm yok. Bağlayıcı olmasa da ABD'li kurumsal müşteriler soru setlerini sık sık bu çerçeveye dayandırıyor; bu rehberdeki adımlar da kabaca Govern → Map → Measure → Manage sırasını izliyor.

Eyalet düzeyinde örnek olarak Colorado: Kapsamlı AI yasası SB 24-205 önce 30 Haziran 2026'ya ertelendi, sonra o tarih gelmeden 14 Mayıs 2026'da imzalanan SB 26-189 ile yeniden yazıldı. Yeni yasa, "sonuç doğuran kararlarda" kullanılan otomatik karar teknolojileri için dokümantasyon, tüketiciye bildirim ve anlamlı insan incelemesi hakkı getiriyor; temel yükümlülükler 1 Ocak 2027'de başlıyor. ABD'de eyalet mevzuatı hızla değişiyor; ABD'ye satıyorsan güncel durumu bir hukukçuya doğrulat.

ISO/IEC 42001

ISO/IEC 42001:2023, Aralık 2023'te yayımlanan ve bir AI yönetim sistemi (AIMS) kurmanın gereksinimlerini tanımlayan ilk uluslararası standart. ISO/IEC 27001 ile aynı yönetim sistemi yapısını kullanıyor; bu yüzden zaten 27001 sertifikası olan şirketler için en doğal genişleme. Sertifikasyon gönüllü. Küçük bir şirket için önerimiz: sertifikayı hedefleme, ama yapını (politika, risk değerlendirmesi, rol tanımı, iç denetim, sürekli iyileştirme) 42001 ile uyumlu kur. Bir gün kurumsal müşteri sertifika isterse sıfırdan başlamazsın.

Hangisi bana dokunuyor?

Adım 1: AI envanteri

Görmediğin şeyi yönetemezsin. İlk iş, şirkette kullanılan bütün AI sistemlerinin bir sistem kaydını (AI register) çıkarmak. Bu, git deposunda duran tek bir YAML dosyası ya da paylaşılan bir tablo olabilir; önemli olan güncel ve tek olması.

Envantere neler girer:

• Satın alınan araçlar: ChatGPT/Claude/Gemini kurumsal hesapları, kodlama asistanları, toplantı not alıcıları, AI özellikli SaaS'lar (CRM, destek, İK araçlarındaki AI modülleri).
• Kendi geliştirdiklerin: LLM API'si çağıran özellikler, RAG sistemleri, ajanlar, sınıflandırma/skor modelleri.
• Gölge AI: Kimsenin onaylamadığı ama kullanılan araçlar. Bunları bulmanın en kolay yolu sormak: kısa bir anket, "hangi AI araçlarını kullanıyorsun, ne için, hangi veriyle?" Ayrıca kurumsal kart harcamalarına ve SSO/OAuth uygulama listesine bakmak işe yarar.

Her kayıt için bir şablon:

# ai-register.yaml — her AI sistemi için bir kayıt
- id: AI-007
  name: "Destek asistanı (müşteri chatbot'u)"
  owner: "ayse.yilmaz"            # iş sahibi: sistemden hesap veren kişi
  tech_owner: "mehmet.kaya"       # teknik sahibi
  status: production              # idea | pilot | production | retired
  purpose: "Web sitesinde sipariş ve iade sorularını yanıtlamak"
  users: external                 # internal | external
  affected_people: ["müşteriler"]
  ai_act:
    role: provider                # provider | deployer | both | n/a
    risk_class: limited           # prohibited | high | limited | minimal
    transparency_notice: true     # md. 50(1): "AI ile konuşuyorsunuz" bildirimi
  vendor:
    name: "Örnek LLM Sağlayıcı"
    model: "model-adı-ve-sürümü"
    region: "eu"
    dpa_signed: true
    zero_data_retention: false
    trains_on_our_data: false
  data:
    personal_data: true
    categories: ["ad", "e-posta", "sipariş no"]
    special_categories: false     # sağlık, biyometri vb.
    cross_border_transfer: true   # KVKK md. 9 / GDPR md. 44+
    legal_basis: "sözleşmenin ifası"
  controls:
    pii_redaction: true
    guardrails: ["konu dışı engelleme", "iade tutarı onaysız taahhüt edilemez"]
    human_in_the_loop: "iade > 1000 TL ise temsilci onayı"
    logging: "prompt+yanıt 90 gün, PII maskeli"
    evals: "haftalık 200 soruluk regresyon seti"
  docs:
    system_card: "docs/ai/AI-007-system-card.md"
    dpia: "docs/privacy/DPIA-2026-03.pdf"
  review:
    last_reviewed: 2026-09-15
    next_review: 2026-12-15

İpucu: Envanteri kodla aynı yerde tutmak, yeni bir AI özelliği eklendiğinde kaydın da aynı pull request'te güncellenmesini kolaylaştırır. PR şablonuna "Bu değişiklik yeni bir AI sistemi ekliyor ya da mevcut birinin modelini/verisini değiştiriyor mu?" sorusunu eklemek yeterli bir tetikleyicidir.

Adım 2: Talep ve risk sınıflandırma

Envanter mevcut durumu gösterir; yeni kullanım senaryoları için bir giriş kapısı (intake) gerekir. Amaç bürokrasi değil, düşük riskli işlerin hızlı geçmesi ve yüksek riskli olanların erken fark edilmesi. Yeni bir AI kullanım fikri olan herkes kısa bir form doldurur; çoğu 10 dakikada onaylanır.

Sınıflandırma için basit bir karar ağacı (AI risk sınıflandırma):

S1. AI Act md. 5'teki yasak bir uygulama mı?
    (sosyal puanlama, manipülasyon, işyerinde/eğitimde duygu tanıma,
     hedefsiz yüz görüntüsü toplama, rıza dışı mahrem içerik üretimi...)
    → EVET: DUR. Kullanılamaz.

S2. Ek III alanlarından birinde mi ya da ürün güvenliği mevzuatına tabi bir üründe mi?
    (işe alım/çalışan değerlendirme, kredi, sigorta fiyatlama, eğitim,
     kritik altyapı, biyometri, temel hizmetlere erişim...)
    → EVET: YÜKSEK RİSK adayı. Hukuk + DPO incelemesi, md. 6(3) değerlendirmesi belgelenir.

S3. Kişiler hakkında otomatik ve onlar için önemli sonuç doğuran bir karar mı veriyor?
    → EVET: En az YÜKSEK (iç) risk. GDPR md. 22 / KVKK md. 11(1)(g) kanalı, insan onayı zorunlu.

S4. Dışarıdaki kişilerle doğrudan etkileşiyor ya da sentetik içerik üretip yayımlıyor mu?
    → EVET: ŞEFFAFLIK yükümlülüğü (md. 50). "AI ile konuşuyorsunuz" bildirimi, içerik etiketi.

S5. Kişisel veri, gizli veri ya da müşteri verisi işliyor mu? Ya da gerçek dünyada eylem yapan bir ajan mı?
    → EVET: ORTA (iç) risk. Veri kuralları, tedarikçi kontrolü, log, ajan izinleri.

S6. Hiçbiri değil (ör. halka açık dokümanlardan özet, kod önerisi, iç taslak)
    → DÜŞÜK risk. Kabul edilebilir kullanım politikası yeterli.

Bu ağaç iki şeyi karıştırmamak için tasarlandı: AI Act'in yasal risk sınıfı (yasak / yüksek / şeffaflık / minimal) ile şirketin iç risk seviyesi. Müşteri verisine erişip e-posta gönderebilen bir ajan, AI Act açısından "minimal" olabilir ama iç risk açısından kesinlikle "düşük" değildir.

Risk seviyesine göre gereken kontroller:

Adım 3: Politikalar

Politika uzun olursa kimse okumaz. Hedef: bir sayfalık kabul edilebilir kullanım politikası + bir onaylı araçlar listesi + bir veri sınıflandırma tablosu. Bunlar birlikte "ne yapabilirim?" sorusunun cevabını verir.

Kabul edilebilir kullanım (özet şablon)

# AI Kullanım Politikası (v1.2, Ekim 2026)

1. Yalnızca "Onaylı AI Araçları" listesindeki araçları, şirket hesabıyla kullan.
   Kişisel hesaplarla şirket verisi işlenmez.
2. Veriyi sınıflandırmasına göre paylaş (aşağıdaki tablo). Emin değilsen paylaşma, sor.
3. AI çıktısından sen sorumlusun. Müşteriye giden metni, kodu ve kararları
   göndermeden önce kontrol et.
4. AI ile kişiler hakkında otomatik karar verme (işe alım, kredi, performans, fiyat)
   yalnızca AI yönetişim grubunun onayıyla yapılır.
5. Kodlama asistanları: sırlar (.env, anahtarlar) ajanın erişiminden çıkarılır;
   ajanın ürettiği kod normal code review sürecinden geçer.
6. Ajanlar: production sistemlere yazma, para transferi, dışarıya e-posta gibi
   geri alınamaz eylemler insan onayı olmadan yapılmaz.
7. Yeni bir AI aracı ya da AI özelliği mi lazım? Talep formunu doldur (10 dk).
8. Bir sorun mu gördün (veri sızıntısı, tuhaf çıktı, prompt injection)?
   #ai-olay kanalına yaz. Bildirim yapan kimse cezalandırılmaz.

Veri sınıflandırması ve AI

Onaylı araçlar listesi

Her araç için şu bilgileri tut: ad, plan/sürüm (kurumsal mı bireysel mi), izin verilen veri sınıfı, sahibi, DPA durumu, son gözden geçirme tarihi. Aynı aracın bireysel ve kurumsal planları arasında veri saklama ve eğitim koşulları çoğu zaman farklıdır; listeye planı yaz, yalnızca ürün adını değil.

AI okuryazarlığı

AI Act md. 4, sağlayıcı ve deployer'ların AI sistemiyle çalışan personelin yeterli AI okuryazarlığına sahip olması için önlem almasını istiyor; belirli bir seviyeyi garanti etmek zorunlu değil. Pratikte: politikayı anlatan 30-45 dakikalık bir oturum, rol bazlı kısa eğitimler (geliştiriciler için prompt injection ve ajan izinleri, satış için müşteri verisi kuralları) ve katılım kaydı. Kaydı tut; bir müşteri ya da denetçi sorduğunda gösterebilmen gerekir.

Adım 4: Dokümantasyon

Dokümantasyonun amacı kâğıt üretmek değil, üç soruya sonradan cevap verebilmek: Bu sistem ne yapıyor? Neden böyle tasarlandı? Bir şey ters gidince ne oldu?

Sistem kartı

Model kartı fikrinin sistem düzeyine taşınmış hali. Bir LLM'i API'den kullanıyorsan model kartını sağlayıcı yazar; senin yazacağın şey, modelin etrafına kurduğun sistemin kartıdır:

# Sistem Kartı: AI-007 Destek Asistanı

## Amaç ve kapsam
- Ne yapar: Sipariş durumu ve iade sorularını yanıtlar.
- Ne yapmaz: İade onaylamaz, fiyat taahhüt etmez, hukuki/tıbbi tavsiye vermez.
- Kullanıcılar: Web sitesi ziyaretçileri (TR, EN).

## Mimari
- Model: <sağlayıcı / model / sürüm>, sıcaklık 0.2
- Bilgi kaynağı: RAG; yalnızca yayımlanmış yardım makaleleri + sipariş API'si (salt okunur)
- Araçlar: get_order_status(order_id)  ← yazma aracı yok

## Bilinen sınırlamalar ve riskler
- Halüsinasyon: politika metni dışında cevap üretebilir → kaynak gösterme zorunlu
- Prompt injection: kullanıcı mesajı talimat içerebilir → araçlar salt okunur
- Dil: Türkçe ve İngilizce dışında test edilmedi

## Değerlendirme
- Regresyon seti: 200 soru, doğruluk hedefi ≥ %95, son sonuç %96,5 (2026-09-28)
- Red team: 2026-08, 14 bulgu, 13'ü kapatıldı (bkz. RT-2026-08)

## İnsan gözetimi
- "Temsilciye bağlan" her ekranda; düşük güvenli yanıtlar otomatik devredilir

## Değişiklik geçmişi
- 2026-09-01: model sürümü güncellendi, eval tekrar koşuldu

Veri notu (data sheet)

Kendi verinle eğittiğin, fine-tune ettiğin ya da RAG için indekslediğin her veri seti için kısa bir not: kaynağı, toplama tarihi, içinde kişisel veri olup olmadığı, hukuki dayanağı, kimin erişebildiği, ne zaman silineceği. RAG indeksleri sık unutulur: silinmesi istenen bir kişinin verisi vektör veritabanında kalmaya devam edebilir.

Karar kaydı

Önemli tasarım kararlarını kısa kayıtlar halinde tut (ADR formatı iyi çalışır): "Neden bu sağlayıcı?", "Neden ajana e-posta gönderme yetkisi vermedik?", "Neden bu sistemi md. 6(3) kapsamında yüksek risk saymadık?". Son soru özellikle önemli: AI Act, Ek III'teki bir sistemi yüksek risk saymayan sağlayıcının bu değerlendirmeyi belgelemesini istiyor.

Adım 5: Teknik kontroller

Politika "yapma" der; teknik kontrol "yapamazsın" der. İkincisi her zaman daha güvenilirdir. Burada guardrail kavramını geniş anlamda kullanıyoruz: modelin önüne, arkasına ve etrafına koyduğun her deterministik kontrol.

PII maskeleme

Kişisel veriyi modele göndermeden önce maskele, yanıtta gerekiyorsa geri koy. Basit bir başlangıç:

import re

PATTERNS = {
    "EMAIL": re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+"),
    "TCKN": re.compile(r"\b[1-9]\d{10}\b"),
    "IBAN": re.compile(r"\bTR\d{2}(?:\s?\d{4}){5}\s?\d{2}\b"),
    "PHONE": re.compile(r"(?:\+90|0)?\s?5\d{2}\s?\d{3}\s?\d{2}\s?\d{2}"),
}

def redact(text: str) -> tuple[str, dict[str, str]]:
    """PII'yi yer tutucularla değiştirir; geri koymak için eşleme döndürür."""
    mapping: dict[str, str] = {}
    for label, pattern in PATTERNS.items():
        for i, match in enumerate(dict.fromkeys(pattern.findall(text))):
            token = f"<{label}_{i}>"
            mapping[token] = match
            text = text.replace(match, token)
    return text, mapping

def restore(text: str, mapping: dict[str, str]) -> str:
    for token, value in mapping.items():
        text = text.replace(token, value)
    return text

masked, m = redact("Ali'nin e-postası ali@ornek.com, telefonu 0532 123 45 67.")
assert "ali@ornek.com" not in masked and restore(masked, m).endswith("45 67.")

Regex tabanlı maskeleme yalnızca yapılandırılmış alanları (e-posta, TCKN, IBAN, telefon) yakalar; isimleri ve adresleri kaçırır. Daha kapsamlı ihtiyaçlar için Microsoft Presidio gibi bir NER tabanlı kütüphane kullan ve maskelemenin kaçırdıklarını eval setinde ölç.

Guardrail'lar

• Girdi tarafı: konu dışı ya da kötüye kullanım isteklerini filtrele, maksimum girdi uzunluğu koy, bilinen prompt injection kalıplarını işaretle (tek başına yeterli savunma değildir).
• Çıktı tarafı: yapılandırılmış çıktıyı şemayla doğrula, yasaklı taahhütleri (fiyat, iade onayı, hukuki tavsiye) kural tabanlı kontrol et, RAG yanıtlarında kaynak göstermeyi zorunlu kıl.
• Önemli ilke: Asıl savunma modelin "itaat etmesi" değil, modelin yapabileceklerinin sınırlı olması. Bir destek botunun yazma aracı yoksa, prompt injection ile iade onaylatılamaz.

İnsan onayı

Human-in-the-loop kontrolünü risk seviyesine göre ayarla:

"İnsan onaylıyor" demek yetmez; onaylayan kişinin neyi onayladığını görebilmesi ve reddetmesinin gerçekten mümkün olması gerekir. Her öneriyi otomatik onaylayan bir insan, bir kontrol değildir (otomasyon yanlılığı).

Loglama

Her AI çağrısı için en az şunları kaydet: zaman, kullanıcı/sistem kimliği, sistem ID'si (envanterdeki), model ve sürüm, maskelenmiş girdi ve çıktı, çağrılan araçlar ve argümanları, insan onayı varsa kim onayladı. Saklama süresini veri minimizasyonuyla dengele ve yazılı hale getir. Yüksek riskli sistem deployer'ları için AI Act, sistemin otomatik ürettiği logların, kendi kontrolleri altında olduğu ölçüde, en az altı ay saklanmasını istiyor (md. 26).

{
  "ts": "2026-10-05T09:14:22Z",
  "system_id": "AI-007",
  "actor": "web-session:8f3a",
  "model": "provider/model@2026-09",
  "input_masked": "Siparişim <ORDER_0> nerede?",
  "tool_calls": [{"name": "get_order_status", "args": {"order_id": "<ORDER_0>"}}],
  "output_masked": "Siparişiniz kargoya verildi...",
  "guardrail_flags": [],
  "human_approval": null,
  "latency_ms": 1840
}

Eval ve red teaming

• Eval seti: Her sistem için gerçek kullanım senaryolarından 50-200 örnek; doğruluk, reddetme davranışı, kaynak gösterme ve PII sızıntısı için ölçüm. Model sürümü, prompt ya da RAG içeriği değiştiğinde yeniden çalıştır. Model sağlayıcısı sürüm güncellediğinde de.
• Red teaming: Orta ve yüksek riskli sistemler için yayına almadan önce ve önemli değişikliklerden sonra. Kapsam: prompt injection (doğrudan ve dolaylı, yani belge/web içeriği üzerinden), jailbreak, sistem prompt sızdırma, araçların kötüye kullanımı, veri sızdırma, zararlı içerik. Bulguları ve kapanış durumunu kaydet.

Ajan izinleri ve sandbox

Ajanlar, AI yönetişiminin en hızlı büyüyen risk alanı; çünkü yalnızca metin değil eylem üretiyorlar. Temel kurallar:

• En az yetki: Ajana yalnızca görevi için gereken araçları ve kimlik bilgilerini ver. Salt okunur başla; yazma yetkisini tek tek ekle.
• Ayrı kimlik: Ajan kendi servis hesabıyla çalışsın, bir çalışanın kişisel token'ıyla değil. Böylece loglarda ayırt edilir ve yetkisi tek hamlede iptal edilir.
• Sandbox: Kod çalıştıran ajanları agent sandbox içinde (konteyner, OS sandbox) çalıştır, ağ erişimini alan adı allowlist'iyle sınırla.
• Ölümcül üçlüyü kır: Bir ajan aynı anda (1) özel veriye erişip (2) güvenilmeyen içerik okuyor ve (3) dışarıya veri gönderebiliyorsa, prompt injection ile veri sızdırılabilir. Üçünden en az birini kaldır ya da onaya bağla.
• Limitler: Tur, bütçe ve zaman limiti; gözetimsiz (CI, cron) ajanlarda zorunlu.
• Kodlama asistanları: .env, SSH anahtarları ve bulut kimlik bilgilerini deny kurallarına koy; tehlikeli komutları hook ile engelle. Ayrıntılar için AI Harness Anatomisi rehberindeki güvenlik bölümüne bak.

System prompt'a "müşteri verisini paylaşma" yazmak bir ricadır; aracın o veriye hiç erişmemesi bir kontroldür. Sistem prompt'ları yazarken System Prompt Rehberi yardımcı olur, ama güvenlik sınırını prompt'a emanet etme.

Adım 6: Tedarikçi incelemesi

LLM API sağlayıcısı, verinin en kritik durağı. Seçmeden önce ve yılda bir kez şu soruları cevaplat. Cevapları sağlayıcının sözleşme, gizlilik ve güven (trust center) sayfalarından yazılı olarak al; satış görüşmesindeki sözlü cevaba güvenme.

Dikkat: Aynı sağlayıcının tüketici uygulaması, kurumsal planı ve API'si arasında veri koşulları genellikle farklıdır. Değerlendirmeyi kullanacağın plan ve uç nokta için yap. Bulut platformları (AWS, Azure, Google Cloud) üzerinden erişilen modellerin koşulları da modelin kendi sağlayıcısınınkinden farklı olabilir.

Adım 7: İzleme, olay ve denetim

İzleme

Yayına alınan bir AI sistemi statik değildir: model sürümü değişir, kullanıcılar beklenmedik sorular sorar, RAG içeriği eskir. Sistem başına birkaç metrik yeterli:

• Kalite: eval skoru trendi, kullanıcı beğeni/beğenmeme oranı, insana devretme oranı.
• Güvenlik: guardrail tetiklenme sayısı, PII maskeleme kaçakları, reddedilen araç çağrıları.
• Maliyet ve kullanım: token tüketimi, istek sayısı, hata oranı.

Olay yönetimi

AI olayı tanımını önceden yap; aksi halde kimse neyi bildireceğini bilmez. Örnekler: kişisel ya da gizli verinin yetkisiz bir modele/kişiye gitmesi, müşteriye yanlış ve zararlı bilgi verilmesi, ajanın yetkisiz bir eylem yapması, başarılı bir prompt injection, ayrımcı bir çıktı.

1. Tespit ve bildirim   → #ai-olay kanalı, nöbetçi kişi
2. Sınırlama            → özelliği kapat (feature flag), ajan kimlik bilgisini iptal et
3. Değerlendirme        → kişisel veri ihlali mi? (GDPR md. 33: 72 saat; KVKK md. 12(5): en kısa sürede)
4. Düzeltme             → kök neden, kontrol ekle, eval setine regresyon örneği ekle
5. Kayıt ve öğrenme     → olay kaydı, envanter ve sistem kartı güncellemesi

Her olaydan sonra eval setine en az bir yeni test ekle. Aynı hatanın ikinci kez sessizce geri gelmesini engellemenin en ucuz yolu bu.

Denetim

AI denetimi küçük bir şirkette dışarıdan bir denetçi gerektirmez; üç ayda bir yapılan bir iç gözden geçirme ile başla:

• Envanter güncel mi? Gölge AI taraması yapıldı mı?
• Her orta/yüksek riskli sistemin sistem kartı, eval sonucu ve sahibi güncel mi?
• Tedarikçi koşullarında değişiklik var mı (saklama, eğitim, alt işleyen)?
• Olaylar kapatıldı mı, aksiyonlar uygulandı mı?
• Mevzuat takviminde yaklaşan bir tarih var mı (örneğin 2 Aralık 2027)?

Yılda bir kez, özellikle kurumsal müşteriler istiyorsa, bağımsız bir göz (dış danışman ya da ISO/IEC 42001 ön değerlendirmesi) faydalıdır.

Roller ve RACI

Küçük bir şirkette bu rollerin çoğu aynı kişilerde toplanır; önemli olan her işin tek bir sorumlusunun olması. Önerilen yapı: CTO ya da mühendislik lideri başkanlığında, ürün, güvenlik, hukuk/DPO ve bir iş birimi temsilcisinden oluşan, ayda bir 30 dakika toplanan küçük bir AI yönetişim grubu.

R = yapan, A = hesap veren (tek kişi), C = danışılan, I = bilgilendirilen

30/60/90 günlük plan

İlk 30 gün: görünürlük

• AI yönetişim grubunu ve tek bir sorumlu (A) kişiyi belirle.
• Gölge AI anketi yap; harcama ve SSO uygulama listesini tara.
• ai-register.yaml dosyasını oluştur, bilinen her sistemi kaydet.
• Bir sayfalık kabul edilebilir kullanım politikasını ve onaylı araçlar listesini yayımla.
• Halka açık araçlara gizli veri girişini durdur; kurumsal plan ya da onaylı API'ye geç.
• #ai-olay kanalını aç.

31-60 gün: kontrol

• Her sistemi karar ağacıyla sınıflandır; yasak ya da yüksek risk adaylarını hukuka götür.
• Orta ve yüksek riskli sistemler için sistem kartı yaz.
• Ana LLM sağlayıcıları için tedarikçi kontrol listesini doldur; DPA ve aktarım dayanağını (GDPR SCC / KVKK standart sözleşme) tamamla.
• Dışa dönük botlarda md. 50 bildirimi ("AI ile konuşuyorsunuz") ekle.
• PII maskeleme ve merkezi loglamayı devreye al.
• Ajanların yetkilerini gözden geçir: ayrı servis hesabı, salt okunur başlangıç, geri alınamaz eylemlerde onay.
• AI okuryazarlığı oturumunu yap, katılımı kaydet.

61-90 gün: süreklilik

• Her orta/yüksek riskli sistem için eval seti oluştur ve CI'a bağla.
• En riskli sistemde ilk red team çalışmasını yap.
• Gerekli yerlerde DPIA'yı tamamla.
• Olay müdahale prosedürünü yaz ve bir masa başı tatbikatı yap.
• PR şablonuna AI envanteri sorusunu ekle; talep formunu devreye al.
• İlk üç aylık gözden geçirmeyi takvime koy; mevzuat takvimini (2 Aralık 2026, 2 Aralık 2027) gündeme ekle.

Kontrol listesi

Envanter ve sınıflandırma

• Şirketteki her AI sistemi envanterde mi, her birinin bir iş sahibi var mı?
• Her sistemin AI Act rolü (sağlayıcı/deployer) ve risk sınıfı belirlendi mi?
• Ek III alanlarına (işe alım, kredi, sigorta, eğitim...) dokunan bir kullanım var mı, hukuk inceledi mi?

Politika ve insanlar

• Kabul edilebilir kullanım politikası bir sayfada ve herkes biliyor mu?
• Onaylı araçlar listesi plan düzeyinde (kurumsal/bireysel) tutuluyor mu?
• AI okuryazarlığı eğitimi yapıldı ve kaydı tutuluyor mu?

Veri ve tedarikçiler

• LLM sağlayıcılarıyla DPA imzalandı mı; eğitim ve saklama koşulları yazılı olarak doğrulandı mı?
• Yurt dışına veri aktarımı için GDPR ve KVKK dayanağı (ve KVKK standart sözleşme bildirimi) tamam mı?
• RAG indekslerindeki kişisel veriler silme taleplerinde güncelleniyor mu?

Teknik kontroller

• PII maskeleme ve merkezi loglama devrede mi?
• Dışa dönük AI sistemlerinde AI bildirimi var mı?
• Ajanlar ayrı kimlikle, en az yetkiyle, sandbox'ta ve limitlerle mi çalışıyor?
• Geri alınamaz eylemler ve kişiler hakkındaki önemli kararlar insan onayına bağlı mı?
• Eval setleri model/prompt değişikliklerinde otomatik çalışıyor mu?

İzleme ve denetim

• AI olayı tanımlı mı, bildirim kanalı ve sorumlu kişi belli mi?
• Üç aylık gözden geçirme takvimde mi?
• Bir müşteri "AI yönetişiminizi anlatın" dediğinde bir saat içinde gönderebileceğin bir paket var mı?

Kaynaklar ve devamı

Birincil kaynaklar (Ekim 2026 itibarıyla kontrol edildi)

• Regulation (EU) 2024/1689 (AI Act), EUR-Lex
• Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
• AB Komisyonu: GPAI Uygulama Kuralları
• Avrupa Parlamentosu yasama takibi: Digital Omnibus (GDPR önerisi)
• GDPR metni (gdpr-info.eu)
• KVKK: Yurt dışına aktarım
• KVKK: Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)
• TBMM: 2/2234 Yapay Zekâ Kanun Teklifi
• NIST AI Risk Management Framework
• ISO/IEC 42001:2023
• Colorado SB 26-189

Bu sitede

• AI Yönetişimi, EU AI Act, AI Risk Sınıflandırma — kavramlar ve yasal çerçeve.
• NIST AI RMF, ISO/IEC 42001, AI Denetimi — çerçeveler ve denetim.
• Model Kartı, AI ve Veri Gizliliği — dokümantasyon ve veri.
• Guardrails, Human-in-the-loop, Agent Sandbox, Prompt Injection, Halüsinasyon — teknik kontroller ve riskler.
• AI Harness Anatomisi ve System Prompt Rehberi — ajanların ve prompt'ların iç yapısı.