AI Act ve CRA: ürüne bakan düzenlemeler

Altay Kargo'nun Avrupa planında üç ürün var. Birincisi, kuryelere günlük teslimat rotasını öneren bir yapay zekâ sistemi. İkincisi, Hamburg iştirakinin sürücü adaylarını sıralayan bir özgeçmiş aracı.

Üçüncüsü, şirketin kendi ürettiği ve Avrupa'daki müşterilere sattığı bir IoT takip cihazı. Önceki dersler kuruluşa bakıyordu. Bu dersteki iki yasa ise ürüne bakar: AB Yapay Zekâ Yasası, kısa adıyla AI Act, ve Siber Dayanıklılık Yasası, kısa adıyla CRA.

Önce AI Act'in rollerini ve risk kademelerini göreceksin. Sonra CRA'nın şartlarına geçecek ve takip cihazı için bir yazılım malzeme listesi üreteceksin. En sonda beş düzenlemeyi tek bir takvimde birleştireceksin.

AI Act, 2024/1689 sayılı tüzüktür ve 1 Ağustos 2024'te yürürlüğe girdi. CRA, 2024/2847 sayılı tüzüktür ve 10 Aralık 2024'te yürürlüğe girdi. İkisi de kuruluşun sektörüne değil, pazara sürülen sisteme ve ürüne bakar. AI Act, sistemi kimin nerede geliştirdiğiyle ilgilenmez.

Sistemi Birlik pazarına süren ya da Birlik'te hizmete sokan sağlayıcı, nerede yerleşik olursa olsun kapsama girer. Birlik dışındaki bir sağlayıcının ya da uygulayıcının sistemi, çıktısı Birlik'te kullanılıyorsa yine kapsamdadır. CRA da Birlik pazarına dijital unsurlu ürün sunan her üreticiyi bağlar. İki yasa da CE işareti mantığını kullanır: yüksek riskli yapay zekâ sistemi ve CRA kapsamındaki ürün, pazara girmeden önce şartları karşılar ve CE işareti taşır.

AI Act yükümlülükleri rollere göre dağıtır. Sağlayıcı, sistemi geliştiren ya da geliştirten ve kendi adıyla pazara süren taraftır. Uygulayıcı (deployer), sistemi kendi yetkisi altında mesleki bir faaliyette kullanan taraftır.

İthalatçı Birlik'te yerleşiktir ve Birlik dışındaki bir sağlayıcının sistemini Birlik pazarına sunar. Dağıtıcı ise bu ikisi dışında, sistemi Birlik pazarında bulunduran taraftır.

Sık bir hata, AI Act'in yalnız geliştiricileri bağladığını sanmaktır; uygulayıcının da yükümlülükleri vardır. Roller sabit de değildir. Yüksek riskli bir sisteme kendi adını koyan ya da onu önemli ölçüde değiştiren taraf, sağlayıcının yükümlülüklerini üstlenir (madde 25).

AI Act sistemleri riske göre dört kademeye ayırır. En üstte kabul edilemez risk taşıyan uygulamalar durur ve bunlar yasaktır (madde 5). Liste somuttur. Kişiyi zarara uğratacak biçimde manipüle etmek ya da yaşından veya engelinden doğan zayıflığını sömürmek yasaktır.

Sosyal puanlama, yalnız profile dayanan suç tahmini ve yüz görüntülerini hedefsiz biçimde toplayıp veri tabanı kurmak da yasaktır. İş yerinde ve okulda duygu tanıma, hassas özellikleri biyometrik veriden çıkarmak ve kolluğun kamusal alanda gerçek zamanlı uzaktan biyometrik tanıma yapması da listededir; sonuncusunun dar istisnaları vardır. Yasak uygulamanın cezası 35 milyon avroya ya da küresel cironun yüzde 7'sine kadar çıkar.

İkinci kademe yüksek risklidir ve iki kaynaktan gelir. Birincisi, makine, oyuncak ya da tıbbi cihaz gibi ürün güvenliği mevzuatına tabi ürünlerin güvenlik bileşeni olan sistemlerdir (Ek I). İkincisi, Ek III'te sayılan hassas alanlardır: biyometri, kritik altyapı, eğitim, istihdam, temel hizmetlere erişim, kolluk, göç ve yargı.

