AB’de Yazılım Hatası ve Güncelleme Sorumluluğu

Kısa ve net cevap: AB’de yazılım hatası ve güvenlik güncellemesi sorumluluğu, yeni Ürün Sorumluluğu Direktifi (AB) 2024/2853 m.4, 7, 8 ve 11 kapsamında yazılımın ürün niteliği, üreticinin kontrolü, güvenlik bakımından hatalılık, zarar ve nedensellik üzerinden değerlendirilir. Yazılımın buluttan veya hizmet olarak sunulması tek başına kapsam dışında bırakmaz. Üreticinin kontrolü altındaki yazılımın, bağlantılı hizmetin veya güvenliği sürdürmek için gerekli güncellemenin eksikliğinin doğurduğu hata, yalnız “ürün teslim edildiğinde sorun yoktu” savunmasıyla değerlendirme dışına çıkarılamaz.

Uygulama tarihi: Bu yazı 28 Eylül 2026’da hazırlanmıştır. Direktif m.2/1, yeni rejimi 9 Aralık 2026 tarihinden sonra piyasaya sürülen veya hizmete sunulan ürünlere bağlar. Üye devletlerin ulusal aktarma düzenlemeleri ayrıca kontrol edilmelidir. Aşağıdaki açıklamalar bütün Türkiye yazılım sözleşmelerine doğrudan uygulanan bir Türk kanunu anlatımı değildir. Genel tarih ve ülke ayrımı için yeni AB ürün sorumluluğu geçiş rehberi tamamlayıcıdır.

Yazılım, SaaS ve dijital dosya aynı kategori midir?

Direktif m.4/1 yazılımı açıkça ürün tanımına dahil eder. Gerekçe 13; işletim sistemi, donanım yazılımı, bilgisayar programı, uygulama ve yapay zekâ sistemlerini bu çerçevede açıklar. Yazılım bağımsız olarak sunulabilir veya başka ürünün bileşeni hâline gelebilir. Teknik olarak hangi modelle dağıtıldığı, ürün niteliği incelemesinde tek başına belirleyici bir istisna değildir. Fiziksel kutu veya indirme dosyası bulunmaması kapsamdan çıkış gerekçesi sayılmamalıdır.

Gerekçe 13, iletişim ağı ve bulut teknolojileri üzerinden erişim ile yazılımın hizmet olarak sunulmasını da ele alır. Bu nedenle sözleşmede yalnız SaaS yazması, ürün sorumluluğunun araştırılmasını gereksiz kılmaz. Buna karşılık her danışmanlık hizmeti, her içerik aboneliği ve her internet sayfası yazılım ürünü olarak aynı sonuca bağlanamaz. Teknik işlev, sunulan çıktı ve kullanıcıya verilen gerçek kullanım biçimi belirlenmelidir.

Aynı gerekçe, bilginin kendisini ürün saymadığını açıklar. Medya dosyası, elektronik kitap içeriği veya yazılımın yalnız kaynak kodu, bilgi niteliği bakımından yazılımın çalıştırılmasından doğan zarar rejimiyle karıştırılmamalıdır. Bu ayrım, yazılım teslim sözleşmesinin teknik eklerinde önem taşır. Teslim edilen çalışmanın çalıştırılabilir ürün mü, açıklayıcı bilgi mi, yoksa üretimi otomatik yöneten bir dosya mı olduğu kaydedilmelidir.

Dijital üretim dosyası ise m.4/2’de ayrıca tanımlanır. Makineleri veya araçları otomatik kontrol ederek maddi nesne üretimini sağlayan işlevsel dijital bilgi bu kapsamdadır. Dolayısıyla bütün dijital dosyaların dışarıda olduğu veya bütün dosyaların ürün sayıldığı şeklindeki iki uç yaklaşım da yanlıştır. Üretim dosyasının işleviyle yazılımın yürüttüğü işlem birbirinden ayrılarak ilgili hüküm belirlenmelidir.

