AB AI Act: ürün ve tedarik için uyum öncelikleri

Avrupa Birliği’nin yapay zekâ düzenlemesi (AI Act) birçok yönetim masasında hâlâ “Brüksel metni” gibi duruyor. Pratikte ise metin, hukuk departmanının raftaki dosyasından önce ürün ve tedarik listesine iner. Soru “Bu yasa bizi ilgilendiriyor mu?” olmaktan çıkar; “Hangi sistemimiz hangi risk sınıfına yakın, hangi tedarikçi neyi kanıtlayacak, hangi doküman eksik?” haline gelir.

Bu yazı hukuki mütalaa değildir. Amaç, yöneticinin AI Act’i nitel bir çerçeve olarak okuması ve öncelik listesi çıkarmasıdır. Takvim maddeleri ve uygulama tarihleri değişebilir veya sektöre göre farklılık gösterebilir. Kesin tarih ve yükümlülük için yöneticilerin resmi EUR-Lex metnini ve güncel resmi zaman çizelgesini doğrulaması gerekir; bu taslakta uydurma son tarih verilmez.

AI Act’i “IT güvenlik politikası ekleri”ne indirgemek de yanlıştır. Düzenleme, özellikle yüksek riskli kullanımlarda ürün yönetimi, veri yönetimi, insan gözetimi, olay kaydı ve tedarik zinciri şeffaflığını birlikte ister. Bu yüzden uyum bir checklist yarışı değil; ürün ve satın alma disiplininin parçasıdır. Aynı disiplin, Avrupa pazarına dolaylı etki eden tedarik zincirlerinde de konuşulmalıdır: müşteri Avrupa’daysa, veri Avrupa’daysa veya karar Avrupa’daki kişiyi etkiliyorsa “biz AB şirketiyiz değiliz” cümlesi tek başına kalkan olmayabilir. Etki analizi iş birimiyle birlikte yapılır.

Risk sınıfları

Çerçeve, yapay zekâ sistemlerini risk düzeyine göre ayırır. Yönetici dilinde bu ayrım şunu söyler: Her AI aynı değildir; yasak, yüksek risk, sınırlı risk ve düşük veya asgari risk yakınlıkları farklı yük getirir. Sınıflandırma tartışması hukukçuya bırakılsa da iş birimleri erken sinyal üretmelidir: Sistem ne yapıyor, kim hakkında karar etkiliyor, hangi ortamda çalışıyor, insan müdahalesi var mı?

Yüksek risk yakınlığı genelde şu sorularla yükselir: Sistem istihdam, kredi veya finansmana erişim, kritik altyapı, temel hizmet erişimi, güvenlik veya benzeri yüksek etkili alanlarda mı kullanılıyor? Çıktı otomatik karar mı üretiyor, yoksa yalnızca taslak mı? Etkilenen kişi itiraz edebiliyor mu? Bu sorulara “evet” veya “emin değiliz” cevabı geliyorsa ürün listesine kırmızı bayrak düşülür; kesin hüküm için uzman görüşü alınır. “Emin değiliz” özellikle değerlidir; çünkü belirsizlik, envanterde görünmeyen risk demektir.

Sınırlı risk ve şeffaflık yükümlülükleri de “küçük iş” değildir. Kullanıcının bir AI ile etkileştiğini bilmesi, belirli içeriklerin işaretlenmesi gibi pratikler ürün deneyimine ve iletişime dokunur. Pazarlama “görünmez AI”yı özellik sanırken düzenleme görünürlüğü isteyebilir. Bu gerilim ürün tasarımında erken çözülmelidir. Aksi halde son anda eklenen uyarı metinleri hem deneyimi bozar hem de samimiyetsiz görünür.

Yasaklanan pratiklere yakınlık ayrı bir alarmdır. Biyometrik ve manipülatif kullanımlara dair yasak hatları metinde çerçevelenir; yönetici burada “biz yapmıyoruz” demeden önce kullanım senaryolarını envantere yazmalıdır. Gölge AI ve yan projeler envanter dışındaysa risk sınıfı tartışması eksik kalır. Pilot adı altında yapılan yüz tanıma denemesi veya çalışan izleme aracı, marka riski kadar düzenleyici risk de taşır.

Sınıflandırma bir kerelik etiket değildir. Model güncellenir, kullanım amacı kayar, aynı motor yeni bir sürece bağlanır. Bu yüzden risk sınıfı ürün yaşam döngüsüne bağlanır: amaç değişince yeniden bakılır. “Geçen yıl düşük risk dedik” cümlesi, bu yılın kullanımını otomatik temizlemez. Ürün komitesinde AI maddesi, yol haritası maddesi kadar olağan hale gelmelidir.

Takvim okuma

Takvim, uyum programının omurgasıdır; ama yanlış okunan takvim yanlış öncelik üretir. AI Act gibi çerçevelerde yükümlülükler kademeli devreye girebilir; bazı hükümler daha önce, bazıları daha sonra uygulanır. Bu yüzden yönetici tek bir “uyum günü” aramamalı; yükümlülük gruplarına göre yol haritası bakmalıdır.

Bu taslakta somut son tarihler uydurulmaz. Doğru davranış şudur: Resmi metni EUR-Lex üzerinden okuyun, kurumunuzun danışmanından veya iç hukuk biriminden güncel uygulama takvimini isteyin, sektörel rehberleri izleyin. Medyadaki özet kartları hızlı oryantasyon sağlar; bağlayıcı kaynak değildir. Danışman sunumundaki tarih ile resmi metin çelişiyorsa resmi metin esas alınır, çelişki yazılı sorulur.

Takvim okurken üç soru işe yarar. Birincisi: Bizim envanterimizde yüksek risk adayı var mı? Varsa dokümantasyon ve tedarikçi kanıtı önceliklidir. İkincisi: Şeffaflık yükümlülüğü doğuran kullanıcıya dönük AI var mı? Varsa ürün ve iletişim ekipleri erken devreye girmelidir. Üçüncüsü: Yasak hattına yakın deneme var mı? Varsa derhal durdurma ve değerlendirme gerekir.

Takvimi yalnızca Brüksel saatiyle okumak da yetmez. Şirket içi ürün yol haritası, sözleşme yenileme tarihleri ve denetim takvimi ile hizalanmalıdır. Tedarikçi sözleşmesi yakında yenilenecekse AI Act maddelerini o yenilemeye bırakmak riskli olabilir; pazarlık penceresi kaçabilir. İç geliştirme varsa sürüm planına uyum kapıları eklenir. “Sonra bakarız” çoğu zaman “sözleşme imzalandı, artık zor” anlamına gelir.

Belirsizlik yönetimi de takvimin parçasıdır. Rehberler netleştikçe yorumlar değişebilir. Bu durumda yönetici iki uçtan kaçınır: “Hiçbir şey yapmayalım, netleşsin” ve “Her şeyi abartılı yapalım.” Makul yol, envanter, risk yakınlığı, doküman iskeleti ve tedarikçi sorularını şimdiden kurmak; kesin tarihleri resmi kaynaktan kilitlemektir. Belirsizliği doldurmak için sahte kesin tarih yazmak, programı değil sunumu güçlendirir.

Yüksek risk pratikleri

Yüksek risk adayı sistemlerde pratik, “policy PDF’i yükledik” seviyesinde kalmaz. Ürün sahibi şu disiplinleri görmelidir: amaç ve kullanım sınırları yazılı mı, veri yönetimi net mi, performans ve sağlamlık nasıl sınanıyor, insan gözetimi gerçekten işliyor mu, olay ve şikâyet kanalları var mı? Bu soruların cevabı “kısmen” ise açık madde listesi çıkarılır; Soft PASS yoktur.

İnsan gözetimi özellikle kritiktir. Ekranda “onay” butonu olması gözetim demek değildir. Gözetim; doğru bilginin, yeterli zamanın ve durdurma yetkisinin insanda olmasıdır. Kör onay üreten arayüzler düzenleyici dilde gözetim gibi görünse de operasyonda gözetim değildir. Bu noktada ajanlı sistemlerle AI Act kaygısı kesişir: otomasyon arttıkça gözetim tasarımı zorlaşır, vazgeçilmezleşir. Onaylayan kişiye ajanın emin dili değil, etkilenen kayıt ve gerekçe gösterilmelidir.

