مالکیت فکری و حق ممیزی الزاماً در تعارض با یکدیگر نیستند. تنظیم‌گر برای نظارت مؤثر بر یک مدل هوش مصنوعی بیش از آنکه به مالکیت یا حتی مشاهده کد منبع نیاز داشته باشد، به حق مطالبه شواهد، دسترسی متناسب به داده و مستندات، امکان آزمون مستقل و در نهایت اختیار الزام به اصلاح نیاز دارد.
یکی از پرسش‌هایی که با گسترش مدل‌های خارجی در سامانه‌های حساس بیشتر مطرح خواهد شد این است که چگونه می‌توان بر فناوری‌ای حکمرانی کرد که کد، وزن‌ها و بخش مهمی از جزئیات فنی آن متعلق به شرکتی در کشور دیگری است. پاسخ ساده این است که تنظیم‌گر باید بتواند کد منبع را ببیند؛ اما این پاسخ هم از نظر فنی و هم از نظر حقوقی بیش از حد ساده است.
توافق‌های جدید تجارت دیجیتال معمولاً دولت‌ها را از مطالبه کد منبع یک نرم‌افزار خارجی به‌عنوان شرط ورود آن به بازار منع می‌کنند. منطق این محدودیت روشن است: اگر هر کشور بتواند برای فروش نرم‌افزار، شرکت خارجی را مجبور به تحویل کد منبع کند، حفاظت از مالکیت فکری عملاً بی‌معنا می‌شود. اما همین قاعده وقتی نرم‌افزار موردنظر یک سامانه هوش مصنوعی باشد، پرسش دیگری ایجاد می‌کند: اگر دولت حق ندارد صرفاً برای ورود محصول به بازار کد آن را مطالبه کند، چگونه باید ایمنی، تبعیض، امنیت یا انطباق آن را ارزیابی کند؟
مطالعه تازه مؤسسه مطالعات جنوب آسیا در دانشگاه ملی سنگاپور درباره قواعد کد منبع در توافق تجارت آزاد هند و اتحادیه اروپا از همین نقطه شروع می‌کند. نکته مهم مطالعه نه خود این توافق، بلکه تفاوتی است که میان حفاظت از مالکیت فکری و قدرت واقعی تنظیم‌گر برای ممیزی آشکار می‌کند.
کد منبع، خودِ مدل نیست
اولین مسئله فنی این است که در سامانه‌های هوش مصنوعی، مشاهده کد منبع الزاماً اطلاعاتی را که تنظیم‌گر نیاز دارد در اختیار او نمی‌گذارد.
در یک نرم‌افزار متعارف، بخش مهمی از منطق رفتار سیستم در کد نوشته شده است. بررسی کد می‌تواند نشان دهد داده چگونه پردازش می‌شود، چه قواعدی اجرا می‌شوند و کدام مسیرهای منطقی به خروجی منتهی می‌شوند. اما رفتار یک مدل یادگیری ماشین فقط محصول کدی نیست که معماری و اجرای آن را تعریف کرده است.
رفتار مدل به داده آموزش، نحوه آماده‌سازی آن، وزن‌های آموخته‌شده، Fine-tuning، تنظیمات استنتاج، System Prompt، Guardrailها، ابزارهای متصل، RAG، داده‌های زمینه‌ای و گاهی حتی تاریخچه تعامل وابسته است. دو سامانه با کد تقریباً یکسان می‌توانند به‌دلیل تفاوت در وزن، داده یا تنظیمات، رفتارهای کاملاً متفاوتی داشته باشند.
در نتیجه، دسترسی به repository یک LLM لزوماً پاسخ نمی‌دهد که مدل تا چه اندازه در یک حوزه تبعیض دارد، چه قابلیت سایبری‌ای پیدا کرده، در چه شرایطی اطلاعات حساس افشا می‌کند یا چه نوع داده‌ای در آموزش آن استفاده شده است.
حتی در مدل‌های وزن‌باز هم مسئله کاملاً حل نمی‌شود. داشتن سورس اجرای مدل و وزن‌ها به‌معنای داشتن Provenance داده، جزئیات فرایند آموزش، گزارش Red Teaming یا نتایج ارزیابی‌های داخلی نیست.
بنابراین اگر «شفافیت» را با «دیدن سورس» یکی بگیریم، ممکن است به چیزی دسترسی پیدا کنیم که از نظر حقوق مالکیت بسیار حساس است، اما برای پاسخ به سؤال تنظیم‌گری چندان کافی نیست.
تنظیم‌گر دقیقاً باید چه چیزی را ببیند؟
قانون هوش مصنوعی اتحادیه اروپا در اینجا تفکیک جالبی ایجاد کرده است. در ماده ۷۴، نهادهای نظارت بر بازار برای سامانه‌های پرریسک می‌توانند به مستندات و مجموعه‌داده‌های آموزش، اعتبارسنجی و آزمون دسترسی داشته باشند؛ حتی در صورت لزوم از طریق API یا روش فنی دیگری که امکان بررسی از راه دور را فراهم کند. دسترسی به کد منبع در مرحله بعد قرار می‌گیرد و فقط زمانی مطرح می‌شود که روش‌های آزمون، ممیزی و بررسی مستندات و داده‌ها برای ارزیابی انطباق کافی نباشند.
این ترتیب مهم است.
منطق آن تقریباً می‌گوید تنظیم‌گر ابتدا باید بتواند شواهد رفتار و فرایند را ببیند، نه لزوماً تمام دارایی فکری سازنده را.
در ارزیابی انطباق نیز همین الگو دیده می‌شود. نهاد ارزیاب می‌تواند شواهد بیشتری مطالبه کند، از ارائه‌دهنده بخواهد آزمون‌های تکمیلی انجام دهد و اگر آزمون‌های شرکت کافی نباشند، خودش آزمون مناسب را اجرا کند. در شرایطی خاص حتی دسترسی به مدل آموزش‌دیده و پارامترهای مربوط نیز پیش‌بینی شده است.
این نگاه، معماری ممیزی AI را از «کد را بده تا بررسی کنیم» به مجموعه‌ای چندلایه تبدیل می‌کند:
مستندات فنی، داده‌های ارزیابی، Provenance، نتیجه آزمون‌ها، دسترسی آزمایشی به مدل، امکان اجرای تست مستقل، دسترسی به مدل یا پارامترها در صورت ضرورت، و در نهایت کد منبع به‌عنوان یکی از ابزارهای ممکن.
این دقیقاً همان تفاوتی است که در یادداشت «قرارداد هوش مصنوعی؛ دقیقاً چه چیزی را باید تحویل بگیریم؟» نیز از زاویه قرارداد مطرح شده بود. در یک پروژه AI، تحویل سورس به‌تنهایی به این معنا نیست که کارفرما واقعاً چیزی قابل ارزیابی یا قابل بازتولید تحویل گرفته است. نسخه مدل، داده، معیارها، Promptها، نتایج ارزیابی و روش بازتولید رفتار بخشی از هویت واقعی سامانه‌اند.
حق ممیزی با مالکیت یکی نیست
از اینجا می‌توان به یک تمایز مهم‌تر رسید: برای حکمرانی بر یک فناوری، لازم نیست مالک آن فناوری باشیم.
نهاد هوانوردی برای بررسی ایمنی هواپیما لازم نیست مالک طراحی موتور باشد. تنظیم‌گر دارو مالک فرمول شرکت داروسازی نیست و حسابرس نیز صاحب سیستم مالی شرکتی که بررسی می‌کند نمی‌شود. آنچه اهمیت دارد، وجود حق قانونی برای مطالبه شواهد و امکان راستی‌آزمایی مستقل است.
همین منطق در AI نیز قابل اعمال است.
یک کشور ممکن است هیچ سهمی در مالکیت یک مدل Frontier نداشته باشد، اما اگر آن مدل در بانک، سلامت، دولت یا زیرساخت حیاتی آن کشور استفاده می‌شود، همچنان می‌تواند برای نحوه استفاده از آن شرط بگذارد، شواهد بخواهد، آزمون مستقل مطالبه کند و در صورت عدم انطباق، کاربرد آن را محدود کند.
از طرف دیگر، حتی مالکیت داخلی مدل هم لزوماً حاکمیت ایجاد نمی‌کند. اگر تنظیم‌گر حق دسترسی به لاگ‌ها، نتایج آزمون یا اطلاعات لازم برای ارزیابی را نداشته باشد، «داخلی بودن» مدل به‌خودی‌خود مسئله نظارت را حل نمی‌کند.
بنابراین حاکمیت فناوری را نباید فقط با مالکیت اشتباه گرفت.
در بسیاری از موارد، حاکمیت بیشتر از مالکیت به قدرت مشاهده، آزمون، الزام و واکنش وابسته است.
تجارت دیجیتال کجا وارد مسئله می‌شود؟
ماده ۹.۹ متن توافق تجارت آزاد هند و اتحادیه اروپا اصل کلی را روشن می‌کند: یک طرف نمی‌تواند ارائه کد منبع نرم‌افزار متعلق به شرکت طرف دیگر را صرفاً به‌عنوان شرط واردات، فروش یا استفاده از محصول مطالبه کند.
اما همان ماده استثناهای مهمی نیز دارد. تنظیم‌گران، مراجع قضایی، نهادهای اجرای قانون و نهادهای ارزیابی انطباق می‌توانند برای تحقیق، بازرسی، اجرای قانون یا تحقق اهداف مشروع سیاست عمومی، دسترسی متناسب و حفاظت‌شده مطالبه کنند. توافق همچنین صراحتاً اجازه می‌دهد در قراردادهای تجاری یا خرید دولتی، طرف‌ها داوطلبانه درباره دسترسی به سورس توافق کنند.
در نتیجه، توافق تجاری لزوماً «دست تنظیم‌گر را نمی‌بندد».
مسئله ظریف‌تر است.
توافق می‌تواند بگوید در صورت وجود یک هدف مشروع و مبنای قانونی، دسترسی تنظیم‌گر ممنوع نیست؛ اما باید ابتدا در قانون داخلی معلوم باشد تنظیم‌گر چه حقی دارد، در چه شرایطی می‌تواند اطلاعات مطالبه کند و چه نوع شواهدی برای انجام وظیفه او ضروری است.
همین‌جا مطالعه NUS به نکته مهمی درباره هند می‌رسد. متن توافق تجاری امکان برخی دسترسی‌های نظارتی را باز گذاشته، اما اگر قوانین داخلی هند هنوز اختیار روشن و نظام‌مند برای ارزیابی AI پرریسک ایجاد نکرده باشند، وجود آن استثنا به‌تنهایی قدرت اجرایی چندانی تولید نمی‌کند. پژوهش این مسئله را نوعی عدم تقارن میان چارچوب داخلی هند و اتحادیه اروپا می‌داند.
یعنی ممکن است حق بین‌المللی اعمال تنظیم‌گری محفوظ باشد، اما ابزار داخلی استفاده از آن هنوز ساخته نشده باشد.
ممیزی از Source Code Review بزرگ‌تر است
این مسئله را می‌توان از زاویه دیگری هم دید. اگر ممیزی AI را معادل Code Review بگیریم، بخش بزرگی از آنچه باید ممیزی شود خارج از میدان دید باقی می‌ماند.
در یک سامانه پرریسک باید بتوان پرسید:
مدل روی چه داده‌ای ارزیابی شده است؟ آیا این داده نماینده محیط واقعی استفاده است؟ چه گروه‌هایی در Test Set حضور نداشته‌اند؟ کدام نسخه مدل آزمون شده است؟ آیا مدل مستقر همان نسخه است؟ چه تغییراتی پس از آزمون انجام شده‌اند؟ چه ابزارهایی در اختیار Agent قرار دارند؟ حدود دسترسی چیست؟ چه رخدادهایی لاگ می‌شوند؟ مدل در Red Teaming چگونه رفتار کرده و چه کنترل‌هایی بعد از آن اضافه شده‌اند؟
بسیاری از این پرسش‌ها با خواندن سورس پاسخ داده نمی‌شوند.
حتی مسئله Bias نیز بیشتر از کد به داده، طراحی آزمون و محیط کاربرد وابسته است. قانون AI اتحادیه اروپا به همین دلیل برای سامانه‌های پرریسک روی کیفیت، نمایندگی و تناسب داده‌های آموزش، اعتبارسنجی و آزمون تأکید دارد.
در نتیجه، شاید بهتر باشد حق ممیزی AI را نه «حق دیدن کد»، بلکه حق دسترسی متناسب به شواهد مورد نیاز برای اثبات انطباق تعریف کنیم.
گاهی این شواهد مستندات‌اند. گاهی لاگ، Dataset یا API آزمایشی. گاهی نیاز به اجرای تست مستقل وجود دارد. در موارد خاص ممکن است وزن مدل یا پارامترها مورد نیاز باشند و تنها در آخرین مرحله، کد منبع لازم شود.
این مدل هم از مالکیت فکری بهتر حفاظت می‌کند و هم ممیزی را به چیزی مرتبط می‌کند که واقعاً می‌خواهیم بدانیم.
یک حق مهم‌تر: حق انجام آزمون مستقل
مسئله حتی از دسترسی به اطلاعات هم فراتر می‌رود.
اگر تمام شواهد توسط خود توسعه‌دهنده تولید شده باشند، تنظیم‌گر همچنان با مشکل self-assessment روبه‌روست. ممکن است مستندات کامل باشند، اما طراحی آزمون به شکلی باشد که نقطه ضعف مدل را نشان ندهد.
بنابراین یکی از مهم‌ترین حقوق تنظیم‌گر، امکان راستی‌آزمایی مستقل است.
این استقلال می‌تواند اشکال مختلف داشته باشد. تنظیم‌گر ممکن است خودش توان فنی انجام آزمون داشته باشد، یک آزمایشگاه معتبر را مأمور کند یا توسعه‌دهنده را موظف کند API، محیط تست یا نسخه‌ای محدود از مدل در اختیار ممیز قرار دهد.
نکته این نیست که همه مدل‌ها باید وزن یا سورس خود را تحویل دهند. نکته این است که سازنده نباید تنها طرفی باشد که هم آزمون را طراحی می‌کند، هم آن را اجرا می‌کند و هم درباره کفایت نتیجه قضاوت می‌کند.
این همان مسیری است که در یادداشت «حکمرانی هوش مصنوعی در حال عبور از قانون‌نویسی» مطرح شد: گذار از اعلام رعایت قواعد به اثبات رعایت قواعد.
مالکیت فکری همچنان مسئله واقعی است
البته نباید از سوی دیگر مسئله بیفتیم و تصور کنیم هرچه دسترسی تنظیم‌گر بیشتر باشد، حکمرانی بهتر است.
کد، وزن‌های مدل، داده آموزشی و حتی System Prompt می‌توانند دارایی‌های بسیار حساس تجاری و امنیتی باشند. دسترسی غیرضروری به آن‌ها ریسک نشت مالکیت فکری، سوءاستفاده یا حتی افزایش سطح حمله را ایجاد می‌کند.
به همین دلیل اصل تناسب اهمیت زیادی دارد.
تنظیم‌گر باید بتواند اطلاعات لازم را مطالبه کند، اما نه بیشتر از آنچه برای انجام وظیفه‌اش لازم است. دسترسی باید هدف‌دار، ثبت‌شده، محدود و مشمول تعهد محرمانگی باشد. قانون AI اتحادیه اروپا نیز دسترسی به Source Code را دقیقاً به‌عنوان گزینه‌ای محدود و پس از ناکافی‌بودن روش‌های دیگر قرار داده است.
این معماری از نظر حکمرانی جذاب است، چون مسئله را از دوگانه غلط «یا اسرار تجاری، یا شفافیت کامل» خارج می‌کند.
می‌توان هم از مالکیت فکری حفاظت کرد و هم اجازه نداد «محرمانه است» به پاسخ پیش‌فرض در برابر هر درخواست نظارتی تبدیل شود.
این مسئله برای مدل‌های خارجی جدی‌تر می‌شود
وقتی مدل در همان حوزه قضایی توسعه یافته باشد، تنظیم‌گر معمولاً ابزارهای بیشتری در اختیار دارد؛ اما در مدل خارجی وضعیت پیچیده‌تر می‌شود.
مدل ممکن است از طریق API ارائه شود، وزن آن قابل دریافت نباشد و سازنده نیز حضور حقوقی محدودی در کشور استفاده‌کننده داشته باشد. ممکن است حتی مشخص نباشد نسخه مدل پشت API دقیقاً چه زمانی عوض شده است.
در چنین وضعیتی، الزام «Source Code را تحویل دهید» هم از نظر تجاری غیرواقع‌بینانه است و هم ممکن است برای ارزیابی کافی نباشد.
اما همچنان می‌توان قواعد دیگری تعریف کرد: ارائه مستندات مشخص، اعلام تغییر نسخه، دسترسی به نتایج آزمون، امکان ارزیابی API، ثبت رخداد، شرایط نگهداری داده، Audit Log، اعلام Subprocessorها و حق توقف استفاده در صورت عدم ارائه شواهد کافی.
این همان چیزی است که در یادداشت قراردادهای هوش مصنوعی اهمیت داشت. اگر سامانه‌ای بر مدل خارجی متکی است، بخشی از حاکمیت باید در قرارداد، معماری و حق آزمون ساخته شود، نه در رؤیای مالکیت کامل بر فناوری.
مسئله ایران نیز دقیقاً «دیدن سورس» نیست
با شکل‌گیری ساختارهای جدید حکمرانی AI در ایران، یکی از پرسش‌های مهم این خواهد بود که نهادهای مسئول ارزیابی و تنظیم‌گری چه اختیاراتی برای سامانه‌هایی دارند که مدل پایه آن‌ها در اختیار یک شرکت خارجی یا حتی یک تأمین‌کننده داخلی مستقل است.
اگر قانون صرفاً بگوید «سامانه باید ارزیابی شود»، هنوز مشخص نیست ارائه‌دهنده دقیقاً موظف به ارائه چه چیزی است.
آیا مرکز ارزیابی می‌تواند مستندات فنی را مطالبه کند؟ نتایج آزمون و Red Teaming چطور؟ آیا حق دارد آزمون مستقلی روی API انجام دهد؟ آیا تغییر نسخه مدل باید اعلام شود؟ اگر شرکت از ارائه شواهد کافی خودداری کرد، چه اتفاقی می‌افتد؟ و در کدام نقطه دسترسی به Weight یا Source Code واقعاً ضروری می‌شود؟
این پرسش‌ها از بحث مالکیت مهم‌ترند.
ممکن است ایران هیچ‌گاه مالک برخی مدل‌های مورد استفاده در کشور نباشد؛ همان‌طور که بسیاری از کشورها مالک فناوری‌های نرم‌افزاری و صنعتی مورد استفاده خود نیستند. مسئله اصلی این است که آیا حق و ظرفیت لازم برای ارزیابی اثر آن‌ها وجود دارد یا نه.
حاکمیت فناورانه را نمی‌توان فقط به ساخت همه چیز در داخل تقلیل داد.
بخشی از حاکمیت، توانایی تنظیم فناوری‌ای است که خودمان نساخته‌ایم.
از مالکیت کد تا مالکیت تصمیم
اگر بخواهیم مسئله را خلاصه کنیم، شاید سؤال «آیا تنظیم‌گر باید کد منبع را ببیند؟» از ابتدا سؤال دقیقی نباشد.
سؤال بهتر این است:
تنظیم‌گر برای تصمیم مسئولانه درباره اجازه استفاده از یک سامانه، به چه شواهدی نیاز دارد؟
در یک مورد ممکن است مستندات و نتیجه آزمون کافی باشند. در مورد دیگر API آزمایشی یا لاگ لازم باشد. در سامانه بسیار پرریسک شاید دسترسی به مدل، پارامترها یا حتی کد ضرورت پیدا کند.
نقطه تعیین‌کننده، تناسب میان ریسک و عمق دسترسی است.
از این منظر، حکمرانی AI بیشتر از آنکه به «مالکیت کد» وابسته باشد، به مالکیت فرایند تصمیم وابسته است: اینکه تنظیم‌گر بتواند بدون اتکا به ادعای سازنده، شواهد را ببیند، مستقلاً آزمون کند و در نهایت درباره پذیرش یا محدودیت سامانه تصمیم بگیرد.
در مجموعه هوش مصنوعی بدون اعتماد اصل محوری این بود که اعتماد باید با شواهد ساخته شود، نه با موقعیت یا ادعا. همان منطق در سطح حکمرانی نیز برقرار است.
یک مدل خارجی، اختصاصی یا محرمانه الزاماً غیرقابل حکمرانی نیست.
مشکل از جایی آغاز می‌شود که «محرمانه بودن» به معنای غیرقابل راستی‌آزمایی بودن تعبیر شود.
و شاید مهم‌ترین حقی که تنظیم‌گر در عصر AI نیاز دارد نه حق مالکیت بر کد، بلکه حق مطالبه شواهد کافی برای نپذیرفتن اعتماد بدون اثبات باشد.