Bulut hizmeti hangi durumda ürünün bağlantılı hizmetidir?

M.4/3, yokluğu ürünün bir veya daha fazla işlevini yerine getirmesini engelleyen entegre veya bağlantılı dijital hizmeti esas alır. M.4/4, bağlantılı hizmeti bileşen kavramıyla ilişkilendirir. İnceleme için hizmetin hangi ürün işlevini taşıdığı somutlaştırılır. Ürünün temel çalışması için gereken hizmet ile yalnız pazarlama veya müşteri iletişimi sağlayan ek ekran aynı hukuki işlevi görmez.

Gerekçe 17, bağlantılı hizmetin ürün güvenliğindeki rolünü açıklar. Bununla birlikte internet erişim hizmeti, üreticinin kontrolündeki ürünün bir parçası olarak aynı kategoriye sokulmaz. Bu açıklama, internet kesildiğinde ortaya çıkan her ürün davranışının hukuken önemsiz olduğu anlamına gelmez. Ürünün bağlantı kaybında güvenli kalıp kalmadığı, ürünün kendi güvenlik değerlendirmesinde ayrıca incelenir.

Bu nedenle teknik mimaride hizmet bağımlılıkları açıkça gösterilmelidir. Hangi sunucu hangi işlevi yürütüyor, hizmeti kim işletiyor, kesinti hâlinde cihaz ne yapıyor ve kullanıcıya hangi bilgi veriliyor soruları aynı dosyada yanıtlanmalıdır. Bu çalışma için ürünün bütün ticari sırlarının kamuya açıklanması gerekmez. Ama sorumluluk değerlendirmesinde işlevsel ilişkinin yalnız sözleşmedeki genel “üçüncü taraf hizmet” cümlesi arkasında belirsiz bırakılması doğru değildir.

Ücretsiz veya açık kaynak yazılımda istisna nasıl uygulanır?

M.2/2, ticari faaliyet dışında geliştirilen veya sağlanan özgür ve açık kaynak yazılımı kapsam dışında bırakır. İstisna, yalnız lisansın adında açık kaynak ibaresi bulunmasına dayanmaz. Geliştirme ve sunumun ticari faaliyet içinde olup olmadığı araştırılır. Ücret alınmaması da her durumda ticari niteliği ortadan kaldırmaz. Gerekçe 14, bu ayrımı yazılımın sağlanma koşulları ve ekonomik bağlamıyla birlikte açıklar.

Gerekçe 14, bedel karşılığında sunumun yanında belirli amaçlar dışındaki kişisel veri karşılığı sağlama durumunu da ticari faaliyet bağlamında değerlendirir. Bu nedenle “uygulama ücretsiz indiriliyor” açıklaması hukuki incelemenin sonu değildir. Kullanım koşulları, gelir modeli ve veri kullanımının niteliği aynı dosyada okunmalıdır. Bu değerlendirme, kişisel veri mevzuatının kendine özgü yükümlülüklerinin yerine geçmez.

Ticari olmayan açık kaynak bileşenin ticari ürüne entegre edilmesi ayrı meseledir. Gerekçe 15, bileşeni ticari faaliyeti içinde ürüne ekleyerek piyasaya süren üreticinin konumunu, ticari olmayan yazılım geliştiricisinden ayırır. Ürün üreticisi, kullandığı bileşenin açık kaynak olmasını bütün ürün güvenliği sorumluluğundan genel muafiyet gibi sunmamalıdır. Bileşenin kaynağı ile son ürünün piyasaya sunulması ayrı hukuki olaylardır.

Açık kaynak lisansına uyum ile ürün güvenliği bakımından sorumluluk da aynı test değildir. Lisans koşullarına uymak, yazılımın her kullanımda güvenli olduğunu kendiliğinden ispatlamaz. Güvenlik değerlendirmesi yapmak da lisans yükümlülüklerini kaldırmaz. Yazılımın telif hakkıyla korunması hakkındaki rehber, fikrî hak boyutunu ayrıca ele alır; burada odak, yazılımın neden olduğu ürün zararıdır.

Üreticinin kontrolü yalnız kaynak koduna sahip olmak mıdır?

M.4/5, üreticinin bileşeni veya güncellemeyi kendisinin sağlaması, üçüncü kişinin entegrasyonuna veya değişikliğine izin vermesi ya da bunu kabul etmesi gibi durumları kapsar. Ayrıca üreticinin kendisi veya üçüncü kişi üzerinden güncelleme sağlama imkânını koruması da tanımda yer alır. Bu nedenle kontrolü yalnız kaynak kodunun mülkiyetine veya sunucunun tapusuna benzer tek bir sahiplik ölçütüne indirgemek doğru değildir.

Gerekçe 18, teknik olarak entegrasyon imkânı bırakılmasının tek başına her bağlantıyı kabul etmek anlamına gelmediğini açıklar. Belirli markaların önerilmesi veya olası hizmetlerin yasaklanmaması da kendiliğinden bütün üçüncü taraf bileşenlerin üretici kontrolünde olduğunu göstermez. Somut yetkilendirme, ürünün sunuluşu ve fiilen yürütülen ilişki belirlenmelidir. Sözleşme ile teknik uygulamanın birbirini doğrulaması gerekir.

Kontrol dosyasında güncellemeyi hazırlama, imzalama, dağıtma, geri çekme ve kullanıcıya bildirme görevleri ayrı satırlarda tutulmalıdır. Ürün üreticisi ile yazılım geliştiricisi farklı şirketlerse yetki ve görev aktarımı belgelenir. Bu tablo, kanunda düzenlenmiş hazır bir resmî form değildir; kontrol olgusunu açıklamak için önerilen dosyalama yöntemidir. Teknik kararın hangi kuruluş tarafından verildiğini görünür hâle getirir.

Güvenlik güncellemesinin eksikliği neden özel olarak düzenlendi?

M.11/1-c, belirli koşullarda hatanın ürün piyasaya sürüldüğünde bulunmadığı veya sonradan ortaya çıktığı savunmasına yer verir. Ancak m.11/2, üreticinin kontrolündeki bağlantılı hizmet, yazılım, yazılım güncellemesi, güvenliği sürdürmek için gerekli güncellemenin eksikliği veya esaslı değişiklikten kaynaklanan hata bakımından bu savunmayı sınırlar. Bu ayrım, teslim anı ile satış sonrası teknik kontrol arasındaki ilişkiyi kurar.

Her yeni özellik veya performans artırımı, güvenliği sürdürmek için gerekli güncelleme değildir. Dosyada güncellemenin amacı açık yazılmalıdır. Güvenlik açığını gideren değişiklik, kullanıcı arayüzü yenilemesi ve ticari abonelik özelliği aynı gerekçeyle ele alınmamalıdır. Hangi güvenlik tehlikesinin hangi sürümde bulunduğu ve hangi değişiklikle giderildiği gösterilmelidir. Böylece yalnız sürüm numarası karşılaştırmasına dayanan yüzeysel değerlendirme önlenir.

Üreticinin güncelleme yayımlaması ile güncellemenin belirli cihaza ulaşması da ayrı olaylardır. Dağıtım kaydı, uyumluluk koşulları, kullanıcı bildirimi ve kurulum sonucu dosyada ilişkilendirilmelidir. Güncellemeyi hiç sağlamama, sağlanan güncellemenin kendisinin hatalı olması ve kullanıcının davranışının zarara katkısı farklı sorulardır. M.13’teki zarar görenin kusuru değerlendirmesi, somut delillere dayanmalıdır; kullanıcıya otomatik kusur yüklenmemelidir.

Cyber Resilience Act güvenlik açığı bildirimi hakkındaki düzenlemeler farklı bir uyum sürecidir. Bir güvenlik olayının yetkili makama bildirilmesi ile bu olay nedeniyle bir gerçek kişiye tazminat ödenmesi aynı hukuki test değildir. Bildirim tarihleri, teknik raporlar ve alınan önlemler delil dosyasında önem taşır; ancak tek başına sorumluluğun kabulü veya reddi olarak sunulmamalıdır.

