Yapay zekâ (AI) sistemleri eğitim, çevrim içi sözlükler ve referans platformları dâhil pek çok üründe artık “çekirdek özellik” haline geldi. Bu dönüşüm; arama, özetleme, kişiselleştirme ve içerik üretimi gibi faydalar sağlarken güvenlik açıkları, etik riskler, veri yönetişimi sorunları ve uyum yükümlülüklerini de beraberinde getirir. Bu yazı, teknik ekiplerden bağımsız olarak karar vericilerin (ürün sahipleri, yöneticiler, okul/kurum liderleri, hukuk-uyum paydaşları) kullanabileceği pratik bir kontrol listesi sunar.

Not: Bu içerik hukuki danışmanlık değildir. Kurumunuzun risk profiline, sektörüne ve faaliyet gösterdiği ülkelere göre hukuk/uyum uzmanlarıyla birlikte değerlendirme yapmanız gerekir.

Neden “etik” ve “güvenlik” aynı toplantıda konuşulmalı?

AI projelerinde etik ve güvenlik bazen ayrı başlıklarda ele alınır; oysa pratikte birbirini etkiler. Örneğin “yanıltıcı çıktı” riski hem kullanıcıya zarar verme ve güven kaybı (etik) hem de saldırganların manipülasyonu (güvenlik) ile ilgilidir. Karar verici açısından hedef şudur: “Model ne kadar iyi?” sorusunun yanına “Ne zaman, kimlere, hangi koşullarda risk üretir?” sorusunu sistematik biçimde eklemek.

Çerçeve: NIST AI RMF ve TEVV ile kontrol listesini yapılandırma

NIST’in AI Risk Management Framework (AI RMF) dokümanı, AI risk yönetimini kurum çapında ele almayı ve kullanım senaryosuna göre “profil” oluşturmayı öneren gönüllü bir çerçevedir. Pratikte bu, dört fonksiyon etrafında kanıt üreten bir işletim modeli kurmak anlamına gelir: yönetişim, haritalama, ölçme ve yönetme (GOVERN / MAP / MEASURE / MANAGE).

Bu yazıda sık geçecek bir kısaltma: TEVV = Test, Değerlendirme, Doğrulama, Geçerleme (İng. Testing, Evaluation, Verification, Validation). Amaç, “yayına aldık” demeden önce kabul kriterlerini netleştirmek ve bu kriterleri kanıtla desteklemektir.

Karar vericiler için “tek sayfa” kontrol listesi

Aşağıdaki kontrol listesi, eğitim ve e-öğrenme gibi kullanıcıyla doğrudan etkileşimi olan ürünler ile kurum içi otomasyon projeleri için uyarlanabilir. Her maddede amaç, sadece “var/yok” değil, kanıtlanabilir çıktı üretmektir (dokümantasyon, test raporu, izleme panosu, onay kaydı gibi).

Alan Karar verici soruları Beklenen kanıt/çıktı
1) Kullanım senaryosu ve kapsam AI ne yapıyor, ne yapmıyor? Hangi kullanıcı grupları etkileniyor? Yüksek riskli karar var mı? Kapsam dokümanı, dışlama listesi, kullanıcı segmentleri
2) Veri yönetişimi Veri kaynakları ve lisanslar net mi? Kişisel veri akışı, saklama/silme ve erişim kuralları tanımlı mı? Veri envanteri, veri akış diyagramı, saklama/silme prosedürü, erişim matrisi
3) Risk haritalama ve tehdit modelleme Adversarial riskler (prompt injection vb.) nerede mümkün? Saldırı yüzeyi ve kritik varlıklar neler? Tehdit modeli, risk kayıt defteri, önceliklendirme
4) TEVV planı Hangi testlerden geçmeden canlıya çıkmıyor? Go/no-go eşikleri ve yeniden test tetikleri var mı? TEVV planı, test senaryoları, kabul kriterleri, sonuç raporu
5) Açıklanabilirlik ve kullanıcı şeffaflığı Kullanıcıya neyi, ne zaman açıklıyoruz? Sınırlılıkları nasıl iletiyoruz? Kullanıcı bilgilendirmeleri, model/özellik notları, sınırlılık beyanı
6) İzleme, geri bildirim ve olay yönetimi Zararlı çıktı veya kötüye kullanım nasıl yakalanır? “Ciddi olay” eşiği nedir? İzleme metrikleri, olay sınıflandırma, eskalasyon ve raporlama akışı
7) Tedarikçi ve üçüncü taraflar Sağlayıcı hangi güvenceleri veriyor? Denetim ve çıkış planı var mı? Vendor risk değerlendirmesi, sözleşmesel güvence başlıkları, çıkış planı

1) Kullanım senaryosu ve kapsam: “yapılacaklar” ve “yapılmayacaklar”

En sık görülen yönetim hatası, AI’yı tek bir özellik gibi ele alıp “hangi kararları etkilediğini” netleştirmemektir. Özellikle eğitim/edtech ürünlerinde, AI çıktıları öğrencinin öğrenme planını, öğretmenin değerlendirme yaklaşımını veya kullanıcıların bilgiye erişim biçimini etkileyebilir.

Kontrol soruları

  • Karar etkisi: AI bağlayıcı bir karar mı üretiyor (kabul/ret, notlandırma vb.) yoksa yalnızca öneri mi?
  • Hedef kullanıcı: Çocuklar/öğrenciler gibi hassas gruplar var mı?
  • Hata toleransı: Yanlış bir öneri, hangi seviyede zarara yol açabilir?

Beklenen kanıtlar

  • Kapsam dokümanı: “ne yapar / ne yapmaz” maddeleri
  • Out-of-scope listesi: AI’nın kullanılmayacağı kararlar ve içerikler
  • Risk sınıfı etiketleme: düşük/orta/yüksek etki alanları

2) Veri yönetişimi: envanter, lisans, kişisel veri akışı, saklama/silme

Veri yönetişimi, etik ve güvenliğin ortak zemini olduğu için karar vericinin “kanıt” talep edebileceği en somut alandır. Amaç, hem ürün içi veri akışını hem de üçüncü taraf paylaşımını netleştirmek ve kontrol altında tutmaktır.

Kontrol soruları

  • Veri kaynağı ve lisans: Veri nereden geliyor, hangi lisans/izin koşullarıyla kullanılıyor?
  • Kişisel veri (PII) akışı: PII nerede oluşuyor, nerede işleniyor, kim erişebiliyor?
  • Saklama/silme: Loglar ve eğitim verileri ne kadar tutuluyor, ne zaman ve nasıl siliniyor?
  • Üçüncü taraf paylaşımı: Harici model/API kullanılıyorsa, hangi veri hangi şartla dışarı çıkıyor?

Karar verici dostu somut örnekler (genel, bağlayıcı olmayan)

  • Örnek veri envanteri satırı: “Kullanıcı soru-günlükleri” | Alanlar: soru metni, zaman damgası, cihaz türü | PII: olabilir (kullanıcı adını yazabilir) | Amaç: kalite iyileştirme | Saklama: kurum politikasıyla sınırlı | Erişim: yalnızca yetkili ekip.
  • Örnek lisans kontrolü: Sözlük/ansiklopedi içerikleri üçüncü taraf kaynaktan alınıyorsa, “AI eğitiminde kullanılabilir mi?” sorusu lisans koşullarında açıkça kontrol edilir; belirsizse “eğitim dışı” olarak işaretlenir.
  • Örnek PII akışı sorusu: “Öğrenci e-postası” veya “ödev metni” harici bir modele gönderiliyor mu? Gönderiliyorsa maskeleme/anonimleştirme ve onay mekanizması var mı?
  • Örnek saklama/silme kanıtı: Silme talebi geldiğinde (kullanıcı/kurum), hangi sistemlerden hangi süre içinde silindiğini gösteren iç kayıt (ticket + log).

