Bu yazıyı okurken DEHA'yı denemek ister misin? Aşağıdaki butonla ana sayfadaki sohbeti aç.
DEHA'yı Dene →Yapay zekânın verdiği zarardan kimin sorumlu olduğu, yalnızca kullanılan modelin adına bakılarak belirlenemez. Zararın türü, tarafların rolleri, sözleşme, kusur, yükümlülükler ve zararla davranış arasındaki bağ incelenir. Geliştirici, uygulama sağlayıcısı, sistemi işine entegre eden kuruluş ve kullanıcı farklı görevler üstlenebilir. “AI yaptı” ifadesi insan ve kuruluşların sorumluluğunu otomatik kaldırmaz; her hatanın bütün sorumluluğunu model sağlayıcısına yüklemek de doğru değildir.
Bu yazı değerlendirme haritası sunar; belirli bir tazminat sonucuna hükmetmez. Genel çerçeve yapay zekâ ve hukuk rehberinde, işlem yapabilen sistemler agent sorumluluğu yazısında ele alınır.
Önce zarar ve olay zincirini tanımlayın
Yanlış bir özet, kişisel veri ifşası, hatalı otomatik e-posta ve fiziksel sistem arızası farklı olaylardır. Aynı hukuki başlık altında incelenseler bile uygulanacak kurallar ve deliller değişebilir. İlk aşamada hangi menfaatin zarar gördüğü ve hangi işlem zincirinde sonuç doğduğu kaydedilir.
Modelin yanıtı yanlış olabilir; ancak yanlışlığın kullanıma nasıl taşındığı ayrıca önemlidir. Çıktı taslak olarak mı sunuldu? İnsan kontrolü vaat edildi mi? Kullanıcıya eksik kaynak bilgisi verildi mi? Son işlem otomatik mi yapıldı? Bu sorular farklı tarafların rolünü görünür kılar.
Olayın zaman sırası teknik kayıtlarda korunmalıdır. Model sürümü, kaynak seti, araç sonucu ve insan onayı farklı aşamalardır. Ancak delil toplama amacı sınırsız veri saklama gerekçesi değildir. Kayıt kapsamı, erişim ve saklama süreleri ayrıca değerlendirilir.
Sorumluluk zincirindeki roller
| Rol | Kontrol ettiği alan | İncelenecek başlık |
|---|---|---|
| Model geliştiricisi | Temel model tasarımı | Açıklamalar ve ürün davranışı |
| Uygulama sağlayıcısı | Arayüz ve iş akışı | Kaynak, erişim, uyarı, hata yönetimi |
| Entegratör | Araç ve veri bağlantısı | Yetki ve işlem sınırı |
| Kuruluş | Kullanım politikası | Eğitim, denetim, onay |
| Kullanıcı | Somut kullanım | Talimat ve doğrulama davranışı |
Tablo rol açıklamasıdır; her satırdaki kişi her olayda otomatik sorumlu değildir. Aynı kuruluş birden fazla rol üstlenebilir. Bir dış API kullanılması uygulama tasarımının tamamen dış sağlayıcıya ait olduğu anlamına gelmez.
Hukuki nitelendirme, hizmet ilişkisinin ve olayın gerçek koşullarına göre yapılmalıdır. Ticari sözleşme ile tüketici ilişkisi farklı değerlendirmeler gerektirebilir. Teknolojik iş bölümünü açıklamak hukuki sorumluluğu tek başına dağıtmaz.
Sözleşmeye aykırılık ve haksız fiil
Türkiye bakımından Türk Borçlar Kanunu'nun resmî metni, sözleşmesel yükümlülükler ve haksız fiil değerlendirmesinde temel kaynaklardan biridir. Bu yazı somut olay için hangi hükmün uygulanacağını belirlemez.
Bir hizmetin vaat edilen kapsamı önemlidir. “Ön inceleme aracı” ile “bütün belgeleri doğrulanmış biçimde analiz eder” iddiası aynı beklentiyi yaratmaz. Uyarı metni bulunması, hizmetin gerçek tasarım ve sunumuyla ilgili bütün soruları ortadan kaldırmaz.
Sözleşmedeki sorumluluk sınırının geçerliliği ayrıca değerlendirilir. Bir sağlayıcının şartlarına “hiç sorumlu değiliz” yazması bu hükmün her durumda uygulanabilir olduğunu göstermez. Tarafların niteliği, emredici kurallar ve olayın özellikleri incelenmelidir.
Kusur ve nedensellik nasıl araştırılır?
Sonucun zararlı olması tek başına hangi davranışın belirleyici olduğunu göstermez. Yanlış veri, eksik retrieval, yanlış araç sonucu veya insanın hatalı kullanımı birlikte etkili olabilir. Bu nedenle sadece nihai yanıtın ekran görüntüsünü değil uygun kapsamda işlem zincirini de incelemek gerekir.
Bir sözleşme özetinde ödeme tarihi yanlış aktarılmış olsun. Kaynakta tarih doğru mu? Metin çıkarımı hatalı mı? Model ilgili maddeyi görmüş mü? Kullanıcıya kaynak gösterilmiş mi? İnceleyen kişi kontrol etmiş mi? Her soru farklı bir neden ihtimalini ayırır.
Teknik inceleme hukuki kanaatin yerine geçmez; fakat olayın nasıl oluştuğunu açıklamaya yardımcı olur. Şeffaf bir hata kaydı, tarafların iddialarını değerlendirmek için yararlı olabilir. İçeriğe sınırsız erişim veren bir log sistemi ise yeni gizlilik riski doğurabilir.
AI Act ile tazminat düzenlemesini karıştırmayın
AI Act risk ve uyum yükümlülükleri getiren bir çerçevedir; her zarar için tek başına otomatik tazminat formülü değildir. Türkiye'deki şirketler için AI Act rehberi, kapsam ve rolleri ayrı ele alır.
AB'nin 2024/2853 sayılı ürün sorumluluğu direktifi yazılımı da kapsayan ürün sorumluluğu çerçevesini düzenler. Direktifin ulusal hukuka aktarılması ve uygulama koşulları ayrıca değerlendirilir; bunu Türkiye'de kendiliğinden uygulanacak kural gibi sunmak doğru değildir.
29 Eylül 2026 tarihli bu yazıda geçiş takvimi önemlidir. Direktifte belirtilen 9 Aralık 2026 eşiği henüz gelecektedir. Somut ürün, piyasa tarihi ve ilgili ülke düzenlemesi incelenmeden genel bir sonuç çıkarılmamalıdır. AB uyum başlığı ile Türkiye'deki zarar iddiası ayrı analiz edilmelidir.
Varsayımsal üç senaryo
İlk senaryoda model kamuya açık bir metni yanlış özetler; kullanıcı özeti kontrol etmeden karar verir. İnceleme, sunulan hizmetin kapsamı ve doğrulama süreci etrafında yapılır.
İkinci senaryoda uygulama bir kullanıcının dosyasını başka hesaba gösterir. Burada yalnızca modelin metin kalitesi değil erişim ve veri güvenliği tasarımı belirleyici hâle gelir. Kişisel veri ihlali değerlendirmesi ayrı yürütülür.
Üçüncü senaryoda agent taslak e-postayı onaysız gönderir. Yetki, onay ve araç çalıştırma kaydı araştırılır. “Model gönderdi” açıklaması hangi sistem bileşeninin işlemi gerçekleştirdiğini gizlememelidir. Bunlar örnek senaryolardır; gerçek olay veya karar değildir.
Kuruluşlar riski nasıl azaltabilir?
İş akışını taslak, inceleme ve icra aşamalarına ayırın. Yüksek etkili işlemler için insan onayı belirleyin. Kaynak dışı bilgi ve eksik belgeleri görünür tutun. Çalışanların hangi aracı hangi veriyle kullanabileceğini açıkça yazın.
Başarı ölçümüne hata ve kontrol süresini de ekleyin. Sistem yalnızca hızlı olduğu için güvenilir sayılmaz. Hata sonrası işlemi durdurma ve düzeltme yolu bulunmalıdır. Kullanıcıya gösterilen uyarılar gerçek iş akışıyla tutarlı olmalıdır.
Sözleşme analizi rehberi, yanlış bir ön incelemenin önlenmesi için kaynak ve kapsam kontrolünü örneklendirir. Bu tür çalışma yöntemleri hukuki sorumluluğu kaldırmaz; hatayı önleme ve incelemeyi destekleme amacı taşır.
DEHA ile kullanımın sınırı
DEHA belge inceleme ve kaynaklı çalışma için yardımcı olabilir. Çıktıların dosya özelinde doğrulanması gerekir. Hukuki hüküm, tazminat sonucu veya mahkeme kararı üreten bağlayıcı sistem gibi kullanılmamalıdır. Gizlilik, veri paylaşımı ve hizmet koşulları güncel metinlerden incelenmelidir.
Sorumluluk tamamen kullanıcıya yüklenebilir mi?
Bir şartlar metninin sonucu her olayda aynı değildir. Hükmün geçerliliği, taraf ilişkisi ve zorunlu kurallar ayrıca değerlendirilir.
Hangi kayıtlar yararlıdır?
Girdi kapsamı, kaynak sürümü, yanıt, araç sonucu ve onay zinciri. Bunların saklanması ölçülü ve güvenli olmalıdır.
Hata sonrasında ilk inceleme düzeni
Bir yanlışlık fark edildiğinde önce zararın büyümesini önleyebilecek uygun işlem değerlendirilir. Otomatik görevlerin durdurulması, yanlış çıktının kullanılmaması ve ilgili kişilerin bilgilendirilmesi farklı kararlar olabilir. Somut olayda hukuki ve teknik uzmanlar birlikte çalışmalıdır.
Kayıtları değiştirmeden uygun kapsamda koruyun; fakat bütün kullanıcı içeriklerini herkese açık bir rapora taşımayın. İnceleme için gerekli teknik durum, kaynak ve onay bilgileri erişim sınırıyla tutulabilir. Şüphe ile doğrulanmış bulguyu ayrı yazın. İlk anda model sağlayıcısını veya kullanıcıyı kesin sorumlu ilan etmek, gerçek nedenin araştırılmasını zorlaştırabilir.
Düzeltme yapılması önceki olayın bütün etkilerinin giderildiğini göstermeyebilir. Hangi çıktıların ve dış işlemlerin etkilendiği ayrıca değerlendirilir. İnceleme sonunda olayın nedeni, düzeltme kapsamı ve tekrar önleme adımları açıkça ayrılmalıdır.
İnceleme tarihi: 29 Eylül 2026. Kaynaklar: Türk Borçlar Kanunu ve AB ürün sorumluluğu direktifi. Örnekler genel analiz içindir; bir sorumluluk kararı değildir.