هوش مصنوعی در زیست بوم وکالت؛ از چت‌بات‌های عمومی تا زیرساخت هوشمند و حاکمیت داده
هوش مصنوعی در زیست بوم وکالت | هوش مصنوعی دیگر صرفاً یک ابزار برای تولید متن یا پاسخ‌گویی به پرسش‌ها نیست. در حرفه وکالت، این فناوری به‌تدریج در حال تغییر شیوه تحقیق، تحلیل اسناد، کشف ادله، ارزیابی استدلال‌ها و حتی معماری فناوری دفاتر و نهادهای حقوقی است.
اما در کنار این فرصت، یک پرسش اساسی وجود دارد:
آیا می‌توان اطلاعات محرمانه پرونده‌ها را همان‌گونه که از یک نرم‌افزار معمولی استفاده می‌کنیم، در اختیار سامانه‌های هوش مصنوعی قرار داد؟
پاسخ به این پرسش، صرفاً به انتخاب یک چت‌بات خوب یا ضعیف مربوط نیست. موضوع اصلی، معماری فناوری، محل پردازش داده، نحوه ذخیره‌سازی اطلاعات، سیاست‌های ارائه‌دهنده خدمت و در نهایت حاکمیت داده است.
برای درک این موضوع، می‌توان زیست‌بوم فعلی هوش مصنوعی حقوقی را در چهار لایه اصلی بررسی کرد؛ از ابزارهای عمومی ابری تا استقرار کاملاً محلی و ایزوله در سازمان.
فهرست محتوا
۱. لایه نخست؛ چت‌بات‌های عمومی و وسوسه استفاده سریع
بسیاری از وکلا نخستین مواجهه خود با هوش مصنوعی را از طریق ابزارهایی مانند ChatGPT، Claude، Gemini یا Copilot تجربه کرده‌اند.
این ابزارها برای کارهایی مانند:
- بازنویسی متن؛
- خلاصه‌سازی مطالب عمومی؛
- ترجمه؛
- ایده‌پردازی؛
- تنظیم ساختار یک متن؛
- یادگیری و تحقیق اولیه؛
- و تهیه پیش‌نویس‌های غیرمحرمانه
بسیار جذاب هستند.
مشکل زمانی آغاز می‌شود که همین الگوی استفاده، بدون توجه به ماهیت اطلاعات حقوقی، به پرونده‌های واقعی تعمیم داده شود.
چرا اطلاعات پرونده را نباید بدون بررسی وارد چت‌بات عمومی کرد؟
وقتی یک وکیل متن دادخواست، قرارداد، نظریه کارشناسی، اطلاعات مالی موکل یا سایر اسناد پرونده را در یک سرویس عمومی وارد می‌کند، دیگر صرفاً با یک «ابزار نگارش» مواجه نیست؛ بلکه داده را در یک زنجیره پردازش ابری متعلق به یک ارائه‌دهنده خارجی قرار داده است.
از این منظر، موضوعاتی مانند شرایط استفاده از سرویس، سیاست نگهداری داده، نحوه استفاده از داده‌های ورودی، محل پردازش و ذخیره‌سازی و سیاست‌های مربوط به آموزش مدل اهمیت پیدا می‌کنند.
بنابراین نباید میان این دو استفاده تفاوتی قائل نشد:
«یک متن عمومی را برای بازنویسی در اختیار هوش مصنوعی قرار می‌دهم.»
و
«اطلاعات محرمانه موکل را برای تحلیل پرونده در اختیار هوش مصنوعی قرار می‌دهم.»
این دو از منظر مدیریت ریسک داده، اساساً یکسان نیستند.
یک سناریوی ساده
فرض کنید وکیل برای خلاصه‌کردن یک قرارداد، متن کامل قرارداد را در یک چت‌بات عمومی کپی می‌کند. قرارداد حاوی نام طرفین، اطلاعات مالی، شماره حساب، مفاد محرمانه و جزئیات یک اختلاف تجاری است.
در این وضعیت، پرسش مهم دیگر این نیست که «آیا هوش مصنوعی می‌تواند قرارداد را خوب خلاصه کند؟»
پرسش اصلی این است:
این اطلاعات کجا پردازش می‌شود، چه کسی بر آن کنترل دارد و چه سیاستی برای نگهداری یا استفاده از آن وجود دارد؟
برای حرفه‌ای که بر محرمانگی اطلاعات موکل استوار است، این پرسش یک موضوع فرعی نیست؛ بخشی از مسئولیت حرفه‌ای وکیل است.
از این رو، استفاده از ابزارهای عمومی برای متون غیرمحرمانه، آموزش، ترجمه، ایده‌پردازی و امور عمومی می‌تواند با استفاده از آنها برای پردازش مستقیم پرونده‌های محرمانه کاملاً متفاوت باشد.
۲. لایه دوم؛ استفاده از چند مدل از طریق درگاه‌های یکپارچه
گام بعدی، استفاده از پلتفرم‌هایی است که امکان دسترسی به چند مدل هوش مصنوعی را از طریق یک رابط واحد فراهم می‌کنند.
نمونه‌هایی مانند OpenRouter، TypingMind و LibreChat در این دسته قرار می‌گیرند.
مزیت این معماری آن است که کاربر دیگر الزاماً به یک مدل واحد وابسته نیست و می‌تواند برای یک مسئله، خروجی چند مدل را با یکدیگر مقایسه کند.
برای مثال، یک وکیل می‌تواند یک مسئله حقوقی را بدون درج مشخصات هویتی پرونده مطرح کند و از چند مدل بخواهد:
- مسئله را تحلیل کنند؛
- استدلال‌های اصلی را استخراج کنند؛
- نقاط ضعف استدلال را مشخص کنند؛
- و در نهایت پاسخ‌های ارائه‌شده با یکدیگر مقایسه شوند.
این رویکرد می‌تواند برای تحقیق اولیه و ارزیابی چندجانبه یک مسئله حقوقی مفید باشد.
اما یک نکته مهم وجود دارد:
«عدم استفاده از داده برای آموزش» با «عدم وجود ریسک محرمانگی» یکی نیست.
حتی اگر یک سرویس تجاری سیاست‌هایی مانند Zero Data Retention داشته باشد، داده ممکن است برای پردازش از زیرساخت‌های خارج از سازمان عبور کند.
بنابراین، برای استفاده حرفه‌ای باید موضوعاتی مانند:
- محل پردازش داده؛
- شرایط قراردادی؛
- سیاست نگهداری اطلاعات؛
- رمزنگاری؛
- کنترل دسترسی؛
- و امکان گمنام‌سازی اطلاعات
بررسی شوند.
قاعده عملی برای وکیل
اگر قرار است از این دسته ابزارها استفاده شود، بهتر است پیش از ارسال اطلاعات:
نام اشخاص، شماره پرونده، کد ملی، نشانی، اطلاعات مالی و سایر شناسه‌های مستقیم یا غیرمستقیم حذف یا ناشناس‌سازی شوند.
در واقع، اینجا وکیل از «پرونده واقعی» به یک صورت‌مسئله حقوقی ناشناس‌شده تبدیل می‌کند و سپس از هوش مصنوعی برای تحلیل آن استفاده می‌کند.
۳. لایه سوم؛ LegalTech؛ وقتی هوش مصنوعی برای حقوق ساخته می‌شود
تفاوت مهمی میان یک چت‌بات عمومی و یک پلتفرم تخصصی LegalTech وجود دارد.
چت‌بات عمومی عمدتاً یک موتور عمومی تولید و تحلیل زبان است؛ اما سامانه حقوقی تخصصی می‌تواند علاوه بر مدل زبانی، به مجموعه‌ای از منابع و ابزارهای تخصصی متصل باشد.
در این معماری، اجزایی مانند:
- پایگاه قوانین؛
- رویه قضایی؛
- اسناد حقوقی؛
- پایگاه داده برداری؛
- ابزارهای جستجوی تخصصی؛
- کنترل‌های امنیتی؛
- و سازوکارهای کاهش خطای مدل
در کنار یکدیگر قرار می‌گیرند.
نمونه‌هایی از بازیگران شناخته‌شده این حوزه عبارت‌اند از:
- Harvey AI برای کاربردهای حرفه‌ای و سازمانی حقوقی؛
- CoCounsel متعلق به Thomson Reuters برای تحقیق، تحلیل و برخی فرایندهای حقوقی؛
- Robin AI برای تحلیل و اتوماسیون قراردادها.
مزیت اصلی چنین سامانه‌هایی این است که هدف آنها صرفاً «تولید یک متن شبیه متن انسانی» نیست؛ بلکه تلاش می‌کنند هوش مصنوعی را در فرایند واقعی کار حقوقی قرار دهند.
یک مثال
فرض کنیم یک مؤسسه حقوقی با صدها صفحه قرارداد و مستندات یک پرونده تجاری مواجه است.
یک چت‌بات عمومی ممکن است بتواند بخشی از متن را خلاصه کند.
اما یک LegalTech تخصصی می‌تواند در معماری مناسب، وظایف پیچیده‌تری مانند:
- شناسایی بندهای متناقض؛
- استخراج تعهدات طرفین؛
- مقایسه نسخه‌های مختلف قرارداد؛
- شناسایی ریسک‌های قراردادی؛
- و ارجاع به محل دقیق اطلاعات
را دنبال کند.
البته این پلتفرم‌ها نیز محدودیت‌های جدی دارند.
مهم‌ترین محدودیت برای کاربران ایرانی، پوشش قوانین و رویه قضایی ایران است. بسیاری از این محصولات بر اساس نظام‌های حقوقی کشورهای دیگر توسعه یافته‌اند و بنابراین نمی‌توان صرفاً به دلیل تخصصی‌بودن یک ابزار، آن را برای تحلیل حقوق ایران مناسب تلقی کرد.
هزینه‌های سازمانی، وابستگی به زیرساخت خارجی و مسائل مربوط به حاکمیت داده نیز از دیگر ملاحظات هستند.
۴. لایه چهارم؛ استقرار محلی؛ زمانی که داده از سازمان خارج نمی‌شود
در بالاترین سطح حاکمیت داده، می‌توان مدل‌های هوش مصنوعی را روی زیرساخت اختصاصی سازمان اجرا کرد.
در این معماری، مدل، پایگاه داده و ابزارهای پردازش می‌توانند در مرکز داده سازمان یا دفتر حقوقی مستقر شوند.
فناوری‌هایی مانند:
- Ollama؛
- vLLM؛
- llama.cpp؛
- و رابط‌هایی مانند Open WebUI
امکان اجرای مدل‌های متن‌باز را در زیرساخت محلی فراهم می‌کنند.
در چنین معماری‌ای، حتی می‌توان سامانه را به‌صورت On-Premise و در شرایط خاص به شکل Air-Gapped طراحی کرد؛ یعنی ارتباط سامانه با اینترنت عمومی به‌طور کامل یا تا حد موردنظر قطع شود.
چرا این معماری برای نهادهای حقوقی اهمیت دارد؟
تصور کنید یک کانون وکلا یا یک مؤسسه حقوقی دارای سامانه‌ای باشد که:
- اسناد پرونده‌ها؛
- دادنامه‌ها؛
- قراردادهای محرمانه؛
- آرای غیرعلنی؛
- و سایر داده‌های حساس
را بدون ارسال به سرویس عمومی خارجی پردازش کند.
در این حالت، سازمان کنترل بسیار بیشتری بر:
- محل ذخیره داده؛
- نحوه دسترسی کاربران؛
- سیاست نگهداری اطلاعات؛
- ثبت رخدادها؛
- به‌روزرسانی مدل؛
- و امنیت زیرساخت
خواهد داشت.
البته «On-Premise» به معنای حذف تمام ریسک‌های امنیتی نیست. امنیت سخت‌افزار، شبکه، سیستم‌عامل، مدل، کنترل دسترسی، پشتیبان‌گیری و مدیریت کاربران همچنان باید به‌صورت حرفه‌ای طراحی شود.
بنابراین، مزیت اصلی این معماری را باید افزایش حاکمیت و کنترل بر داده دانست، نه یک ادعای مطلق درباره حذف تمام ریسک‌ها.
۵. چهار معماری را چگونه با یکدیگر مقایسه کنیم؟
اگر چهار لایه بالا را کنار یکدیگر قرار دهیم، یک تصویر کلی به دست می‌آید:
| معیار | چت‌بات عمومی | API / Hub | LegalTech تخصصی | On-Premise |
|---|---|---|---|---|
| سهولت استفاده | بسیار بالا | بالا | بالا | متوسط |
| هزینه اولیه | کم | کم تا متوسط | بالا | بالا |
| کنترل بر داده | محدود | وابسته به قرارداد و معماری | بالاتر | بسیار بالا |
| تخصص حقوقی | محدود | وابسته به مدل | بالا | قابل طراحی |
| استقلال از سرویس خارجی | کم | کم | کم | بسیار بالا |
| قابلیت شخصی‌سازی | کم | متوسط | بالا | بسیار بالا |
| مناسب برای داده محرمانه | نیازمند احتیاط جدی | مشروط | وابسته به معماری و قرارداد | مناسب‌تر برای طراحی سازمانی |
این جدول یک نکته مهم را نشان می‌دهد:
انتخاب فناوری هوش مصنوعی نباید صرفاً بر اساس «قدرت مدل» انجام شود.
برای یک نهاد حقوقی، معماری داده و سطح کنترل بر اطلاعات ممکن است به اندازه توانایی مدل اهمیت داشته باشد.
۶. از کجا بدانیم یک پاسخ هوش مصنوعی قابل اعتماد است؟
مسئله مهم دیگری که وکلا باید بشناسند، توهم هوش مصنوعی یا Hallucination است.
مدل زبانی بزرگ، برخلاف یک پایگاه داده حقوقی قطعی، اساساً یک سیستم تولید زبان است. یکی از سازوکارهای بنیادین این مدل‌ها، پیش‌بینی توکن بعدی بر اساس الگوهایی است که در فرایند آموزش آموخته‌اند.
به همین دلیل، ممکن است یک مدل:
- ماده قانونی را اشتباه نقل کند؛
- شماره رأیی را که وجود ندارد تولید کند؛
- یک منبع قضایی ساختگی ارائه دهد؛
- یا استدلالی ظاهراً کاملاً منطقی اما فاقد مبنای واقعی ارائه کند.
مشکل اینجاست که پاسخ نادرست ممکن است با لحن بسیار مطمئن و حرفه‌ای ارائه شود.
پرونده مشهور Mata v. Avianca نمونه‌ای هشداردهنده از خطر استناد به آرای ساختگی تولیدشده توسط هوش مصنوعی است.
بنابراین، یک اصل باید در استفاده حقوقی از هوش مصنوعی پذیرفته شود:
پاسخ روان و قانع‌کننده، لزوماً پاسخ درست نیست.
هوش مصنوعی می‌تواند دستیار تحقیق باشد؛ اما مسئولیت راستی‌آزمایی منبع و صحت استناد همچنان بر عهده انسان باقی می‌ماند.
۷. جستجوی معنایی؛ چرا جستجوی حقوقی در حال تغییر است؟
یکی از تحولات مهم در فناوری LegalTech، حرکت از جستجوی صرفاً کلیدواژه‌ای به سمت جستجوی معنایی یا Semantic Search است.
در جستجوی سنتی، معمولاً کاربر واژه‌ای را وارد می‌کند و سامانه به دنبال همان واژه یا ترکیب مشابه می‌گردد.
اما در جستجوی معنایی، متن به نمایش عددی موسوم به Embedding تبدیل می‌شود.
به زبان ساده، سیستم تلاش می‌کند به جای تمرکز صرف بر کلمات، معنای متن و ارتباط مفهومی میان بخش‌های مختلف آن را نیز در نظر بگیرد.
برای مثال، یک سامانه جستجوی معنایی می‌تواند میان مفاهیمی مانند:
«تلف مبیع پیش از قبض»
و
«هلاکت کالا و آثار آن بر قرارداد بیع»
ارتباط مفهومی برقرار کند، حتی اگر تمام واژه‌های دو عبارت یکسان نباشند.
این فناوری برای حقوق اهمیت زیادی دارد؛ زیرا زبان حقوقی همیشه به شکل یکسان و با واژگان ثابت بیان نمی‌شود.
۸. چرا قراردادن یک پرونده ۵۰۰ صفحه‌ای در یک چت، الزاماً ایده خوبی نیست؟
یکی دیگر از مفاهیمی که در طراحی سامانه‌های هوش مصنوعی حقوقی اهمیت دارد، Context Window یا پنجره زمینه است.
مدل‌های زبانی می‌توانند حجم زیادی از متن را همزمان دریافت کنند، اما «توانایی دریافت متن» با «توانایی توجه یکسان به تمام بخش‌های آن» یکی نیست.
در متون بسیار طولانی، پدیده‌ای با عنوان Lost in the Middle مطرح می‌شود؛ یعنی ممکن است اطلاعاتی که در میانه یک ورودی بسیار طولانی قرار گرفته‌اند، کمتر مورد توجه مدل قرار گیرند.
این موضوع برای پرونده‌های حقوقی اهمیت ویژه‌ای دارد.
یک پرونده ۵۰۰ صفحه‌ای ممکن است حاوی یک سند بسیار مهم در صفحه ۲۷۸ باشد. بنابراین صرفاً بارگذاری کل پرونده و طرح یک سؤال ساده، تضمین نمی‌کند که مدل آن سند را به‌درستی شناسایی و در استدلال خود لحاظ کند.
راه‌حل حرفه‌ای‌تر، طراحی معماری‌هایی است که:
- اسناد را طبقه‌بندی کنند؛
- متن را به بخش‌های معنادار تقسیم کنند؛
- اسناد مرتبط را بازیابی کنند؛
- و سپس بخش‌های مرتبط را در اختیار مدل قرار دهند.
اینجاست که مفهوم RAG اهمیت پیدا می‌کند.
۹. RAG حقوقی؛ اتصال مدل زبانی به منابع حقوقی
Retrieval-Augmented Generation یا RAG یکی از مهم‌ترین معماری‌هایی است که می‌تواند استفاده از مدل‌های زبانی را در محیط حقوقی قابل‌کنترل‌تر کند.
در یک معماری ساده RAG، فرایند می‌تواند چنین باشد:
پرسش کاربر ← جستجوی پایگاه اسناد ← بازیابی اسناد مرتبط ← ارسال بخش‌های مرتبط به مدل ← تولید پاسخ مستند
در این روش، مدل صرفاً بر دانسته‌های عمومی خود تکیه نمی‌کند؛ بلکه ابتدا منابع مرتبط را از یک پایگاه داده بازیابی می‌کند.
برای یک سامانه حقوقی، این پایگاه می‌تواند شامل:
- قوانین؛
- مقررات؛
- آرای وحدت رویه؛
- آرای قضایی؛
- نظریات مشورتی؛
- قراردادها؛
- آیین‌نامه‌ها؛
- و اسناد سازمانی
باشد.
با این حال، نباید از اصطلاح «Zero Hallucination» به معنای تضمین مطلق نبود خطا برداشت کرد.
RAG می‌تواند احتمال خطا را کاهش دهد و امکان استناد به منابع را افزایش دهد، اما هیچ معماری نرم‌افزاری به‌تنهایی مسئولیت راستی‌آزمایی حقوقی را حذف نمی‌کند.
۱۰. مهندسی داده حقوقی؛ چرا تکه‌تکه کردن متن یک کار ساده نیست؟
در نگاه اول ممکن است تقسیم یک سند به قطعات کوچک، یک کار کاملاً فنی به نظر برسد.
اما در اسناد حقوقی، این کار مستقیماً به کیفیت پاسخ هوش مصنوعی مرتبط است.
فرض کنید یک قانون به این شکل ساختار یافته باشد:
ماده ← تبصره ← بند ← جزء
اگر سیستم صرفاً متن را بر اساس تعداد ثابتی از کاراکترها یا کلمات تقسیم کند، ممکن است ماده از تبصره مرتبط با آن جدا شود.
در این صورت، مدل ممکن است بخشی از حکم را ببیند اما استثنا یا شرط آن را نبیند.
به همین دلیل، در سامانه‌های LegalTech حرفه‌ای، Hierarchical Chunking یا تقطیع سلسله‌مراتبی اهمیت پیدا می‌کند.
یعنی ساختار حقوقی سند تا حد امکان حفظ شود.
برای مثال، سامانه باید بداند که:
- این متن یک ماده است؛
- این بخش تبصره همان ماده است؛
- این قسمت بند مربوط به آن تبصره است؛
- و این رأی قضایی به کدام موضوع مرتبط است.
اینجاست که یک واقعیت مهم آشکار می‌شود:
ساخت یک سامانه هوش مصنوعی حقوقی صرفاً پروژه برنامه‌نویسی نیست.
این کار نیازمند همکاری نزدیک متخصص هوش مصنوعی، مهندس داده، متخصص امنیت و وکیل آشنا با ساختار و منطق منابع حقوقی است.
۱۱. آینده وکالت؛ از یک چت‌بات به یک تیم از ایجنت‌ها
گام بعدی تحول هوش مصنوعی، حرکت از «پرسش و پاسخ» به سمت Agentic AI و سیستم‌های چندعاملی است.
در مدل سنتی، وکیل یک سؤال را مطرح می‌کند و مدل یک پاسخ تولید می‌کند.
اما در یک سیستم چندعاملی، وظیفه پیچیده می‌تواند به چند مرحله تقسیم شود.
برای مثال، در یک فرایند فرضی:
Agent A — استخراج اطلاعات
تاریخ‌ها، اسامی، خواسته‌ها، مبالغ و سایر داده‌های ساختاریافته را از اسناد استخراج می‌کند.
Agent B — تحقیق حقوقی
اطلاعات استخراج‌شده را با قوانین، مقررات و رویه‌های مرتبط تطبیق می‌دهد.
Agent C — تولید پیش‌نویس
بر اساس داده‌ها و منابع بازیابی‌شده، پیش‌نویس لایحه یا گزارش حقوقی تهیه می‌کند.
Agent D — وکیل مخالف
متن تهیه‌شده را از منظر طرف مقابل نقد می‌کند و نقاط ضعف استدلال را پیدا می‌کند.
در این معماری، وکیل دیگر صرفاً با «یک چت‌بات» گفت‌وگو نمی‌کند.
او در حال مدیریت یک فرایند متشکل از چند عامل نرم‌افزاری تخصصی است.
این تغییر می‌تواند در سال‌های آینده یکی از مهم‌ترین تحولات در سازمان‌دهی کار حقوقی باشد.
۱۲. چهار سطح بلوغ هوش مصنوعی در دفتر وکالت
با کنار هم گذاشتن مباحث بالا، می‌توان برای دفاتر و نهادهای حقوقی یک مدل چهارسطحی از بلوغ هوش مصنوعی ترسیم کرد.
سطح اول: استفاده عمومی و غیرایمن
وکیل از چت‌بات‌های عمومی برای پرونده‌های واقعی استفاده می‌کند، بدون اینکه سیاست مشخصی درباره محرمانگی داده وجود داشته باشد.
این پایین‌ترین سطح بلوغ است.
سطح دوم: استفاده کنترل‌شده از RAG
دفتر حقوقی از ابزارهایی استفاده می‌کند که امکان اتصال مدل به اسناد مشخص را فراهم می‌کنند و تلاش می‌شود داده‌ها و منابع بهتر کنترل شوند.
سطح سوم: زیرساخت سازمانی
دفتر یا سازمان دارای پایگاه داده برداری، سامانه RAG اختصاصی و ایجنت‌های تخصصی خود است.
در این مرحله، هوش مصنوعی دیگر یک «ابزار شخصی وکیل» نیست؛ بلکه بخشی از زیرساخت سازمانی است.
سطح چهارم: زیرساخت بومی و On-Premise
در بالاترین سطح، سازمان می‌تواند مدل‌ها، داده‌ها و سامانه‌های هوشمند خود را روی زیرساخت اختصاصی اجرا کند و در صورت نیاز مدل را برای حوزه حقوقی و زبان فارسی متناسب‌سازی کند.
۱۳. کانون‌های وکلا در برابر یک انتخاب راهبردی
با توجه به سرعت تحول فناوری، مسئله اصلی برای نهادهای حرفه‌ای دیگر این نیست که:
«آیا وکلا باید از هوش مصنوعی استفاده کنند؟»
این سؤال تا حد زیادی پاسخ خود را پیدا کرده است.
پرسش مهم‌تر این است:
«وکلا با چه قواعدی، چه ابزارهایی و تحت چه نظامی از حاکمیت داده باید از هوش مصنوعی استفاده کنند؟»
برای کمیسیون‌ها و کمیته‌های فناوری اطلاعات کانون‌های وکلا، می‌توان چند محور عملی را در نظر گرفت.
نخست؛ سیاست‌گذاری
باید مشخص شود چه نوع اطلاعاتی مجاز است وارد سامانه‌های عمومی شود و چه اطلاعاتی باید تحت هر شرایطی در محیط‌های کنترل‌شده پردازش شود.
دوم؛ آموزش
وکیل باید بداند که:
- هوش مصنوعی چگونه کار می‌کند؛
- Hallucination چیست؛
- چگونه منبع را بررسی کند؛
- چگونه اطلاعات محرمانه را ناشناس کند؛
- و چگونه خروجی مدل را اعتبارسنجی کند.
سوم؛ ایجاد زیرساخت
به‌جای اینکه هر وکیل به‌صورت جداگانه ابزارهای مختلف را آزمایش کند، کانون می‌تواند امکان ایجاد یک زیرساخت امن و سازمانی هوش مصنوعی را بررسی کند.
چهارم؛ توسعه پایگاه دانش حقوقی
اگر قرار است هوش مصنوعی واقعاً در خدمت حقوق ایران قرار گیرد، کیفیت و ساختار داده‌های حقوقی اهمیت اساسی دارد.
قوانین، مقررات، آراء، نظریات و سایر منابع باید به شکل استاندارد، قابل جستجو و قابل استفاده برای معماری‌های هوش مصنوعی آماده شوند.
پنجم؛ تدوین استانداردهای حرفه‌ای
کانون‌ها می‌توانند در آینده به سمت تدوین دستورالعمل‌هایی درباره:
- محرمانگی؛
- استفاده از هوش مصنوعی در تنظیم اسناد؛
- اعتبارسنجی خروجی؛
- مسئولیت وکیل؛
- ثبت استفاده از AI؛
- و امنیت داده
حرکت کنند.
جمع‌بندی؛ آینده متعلق به وکیلی نیست که فقط «پرامپت» بهتری می‌نویسد
هوش مصنوعی در حرفه وکالت را نباید به استفاده از ChatGPT یا یک چت‌بات دیگر تقلیل داد.
تحول اصلی در جای دیگری اتفاق می‌افتد:
در معماری داده، جستجوی معنایی، RAG، پایگاه‌های دانش حقوقی، مدل‌های استدلالی، ایجنت‌های هوشمند و زیرساخت‌های امن پردازش اطلاعات.
وکیل آینده احتمالاً کسی نیست که صرفاً سریع‌تر از دیگران یک متن را با هوش مصنوعی تولید کند.
وکیل آینده کسی است که بتواند:
- مسئله حقوقی را به‌درستی صورت‌بندی کند؛
- منابع معتبر را به سیستم متصل کند؛
- خروجی هوش مصنوعی را نقد و راستی‌آزمایی کند؛
- ریسک محرمانگی را مدیریت کند؛
- و از مجموعه‌ای از ابزارهای هوشمند در یک فرایند حرفه‌ای استفاده کند.
از این منظر، هوش مصنوعی الزاماً جایگزین وکیل نیست؛ بلکه هندسه کار حقوقی را تغییر می‌دهد.
مسئله اصلی نیز دیگر صرفاً انتخاب «بهترین مدل هوش مصنوعی» نیست.
مسئله این است که:
چه کسی داده را کنترل می‌کند، چه کسی معماری را طراحی می‌کند و چه کسی قواعد استفاده از هوش مصنوعی در حرفه وکالت را تعیین خواهد کرد؟
برای کانون‌های وکلا، این پرسش یک موضوع صرفاً فناورانه نیست؛ موضوعی درباره حاکمیت حرفه‌ای، محرمانگی، اخلاق حرفه‌ای و آینده نظام ارائه خدمات حقوقی است.
سید علیرضا طباطبایی وکیل سایبری
مطالب مرتبط:
