🧭 پنج لایه حاکمیت ایجنت‌ها و چرا بیشتر تیم‌ها هنوز فقط دو لایه دارند (۲/۱۰)

چرا حساب‌های سرویس و گیت‌های تأیید دیگر کافی نیستند، وقتی ایجنت‌ها کد می‌نویسند، بازبینی می‌کنند و آن را به production می‌رسانند.

مقاله ۲ از ۱۰ — حاکمیت هوش مصنوعی در یک شرکت توسعه نرم‌افزار AI-Native

گران‌ترین جمله در مهندسی AI-Native معمولاً با اعتمادبه‌نفس کامل گفته می‌شود:

«ما همین حالا هم حاکمیت داریم.» 🫤

بیشتر وقت‌ها منظور از این جمله سه چیز است:

• ایجنت‌ها از طریق SSO یا یک حساب سرویس وارد می‌شوند
• مجوزهای repository وجود دارد
• هنوز یک انسان تغییرات production را تأیید می‌کند

این حاکمیت نیست. این فقط کنترلِ درِ ورودی است.

این کنترل‌ها به سؤال‌های اول پاسخ می‌دهند و سؤال‌های پرهزینه‌تر را نادیده می‌گیرند:

• چرا ایجنت آن تصمیم را گرفت؟
• آن تصمیم چگونه به یک تغییر production تبدیل شد؟
• در اطراف آن چه چیزهای دیگری تغییر کرد؟
• آیا ایجنت واقعاً نتیجه را بهتر کرد؟
• سه‌ماهه بعد باید اختیار بیشتری به این ایجنت بدهیم یا کمتر؟

شکاف واقعی همین‌جاست.

در مقاله قبلی، «فکر می‌کنید AI Governance دارید؟ ندارید.»، توضیح دادم که حاکمیت هوش مصنوعی در یک شرکت نرم‌افزاری همان بحث AI Safety نیست. این یک مسئله عملیات مهندسی است. این مقاله آن ایده را به یک ابزار تشخیصی تبدیل می‌کند: مدل پنج‌لایه‌ای که با آن مشخص می‌کنم یک شرکت واقعاً حاکمیت دارد یا فقط چند کنترل قابل‌مشاهده و مقدار زیادی امید.

نسخه کوتاه و صریح: بیشتر تیم‌ها فقط لایه‌های ۱ و ۲ را آن هم به‌صورت ناقص دارند. بقیه، بدهی حاکمیتی است.

🧩 مدل در یک جمله

حاکمیت ایجنت‌ها پنج لایه دارد:

1. هویت: چه کسی در حال عمل است؟
   2. عمل: ایجنت اجازه انجام چه کاری را دارد؟
   3. خروجی: چه تصمیمی گرفت و چه شواهدی از آن پشتیبانی می‌کند؟
   4. تغییر: آن خروجی چگونه به یک تغییر production تبدیل شد؟
   5. نتیجه: ایجنت کمک کرد، آسیب زد یا دچار drift شد؟

اگر حتی یکی از این لایه‌ها را نداشته باشید، در stack حاکمیتی شما یک نقطه کور وجود دارد. اگر لایه‌های ۳ تا ۵ را نداشته باشید، که وضعیت بسیاری از شرکت‌هاست، دیگر یک stack حاکمیتی ندارید؛ فقط کنترل دسترسی به‌اضافه خوش‌بینی دارید.

نکته اصلی به زبان ساده این است:

لایه‌های ۱ و ۲ دسترسی را کنترل می‌کنند. لایه‌های ۳، ۴ و ۵ اعتماد را در مقیاس ایجاد می‌کنند.

دسترسی، اعتماد نیست. اعتماد از لایه‌های ۳، ۴ و ۵ شروع می‌شود. کنترل‌های ورودی جلوی خطاهای آشکار را می‌گیرند؛ سه لایه بعدی به شما امکان می‌دهند کاری را که از این کنترل‌ها عبور کرده بررسی کنید، برگردانید و بهبود دهید.

🗂 پنج لایه

۱. هویت
سؤال اصلی: چه کسی در حال عمل است؟
وضعیت خوب: هر ایجنت یک هویت یکتا و قابل‌تأیید، credential محدود و یک مالک مشخص دارد.
نبود آن چه چیزی را خراب می‌کند: credential مشترک، attribution ضعیف و containment تقریباً ناممکن.

۲. عمل
سؤال اصلی: ایجنت چه کاری می‌تواند انجام دهد؟
وضعیت خوب: مرزهای صریح autonomy، non-goalهای enforceشده توسط ماشین و تأیید انسانی در جایی که اختیار تمام می‌شود.
نبود آن چه چیزی را خراب می‌کند: scope creep، استفاده ناامن از ابزار و overreach ناخواسته.

۳. خروجی
سؤال اصلی: ایجنت چه تصمیمی گرفت و چرا؟
وضعیت خوب: decision trace، لینک شواهد، confidence، citation و rationale ساختاریافته.
نبود آن چه چیزی را خراب می‌کند: PRهای مرموز، شکست audit و postmortem مبتنی بر حدس.

۴. تغییر
سؤال اصلی: خروجی چگونه به production رسید؟
وضعیت خوب: traceability انتها‌به‌انتها از request تا PR، CI، canary و deploy همراه با آمادگی rollback.
نبود آن چه چیزی را خراب می‌کند: شکاف زمانی، drift خاموش prompt یا model و incident response کند.

۵. نتیجه
سؤال اصلی: آیا ایجنت مؤثر بود؟
وضعیت خوب: metric در سطح version برای accept rate، rework، rollback، cost، escalation و drift.
نبود آن چه چیزی را خراب می‌کند: گسترش autonomy بر اساس حس، ماندگاری ایجنت‌های ضعیف و فرسایش اعتماد.

این جمله را دوباره تکرار کنید، چون دقیقاً همین‌جا تیم‌ها خودشان را فریب می‌دهند: لایه‌های ۱ و ۲ دسترسی را کنترل می‌کنند. لایه‌های ۳، ۴ و ۵ اعتماد را در مقیاس ایجاد می‌کنند. اگر فقط دو لایه اول را ساخته‌اید، stack را کامل نکرده‌اید. فقط لابی ساختمان را ساخته‌اید و بقیه ساختمان را در تاریکی رها کرده‌اید.

لایه ۱: هویت 🔐

هر سیستم حاکمیتی از اینجا شروع می‌شود، چون بدون هویت همه‌چیز به ابهام تبدیل می‌شود. ایجنتی که هویت یکتا ندارد governed نیست؛ فقط فرایندی است که مسئولیت‌پذیری در آن مبهم است.

حداقلِ لایه ۱ یعنی:

• هر instance ایجنت یک identity record جداگانه دارد
• credentialها مختص همان ایجنت‌اند و بین یک کلاس از ایجنت‌ها مشترک نیستند
• permissionها بر اساس purpose ثبت‌شده ایجنت محدود شده‌اند
• صدور، rotation و revoke کردن credential قابل audit است
• یک مالک انسانی مشخص وجود دارد

این موضوع بدیهی به نظر می‌رسد، اما در عمل هنوز تیم‌های زیادی چند ایجنت را با یک token اجرا می‌کنند یا اجازه می‌دهند IDE agentها به‌دلیل راحتی، دسترسی گسترده توسعه‌دهنده را به ارث ببرند. این راحتی خیلی سریع به بدهی عملیاتی تبدیل می‌شود. اگر سه ایجنت یک credential مشترک داشته باشند، هنگام incident نمی‌توانید یکی را isolate کنید. اگر ایجنت دسترسی یک انسان را قرض بگیرد، مرز بین اقدام انسانی و اقدام ایجنت از بین رفته است. اگر یک production agent secret ثابت و طولانی‌مدت داشته باشد، یک log leak کافی است تا با breachای مواجه شوید که attribution آن سخت است.

هویت فقط یک موضوع امنیتی نیست؛ اولین پیش‌نیاز برای legibility است. اگر نمی‌توانید با یک query جواب دهید «کدام ایجنت این کار را انجام داد؟»، هنوز وقت maturity model و KPI deck نیست. شما هنوز در لایه ۱ هستید.

🛑 لایه ۲: عمل

هویت می‌گوید ایجنت چه کسی است. عمل می‌گوید اجازه انجام چه کاری را دارد. مرزهای autonomy، non-goalها، scope ابزارها، threshold تأیید و قواعد fail-closed در این لایه قرار می‌گیرند.

در یک لایه ۲ قوی، اختیار ایجنت در پنج جهت صریح است:

• عملکردی: چه اقدام‌هایی را می‌تواند یا نمی‌تواند انجام دهد
• داده: به چه سیستم‌ها و domainهای داده‌ای دسترسی دارد
• زمانی: چه زمانی می‌تواند عمل کند و چه زمانی نباید
• اختیار: کدام تصمیم‌ها نیازمند تأیید انسانی‌اند
• escalation: چه زمانی ابهام یا ریسک باید workflow را متوقف کند

یک تصمیم طراحی ساده اما کمیاب این است: رد کردن درخواست باید یک خروجی صحیح محسوب شود.

اگر ایجنت نمی‌تواند تشخیص دهد یک درخواست در scope هست یا نه، باید آن را رد و escalate کند. هنوز تیم‌های زیادی ایجنت را برای «کمک‌کردن» تشویق می‌کنند، در حالی که رفتار governed در آن موقعیت باید «توقف» باشد.

این همان تفاوت بین ایجنتی است که در demo باهوش به نظر می‌رسد و ایجنتی که می‌توانید با خیال راحت در production اجرا کنید. بیشتر شرکت‌ها نسخه‌ای از لایه ۲ را دارند، اما معمولاً ضعیف است: شاید یک policy document داخلی، شاید promptی با عبارت «به production دست نزن»، یا یک مرحله approval دستی برای اقدامات پرریسک.

این کافی نیست. لایه ۲ واقعی در runtime enforce می‌شود، machine-readable است و قبل از انجام اقدام جلوی آن را می‌گیرد. وگرنه مرزهای شما مرز نیستند؛ پیشنهادند.

🧾 لایه ۳: خروجی

این لایه‌ای است که بیشتر تیم‌ها تقریباً کامل از آن عبور می‌کنند، و دقیقاً همین‌جاست که governance واقعی شروع می‌شود. لایه ۳ می‌پرسد: وقتی یک ایجنت تصمیم مهمی می‌گیرد، چه شواهدی از آن تصمیم باقی می‌ماند؟ نه توضیح صیقل‌خورده PR و نه شعار «شفاف بودن» ایجنت؛ منظور شواهد واقعی عملیاتی است.

برای یک تصمیم معنادار باید بتوانید این موارد را بازیابی کنید:

• decision trace ID
• inputهایی که ایجنت استفاده کرده
• منابع دانش یا referenceهایی که به آن‌ها تکیه کرده
• signal مربوط به confidence یا certainty در جایی که معنا دارد
• alternativeهایی که برای تصمیم‌های مهم بررسی شده‌اند
• خروجی ساختاریافته‌ای که تولید شده

بدون این موارد به همان چیزی می‌رسید که بسیاری از تیم‌ها امروز دارند: کدی در main که توضیح قابل‌اعتمادی برای دلیل وجودش ندارید. در incident یا audit، نبود لایه ۳ یعنی postmortem شما با جست‌وجوی Slack شروع می‌شود و پاسخ compliance با «فکر می‌کنیم».

Chat log، traceability نیست. فقط باقی‌مانده است.

باستان‌شناسی Slack، auditability نیست؛ reconstruction است. اعتراض رایج سرعت است: «اگر همه این‌ها را capture کنیم دیگر سریع نیستیم.» معمولاً درست نیست. برای هر خروجی رمان نمی‌خواهید؛ traceهای ساختاریافته و قابل query می‌خواهید. governance خوبِ خروجی narrative-heavy نیست؛ schema-heavy است.

این لایه postmortem را از داستان کارآگاهی به مهندسی تبدیل می‌کند. بخش بزرگی از درد audit هم از همین‌جا می‌آید. وقتی compliance می‌پرسد چه کسی یا چه چیزی یک تغییر را approve کرد، کدام نسخه policy فعال بود یا کدام سطح evidence از تصمیم پشتیبانی می‌کرد، تیم فاقد لایه ۳ سراغ chat log و screenshot می‌رود. این governance نیست؛ reconstruction است. لایه ۳ کار را legible می‌کند.

🔄 لایه ۴: تغییر

لایه ۳ می‌گوید ایجنت چه تصمیمی گرفت. لایه ۴ می‌گوید آن تصمیم چگونه به یک تغییر زنده تبدیل شد. incidentهای production معمولاً در نقطه تصمیم اتفاق نمی‌افتند؛ بعداً رخ می‌دهند، وقتی زنجیره‌ای از سیستم‌ها خروجی ایجنت را به اثر روی مشتری تبدیل می‌کند.

لایه ۴ کل timeline را به هم متصل می‌کند: request → plan → PR → CI → canary → deploy → runtime signals → incident → rollback.

حاکمیت خوب در لایه ۴ یعنی:

• یک correlation ID در تمام مسیر باقی می‌ماند
• لینک artifactها حفظ می‌شود و شلخته در noteها کپی نمی‌شود
• هر edge مهم در timeline امضاشده یا قابل audit است
• missing link با صدای بلند fail می‌شود
• آمادگی rollback قبل از promotion بررسی می‌شود
• تغییرات مؤثر بر رفتار، مثل prompt، نسخه model و tool schema، مثل کد version و promote می‌شوند

آخرین مورد جایی است که حتی سازمان‌های مهندسی منضبط هم گیر می‌کنند. هنوز «تغییر» را فقط source code می‌بینند.

در مدل عملیاتی AI-Native، تغییر prompt، routing rule، tool schema، retrieval index و model version همگی رفتار production را تغییر می‌دهند. promptی که رفتار زنده را تغییر می‌دهد یک production change است. model swapی که رفتار approval را عوض می‌کند production change است. tool-schemaای که دامنه ابزار قابل‌فراخوانی را بزرگ‌تر می‌کند production change است.

اگر این تغییرها همان discipline مربوط به promotion کد را دور بزنند، change control ندارید. یک deployment model دوپاره دارید: Git governed است، رفتار نیست. اگر رفتار سیستم بتواند بیرون از deployment pipeline تغییر کند، سیستم واقعاً governed نیست.

به همین دلیل تیم‌ها گاهی جمعه incidentی را debug می‌کنند که علتش prompt update سه‌شنبه بوده؛ بدون review، بدون canary و بدون rollback plan. لایه ۴ reversibility را از شعار به واقعیت تبدیل می‌کند.

📈 لایه ۵: نتیجه

لایه آخر همان سؤالی را می‌پرسد که مدیران در نهایت خواهند پرسید: آیا این ایجنت واقعاً کمک می‌کند؟ نه اینکه «توسعه‌دهنده‌ها دوستش دارند؟»، نه «این ماه چند prompt deploy کردیم؟» و نه «چند token خریدیم؟».

سؤال واقعی این است که آیا یک نسخه مشخص از capability نتیجه را بهتر کرده، بدون اینکه هزینه پنهان را به جای دیگری منتقل کند. پس باید در سطح capability-version این موارد را اندازه بگیرید:

• accept rate
• rework rate
• escalation rate
• rollback rate
• تغییر time-to-done
• cost per task
• bounded-autonomy respect rate
• مشارکت در incidentها

بیشتر شرکت‌ها هنوز در این لایه بر اساس حس جلو می‌روند. می‌دانند ایجنت‌ها «همه‌جا» هستند، usage بالا رفته و CFO داستان ROI می‌خواهد؛ اما نمی‌توانند بگویند کدام نسخه ایجنت به تیم checkout کمک کرد، کدام review burden را بالا برد، کدام بعد از model swap regress کرد یا کدام باید فصل بعد scope بیشتری بگیرد.

ارزیابی بر اساس حس باعث می‌شود ایجنت‌های متوسط promote شوند، ایجنت‌های گران دفاع شوند و ایجنت‌های ضعیف به «استراتژی» تبدیل شوند. همین‌طور اشتباهات پرهزینه کم‌کم عادی می‌شوند.

بدون لایه ۵، رشد autonomy سیاسی می‌شود: پرصداترین حامی، جذاب‌ترین demo یا roadmap فروشنده برنده می‌شود. با لایه ۵، governance قابل‌بهبود می‌شود: می‌توانید scope را محدود کنید، نسخه‌های امن‌تر را promote کنید، capability ضعیف را retire کنید و تصمیم منابع را بر اساس evidence بگیرید، نه هیجان.

🏦 یک incident از نگاه هر پنج لایه

یک coding agent در یک شرکت fintech مأمور کاهش latency checkout می‌شود. مسیر query داغ را بازنویسی می‌کند، lookup محدود را با join گسترده‌تر جایگزین می‌کند، PR می‌سازد و test suite پاس می‌شود. تست‌ها correctness را روی fixture کوچک می‌سنجند، نه latency با cardinality production و concurrency واقعی. reviewer انسانی سریع approve می‌کند. deploy agent هم چون error spike و breach در p95 پیش‌فرض نمی‌بیند تغییر را از canary عبور می‌دهد. تا عصر latency checkout بدتر شده و تیم rollback می‌کند.

اگر فقط لایه‌های ۱ و ۲ را داشته باشید احتمالاً فقط می‌توانید بگویید کدام حساب ایجنت PR را باز کرده و این ایجنت از نظر فنی permission ویرایش آن service را داشته. این اطلاعات مفیدند، اما به‌هیچ‌وجه کافی نیستند.

لایه ۱، هویت
instance دقیق ایجنت، مالک، credential set و capability version درگیر را می‌دانید.

لایه ۲، عمل
می‌دانید تغییر performance logic checkout واقعاً در scope ایجنت بوده یا نه، آیا از مرز داده/اختیار عبور کرده و threshold review برای criticality آن سرویس مناسب بوده یا نه.

لایه ۳، خروجی
decision trace را می‌بینید: چه فایل‌هایی خوانده، چه شواهدی استفاده کرده، benchmark قدیمی citation شده یا نه، confidence پایین بوده یا نه و آیا signal متناقض را نادیده گرفته است.

لایه ۴، تغییر
timeline امضاشده از request تا PR، CI، canary، deploy و rollback را بازسازی می‌کنید و می‌بینید آیا prompt update یا tool-schema change در همان بازه اثرگذار بوده است.

لایه ۵، نتیجه
این incident را با سابقه عملکرد گسترده‌تر ایجنت مقایسه می‌کنید: یک miss منفرد؟ regression جدید؟ الگو روی سرویس‌های critical؟ یا علامتی برای کاهش autonomy؟

این تفاوت میان «یک incident هوش مصنوعی داشتیم» و «سیستم عملیاتی خودمان را می‌فهمیم» است. حالت اول reactive و گران است. حالت دوم همان چیزی است که trust at speed را می‌سازد.

🚧 چرا بیشتر تیم‌ها در لایه ۲ متوقف می‌شوند؟

سه دلیل. اول، لایه‌های ۱ و ۲ شبیه governance سنتی‌اند. Security هویت را دارد، Platform permission را؛ کنترل‌ها قابل‌مشاهده‌اند و leadership احساس پیشرفت می‌کند.

دوم، لایه‌های ۳ و ۴ discipline ناراحت‌کننده می‌خواهند: trace ساختاریافته، timeline امضاشده، prompt version-pinned، تشخیص gap در deploy gate و rollback probe. این کار مهندسی واقعی است و نشان می‌دهد چه میزان از فرایند فعلی به رفتار غیررسمی وابسته است.

سوم، لایه ۵ سازمان را مجبور به صداقت می‌کند. وقتی effectiveness ایجنت را در سطح version اندازه می‌گیرید، بعضی ابزارهای محبوب دیگر چشمگیر نیستند؛ بعضی توسعه‌های autonomy زودهنگام‌اند و bottleneck بعضی تیم‌ها coding speed نیست بلکه review، incident handling یا retrieval بی‌کیفیت است.

یعنی لایه‌های عمیق‌تر فقط ایجنت را govern نمی‌کنند؛ narrative مدیریتی را هم govern می‌کنند. برای همین عقب می‌افتند؛ و دقیقاً برای همین مهم‌اند.

✅ یک self-assessment سریع

برای اینکه بفهمید کجا ایستاده‌اید، این پنج سؤال را بپرسید:

1. هویت: آیا امروز می‌توانیم نام هر ایجنت مرتبط با production، مالک، credential و scope آن را مشخص کنیم؟
   2. عمل: آیا می‌توانیم نشان دهیم هر ایجنت چه کارهایی را نباید انجام دهد و ثابت کنیم این مرزها در runtime enforce می‌شوند؟
   3. خروجی: آیا می‌توانیم یک تصمیم مهم ایجنت را از روی evidence قابل trace بازسازی کنیم، نه chat log؟
   4. تغییر: آیا می‌توانیم یک correlation ID را از request تا deploy و rollback، همراه با تغییر prompt و model دنبال کنیم؟
   5. نتیجه: آیا می‌توانیم بگوییم کدام capability versionها کمک می‌کنند، آسیب می‌زنند یا drift دارند؟

اگر پاسخ هرکدام «نه» است، آن لایه ضعیف است. اگر پاسخ سؤال‌های ۳ تا ۵ «نه» است، در رایج‌ترین وضعیت قرار دارید: کنترل‌های پایه در جلو، مه در میانه و نبود حلقه یادگیری قابل‌اعتماد در انتها.

این نقطه برای شروع قابل‌قبول است؛ برای ماندن امن نیست. صریح‌تر: اگر سؤال‌های ۳ تا ۵ را نمی‌توانید جواب دهید، trust at scale ندارید؛ exposure at scale دارید.

🏗️ بعدی را کجا بسازیم؟

سعی نکنید هر پنج لایه را هم‌زمان پیاده کنید. اگر اول راه هستید، لایه‌های ۱ و ۲ را از policy document خارج کنید و به enforcement واقعی برسانید. اگر این دو را دارید، مستقیم سراغ dashboardهای ROI مدیریتی نروید. اول لایه‌های ۳ و ۴ را بسازید. بدون آن‌ها metricهای outcome پرنویز، قابل‌مناقشه و قابل‌بازی‌دادن خواهند بود.

ترتیب عملی ساخت برای بیشتر تیم‌ها:

1. هویت یکتای ایجنت و credentialهای محدود
   2. مرزهای autonomy در runtime و non-goalهای صریح
   3. decision trace برای اقدامات مهم ایجنت
   4. timeline انتها‌به‌انتها برای change همراه با rollback readiness
   5. metricهای effectiveness در سطح capability version

این ترتیب مهم است، چون هر لایه اعتبار لایه بعدی را می‌سازد.

🎯 نکته اصلی مدل

مدل پنج‌لایه یک تمرین taxonomy نیست. هدفش این است که کلمه «governance» آن‌قدر شل استفاده نشود که معنای عملیاتی خود را از دست بدهد.

Governance یک prompt نیست که به ایجنت بگوید مراقب باش. Governance، SSO به‌اضافه template برای pull request نیست. Governance، کمیته Responsible AI نیست که هیچ‌وقت timeline deploy را نگاه نمی‌کند.

Governance همان discipline عملیاتی است که نیروی کار غیرانسانی را legible، contained، reversible و improvable می‌کند. همین موضوع اجازه می‌دهد سازمان مهندسی استفاده از ایجنت را scale کند، بدون اینکه confusion هم با همان سرعت scale شود. و همین چیزی است که trust at speed را ممکن می‌کند.

اگر مقاله ۱ بازتعریف مسئله بود، این مقاله ابزار تشخیص است: مشکل بسیاری از تیم‌ها کمبود principle نیست؛ مشکل این است که stack آن‌ها فقط دو لایه دارد، در حالی که production را روی هر پنج لایه شرط بسته‌اند.

این شرط هر فصل گران‌تر می‌شود.

پس با همان جمله‌ای تمام کنیم که اهمیت دارد: لایه‌های ۱ و ۲ دسترسی را کنترل می‌کنند. لایه‌های ۳، ۴ و ۵ اعتماد را در مقیاس ایجاد می‌کنند.

اگر نمی‌توانید کار را ببینید، تغییر را trace کنید و نتیجه را اندازه بگیرید، ایجنت‌ها را govern نمی‌کنید؛ بر اساس اعتماد کور عمل می‌کنید.