Yüksek risk pratiklerinde test ve doğrulama da ürün işidir. “Model iyi çalışıyor” iddiası yetmez. Hangi senaryoda, hangi metrikte, hangi sınır koşulunda, kim imzaladı soruları dosyalanır. Metrik uydurmak yerine kendi kullanımınıza uygun kabul kriterleri yazın. Dışarıdan kopyalanan yüzde tabloları sizin bağlamınızı kanıtlamaz. Az ama ilgili test, çok ama alakasız gösterge tablosundan iyidir.

Olay yönetimi unutulmamalıdır. Sistem beklenmedik zarar ürettiğinde kim bilgilendirilir, nasıl kayda geçer, nasıl düzeltilir? Bu süreç yoksa uyum dosyası eksiktir. Yüksek etkili AI’da olay, klasik IT incident’ından ayrı düşünülmemeli; fakat model sürümü, veri sürümü ve insan onayı gibi AI’ya özgü alanlar eklenmelidir. Müşteri etkisi varsa iletişim planı hazır beklemelidir.

Son olarak “amaç kayması” yüksek riski sessizce büyütür. Destek için kurulan sistem performans değerlendirmesine kayarsa sınıf tartışması değişir. Bu yüzden ürün sahibi kullanım amaçlarını dar yazar ve sapmayı yönetir. Satış ekibinin “bir de şunu yapar” vaadi, uyum envanterine yeni satır açabilir. Vaadin öncesi envanter güncellemesi olmalıdır.

Dokümantasyon

Dokümantasyon, denetim günü için üretilen kâğıt yığını olmamalıdır; ürünün işletim belleği olmalıdır. İyi bir dosya seti şunları taşır: sistem ne işe yarar ve ne işe yaramaz, hangi verilerle çalışır, bilinen sınırlılıklar, insan gözetimi düzeni, test özeti, değişiklik kaydı, tedarikçi rolleri. Bunlar yaşayan belgelerdir; sürüm numarası ve sahip adı olmadan çürür.

Dokümantasyonu kim yazar? Yalnızca hukuk değil. Ürün, veri, güvenlik ve operasyon birlikte yazar; hukuk gözden geçirir. Aksi halde metin ya fazla genel olur ya da teknik gerçekle kopuk kalır. “Model kartı” veya eşdeğer iç format ortak dil sağlar. Format mükemmel olmak zorunda değildir; eksiksiz ve güncel olmak zorundadır. Sahipsiz doküman, yok hükmündedir.

Değişiklik kaydı özellikle zayıftır. Model değişti, prompt değişti, tool izni değişti, eşik değişti — bunların hangisi kayda girdi? AI sistemlerinde görünmeyen değişiklikler davranışı değiştirir. Bu yüzden değişiklik yönetimi klasik yazılım disiplinine yaklaşmalıdır. “Prompt’u biraz düzelttik” cümlesi, yüksek etkili sistemde sürüm notudur. Değişiklik sonrası kısa doğrulama yapılmadan üretime alma, sessiz regresyon davetidir.

Kanıt ile iddia ayrılmalıdır. “Adil çalışıyoruz” iddiası kanıt değildir. Kanıt; yöntem, tarih, kapsam ve sonuç özetidir. Kanıt yoksa iddiayı dosyaya yazmayın. Eksik olduğunu yazmak, uydurmadan iyidir. Soft PASS yoktur: tamamlanmamış madde açık madde olarak kalır. Yönetim sunumunda yeşil göstermek için eksik maddeyi kapatmak, denetimde daha pahalıya biner.

Dokümantasyon erişimi de planlanmalıdır. Denetçi geldiğinde dosya üç kişinin dizüstü bilgisayarında dağınık olmamalıdır. Merkezi, yetki kontrollü bir depo ve okunabilir dizin yapısı şarttır. Aynı depo, tedarikçi kanıtlarını ve iç testleri de bağlar. Erişim logu, kim neyi ne zaman gördü sorusunu da cevaplar.

Tedarikçi soruları