Yazılımın hatalı olduğunu belirlerken hangi güvenlik ölçütleri kullanılır?

M.7, kişinin beklemeye hakkı olan veya hukukun gerektirdiği güvenliği esas alır. Yazılımın tasarımı, talimatları, öngörülebilir kullanımı, başka ürünlerle etkileşimi, öğrenme veya yeni özellik edinme kapasitesi ve ilgili siber güvenlik gereklilikleri bu değerlendirmeye dahil edilir. Bu nedenle yalnız satış sunumundaki tek performans ölçümüne dayanmak yeterli değildir. Ürünün kullanım bağlamı ve hedef kullanıcı grubunun ihtiyaçları birlikte incelenir.

Güvenlik işlevi bulunan bir yazılımda bu işlevin yerine getirilememesi de m.7/2-i’de ayrıca dikkate alınır. Teknik rapor, yazılımın hangi görevi üstlendiğini ve bildirilen olayda hangi davranışı gösterdiğini açıklamalıdır. Sonuç ekranında görülen hata mesajı ile zarara neden olan teknik süreç aynı şey olmayabilir. İnceleme, mümkün olduğunca olayın teknik akışını ve ilgili sürümü belirlemelidir.

M.7/3 uyarınca daha iyi bir ürünün, güncellemenin veya yükseltmenin sonradan sunulması tek başına eski ürünü hatalı hâle getirmez. Bu sınır, güvenlik için gereken güncellemeyi sağlamama kuralıyla birlikte okunmalıdır. Yeni özellik çıkması ile mevcut güvenlik açığının giderilmemesi aynı olgu değildir. Sözleşme ve teknik raporda kullanılan terminoloji bu ayrımı korumalıdır.

Veri kaybı, veri sızıntısı ve ticari kayıp ayrı mı incelenir?

M.6/1-c, mesleki amaçlarla kullanılmayan verilerin yok olmasını veya bozulmasını kapsar. Verinin sızması, hukuka aykırı işlenmesi ve verinin bozulması ise aynı olay değildir. Gerekçe 20, veri koruma mevzuatı ile bu zarar türünün ayrımını açıklar. Olayın yalnız “veri ihlali” olarak adlandırılması, hangi hukuki talebin ileri sürüldüğünü belirlemek için yeterli değildir.

Mesleki amaçla kullanılan veri, yalnız mesleki kullanıma özgülenmiş eşya ve karma kullanımlı eşya bakımından da metindeki ayrımlar korunmalıdır. M.6, bütün işletme kayıplarını bu Direktif altında toplamaz. Başka sözleşmesel veya kanuni tazminat yolları ayrıca incelenir. Zarar dosyasında kişisel fotoğraf arşivi, ticari müşteri kaydı ve yazılımın kendi bedeli aynı talep kalemine dönüştürülmemelidir.

Verilerin geri getirilebilmesi, geri getirme için katlanılan gider ve kaybın gerçek ekonomik sonucu ayrıca belgelenir. Gerekçe 20, ücretsiz erişilebilir yedeğin bulunduğu veya verinin masrafsız biçimde geri sağlandığı durumlarla maddi kayıp arasındaki ilişkiyi açıklar. Bu nedenle dosyada yalnız kayıp iddiası değil, geri yükleme olanağı, yapılan işlem ve ortaya çıkan masraf da gösterilmelidir. Aynı giderin birden fazla başlık altında tekrar talep edilmemesi gerekir.

Yazılım geliştiricisi ile cihaz üreticisi birlikte sorumlu olabilir mi?

M.8, hatalı ürün üreticisinin yanında koşulları gerçekleştiğinde hatalı bileşenin üreticisini de düzenler. M.12, aynı zarardan sorumlu birden fazla ekonomik işletmeci için birlikte ve müteselsil sorumluluğu öngörür. Bu sonuç, her projedeki bütün yazılımcıların otomatik olarak aynı zarardan sorumlu olduğu anlamına gelmez. Kimin ürün veya bileşen üreticisi olduğu, hangi hatanın hangi zarara neden olduğu ve ilgili diğer koşullar belirlenmelidir.

M.12/2, yazılım bileşeni üreten mikro veya küçük işletmeye karşı rücu bakımından özel bir düzenleme içerir. İlgili işletme ölçeği koşuluna ek olarak, yazılımı ürüne entegre eden üreticinin rücu hakkından sözleşmeyle vazgeçmiş olması gerekir. Küçük işletme olmak tek başına bütün rücu taleplerini kaldırmaz. Bu iki koşulun birlikte aranması, sözleşme hazırlığında özellikle önemlidir.

Ürün üreticisi ile bileşen sağlayıcısı arasındaki rücu paylaşımı, zarar görenin hakkından ayrıdır. M.15’teki sorumluluğu zarar görene karşı sınırlamama kuralı gözden kaçırılmamalıdır. Taraflar kendi aralarında bedel, savunma gideri, teknik destek ve iç ilişkiyi düzenlerken bunları üçüncü kişinin kanuni hakkını yok eden hükümler gibi kaleme almamalıdır. Sigorta ve garanti başlıkları da aynı ayrımla okunmalıdır.

Yazılım kaynaklı zarar dosyasında hangi teknik kayıtlar gerekir?

Başlangıç dosyası, ürün ve yazılım sürümü, olay zamanı, kullanım ortamı, ilgili güncelleme, hata kaydı ve zarar belgesini bir araya getirir. Her kayıt aynı olaya bağlanmalıdır. Farklı kullanıcıya veya başka sürüme ait genel bir teknik rapor, somut olayı kendiliğinden açıklamaz. Teknik inceleme sırasında orijinal kayıtlar korunmalı; sonradan yapılan düzeltme ile olay anındaki durum ayrı tutulmalıdır.

M.9, ilgili delillerin açıklanmasını gerekli ve ölçülü olma koşuluyla düzenler; ticari sırlar ve gizli bilgiler bakımından koruyucu önlemler öngörür. Bu nedenle delil hazırlığı, bütün kaynak kodunun herkese açık yayımlanması anlamına gelmez. Hangi kayıtların uyuşmazlıkla ilgili olduğu ve bunların hangi koruma altında inceleneceği belirlenmelidir. Delil sunmama ile haklı gizlilik talebi aynı tutum değildir.

M.10’daki karineler, teknik veya bilimsel karmaşıklık nedeniyle aşırı ispat güçlüğü yaşanan durumları da koşullarıyla ele alır. Ancak bütün yazılım davalarında ispat yükünün otomatik olarak tersine döndüğü söylenemez. Hatalılık, zarar ve nedensellik temel çerçevesi korunur; karine koşulları ve çürütme hakkı ayrıca uygulanır. Teknik rapor bu hukuki sorulara yanıt verecek biçimde hazırlanmalıdır.

Güvenlik desteği ve sorumluluk hükümleri nasıl ayrılmalıdır?

Yazılım sözleşmesinde teslim kapsamı, güncelleme yetkisi, güvenlik bildirimi, destek süresi, kayıt erişimi, alt yüklenici ve olay incelemesine katılım ayrı başlıklar olmalıdır. Genel bir “tüm sorumluluk kullanıcıya aittir” cümlesi, Direktif kapsamındaki zarar görenin hakkını ortadan kaldırmaz. Buna karşılık tarafların teknik iş bölümünü hiç yazmaması da olay sonrasında kimin hangi kaydı sunacağını belirsizleştirir.

