AI Act uyumu bir yayın kapısı değil, sürekli yükümlülüktür

Tez#

Kurumlar uyum işini bildikleri kalıba oturtuyor: bir kontrol listesi, bir onay, bir imza. Bu kalıp ürün güvenliği ve veri koruma alanlarında kısmen çalışıyor çünkü orada da periyodik denetimler var ama ana yük başlangıçta. Yapay zekâ mevzuatında denge tersine dönüyor ve bu ters dönüş uyum programlarının en sık yaptığı yapısal hatayı üretiyor.

Nedeni sistemin doğası. Klasik bir yazılım ürününün davranışı yayından sonra kendiliğinden değişmez; kod aynı kalırsa çıktı aynı kalır. Yapay zekâ sisteminin davranışı ise üç ayrı kanaldan kendiliğinden değişir: temel model sürümü güncellenir, girdi verisinin dağılımı kayar ve kullanıcılar sistemi tasarlanmamış işler için kullanmaya başlar. Yayın günü yapılan bir risk değerlendirmesi, bu üç kanaldan biri hareket ettiği anda eskimiş olur. Bu yüzden mevzuatın izleme ve güncelleme yükümlülükleri bir formalite değil, sistemin doğasına verilmiş doğrudan bir cevap.

Bağlam: tek seferlik ile sürekli yükümlülükler#

Aşağıdaki tablo yükümlülükleri zaman boyutuna göre ayırıyor. Ayrımı yapmadan kurulan bir uyum programı, tüm yükü başlangıca yığar ve sonrasını boş bırakır.

Beşinci satır en çok gözden kaçan. Olay bildirimi yükümlülüğü, neyin "olay" sayıldığı yazılı olmadıkça uygulanamaz. Bir dil modeli sisteminde olay tanımı klasik yazılımdan farklı: servis çökmesi değil, çıktı kalitesinde ciddi bozulma ya da zarar verici bir çıktı. Bu tanım kurum içinde yazılmamışsa, olay gerçekleştiğinde kimse onu olay olarak tanımlamıyor — bildirim yükümlülüğü ihlal edilmiş olmuyor, hiç tetiklenmiyor.

Kanıt: uyumu işletime bağlamak#

Sürekli yükümlülükler ancak mühendislik akışının içine gömüldüğünde sürdürülebilir. Ayrı bir uyum takvimine bağlanan yükümlülük, ilk yoğun dönemde düşer.

1. 1Envanteri canlı tutun

   Sistem envanteri bir tablo değil bir kayıt. Yeni bir yapay zekâ bileşeni devreye girdiğinde envantere girmesi otomatik olmalı.

2. 2Dokümantasyonu sürüm akışına bağlayın

   Teknik dokümantasyon deponun içinde dursun ve önemli değişikliklerde güncellenmesi gözden geçirme koşulu olsun.

3. 3Kayıtları saklama politikasına bağlayın

   Ne kaydedilecek, ne kadar saklanacak, kim erişecek? Üçü yazılmadan kayıt tutma yükümlülüğü karşılanamaz.

4. 4Olay tanımını yazın

   Hangi çıktı kalitesi düşüşü olay sayılır? Eşik yazılı değilse bildirim hiç tetiklenmez.

5. 5Gözetimi ölçün

   İnsan onayı var mı yeterli değil; onayın gerçekten bir inceleme olup olmadığı izlenmeli. Biçimselleşen gözetim gözetim değildir.

6. 6Sağlayıcı sürümünü tetikleyici yapın

   Temel model güncellendiğinde risk değerlendirmesi ve dokümantasyon otomatik olarak gözden geçirme kuyruğuna girsin.

Altıncı adım en az uygulanan ama en yüksek getirili olanı. Sağlayıcı model sürümü habersiz güncellenebilir ve bu güncelleme sistemin davranışını değiştirir; dolayısıyla risk değerlendirmesini geçersizleştirir. Bu tetikleyiciyi kurmak teknik olarak basit — sürüm kimliğini kaydedip değişimi izlemek — ama uyum programlarında neredeyse hiç bulunmuyor.

Mekanizma: neden envanter her şeyin önünde#

Uyum programlarında sıralama hatası neredeyse evrensel: politika yazmakla başlanıyor. Politika önemli ama uygulanacağı kümeyi bilmeden yazılan politika bir metin olarak kalıyor. Hangi sistemlerin var olduğu bilinmeden risk sınıflandırması yapılamaz, dolayısıyla hiçbir yükümlülük eşlenemez.

Envanterin en çok kaçırılan bölümü kurumun kendi geliştirdiği sistemler değil; satın alınan araçlar ve ekiplerin kendi başına kullanmaya başladığı servisler. Bir pazarlama ekibinin abone olduğu içerik üretim aracı, bir destek ekibinin kurduğu sohbet eklentisi, bir analistin kullandığı veri özetleme servisi — üçü de envanterde görünmüyor ve üçü de kurum verisi işliyor. Envanter bu kümeyi kapsamıyorsa, uyum programı kurumun gerçek yapay zekâ kullanımının bir bölümünü hiç görmüyor demektir.

Karşı görüş#

İki itiraz güçlü. Birincisi: sürekli yükümlülük modeli küçük kurumlar için taşınamaz bir yük; kapı modeli pragmatik bir uzlaşma. İkincisi: mevzuatın uygulanma biçimi henüz oturmadı ve denetim pratiği büyük ölçüde belgeye bakıyor, sürekliliğe bakmıyor — yani kapı modeli fiilen yeterli olabilir.

Uyum dosyasını hazırladık, denetimde sorun çıkmadı. Ama altı ay sonra kendi dosyamızı okuduk ve anlattığı sistemin artık var olmadığını gördük.

Alıntı ikinci itirazın sınırını gösteriyor: denetimden geçmek ile uyumlu olmak aynı şey değil ve fark denetim pratiği olgunlaştıkça kapanır. Ama daha önemlisi, sürekli yükümlülüklerin gerekçesi denetim değil: kayıt tutmayan bir sistemde bir zarar gerçekleştiğinde neyin olduğu gösterilemez ve bu, denetimden bağımsız bir sorumluluk riski. Birinci itiraz için ise nüans var: sürekli yükümlülük ayrı bir ekip gerektirmiyor, mevcut mühendislik akışına gömülebiliyor. Envanteri canlı tutmak bir kayıt alanı, dokümantasyonu güncel tutmak bir gözden geçirme koşulu, sürüm tetikleyicisi bir izleme kuralı. Üçü de ayrı bir uyum takvimi değil, var olan akışın parçası.

Sınırlar ve belirsizlik#

Bu analiz hukuki görüş değil; mevzuat yorumu uzman incelemesi gerektirir ve aşağıdaki noktalar açık kalıyor.

• Denetim pratiği oluşuyor: yükümlülüklerin nasıl denetlendiği ülkeye ve sektöre göre değişiyor; bu analiz metne bakıyor, pratiğe değil.
• Risk sınıfı yorumu tartışmalı: aynı sistemin hangi sınıfa girdiği kullanım amacına göre değişiyor ve sınırlar her zaman net değil.
• Küçük kurum yükü ölçülmemiş: sürekli yükümlülüklerin gerçek maliyeti kurum büyüklüğüne göre nicelenmedi.
• Olay tanımı standart değil: çıktı kalitesinde hangi düşüşün bildirim gerektirdiğine dair yerleşik bir eşik yok.

Sonuç#

Uyumu bir kapı olarak kurmak, yükün büyük bölümünü yayın gününe yığıp sonrasını boş bırakıyor. Oysa yükümlülüklerin ağırlık merkezi yayından sonra: sistem davranışı kendiliğinden değiştiği için değerlendirme de kendiliğinden eskiyor.

Uygulanabilir çerçeve, uyumu bir işletim biçimine çevirmek: envanter canlı, dokümantasyon depoda, kayıtlar saklama politikasına bağlı, olay tanımı yazılı ve sağlayıcı sürüm değişimi bir gözden geçirme tetikleyicisi. Bu beş öge kurulduğunda uyum ayrı bir proje olmaktan çıkıp mühendislik akışının bir özelliği hâline geliyor — ve yalnızca o zaman sürdürülebilir oluyor.

Ne yapmalı?#

1. 1Envanterden başlayın, politikadan değil

   Hangi sistemlerin var olduğu bilinmeden hiçbir yükümlülük eşlenemez. Satın alınan araçlar ve ekiplerin kendi kullandığı servisler de envanterde olmalı.

2. 2Dokümantasyonu depoya taşıyın

   Ayrı bir belge sisteminde duran dokümantasyon güncel kalmaz. Kodun yanında dursun, gözden geçirmede güncellenmesi koşul olsun.

3. 3Olay tanımını yazın ve duyurun

   Hangi kalite düşüşü olay sayılır, kim bildirir, hangi süre içinde? Yazılmamış tanım hiç tetiklenmez.

4. 4Sağlayıcı sürümünü izleyin

   Model sürüm kimliğini kaydedin ve değişimi gözden geçirme kuyruğuna bağlayın. Teknik olarak basit, uyum açısından belirleyici.

5. 5Gözetimin gerçekliğini ölçün

   Onay sayısı değil, onaya ayrılan süre ve düzeltme oranı izlenmeli. Biçimselleşen gözetim yükümlülüğü karşılamaz.

6. 6Hukuk incelemesini rutin yapın

   Bu analiz hukuki görüş değildir. Risk sınıflandırması ve belge kapsamı uzman incelemesinden geçmeli.