Ek III'teki bir sistem karara önemli etkisi olmayan dar bir usul işi yapıyorsa yüksek risk sayılmayabilir (madde 6/3). Kişi hakkında profil çıkaran sistem ise her durumda yüksek risklidir. Sağlayıcı risk yönetimi, veri yönetişimi, teknik belge, kayıt tutma, insan gözetimi, doğruluk ve siber güvenlik şartlarını karşılar. Sistem uygunluk değerlendirmesinden geçer ve Birlik veri tabanına kaydedilir.

Üçüncü kademe sınırlı risktir ve şeffaflık yükümlülüğü getirir. Sohbet botu kişiye bir yapay zekâyla konuştuğunu söyler; yapay olarak üretilmiş görüntü, ses ve metin işaretlenir (madde 50). Dördüncü kademe minimal risktir ve ek yükümlülük taşımaz. Altay Kargo'nun sistemlerine bu gözle bak.

Paketler için en kısa rotayı hesaplayan sistem kişiler hakkında karar vermez; minimal risktedir. Aynı sistem işleri kuryelerin davranışına ve performans puanına göre dağıtmaya başlarsa tablo değişir. Ek III'ün istihdam başlığı, görev dağıtan ve çalışan performansını izleyen sistemleri de sayar. Hamburg için sürücü adaylarını sıralayan özgeçmiş aracı ise doğrudan yüksek risklidir.

Altay Kargo özgeçmiş aracını hazır satın alırsa uygulayıcıdır. İnsan gözetimini yetkin kişilere verir ve aracı sağlayıcının talimatlarına göre kullanır. Sistemin ürettiği kayıtları en az altı ay saklar.

Aracı kullanmaya başlamadan önce çalışan temsilcilerini ve etkilenecek çalışanları bilgilendirir. Bu yükümlülüklerin gerçek bir karşılığı var. 2018'de büyük bir teknoloji şirketinin deneysel işe alım aracının kadın adayları geri plana ittiği ortaya çıktı.

Araç eski işe alım verisinden öğrenmişti ve o verideki dengesizliği tekrar ediyordu. İnsan gözetimi ve kayıt tutma, böyle bir sapmayı erken yakalamak için vardır.

CRA, doğrudan ya da dolaylı olarak bir cihaza veya ağa bağlanan her dijital unsurlu ürünü kapsar. Donanım da bağımsız yazılım da bu tanıma girer. Ürünün çalışması için gereken uzak veri işleme, yani üreticinin geliştirdiği bulut arka ucu da ürünün parçası sayılır. Tıbbi cihazlar, motorlu taşıtlar, sivil havacılık ve gemi ekipmanı gibi kendi sektör kuralları olan ürünler kapsam dışında kalır.

Üretici Ek I'deki temel şartları karşılar. Ürün bilinen sömürülebilir açık olmadan, güvenli varsayılan ayarlarla pazara çıkar. Erişim denetimi, şifreleme, saldırı yüzeyini küçültme ve güvenlik kaydı da şartlar arasındadır. Destek süresi kural olarak en az beş yıldır; bu sürede güvenlik güncellemeleri ücretsiz sunulur.

CRA ürünleri sınıflara ayırır ve uygunluk değerlendirmesi sınıfa göre değişir. Varsayılan sınıftaki ürün için üretici öz değerlendirme yapabilir. Ek III'teki önemli ürünler iki sınıftır.

Sınıf I'de parola yöneticileri, VPN ürünleri, yönlendiriciler, işletim sistemleri ve akıllı kapı kilidi ya da güvenlik kamerası gibi ev güvenlik ürünleri bulunur. Bu sınıfta üretici uyumlaştırılmış standardı uygularsa öz değerlendirme yeterlidir, uygulamazsa üçüncü taraf değerlendirmesi gerekir. Sınıf II'de güvenlik duvarları, saldırı tespit ve önleme sistemleri ve hipervizörler bulunur; burada üçüncü taraf değerlendirmesi şarttır.

Ek IV'teki kritik ürünler, akıllı kartlar ve donanım güvenlik kutuları gibi en hassas gruptur. Altay Kargo'nun takip cihazı bu listelerde yer almaz, varsayılan sınıftadır.

