مهندسی سامانه‌های هوش مصنوعی · فصل ۴ — Model Artifacts، Transfer، License، Scheduler و Device Telemetry · 146
Model License Policy
می‌تواند مدل یا ابزار AI را فراخوانی کند اما contract، qualification، routing، cost، trust و failure را کنترل نمی‌کند. موضوع جاری: «Model License Policy». می‌تواند «Model License Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
خلاصهٔ درس
می‌تواند مدل یا ابزار AI را فراخوانی کند اما contract، qualification، routing، cost، trust و failure را کنترل نمی‌کند. موضوع جاری: «Model License Policy».
می‌تواند «Model License Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
خروجی این درس
می‌تواند «Model License Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
1. مسئله واقعی: «قابل دانلود» با «مجاز برای use case ما» یکی نیست
فرض کنید سه artifact مدل برای یک دستیار تجاری داخلی داریم. A با digest دقیق sha256:MODEL-A از revision مشخص آمده و model card آن license: apache-2.0 دارد؛ B با license: other و یک license_name و license_link سفارشی منتشر شده؛ C در یک mirror داخلی کپی شده ولی مرجع license آن همراه artifact حفظ نشده است. اینکه هر سه فایل دانلود می‌شوند یا inference می‌دهند هیچ تصمیم مجوزی را ثابت نمی‌کند. artifact مالک این درس Model Artifact License Decision & Provenance Record v1 است.
2. مرز درس: policy gate مهندسی، نه مشاوره حقوقی
AIE-015 باید evidence را جمع و bind کند، نه اینکه متن مبهم مجوز را به‌جای حقوق‌دان تفسیر کند. تصمیم‌های این درس ALLOW، BLOCK و REVIEW_REQUIRED فقط برای یک use case و policy oracle اعلام‌شده معتبرند. BLOCK یعنی مسیر خودکار محصول تحت policy فعلی نباید ادامه دهد؛ این واژه الزاماً به معنی «غیرقانونی بودن» نیست. هر ambiguity، custom term یا conflict که oracle صریح پوشش نداده باید به human review برسد.
3. تصمیم را به identity دقیق artifact گره بزنید
Friendly name مثل model-x-latest برای تصمیم قابل ممیزی کافی نیست. حداقل artifact_digest، source_revision و source repository/reference را نگه دارید. اگر upstream revision عوض شود یا digest جدیدی وارد شود، تصمیم قبلی برای artifact قبلی تاریخی می‌ماند و به artifact جدید منتقل نمی‌شود؛ حتی اگر نام نمایشی همان باشد.
4. license metadata evidence است، نه authorization oracle
Repository metadata برای discovery و provenance بسیار مفید است. در Hugging Face می‌توان license را در metadata model card ثبت کرد و برای license سفارشی از license: other همراه license_name و license_link استفاده کرد. اما label به‌تنهایی همه dependencyها، datasetها، adapterها، noticeها یا شرایط use case شما را پوشش نمی‌دهد. تصمیم نهایی باید به evidence کامل‌تر و policy version متصل باشد.
5. SPDX برای normalization است، نه برای صدور اجازه
SPDX License List شناسه‌های کوتاه استاندارد و license expressionهایی مثل MIT OR Apache-2.0 را برای بیان ماشینی اطلاعات مجوز تعریف می‌کند. این normalization کمک می‌کند سیستم بداند درباره کدام license identifier صحبت می‌کند و ambiguity نام‌ها کمتر شود. اما SPDX ID به‌خودی‌خود نمی‌گوید use case تجاری، redistribution یا hosting شما مجاز است؛ این نتیجه باید از authority/policy مناسب بیاید.
6. standard، custom، unknown و conflicting را جدا نگه دارید
چهار حالت evidence را یکی نکنید. STANDARD یعنی metadata به یک identifier/expression قابل normalize اشاره می‌کند؛ CUSTOM یعنی متن/نام سفارشی است؛ UNKNOWN یعنی evidence لازم نداریم؛ CONFLICT یعنی دو provenance معتبر ادعاهای ناسازگار دارند. فقط STANDARD بودن نیز به‌معنی ALLOW نیست. Custom/unknown/conflict باید طبق policy به REVIEW_REQUIRED یا block خودکار برود.
7. license text/reference provenance را همراه metadata ثبت کنید
برای تصمیم قابل بازتولید، تنها license=... کافی نیست. تا جای ممکن reference متن license، link، file path داخل repo یا snapshot/ref مشخص را ثبت کنید. اگر artifact در mirror منتقل شده است، باید بتوان نشان داد license reference از کجا آمده و آیا به همان source revision مربوط است. filename مشترک یا README جدیدتر نباید به artifact قدیمی نسبت داده شود.
8. use case را explicit و versioned کنید
Policy gate بدون use case بی‌معنی است. رکورد باید روشن کند سؤال چیست: internal commercial hosting؟ redistribution وزن‌ها؟ modification؟ ارائه API؟ attribution/notice obligation؟ تصمیم ALLOW باید دقیقاً به همان scope محدود شود. اگر use case بعداً از internal hosting به redistribution تغییر کرد، تصمیم باید دوباره evaluate شود حتی اگر artifact digest ثابت مانده باشد.
9. policy oracle را از license metadata جدا نگه دارید
در Lab، یک synthetic policy oracle صریح داریم. این oracle از قبل می‌گوید برای artifact/evidence مشخص و use case اعلام‌شده چه automation outcome مجاز است. evaluator حق ندارد از اسم Apache-2.0 یا هر identifier دیگری permission حقوقی استنباط کند. اگر oracle یک use case را پوشش ندهد، نتیجه REVIEW_REQUIRED است؛ اگر oracle صریح deny کند، مسیر خودکار BLOCK می‌شود.
10. Decision سه‌حالته را دقیق تعریف کنید
ALLOW یعنی evidence لازم برای همان digest/revision/use-case/policy-version حاضر است و synthetic/approved policy oracle اجازه ادامه خودکار را داده است. BLOCK یعنی یک rule صریح policy یا فقدان decisive evidence تحت policy جاری مسیر خودکار را می‌بندد. REVIEW_REQUIRED یعنی custom، unknown، stale، conflicting یا خارج‌از-scope داریم و انسان صاحب authority باید تصمیم بگیرد. هیچ‌کدام claim حقوقی جهانی نیستند.
11. conflict را با انتخاب «رکورد راحت‌تر» حل نکنید
اگر model card یک license نشان می‌دهد اما mirror provenance یا preserved license text چیز دیگری می‌گوید، سیستم نباید یکی را ساکت حذف کند. CONFLICT باید در decision record باقی بماند، automation متوقف شود و exact evidence برای review ارائه شود. همین قاعده درباره source revision نامشخص یا دو link متفاوت به متن license نیز صدق می‌کند.
12. freshness و recheck trigger بخشی از policy contract هستند
License metadata و source revision ممکن است تغییر کنند؛ policy داخلی هم version دارد. تصمیم باید policy_version، زمان/مرجع capture evidence و trigger بازبینی را ثبت کند. triggerهای معمول: digest یا source revision جدید، تغییر metadata/license link، policy جدید، use case جدید، conflict تازه، یا review due. history قدیمی overwrite نمی‌شود؛ تصمیم جدید کنار تصمیم تاریخی ثبت می‌شود.
13. provenance زنجیره تصمیم را قابل audit می‌کند
رکورد خوب نشان می‌دهد: artifact چه بود، metadata از کجا capture شد، آیا identifier normalize شد، text/reference چه بود، use case چه بود، کدام policy version اجرا شد، چه ruleی outcome را ساخت و human review لازم بود یا نه. downstream فقط باید به همین bounded decision تکیه کند و نباید ALLOW را به «هر استفاده‌ای مجاز است» گسترش دهد.
14. Lab: هشت fixture برای شکستن shortcutهای رایج
Case 1 baseline است و artifact استاندارد فقط چون oracle همان use case را صریحاً allow کرده ALLOW می‌شود. Case 2 custom license را REVIEW_REQUIRED نگه می‌دارد. Case 3 mirror بدون license provenance مسیر خودکار را BLOCK می‌کند. Case 4 نشان می‌دهد revision/digest جدید با همان friendly name تصمیم قبلی را به ارث نمی‌برد. Case 5 conflict را escalate می‌کند؛ Case 6 deny صریح policy را block می‌کند؛ Case 7 policy/evidence stale را review می‌برد؛ Case 8 ثابت می‌کند old decision برای digest دیگر قابل reuse نیست.
15. Transfer و چک‌لیست نهایی
در transfer، artifact A با revision جدید جایگزین می‌شود و license metadata از standard identifier به other تغییر می‌کند. تصمیم تاریخی artifact قبلی را نگه دارید، اما برای digest جدید evaluation تازه لازم است و outcome خودکار به REVIEW_REQUIRED می‌رود. چک‌لیست: exact digest و revision؛ captured metadata؛ SPDX normalization فقط در صورت معتبر بودن؛ custom name/link/text provenance؛ use case دقیق؛ policy version؛ evidence state؛ ALLOW/BLOCK/REVIEW_REQUIRED محدود؛ human-review flag؛ decision scope؛ non-claims؛ و recheck trigger. این درس هیچ permission حقوقی اختراع نمی‌کند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1
Why is an SPDX identifier or repository license label insufficient by itself to issue ALLOW?
Q2
When must a license decision become REVIEW_REQUIRED?
Q3
Why can a historical ALLOW not automatically transfer to a new digest with the same friendly model name?
Q4
What does BLOCK mean in this engineering lesson?
ملاک‌های ارزیابی (rubric)
Blocking dimensions: exact artifact/source binding; license metadata/text/reference provenance; standard versus custom/unknown/conflicting/stale evidence; explicit use case and policy version; bounded ALLOW/BLOCK/REVIEW_REQUIRED; no invented legal permission; historical decision preservation; and changed-context re-evaluation. A submission fails if a repository label or SPDX identifier is treated as a universal permission oracle, ambiguity is silently converted to ALLOW, provenance is missing, or a decision bound to an old digest is reused for a new artifact.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Implement evaluate_license(case) in starter.py. Bind every decision to the exact artifact digest/source revision, preserve license metadata and text/reference provenance, normalize standard identifiers only as evidence, and apply only the supplied synthetic policy oracle for the declared use case. Custom, unknown, conflicting, or stale evidence must not become invented permission. Emit one bounded result: ALLOW, BLOCK, or REVIEW_REQUIRED.
Run python run_checks.py to verify that all eight learner fixtures are structurally ready. Hidden evaluation checks deterministic outcomes. This lab is not legal advice and uses synthetic policy rules.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)