یک پرامپت بهتر میتواند پاسخ بهتری تولید کند.
اما نمیتواند مرز عملیاتی تعریف کند.
این تفاوت از زمانی مهم میشود که سامانه هوش مصنوعی دیگر فقط نقش دستیار ندارد و میتواند عمل کند. وقتی یک عامل میتواند ابزار فراخوانی کند، وضعیت سامانه را تغییر دهد، هزینه ایجاد کند، درخواست ادغام کد باز کند، پیکربندی را عوض کند، خروجی قابلاستفاده بسازد یا عامل دیگری را به کار بیندازد، سازمان به چیزی محکمتر از چند جمله درباره «محتاط بودن» نیاز دارد.
این مقاله بخش پنجم از مجموعه دهقسمتی حاکمیت هوش مصنوعی در یک شرکت نرمافزاری AI-Native است. بخش چهارم، لایه سیاست اجرایی نشان داد که حاکمیت زمانی واقعی میشود که سیاست وارد مسیر اجرا شود. این بخش یک گام به خود عامل نزدیکتر میشود: عامل دقیقاً چه کاری را، در چه شرایطی، با چه ابزارهایی میتواند انجام دهد و اگر شرایط لازم برقرار نبود چه باید رخ دهد؟
پاسخ، قرارداد است.
پرامپت نیت را بیان میکند. قرارداد رفتار را مقید میکند.
پرامپت مرز کنترلی نیست
پرامپت به این دلیل مفید است که انعطافپذیر است.
همین ویژگی باعث میشود قرارداد ضعیفی باشد.
فرض کنید پرامپت میگوید:
«این استقرار را با دقت بررسی کن. تغییر پرریسک انجام نده. هر جا لازم بود تأیید بگیر.»
برای انسان، این جمله پر از معناهای ضمنی است. اما عامل باید در هر اجرا دوباره حدس بزند که این قواعد دقیقاً چه معنایی دارند.
چه چیزی پرریسک محسوب میشود؟
کدام محیط در محدوده مجاز است؟
کدام ابزارها قابل استفادهاند؟
پیش از تأیید چه شواهدی باید وجود داشته باشد؟
حد هزینه چقدر است؟
اگر شواهد ناقص بود چه اتفاقی باید بیفتد؟
چه کسی اجازه استثنا دارد؟
خروجی برای سامانه بعدی باید چه ساختاری داشته باشد؟
اگر مدل، تعریف ابزار یا محیط اجرا تغییر کرد چه میشود؟
پرامپت به این پرسشها پاسخ نمیدهد. فقط به آنها اشاره میکند.
برای یک دستیار کمریسک شاید کافی باشد. برای سامانهای که اختیار عمل دارد کافی نیست.
در نهایت، آنچه در زمان اجرا ممکن و enforce میشود تعیینکننده است.
هر نیتی که در پرامپت نوشته شده باشد، رفتار واقعی را قابلیتهایی که محیط اجرا در اختیار عامل میگذارد و مرزهایی که همان محیط enforce میکند تعیین میکنند.
پشته قرارداد
یک تفکیک کاربردی این است:
- پرامپت نیت را بیان میکند
- فایلهای دستورالعمل زمینه را فراهم میکنند
- مهارتها و قواعد قرارداد کاری را تعریف میکنند
- نقاط اجرای کنترل، قرارداد را الزامآور میکنند
- راستیآزمایی هنگام اجرا گواه انطباق تولید میکند
- شواهد و امتناع، سابقه قابل حسابرسی میسازند
نام این اجزا در پلتفرمهای مختلف میتواند متفاوت باشد. تفکیک نقش آنها نباید از بین برود.
پرامپت میگوید عامل بهتر است به چه نتیجهای برسد.
قرارداد میگوید عامل در مسیر رسیدن به آن نتیجه چه کارهایی اجازه دارد انجام دهد.
این تفاوت میان توصیه و اختیار است.
قرارداد عامل باید چه چیزهایی را مشخص کند؟
قرارداد عامل لازم نیست از روز اول یک طرح عظیم حاکمیتی باشد.
هدف اولیه این است که فرضهای پنهان به قواعد صریح تبدیل شوند.
در عمل، یک قرارداد مفید حداقل باید این ابعاد را پوشش دهد.
هویت و مالکیت
هر عامل یا قابلیت عملیاتی باید هویت پایدار، نسخه و مالک مشخص داشته باشد.
باید بتوان پاسخ داد:
- کدام عامل در حال عمل است
- کدام بسته قابلیت فعال است
- مالک قرارداد چه کسی است
- قرارداد چه زمانی تأیید شده
- چه زمانی منقضی میشود یا باید دوباره بررسی شود
عاملی که نام مشخص ندارد و با حساب سرویس مشترک کار میکند، از همان ابتدا بهسختی قابل حاکمیت است.
هدف و کارهای خارج از محدوده
مشخص کنید عامل برای چه کاری ساخته شده و چه کارهایی صریحاً وظیفه او نیست.
«کمک به استقرار» مبهم است.
«شواهد استقرار سرویس X را بررسی کن و یکی از سه نتیجه اجازه، رد یا نیاز به بررسی انسانی را برگردان؛ هرگز استقرار production را اجرا نکن» یک قرارداد است.
تعریف کارهای خارج از محدوده مهم است، چون ابهام بهتدریج اختیار را گسترش میدهد.
محدوده ابزار و منابع
ابزارهایی که عامل میتواند فراخوانی کند و منابعی که هر ابزار میتواند به آنها دسترسی داشته باشد باید مشخص باشند.
قرارداد باید میان این موارد تفاوت بگذارد:
- خواندن و نوشتن
- توسعه، staging و production
- یک repository و همه repositoryها
- یک tenant و همه tenantها
- مشاهده و تغییر
وجود یک ابزار در محیط اجرا نباید به معنی مجاز بودن استفاده عامل از آن باشد.
ورودیها و پیششرطها
تعریف کنید پیش از اجرای قابلیت چه شرایطی باید برقرار باشد.
برای نمونه:
- فیلدهای اجباری درخواست
- شواهد لازم
- نسخه سیاست لازم
- تفویض اختیار انسانی
- وضعیت لازم محیط
- حداکثر عمر اطلاعات بازیابیشده
اگر یک پیششرط برقرار نبود، سامانه باید بداند باید درخواست را رد کند، به تعویق بیندازد یا به انسان ارجاع دهد.
خروجیها و پسشرطها
سامانههای بعدی نباید مجبور باشند منظور عامل را از متن آزاد حدس بزنند.
قرارداد باید تعریف کند:
- ساختار خروجی
- ارجاعهای الزامی به شواهد
- فیلدهای عدمقطعیت در صورت نیاز
- وضعیتهای تصمیم مجاز
- اثرات جانبی مورد انتظار
- شرایطی که پس از اجرا باید برقرار باشند
متن طبیعی میتواند بخشی از خروجی باشد، اما بخش قابل پردازش توسط ماشین نباید فقط به تفسیر متن وابسته باشد.
ریسک، شعاع اثر و بودجه
قرارداد باید مقدار اختیاری را که قابلیت میتواند اعمال کند مشخص کند.
موضوع فقط permission نیست.
مرزهای مفید میتوانند شامل این موارد باشند:
- حداکثر کلاس اقدام
- حداکثر شعاع اثر
- بودجه مالی
- بودجه توکن
- بودجه زمان یا تعداد گام
- سقف همزمانی
- محدوده نرخ فراخوانی
قرارداد جایی است که پرسش «این کار تا کجا میتواند پیش برود؟» پاسخ صریح پیدا میکند.
امتناع و ارجاع
امتناع، الزاماً شکست مدل نیست.
در سامانه تحت حاکمیت، امتناع میتواند نتیجه صحیح باشد.
قرارداد باید مشخص کند چه زمانی عامل باید متوقف شود، چه زمانی میتواند با دامنه محدودتر ادامه دهد، چه زمانی باید تأیید انسانی بخواهد و چه زمانی باید خروجی را قرنطینه کند و وارد مسیر زنده نکند.
اگر رفتار امتناع تعریف نشده باشد، عامل دقیقاً در لحظهای که سازمان بیشترین نیاز را به رفتار قابل پیشبینی دارد مجبور به بداههپردازی میشود.
شواهد
هر اقدام مهم باید به اندازه کافی شواهد باقی بگذارد تا بعداً بتوان علت آن را بازسازی کرد.
قرارداد میتواند ثبت این موارد را اجباری کند:
- ورودیهای بررسیشده
- منابع دانش
- فراخوانی ابزارها
- نسخه سیاست
- نسخه قرارداد
- دلیل تصمیم
- تأییدها
- استثناها
- اثرات جانبی ایجادشده
در این نقطه، رفتار عامل از یک روایت شفاهی به چیزی قابل حسابرسی تبدیل میشود.
پرامپت خوانده میشود. سابقه باید قابل اثبات باشد.
قرارداد میتواند کوچک باشد
نسخه اول میتواند عمداً ساده باشد.
برای مثال:
~~~yaml agent_contract: id: deployment-reviewer version: 3 purpose: review deployment evidence
allowed_tools:
- read_repository
- read_ci_results
- read_runtime_health
forbidden_actions:
- deploy_production
- modify_secrets
preconditions:
- deployment_evidence_present
- active_policy_version_present
outputs: schema: deployment_review_v2 allowed_decisions:
- allow
- deny
- require_approval
escalation: when:
- evidence_incomplete
- blast_radius_above_medium
evidence: required:
- sources_used
- policy_version
- contract_version
- decision_reason
~~~
نحو این نمونه اصل موضوع نیست.
تغییر اصلی این است که فرضهای پنهان اکنون قابل مشاهده، قابل آزمون و قابل نسخهبندی شدهاند.
تیم میتواند این artifact را review کند.
pipeline میتواند آن را اعتبارسنجی کند.
محیط اجرا میتواند بخشهایی از آن را enforce کند.
سامانه ارزیابی میتواند رفتار عامل را با آن بسنجد.
بازرس حادثه میتواند بپرسد کدام نسخه فعال بوده است.
این وضعیت بسیار محکمتر از جمله «مراقب باش» است.
مهارت بهتنهایی قرارداد نیست
پلتفرمهای جدید عاملها، قابلیتها را در قالب مهارت، قاعده، فایل دستورالعمل، manifest یا مجموعه ابزار ارائه میکنند.
این پیشرفت مفیدی است.
اما مهارتی که روش انجام کار را توضیح میدهد، بهتنهایی قرارداد حاکمیتی نیست.
ممکن است یک مهارت توضیح دهد چگونه سرویس مستقر شود.
قرارداد هنوز باید پاسخ دهد:
- آیا این عامل مجاز است این سرویس را مستقر کند
- در کدام محیط
- با تفویض اختیار چه کسی
- با چه شواهدی
- در چه محدودهای از شعاع اثر
- با چه بودجهای
- با کدام نسخه مهارت
- با چه الزام rollback یا containment
یک مهارت ممکن است برای یک عامل امن و برای عامل دیگر نامناسب باشد.
یک ابزار ممکن است در staging مجاز و در production ممنوع باشد.
یک درخواست واحد ممکن است در شرایط عادی مجاز باشد و هنگام incident نیاز به تأیید پیدا کند.
قابلیت با اختیار یکی نیست.
یک قاعده ساده:
مهارت به عامل میگوید چگونه انجام بدهد. قرارداد به سامانه میگوید آیا، کجا و تحت چه شرایطی اجازه انجام وجود دارد.
قرارداد باید در برابر تغییرات زمان اجرا دوام بیاورد
حتی قرارداد خوب هم بیمعنا میشود اگر سطح رفتار زیر آن بدون کنترل تغییر کند.
رفتار عامل میتواند با تغییر هر یک از این موارد جابهجا شود:
- مدل
- system prompt
- فایل دستورالعمل
- مهارت
- schema ابزار
- permission
- routing
- منبع retrieval
- policy bundle
- runtime host
بنابراین قرارداد باید به نسخهها متصل باشد، نه به نامهایی که ممکن است بیصدا تغییر کنند.
«از coding agent استفاده کن» کافی نیست.
«بسته قابلیت 4.7 تحت قرارداد 3.2 و بسته سیاست 12» قابل حاکمیت است.
هدف قرارداد منجمد کردن دائمی سامانه نیست.
هدف این است که تغییر، قابل مشاهده شود.
وقتی ارتقای مدل یا مهارت رفتار را تغییر میدهد، نسخه بسته قابلیت هم تغییر میکند. قرارداد میتواند دوباره ارزیابی، آزمون و تأیید شود.
بدون این انضباط، قرارداد به مستندی درباره سامانهای تبدیل میشود که دیگر وجود ندارد.
راستیآزمایی هنگام اجرا نیمه فراموششده قرارداد است
نوشتن قرارداد کافی نیست.
سامانه باید بتواند بررسی کند که اجرا واقعاً در محدوده قرارداد باقی مانده است.
این بررسی میتواند شامل کنترلهای قطعی باشد:
- فقط ابزارهای مجاز فراخوانی شدهاند
- منابع ممنوع تغییر نکردهاند
- شواهد لازم وجود داشتهاند
- بودجهها رعایت شدهاند
- خروجی با schema قرارداد مطابقت دارد
- با عبور از threshold لازم، ارجاع انجام شده است
در جاهایی که کنترل قطعی کافی نیست، ارزیابی رفتاری هم میتواند اضافه شود.
نکته مهم این است که نتیجه باید بهصورت یک گواه انطباق در همان trace اجرای عامل ثبت شود.
پرسش مفید فقط این نیست:
«آیا عامل کار را تمام کرد؟»
پرسش قویتر این است:
«آیا عامل کار را در محدوده قرارداد تمام کرد؟»
این تعریف بسیار بهتری از موفقیت است.
امتناع بخشی از محصول است
تیمهای عامل معمولاً completion rate را بهشدت بهینه میکنند.
این کار بهراحتی باعث میشود refusal و escalation بهعنوان شکست دیده شوند.
حاکمیت نگاه دیگری لازم دارد.
عامل خوب باید در این شرایط امتناع کند:
- شواهد لازم وجود ندارد
- اختیار درخواستی از محدوده او بیشتر است
- فراخواننده تفویض اختیار معتبر ندارد
- اقدام از مرز شعاع اثر عبور میکند
- بودجه تمام شده
- وضعیت سیاست مبهم است
- محیط اجرا نمیتواند فعال بودن یک کنترل ضروری را اثبات کند
امتناع همراه با دلیل ساختاریافته، خروجی بیارزش نیست.
یک نتیجه حاکمیتی است.
همین موضوع درباره «نیاز به تأیید»، «تعویق» و «قرنطینه» هم صدق میکند.
وقتی این وضعیتها صریحاً در قرارداد تعریف شوند، سامانه میتواند آنها را مسیریابی کند و مجبور نیست از مدل بخواهد در لحظه راهحل بداهه بسازد.
قرارداد باید قابل آزمون باشد
اگر از یک بند قرارداد نتوان آزمون ساخت، احتمالاً آن بند هنوز بیش از حد مبهم است.
برای هر شرط مهم بپرسید چه شواهدی انطباق را ثابت میکند.
اگر قرارداد میگوید عامل نباید روی production deploy انجام دهد، ابزار deploy را در یک سناریوی آزمون در دسترس بگذارید و بررسی کنید که runtime آن را مسدود میکند.
اگر قرارداد بالاتر از یک شعاع اثر مشخص ارجاع را اجباری میکند، دقیقاً همان مرز را آزمایش کنید.
اگر خروجی باید ارجاع به شواهد داشته باشد، خروجی بدون ارجاع را رد کنید.
اگر بودجه باید workflow را متوقف کند، در محیط غیرتولیدی عامل را به سقف بودجه برسانید و رفتار واقعی را ببینید.
قرارداد زمانی ارزش پیدا میکند که به evaluation متصل شود.
در غیر این صورت فقط یک سند دیگر است که بهمرور از واقعیت فاصله میگیرد.
ترتیب عملی ساخت
کار را با طراحی یک زبان قرارداد سازمانی شروع نکنید.
یک قابلیت واقعی را انتخاب کنید.
۱. عاملی را انتخاب کنید که اثر جانبی ایجاد میکند
دستیارهای فقطخواندنی مفیدند، اما پرسشهای دشوار حاکمیتی را پنهان میکنند.
قابلیتی را انتخاب کنید که میتواند state را تغییر دهد، هزینه بسازد، PR باز کند، configuration را عوض کند یا deployment را تحریک کند.
۲. کوچکترین قرارداد صریح را بنویسید
هویت، هدف، کارهای خارج از محدوده، ابزارها، منابع، پیششرطها، خروجیها، مرز ریسک، امتناع، ارجاع و شواهد را تعریف کنید.
قرارداد باید آنقدر کوچک بماند که تیم مالک واقعاً بتواند آن را review کند.
۳. قرارداد را به نسخهها متصل کنید
مدل، prompt، مهارتها، ابزارها، policy bundle و فرضهای runtime که رفتار را تغییر میدهند pin کنید.
تغییر در این اجزا را تغییر قابلیت در نظر بگیرید.
۴. مرزهای سخت را خارج از مدل enforce کنید
از مدل نخواهید پرریسکترین permissionهای خودش را کنترل کند.
runtime باید اقدامهایی را که از قرارداد عبور میکنند مسدود کند.
۵. شواهد قرارداد را ثبت کنید
نسخه قرارداد و سیگنالهای مهم انطباق را در همان trace اقدام ثبت کنید.
اجرا باید قابل بازسازی باشد.
۶. امتناع و ارجاع را آزمایش کنید
فقط مسیر موفق را ارزیابی نکنید.
کمبود شواهد، عبور از محدوده، فشار بودجه و ابهام سیاست را عمداً ایجاد کنید.
بررسی کنید سامانه دقیقاً همانطور شکست میخورد که قرارداد تعریف کرده است.
۷. قراردادها را artifact عملیاتی بدانید
قرارداد باید مالک، نسخه، تاریخ review و مسیر بازنشستگی داشته باشد.
این artifact بخشی از چرخه production است.
جمعبندی
پرامپت حذف نمیشود.
فقط در جای درست خودش قرار میگیرد.
پرامپت برای بیان هدف، زمینه، لحن، راهبرد و reasoning انعطافپذیر بسیار خوب است.
اما جایگزین مناسبی برای مرز اختیار نیست.
یک سازمان AI-Native به هر دو نیاز دارد.
پرامپت میگوید انسان چه میخواهد.
قرارداد به سامانه میگوید عامل در مسیر رسیدن به آن هدف چه کارهایی مجاز است انجام دهد.
لایه اجرای کنترل، قرارداد را واقعی میکند.
شواهد runtime نشان میدهد قرارداد رعایت شده یا نه.
و امتناع راه مشروعی برای توقف ایجاد میکند، وقتی شرایط قرارداد برقرار نیست.
روند کامل این است:
نیت -> قرارداد -> اجرا -> گواه انطباق -> شواهد
قرارداد در حال تبدیل شدن به مشخصات رفتاری قابل اجرا میان انسان، عامل و ابزار است.
نه به این دلیل که عاملها به paperwork بیشتری نیاز دارند.
به این دلیل که autonomy بدون قرارداد یعنی تفسیر نامحدود همراه با دسترسی به ابزار.
مقاله بعد یک فرض ناخوشایند را میپذیرد: عامل گاهی از قرارداد خارج خواهد شد.
از همان نقطه containment آغاز میشود.
مقاله بعدی مجموعه: حاکمیت هوش مصنوعی بدون مهار شکست میخورد.
این مقاله نخستین بار در ۲۹ مه ۲۰۲۶ توسط Reza Arani در Medium منتشر شد و برای Aipolix بهعنوان بخش پنجم مجموعه AI Governance in an AI-Native Software Development Company بازآرایی شده است.
دیدگاهها
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید.
ثبت دیدگاه