Beklenen kanıtlar

  • Veri envanteri ve sahiplik (data owner) listesi
  • Veri akış diyagramı (ürün içi + üçüncü taraflar)
  • Saklama/silme prosedürü ve erişim matrisi

3) Risk haritalama ve tehdit modelleme: adversarial riskler ve “prompt injection”

Adversarial riskler, modelin veya entegrasyonun “normal olmayan” girdilerle istenmeyen davranış üretmesine yol açabilir. NLP bağlamında bu tehdit sınıflarına genel bir bakış için akademik değerlendirme: Adversarial natural language processing: overview, challenges, and policy implications. Kurumsal açıdan pratik hedef, tehdit modelini yaşayan bir doküman yapmak ve savunmaları “tek filtre” yerine katmanlı tasarlamaktır.

Bu yazıda prompt injection terimini kullanacağız (bazı ekiplerde prompt manipülasyonu olarak da geçer): Kullanıcının girdisiyle modelin talimat hiyerarşisini bozarak, politika dışı veya veri sızdıran çıktılara zorlanması.

Pratik risk sınıfları

  • Evasion/manipülasyon: Girdiyi değiştirerek istenmeyen çıktıyı tetikleme (prompt injection dâhil).
  • Veri zehirleme: Eğitim/veri toplama sürecine kötü niyetli örnekler sızdırma olasılığı.
  • Backdoor: Belirli bir tetikleyiciyle model davranışını “gizli” biçimde değiştirme riski.

Minimum savunma paketi (ürün sahibinin talep edebileceği)

  • Tehdit modellemesi: saldırgan profili, varlıklar (veri, model, API anahtarları), saldırı yüzeyleri.
  • Girdi/çıktı kontrolleri: politika ihlali ve veri sızıntısı sinyalleri için katmanlı kontroller.
  • Erişim ve yetki: yönetici özellikleri, log erişimi, model yapılandırması için en az ayrıcalık.
  • Güvenlik testleri: red teaming / senaryo testleri; sonuçların canlıya çıkış kriterlerine bağlanması.

AI çağında siber güvenlik varsayımlarının yeniden ele alınması gerektiğine dair NIST duyurusu (Cyber AI Profile taslağına işaret eder): Draft NIST Guidelines Rethink Cybersecurity for the AI Era. Ayrıca çok katmanlı yaklaşımların pratikte öne çıktığını vurgulayan derleme niteliğinde bir kaynak: International AI Safety Report 2026.

4) TEVV planı: “hazır” saymadan önce eşikleri tanımlayın

TEVV, “tek seferlik test” değil; sürüm güncellemeleri, veri değişimi ve yeni kullanım senaryolarında tekrarlanan bir disiplindir. Ortak metriklerin her zaman net olmaması durumunda bile karar verici olarak hedefiniz, asgari bir TEVV sözleşmesi oluşturmak ve zamanla olgunlaştırmaktır.

TEVV planı için kısa şablon

  • Test kapsamı: Normal kullanım + kötüye kullanım + sınır durumlar (edge cases).
  • Kalite metrikleri: Göreve uygun ölçüler (ör. cevap doğruluğu yerine “kabul edilebilir hata türleri” ve tutarlılık).
  • Güvenlik metrikleri: Prompt injection dayanıklılığı, veri sızıntısı denemeleri, politika ihlali oranları.
  • Eşikler: Go/no-go barajları ve istisna/onay mekanizması.
  • Yeniden test tetikleri: Model sürümü, istem (prompt) şablonu, veri kaynağı veya güvenlik kontrolü değiştiğinde tekrar test.

Karar verici dostu TEVV örnekleri (genel, bağlayıcı olmayan)

  • Örnek test seti: 50 normal kullanıcı senaryosu + 20 kötüye kullanım senaryosu (prompt injection, veri sızdırma denemesi, uygunsuz içerik talebi) + 10 sınır durum (çok uzun metin, çelişkili talimatlar).
  • Örnek “0 tolerans” alanları: Çocuk güvenliği, açık kişisel veri ifşası, şiddet/nefret içeriği gibi kritik politika ihlallerinde testlerde “kabul edilemez” sınıfı (go/no-go).
  • Örnek kademeli eşik: “Düşük etkili” hata türlerinde belirli bir oran üstünde artış olduğunda (ör. sürüm bazında belirgin sıçrama) yayını durdurma ve kök neden analizi tetikleme.
  • Örnek yeniden test kuralı: Yeni bir veri kaynağı eklendiğinde veya filtre kuralı değiştiğinde, en azından ilgili senaryoların yeniden çalıştırılması.

Operasyonel olarak “eşik göstergeleri” ve değerlendirme tetikleri tasarlamaya dair bir endüstri örneği: Microsoft Frontier Governance Framework. (Bu bir şirket çerçevesidir; standart yerine operasyonel fikir kaynağı olarak düşünülmelidir.)

5) Açıklanabilirlik ve kullanıcı şeffaflığı: gerekli olabilir, tek başına yeterli değildir

Ürün ekipleri bazen “açıklanabilirlik ekledik, o hâlde güvenliyiz” varsayımına kayabilir. Oysa açıklama mekanizmalarının da saldırılara açık olabileceği ve bu yüzden açıklanabilirliğin TEVV ve güvenlik kontrolleriyle birlikte ele alınması gerektiği tartışılır: Adversarial attacks and defenses in explainable artificial intelligence: A survey.

Uygulanabilir yaklaşım

  • Kullanıcı şeffaflığı: Kullanıcıya AI ile etkileşimde olduğunu, sınırlılıkları ve uygun kullanım beklentilerini net söyleyin.
  • Operasyonel açıklama: İç ekipler için “model nerede ve nasıl başarısız olur?” sorusuna cevap veren hata analizi raporları üretin.
  • Güvenlik ayrı katman: Açıklanabilirliği güvenlik duvarı gibi konumlamayın; izleme, erişim kontrolü ve TEVV ile tamamlayın.

Şeffaflık ve raporlama: gönüllü çerçeveler ve düzenleyici beklentiler

Şeffaflık iki motivasyonla gündeme gelir: (1) güven inşası ve hesap verebilirlik, (2) uyum beklentileri. OECD’nin HAIP çalışması, geliştiricilerin risk raporlamasında farklı yaklaşımlar benimsediğini ve pilot dönemde gönüllü raporlamaların başladığını inceler: How are AI developers managing risks? (OECD).

AB bağlamında ise EU AI Act – Code of Practice overview sayfası, genel amaçlı yapay zekâ (GPAI) için hazırlanan “Code of Practice” yaklaşımına dair bir genel bakış sunar. Bu tür dokümanların statüsü (taslak/nihai), kapsamı ve bağlayıcılık düzeyi zaman içinde netleşebileceği için, bu yazı bunu “uygulamaya dönük referans” olarak ele alır; bağlayıcı hukuki yükümlülük yorumu için güncel hukuki değerlendirme gerekir.

6) İzleme, geri bildirim ve olay yönetimi: AI’ya özel eşikler belirleyin

Klasik siber olay yönetimi süreçleri iyi bir temel sağlar; ancak AI’nın çıktı kaynaklı riskleri (zararlı öneriler, uygunsuz içerik, veri sızıntısı) farklı tetikleyiciler gerektirebilir. Buradaki amaç, “tekil şikâyet” ile “ciddi olay” ayrımını önceden tanımlamak ve hızlı müdahale edebilmektir.

Uygulanabilir olay yönetimi akışı

  1. Tespit: Kullanıcı raporları + otomatik sinyaller (ani ihlal artışı, olağandışı istek kalıpları, veri sızıntısı denemeleri).
  2. Sınıflandırma: Güvenlik, etik, veri, uyum gibi kategoriler; etki/olasılık değerlendirmesi.
  3. Müdahale: Özelliği kısıtlama, model sürüm geri alma, ek filtre, erişim anahtarı rotasyonu.
  4. Kök neden analizi: Prompt şablonları, veri kaynağı, model güncellemesi veya entegrasyon hatası.
  5. Önleme: TEVV kapsamını genişletme, yeni izleme metrikleri, politika güncellemesi.

