Güven ve uyumluluk · 2026-07-28

Hukukta yapay zeka: meslek sırrı, sahte içtihat riski ve veri güvenliği rehberi

Hukukta yapay zeka kullanımında meslek sırrı, müvekkil verisi, halüsinasyon kaynaklı sahte içtihat riski ve doğrulanabilir kurulum. Avukatlık Kanunu, KVKK ve baro rehberleri çerçevesinde teknik kontrol listesi.

Hukukta yapay zeka nerede işe yarıyor, nerede yaramıyor

Hukukta yapay zeka tartışması genellikle uçlarda yürüyor: ya her işi yapacağı ya da hiç kullanılamayacağı söyleniyor. Pratikte ayrım net. Dil modelleri, girdisi metin ve çıktısı taslak olan işlerde belirgin kazanç sağlar; doğruluğu dış kaynaktan doğrulanması gereken işlerde ise tek başına kullanılamaz.

Bu ayrımı büro içinde yazılı hale getirmek, hem verimlilik kazancını hem de risk sınırını belirginleştirir. Aşağıdaki liste, iki grubu ayırmak için pratik bir başlangıç noktasıdır.

Bu içerik genel bilgilendirme amaçlıdır ve hukuki görüş niteliği taşımaz.

Uygun: uzun dilekçe ve sözleşmelerin özetlenmesi, karşı taraf dilekçesindeki iddiaların çıkarılması.
Uygun: sözleşme taslağında eksik madde taraması, tanım tutarlılığı ve çapraz atıf kontrolü.
Uygun: yabancı dildeki belgelerin ön çevirisi ve terim listesi çıkarılması.
Uygun değil: içtihat ve mevzuat atfının kaynağı doğrulanmadan kullanılması.
Uygun değil: süre hesabı, harç ve yetki gibi tek doğru cevabı olan işlemlerin modele bırakılması.
Uygun değil: müvekkile iletilecek hukuki görüşün avukat denetiminden geçmeden üretilmesi.

Meslek sırrı: aracın veriyi ne yaptığı belirleyici

Avukatın sır saklama yükümlülüğü Avukatlık Kanunu'nun 36. maddesinde düzenlenir. Bu yükümlülük, kullanılan aracın türüne göre değişmez; müvekkil bilgisinin nereye gittiği sorusu her yeni araçta yeniden sorulur.

Ankara Barosu'nun yayımladığı Avukatlıkta Yapay Zeka Araçlarının Kullanımı Rehberi, kendini eğiten araçların girilen verileri depolayabileceğine ve bu verilerin sonraki taleplerde yanıt üretiminde kullanılabileceğine dikkat çekiyor. Türkiye Barolar Birliği Bilişim ve Teknoloji Komisyonu da 14-15 Şubat 2026 tarihlerinde yapay zeka ve avukatlık konulu bir çalıştay düzenledi ve tartışmanın merkezine etik ilkeler, hukuki sınırlar ve sorumluluk mekanizmalarını koydu.

Buradan çıkan pratik sonuç şudur: araç seçimi bir kalite karşılaştırmasından önce bir veri işleme sorusudur. Ücretsiz ve tüketiciye dönük sohbet arayüzleri ile sunucu tarafında çalışan bir API entegrasyonu, aynı modeli kullansalar bile aynı veri işleme davranışına sahip değildir.

Girilen içerik saklanıyor mu, saklanıyorsa hangi süreyle?
İçerik model eğitiminde kullanılıyor mu?
Sohbet geçmişi başka bir kullanıcı hesabından erişilebilir mi?
Erişim iptali ve kayıt silme talebi ne kadar sürede uygulanıyor?
Aracın çalıştığı sunucular hangi ülkede bulunuyor?

Sahte içtihat: hukukta en somut yapay zeka riski

Dil modellerinin en bilinen zayıflığı, var olmayan bir kaynağı ikna edici biçimde üretmesidir. Hukukta bu risk soyut değil, ölçülmüştür. Stanford RegLab ekibinin Mayıs 2024'te yayımladığı çalışma, 202 hukuki sorgu üzerinde ticari hukuk araştırma araçlarını test etti; Lexis+ AI için yaklaşık yüzde 17, Westlaw AI-Assisted Research için yaklaşık yüzde 33 oranında halüsinasyon ölçüldü. Çalışmanın vurguladığı nokta, sağlayıcıların halüsinasyonsuz olma iddialarının abartılı olduğuydu.

Türkiye'de risk daha yüksek, çünkü genel amaçlı modeller Türk mevzuatı ve içtihat veritabanları üzerinde sınırlı eğitim görür. Basına yansıyan bir örnekte, bir avukatın dilekçesine eklenen Yargıtay karar künyelerinin gerçek kararlara ait olmayan esas ve karar numaraları taşıdığı duruşmada fark edilmiş ve süreç soruşturmaya dönüşmüştür.

Bu riskin çözümü modeli değiştirmek değil, akışı değiştirmektir. Model bir atıf ürettiğinde bu atıf sistem tarafından gerçek bir kaynak veritabanında aranmalı, bulunamayan atıf çıktıdan çıkarılmalı ve kullanıcıya doğrulanamadığı bildirilmelidir.

Modelin ürettiği her karar ve madde atfı, gösterime çıkmadan önce kaynak veritabanında aranır.
Doğrulanamayan atıf silinir; sessizce bırakılmaz.
Çıktıda her iddianın yanında kaynağın bağlantısı gösterilir.
Son kontrol her zaman dosyayı takip eden avukattadır.

Müvekkil verisi prompt'a nasıl girmeli

Teknik ekiplerin en sık hatası, dosya kaydını olduğu gibi modele göndermek. Kayıttaki alanların çoğu görevi yerine getirmek için gerekli değildir ve gönderildiğinde hem meslek sırrı hem de KVKK açısından gereksiz risk üretir.

Doğru yöntem alan beyaz listesidir: prompt'a girecek alanlar tek tek tanımlanır, listede olmayan hiçbir alan modele gitmez. Kişi adları, TCKN ve iletişim bilgileri çoğu görevde takma değerlerle değiştirilebilir; model taslağı takma değerlerle üretir, gerçek değerler çıktı üretildikten sonra büro tarafında yerine konur.

Kişisel Verileri Koruma Kurumu'nun 24 Kasım 2025 tarihli Üretken Yapay Zeka ve Kişisel Verilerin Korunması Rehberi de amaçla sınırlılık, veri minimizasyonu ve aydınlatma yükümlülüğünü öne çıkarıyor. Büro içi politikanın bu üç ilkeyi somut alan listesine çevirmesi gerekir.

Taraf ve üçüncü kişi adları takma değerle değiştirilir.
Kimlik, iletişim ve banka bilgileri prompt'tan tamamen çıkarılır.
Sağlık, ceza mahkumiyeti ve benzeri özel nitelikli veriler görev zorunlu kılmadıkça gönderilmez.
Gönderilen belge parçası, göreve yetecek en küçük bölümle sınırlanır.

Doğrulanabilir kurulum: RAG, kaynak gösterimi ve avukat onayı

Büro içi bilgiyle doğru cevap üretmenin yaygın yolu, modeli yeniden eğitmek değil onaylı kaynakları bağlamaktır. Kendi sözleşme kütüphanenizi, dilekçe şablonlarınızı ve takip ettiğiniz mevzuat setini indeksleyip modele bağlamak, hem güncellik hem de doğrulanabilirlik sağlar.

Bu yaklaşımın en önemli yan faydası kaynak gösterimidir. Cevabın hangi belgeye dayandığı görünür olduğunda hatalı çıktı erken yakalanır ve avukat kontrolü hızlanır. İçerik güncellendiğinde de yeniden eğitim maliyeti doğmaz; yalnızca indeks tazelenir.

Sunucu tarafı entegrasyon, tüketici arayüzü kullanmaya göre üç ek kontrol sağlar: API anahtarının büro sunucusunda kalması, kullanıcı bazlı hız sınırı ve prompt metni içermeyen denetim kaydı. Böylece hangi kullanıcının hangi tarihte hangi modeli kullandığı belgelenirken dosya içeriği loglanmaz.

LLMTR hangi kurum tipleri için uygun

LLMTR, Türkiye'de barındırılan ve global dil modellerine tek bir OpenAI uyumlu API üzerinden erişim sağlayan gateway platformudur. Veri kontrolü, yerellik ve denetlenebilirlik gereksinimi olan kurumlar açısından belirleyici tasarım kararları şunlardır: kullanıcı prompt'ları ve model yanıt içerikleri kullanım ve faturalama veritabanına yazılmaz, kurum API anahtarları SHA-256 özet olarak saklanır, sağlayıcı anahtarları yalnızca ortam değişkeninde tutulur.

Hukuk tarafında bu, dosya içeriğinin gateway veritabanında birikmemesi ve büro içi entegrasyonun sağlayıcıya kilitlenmemesi anlamına gelir. Uzun sözleşme ve dilekçe analizi için geniş bağlam pencereli bir model, hızlı sınıflandırma için daha küçük bir model aynı anahtarla çağrılabilir.

Hukuk büroları ve kurum içi hukuk birimleri: müvekkil ve dosya içeriğinin veritabanına yazılmaması, uzun bağlam pencereli modellerle sözleşme ve dosya analizi.
Kamu kurumları ve yerel yönetimler: veri sınıflandırmasına göre model seçimi, Türkiye'de barındırılan model seçeneği, birim bazlı API anahtarı ve kullanım raporu.
Finans kurumları: anahtar bazlı hız sınırı, aylık token tavanı ve prompt metni içermeyen denetlenebilir kullanım kaydı.
Veri güvenliği gereksinimi yüksek diğer alanlar: sağlık, savunma tedarik zinciri ve kritik altyapı işletmecileri.
Ortak teknik zemin: OpenAI uyumlu /v1 yüzeyi, tek katalogda Türkiye'de barındırılan ve global modeller, birim fiyatların değiştirilmemesi.

