تصور کنید یک عامل هوش مصنوعی دسترسی کامل به کدبیس تولیدی شما داشته باشد اما هیچ درکی از استانداردهای امنیتی شرکتتان نداشته باشد؛ این یعنی تبدیل یک دارایی به یک ریسک بزرگ. در ۲۹ اوت ۲۰۲۶، چارچوب NAEOS (سیستم‌عامل مهندسی هوش مصنوعی نوسانتارا) توضیح داد که چرا مهندسی نرم‌افزار خودگردان نیازمند گذار از دستورات مبتنی بر پرامپت به یک «قانون اساسی مهندسی» ساختاریافته و ماشین‌خوان است.
همان‌طور که در تحلیل قبلی ما درباره‌ی جایگزینی پرامپت‌های موقت با قراردادهای متنی اشاره کردیم، صنعت اکنون به این نتیجه رسیده است که «دانش ضمنی» — همان قواعد نانوشته‌ای که مهندسان ارشد برای جلوگیری از فروپاشی سیستم‌ها به کار می‌برند — توسط یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — قابل ارث‌بری نیست. طبق اعلام NAEOS، یک مدل ممکن است بداند OAuth یا mTLS چیست، اما نمی‌داند سازمان شما کدام‌یک را برای سرویس‌های داخلی اجباری کرده است، مگر اینکه این سیاست صراحتاً کدگذاری شده باشد.
شکاف میان هوش و قضاوت
هوش خام به مدل اجازه می‌دهد کدهای خیره‌کننده‌ای بنویسد، اما مهندسی نرم‌افزار در واقع تعریفِ «محدودیت‌ها» است. به گزارش dev.to، هوش با قضاوت مهندسی متفاوت است. قضاوت یعنی پاسخ به پرسش‌های حیاتی سازمانی:
- کدام فناوری‌های پایگاه‌داده تأیید شده‌اند؟
- چه تغییری «تغییر شکست‌دهنده» (Breaking Change) محسوب می‌شود؟
- چه کسی صلاحیت تأیید یک تغییر معماری را دارد؟
- کدام اجزا نباید با هم ارتباط داشته باشند؟
- چه الگوهای API اجباری هستند؟
- چه مدل امنیتی اعمال می‌شود و چه میزان پوشش تست لازم است؟
انسان‌ها این مسائل را از طریق استانداردها و فرآیندهای بازبینی حل می‌کنند، اما عامل‌های هوش مصنوعی فاقد این بستر فرهنگی هستند. بدون یک قانون اساسی، عامل ممکن است کتابخانه‌ای را انتخاب کند که از نظر فنی درست اما از نظر سازمانی ممنوع است و باعث ایجاد بدهی فنی (Technical Debt) عظیم شود. این چالش دقیقاً همان نقطه‌ای است که برخی قوانین کلیدی مهندسی برای تبدیل عامل‌ها به ابزارهای قابل‌اعتماد را تعریف می‌کنند تا ریسک‌های عملیاتی کاهش یابد. برای مثال، مدل ممکن است روش‌های مختلف احراز هویت را بداند، اما نمی‌داند سازمان شما OAuth 2.1 را برای APIهای خارجی و mTLS را برای ارتباطات سرویس-به-سرویس الزامی کرده است.
سلسله‌مراتب حاکمیت
NAEOS برای جلوگیری از تبدیل شدن قانون اساسی به یک فایل تنظیمات حجیم، سلسله‌مراتبی سخت‌گیرانه پیشنهاد می‌دهد که از اصول انتزاعی به اجرای عینی می‌رسد:
۱. قانون اساسی مهندسی: اصول سطح بالا و غیرقابل مذاکره.
۲. استانداردهای معماری: الگوهای طراحی خاص.
۳. سیاست‌های مهندسی: قواعد عملیاتی شده.
۴. استانداردهای پروژه: الزامات محلی.
۵. گردش‌های کاری: مکانیزم‌های اجرایی.
۶. پیاده‌سازی: کد نهایی تولید شده توسط عامل.
این ساختار تضمین می‌کند که قانون اساسی، اصول پایدار را تعریف کند نه لیستی از دستورالعمل‌های اجرایی. مثلاً یک اصل می‌گوید «سیستم‌های تولیدی باید مشاهده‌پذیر باشند». سپس سیاست پیاده‌سازی، الزاماتی مثل لاگ‌های ساختاریافته و بررسی‌های سلامت (Health Checks) را تعریف می‌کند و در نهایت، گردش کار (Workflow) حکم می‌کند که هیچ استقراری بدون تأیید این موارد رخ ندهد.
قوانین اساسی متمرکز بر دامنه
برای مدیریت پیچیدگی، این چارچوب قانون اساسی را به دامنه‌های تخصصی تقسیم می‌کند:
- قانون اساسی معماری: حفظ مرزهای دامنه و نسخه‌بندی رابط‌های عمومی.
- قانون اساسی امنیت: ممنوعیت ورود اسرار (Secrets) به کنترل نسخه و اجرای اصل «حداقل دسترسی».
- قانون اساسی هوش مصنوعی: تعریف مرزهای خودِ عامل‌ها.
- قوانین تست، مستندات و API: استانداردهای کیفیت و طراحی رابط.
- قوانین زیرساخت، داده و قابلیت اطمینان: حاکمیت بر محیط عملیاتی.
- قانون اساسی حاکمیت: مدیریت کلی قواعد سیستم.
در بخش امنیت، اصول غیرقابل مذاکره‌ای تعریف شده است؛ مثلاً دسترسی به محیط تولید باید قابل حسابرسی باشد و کنترل‌های امنیتی نباید برای راحتیِ کار دور زده شوند. این سیستم صراحتاً «توانایی» را از «اجازه» جدا می‌کند؛ اینکه یک عامل از نظر فنی بتواند یک رمز را بخواند، به معنای داشتن اجازه برای این کار نیست.
قانون اساسی AI و سطوح خودمختاری
یکی از حیاتی‌ترین بخش‌ها، قانون اساسی AI است که مرزهای عامل‌ها، دسترسی به ابزارها، دانش و الزامات تأیید انسانی را تعریف می‌کند. NAEOS یک مدل خودمختاری لایه‌بندی شده برای مدیریت ریسک پیشنهاد می‌دهد:
- سطح ۰: تحلیل فقط-خواندنی.
- سطح ۱: تولید تغییرات پیشنهادی.
- سطح ۲: تغییر در محیط توسعه.
- سطح ۳: اجرای گردش‌های کاری تأیید شده.
- سطح ۴: استقرار کنترل‌شده.
- سطح ۵: عملیات خودگردان در محیط تولید.
این سطوح به‌صورت سراسری اعطا نمی‌شوند، بلکه به ریسک تسک، هویت عامل و نتایج اعتبارسنجی بستگی دارند.
امنیت مبتنی بر قابلیت
به جای اعطای دسترسی گسترده به مخزن کد، سیستم با قابلیت‌های عامل به عنوان مجوزهای صریح برخورد می‌کند. مثلاً عاملی ممکن است اجازه repository.read داشته باشد اما بدون تیکت تأیید شده توسط انسان و اسکن امنیتی موفق، از deployment.execute در محیط تولید منع شود.
قابلیت‌ها با شرایط خاص تعریف می‌شوند. اجرای استقرار در محیط Staging ممکن است فقط به یک بیلد تأیید شده نیاز داشته باشد، اما همان قابلیت در محیط Production نیازمند تیکت تغییر، اعتبارسنجی امنیتی و پنجره زمانی مشخص برای استقرار است.
حل تضادهای سیاستی
مهندسی مبتنی بر پرامپت در مقیاس بالا شکست می‌خورد چون نمی‌تواند تضاد دستورات را حل کند. تصور کنید پرامپت توسعه‌دهنده می‌گوید «از کتابخانه X استفاده کن»، اما سیاست امنیتی آن را ممنوع کرده است.
در مدل NAEOS، سلسله‌مراتب برای جلوگیری از غلبه قضاوت مدل بر ایمنی، مطلق است:
سیاست امنیتی $\uparrow$ سیاست پروژه $\uparrow$ دستور توسعه‌دهنده $\uparrow$ پرامپت کاربر.
در نهایت، سیستم از این ریشه پیروی می‌کند: قانون اساسی > سیاست سازمانی > سیاست دامنه > سیاست پروژه > تنظیمات محلی.
صفحه کنترل مهندسی (Control Plane)
این رویکرد، حاکمیت را به یک سیستم زمان-اجرا (Runtime) تبدیل می‌کند. وقتی عاملی درخواست نوشتن در پایگاه‌داده تولید را می‌دهد، موتور سیاست‌ها هویت عامل، محیط، منبع و سطح ریسک را ارزیابی کرده و پاسخ دوگانه «اجازه/عدم اجازه» یا «ارجاع به انسان» می‌دهد.
این چرخه به این شکل است: قصد انسان $\rightarrow$ حاکمیت $\rightarrow$ قانون اساسی $\rightarrow$ دانش $\rightarrow$ برنامه $\rightarrow$ اجرای AI $\rightarrow$ اعتبارسنجی $\rightarrow$ نتیجه $\rightarrow$ حافظه.
این صفحه کنترل شامل سه بخش است:
- کامپایلر و رانتایم سیاست: تبدیل قانون اساسی به چک‌های زمان-اجرا.
- سیستم دانش: اتصال عامل به دانش دامنه و بستر پروژه.
- اعتبارسنجی/حسابرسی: تضمین ثبت هر اقدام و عدم دور زدن گیت‌های مهندسی.
تغییر نقش انسان در چرخه
حاکمیت به معنای تأیید هر خط کد توسط انسان نیست، بلکه مداخله متناسب با ریسک است:
- ریسک پایین (بدون تأیید): خواندن کد یا تولید تست.
- ریسک متوسط (بازبینی): تغییر در معماری.
- ریسک بالا (تأیید): تغییر سیاست‌های امنیتی یا زیرساخت تولید.
- ریسک بحرانی (تأیید اجباری): تغییر رمزهای دسترسی تولید.
این رویکرد پاسخ به نارضایتی مهندسانی است که احساس می‌کنند نقششان از حل مسئله به مدیریت ابزارهای AI تبدیل شده است. با کدگذاری «قضاوت مهندس ارشد» در یک قانون اساسی، نقش انسان از نظارت خسته‌کننده به تعریف قصد و حاکمیت سطح بالا تغییر می‌کند.
گام بعدی شما
- ظهور زبان‌های «سیاست-به-عنوان-کد» (Policy-as-Code) را دنبال کنید که احتمالاً استاندارد تعریف این قوانین اساسی خواهند بود.
- سعی کنید قواعد نانوشته تیم خود را به صورت Declarative (اظهاری) لیست کنید تا برای آینده آماده شوید.
- مدل‌های خودمختاری لایه‌بندی شده را در گردش‌های کاری کوچک خود پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو