Hukuk & Uyum

Legal tech ajanlarını bir hukuk bürosuna satabilmek için gerekli altyapı ve yönetişim

Hukuk bürosu için legal tech yazılımı ve güvenlik görseli

Hukuk sektörü, özellikle Türkiye'de, legal tech özelinde adaptasyonu ve giriş bariyerleri çok yüksek bir alandır. Yıllardır piyasaya derinlemesine girebilen ürünler; içtihat araması, dilekçe araması gibi müvekkil bilgisi içermeyen araçlar oldu. Nedeni basit: bu araçlar bir hassas veri kasasına dokunmadığı için müvekkil gizliliği açısından ciddi bir risk taşımaz.

Son bir yılda ise tablo değişti. Agentic (ajan tabanlı) hukuk bürosu çözümleri ortaya çıkmaya başladı — ve satışta ciddi itirazlarla karşılaşıyorlar. Çünkü bir ajan artık avukatın çalıştığı e-postadan drive'ına, dava dosyalarından arşivlere kadar her yere erişebiliyor. Bu erişim, müvekkil gizliliği ve buna bağlı riskleri hiç olmadığı kadar yükseğe taşıyor. Üstelik bu ürünlerin çoğu arka planda yurt dışı LLM'lere veri aktardığı için, KVKK kapsamında ayrı bir risk katmanı daha ekliyor.

Bu yazı, bir legal tech ajanını bir hukuk bürosuna satabilmek için kurmanız gereken güvenlik altyapısını ve yönetişim yol haritasını ele alıyor: alıcının gerçek itirazlarından, bu itirazları yapısal olarak yanıtlayan mimariye ve “SOC 2'den önce başlayan” güven sinyallerine kadar.

Ajan, hukuk bürosunda neden farklı bir risk yaratır?

Üretken yapay zeka (chatbot) döneminde risk yüzeyi darlıkla tanımlanabiliyordu: veri ifşası, istem manipülasyonu, güvenilmez çıktı. Sorunların çoğu, modelin ne söylediğiyle ilgiliydi. Ajanlar bu tabloyu kökten değiştirir: planlar, araç çağırır, veritabanına erişir, kod çalıştırır, dosya açar, form doldurur ve işi başka bir ajana devreder. Yani risk, “bilgi problemi” olmaktan çıkıp “eylem problemi”ne dönüşür.

Fark şurada keskinleşir: üretken bir model hatalı bir sözleşme maddesi yazabilir; agentic bir sistem aynı maddeyi yazar ve müvekkile e-postayla gönderir, mahkemeye sunar, hatta karşı tarafa iletir. Bir hukuk bürosunda küçük bir sapma bile büyür: kaçırılan bir süre, loglanmamış bir değişiklik, yanlış adrese giden bir belge zincirleme risk doğurur. Bu yüzden ajanlar, hukuk mesleğinin dört temel direğiyle doğrudan çarpışır: denetlenebilirlik, hesap verebilirlik, gizlilik ve kontrol.

Alıcının gerçek itirazları

