بیشتر تیم‌ها در Agent Governance به این دلیل متوقف نمی‌شوند که یک approval gate دیگر کم دارند. مشکل اصلی این است که سیستم‌های زیرِ کنترل‌ها نمی‌توانند با اطمینان توضیح دهند ایجنت چه دانشی داشته، چه چیزی را تغییر داده و آیا نتیجه واقعاً بهتر شده است یا نه.

این همان implementation gap است.

این نوشته بخش سوم از مجموعه ده‌قسمتی AI Governance در یک شرکت نرم‌افزاری AI-Native است. بخش دوم، مدل پنج‌لایه Identity، Action، Output، Change و Outcome را معرفی کرد. بیشتر سازمان‌ها روی دو لایه اول سریع‌تر پیش می‌روند، چون identity و permission به کنترل‌های آشنای security و platform نزدیک‌اند.

کار سخت از بعد از آن شروع می‌شود.

لایه‌های ۳، ۴ و ۵ به infrastructureای وابسته‌اند که خیلی از شرکت‌ها هنوز ندارند. این لایه‌ها به knowledge ساخت‌یافته، decision trace پایدار، delivery pipeline آگاه از behavior و outcome measurement نیاز دارند که در بررسی فنی قابل دفاع باشد.

در عمل سه سیستم پنهان، Governance واقعی را ممکن می‌کنند:

  1. Knowledge System
  2. Execution System
  3. Evaluation System

بدون این سه، Governance فقط در ورودی سیستم دیده می‌شود و رفتار مهم پشت آن همچنان مبهم باقی می‌ماند.

فاصله بین Governance و واقعیت

Identity control جواب می‌دهد چه کسی یا چه چیزی در حال عمل است.

Action control جواب می‌دهد ایجنت اجازه انجام چه کاری را دارد.

هر دو لازم‌اند، اما برای ایجاد trust در مقیاس کافی نیستند.

وقتی ایجنت شروع به تولید plan، تغییر code، تغییر infrastructure، recommendation حساس به policy یا action مستقیم روی production می‌کند، سازمان باید بتواند به سؤال‌های سخت‌تری جواب دهد:

  • ایجنت به چه knowledgeای تکیه کرده؟
  • کدام version از آن knowledge authoritative بوده؟
  • چه decision pathای به output رسیده؟
  • کدام prompt، model، tool و policy version فعال بوده؟
  • output چگونه تبدیل به production change شده؟
  • بعد از deploy چه اتفاقی افتاده؟
  • آیا capability واقعاً outcome را بهتر کرده یا فقط activity را بیشتر کرده است؟

اگر پاسخ به این سؤال‌ها نیازمند بازسازی دستی از chat log، dashboard و حافظه افراد باشد، Governance هنوز بیشتر process است تا engineering system.

Governance بدون infrastructure به theater تبدیل می‌شود.

سیستم اول: Knowledge Layer

Output Governance قبل از تولید output شروع می‌شود. نقطه شروع، کیفیت دانشی است که ایجنت اجازه دارد مصرف کند.

بیشتر سازمان‌ها هنوز knowledge عملیاتی مهم را در قالب‌هایی نگه می‌دارند که برای انسان قابل فهم ولی برای machine governance ضعیف‌اند: wikiهای قدیمی، ticketها، تصمیم‌های Slack، screenshot، runbookهای کپی‌شده و policy documentهایی که authority و lifecycle مشخص ندارند.

انسان گاهی می‌تواند تناقض‌ها را با context حل کند. ایجنت بدون structure صریح نمی‌تواند این کار را با اطمینان انجام دهد.

یک governed knowledge object باید چیزی بیشتر از prose داشته باشد.

حداقل باید معلوم باشد:

  • owner چه کسی است
  • canonical source کدام است
  • محتوا برای چه scopeای معتبر است
  • آخرین review چه زمانی بوده
  • چه زمانی نیاز به revalidation دارد
  • authority tier آن چیست
  • claim از کجا آمده
  • آیا منبع دیگری با آن conflict دارد
  • runtime چگونه اجازه استفاده از آن را دارد

این نگاه، retrieval را هم تغییر می‌دهد.

retrieval برای governed agent نباید فقط متن semantic-similar برگرداند. باید evidence را همراه provenance، authority و lifecycle context تحویل دهد.

سند بزرگ را به claimهای governed بشکنید

یک document طولانی unit خوبی برای control نیست. policy، procedure، constraint و fact باید به objectهای پایدار تبدیل شوند که قابل cite و version باشند.

canonical sourceها را ثبت کنید

یک منبع نباید فقط چون در vector search رتبه اول گرفته authoritative شود. system of record، draft و note غیررسمی باید از هم تفکیک شوند.

conflict را قبل از generation پیدا کنید

اگر دو منبع درباره deployment rule با هم تناقض دارند، ایجنت نباید compromise اختراع کند. knowledge layer باید conflict را آشکار کند و از authority rule یا escalation استفاده کند.