7) Tedarikçi ve üçüncü taraflar: “model satın almak” risk devri değildir

Üçüncü taraf model/API kullanıyor olsanız bile, kullanıcıya sunulan deneyimin ve risk yönetiminin sorumluluğu çoğu zaman ürün sahibinde kalır. Bu nedenle tedarikçi yönetimini yalnızca maliyet/performans açısından değil, güvence ve doğrulama açısından da ele alın.

Sözleşme ve operasyon için istenebilecek başlıklar (örnek)

  • Dokümantasyon: Model/özellik notları, bilinen sınırlamalar, güncelleme politikası.
  • Güvenlik: Erişim kontrolü, loglama, anahtar yönetimi, kötüye kullanım tespiti.
  • Değerlendirme: Test raporları, bağımsız güvence/denetim opsiyonu (mümkünse).
  • Olay bildirimi: Ciddi olaylarda bildirim süresi ve paylaşılacak asgari bilgiler.
  • Çıkış planı: Sağlayıcı değişiminde veri taşınabilirliği ve hizmet sürekliliği.

Örnek: Eğitim / çevrim içi sözlük ürününde hızlı uygulama planı (30 gün)

Aşağıdaki plan, küçük-orta ekiplerin başlangıç seviyesinde bir kontrol seti kurması için örnektir. Kurumun büyüklüğüne ve riskine göre kapsam genişletilebilir.

1. Hafta: Kapsam + veri envanteri

  • Kullanım senaryosu belgesi (ne yapar/ne yapmaz) ve kullanıcı segmentleri.
  • Veri envanteri taslağı + veri akış diyagramının ilk sürümü.

2. Hafta: Tehdit modeli + TEVV taslağı

  • Risk kayıt defteri ve ilk tehdit modeli (prompt injection dâhil).
  • Normal/kötüye kullanım/sınır durum test senaryoları ve ilk go/no-go eşikleri.

3. Hafta: İzleme + olay akışı

  • Olay sınıflandırma tablosu ve eskalasyon sorumluları.
  • Minimum izleme metrikleri: politika ihlali sinyalleri, şikâyet türleri, anomali istekleri.

4. Hafta: Şeffaflık + dokümantasyon + tedarikçi kontrolleri

  • Kullanıcıya yönelik “AI kullanımı ve sınırlılıklar” metni.
  • İç dokümantasyon: değişiklik günlüğü, TEVV raporu, risk karar kayıtları.
  • Üçüncü taraf kullanılıyorsa vendor risk değerlendirmesi ve çıkış planı taslağı.

Sık yapılan yönetim hataları (ve daha iyi alternatifler)

  • Hata: “Açıklanabilirlik ekledik, tamamdır.”
    Alternatif: Açıklanabilirlik + TEVV + izleme + olay yönetimini birlikte tasarlayın.
  • Hata: Güvenliği sadece sızma testi olarak görmek.
    Alternatif: Adversarial senaryoları düzenli test setine alın; tehdit modelini yaşayan doküman yapın.
  • Hata: Tedarikçi kullanınca riskin “taşındığını” düşünmek.
    Alternatif: Dokümantasyon, olay bildirimi ve değerlendirme gereksinimlerini sözleşme ve operasyon planına bağlayın.

Sonuç: Kontrol listesi bir belge değil, bir işletim sistemi

Yapay zekâ etik ve güvenlik programı, tek seferlik bir uyum belgesi değil; sürekli ölçme ve iyileştirme döngüsüdür. Karar verici olarak en güçlü kaldıraçlarınız: kapsamı netleştirmek, veri ve test kanıtı istemek, eşik belirlemek ve olaylara hazırlıklı olmaktır.