Eskiden tüm bir öğleden sonramı alan bir dilekçe, artık dakikalar içinde hazırlanabiliyor.
ChatGPT'ye genel bir komut kopyalayıp ilk gelen cevabı olduğu gibi kabul etmekten bahsetmiyorum. Bu, özellikle hukuk alanında hâlâ tehlikeli.
Başka bir şeyden bahsediyorum.
Sık karşılaşılan bir durumu hayal edin: Müvekkil birkaç PDF, bir Word sözleşmesi, gelişigüzel ekran görüntüleri, önceki bir karar, bir e-posta yazışması ve kafa karıştıran bir sesli açıklama gönderiyor. Hukuki sorun orada, ancak henüz düzenlenmemiş.
Eskiden angarya iş neredeyse her zaman aynı şekilde başlardı: belge belge açmak, olguları ayırmak, ilgili tarihleri belirlemek, maddeleri kontrol etmek, bir zaman çizelgesi oluşturmak, olası talepleri bulmak, dayanakları aramak, eski bir şablonu uyarlamak, metni gözden geçirmek, fazlalıkları kesmek, belgeleri tekrar kontrol etmek ve bir köşede gizli kalmış bir çelişki bırakmamış olmayı ummak. SAATLER süren bir düzenleme çalışması.
Davaya bağlı olarak, metin yazılmaya başlanmadan önce bu 4, 5 veya 6 saat alırdı.
Bugün, iyi tasarlanmış bir akışla, ilk yapılandırılmış taslak dakikalar içinde ortaya çıkabiliyor.
Önemli olan, yapay zekanın "dilekçeyi yazması" değil.
Önemli olan, avukatın yapay zekayı bir metin kutusu olarak kullanmayı bırakıp bir çalışma sistemi olarak kullanmaya başlamasıdır.
Bana göre, bir komut (prompt) kullanmak ile bir ajan akışı (agentic flow) oluşturmak arasındaki temel fark budur.
Komut, tek başına bir talimattır.
Ajan akışı ise görevlerin, içeriğin, dosyaların, kriterlerin, şablonların, incelemelerin ve kararların organize bir dizisidir.
Bir komutta, "bununla ilgili bir dilekçe yaz" dersiniz.
Bir akışta, ajana nasıl çalışması gerektiğini öğretirsiniz.
Belgelerin nerede olduğunu gösterirsiniz. Hangi dosyaları önce okuması gerektiğini söylersiniz. Olguları nasıl çıkaracağını tanımlarsınız. Zaman çizelgesi formatını açıklarsınız. Dilekçe şablonlarınızı sağlarsınız. Dayanakları düzenleme şeklinizi belirtirsiniz. Yazmadan önce neyi kontrol etmesi gerektiğini tanımlarsınız. Asla neyi uydurmaması gerektiğini belirlersiniz. Bir şüphe listesi istersiniz. Bir risk matrisi istersiniz. Ancak ondan sonra yazmayı emredersiniz.
Pratikteki fark ÇOK BÜYÜK'tür.
Yapay zeka ile iyi bir hukuk akışı kabaca şu mantığı izleyebilir:
- Dava belgelerini oku.
- İlgili olguları çıkar.
- Belgeleri ispat işlevlerine göre ayır.
- Bir zaman çizelgesi oluştur.
- Tartışmalı noktaları belirle.
- Olguları olası taleplerle ilişkilendir.
- Davayı önceki şablonlarla karşılaştır.
- Bir metin planı oluştur.
- Bölümler halinde yaz.
- Tutarlılık, eksiklikler ve riskler açısından gözden geçir.
- Word'de son bir versiyon oluştur.
- İnsan incelemesi için bir kontrol listesi hazırla.
Bu, hukuki muhakemenin yerini almaz.
Aslında, daha fazla hukuki muhakeme gerektirir, çünkü avukatın süreci nasıl tasarlayacağını bilmesi gerekir.
Yapay zeka, kendi başına, stratejinizin ne olduğunu, hangi tezi tercih ettiğinizi, hangi riskin almaya değer olduğunu, hangi argümanın zayıf olduğunu, hangi olgunun kanıtlanması gerektiğini, hangi belgenin kullanılmaması gerektiğini, hangi talebin maliyet doğurabileceğini veya o mahkeme için hangi dilin uygun olduğunu bilmez.
Ancak belgelerin girilmesi ile metnin ilk kullanışlı versiyonu arasındaki mekanik işi acımasızca azaltabilir.
İşte bu noktada LLM'ler (Büyük Dil Modelleri) devreye giriyor.
LLM, large language model (büyük dil modeli) anlamına gelir. Pratikte, bağlamdan metin okuyabilen, yorumlayabilen, özetleyebilen, karşılaştırabilen, sınıflandırabilen, yeniden yazabilen, yapılandırabilen ve üretebilen model türüdür.
Ancak bir LLM, tek başına, hâlâ sadece motordur.
İşi değiştiren şey, motorun bir operasyon içinde kullanılmasıdır.
Aynı model kötü veya mükemmel bir şekilde kullanılabilir.
Dağınık belgeleri atıp eksiksiz bir dilekçe isterseniz, olguları karıştırabilir, dayanakları abartabilir, nüansları kaybedebilir ve güzel ama güvensiz bir metin teslim edebilir.
Akışı düzenler, aşamaları ayırır, şablonlar sağlar, gerekçeler isterseniz, izlenebilirlik talep eder ve insan incelemesi eklerseniz, sonuç doğası gereği değişir.
Avukat "bir yapay zeka metni" almayı bırakır ve bir çalışma paketi almaya başlar: çıkarılmış olgular, kronoloji, argüman yapısı, taslak, şüphe listesi, dikkat edilmesi gereken noktalar ve bir doğrulama kontrol listesi.
İşte beni ilgilendiren şey bu.
Codex ve Claude gibi araçlar, tam da tek başına komutun ötesine geçmeye izin verdikleri için ilginçtir.
Her ikisinde de mantık, dosyalar, talimatlar, terminal, betikler, şablonlar ve proje yapısı olan bir ortamda çalışmaktır.
Bu, hukuk mesleği için çok somut bir olasılık açar: her davayı organize bir çalışma klasörü olarak ele almak.
Avukatlar için dava başına basit bir klasör örneği:
/dava-müvekkil-x
/belgeler
/şablonlar
/taslaklar
/zaman-çizelgeleri
/kontrol-listeleri
/çıktılar
/belgeler klasörünün içine PDF'ler, sözleşmeler, kararlar, vekaletnameler, dışa aktarılmış e-postalar, raporlar, elektronik tablolar ve ilgili diğer her şey girer.
/şablonlar klasörünün içine önceki dilekçeleriniz, onaylanmış yapılar, referans metinler ve firma içi standartlar girer.
Talimatlar dosyasında, ajana bu tür bir talepte nasıl çalışması gerektiğini açıklarsınız.
Şöyle bir şey:
*“Önce ana belgeleri oku.” “Olguları tarih, kaynak ve ait olduğu belge ile birlikte çıkar.” “Doğrulanması gerektiğini belirtmeden hukuki dayanak oluşturma.” “Dilekçe şablonumu yapı olarak kullan, ancak davaya uyarla.” “Yazmadan önce bir plan sun.” “Taslaktan sonra bir inceleme kontrol listesi oluştur.” “Avukat onayına bağlı noktaları vurgula.”*
Bu basit görünüyor, ama her şeyi değiştiriyor.
Hem Codex hem de Claude, özellikle iş dosyaları içerdiğinde kullanışlı olabilir. Klasörlerde çalışabilir, içeriği okuyabilir, belgeleri düzenleyebilir, betikler çalıştırabilir, bilgileri dönüştürebilir, yapılandırılmış çıktılar oluşturabilir ve sıradan bir sohbete pek sığmayan materyallerle çalışabilirler.
Örneğin PDF'ler varsa, akış metin çıkarma, ilgili sayfaları belirleme, belge başına özet, ek listesi ve olgu ile kanıt arasında bağlantı kurmayı içerebilir.
Word dosyaları varsa, akış .docx şablonlarını kullanabilir, sürümleri karşılaştırabilir, yeni bir taslak oluşturabilir, antetinizi bozmadan yapıları, altbilgileri ve üstbilgileri koruyabilir, ayrıca başlıkları gözden geçirebilir ve insan düzenlemesi için son bir dosya hazırlayabilir.
Bu, "savunma yaz" demekten çok farklıdır.
Daha iyi bir akış şöyle olurdu:
*“1. Belgeler klasöründeki PDF'leri oku; 2. Olgu, tarih, belge ve sayfa içeren bir tablo oluştur; 3. Hukuken ilgili olguları belirle; 4. Şablonlar klasöründeki savunma şablonuyla karşılaştır; 5. Bir savunma planı oluştur; 6. Yazmadan önce şüpheleri listele; 7. Plan onaylandıktan sonra Word'de bir taslak oluştur; 8. Çelişkiler, temelsiz talepler ve kanıtı olmayan olgular için ikinci bir inceleme yap.”*
Bu noktada, dakikalar içinde dilekçe hazırlama vaadi boş bir söz olmaktan çıkar.
Düzenlemenin bir sonucu haline gelir.
Avukat hâlâ inceler.
Avukat hâlâ karar verir.
Avukat hâlâ cevaplar.
Ancak dosya dosya açmak ve bir sürece dönüştürülebilecek adımları elle tekrar tekrar yapmak için aynı enerjiyi harcamak zorunda kalmaz.
Claude, bu özel bağlamda, okuma, sentez, uzun metin yazma, dil incelemesi, muhakeme yapılandırma ve geniş bağlamla çalışma konularında genellikle çok güçlüdür. Hukuki akışlarda bu, kafa karıştırıcı materyalleri düzenli bir muhakemeye dönüştürmek için faydalı olabilir.
Claude Code ile mantık, talimatlar, beceriler, komutlar, uzmanlaşmış ajanlar ve zincirlenmiş görevler içeren projelerde ve dosyalarda ajan yürütmeye yaklaşır.
Claude Cowork ile bu mantık, masaüstünde bilgi çalışmasına gider: yerel dosyalar, uygulamalar, klasörler, tekrarlayan görevler, ofis malzemeleri ve mutlaka kod olmayan teslimatlar.
Bir avukat için bu çok önemlidir.
Çünkü hukuk işinin büyük bir kısmı sadece "yazmak" değildir.
Bilgiyi koordine etmektir.
Dağınık belgeleri bir teze dönüştürmektir.
Bir tezi bir metne dönüştürmektir.
Bir metni gözden geçirilmiş bir sürüme dönüştürmektir.
Bir incelemeyi bir kontrol listesine dönüştürmektir.
Öğrenmeyi tekrar kullanılabilir bir şablona dönüştürmektir.
Claude Cowork, bilgi görevleri için bir yürütme asistanı olarak düşünülebilir: bir klasörü düzenlemek, belgeleri incelemek, sürümleri karşılaştırmak, bir rapor hazırlamak, bir taslağı yapılandırmak, Word, Excel, PowerPoint ve diğer çalışma ortamlarında yardımcı olmak, her zaman kullanıcı denetimi ve izniyle.
Kazanç, başı, ortası ve sonu olan görevleri devretmekte yatar.
"Bu davada bana yardım et" değil.
Ama:
"Bu dava klasörünü aç, ana belgeleri oku, bir tabloda zaman çizelgesi oluştur, kanıt boşluklarını belirle ve inceleme için ilk taslak raporu hazırla."
Veya:
"Bu taslağı firmanın standart şablonuyla karşılaştır, ilgili farklılıkları belirt, eksik maddeleri vurgula ve daha nesnel bir dille gözden geçirilmiş bir versiyon oluştur."
Veya:
"Bu belgeleri oku, olguyu, iddiayı, kanıtı ve hâlâ doğrulanması gerekeni ayır."
Komuttaki bu değişiklik yüzeyde küçük, ancak operasyonda derindir.
Ajanın kalitesi, ona öğrettiğiniz işin kalitesine bağlıdır.
İşte bu noktada beceriler (skills) devreye giriyor.
Bir beceri, basit bir ifadeyle, ajana belirli bir tür işi yapmayı öğreten bir talimatlar, referanslar ve bazen betikler veya şablonlar paketidir.
Hukuk alanında bu, çok güçlü bir şey haline gelebilir.
Şunlar için bir beceriniz olabilir:
- bir tüketici dilekçesi hazırlamak;
- bir hizmet sözleşmesini incelemek;
- prosedürel bir zaman çizelgesi oluşturmak;
- ispat belgelerini analiz etmek;
- bir müvekkil için yönetici raporu hazırlamak;
- tutarlılık ve risk odaklı bir metni incelemek;
- bir mahkeme kararını stratejik bir özete dönüştürmek;
- bir dosyalama kontrol listesi oluşturmak;
- bir firma şablonunu belirli bir davaya uyarlamak.
Beceri yalnızca "güzel bir komut" içermek zorunda değildir.
Yöntem içerebilir.
Şöyle diyebilir:
*“Yazmadan önce her zaman bir plan yap.”
“Olguları argümanlardan ayır.”
“Asla dava numarası, içtihat veya belge uydurma.”
“Kanıt olmadığında, bunu beklemede olarak işaretle.”
“Açık ve teknik dil kullan.”
“Firma şablonunun yapısını koru.”
“Son bir kontrol listesi oluştur.”
“İnsan onayı gerektiren noktaları belirt.”*
Zamanla, firma doğaçlamaya bağımlı olmaktan çıkar.
Akıllı prosedürlerden oluşan bir kütüphane oluşturmaya başlar.
Bu, Codex için geçerlidir.
Claude için geçerlidir.
API çözümleri için geçerlidir.
Araç zaten hazır bir arayüz sunduğunda abonelik planları için geçerlidir.
"Model"in hepsi aynı olmadığını anlamak da önemlidir.
Yaygın bir hata, tek bir seçenek varmış gibi yapay zeka seçmektir: en ünlü, en pahalı veya en çok konuşulan model.
Pratikte, hukuk akışı farklı görevler için farklı modeller kullanabilir.
- Hızlı bir model belgeleri sınıflandırabilir, basit verileri çıkarabilir veya isimleri, tarihleri ve değerleri düzenleyebilir.
- Daha iyi muhakeme yeteneğine sahip bir model tezleri analiz edebilir, riskleri belirleyebilir, bir metin planı oluşturabilir ve çelişkileri inceleyebilir.
- Daha büyük bağlamı olan bir model aynı anda birçok belgeyi okuyabilir.
- Yazma konusunda daha güçlü bir model planı net bir taslağa dönüştürebilir.
- Dosyalara erişimi olan bir ajan Word belgesini oluşturabilir, sürümleri karşılaştırabilir ve klasörü düzenleyebilir.
Operasyonel sır, her şeyi tek bir yapay zeka çağrısı olarak ele almamakta yatar.
Akış bölünebilir:
- Önce, çıkarma.
- Sonra, düzenleme.
- Sonra, analiz.
- Sonra, plan.
- Sonra, yazma.
- Sonra, inceleme.
- Sonra, biçimlendirme.
- Sonra, kontrol listesi.
Her aşamanın bir işlevi vardır.
Ve her aşamanın kendi kriterleri olabilir.
Bu, halüsinasyonu azaltır.
Yeniden çalışmayı azaltır.
İzlenebilirliği artırır.
Ve insan incelemesini çok daha objektif hale getirir.
Bir dilekçe için bir akışın pratik bir örneği şöyle olabilir:
1. Belgelerin girilmesi.
Avukat bir dava klasörü oluşturur ve sözleşmeyi, görüşmeleri, makbuzları, bildirimleri, önceki kararları, vekaletnameyi, kişisel belgeleri ve müvekkil gözlemlerini koyar.
2. Okuma ve envanter.
Ajan tüm belgeleri listeler, türünü, tarihini, ilgili tarafları ve olası ilgiyi belirler.
3. Zaman çizelgesi.
Ajan, tarih, olgu, kaynak belge ve kanıtla ilgili gözlem içeren bir kronoloji oluşturur.
4. Hukuki sorunlar.
Ajan olası dayanakları ayırır ancak doğrulama gerektiğini işaretler.
5. Avukata sorular.
Yazmadan önce ajan neyin eksik olduğunu sorar: değer, talep, kanıt, yargı yetkisi, zamanaşımı, uzlaşma girişimi, prosedürel risk.
6. Metin planı.
Ajan bir yapı oluşturur: olgular, dayanaklar, talepler, kanıtlar, ihtiyati tedbir, dava değeri, ekli belgeler.
7. Şablona uyarlama.
Ajan bir firma şablonu kullanır, stili, yapıyı ve dili korur, ancak davaya uyarlar.
8. Taslak.
Ajan ilk versiyonu yazar.
9. Teknik inceleme.
Ajan tüm taleplerin bir dayanağı olup olmadığını, tüm önemli olguların bir belgesi olup olmadığını, çelişkiler olup olmadığını ve herhangi bir pasajın çok genel olup olmadığını inceler.
10. Word çıktısı.
Ajan, avukatın son incelemesi için başlık, konular ve yapı hazır olan düzenlenebilir bir versiyon oluşturur.
11. Kontrol listesi.
Ajan, dosyalamadan önce bir doğrulama listesi teslim eder.
Bu senaryoda, ilk taslak dakikalar içinde çıkabilir.
Ama yoktan var olmaz.
Bir sistemden doğar.
Ve bu sistem üç şeye bağlıdır: iyi girdiler, iyi talimatlar ve iyi inceleme.
Bunlar olmadan, yapay zeka yalnızca düzensizliği hızlandırır.
Yapay zekayı olgunlukla kullanmak isteyen bir firmanın bazı dahili varlıklar oluşturması gerekir.
Bunlar:
İşte bu noktada konu yeniden yönetişime (governance) döner.
Hukuk mesleğinde yapay zeka, bir üretkenlik oyuncağı olarak ele alınamaz.
Gizliliği, stratejiyi, mesleki sorumluluğu, kişisel verileri, hassas belgeleri, prosedürel riski ve müvekkil güvenini etkiler.
Bu nedenle avukatın teknolojinin asgarisini anlaması gerekir.
Mühendis olmak için değil. Neyi devrettiğini bilmek için.
Bir ajan bilgiyi düzenlemede mükemmel olabilir, ancak mesleki sorumluluk üstlenmez.
Bir LLM çok iyi yazabilir, ancak bu tezin o müvekkil için en iyisi olup olmadığını bilmez.
Bir akış metni hızlandırabilir, ancak hukuki stratejinin yerini almaz.
Olgunluk, yapay zekanın nerede devreye girdiğini ve nerede durduğunu bilmekte yatar.
Bana göre, hukuk mesleği, avukat kendi işinin etrafında küçük bir yapay zeka operasyonu kurabileceğini anladığında gerçekten değişmeye başlar.
Büyük başlaması gerekmez.
Bir klasör, üç şablon, iyi yazılmış bir talimat ve basit bir akışla başlayabilir:
"Oku, düzenle, sor, planla, yaz, gözden geçir."
Ondan sonra iyileştirir.
Beceri oluşturur.
Kontrol listesi oluşturur.
Çıktı standardı oluşturur.
Şablon bankası oluşturur.
Word için akış oluşturur.
PDF için akış oluşturur.
API üzerinden entegrasyon oluşturur.
Yönetişim oluşturur.
Zamanla, avukat sadece bir yapay zeka ile konuşan biri olmaktan çıkar.
Ajanları çalıştırmaya başlar.
Ve bu derin bir değişimdir.
Çünkü ajanları çalıştırmayı öğrenenler, hukuki bilgiyi tekrar kullanılabilir bir sürece dönüştürebilir.
Zaten var olan bir şablonu alıp ajanın belirli bir davaya uygulamasını sağlayabilirler.
Dağınık belgeleri yapıya dönüştürebilirler.
Saatler süren taramayı dakikalık incelemeye dönüştürebilirler.
"Bu dilekçede bana yardım et" ten "Şablonlarımı, kriterlerimi ve kontrol listelerimi kullanarak bu yazma akışını yürüt" e geçebilirler.
Mesele bu.
Avukat, ajana kendi yöntemi dahilinde çalışmayı öğrettiğinde, yapay zeka sadece bir yazma aracı olmaktan çıkar ve firmanın operasyonel bir katmanı olarak işlev görmeye başlar.
Dakikalar içinde dilekçe hazırlamak sadece görünen kısımdır.
Arkasında repertuar, iyi oluşturulmuş şablonlar, organize dosyalar, net talimatlar, uygun LLM seçimi, insan incelemesi ve yönetişim yatar.
Birçok kişinin hâlâ hafife aldığı nokta budur.
Gerçek dönüşüm, daha fazla metin üretmek değildir. Hukuki bilgiyi tekrar kullanılabilir bir sürece dönüştürmektir.
Bunu öğrenen bir firma tutarlılık kazanmaya başlar.
Tarama iyileşir.
İnceleme daha objektif hale gelir.
Şablonlar eski klasörlerde unutulmaz.
Birikmiş bilgi daha net akışlar içinde dolaşmaya başlar.
Ve avukat, hukuk pratiğinde her zaman kıt olan bir şeyi kazanır: daha iyi düşünmek için nitelikli zaman.
Sonuçta, yapay zeka hukuk işini daha az teknik yapmaz.
Daha fazla yöntem gerektirir.
Ve bu yöntemi inşa etmeyi bilenler, göz ardı edilmesi zor bir avantajla çalışacaktır.