provenance را حفظ کنید

هر claim مهم باید به source، owner و version قابل trace باشد. محتوای بدون provenance شاید context مفیدی باشد، اما نباید بی‌صدا تبدیل به control شود.

اگر تمام knowledge شما prose است، Governance شما هم prose است.

Layer 3 یعنی Output فقط زمانی قابل اعتماد می‌شود که substrate زیر آن معتبر، تازه و قابل audit باشد.

سیستم دوم: Execution Layer

بعد از ساختن knowledge، Governance باید وارد execution شود.

اینجا دو record متفاوت مهم‌اند.

اولی decision trace است. توضیح می‌دهد ایجنت چگونه به یک تصمیم مهم رسیده است.

دومی change timeline است. توضیح می‌دهد آن تصمیم چگونه تبدیل به تغییر واقعی در سیستم شده است.

برای decisionهای مهم، trace مفید باید حداقل شامل این موارد باشد:

  • root trace ID
  • parent trace ID
  • decision trace ID
  • agent یا capability ID
  • capability version
  • prompt version
  • model version
  • tool version و schema
  • knowledge object و citationهای استفاده‌شده
  • policy version فعال
  • inputهای مهم
  • confidence یا uncertainty signal
  • structured outcome
  • timestamp و actor identity

این evidence برای Layer 3 لازم است.

Layer 4 به مسیر کامل‌تری نیاز دارد:

request -> plan -> PR -> CI -> deploy -> runtime -> rollback

یک correlation ID باید در تمام این مسیر زنده بماند.

work tracking، code review، test، deployment، observability، incident و rollback باید با همان شناسه قابل join باشند. eventها تا جای ممکن append-only باشند و gapهای trace به جای نادیده گرفته شدن، failure واضح ایجاد کنند.

این مدل فقط برای source code نیست.

در agentic system موارد زیر هم می‌توانند production behavior را تغییر دهند:

  • prompt update
  • model change
  • tool-schema change
  • routing logic
  • retrieval configuration
  • knowledge-index refresh
  • policy object
  • skill یا instruction change

اگر code از promotion path کنترل‌شده عبور می‌کند ولی prompt و tool در production به‌صورت in-place تغییر می‌کنند، سازمان عملاً دو سیستم change control دارد.

اگر behavior خارج از pipeline تغییر کند، Governance شکسته است.

execution system بالغ، هر artifact مؤثر بر behavior را مثل production artifact version می‌کند، از rollout stage عبور می‌دهد، impact metadata و telemetry دارد و rollback path مشخص نگه می‌دارد.

در آن صورت سازمان فقط نمی‌پرسد «چه codeای deploy شد؟» بلکه می‌تواند بپرسد «هنگام این تصمیم دقیقاً چه behaviorی فعال بود؟»

سیستم سوم: Evaluation Layer

سیستم سوم تعیین می‌کند autonomy چه زمانی می‌تواند منطقی افزایش پیدا کند.

Outcome Governance در ظاهر ساده است: «آیا ایجنت کمک کرد؟»

اما usage به تنهایی کافی نیست.

token volume کافی نیست.

PR count کافی نیست.

feedback مثبت چند مهندس هم کافی نیست.

evaluation واقعی باید روی capability و version انجام شود.

metricهای عملی می‌توانند شامل این موارد باشند:

  • accept rate
  • rework rate
  • refusal rate
  • escalation rate
  • rollback involvement
  • bounded-autonomy respect rate
  • cost per completed task
  • time-to-done delta
  • evidence completeness

این metricها visibility می‌دهند، اما برای افزایش autonomy کافی نیستند.

برای آن به behavioral benchmarking نیاز است.

single-prompt test برای بسیاری از agent workloadها ضعیف است، چون رفتار واقعی طی چند step، چند tool، permission و context shift شکل می‌گیرد. scenarioها باید شبیه کار واقعی باشند:

  • تغییر یک service زیر policy constraint
  • مدیریت conflicting knowledge
  • refusal درست وقتی autonomy boundary رد می‌شود
  • escalation هنگام ambiguity
  • recovery از tool failure
  • ماندن داخل budget و scope در task طولانی
  • تکمیل کار همراه trace کامل

deterministic signal و LLM-as-a-judge هر دو مفیدند، اما جای هم را نمی‌گیرند.

deterministic check برای boundary violation، tool-use correctness، trace completeness، rollback و policy compliance مناسب‌تر است.

LLM judge برای کیفیت explanation، completeness، citation adequacy یا tradeoff reasoning با rubric مشخص مفید است.

evaluation system خوب از هر دو استفاده می‌کند.

و drift را هم اندازه می‌گیرد.

agent behavior ممکن است بدون code change تغییر کند:

  • upstream model عوض شود
  • prompt تغییر کند
  • retrieval corpus جابه‌جا شود
  • tool authority بیشتر شود
  • task distribution تغییر کند
  • policy object update شود