İmza öncesi kontrol yalnız bedel ve lisans süresine odaklanmamalıdır. Ürünün AB’ye ilk sunumu, yazılımın ticari niteliği, entegrasyon onayları ve güncelleme süreci aynı sözleşme dosyasında görünmelidir. Çalışanın yazdığı yazılım üzerindeki mali haklar ayrıca incelendiğinde, fikrî hak zinciri ile ürün güvenliği görevleri arasındaki fark da korunmuş olur.

Teknik dosya için kısa kontrol tablosu

Sık sorulan sorular

SaaS olarak sunulan yazılım ürün sorumluluğunun dışında mıdır?

Hayır. Gerekçe 13, bulut ve hizmet olarak yazılım sunumunu kapsam bakımından açıklar. Ancak somut yazılımın ticari niteliği, zaman bakımından kapsam ve diğer sorumluluk şartları ayrıca incelenir.

Her kaynak kodu paylaşımı ürün sunumu sayılır mı?

Hayır. Gerekçe 13, bilginin kendisi ve yalnız kaynak kodu ile yazılım ürününü ayırır. Dosyanın işlevi ve piyasaya sunulan teknik çıktı belirlenmelidir.

Açık kaynak yazılım için genel muafiyet var mı?

M.2/2, ticari faaliyet dışında geliştirilen veya sağlanan özgür ve açık kaynak yazılımı dışarıda bırakır. Yalnız açık kaynak lisansı kullanılması veya indirme ücreti alınmaması her durumda yeterli değildir.

Açık kaynak bileşeni kullanan ticari ürün üreticisi otomatik olarak muaf mı?

Hayır. Ticari olmayan geliştiricinin konumu ile bileşeni ticari ürüne entegre ederek piyasaya süren üreticinin konumu ayrı değerlendirilir. Gerekçe 15 bu ayrımı açıklar.

Güncelleme yapılmaması her zaman sorumluluk doğurur mu?

Otomatik sonuç kurulmaz. M.11/2 bakımından güvenliği sürdürmek için gerekli güncelleme, üreticinin kontrolü, ürünün hatalılığı, kapsam içindeki zarar ve nedensellik birlikte incelenir.

Daha iyi bir yazılım sürümü çıkması eski sürümü hatalı yapar mı?

Tek başına yapmaz. M.7/3 bunu açıkça belirtir. Güvenlik açığını gidermek için gereken güncelleme ile yeni ticari özellik sunumu birbirinden ayrılmalıdır.

Veri sızıntısı ile verinin bozulması aynı talep midir?

Hayır. M.6/1-c belirli verilerin yok olması veya bozulmasını düzenler. Veri koruma mevzuatından doğan talepler ayrı hukuki temele dayanabilir.

Küçük yazılım şirketine hiçbir durumda rücu edilemez mi?

Hayır. M.12/2’de işletme ölçeği şartının yanında entegre eden üreticinin sözleşmeyle rücu hakkından vazgeçmiş olması da aranır. Küçük işletme sıfatı tek başına yeterli değildir.

Teknik karmaşıklık bütün ispat yükünü otomatik olarak değiştirir mi?

Hayır. M.10’daki karine koşulları ayrı ayrı değerlendirilir ve karşı taraf bunları çürütebilir. Hatalılık, zarar ve nedensellik incelemesi ortadan kalkmaz.

Yeni kurallar hangi ürün dönemine ilişkindir?

M.2/1, 9 Aralık 2026 tarihinden sonra piyasaya sürülen veya hizmete sunulan ürünleri esas alır. 28 Eylül 2026’da bu tarih henüz gelmemiştir; ulusal aktarma mevzuatı ayrıca kontrol edilmelidir.

Resmî kaynaklar ve dayanaklar

EUR-Lex: (AB) 2024/2853 sayılı Direktif, özellikle m.2, 4, 6–13, 15, 21–22 ve gerekçeler 13–22. Gerekçeler, maddelerin kapsamını açıklamak için belirtilmiştir; bağımsız bir Türk kanunu hükmü olarak sunulmamaktadır. Ulusal aktarma ve somut uyuşmazlığa uygulanacak hukuk ayrıca belirlenmelidir.