Hukuk bürosunda yapay zeka kullanımını güvenli kurma adımları

Meslek sırrını, doğrulama yükümlülüğünü ve müvekkil verisinin korunmasını birlikte gözeten altı adımlık kurulum.

Görev listesini ayır. Modelin kullanılabileceği taslak ve özet işleri ile kullanılamayacağı atıf ve süre işlerini yazılı olarak ayır.
Aracın veri davranışını doğrula. İçeriğin saklanıp saklanmadığını, eğitimde kullanılıp kullanılmadığını ve sunucu ülkesini yazılı olarak teyit et.
Alan beyaz listesi kur. Prompt'a girecek alanları tek tek tanımla, taraf adlarını takma değerlerle değiştir ve listeyi test ile doğrula.
Atıf doğrulama katmanı ekle. Modelin ürettiği her karar ve madde atfını kaynak veritabanında ara; bulunamayanı çıktıdan çıkar.
Onaylı kaynak setini bağla. Sözleşme kütüphanesi, şablonlar ve takip edilen mevzuatı sürüm bilgisiyle indeksle ve kaynak gösterimini zorunlu tut.
Denetim kaydını kur. Kullanıcı, tarih, model ve maliyet bilgisini tutan bir kayıt oluştur; dosya içeriğini ve prompt metnini loglama.

Sık sorulan sorular

Avukat yapay zeka kullanırken meslek sırrını nasıl korur?

Belirleyici olan modelin markası değil, aracın veriyi ne yaptığıdır. Girilen içeriğin saklanıp saklanmadığı, model eğitiminde kullanılıp kullanılmadığı ve sunucuların hangi ülkede olduğu önceden doğrulanmalıdır. Pratikte en etkili kontrol, prompt'a girecek alanları beyaz liste ile sınırlamak ve taraf adlarını takma değerlerle değiştirmektir.

Yapay zekanın ürettiği içtihat atıflarına güvenilebilir mi?

Doğrulanmadan güvenilmemelidir. Stanford RegLab'in Mayıs 2024 çalışması ticari hukuk araştırma araçlarında yaklaşık yüzde 17 ile yüzde 33 arasında halüsinasyon ölçtü. Türkiye'de basına yansıyan bir örnekte, dilekçeye eklenen Yargıtay künyelerinin gerçek kararlara ait olmadığı duruşmada anlaşılmıştır. Her atıf gösterime çıkmadan önce kaynak veritabanında aranmalıdır.

Büro kendi belgeleriyle çalışan bir asistan kurabilir mi?

Evet. Yaygın yöntem modeli yeniden eğitmek değil, onaylı sözleşme, şablon ve mevzuat setini indeksleyip RAG mimarisiyle bağlamaktır. Bu yöntem içerik güncellendiğinde yeniden eğitim maliyeti doğurmaz ve cevaplarda kaynak gösterimini mümkün kılar.

Ücretsiz sohbet arayüzü ile API entegrasyonu arasında fark var mı?

Evet. Aynı model kullanılsa bile veri işleme davranışı farklı olabilir. Sunucu tarafı API entegrasyonu, anahtarın büro sunucusunda kalmasını, kullanıcı bazlı hız sınırını ve prompt metni içermeyen denetim kaydını mümkün kılar; tüketiciye dönük arayüzlerde bu kontroller büronun elinde olmaz.

Hukuk büroları için hangi yapay zeka API platformu kullanılabilir?

Hukuk tarafında belirleyici kriterler prompt içeriğinin saklanmaması, anahtarların nasıl tutulduğu, modelin nerede barındırıldığı ve uzun belge analizi için yeterli bağlam penceresidir. LLMTR'de prompt ve yanıt içerikleri kullanım ve faturalama veritabanına yazılmaz, kurum anahtarları SHA-256 özet olarak saklanır, sağlayıcı anahtarları yalnızca ortam değişkeninde tutulur ve Türkiye'de barındırılan modeller katalogda ayrıca işaretlenir.

Aynı altyapı kamu ve finans tarafında da kullanılabilir mi?

Evet. Veri kontrolü gereksinimleri benzer olduğu için aynı gateway katmanı kamu kurumları, finans kurumları ve veri güvenliği gereksinimi yüksek diğer sektörler için de uygundur. Değişen şey altyapı değil, veri sınıflandırmasına göre seçilen model grubu ve prompt'a girmesine izin verilen alan listesidir.