پس evaluation باید به capability version و behavior-affecting release متصل باشد.

بدون این لایه، autonomy scaling سیاسی می‌شود.

demo بهتر برنده می‌شود. vendor پرصداتر برنده می‌شود. tool محبوب حتی وقتی rework و rollback آن بالا می‌رود همچنان اختیار بیشتری می‌گیرد.

بدون evaluation، autonomy تبدیل به negotiation می‌شود، نه decision.

کنار هم گذاشتن Governance Stack واقعی

این سه سیستم به هم وابسته‌اند.

Knowledge System اطلاعات canonical، validated و machine-usable را با ownership، provenance و authority منتشر می‌کند.

Execution System همان knowledge را مصرف می‌کند، decision evidence می‌سازد، artifactهای مؤثر بر behavior را version می‌کند و مسیر request تا production و rollback را حفظ می‌کند.

Evaluation System traceها و runtime outcome را می‌خواند، capability versionها را مقایسه می‌کند، regression را پیدا می‌کند و evidence را وارد تصمیم autonomy می‌کند.

dependency روشن است:

Knowledge، Output را ممکن می‌کند. Execution، Change را ممکن می‌کند. Evaluation، Outcome را ممکن می‌کند.

در عمل loop این‌طور است:

  1. governed knowledge وارد retrieval و runtime می‌شود
  2. runtime structured decision trace تولید می‌کند
  3. pipeline تمام artifactهای مؤثر بر behavior را version و promote می‌کند
  4. observability و incident system با correlation ID مشترک به trace وصل می‌شوند
  5. evaluation با metric و behavioral scenario capability version را score می‌کند
  6. نتیجه Governance وارد version بعدی capability می‌شود

این loop operating system واقعی Agent Governance است.

نه committee.

نه slide deck.

نه approval template.

Practical Build Order

قرار نیست از روز اول یک governance platform کامل بسازید.

minimum viable substrate را به ترتیبی بسازید که هر مرحله evidence مرحله بعد را فراهم کند.

۱. Structured knowledge، حداقل نسخه قابل استفاده

از policy و operating documentهایی شروع کنید که ایجنت واقعاً مصرف می‌کند. ownership، provenance، freshness، lifecycle state و یک schema کوچک اضافه کنید. ontology کامل می‌تواند بعداً ساخته شود. canonical source باید از اول مشخص باشد.

۲. Decision trace schema

minimum event contract برای decisionهای مهم تعریف کنید. trace ID، capability version، knowledge ref، input، output و uncertainty را ثبت کنید.

۳. End-to-end correlation

یک correlation ID را از request تا plan، PR، CI، deploy، incident و rollback حمل کنید. اگر lifecycle قابل join نیست، audit قابل اتکا هم ندارید.

۴. Behavior versioning در pipeline

prompt، model، tool، routing rule، retrieval artifact و policy object را وارد همان promotion model کنید که code دارد. silent swap و in-place production change نباید وجود داشته باشد.

۵. Outcome metrics + benchmarking

با چند metric capability-level و یک مجموعه کوچک multi-step scenario شروع کنید. هر behavior-affecting change را با آن بسنجید و بر اساس evidence تصمیم بگیرید autonomy افزایش یابد، کاهش پیدا کند یا ثابت بماند.

از dashboard شروع نکنید. از evidence شروع کنید.

جمع‌بندی

Agent Governance با اضافه کردن مداوم control در اطراف سیستم به بلوغ نمی‌رسد.

بلوغ زمانی ایجاد می‌شود که behavior قابل توضیح، trace و اندازه‌گیری باشد.

تیمی که در identity، permission و approval gate متوقف شده معمولاً یک control با maturity فاصله ندارد. مشکلش نبود infrastructure لازم برای لایه‌های عمیق‌تر است.

پس فقط نپرسید:

«کدام control را نداریم؟»

این سؤال‌ها را هم بپرسید:

  • آیا agent از knowledgeای استفاده می‌کند که واقعاً قابل اعتماد است؟
  • آیا می‌توانیم توضیح دهیم یک decision چگونه به production change تبدیل شد؟
  • آیا می‌توانیم ثابت کنیم capability outcome را بهتر کرده؟
  • آیا این سه پاسخ با evidence پایدار به هم متصل‌اند؟

اگر پاسخ منفی است، مسئله Governance نظری نیست.

مسئله معماری است.

مقاله بعدی وارد مرز اجرایی بعدی می‌شود: policy ممکن است روی کاغذ وجود داشته باشد و در runtime کاملاً شکست بخورد.

قسمت بعدی: The Executable Policy Layer: Why Governance Dies Before Runtime

نسخه اصلی این مقاله در ۶ مه ۲۰۲۶ توسط Reza Arani در Medium منتشر شده است. این نسخه برای Aipolix به‌عنوان قسمت سوم مجموعه AI Governance in an AI-Native Software Development Company بازنویسی و بومی‌سازی شده است.