Raporlama yükümlülüğü 11 Eylül 2026'dan beri uygulanıyor (madde 14). Üretici, ürününde aktif olarak sömürülen bir açığı fark ettiğinde 24 saat içinde erken uyarı verir. 72 saat içinde açığa ve alınan önlemlere dair bildirimi yapar. Düzeltici önlem kullanıma sunulduktan sonra en geç 14 gün içinde nihai raporu gönderir.

Ürünün güvenliğini etkileyen ağır bir olayda süreler 24 saat, 72 saat ve bir aydır. Bildirimler ENISA'nın Tek Raporlama Platformu üzerinden koordinatör olay müdahale ekibine gider ve ENISA'ya aynı anda ulaşır. Birlik'te işyeri olmayan üretici için ülke sırası yetkili temsilci, ithalatçı, dağıtıcı ve en çok kullanıcının bulunduğu ülkedir. Yükümlülük, 11 Aralık 2027'den önce pazara sürülmüş ürünleri de kapsar.

Bir açığı bildirebilmek için önce açığın hangi üründe olduğunu bilmek gerekir. 2021 sonunda yaygın bir Java günlük kütüphanesinde kritik bir açık çıktığında, birçok kuruluş bu kütüphaneyi hangi ürününde kullandığını günlerce aradı. CRA bu yüzden üreticiden ürünündeki bileşenleri belgelemesini ister. Bu belge, yaygın kullanılan ve makinenin okuyabildiği bir biçimdeki yazılım malzeme listesidir, kısaca SBOM.

En azından ürünün doğrudan bağımlılıklarını kapsar. Altay Kargo'nun takip cihazındaki yazılım Python ile yazıldı. Ekip SBOM'u syft aracıyla üretir ve grype aracıyla bilinen açıklarla eşleştirir.

$ syft dir:. -o cyclonedx-json > sbom.json
$ jq -r '.bomFormat, .specVersion' sbom.json
CycloneDX
1.7
$ jq -r '.components[] | select(.type=="library") | "\(.name) \(.version) \(.purl)"' sbom.json
cryptography 43.0.1 pkg:pypi/[email protected]
paho-mqtt 2.1.0 pkg:pypi/[email protected]
requests 2.32.3 pkg:pypi/[email protected]

$ grype sbom:sbom.json
NAME          INSTALLED  FIXED IN  TYPE    VULNERABILITY        SEVERITY  EPSS          RISK
cryptography  43.0.1     44.0.1    python  GHSA-79v4-65xg-pq4g  Low       2.5% (84th)   0.8
requests      2.32.3     2.32.4    python  GHSA-9hjg-9r4m-mvj7  Medium    1.0% (60th)   0.5
cryptography  43.0.1     46.0.5    python  GHSA-r6ph-v2qm-q3c2  High      0.3% (25th)   0.3
(4 satır daha)

Çıktıyı satır satır oku. İlk komut dizindeki bağımlılık dosyalarını tarar ve SBOM'u CycloneDX biçiminde sbom.json dosyasına yazar. İkinci komut biçimi doğrular: CycloneDX, sürüm 1.7.

Üçüncü komut bileşen listesini çıkarır; her satırda ad, sürüm ve paket adresi (package URL), kısaca purl vardır. purl bir bileşeni ekosistemi, adı ve sürümüyle tek bir dizgide tanımlar. Açık veri tabanları bileşeni bu dizgiyle eşleştirir. Son komut listeyi bilinen açıklarla karşılaştırır.

requests 2.32.3 satırı GHSA-9hjg-9r4m-mvj7 kaydıyla eşleşir. Bu kayıt CVE-2024-47081'dir: özel hazırlanmış bir adres, .netrc dosyasındaki kimlik bilgilerini üçüncü tarafa sızdırabilir. FIXED IN sütunu düzeltmenin 2.32.4 sürümünde geldiğini söyler. EPSS, açığın önümüzdeki 30 günde sömürülme olasılığını tahmin eder.

İki yaygın SBOM biçimi var. CycloneDX bir OWASP projesidir ve güvenlik kullanımına odaklanır. SPDX Linux Foundation'da doğdu, lisans bilgisinde güçlüdür ve ISO/IEC 5962:2021 olarak standartlaştı. syft ikisini de üretir; CRA belirli bir biçim dayatmaz.

Süreç tek bir taramayla bitmez. Altay Kargo her yazılım sürümünün SBOM'unu arşivler. Yeni bir açık duyurulduğunda arşivde arar ve etkilenen cihaz sürümlerini dakikalar içinde bulur.

grype listesi tek başına bir CRA bildirimi doğurmaz. Bildirim, üretici ürünündeki bir açığın aktif olarak sömürüldüğünü öğrendiğinde başlar. Listedeki açıklar ise riskine göre değerlendirilir ve gerekirse gecikmeden, ücretsiz bir güvenlik güncellemesiyle kapatılır.

$ grype sbom:sbom.json
NAME      INSTALLED  FIXED IN  TYPE    VULNERABILITY        SEVERITY
requests  2.32.3     2.32.4    python  GHSA-9hjg-9r4m-mvj7  Medium

AB DÜZENLEMELERİ: UYGULAMA TAKVİMİ (1 Ekim 2026 itibarıyla)
------------------------------------------------------------------------
GDPR    25.05.2018  Tam uygulama
NIS2    17.10.2024  Aktarım son günü; 08.07.2026'da 4 üye devlet Divan'a sevk edildi
DORA    17.01.2025  Tam uygulama
AI Act  02.02.2025  Yasaklar ve yapay zekâ okuryazarlığı
        02.08.2025  Genel amaçlı yapay zekâ modelleri
        02.08.2026  Şeffaflık kuralları ve genel uygulama
        02.12.2027  Ek III yüksek riskli sistemler (AI Omnibus ile ertelendi)
        02.08.2028  Ürünlere gömülü yüksek riskli sistemler (Ek I)
CRA     11.06.2026  Uygunluk değerlendirme kuruluşlarına dair kurallar
        11.09.2026  Aktif sömürülen açık ve ağır olay bildirimi
        11.12.2027  Bütün yükümlülükler

Takvimi satır satır oku. GDPR 2018'den beri tam uygulanıyor. NIS2'nin aktarım süresi 17 Ekim 2024'te doldu, ama gecikmeler sürüyor; Temmuz 2026'da dört üye devlet Adalet Divanı'na sevk edildi.

DORA tüzük olduğu için tek tarihle, 17 Ocak 2025'te devreye girdi. AI Act basamak basamak ilerliyor. Yasaklar Şubat 2025'te, genel amaçlı model kuralları Ağustos 2025'te, şeffaflık kuralları Ağustos 2026'da başladı.

27 Temmuz 2026'da yürürlüğe giren AI Omnibus, yüksek riskli sistemlerin tarihini erteledi. CRA'da bildirim yükümlülüğü genel şartlardan önce geldi. Bir şirket için doğru soru, düzenlemenin yürürlükte olup olmadığı değildir. Doğru soru, kendi ürününe uygulanan maddenin hangi tarihte devreye girdiğidir.

Türkiye'deki bir ekip bu takvimi kendi kurallarıyla birlikte okur. Kişisel Verileri Koruma Kurumu, 24 Kasım 2025'te Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi'ni yayımladı. Rehber, üretken yapay zekâ sistemlerindeki veri işlemeyi 6698 sayılı Kanun çerçevesinde ele alır.

Yönetim sistemi kurmak isteyen kurum ISO/IEC 42001:2023 standardına bakar. Bu standart, yapay zekâ için yayımlanan ilk uluslararası yönetim sistemi standardıdır. AI Act'e uyum zorunludur, ISO/IEC 42001 belgesi ise gönüllüdür. Yine de iyi kurulmuş bir yönetim sistemi, AI Act'in istediği risk yönetimi ve kayıt kanıtlarının çoğunu hazır eder.

Artık Türkiye ve Avrupa Birliği mevzuatının hangi soruları sorduğunu biliyorsun. GDPR kişiye, NIS2 ve DORA kuruluşa, AI Act ve CRA ürüne bakar. Bir sonraki adım, bu düzenlemeleri kurumunun politika ve denetim döngüsüne bağlamaktır.

Kuralı bilmek yetmez; ona uyduğunu gösteren politikayı, kontrolü ve kaydı da kurman gerekir. Sıradaki modül bu konuyu işler. Önce takip cihazı için kendi CRA kontrol sorunu yaz.