بررسی قرارداد با تأمینکنندهی هوش مصنوعی: ۱۰ بندی که نباید جا بیفتد
قرارداد خرید یا اشتراک ابزار هوش مصنوعی را پیش از امضا با این چکلیست بررسی کنید: استفاده از داده برای آموزش، نگهداری و حذف، مسئولیت خطای مدل، تغییر مدل، ممیزی، مالکیت خروجی و خروج از قرارداد.
قراردادی که با تأمینکنندهی ابزار هوش مصنوعی امضا کردهاید را دوباره بخوانید. به احتمال زیاد، قرارداد یا «شرایط استفاده»ی استاندارد فروشنده است که با یک کلیک پذیرفته شده، یا یک قرارداد نرمافزاری معمولی که هیچ اشارهای به ویژگیهای خاص هوش مصنوعی ندارد: مدلی که ممکن است با دادهی شما آموزش ببیند، خروجیای که ممکن است اشتباه باشد و رفتاری که ممکن است بعد از یک بهروزرسانی عوض شود.
این راهنما ده بند کلیدی را مرور میکند که در قراردادهای هوش مصنوعی نباید جا بیفتد. برای طراحی آن از منابع رسمی مثل بندهای قراردادی نمونهی هوش مصنوعی اتحادیه اروپا (MCC-AI) و راهنمای خرید هوش مصنوعی دولت بریتانیا استفاده شده است. (برای سؤالهایی که پیش از مذاکره باید بپرسید، چکلیست ارزیابی پیش از خرید را ببینید.)
این مقاله آموزشی است و جایگزین بازبینی قرارداد توسط مشاور حقوقی نیست.
۱. استفاده از دادهی شما برای آموزش مدل
چه باید بنویسد: دادههای ورودی، خروجیها و فایلهای شما برای آموزش یا بهبود مدلهای تأمینکننده یا ارائه به مشتریان دیگر استفاده نمیشود، مگر با رضایت کتبی شما.
مراقب باشید: عبارتهایی مثل «برای بهبود خدمات» یا «دادههای ناشناسشده و تجمیعی» میتواند راه استفادهی گسترده را باز بگذارد.
۲. نگهداری، مکان و حذف داده
چه باید بنویسد: مدت نگهداری هر نوع داده (ورودی، خروجی، لاگ)، کشور یا منطقهی ذخیرهسازی، و حذف کامل ظرف مدت مشخص پس از پایان قرارداد، با امکان دریافت تأییدیهی حذف.
۳. زیرپیمانکاران و زنجیرهی مدل
بسیاری از ابزارهای AI روی مدل یک شرکت دیگر ساخته شدهاند. چه باید بنویسد: فهرست زیرپردازندهها (از جمله ارائهدهندهی مدل پایه و زیرساخت ابری)، الزام به اطلاعرسانی پیش از تغییر آنها، و انتقال همان تعهدات حفاظت داده به زیرپیمانکاران. اگر دادهی شخصی ساکنان اتحادیه اروپا پردازش میشود، این موارد بخشی از الزامات مادهی ۲۸ GDPR دربارهی قرارداد با پردازشگر است.
۴. تغییر مدل و اطلاعرسانی
رفتار ابزار هوش مصنوعی با تغییر مدل زیربنایی میتواند عوض شود؛ همان چیزی که در ماجرای چتبات DPD پس از یک بهروزرسانی رخ داد. چه باید بنویسد: اطلاعرسانی پیشاپیش دربارهی تغییرات مهم مدل یا قابلیتها، و در کاربردهای حساس، امکان آزمون پیش از اعمال تغییر.
۵. عملکرد و کیفیت
چه باید بنویسد: معیارهای عملکرد قابل سنجش برای کاربرد شما (دقت، زمان پاسخ، دسترسپذیری)، نحوهی سنجش و پیامد برآورده نشدن آنها. قراردادی که فقط «همانطور که هست» ارائه میدهد، هیچ ابزاری برای مطالبهی کیفیت به شما نمیدهد.
۶. مسئولیت خطای مدل و جبران خسارت
این همان بندی است که اکثر قراردادها عمداً مبهم میگذارند. چه باید بررسی شود:
- سقف مسئولیت تأمینکننده چقدر است و آیا با ریسک کاربرد شما تناسب دارد؟
- آیا نشت داده و نقض محرمانگی از سقف مسئولیت مستثنا شده است؟
- آیا تأمینکننده در برابر ادعای نقض مالکیت فکری ناشی از خروجی، تعهد جبران خسارت (Indemnity) دارد؟
در اروپا، دستورالعمل جدید مسئولیت محصول نرمافزار و هوش مصنوعی را «محصول» میداند و مادهی ۲۵ قانون هوش مصنوعی مسئولیتها را در طول زنجیرهی ارزش توزیع میکند؛ اینها پایهی خوبی برای مذاکرهاند.
۷. شفافیت، مستندات و همکاری در ممیزی
چه باید بنویسد: دسترسی به مستندات فنی کافی (هدف و محدودیتهای مدل، دادههای آموزشی در سطح کلی، نتایج آزمونها)، امکان دریافت لاگها و همکاری تأمینکننده در ممیزی یا درخواست نهاد ناظر. اگر سازمان شما در مسیر ISO/IEC 42001 است، این بند برای کنترلهای پیوست A.10 لازم است.
۸. امنیت و اطلاعرسانی رخداد
چه باید بنویسد: حداقل کنترلهای امنیتی، گواهیهای امنیتی موجود، و الزام به اطلاعرسانی رخداد امنیتی ظرف مدت مشخص (مثلاً ۲۴ تا ۷۲ ساعت) همراه با همکاری در بررسی.
۹. مالکیت خروجی و محتوای ورودی
چه باید بنویسد: ورودیهای شما متعلق به شما باقی میماند و حقوق تأمینکننده بر خروجیها (در حدی که قابل حمایتاند) به شما واگذار میشود. یادتان باشد ممکن است خروجی صرفاً ماشینی از نظر قانون کپیرایت قابل حمایت نباشد (کپیرایت محتوای هوش مصنوعی).
۱۰. خروج از قرارداد و تداوم کسبوکار
چه باید بنویسد: حق خروج در صورت تغییر اساسی شرایط یا نقض تعهدات، تحویل دادهها در قالب قابل استفاده، و دورهی انتقال. برای سازمانهای ایرانی که ممکن است با قطع ناگهانی دسترسی به سرویسهای خارجی روبهرو شوند، داشتن برنامهی جایگزین و امکان دریافت دادهها اهمیت دوچندان دارد.
یک جدول ساده برای بازبینی سریع
| بند | وضعیت در قرارداد فعلی | اقدام لازم |
|---|---|---|
| آموزش مدل با دادهی ما | ||
| نگهداری و حذف داده | ||
| زیرپیمانکاران | ||
| تغییر مدل | ||
| عملکرد و کیفیت | ||
| مسئولیت و جبران خسارت | ||
| مستندات و ممیزی | ||
| امنیت و رخداد | ||
| مالکیت خروجی | ||
| خروج و تداوم |
اگر قدرت مذاکره ندارید چه؟
با ارائهدهندگان بزرگ، اغلب امکان تغییر متن استاندارد وجود ندارد. در این صورت:
- سطح حساب را درست انتخاب کنید: شرایط حسابهای سازمانی معمولاً بسیار بهتر از حسابهای شخصی است.
- شرایط را مستند کنید: نسخهی شرایط استفاده در زمان امضا را نگه دارید.
- ریسک را با کاربرد مدیریت کنید: اگر نمیتوانید قرارداد را تغییر دهید، دادهها و کاربردهایی را که به آن ابزار میسپارید محدود کنید.
جمعبندی
در قرارداد هوش مصنوعی، هر چیزی که نوشته نشده، معمولاً به نفع فروشنده تفسیر میشود. بستن این ده شکاف پیش از امضا، ده برابر ارزانتر از حل اختلاف پس از رخداد است.
منابع
- European Commission — EU model contractual AI clauses (MCC-AI)
- UK Government — Guidelines for AI procurement
- GDPR — Article 28 (Processor)
- EU AI Act — Article 25 (Responsibilities along the AI value chain)
- Directive (EU) 2024/2853 on liability for defective products
- ISO/IEC 42001:2023 — Annex A.10 (Third-party and customer relationships)
- NIST AI RMF 1.0 — GOVERN 6 (Third-party risks)
این مطلب برایتان مفید بود؟
این موضوع در سازمان شما چه وضعیتی دارد؟
ارزیابی رایگان آمادگی، شکافها و اولویتهای سازمان را در ۱۰ دقیقه نشان میدهد.
ارزیابی رایگان سازمان
دیدگاهها (۰)
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید؛ سؤالها و تجربههای شما به بهتر شدن این مطلب کمک میکند.