AI Act risk sınıflandırması yapmak

Envanterin birimi model değil kullanım amacıdır. Aynı dil modeli kurumda üç ayrı akışta çalışıyorsa envanterde üç satır bulunur, çünkü sınıflandırma her birinde farklı sonuç verebilir. Envanteri teknik ekip tek başına dolduramaz: "bu sistem kimin hakkında karar veriyor" sorusunun cevabı iş biriminde durur, kod tabanında değil.

Rol, yükümlülüğün adresini belirler. Sınıf aynı kalsa bile rol değiştiğinde yapılacak iş baştan aşağı değişir: sağlayıcıdan teknik dokümantasyon ve uygunluk değerlendirmesi beklenirken, uygulayıcıdan kullanım amacına sadakat, insan gözetimi ve kayıt saklama beklenir.

Rolü kaydıran üç eylem var: sistemi kendi markanızla sunmak, sağlayıcının tanımladığı kullanım amacının dışında kullanmak ve sistemde esaslı değişiklik yapmak. Üçü de uygulayıcıyı fiilen sağlayıcı konumuna taşıyabilir. Bu, sözleşmedeki başlıkla değil fiiliyatla belirlenir; sözleşmede "kullanıcı" yazması tek başına bir şey ifade etmez.

Bu tarama diğerlerinden önce gelir, çünkü sonucu "uyum planı" değil "durdurma" olabilir. Sıralamayı bozup önce yüksek risk çalışması yapan ekipler, haftalarca belge üretip sonunda sistemi kapatmak zorunda kalıyor. Tarama ucuzdur; yanlış sırayla yapılan çalışma pahalıdır.

• Sistem, kişilerin davranışını bilinçaltı veya manipülatif tekniklerle yönlendiriyor mu?
• Yaş, engellilik veya sosyoekonomik durum gibi kırılganlıkları istismar ediyor mu?
• Kişileri sosyal davranışlarına göre genel amaçlı puanlayıp ilgisiz alanlarda aleyhlerine sonuç doğuruyor mu?
• Biyometrik veriden hassas kategoriler çıkarıyor mu?
• Kolluk amacıyla, kamuya açık alanda gerçek zamanlı uzaktan biyometrik kimlik tespiti yapıyor mu? Kolluk dışı kullanım yasak değil, yüksek risk adayıdır.
• İşyerinde veya eğitim ortamında duygu tanıma yapıyor mu?

Sınıflandırmayı modelden başlatmak en sık yapılan hata. Model, sınıfın belirleyeni değil bileşenidir; belirleyen, çıktının hangi karara girdiğidir. Aynı sağlayıcının aynı sürümü bir akışta insan hakkında eleme kararı üretiyorsa yüksek risk adayı, başka bir akışta iç toplantı notu özetliyorsa asgari risktir.

1. 1Yasak listesinde mi?

   Evet ise sınıflandırma orada biter; sistem kullanılmaz, uyum planı üretilmez.

2. 2Bir ürünün güvenlik bileşeni mi?

   Ürün mevzuatı kapsamındaki güvenlik işlevleri yüksek riske işaret eder; ürün tarafındaki uygunluk süreciyle birlikte değerlendirilir.

3. 3Ek III alanlarından birinde mi?

   İstihdam, eğitim, kredi, temel hizmetlere erişim, kolluk, göç ve adalet gibi alanlar yüksek risk adayıdır.

4. 4İnsanla etkileşiyor veya sentetik içerik üretiyor mu?

   Şeffaflık yükümlülüğü doğar: kullanıcı bir yapay zekâ ile konuştuğunu bilmeli, üretilen içerik işaretlenmeli.

5. 5Hiçbiri değil mi?

   Asgari risk; yine de gerekçeyi yazıp envantere işleyin, çünkü sınıfın kendisi değil gerekçesi denetlenir.

Sınıflandırmanın çıktısı sınıf değil gerekçedir. "Yüksek risk değil" cümlesi tek başına denetimde bir şey ifade etmez; hangi alanın hangi ölçütle dışarıda kaldığı, kimin karar verdiği ve kararın hangi tarihte alındığı yazılmalıdır. Gerekçesiz kararlar, tek bir soru sorulduğunda tüm envanterin yeniden açılmasına yol açıyor.

Genel amaçlı model ile o modeli kullanan sistem ayrı yükümlülük başlıklarıdır. Modeli eğiten taraf teknik dokümantasyon, eğitim verisi özeti ve telif politikasıyla; modeli bir uygulamaya gömen taraf ise kullanım amacı, insan gözetimi ve kayıt tutmayla sorumludur. Aradaki bağ sözleşmedir: sağlayıcının ürettiği belgeye erişiminiz yoksa kendi dosyanızı tamamlayamazsınız.

• Teknik dokümantasyon ve entegrasyon için yeterli bilgi
• Eğitim verisi hakkında yayımlanan özet
• Telif hakkı politikası ve metin-veri madenciliği ayrılma sinyallerine uyum beyanı
• Bilinen sınırlar, değerlendirme sonuçları ve uygulanan güvenlik önlemleri
• Sürüm değişikliği ve kullanımdan kaldırma bildirimi taahhüdü
• Olay bildirimi ve destek kanalı

Düzenleme kademeli yürürlüğe giriyor: yasak uygulamalar, genel amaçlı model yükümlülükleri, yüksek risk yükümlülükleri ve belirli ürün kategorileri farklı tarihlerde uygulanmaya başlıyor. Tarihleri bu rehberden almayın. İkincil kaynaklar sık sık eski takvimi taşır ve bir kurumu hazırlıksız bir yükümlülüğün içine sokar; kopyayı resmî metinden ve hukuk biriminizden yapın.

Uyumun teknik karşılığı üç yetenekte toplanıyor: her çıkarımın izlenebilir olması, verinin kaynağının ve amacının belgelenmiş olması, insan gözetiminin gerçek bir müdahale yeteneğine karşılık gelmesi. Üçü de iyi kurulmuş bir LLMOps yığınının zaten ürettiği çıktılar; uyum çalışması çoğu kurumda yeni bir altyapı değil, var olanın belgelenmesi oluyor.

{
  "olay_kimligi": "ik-on-eleme-2026-09-15-004812",
  "sistem_kimligi": "ik-on-eleme",
  "model": "saglayici/model-adi",
  "model_surumu": "saglayicinin-bildirdigi-surum-etiketi",
  "istem_surumu": "v7",
  "girdi_ozeti": "sha256:...",
  "cikti_ozeti": "sha256:...",
  "karar": "insan-incelemesine-yonlendirildi",
  "insan_mudahalesi": {
    "kullanici": "ik-uzmani-14",
    "sonuc": "reddedildi",
    "gerekce": "aday deneyimi ilan kriterini karşılamıyor"
  },
  "zaman": "2026-09-15T09:12:44Z"
}

Sınıflandırma bir anlık fotoğraftır ve sistemler duruyor gibi görünürken değişir: bir pilot üretime alınır, bir iç araç müşteriye açılır, bir öneri motorunun çıktısı fiyat kararına girdi olur. Bu değişikliklerin hiçbiri kod incelemesinde "uyum konusu" gibi görünmez; bu yüzden tetikleyiciler önceden yazılır.

• Kullanım amacının veya kullanıcı kitlesinin değişmesi
• Model veya sağlayıcı değişikliği
• Sistem çıktısının yeni bir karara girdi olması
• İnsan gözetimi noktasının kaldırılması veya otomatikleştirilmesi
• Yeni bir coğrafyada hizmete açılma
• Resmî rehber veya uyumlaştırılmış standart yayımlanması

Her gözden geçirmede sınıf değişmese bile tarih, karar verenin adı ve "değişiklik yok" notu yazılır. Denetimde sorulan soru "sınıf doğru mu" değil, "bu sınıfa nasıl karar verdiniz ve en son ne zaman kontrol ettiniz" oluyor. İkinci sorunun cevabı bir tarihtir; tarih yoksa cevap da yoktur.