# Kulular Bilişim Teknolojileri Limited Şirketi yazıları, tam metin > Bu dosya sitedeki tüm yazıların tam metnini içerir. Dil modelleri ve > yapay zekâ ajanları tek istekle okuyabilsin diye hazırlanmıştır. Kaynak: https://kulular.com.tr Kanonik özet: https://kulular.com.tr/llms.txt Yazı sayısı: 11 Kaynak gösterimi: Yazılar genel bilgilendirme amaçlıdır ve somut olaya ilişkin hukuki görüş yerine geçmez. Alıntı yaparken yazının başlığını ve adresini belirtiniz. --- # İnsan Denetimi Diye Koyduğunuz Onay Düğmesi Muhtemelen Çalışmıyor Adres: https://kulular.com.tr/yazilar/yapay-zeka-yonetisimi Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-08-30 Özet: Yapay zekâ yönetişiminde en çok kandırılan bileşen insan denetimi. Onay oranı yüzde yüze yaklaşıyorsa kararı fiilen sistem veriyor demektir. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 11 (İlgili kişinin hakları, otomatik sistemlerle analiz sonucuna itiraz) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - Kişisel Verileri Koruma Kurumu, yapay zekâ alanındaki rehber çalışmaları https://www.kvkk.gov.tr/ - OECD Yapay Zekâ İlkeleri https://oecd.ai/en/ai-principles - NIST Yapay Zekâ Risk Yönetimi Çerçevesi https://www.nist.gov/itl/ai-risk-management-framework Yapay zekâ yönetişimi konuşulurken en sık duyulan cümle şu. "İnsan onayı var, karar makineye bırakılmıyor." Bu cümleyi duyduğumda sorduğum tek soru var. Onay oranınız kaç? Cevap gelmiyor, çünkü ölçülmüyor. Ölçüldüğü birkaç yerde de sonuç genellikle yüzde doksan sekizin üzerinde çıkıyor. Yani denetleyen kişi elli kararda bir kez modele itiraz ediyor. Bu tabloda insan denetimi vardır demek, biçimsel olarak doğru ama işlevsel olarak yanlış. Kararı fiilen sistem veriyor, insan yalnızca imza atıyor. ## Onay düğmesi neden çalışmıyor Sebep kötü niyet değil, tasarım. Bir kullanıcıya günde üç yüz öneri gösterip her birini onaylamasını isterseniz, o kullanıcı kısa sürede otomatikleşir. Modelin doğruluk oranı yüksekse bu daha da hızlanır, çünkü reddettiği birkaç durumda da genellikle model haklı çıkar ve kullanıcı kendi yargısına güvenmeyi bırakır. Buna literatürde otomasyona aşırı güven deniyor ve bilinen bir olgu. Yani sistem iyi çalıştıkça insan denetimi zayıflıyor. Bu, denetimi tasarlarken hesaba katılması gereken bir gerçek. ## Denetimi anlamlı kılan üç koşul Denetimin işlevsel olabilmesi için üç şeyin birlikte bulunması gerekiyor. Denetleyen kişi önerinin dayanağını görebilmeli. Modelin hangi girdilere bakarak bu sonuca vardığı gösterilmiyorsa, kişi yalnızca sonucu değerlendirebilir ve sonucu değerlendirmek için kendi başına baştan karar vermesi gerekir. Bu, denetimi pratikte imkânsız kılar. Reddetme maliyetsiz olmalı. Reddettiğinde ek form doldurması, gerekçe yazması ve amirinden onay alması gereken bir kullanıcı, reddetmemeyi seçer. Reddetme akışı en az onay akışı kadar kolay olmalı. Reddin bir sonucu olmalı. Reddedilen öneriler bir yere yazılıp kimse bakmıyorsa, denetleyen kişi bunu fark eder ve zamanla ilgisini keser. Reddedilen durumların modelin geliştirilmesine girdi olması, denetimi canlı tutar. ## Ölçmediğiniz denetim yoktur Bu üç koşul kurulduktan sonra bile ölçüm gerekiyor. İzlenmesi gereken asgari üç gösterge var. Reddetme oranı, karar başına harcanan ortalama süre ve reddedilen kararların sonradan doğru çıkma oranı. Karar başına süre saniyeler mertebesine düşmüşse denetim yapılmıyor demektir. Reddetme oranı sıfıra yaklaşmışsa aynı sonuç. Bu göstergeler bir denetimde sorulduğunda cevabı olan kurum sayısı çok az. Oysa bunlar zor ölçümler değil, sistemin zaten ürettiği verilerden çıkarılıyor. ## İtiraz hakkı mimariyi belirliyor 6698 sayılı Kanun'un 11. maddesi, kişiye münhasıran otomatik sistemlerle analiz edilmesi suretiyle aleyhine bir sonuç doğmasına itiraz etme hakkı tanıyor. Bu hükmün teknik sonucu doğrudan. İtiraz geldiğinde kararın nasıl verildiğini göstermek zorundasınız. Gösteremiyorsanız kararı savunamazsınız. Buradan çıkan mimari kural şu. Kişi hakkında sonuç doğuran bir akışta, gerekçe üretmeyen bir model kullanılamaz. Bu, model seçiminde bir kısıt olarak baştan yazılmalı. Sonradan açıklanabilirlik eklemek, çoğu mimaride mümkün değil. ## Kayıt tutmak yetmez, doğru şeyi kaydetmek gerekir Denetim izi denince akla günlük tutmak geliyor ama günlüğün içeriği belirleyici. Bir kararın sonradan incelenebilmesi için beş şeyin birlikte kaydedilmesi gerekiyor. Sisteme giren veri, modelin sürümü, üretilen çıktı, çıktının dayandığı gerekçe ve insanın verdiği son karar. Bu beşi ayrı sistemlerde tutulursa sonradan eşleştirilemiyor. Model sürümü kaydedilmemişse, aylar sonra "o tarihte model ne diyordu" sorusuna cevap verilemiyor. Model sürümünün kaydedilmemesi, uygulamada en sık gördüğüm eksik. Model güncelleniyor, eski kararlar yeni modelle açıklanmaya çalışılıyor ve tutmuyor. ## Emin olmakla olmamak arasındaki fark gösterilmeli Son bir nokta. Sistem, düşük güvenle ürettiği çıktıyı yüksek güvenle ürettiğinden ayırt edilebilir biçimde göstermeli. Bu ayrım yoksa kullanıcı hepsine eşit güveniyor ve hatanın en olası olduğu yerde uyarı almıyor. Oysa modelin kendi belirsizliği çoğu zaman ölçülebiliyor. Bu ölçümü arayüze taşımak, denetimin en ucuz ve en etkili iyileştirmesi. Bir yapay zekâ projesinde bugün yapılabilecek tek bir iş seçilecek olsaydı, ben bunu seçerdim. --- # Yazılım Uyuşmazlıklarının Çoğu Tek Bir Eksik Maddeden Çıkıyor Adres: https://kulular.com.tr/yazilar/yazilim-gelistirme-sozlesmesi Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-08-21 Özet: Teslim edildi mi edilmedi mi tartışması, kabul ölçütü yazılmadığı için çıkıyor. Bu tek maddenin eksikliği, aylarca süren uyuşmazlıkların ortak sebebi. Kaynaklar: - 6098 sayılı Türk Borçlar Kanunu, m. 470 vd. (Eser sözleşmesi) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6098.pdf - 5846 sayılı Fikir ve Sanat Eserleri Kanunu (Bilgisayar programları ve mali hakların devri) https://www.mevzuat.gov.tr/mevzuatmetin/1.3.5846.pdf - 6698 sayılı Kişisel Verilerin Korunması Kanunu (Veri işleyen sıfatı) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf Bir yazılım uyuşmazlığı dosyası açıldığında taraflar genellikle şunu tartışıyor. Yazılım çalışıyor mu çalışmıyor mu. Bu tartışmanın çözülememesinin sebebi teknik değil. Sözleşmede "çalışıyor" kelimesinin ne anlama geldiği yazmıyor. Kabul ölçütü yoksa, geliştirici teslim ettiğini, müşteri almadığını söylüyor ve ikisi de kendi ölçütüne göre haklı. Bu tek eksiklik, gördüğüm yazılım uyuşmazlıklarının ortak paydası. ## Kabul ölçütü nasıl yazılmalı Kabul, teslimin hukuki sonucunu doğuran an. Ayıp sorumluluğunun süresi de buradan işlemeye başlıyor. Yani bu tarihin belirsiz olması, sorumluluğun ne zaman biteceğinin de belirsiz olması demek. Çalışan bir kabul maddesi şunları içeriyor. Kabul testinin listesi, testin koşulacağı ortam, testi kimin koşacağı, itiraz süresi ve süre içinde itiraz gelmezse kabulün gerçekleşmiş sayılacağı hükmü. En çok atlanan kalem test ortamı. Geliştiricinin makinesinde çalışan yazılım, müşterinin ortamında çalışmayabiliyor ve o noktada kimin sorumlu olduğu tartışılıyor. Ortam sözleşmede tanımlanmışsa bu tartışma çıkmıyor. Kabul ölçütünü beğeniye bağlamak ise en kötü seçenek. "Müşterinin memnuniyetine" bağlanan bir kabul, süresiz bir yükümlülük yaratıyor ve geliştiricinin işi hiç bitmiyor. ## Fikri haklar kendiliğinden geçmiyor İkinci sık hata mülkiyet varsayımı. Müşteri, ödediği bedelin karşılığında kodun sahibi olduğunu düşünüyor. Hukuken durum böyle değil. Bilgisayar programları 5846 sayılı Kanun kapsamında eser olarak korunuyor ve aksi kararlaştırılmadıkça mali haklar eser sahibinde kalıyor. Devir açıkça düzenlenmeli, yazılı yapılmalı ve devredilen haklar tek tek gösterilmeli. "Tüm haklar devredilmiştir" biçimindeki genel bir ifade tartışmaya açık. Bunun yanında üç kategorinin ayrılması gerekiyor. Müşteriye özgü olarak yazılan kod genellikle devrediliyor. Geliştiricinin önceden var olan bileşenleri devredilmiyor, lisanslanıyor ve lisansın kapsamı ile süresi ayrıca yazılıyor. Açık kaynak bileşenler kendi lisanslarına tabi ve kullanılanların listesi sözleşme ekinde verilmeli. Bu üçü ayrılmadığında ortaya şu çıkıyor. Müşteri kodun tamamına sahip olduğunu sanıyor, geliştirici kendi kütüphanesini başka projede kullanmaya devam ediyor ve mesele ancak bir uyuşmazlıkta fark ediliyor. ## Değişiklik yönetimi olmayan sözleşme yürümez Kapsam metni ne kadar iyi yazılırsa yazılsın, proje sırasında değişiklik talebi geliyor. Sözleşmede bu talebin nasıl ele alınacağı yazmıyorsa her talep bir pazarlığa dönüşüyor. Çalışan bir düzenleme şu soruları cevaplıyor. Talep kime, hangi biçimde iletilir. Etki analizi kim tarafından, kaç gün içinde yapılır. Fiyat ve takvim etkisi nasıl hesaplanır. Onay kimin imzasıyla verilir. Onaylanmayan talep ne olur. Bu beş soru cevaplandığında değişiklik bir kriz olmaktan çıkıp bir süreç hâline geliyor. ## Veri işleyen sıfatı fark edilmeden doğuyor Geliştirici, müşterinin kişisel verilerine erişiyorsa 6698 sayılı Kanun anlamında veri işleyen konumuna geliyor. Bu sıfat çoğu zaman farkında olunmadan kazanılıyor. En yaygın hâli test ortamında gerçek veri kullanılması. Üretim veritabanının bir kopyası test ortamına alınıyor, geliştiriciler onunla çalışıyor ve o andan itibaren bir veri işleme ilişkisi doğmuş oluyor. Sözleşmede buna dair hüküm yoksa, ilişki hukuki dayanaktan yoksun yürüyor. En temiz çözüm bu durumu hiç doğurmamak. Maskelenmiş veya sentetik veriyle test yapmak teknik olarak zor değil ve riski büyük ölçüde ortadan kaldırıyor. Gerçek veriye erişim gerçekten zorunluysa, işlemenin konusu, süresi ve amacı, geliştiricinin talimatla bağlılığı, alt işleyen kullanımı, güvenlik tedbirleri ve sözleşme sonunda verinin iadesi veya imhası yazılı olarak düzenlenmeli. ## Bakım ayrı bir sözleşmedir Son olarak bakım ve destek. Bu, geliştirmeden ayrı bir edim ve ayrı düzenlenmesi gerekiyor. Yazılması gereken şey müdahale süresi değil, arıza sınıflandırması. Hangi arızanın hangi sınıfa gireceği tanımlanmazsa, her arıza en yüksek öncelikte talep ediliyor. Sınıf tanımlandıktan sonra her sınıf için müdahale ve çözüm süresi ayrı ayrı yazılıyor. Bir de ölçüm meselesi var. Hizmet seviyesi taahhüdü, ölçülebilir değilse ihlal edildiğinde yaptırımsız kalıyor. Ölçümün nasıl yapılacağı ve kimin kaydına göre yapılacağı sözleşmede olmalı. ## Sözleşmeyi kim yazmalı Bu maddelerin tamamı, hukuk ile mühendisliğin birlikte karar vermesini gerektiriyor. Kabul ölçütünü avukat tek başına yazamaz, çünkü neyin test edilebilir olduğunu bilmez. Fikri hak devrini mühendis tek başına yazamaz. Sözleşme müzakeresine teknik ekip olmadan giden taraf, sonradan uygulanamayacak hükümler kabul ediyor. Uygulanamayan hüküm, uyuşmazlık çıktığında hiç yokmuş gibi davranıyor. --- # Bulut Sağlayıcınız Yurt Dışındaysa Zaten Aktarım Yapıyorsunuz Adres: https://kulular.com.tr/yazilar/yurt-disi-veri-aktarimi Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-08-11 Özet: Yurt dışına aktarım, veriyi bilerek göndermekle sınırlı değil. Sunucusu Almanya'da olan bir hizmeti kullanmak da aktarımdır ve çoğu kurum bunu geç fark ediyor. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 9 (Kişisel verilerin yurt dışına aktarılması) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - Kişisel Verileri Koruma Kurumu, yurt dışına aktarım rehberleri ve Kurul kararları https://www.kvkk.gov.tr/ Bir kuruma "yurt dışına veri aktarıyor musunuz" diye sorulduğunda alınan cevap genellikle hayır oluyor. Ardından hangi hizmetleri kullandıkları soruluyor ve liste çıkıyor. Bulut barındırma, e-posta, müşteri destek yazılımı, analiz aracı, ödeme sağlayıcısı, yedekleme hizmeti. Bu listedeki hizmetlerin çoğunun sunucusu Türkiye'de değil. Yani cevap aslında evet ve kurum bunu bilmiyor. Bu yanlış anlamanın kaynağı şu. Aktarım kelimesi, bir dosyayı alıp göndermek gibi bilinçli bir eylemi çağrıştırıyor. Oysa verinin yurt dışındaki bir sistemde tutulması veya orada işlenmesi de aktarım. Ayrıca bir gönderme işlemi aramaya gerek yok. ## Aktarımın nerede başladığını görmek Kanun'un 9. maddesi yurt dışına aktarımı düzenliyor. Uygulamada zorluk hükmün kendisinde değil, aktarımın ne zaman gerçekleştiğini tespit etmekte. Şu üç durumun hepsi aktarım doğuruyor. Verinin yurt dışındaki bir sunucuda barındırılması. Yurt dışındaki bir ekibin destek amacıyla sisteme erişebilmesi. Verinin yurt dışında işlenip sonucun geri dönmesi. Üçüncüsü en çok gözden kaçanı. Bir metin analiz servisi kullanıyorsanız ve o servis yurt dışındaysa, gönderdiğiniz metin orada işleniyor. Sonucun size dönmesi, aktarımın gerçekleşmediği anlamına gelmiyor. Kendi sitemizde bu durum var. Ana sayfadaki serbest metin alanı, girilen metni analiz için yurt dışındaki bir sağlayıcıya gönderiyor. Bu yüzden aydınlatma metnimizde bunun ayrı bir bölümü bulunuyor ve ziyaretçi o alanı hiç kullanmadan sitenin tamamını gezebiliyor. İşlevin kendisi kadar, kullanılmadığında hiçbir aktarım doğmaması da bir tasarım kararı. ## Envanterde eksik olan sütun Çoğu veri envanterinde kategori, amaç ve saklama süresi yazıyor. Eksik olan sütun şu. Bu veri fiziksel olarak hangi ülkede duruyor? Bu sütun eklendiğinde tablo değişiyor. Kurumun kendi veri merkezinde tuttuğunu sandığı verilerin bir kısmının aslında yurt dışında olduğu ortaya çıkıyor. Yedekler özellikle sık kaçırılıyor, çünkü yedekleme hizmeti genellikle ayrı bir sağlayıcıdan alınıyor ve kimse onun nerede olduğuna bakmıyor. Envanteri çıkarırken sağlayıcıya doğrudan sormak gerekiyor. Sözleşmede veri ikametgâmına ilişkin bir taahhüt varsa yazılı olarak alınmalı. Yoksa, sağlayıcı bunu tek taraflı değiştirebilir ve siz haberdar olmazsınız. ## Alt işleyen zinciri İkinci katman daha da görünmez. Kullandığınız sağlayıcı, kendi altyapısı için başka sağlayıcılardan hizmet alıyor olabilir. Bir müşteri destek yazılımı kullanıyorsunuz, o yazılım bir bulut sağlayıcısında çalışıyor, arama işlevi için başka bir servis kullanıyor ve bildirim göndermek için bir üçüncüsüne bağlanıyor. Verileriniz bu zincirin tamamında dolaşıyor. Bu zinciri tamamen kontrol etmek mümkün değil ama görünür kılmak mümkün. Sözleşmede alt işleyen kullanımına ilişkin bildirim yükümlülüğü ve değişiklik hâlinde itiraz hakkı düzenlenmeli. Çoğu kurumsal sağlayıcı bunu zaten sunuyor, sadece sorulması gerekiyor. ## Ne yapmalı Yapılacak ilk iş bir hizmet envanteri çıkarmak. Kullanılan her dış hizmetin adı, ne için kullanıldığı, hangi kişisel veriye eriştiği ve sunucularının nerede olduğu. Bu tablo çıktıktan sonra üç seçenek oluyor. Hizmeti Türkiye'de barındıran bir alternatifle değiştirmek, sağlayıcının Türkiye bölgesi varsa oraya taşımak, ya da aktarımı Kanun'un öngördüğü mekanizmalardan biriyle hukuki zemine oturtmak. Üçünün de maliyeti var ve seçim işin niteliğine göre değişiyor. Ama hiçbirini seçmemek, yani durumu fark etmemiş olmak, en pahalı seçenek. Çünkü o hâlde aydınlatma metniniz de yanlış bilgi veriyor ve tek bir eksiklik iki ayrı yükümlülüğü birden ihlal etmiş oluyor. Bu alandaki düzenlemeler değişiyor ve Kurul kararları çerçeveyi zaman zaman yeniden çiziyor. Bir aktarım mekanizması seçmeden önce güncel duruma bakılması gerekiyor. --- # Yetmiş İki Saatin Nereye Gittiğini Saat Saat Anlatıyorum Adres: https://kulular.com.tr/yazilar/veri-ihlali-bildirimi Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-08-01 Özet: İhlal bildiriminde asıl darboğaz hukuki değil. Süre, hangi verinin nerede tutulduğunu tespit etmeye harcanıyor ve o tespit yapılamıyor. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 12 (Veri güvenliğine ilişkin yükümlülükler, beşinci fıkra bildirim) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - Kişisel Verileri Koruma Kurulu kararları (Bildirim süresi ve usulüne ilişkin) https://www.kvkk.gov.tr/ Bir kuruma pazartesi sabahı bir uyarı düşüyor. Bir sunucuda olağandışı erişim tespit edilmiş. Bu andan itibaren yetmiş iki saat işlemeye başlıyor. Kulağa geniş bir süre gibi geliyor. Aşağıda o sürenin gerçekte nasıl harcandığını anlatıyorum, çünkü bu tabloyu görmeden ihlal hazırlığının neden ihlalden aylar önce yapılması gerektiği anlaşılmıyor. ## İlk sekiz saat: olay gerçekten ihlal mi İlk yapılan şey uyarının doğru olup olmadığını anlamak. Yanlış alarm olabilir, bir bakım işlemi olabilir, bir yetkilendirme hatası olabilir. Bu aşamada teknik ekip günlükleri inceliyor. Günlükler yeterli değilse, ki çoğu kurumda değil, tespit uzuyor. Erişimin hangi hesapla, hangi adresten ve hangi tabloya yapıldığı bilinmiyorsa, sonraki hiçbir adım atılamıyor. Buradaki ilk kritik nokta şu. Günlük tutmuyorsanız süre burada tükenmeye başlıyor ve geri kazanılmıyor. ## Sonraki yirmi dört saat: hangi veri etkilendi Olayın ihlal olduğu anlaşıldıktan sonra tek bir soru geliyor. O sunucuda hangi kişisel veri vardı? Envanteri güncel olan kurum bu soruyu on dakikada cevaplıyor. Olmayan kurum, veritabanı şemasını inceleyerek tespit etmeye çalışıyor. Tablo adlarına bakıyor, örnek kayıtlar açıyor, geliştiricilere soruyor. Bu iş bir günü rahatça alıyor. Sorunun ikinci yarısı daha da zor. Yedeklerde ne var? Bir rapor için dışarı alınmış bir kopya var mı? Test ortamına aktarılmış bir örnek var mı? Bu soruların cevabı hiçbir yerde yazılı değilse, cevap tahmine dayanıyor ve tahmine dayanan bir bildirim, sonradan düzeltilmek zorunda kalıyor. ## Sonraki on iki saat: kaç kişi etkilendi Kapsam belirlendikten sonra sayı çıkarılması gerekiyor. Kaç ilgili kişi, hangi veri kategorileri, hangi coğrafyalar. Burada sık yapılan hata, sayının yuvarlanması. "Yaklaşık on bin kişi" demek bildirimin kabul edilmemesine yol açmasa da, sonradan gerçek sayının farklı çıkması kurumun beyanının güvenilirliğini zedeliyor. Sayı çıkarılamıyorsa, çıkarılamadığının ve neden çıkarılamadığının yazılması daha doğru. ## Kalan süre: bildirimin hazırlanması ve iletilmesi Kurul'a yapılacak bildirimde ihlalin ne zaman ve nasıl gerçekleştiği, hangi veri kategorilerinin etkilendiği, olası sonuçları ve alınan ile alınacak tedbirler yer alıyor. Bu metni boş sayfadan yazmak, kalan süreyi tüketiyor. Şablonu önceden hazır olan kurum yarım saatte dolduruyor. Ayrıca metni kimin imzalayacağı önceden belli olmalı, çünkü imza yetkisi tartışması bu aşamada başlarsa süre yetmiyor. İlgili kişilere bildirim ayrı bir iş. Etkilenen kişilerin belirlenmesini müteakip makul olan en kısa sürede yapılıyor. Doğrudan iletişim mümkün değilse uygun başka yöntemler kullanılıyor. Bu iletişimin dili önemli. Teknik ayrıntıya boğulmuş bir metin, kişinin ne yapması gerektiğini anlamasını engelliyor. ## Planda gerçekten ne olmalı Yukarıdaki tablodan çıkan sonuç şu. Müdahale planının değeri, olay anında düşünülmesi gerekenleri önceden düşünmüş olmasında. Planda rol dağılımı bulunmalı. Kim tespit yapar, kim ihlal olduğuna karar verir, kim imzalar. Tek kişiye bağlı bir plan, o kişi izinliyken çöküyor. Eşik tanımı bulunmalı. Hangi olayın ihlal sayılacağı önceden yazılmalı, aksi hâlde bu tartışma süre içinde yapılıyor. Kanıt koruma kuralı bulunmalı. İlk refleks sistemleri temizlemek oluyor ve bu, tespiti imkânsız hâle getiriyor. Günlüklerin dokunulmadan saklanması planda açıkça yazılmalı. İletişim şablonu bulunmalı. Hem Kurul'a hem ilgili kişilere yapılacak bildirimin taslağı hazır durmalı. ## Bildirimden sonra biten bir şey yok Bildirim yükümlülüğün sonu değil. Kurul, alınan teknik ve idari tedbirlerin yeterliliğini değerlendiriyor. Aynı kurumda tekrarlayan ihlal, tedbirlerin yetersiz kaldığının göstergesi olarak okunuyor. Bu nedenle ihlal sonrası yapılan düzeltici faaliyetin kayda geçirilmesi ve etkisinin ölçülmesi gerekiyor. "Gerekli önlemler alınmıştır" cümlesi bir kanıt değil. ## Bugün yapılabilecek tek şey Bir ihlal yaşamadan önce yapabileceğiniz en yüksek getirili iş, envanteri fiziksel yerleşim bilgisiyle birlikte çıkarmak. Hangi veri hangi veritabanında, hangi tabloda, hangi alanda ve hangi yedekte. Bu tablo hazırsa yetmiş iki saatin ilk otuz saati geri kazanılmış olur. Hazır değilse, plan ne kadar iyi yazılmış olursa olsun süre yetmez. --- # Aydınlatma Metninizi Denetleyen Kişi Önce Neye Bakar Adres: https://kulular.com.tr/yazilar/aydinlatma-metni-nasil-yazilir Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-07-25 Özet: İnternetten alınmış bir şablonu kendi metniniz sanıyorsanız, denetimde ilk sorulacak soru sizi zorlar. Bu metinde yazan kategoriler nereden çıkarıldı? Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 10 ve m. 11 https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - Aydınlatma Yükümlülüğünün Yerine Getirilmesinde Uyulacak Usul ve Esaslar Hakkında Tebliğ - Kişisel Verileri Koruma Kurumu, aydınlatma yükümlülüğü rehberi https://www.kvkk.gov.tr/ Bir kurumun aydınlatma metnini incelerken ilk yaptığım şey metni okumak değil. Metinde sayılan veri kategorilerini alıp veritabanı şemasıyla karşılaştırmak. Bu karşılaştırma neredeyse her seferinde aynı sonucu veriyor. Metinde yazmayan alanlar var. Bazen tersi de oluyor, metinde sayılan ama sistemde hiç toplanmayan kategoriler bulunuyor. İkisi de aynı sorunun belirtisi. Metin, gerçeğin tespitinden değil bir şablondan türetilmiş. ## Yükümlülük metin hazırlamak değil Kanun'un 10. maddesi, veri sorumlusunun kişisel veriyi elde ederken belirli hususları bildirmesini arıyor. Kimliği, işleme amacı, aktarılacağı taraflar ve amacı, toplama yöntemi ve hukuki sebebi, bir de 11. maddedeki haklar. Buradaki fiil bildirmek. Yani metin bir araç, yükümlülük ise doğru bilgiyi vermek. Yanlış bilgi veren bir metin, hiç metin olmamasından daha kötü bir konum yaratıyor, çünkü kurum artık gerçeğe aykırı bir beyanda bulunmuş oluyor. Bu yüzden metin yazma işi envanterden sonra gelir. Envanteri olan kurum metni bir günde yazar. Olmayan kurum, ne yazdığını bilmeden yazar. ## En sık gördüğüm beş hata Birkaç yıldır aynı hataları görüyorum ve bunların hiçbiri hukuk bilgisi eksikliğinden kaynaklanmıyor. Aydınlatma ile açık rızanın tek bir onay kutusunda birleştirilmesi. Kullanıcı "okudum, kabul ediyorum" diyerek hem aydınlatıldığını hem rıza verdiğini beyan ediyor. Aydınlatma bir bildirimdir ve kabul edilecek bir şey değildir. Bu birleştirme, rızanın ayrı bir irade beyanı olma niteliğini zedeliyor. Metnin işlem tamamlandıktan sonra gösterilmesi. Form gönderiliyor, sonra teşekkür sayfasında aydınlatma metnine bağlantı çıkıyor. Veri o an zaten toplanmış oluyor. Tek bir metnin bütün süreçlere uydurulması. İşe alım, müşteri iletişimi, tedarikçi ilişkisi ve web sitesi ziyareti aynı metinde toplanıyor. Sonuç, hiçbirini doğru anlatmayan bir genel metin oluyor. Hukuki sebebin yazılmaması ya da hepsinin birden sayılması. "Kanun'un 5. ve 6. maddelerinde belirtilen şartlar çerçevesinde" ifadesi bir hukuki sebep göstermiyor. Hangi işleme hangi bende dayanıyorsa o yazılmalı. Saklama süresinin belirtilmemesi. Tebliğ, ilgili kişiye verilecek bilgide bunun da yer almasını bekliyor ve süre yazılmadığında ilgili kişi ne kadar süreyle veri tutulacağını öğrenemiyor. ## Metin nasıl kurulmalı İyi bir aydınlatma metni süreç bazlı yazılıyor. Yani "şirketimiz kişisel verilerinizi işler" diye başlamıyor, "iletişim formunu doldurduğunuzda şu veriler işlenir" diye başlıyor. Her süreç için dört kolonlu bir tablo çıkarmak işi kolaylaştırıyor. Veri kategorisi, işleme amacı, hukuki sebep, saklama süresi. Bu tablo hazırsa metin kendiliğinden yazılıyor ve okuyan kişi de aradığını bulabiliyor. Dil meselesi de önemli. Tebliğ, bilginin açık, anlaşılır ve sade bir dille aktarılmasını arıyor. Uygulamada bunun tersini görüyoruz. Metinler uzuyor, cümleler ağırlaşıyor ve okunmaz hâle geliyor. Okunmayan bir metin, bildirim işlevini yerine getirmiyor. Sadeleştirmek burada bir üslup tercihi değil, yükümlülüğün gereği. ## Metni güncel tutmak Aydınlatma metni bir kez yazılıp unutulacak bir belge değil. Yeni bir alan eklendiğinde, yeni bir tedarikçiyle çalışılmaya başlandığında veya bir aktarım eklendiğinde metnin de güncellenmesi gerekiyor. Bunu sürdürülebilir kılmanın tek yolu, güncellemeyi geliştirme sürecine bağlamak. Veri modeline yeni bir kişisel veri alanı ekleyen bir değişiklik, envanterin ve metnin de güncellenmesini tetiklemeli. Bu bağ kurulmadığında metin ilk yılın sonunda gerçeklikten kopuyor ve kimse fark etmiyor. Kendi sitemizde bu bağı kurarken şunu yaptık. Yapay zekâ destekli analiz işlevini eklediğimizde, metne yurt dışı aktarımı anlatan ayrı bir bölüm girdi. O bölüm olmadan işlev yayına alınmadı. Sıralama böyle olmalı. --- # KVKK Uyum Sürecinde Envanter Neden Diğer Her Şeyden Önce Gelir Adres: https://kulular.com.tr/yazilar/kvkk-uyum-sureci Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-07-20 Özet: Uyum çalışmalarının çoğu aydınlatma metniyle başlıyor. Yanlış sıra. Envanter çıkarılmadan yazılan her belge, doğruluğu kontrol edilmemiş bir beyandır. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu (Özellikle m. 4, 5, 7, 10 ve 12) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik https://www.resmigazete.gov.tr/eskiler/2017/10/20171028-10.htm - Veri Sorumluları Sicili Hakkında Yönetmelik https://www.resmigazete.gov.tr/eskiler/2017/12/20171230-7.htm - Kişisel Verileri Koruma Kurumu, rehberler ve Kurul kararları https://www.kvkk.gov.tr/ Bir kuruma KVKK uyum çalışması için gidildiğinde elde genellikle şu vardır. Bir aydınlatma metni, bir açık rıza formu, bir saklama ve imha politikası. Üçü de hazırlanmış, imzalanmış, klasöre konmuştur. Sonra tek bir soru sorulur. Bu metinlerde yazan veri kategorileri nereden çıkarıldı? Cevap çoğunlukla şudur. İnternette bulunan bir örnek alınmış, kurumun adı yazılmış, birkaç madde eklenmiş. Yani beyan, gerçeğin tespitinden değil bir şablondan türetilmiş. Bu, uyum çalışmalarında gördüğüm en yaygın ve en maliyetli sıra hatasıdır. ## Sıra neden bu kadar önemli Aydınlatma metni bir beyandır. Kanun'un 10. maddesi, veri sorumlusunun işlenen veri kategorilerini, amaçları, aktarılacağı tarafları ve hukuki sebebi bildirmesini öngörür. Beyanda bulunuyorsanız, beyanınızın doğru olması gerekir. Envanter çıkarmadan yazılan metin doğru olamaz. En iyi ihtimalle eksik olur. Denetimde metinde yer almayan bir işleme faaliyeti tespit edildiğinde, ortada yalnızca teknik bir eksiklik değil, aydınlatma yükümlülüğünün gereği gibi yerine getirilmemesi hâli bulunur. Bunun tersi de doğrudur. Envanteri elinde olan bir kurum aydınlatma metnini bir günde yazar, çünkü yazılacak her şey zaten tespit edilmiştir. ## Envanterde gerçekten ne aranıyor Envanter tablosu genellikle veri kategorisi, amaç ve saklama süresi sütunlarıyla hazırlanır. Bu üç sütun yetmez. Eksik olan sütun şudur. Bu veri fiziksel olarak nerede duruyor? Hangi veritabanında, hangi tabloda, hangi alanda? Yedeklerde de var mı? Bir üçüncü taraf hizmet sağlayıcının sisteminde kopyası var mı? Bu soru sorulmadığında envanter, kurumun kendi hakkındaki kanaatini yansıtır ve gerçeği yansıtmaz. Bir veri ihlali yaşandığında sorulacak ilk soru "o sunucuda hangi kişisel veri vardı" olacaktır. Fiziksel yerleşimi yazmayan envanter o an işe yaramaz. ## Hukuki sebep seçimi bir mimari karardır Kanun'un 5. maddesi işleme şartlarını sayar. Uygulamada bu maddeye çoğu zaman formalite olarak bakılır, oysa seçilen hukuki sebep sistemin nasıl kurulacağını doğrudan belirler. Açık rızaya dayanan bir işleme faaliyetinde, rıza her an geri alınabilir. Geri alındığı anda işlemenin durması gerekir. Bu, sistemde şu üç şeyi zorunlu kılar. Rızanın hangi sürüm metne verildiğinin kaydı, geri alma işlemini kullanıcıya sunan bir arayüz ve rıza geri alındığında ilgili işlemeyi durduran bir kontrol. Üçü de yoksa rızaya dayanmak kurumu savunulamaz bir konuma sokar. Buna karşılık sözleşmenin ifası için zorunlu olan bir işlemede bu mekanizmalar gerekmez. Aynı veri, farklı hukuki sebeple işlendiğinde bambaşka bir teknik yük doğurur. Bu yüzden hukuki sebep seçimini avukat tek başına, mimariden bağımsız olarak yapmamalıdır. ## Saklama süresi ve onu uygulayan bileşen Saklama süresi belirlemek, uyum çalışmasının en kolay kısmıdır. Uygulanmasını sağlamak en zor kısmıdır. Çalışan bir kurgu şöyle görünür. Her kayıt kendi saklama süresini taşır, örneğin bir `saklama_bitis` alanı bulunur. Süresi dolan kayıtları tarayan bir iş düzenli olarak çalışır. İş, kaydı siler, yok eder ya da anonim hâle getirir ve yaptığı işlemi ayrı bir tabloya yazar. Denetimde sunulan şey politika metni değil, o tablodur. Bu yapıyı kurmayan kurumlar genellikle şunu yapar. Süreyi politikaya yazar, uygulamayı ileri bir tarihe bırakır ve o tarih hiç gelmez. Aradan iki yıl geçtiğinde elde silinmemiş veri ve onun silinmiş olması gerektiğini yazan bir belge bulunur. Bu ikisinin bir arada bulunması, hiç politika yazmamış olmaktan daha kötü bir durumdur. ## VERBİS ve kapsam meselesi Veri Sorumluları Sicili'ne kayıt yükümlülüğü, Kurul tarafından belirlenen kriterlere tabidir. Yıllık çalışan sayısı, mali bilanço büyüklüğü ve işlenen verinin niteliği belirleyicidir. Burada bir uyarı gerekiyor. Muafiyet kapsamı Kurul kararlarıyla zaman içinde değişmiştir ve değişmeye devam edebilir. Bugün muaf olan bir kurum, çalışan sayısı arttığında yükümlü hâle gelir. Bu nedenle muafiyet bir kez tespit edilip unutulacak bir konu değildir, yıllık olarak kontrol edilmelidir. Güncel eşikler için Kurum'un yayımladığı duyurulara bakılması gerekir. ## İhlal planı önceden yazılır Kanun'un 12. maddesinin beşinci fıkrası, ihlalin en kısa sürede Kurul'a bildirilmesini öngörür. Kurul kararlarında bu süre yetmiş iki saat olarak somutlaşmıştır. Yetmiş iki saat, olayı fark ettikten sonra kapsamı tespit etmek, etkilenen kişileri belirlemek ve bildirimi hazırlamak için ayrılan toplam süredir. Bu adımların ilki bile çoğu kurumda günler alır, çünkü hangi verinin nerede tutulduğu yazılı değildir. Yani ihlal hazırlığı ihlalden çok önce başlar ve yine aynı yere çıkar. Envanter. ## Uyum bittiğinde ne olur Bitmez. Yeni bir özellik yeni bir veri alanı doğurur. Yeni bir tedarikçi yeni bir aktarım doğurur. Kurul kararları çerçeveyi daraltır. Bu yüzden uyumu bir proje olarak kurgulamak yerine, ürün geliştirme sürecinin içine yerleştirmek gerekir. Yeni bir alan eklenirken envanterin de güncellenmesi, kod incelemesinin bir parçası hâline gelirse süreç kendi kendini taşır. Aksi hâlde her yıl baştan başlanır ve her seferinde aynı sıra hatası tekrarlanır. --- # Hukuk Teknolojileri: Sözleşme Şablonu Üreten Araçlar Neden Asıl İşi Yapmıyor Adres: https://kulular.com.tr/yazilar/hukuk-teknolojileri Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-06-16 Özet: LegalTech denince akla belge üretimi geliyor. Oysa alanın çözmesi gereken asıl mesele, verilmiş bir hukuki yorumun çalışma anında tekrarlanabilir biçimde uygulanması. Kaynaklar: - 1136 sayılı Avukatlık Kanunu, m. 35 (Avukatların yalnız yapabileceği işler) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.1136.pdf - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 12 (Veri güvenliğine ilişkin yükümlülükler) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - 5070 sayılı Elektronik İmza Kanunu https://www.mevzuat.gov.tr/mevzuatmetin/1.5.5070.pdf - Türkiye Barolar Birliği Reklam Yasağı Yönetmeliği (Avukatlara yönelik ürünlerin tanıtımında dikkate alınmalı) Bir hukuk teknolojisi ürünü tanıtımına baktığınızda büyük ihtimalle şunu görürsünüz. Sözleşme taslağı üretiyor, madde öneriyor, belgeyi biçimlendiriyor. Bunlar faydalı işler. Sorun şu ki alanın asıl meselesi bu değil ve bu araçların çözdüğünü sandığımız problem, aslında problemin en kolay kısmı. Asıl mesele şurada. Bir kurum bir hukuki yükümlülüğe tabidir. O yükümlülüğün ne anlama geldiğine dair bir yorum yapılır. Yorum bir belgeye yazılır. Sonra o belge bir klasöre konur ve kurumun günlük işleyişi, o belgeden habersiz biçimde devam eder. Belge ile sistem arasındaki bu kopukluk, uygulamada gördüğüm en pahalı hatadır ve hiçbir sözleşme şablonu aracı bunu çözmez. ## Yorum insanın, uygulama sistemin işi Bir kuralı yazılıma çevirmek, kuralı koda yazmak değildir. Arada, otomatikleştirilemeyen bir adım vardır. 6698 sayılı Kanun'un 7. maddesi, işlenmesini gerektiren sebeplerin ortadan kalkması hâlinde kişisel verinin silineceğini, yok edileceğini veya anonim hâle getirileceğini düzenler. Bu hüküm açıktır. Fakat "sebebin ortadan kalkması" bir kurumun fatura verisi bakımından tam olarak ne demektir? Müşteri ilişkisinin sona ermesi mi, vergi mevzuatındaki saklama süresinin dolması mı, ikisinin daha geç olanı mı? Bu soruya bir hukukçu cevap verir. Verdiği cevap bir yorumdur ve o yorum kayıt altına alınmadığı sürece, altı ay sonra kimse neden o süreyi seçtiğimizi hatırlamayacaktır. Yazılımın işi burada başlar. Yorum verildikten sonra, o yorumun her seferinde aynı biçimde uygulanmasını ve uygulandığının gösterilebilmesini sağlamak. Bunu yapan bir sisteme sahipseniz hukuk teknolojisi kullanıyorsunuz demektir. Şablon üretiyorsanız kelime işlemci kullanıyorsunuz. ## Belge ile sistem ayrıştığında ne oluyor Somut bir örnek üzerinden gidelim. Bir kurumun saklama politikasında müşteri iletişim kayıtlarının iki yıl saklanacağı yazıyor. Denetim geldiğinde bu politika sunuluyor. Denetçi tek bir soru soruyor. Bu süreyi hangi bileşen uyguluyor? Cevap çoğu zaman yoktur. Veritabanında `created_at` alanı vardır ama `expires_at` yoktur. Süresi dolan kaydı silen bir iş yoktur. Silme işlemi olsa bile bir kayıt üretmez. Sonuçta kurum, politikasında yazan şeyi yaptığını gösteremez. Politikanın kendisi delil değildir, olsa olsa niyet beyanıdır. Bu tabloyu düzeltmenin yolu daha iyi bir politika metni yazmak değil. Veri modeline saklama süresini taşıyan bir alan eklemek, süreyi uygulayan bir bileşen yazmak ve o bileşenin çalıştığında kayıt üretmesini sağlamaktır. Üçü birlikte olduğunda politika metni artık bir iddia değil, sistemin yaptığı işin tarifi hâline gelir. ## Zincirin beş halkası Bir hukuki metnin sistemde çalışan bir kontrole dönüşmesi beş adımda olur. Bu adımların sırası önemlidir ve herhangi biri atlandığında sonuç güvenilmez hâle gelir. Önce hüküm tespit edilir. Uygulanacak kural ve varsa istisnası belirlenir. Ardından yorum yapılır, yani kuralın somut iş sürecinde ne anlama geldiği kararlaştırılır. Bu adım insana aittir ve kayıt altına alınmalıdır. Üçüncü adımda yorum mimariye bağlanır, hangi alanın hangi kuralı taşıyacağı belirlenir. Dördüncü adımda kuralı çalışma anında uygulayan bileşen yazılır. Beşinci adımda o bileşenin çalıştığı kayda geçirilir. Yorum yapılmadan yazılan kontrol yanlış kuralı uygular. Kanıt üretmeyen kontrol ise denetimde işe yaramaz. Sık karşılaştığım hata, üçüncü ve dördüncü adımın atlanıp doğrudan beşinciye geçilmesidir. Kurum bir günlük tutar, orada bir şeyler yazar, ama o günlüğün hangi kuralın uygulandığını gösterdiği belli değildir. ## Avukatlık tekeli meselesi Bu alanda ürün geliştiren herkesin bilmesi gereken bir sınır var. 1136 sayılı Avukatlık Kanunu'nun 35. maddesi, hukuki işlerin takibini ve hukuki mütalaa verilmesini avukatlara özgülemiştir. Pratikte bu, ürününüzün ne söyleyip ne söyleyemeyeceğini belirler. "Sözleşmenizde şu madde eksik" demek bilgilendirmedir. "Bu sözleşmeyi imzalamayın, aleyhinize sonuç doğurur" demek görüş vermektir. Aradaki çizgi ince ve ürün tasarımında bilinçli olarak korunması gerekir. Çizgiyi koruyan en sağlam yöntem, sistemin kararı kendisinin vermemesi ve her çıktının arkasında bir insan kararının görünür kalmasıdır. Bu sınır bir engel gibi görünür ama aslında iyi bir tasarım kısıtıdır. Kararı üstlenmeyen bir sistem, hata yaptığında da sorumluluğu üstlenmez ve bu, kullanıcının sisteme körü körüne güvenmesini engeller. ## Yapay zekâ neyi değiştirdi, neyi değiştirmedi Doğal dil işleme, doküman incelemesinde gerçek bir verim sağlıyor. Yüzlerce sözleşme içinden belirli bir madde tipini bulmak, eskiden haftalar alan bir işti. Şimdi saatler alıyor. Değişmeyen şey sorumluluk. Modelin ürettiği çıktının hangi belgeden ve hangi paragraftan çıktığı izlenebilir değilse, o çıktı bir tespit değil bir tahmindir. Aynı şekilde, sistem emin olmadığı bir sonucu emin olduğu bir sonuçtan ayırt edilebilir biçimde göstermiyorsa, kullanıcı hepsine eşit güvenir ve hata fark edilmeden geçer. Bu iki koşul sağlanmadığında elde edilen verimlilik kazancı, sonradan doğan riskle telafi edilir. Kötüsü, riskin ne zaman gerçekleşeceği bilinmez. ## Nereden başlanmalı Kurumsal bir hukuk teknolojisi çalışmasına başlarken tek bir yükümlülük seçmenizi öneririm. Tamamını birden ele almak kulağa iyi gelir ama uygulamada hiçbiri bitmez. Seçilen yükümlülük için beş halkanın tamamı kurulur. Hüküm yazılır, yorum kayda geçer, veri modeline bağlanır, kontrol çalışır, kanıt üretilir. Bu çalışma altı haftada biter ve sonunda elinizde bir rapor değil, çalışan bir kontrol ve denetimde gösterilebilecek bir kayıt olur. İkinci yükümlülük çok daha hızlı ilerler. Çünkü zor olan kısım kural değil, zinciri ilk kez kurmaktır. --- # Uzayda Şirketiniz Adına Değil, Devlet Adına Hareket Ediyorsunuz Adres: https://kulular.com.tr/yazilar/uzay-hukuku Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-06-09 Özet: 1967 Dış Uzay Antlaşması'nın 6. maddesi, özel şirketlerin faaliyetinden devleti sorumlu tutuyor. Bu tek hüküm, uzay girişimlerinin sözleşme yapısını baştan belirliyor. Kaynaklar: - 1967 tarihli Dış Uzay Antlaşması, m. 2 ve m. 6 (Ulusal mülkiyet yasağı ve devlet sorumluluğu) https://www.unoosa.org/oosa/en/ourwork/spacelaw/treaties/outerspacetreaty.html - 1972 tarihli Sorumluluk Sözleşmesi (Yeryüzündeki zararda kusursuz sorumluluk) https://www.unoosa.org/oosa/en/ourwork/spacelaw/treaties/liability-convention.html - 1975 tarihli Tescil Sözleşmesi https://www.unoosa.org/oosa/en/ourwork/spacelaw/treaties/registration-convention.html - Türkiye Uzay Ajansı https://tua.gov.tr/ - Uluslararası Telekomünikasyon Birliği Radyo Düzenlemeleri (Frekans ve yörünge tahsisi) https://www.itu.int/pub/R-REG-RR Uzay hukukunda diğer bütün hukuk dallarından farklı çalışan tek bir kural var ve girişimcilerin çoğu bunu geç öğreniyor. 1967 tarihli Dış Uzay Antlaşması'nın 6. maddesi, devletlerin ulusal uzay faaliyetlerinden uluslararası düzeyde sorumlu olduğunu düzenliyor. Faaliyeti bir özel şirket yürütse bile sonuç değişmiyor. Madde ayrıca bu faaliyetlerin ilgili devletin yetkilendirmesine ve sürekli gözetimine tabi olduğunu söylüyor. Bunun ne anlama geldiğini bir örnekle görmek daha kolay. Bir yazılım şirketi hata yaptığında müşterisine karşı sorumlu olur. Bir uzay şirketi hata yaptığında, devlet başka bir devlete karşı sorumlu hâle gelir. Aradaki fark ölçek farkı değil, cins farkı. ## Sorumluluk zinciri nasıl kuruluyor 1972 tarihli Sorumluluk Sözleşmesi bu zinciri somutlaştırıyor. Yeryüzünde veya uçuş hâlindeki bir hava aracına verilen zararda fırlatan devletin kusursuz sorumluluğu bulunuyor. Yani kusur aranmıyor. Bu, ticari tarafta doğrudan bir sonuç doğuruyor. Devlet, kendisine yönelebilecek bu sorumluluğu özel operatöre yansıtmak isteyecektir. Yetkilendirme belgesinde rücu hükümleri, sigorta zorunluluğu ve teminat şartları bu yüzden bulunur. Sözleşme müzakeresine başlarken bu kalemlerin tutarını bilmiyorsanız, projenin maliyetini de bilmiyorsunuz demektir. Tescil tarafı da buna bağlı. 1975 tarihli Tescil Sözleşmesi uzaya fırlatılan cisimlerin kayda geçirilmesini öngörüyor. Tescil, bir cismin hangi devletin yargı yetkisi ve denetimi altında olduğunu belirliyor. Yani hangi hukukun uygulanacağı sorusunun cevabı burada başlıyor. ## Türkiye'de yetkilendirme haritası Türkiye Uzay Ajansı 2018 yılında Cumhurbaşkanlığı Kararnamesi ile kuruldu ve ulusal uzay programının hazırlanması ile faaliyetlerin koordinasyonundan sorumlu. Fakat uzay faaliyeti tek bir kurumla sınırlı kalmıyor. Frekans ve yörünge kullanımı ayrı bir rejime tabi ve burada Uluslararası Telekomünikasyon Birliği düzenlemeleri belirleyici. Ulusal düzeyde Bilgi Teknolojileri ve İletişim Kurumu yetkili. İhracat kontrolü söz konusuysa başka merciler devreye giriyor. Bir projeye başlarken bu haritanın çıkarılması gerekiyor. Hangi izin hangi kurumdan, hangi sırayla ve ne kadar sürede alınacak. Bu takvim, teknik geliştirme takviminden bağımsız ilerliyor ve genellikle ondan uzun sürüyor. Projeyi geciktiren şey çoğu zaman yazılım değil, izin. ## Verinin kendisi ayrı bir mesele Uzay projelerinde en sık karşıma çıkan pratik sorun teknik değil, veriye ilişkin. Görev verisi üzerindeki haklar fırlatma ve işletme sözleşmelerinde düzenlenmeli. Sözleşmede boşluk kalırsa sonradan çözmek çok zor, çünkü karşı tarafın da o veriye erişimi olmuş oluyor ve geriye dönük sınırlama pratikte işlemiyor. Yer gözlem verisinde ayrı bir başlık var. Çözünürlük arttıkça verinin kişisel veri niteliği kazanma ihtimali güçleniyor. Bir aracın plakasının okunabildiği bir görüntü ile şehir ölçeğinde bir görüntü aynı rejime tabi değil. Sistem tasarlanırken hangi çözünürlükten itibaren farklı bir işleme rejiminin devreye gireceği belirlenmeli ve bu, veri hattında bir kontrol noktası olarak kurulmalı. Üçüncü başlık bütünlük. Telemetri verisinin kökeni, zaman damgası ve değiştirilmemiş olduğu gösterilebilmeli. Bu, bir olay sonrası inceleme yapıldığında delil değeri taşıyacak tek şey. Kaydın sonradan üretilmiş olma ihtimali varsa, kaydın kendisi savunmada işe yaramaz. ## Kaynak çıkarımı tartışması Antlaşma'nın 2. maddesi ulusal mülkiyeti yasaklıyor. Gök cisimlerinden kaynak çıkarılmasının bu yasak karşısındaki durumu ise açık değil. Bazı devletler iç mevzuatlarında, çıkarılan kaynak üzerinde mülkiyet tanıyan düzenlemeler yaptı. Bu düzenlemelerin Antlaşma ile uyumu tartışmalı ve konuda yerleşmiş bir uluslararası uygulama henüz oluşmadı. Bu alanda çalışan bir girişime söylenebilecek dürüst şey şu. Hukuki zemin oturmamış durumda ve bu belirsizlik, yatırım kararında bir risk kalemi olarak yazılmalı. Kesinmiş gibi sunulan her görüş, bugün itibarıyla eksik bilgi veriyor. ## Sözleşme masasına ne getirmeli Uzay projelerinde teknik ekip ile hukuk ekibinin ayrı çalıştığı her yerde aynı sorunu görüyorum. Yer segmenti yazılımı yazılırken verilen kararlar, sorumluluk rejimini doğrudan etkiliyor ve bu bağ genellikle sözleşme imzalandıktan sonra fark ediliyor. İlk müzakereye şu üç başlık netleşmiş olarak gidilmeli. Yetkilendirmenin hangi kurumdan ve hangi şartlarla alınacağı. Sorumluluğun ve sigorta yükünün taraflar arasında nasıl dağıtılacağı. Görev verisi üzerindeki hakların kime ait olacağı ve kimin erişebileceği. Bu üçü çözülmeden yapılan teknik planlama, sonradan yeniden yapılmak zorunda kalıyor. --- # Yazılımınızın Tıbbi Cihaz Olup Olmadığına Pazarlama Metniniz Karar Veriyor Adres: https://kulular.com.tr/yazilar/saglik-hukuku Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-06-05 Özet: Bir sağlık uygulamasının hangi uyum rejimine gireceğini kod değil, üreticinin beyan ettiği kullanım amacı belirliyor. Bu, farkında olmadan yapılan en pahalı hata. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 6 (Özel nitelikli kişisel verilerin işlenme şartları) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - 3359 sayılı Sağlık Hizmetleri Temel Kanunu https://www.mevzuat.gov.tr/mevzuatmetin/1.5.3359.pdf - 1219 sayılı Tababet ve Şuabatı San'atlarının Tarzı İcrasına Dair Kanun https://www.mevzuat.gov.tr/mevzuatmetin/1.3.1219.pdf - Kişisel Sağlık Verileri Hakkında Yönetmelik - Türkiye İlaç ve Tıbbi Cihaz Kurumu (Tıbbi cihaz mevzuatı ve kılavuzlar) https://www.titck.gov.tr/ İki uygulama düşünün. İkisi de kullanıcının girdiği belirtileri alıyor, bir algoritma çalıştırıyor ve bir liste döndürüyor. Kod neredeyse aynı. Biri tıbbi cihaz mevzuatına tabi, diğeri değil. Farkı yaratan şey, uygulama mağazasındaki açıklama metni. Birincisi "belirtilerinize göre olası durumlar hakkında bilgi verir" diyor. İkincisi "belirtilerinizi değerlendirir ve olası tanıyı gösterir" diyor. İkinci cümle, ürünü tanı amacıyla sunulmuş hâle getiriyor ve bununla birlikte risk sınıflandırması, uygunluk değerlendirmesi, teknik dosya, klinik değerlendirme ve piyasaya arz sonrası izleme yükümlülükleri devreye giriyor. Bu, sağlık teknolojisi projelerinde gördüğüm en pahalı ve en kolay önlenebilir hata. Ürün tanımını pazarlama ekibi yazıyor, kimse hukuki sonucunu düşünmüyor ve ürün, üstlenilmediği bir uyum rejiminin içine giriyor. ## Kullanım amacı bir hukuki metin Buradan çıkan pratik kural şu. Ürün tanımı, gizlilik politikası kadar dikkatle yazılmalı ve yayımlanmadan önce hukuki incelemeden geçmeli. İnceleme yalnızca mağaza açıklamasıyla sınırlı kalmamalı. Web sitesindeki başlık, tanıtım videosundaki cümle, satış sunumundaki iddia ve destek dokümanındaki ifade de aynı sonucu doğurabilir. Bir yerde "tanı koyar" dediyseniz, başka yerde "bilgi amaçlıdır" yazmanız bu beyanı geri almaz. Kararı baştan vermek gerekiyor. Ürün tıbbi cihaz olacaksa, o rejimin gerektirdiği süreç en baştan kurulur ve bu bir maliyet kalemi olarak plana girer. Olmayacaksa, her metinde bu sınırın korunması ürün geliştirme kuralı hâline getirilir. ## Sağlık verisinde erişim mimarisi 6698 sayılı Kanun'un 6. maddesi sağlık verisini özel nitelikli kişisel veri olarak sayıyor ve işlenmesini daha dar şartlara bağlıyor. Bu nitelendirmenin teknik karşılığı çoğu projede eksik kalıyor. Sık gördüğüm tablo şu. Uygulama çalışıyor, veriler tutuluyor, ama sistemde herkes her şeyi görebiliyor. Geliştirici üretim veritabanına bakabiliyor, destek ekibi hasta kaydını açabiliyor, yönetici raporlarda ham veri görebiliyor. Bu, erişimin sınırlandırılmadığı anlamına geliyor ve bir denetimde savunulması güç. Doğru kurgu rol tabanlı erişimle başlıyor ama orada bitmiyor. Her erişimin kaydedilmesi, kaydın kim tarafından hangi amaçla yapıldığını göstermesi ve olağandışı erişimin fark edilebilmesi gerekiyor. Bir hasta kaydını gece yarısı açan bir kullanıcı varsa, bunun sistemde görünür olması lazım. Test ortamı ayrı bir başlık. Gerçek hasta verisiyle test yapmak, sağlık teknolojisinde en yaygın ve en riskli alışkanlık. Maskelenmiş veya sentetik veriyle çalışmak bu riski büyük ölçüde ortadan kaldırıyor ve teknik olarak zor bir iş değil. ## Klinik karar destek ve sorumluluk Yapay zekâ destekli karar destek sistemleri, sorumluluğun kimde olduğu sorusunu doğuruyor. Uygulamada güvenli kurgu, sistemin öneri üretmesi ve nihai kararın yetkili sağlık profesyoneline bırakılması. Bu kurgunun kâğıt üzerinde kalmaması için üç kaydın birlikte tutulması gerekiyor. Sistemin ürettiği öneri, önerinin dayandığı girdiler ve sağlık profesyonelinin verdiği son karar. Üçü ayrı ayrı tutulursa sonradan eşleştirilemez, hiç tutulmazsa sorumluluğun nerede olduğu gösterilemez. Buna bir ölçüt eklemekte fayda var. Sağlık profesyonelinin sistemin önerisini reddetme oranı izlenmeli. Bu oran sıfıra yaklaşıyorsa, insan denetimi biçimsel hâle gelmiş demektir ve o noktada sistem fiilen kararı kendisi veriyor olur. Bu tespit, sorumluluk tartışmasında belirleyici olabilir. ## Uzaktan sağlık hizmeti Uzaktan sağlık hizmetleri Sağlık Bakanlığı düzenlemeleri çerçevesinde yürütülüyor. Hangi hizmetlerin uzaktan sunulabileceği, kayıt yükümlülükleri ve hizmetin sınırları ikincil mevzuatta belirleniyor. Bu düzenlemeler zaman içinde değişebildiği için, ürün tasarlanırken güncel metne bakılması gerekiyor. Değişmeyen ilke şu. Yüz yüze muayene gerektiren durumlar uzaktan karşılanamaz. Bir uzaktan sağlık uygulaması, bu sınırı aşan bir talebi tanıyıp yönlendirebilmeli. Sistemin "bu durum için lütfen hekime başvurun" diyebilmesi, bir kullanılabilirlik özelliği değil hukuki bir gereklilik. ## Projeye başlarken Sağlık teknolojisi projelerinde ilk toplantıda cevaplanması gereken soru ürünün ne yapacağı değil, ne olduğunu beyan edeceği. Bu cevap verilmeden yazılan her satır kod, yanlış rejime göre yazılmış olabilir. İkinci soru veri modeline ait. Hangi veri gerçekten gerekli, kim görebilecek, erişim nerede kaydedilecek ve amaç sona erdiğinde ne olacak. Bu dört sorunun cevabı tabloların tasarımını doğrudan belirliyor ve sonradan değiştirilmesi, geçmiş hasta verisini taşımayı gerektirdiği için hem teknik hem hukuki bir sorun doğuruyor. --- # Uzaktan Sınavda Kamera Zorunluluğu Ölçülülük Testini Geçiyor mu Adres: https://kulular.com.tr/yazilar/egitim-hukuku Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-05-23 Özet: Sınav bütünlüğü meşru bir amaç. Bu, öğrencinin evini iki saat boyunca kaydetmeyi kendiliğinden meşru kılmıyor. Aradaki fark ölçülülükte. Kaynaklar: - Türkiye Cumhuriyeti Anayasası, m. 42 (Eğitim ve öğrenim hakkı ve ödevi) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.2709.pdf - 6698 sayılı Kişisel Verilerin Korunması Kanunu, m. 4 ve 5 (Genel ilkeler ve işleme şartları) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - 2547 sayılı Yükseköğretim Kanunu https://www.mevzuat.gov.tr/mevzuatmetin/1.5.2547.pdf - 1739 sayılı Millî Eğitim Temel Kanunu https://www.mevzuat.gov.tr/mevzuatmetin/1.5.1739.pdf Bir öğrenci uzaktan sınavda kamera açmayı reddediyor ve gerekçe olarak evini kaydettirmek istemediğini söylüyor. Kurum, sınav bütünlüğünün sağlanması gerektiğini belirtiyor. Bu noktada iki meşru menfaat karşı karşıya geliyor ve mesele, hangisinin haklı olduğu değil, kurumun seçtiği yöntemin gerçekten gerekli olup olmadığı. Bu soru eğitim teknolojisi projelerinde sürekli karşıma çıkıyor ve genellikle yanlış çerçevede tartışılıyor. Tartışma "kamera açılsın mı açılmasın mı" ikilemi hâline geliyor, oysa hukuken sorulması gereken soru daha dar. Aynı amaca daha az veri işleyerek ulaşılabiliyor mu? ## Ölçülülük neyi soruyor 6698 sayılı Kanun'un 4. maddesi, kişisel verinin işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını arıyor. Bu ilke soyut bir temenni değil, somut bir eleme aracı. Sınav bütünlüğü meşru bir amaç, bunda tartışma yok. Fakat bu amaç, aday hakkında toplanabilecek her veriyi meşru kılmıyor. Sürekli video kaydı, ekran görüntüsü toplama, klavye ve fare hareketlerinin izlenmesi, cihaz üzerinde geniş yetki isteyen bir istemci kurulması. Bunların her biri ayrı ayrı değerlendirilmeli ve her biri için şu sorulmalı. Bu olmadan sınav bütünlüğü sağlanamaz mı? Çoğu durumda sağlanabiliyor. Soru havuzunun rastgeleleştirilmesi, süre sınırı, soru sırasının karıştırılması, açık uçlu soru ağırlığının artırılması ve sonradan yapılan istatistiksel anomali analizi, kayıt almadan da ciddi bir bütünlük düzeyi sağlıyor. Bu araçlar denenmeden doğrudan kamera kaydına geçilmesi, ölçülülük bakımından savunması zor bir tercih. ## Rıza burada neden işe yaramıyor Kurumların ilk refleksi öğrenciden rıza almak oluyor. Sınav başlamadan bir onay kutusu çıkıyor ve öğrenci onaylamadan sınava giremiyor. Bu kurgunun sorunu şu. Rızanın geçerli olabilmesi için özgür iradeyle verilmiş olması gerekiyor. Onaylamadığında sınava giremeyen bir öğrencinin verdiği onayın özgür iradeye dayandığını savunmak güç. Üstelik karşı tarafta notu veren, devamsızlığı işleyen ve mezuniyet kararını etkileyen kurum var. Bu güç dengesizliği rızayı baştan sakatlıyor. Buradan çıkan pratik sonuç şu. Öğrenci verisinde rızaya dayanmak, kuruma güvenlik hissi veriyor ama hukuki koruma sağlamıyor. Kurumun yapması gereken, işlemenin başka bir hukuki sebebe dayanıp dayanmadığını değerlendirmek ve dayanmıyorsa o işlemeden vazgeçmek. ## Çocuk söz konusu olduğunda Zorunlu eğitim çağındaki öğrenciler bakımından tablo daha da hassas. Burada rıza ehliyeti, velinin rolü ve çocuğun üstün yararı ayrı ayrı değerlendirilmesi gereken başlıklar. Bir eğitim platformu tasarlanırken kullanıcının yaşına göre farklı akış kurulması gerekiyor. Aynı arayüzü hem on yaşındaki bir öğrenciye hem yirmi beş yaşındaki bir yüksek lisans öğrencisine sunmak, sadece kullanılabilirlik açısından değil hukuken de sorunlu. Veri modelinde yaş grubunu taşıyan bir alan ve o alana bağlı farklı işleme kuralları, bu ayrımın teknik karşılığı. ## Öğrenme kaydı neyi kanıtlıyor Eğitim teknolojisinin daha az konuşulan tarafı, ürettiği kaydın sonradan ne işe yaradığı. Bir öğrenci notuna itiraz ettiğinde kurumun elinde ne var? Bilet kapatır gibi "sınav tamamlandı" kaydı mı, yoksa hangi soruya ne cevap verildiğini, hangi ölçüte göre puanlandığını ve kimin değerlendirdiğini gösteren bir zincir mi? İkincisi varsa itiraz on dakikada sonuçlanır. Yoksa itiraz, kurumun kendi kaydına güvenmesini isteyen bir savunmaya dönüşür ve bu savunma zayıftır. Bu yüzden ölçme sistemi tasarlanırken şu sıra izlenmeli. Önce öğrenme çıktısı yazılır. Sonra geçme ölçütü o çıktıya bağlanır. Soru ölçüte göre üretilir. Değerlendirme kaydı tutulur. İtiraz yolu ve inceleme usulü önceden tanımlanır. Bu zincir kurulduğunda başarı belgesi, arkasında gösterilebilir bir dayanağa sahip olur. Kurulmadığında belge, kurumun iyi niyetine dayanan bir beyandan ibaret kalır. ## Kurumlara önerim Gözetim yazılımı satın almadan önce, bütünlük sorununun ne kadarının sınav tasarımıyla çözülebileceğini ölçün. Çoğu kurumda bu ölçüm hiç yapılmıyor ve doğrudan en müdahaleci çözüme geçiliyor. Ölçüm yapıldıktan sonra hâlâ gözetime ihtiyaç varsa, toplanan her veri kalemi için ayrı gerekçe yazın. "Sistem bunu topluyor" bir gerekçe değil. Gerekçesi yazılamayan kalem, sistemden çıkarılmalı. Bu, tedarikçiyle yapılacak sözleşmenin de konusu olmalı, çünkü çoğu hazır ürün ihtiyacınızdan fazlasını topluyor ve varsayılan ayarlarla geliyor. --- # Bilişim Hukuku Tek Bir Kanunda Değil, Bu Yüzden Zor Adres: https://kulular.com.tr/yazilar/bilisim-hukuku Yazar: Öğr. Gör. Tarık İsmet Alkan Yayımlayan: Kulular Teknoloji Yayın: 2026-05-19 Özet: Türkiye'de bilişim hukuku diye tek bir metin yok. Alan altı ayrı kanunun kesişiminde uygulanıyor ve aynı olay üç farklı mercide sonuç doğurabiliyor. Kaynaklar: - 6698 sayılı Kişisel Verilerin Korunması Kanunu (Resmî Gazete, 7 Nisan 2016, sayı 29677) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf - 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi Hakkında Kanun (Resmî Gazete, 23 Mayıs 2007) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.5651.pdf - 5237 sayılı Türk Ceza Kanunu, m. 135-140 ve m. 243-246 https://www.mevzuat.gov.tr/mevzuatmetin/1.5.5237.pdf - 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6563.pdf - 5070 sayılı Elektronik İmza Kanunu https://www.mevzuat.gov.tr/mevzuatmetin/1.5.5070.pdf "Bilişim hukuku ne diyor bu konuda" sorusunun cevabı yoktur, çünkü bilişim hukuku diye tek bir metin yoktur. Bu alanda çalışan herkesin ilk öğrendiği ve müvekkile anlatması en zor olan şey budur. Türkiye'de bilişim faaliyetleri en az altı ayrı kanunun kesişiminde düzenlenir. Bunların hiçbiri diğerini kapsamaz. Hepsi kendi mantığıyla, kendi yaptırım rejimiyle ve kendi denetim merciiyle çalışır. Sonuç şudur. Tek bir metne bakarak yükümlülük listesi çıkarmak mümkün değildir ve aynı olay aynı anda birden fazla rejim altında sonuç doğurabilir. ## Bir veri ihlali üç ayrı yerde karşınıza çıkar Bunu somut bir örnekle görmek gerekiyor. Diyelim ki bir e-ticaret şirketinin müşteri veritabanına yetkisiz erişim sağlandı ve veriler dışarı çıkarıldı. Birinci hat idaridir. 6698 sayılı Kanun'un 12. maddesi veri güvenliğine ilişkin yükümlülükleri düzenler ve aynı maddenin beşinci fıkrası ihlalin Kurul'a bildirilmesini öngörür. Kurul, alınan teknik ve idari tedbirlerin yeterliliğini değerlendirir ve yeterli bulmazsa idari para cezası uygular. İkinci hat cezaidir. Erişimi sağlayan kişinin fiili 5237 sayılı Kanun'un 243. maddesi kapsamında bilişim sistemine girme suçunu, verileri dışarı çıkarması ise 136. madde kapsamında verileri hukuka aykırı olarak verme veya ele geçirme suçunu oluşturabilir. Bu soruşturma, şirketin idari sorumluluğundan bağımsız yürür. Üçüncü hat özel hukuktur. Verisi sızan kişi, uğradığı zararın giderilmesini talep edebilir. Kanun'un 11. maddesinin son bendi bu hakkı açıkça saklı tutar. Üç hat birbirinin alternatifi değildir, aynı anda işler. Kurul'un cezasını ödemiş olmak ceza soruşturmasını sona erdirmez, ceza davasının sonucu tazminat talebini kendiliğinden karara bağlamaz. ## Kanunlar hangi soruya cevap veriyor Alanın dağınıklığını anlamanın en pratik yolu, her metnin hangi soruyu cevapladığını görmektir. 6698 sayılı Kanun "bu veriyi işleyebilir misin" sorusuna cevap verir. İşleme şartları, aydınlatma, güvenlik tedbirleri ve ilgili kişinin hakları buradadır. 5651 sayılı Kanun "bu içerikten kim sorumlu" sorusuna cevap verir. İçerik sağlayıcı, yer sağlayıcı, erişim sağlayıcı ve toplu kullanım sağlayıcı ayrımı ile içeriğin çıkarılması ve erişimin engellenmesi usulleri bu kanunda düzenlenir. Sorumluluk rejimi, kişinin bu dört sıfattan hangisine girdiğine göre tamamen değişir. 5237 sayılı Kanun "bu fiil suç mu" sorusuna cevap verir. 6563 sayılı Kanun "bu ticari iletiyi gönderebilir misin ve hizmet sağlayıcı olarak neyi bildirmek zorundasın" sorusuna cevap verir. 5070 sayılı Kanun "bu elektronik imza ıslak imza yerine geçer mi" sorusuna cevap verir. Bir projede genellikle bu soruların hepsi aynı anda gündeme gelir. Yalnızca birine bakarak verilen karar, diğer dördü bakımından körlük yaratır. ## Dağınık yetki dağınık denetim demek Bu tabloyu daha da karmaşık hâle getiren şey, farklı kanunların farklı kurumlara emanet edilmiş olmasıdır. Kişisel Verileri Koruma Kurumu veri işleme faaliyetlerini denetler. Bilgi Teknolojileri ve İletişim Kurumu elektronik haberleşme alanında yetkilidir ve erişim engelleme kararlarının uygulanmasında görev alır. Ticaret Bakanlığı elektronik ticaret mevzuatının uygulanmasından sorumludur. Bunun pratik sonucu şudur. Tek bir üründe birden fazla denetim merciine karşı sorumlu olabilirsiniz ve bu merciler birbirinin kararıyla bağlı değildir. Birinden gelen olumlu bir görüş, diğerinin farklı sonuca varmasını engellemez. ## Uygulamada nerede hata yapılıyor Bu alanda gördüğüm hataların büyük çoğunluğu bir ortak özelliği paylaşır. Hukuki değerlendirme, teknik kararlar verildikten sonra yapılır. Veri modeli kurulmuş, tablolar açılmış, entegrasyonlar yazılmıştır. Ürün canlıya çıkmak üzereyken hukukçuya "bir bakar mısınız" denir. O aşamada söylenebilecek şeyler sınırlıdır, çünkü söylenen her şey artık geriye dönük düzeltme anlamına gelir ve geriye dönük düzeltme, o güne kadar toplanmış veri bakımından ayrı bir sorun doğurur. Oysa aşağıdaki soruların tamamı veri modeli kurulurken cevaplanabilecek sorulardır. Hangi kişisel veri kategorileri işlenecek. Her kategori hangi hukuki sebebe dayanacak. Saklama süresi ne olacak ve süreyi hangi bileşen uygulayacak. Silme talebi geldiğinde hangi tablolara dokunulacak. Yurt dışına aktarım olacak mı. Beş soru. Hepsi bir toplantıda cevaplanabilir. Cevaplanmadığında ortaya çıkan maliyet, o toplantının maliyetinin kat kat üzerindedir. ## Alanın gerçek zorluğu Bilişim hukukunun zorluğu kuralların karmaşık olması değildir. Kurallar tek tek okunduğunda anlaşılırdır. Zorluk, kuralların hangi anda devreye gireceğini bilmektir. Bir mühendisin verdiği "bu alanı da kaydedelim, lazım olur" kararı, üç ayrı kanun bakımından sonuç doğurur ve o kararı veren kişi çoğu zaman bunu bilmez. Bu bilgi boşluğunu kapatmanın yolu daha kalın bir uyum dosyası hazırlamak değil, kararın verildiği masada hukukçunun bulunmasıdır.