Bir büroya satış görüşmesinde masaya oturan CISO ya da uyum sorumlusu, ürünün özelliklerini değil bu soruları sorar. Her biri bir satış engelidir ve her biri yapısal bir cevap bekler.

  • Müvekkil sırrı ve sır saklama yükümlülüğü: Avukatın sır saklama yükümlülüğü (Avukatlık Kanunu m.36) devredilemez. Ajanın müvekkil dosyalarına erişimi, bu yükümlülüğü teknik bir soruya dönüştürür: veri kimin elinde, nereye gidiyor, kim görebiliyor?
  • Yurt dışı veri aktarımı (KVKK m.9): Ajanın kullandığı model nerede çalışıyor? Müvekkil verisinin yurt dışındaki bir LLM'e çıkması, uygun bir aktarım mekanizması (genelde standart sözleşme) olmadan başlı başına bir ihlal riskidir.
  • Hafıza ve dosya karışması: Uzun süreli hafıza ajanı daha yararlı yapar; ama bir müvekkilin dosyasından öğrendiğini başka bir müvekkilin işinde kullanması, gizliliği, vekâlet sırrını ve etik duvarları (ethical walls) ihlal eder. Bölmelenme üzerine kurulu bir meslekte hafızanın kendisi bir risk vektörüdür.
  • Veri ile talimatı ayıramama: Avukat, karşı taraftan gelen bir e-postanın veri olduğunu, bir talimat olmadığını bilir. Ajan her zaman bilmez. Bir dilekçeye, PDF'e ya da e-postaya gizlenmiş bir satır, ajana “bunu yap” komutu gibi gelebilir — dava dosyaları ve keşif belgeleri hep dışarıdan geldiği için bu yeni ve güçlü bir saldırı yüzeyidir.
  • Kimlik ve yetki — “dijital içeriden” riski: Ajan yararlı olsun diye ona geniş yetki vermek caziptir: tüm dosyalar, takvim, faturalama, bulut sürücü. O an ajan bir dijital içeridene dönüşür; yanlış hizalandığında ya da manipüle edildiğinde yetkili erişimle zarar verir. Tehdit her zaman dışarıdaki hacker değil; “teknik olarak izinli” ama hiç istenmeyen eylemdir.
  • Katlanan ve zincirleme hatalar: Bir chatbot'un halüsinasyonunu, dilekçedeki atıfı elle kontrol ederek yakalayabilirsiniz. Ajanda erken bir adımdaki hata, sonraki her adıma taşınır; üstelik sistem kendi içinde tutarlı göründüğü için sonucu sorgulamak zorlaşır. Ara kontrol noktaları olmadan hatanın nerede başladığını bulmak güçtür.
  • Gölge YZ (Shadow AI): Avukatlar, onaylı sistem yavaş ya da hantal geldiğinde kendi araçlarını gizlice kullanır: bir ortağın evde denediği tarayıcı-tabanlı ajan, bir stajyerin müvekkil belgesini genel bir chatbot'a yapıştırması. Gölge YZ; loglama, gizlilik kontrolleri, tedarikçi denetimi ve yönetişimin tamamen dışında kaldığı için sadece bir BT sorunu değil, bir yetkinlik, gizlilik ve gözetim sorunudur.

Satabilmek için kurmanız gereken altyapı

Bu itirazların hiçbiri bir slaytla kapanmaz; her biri mimariyle yanıtlanır. Bir büronun “evet” demesi için ürününüzün aşağıdaki yapısal cevapları taşıması gerekir.

1. Konuşlandırma: veri binadan çıkmasın

  • Private AI (kurum içi / air-gapped): Modelin firma sunucularında, dış dünyadan yalıtılmış çalıştığı, verinin tesisten hiç çıkmadığı kurulum. En yüksek güven, en yüksek teknik yük.
  • Kapalı sistem (firewall içi + RAG): Verinin genel modellere ifşa edilmeden, kurumun güvenlik duvarı içinde işlendiği ara adım. Tedarikçiyi dikkatle denetleyin.
  • VPC (özel bulut) kurulumu: Ajanın kurumun özel bulut ağında, genel internetten yalıtılmış barındırıldığı teknik uygulama.

2. En az yetki (least privilege)

Hiçbir ajan, yalnızca “kolay olduğu için” her şeyi yapabilme kapasitesine sahip olmamalı. Belge özetleyen bir ajanın e-posta gönderme, kayıt değiştirme ya da tüm dosyalara erişme yetkisi olmamalı. Salt-okunur gerekiyorsa yazma verme; bir klasör yetiyorsa tüm sürücüyü açma. Avukatlar bu ilkeyi zaten insan çalışanlar için uygular — aynı kural dijital çalışana da geçmeli.

3. Sıfır güven (Zero Trust) ve döngüde insan

Her kullanıcı, ajan ve uygulama kimlik doğrulamadan ve yetkilendirilmeden iş göremez; bu, kontrolden çıkmış ajanı ya da kötü niyetli kullanıcıyı durdurur. Bunun üzerine anlamlı bir uzman gözetimi gelir: dosya/dilekçe sunma, süre değişikliği, dış iletişim, uzlaşma şartları, ayrıcalıklı (privileged) materyal ya da geri alınamaz sistem değişikliği gibi yüksek etkili eylemler otonom bırakılmamalı. İnsan onayı gerçek bir kontrol noktası olmalı — bir “tören tıklaması” değil. Soru “sistem bunu yapabilir mi?” değil, “meslek sorumluluğu bunu insan onayı olmadan yapmasına izin verir mi?”dir.