Birçok kurumda AI, içeriden değil tedarikçiden gelir: model sağlayıcı, SaaS, gömülü özellik, ajans, entegratör. Bu durumda uyum yalnızca sizin politikanız değil; sözleşmeniz ve sorgulama gücünüzdür. Satın alma “fiyat ve SLA” ile yetinmemeli; AI’ya özgü sorular eklemelidir. RFP şablonuna üç satır eklemek, sonradan kriz yönetmekten ucuzdur.

Temel soru seti niteldir: Sistem hangi amaçla sunuluyor? Sizin kullanımınız sağlayıcının öngördüğü amaçla uyumlu mu? Sağlayıcı risk sınıfı değerlendirmesine dair ne paylaşıyor? Eğitim ve log verisi nereye gidiyor, ne kadar süre tutuluyor, alt işlemci var mı? İnsan gözetimi için hangi kontroller sizde, hangileri onda? Olay bildirimi nasıl işliyor? Model veya sistem değişince müşteri nasıl haberdar ediliyor? Veri silme ve taşınabilirlik talebi nasıl karşılanıyor?

“Biz uyumluuz” cümlesi cevap değildir. Kanıt isteyin: doküman özeti, güvenlik özeti, veri işleme açıklaması, alt yüklenici listesi, denetim raporlarının hangi kapsamda olduğu. Kanıt paylaşılmıyorsa risk kabulü bilinçli yapılmalı veya alternatif aranmalıdır. Özellikle yüksek risk adayı kullanımlarda boş sözleşme maddesi ileride pahalıya biner. Pazarlıkta “standart sözleşmemiz budur” cevabı, sizin risk iştahınızı otomatik belirlemez.

Sözleşme dilinde rol dağılımı netleşmelidir: kim sağlayıcı, kim dağıtıcı, kim kullanıcı konumuna daha yakın? Bu roller hukuki sonuç doğurur; iş birimi varsayımla ilerlememelidir. Ayrıca exit planı yazın: sağlayıcı değişirse model, veri ve loglara erişim nasıl taşınır? Kilitlenme, uyum riskini de büyütür. Exit planı yoksa tedarikçi değişimi felaket senaryosudur.

Tedarikçi yönetişimi bir kerelik RFP değildir. Yıllık gözden geçirme, olay sonrası gözden geçirme ve kapsam genişletmede yeniden sorgu gerekir. Yeni bir özellik “ücretsiz açıldı” diye aynı riskte kalmaz. Ürün ekibi yeni özelliği açmadan önce tedarikçi sorularını yenilemelidir. Aynı şekilde alt yüklenici değişimi de sizi etkileyebilir; bildirim maddesi önemlidir.

Öncelik listesini somutlaştırın. Birinci dalga: AI envanteri ve kullanım amaçları. İkinci dalga: yüksek risk adayları için doküman iskeleti ve insan gözetimi. Üçüncü dalga: tedarikçi soru seti ve sözleşme maddeleri. Dördüncü dalga: resmi takvime göre sıkılaştırma. Bu sıra, belirsiz tarihler yüzünden felç olmayı engeller. Tarihler EUR-Lex ve uzmanla doğrulandıkça iş paketleri netleşir.

Sonuç olarak AI Act, Avrupa’ya satış yapan veya Avrupa’da etki üreten yapılar için ürün ve tedarik öncelik listesidir. Risk sınıflarını erken konuşun, takvimi resmi kaynaktan doğrulayın, yüksek risk pratiklerini ürün disiplinine bağlayın, dokümantasyonu yaşatın, tedarikçiyi sorun. Belirsiz tarihleri doldurmak cesaret değil; resmi doğrulama disiplindir. Öncelik listesi bugünden çıkar.

---

Şeffaflık notu

Bu içerik ManegAI destekli üretimle hazırlanmış bir AI Ekonomisi taslağıdır. Yayınlanmadan önce editör incelemesi ve onay gerekir. Metin yatırım tavsiyesi, hukuki mütalaa veya regülasyon taahhüdü değildir; yönetici kararları resmi kaynaklar ve uzman danışmanlıkla doğrulanmalıdır.