تصور کنید لایسنس‌های گران‌قیمت هوش مصنوعی را خریده‌اید و حالا تصور می‌کنید امنیت کدهای حساس شما تضمین شده است؛ اما حقیقت این است که دسترسی کاربر به ابزار، به معنای کنترل او بر محتوای کد نیست. اگر فکر می‌کنید با پرداخت هزینه به GitHub، تمام قوانین استفاده از AI در سازمان شما به‌طور خودکار اعمال شده است، با یک ریسک امنیتی جدی روبه‌رو هستید.
آیا خرید لایسنس GitHub Copilot Business به‌طور خودکار تعیین می‌کند که کدام کدبیس‌ها اجازه تولید پیشنهاد (Suggestion) دارند؟ در حالی که فرآیند خرید بسیار ساده است — یعنی خرید صندلی‌ها و تخصیص آن‌ها به کارکنان از طریق یک ماشین‌حساب قیمت‌گذاری و دکمه پرداخت — این موضوع تنها جنبه‌های مالی و دسترسی را حل می‌کند. در مدل Copilot Business، یک صندلی به یک حساب کاربری خاص اختصاص می‌یابد، نه به یک مخزن (Repository) یا طبقه‌بندی مشخصی از کدها. در نتیجه، متمرکز کردن خرید لایسنس‌ها به‌طور ذاتی هیچ رژیم استفاده‌ای برای کل کدبیس تیم ایجاد نمی‌کند. برای مدیریت مؤثر، سازمان‌ها باید بین سه اقدام مجزا تفاوت قائل شوند: خرید اشتراک، تخصیص صندلی‌ها و تأیید سیاست‌های کاربردی.
یک باور غلط رایج وجود دارد که پس از توزیع صندلی‌ها، قوانین استفاده به‌طور خودکار تنظیم می‌شوند. این فرض خطرناک است. تخصیص صندلی صرفاً یک وظیفه اداری است؛ مالکان سازمان می‌توانند در هر لحظه از چرخه صورت‌حساب، صندلی‌ها را اضافه یا حذف کنند. چه صندلی‌ها به‌صورت فردی اختصاص یابند و چه به کل تیم‌های گیت‌هاب از طریق بخش «Users and teams» یا APIهای REST، این تخصیص تنها به کاربر حق استفاده از ابزار را می‌دهد. این کار مرزهای کاربرد ابزار را تعریف نمی‌کند. گیت‌هاب مفهومی به نام «کلاس مخزن» (Repository Class) در تنظیمات صورت‌حساب یا سیاست‌های خود ندارد. به همین دلیل، ایجاد یک ماتریس دسترسی بر اساس کلاس‌های کد — شامل مالکان، توجیهات و تاریخ‌های بازبینی — یک لایه مهندسی است که باید توسط سازمان روی زیرساخت‌های پایه گیت‌هاب پیاده‌سازی شود، چرا که این یک ویژگی داخلی محصول نیست.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ابزارهای بهره‌وری بدون لایه‌های نظارتی تبدیل به حفره‌های امنیتی می‌شوند. برای پیاده‌سازی یک مدل حاکمیتی مستحکم، سازمان‌ها باید ابتدا مخازن خود را بر اساس ریسک دسته‌بندی کنند. برای مثال، یک مخزن «عمومی» (Public) می‌تواند سیاست باز داشته باشد، اما یک مخزن «مالکیت محرمانه هسته» (Core Proprietary) باید محدودیت‌های شدیدی در نحوه ادغام کدهای تولید شده توسط AI داشته باشد. از آنجا که گیت‌هاب گزینه‌ای برای «غیرفعال کردن کوپایلت برای مخزن X» در سطح سازمان برای کاربران خاص ارائه نمی‌دهد، مکانیزم کنترل به ترکیبی از تنظیمات سازمانی و دستورالعمل‌های توسعه‌دهنده تغییر می‌کند.
تنظیمات Copilot Business به مدیران اجازه می‌دهد کنترل کنند که آیا مدل می‌تواند کدهایی را پیشنهاد دهد که با کدهای عمومی گیت‌هاب مطابقت دارند یا خیر، اما این یک سوئیچ جهانی (Global Toggle) برای کل سازمان است، نه تنظیمی برای هر مخزن به‌صورت جداگانه. این بدان معناست که اگر قوانین متفاوتی برای پروژه‌های مختلف می‌خواهید، نمی‌توانید تنها به یک کلید در منوی تنظیمات تکیه کنید. این شکاف بین خرید لایسنس و اجرای سیاست‌ها، یک «خلاء حاکمیتی» ایجاد می‌کند. اگر توسعه‌دهنده‌ای صندلی کوپایلت داشته باشد، از نظر فنی می‌تواند از آن در هر مخزنی که به آن دسترسی دارد استفاده کند.
برای کاهش این ریسک، شرکت‌ها باید یک «دفتر ثبت دسترسی به مخازن» (Repository Access Registry) ایجاد کنند. این دفتر به عنوان منبع حقیقت (Source of Truth) عمل کرده و هر مخزن را به یک سطح ریسک و سیاست استفاده متناظر متصل می‌کند. به عنوان مثال، در مخازن «پرریسک» (High Risk)، سیاست سازمان باید بازبینی دستی (Peer Review) برای هر بلوک کد پیشنهادی AI را اجباری کند تا از نشت الگوهای حساس یا ورود کدهای ناامن جلوگیری شود. در مقابل، در مخازن «کم‌ریسک» (Low Risk)، سیاست‌ها می‌توانند منعطف‌تر و بازتر باشند. با مستندسازی این الزامات در یک دفتر ثبت، سازمان یک «سیاست AI» مبهم را به یک استاندارد مهندسی قابل راستی‌آزمایی تبدیل می‌کند.
علاوه بر این، پیاده‌سازی فنی این سیاست‌ها نیازمند تغییر دیدگاه است. مدیران نباید به دنبال یک «دکمه سیاست» در رابط کاربری گیت‌هاب باشند، بلکه باید بر تنظیمات مربوط به تله‌متری و حریم خصوصی داده‌ها در بخش Copilot for Business تمرکز کنند. غیرفعال کردن گزینه «اجازه به گیت‌هاب برای استفاده از کد من جهت بهبود محصول» (Allow GitHub to use my code for product improvement) اولین گام حیاتی در حفاظت از مالکیت معنوی است. با این حال، این یک اقدام کلی است. کنترل‌های دقیق‌تر — مانند تصمیم‌گیری درباره اینکه آیا کوپایلت باید برای یک ماژول قدیمی (Legacy) استفاده شود یا یک پروژه جدید (Greenfield) — همچنان یک فرآیند مدیریت انسانی است.
توصیه می‌شود که دفتر ثبت دسترسی به مخازن در خط لوله CI/CD یا قالب‌های PR (Pull Request) ادغام شود. با افزودن یک چک‌باکس به قالب PR با این پرسش که «آیا از کوپایلت برای این تغییر استفاده شده است؟ و اگر بله، آیا با کلاس ریسک مخزن مطابقت دارد؟»، سازمان یک ردپای پاسخگویی (Trail of Accountability) ایجاد می‌کند. این روش تضمین می‌کند که هر تغییر در کد، به‌ویژه زمانی که توسط AI تولید شده، از فیلتر تأییدیه سازمان عبور کرده باشد.
لایه دیگری از پیچیدگی هنگام مواجهه با پیمانکاران شخص ثالث ایجاد می‌شود. وقتی صندلی‌ها به همکاران خارجی اختصاص می‌یابد، پروفایل ریسک تغییر می‌کند. یک پیمانکار ممکن است به چندین مخزن مشتری دسترسی داشته باشد و اگر سازمان به او صندلی کوپایلت بدهد، آن پیمانکار می‌تواند از AI در تمام آن پروژه‌ها استفاده کند. برای جلوگیری از تداخل منطق‌ها یا نشت تصادفی الگوهای محرمانه در بستر (Context) مدل، سازمان‌ها باید تخصیص صندلی‌ها را به‌شدت به کارکنان داخلی محدود کنند یا از سازمان‌های گیت‌هاب بسیار محدود و مجزا برای پیمانکاران استفاده نمایند. این کار تضمین می‌کند که «شعاع انفجار» (Blast Radius) یک دستیار AI در محدوده مرز امنیتی مناسب مهار شود و دسترسی‌های گسترده پیمانکاران به ابزارهای هوش مصنوعی منجر به خروج داده‌های حساس نشود.
به طور خلاصه، خرید Copilot Business ساده‌ترین بخش مسیر است. کار واقعی در طراحی معماری سیاست‌های استفاده نهفته است. سازمان‌ها باید از حالت دوتایی «فعال» یا «غیرفعال» فاصله بگیرند و یک ماتریس دقیق از مجوزها بسازند. این مسیر شامل نگاشت کاربران به صندلی‌ها، صندلی‌ها به مخازن و مخازن به سطوح ریسک است. این رویکرد سیستماتیک اجازه می‌دهد تا بهره‌وری افزایش یابد بدون اینکه کنترل روی کیفیت و امنیت کد از دست برود.
با تبدیل حاکمیت AI به یک مسئله مهندسی — همراه با دفتر ثبت، چرخه بازبینی و فرآیند تأیید — شرکت‌ها می‌توانند از افزایش بهره‌وری بهره‌مند شوند بدون اینکه امنیت یا مالکیت معنوی خود را به خطر بیندازند. هدف، حرکت از «استفاده تصادفی» به «کاربرد آگاهانه» است، جایی که هر خط کد پیشنهادی تحت نظارت یک سیاست مستند باشد که با تکامل پروژه، بازبینی و به‌روزرسانی شود. این رویکرد تضمین می‌کند که ابزار در خدمت اهداف تجاری باشد، بدون اینکه ریسک‌های مدیریت‌نشده‌ای را وارد کدبیس کند. در نهایت، مدیریت هوش مصنوعی در سازمان نباید یک تصمیم مدیریتی ساده باشد، بلکه باید به عنوان بخشی از استراتژی مدیریت ریسک نرم‌افزاری دیده شود.
گام بعدی شما
- ایجاد یک دفتر ثبت دسترسی (Registry) برای دسته‌بندی مخازن بر اساس سطح ریسک (کم، متوسط، زیاد).
- غیرفعال کردن گزینه استفاده از داده‌ها برای بهبود محصول در تنظیمات سازمانی Copilot Business.
- افزودن پرسش‌های تأییدی درباره استفاده از AI به قالب‌های Pull Request برای ایجاد ردپای نظارتی.
اما مدیریت دسترسی‌ها تنها بخشی از معماری امنیت است؛ برای درک چگونگی کنترل جریان داده‌ها در مدل‌های زبانی، به تحلیل ما درباره پروتکل MCP مراجعه کنید.
گفتگو