Hukuk teknolojisi yazılımında belge üretiminden fazlası gerekiyor

Hukuk teknolojileri, yazılım geliştirdiğimiz beş alandan biri. Bu alanda en sık gördüğümüz yanılgı, ürünün değerini ürettiği belgede aramak. Asıl değer, kuralın sistemin içinde her seferinde aynı biçimde çalışmasında.

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.