4. Gözlemlenebilirlik ve etik duvarlar

Göremediğiniz bir ajanı yetkinlikle denetleyemezsiniz. Model seçiminden dağıtıma, izinlerden bağlayıcılara, çalışma-zamanı eylemlerinden loglamaya kadar tüm akışta görünürlük gerekir (kimileri buna “AI Security Posture Management” diyor). Ajanın her eylemi — hangi dosyaya dokundu, kimin adına, hangi yetkiyle — loglanmalı; bu loglar da kişisel veri içerdiği için maskelenmeli ve erişimi sınırlanmalı. Müvekkil bazında yalıtım (matter isolation) ve etik duvarlar, bir dosyanın diğerine sızmasını teknik olarak imkânsız kılmalı.

Yönetişim ve güven sinyalleri: SOC 2'den önce başlar

Büyük bürolar, küçük bir ekibin bir gün ortadan kaybolmasından, bir şeyi bozmasından, veriyi yanlış yönetmesinden ya da ölçeklenememesinden endişe eder. Birçok kurucu bu tuhaf aşamaya gelir: ürün gerçektir, müşteri ilgilidir, ama şirket alıcı için hâlâ “fazla erken” görünür. Alıcının aradığı şey, güvenlik ve mahremiyetin tasarımın en başından düşünüldüğüne dair kanıttır.

Birçok girişim, konuşmanın SOC 2 ile başladığını sanır. Oysa güven çok daha erken başlar: yapı, şeffaflık ve olgunluk sinyalleriyle. Gerçekçi bir yol haritası şöyledir:

  • Resmî mimariyi ve veri akışlarını gösterin (diyagramlarla).
  • Politika ve yönetişim dokümantasyonunu sunun.
  • Güvenlik kontrollerinizi ve güvenli yazılım geliştirme (SDLC) pratiklerinizi belgeleyin.
  • 6–12 ay içinde SOC 2 Type I için sözleşmesel bir taahhüt verin.
  • Programı resmî denetimlere ve sürekli uyuma doğru olgunlaştırın (ISO 27001/27701 ve YZ yönetişimi için ISO 42001).

Bu sinyaller aynı zamanda büronun KVKK m.12 (uygun güvenlik düzeyi) yükümlülüğünü karşılamasını mümkün kılar — yani sizin olgunluğunuz, alıcının hukuki uyumunun da parçası olur.

KVKK boyutu: bu bir “dış hizmet alımı”dır

Hukuki çerçeve nettir: müvekkil verisi üzerinde veri sorumlusu hukuk bürosudur; legal tech firması ise onun adına işleyen veri işleyendir. Bu, üç şeyi zorunlu kılar: imzalı bir veri işleme sözleşmesi (DPA — “kullanım koşulları” yetmez), yurt dışı aktarım için m.9 mekanizması ve müvekkile/çalışana yönelik güncel aydınlatma. Ajan otomatik kararlar veriyorsa ilgili kişinin KVKK m.11 kapsamındaki haklarına ve bir insan incelemesine erişimi de teknik olarak var olmalı. Kısacası bir ajanı bir büroya satmak, tıpkı bankacılıktaki gibi titiz bir dış hizmet alımı sürecidir.

Unutmayın
Bir legal tech ajanını satış görüşmesinde kazandıran şey özellik listesi değildir; güvenlik ve mahremiyetin ilk günden mimariye gömüldüğünü kanıtlayabilmektir. Türkiye'de bu kapının adı müvekkil gizliliğidir: kurum içi/VPC konuşlandırma, en az yetki, döngüde insan, loglama, etik duvarlar ve imzalı bir DPA — bunlar giriş bileti, seçenek değil.

Aynı çerçeveyi bir hukuk bürosu, tedarikçisini tartmak için de kullanabilir. Veri yeri, DPA, sertifikalar, durdurma ve olay bildirimi gibi başlıkları tek sayfaya dökmek için tedarikçi değerlendirme aracını deneyin.

Tedarikçiyi (ya da kendinizi) bu kriterlerle tartın

Bir ajanı satın almadan — ya da satmaya çalışmadan — önce doğru soruları sorun. Ücretsiz tedarikçi değerlendirme aracıyla tek sayfalık due diligence belgenizi çıkarın.

Aracı aç →