بیشتر برنامه‌های Governance در یک نقطه مشترک شکست می‌خورند.

Policy نوشته می‌شود. approve می‌شود. منتشر می‌شود. بعد runtime تصمیمی می‌گیرد که هیچ‌وقت آن policy را ارزیابی نکرده است.

این همان handoffای است که Governance هرگز انجام نمی‌دهد.

یک policy می‌تواند دقیق، از نظر حقوقی بررسی‌شده و از نظر فنی منطقی باشد، اما اگر execution path نتواند قبل از action آن را evaluate کند، عملاً چیزی را govern نمی‌کند.

این مقاله بخش چهارم از مجموعه ده‌قسمتی AI Governance در یک شرکت نرم‌افزاری AI-Native است. بخش سوم، چرا بیشتر تیم‌ها در Action Controls متوقف می‌شوند، Knowledge، Execution و Evaluation را به‌عنوان زیرساخت لایه‌های عمیق‌تر معرفی کرد. این بخش سراغ مرز بعدی می‌رود: تبدیل policy به رفتار runtime.

اگر policy در documentation متوقف شود، AI Governance ندارید. فقط formatting دارید.

شکاف اجرای دستی

بیشتر سازمان‌ها policy دارند.

acceptable-use rule، الزام‌های data handling، approval matrix، production access control، security standard و escalation procedure وجود دارند. مشکل کمبود intent نیست.

مشکل translation است.

انسان می‌تواند قانونی مثل «تغییر production که روی customer data اثر می‌گذارد باید توسط service owner تأیید شود» را در context تفسیر کند. از یک agent نمی‌شود انتظار داشت هر بار همان تفسیر را از prose با اطمینان بازسازی کند.

همان rule ممکن است به runtime factهای مختلف وابسته باشد:

  • کدام agent در حال عمل است
  • کدام capability version فعال است
  • کدام user درخواست را delegate کرده
  • کدام tool فراخوانی می‌شود
  • action فقط read است یا state را تغییر می‌دهد
  • target کدام environment است
  • data classification چیست
  • blast radius ممکن چقدر است
  • چه مقدار budget باقی مانده
  • آیا exception فعالی وجود دارد
  • کدام policy version در force است

این state از یک request به request بعدی تغییر می‌کند.

wiki page آن را evaluate نمی‌کند.

system prompt آن را enforce نمی‌کند.

و human approval queue وقتی agentها دائماً کار می‌کنند، برای هر action کم‌ریسک scale نمی‌شود.

به همین دلیل Governance قبل از runtime می‌میرد. سازمان policy intent دارد، اما بین intent و side effect یک decision boundary اجرایی ندارد.

Executable Policy واقعاً چیست

Executable Policy یعنی همه governance documentها را به code تبدیل کنیم؟ نه.

یعنی ruleهایی را که باید رفتار machine را تغییر دهند مشخص کنیم و آن‌ها را در قالبی قرار دهیم که runtime بتواند به‌شکل consistent ارزیابی کند.

یک executable policy مفید هفت ویژگی دارد.

خارج از model است. model می‌تواند action را propose کند، اما نباید authority نهایی برای مجاز بودن همان action باشد.

Structured است. decision باید روی attributeهای مشخص و typed intent انجام شود، نه paragraphای که model مجبور است دوباره تفسیر کند.

State-aware است. یک intent ممکن است در staging مجاز و در production غیرمجاز باشد. با budget کافی allow شود و وقتی budget نزدیک cap است approval بخواهد.

Versioned است. هر decision باید به policy version دقیق خودش قابل نسبت دادن باشد.

در boundaryهای لازم deterministic است. model می‌تواند probabilistic plan بسازد. hard permission boundary نباید به confidence مدل وابسته باشد.

Enforceable است. verdict از نوع deny باید واقعاً tool call یا state change را متوقف کند.

Evidence تولید می‌کند. سیستم باید ثبت کند چه چیزی evaluate شد، کدام rule match شد، verdict چه بود و بعد چه اتفاقی افتاد.

هدف این نیست که همه governance questionها deterministic شوند. بسیاری از business decisionها همچنان judgment انسانی می‌خواهند.

هدف این است که enforcement boundary صریح باشد.

Probabilistic reasoning می‌تواند پیشنهاد بدهد. deterministic control تعیین می‌کند چه چیزی اجازه دارد واقعاً اتفاق بیفتد.

معماری Runtime Policy

معماری از زبان پیچیده Governance ساده‌تر است.

یک flow مفید:

request -> structured intent -> policy decision -> enforcement -> action -> evidence

agent یا orchestration layer ابتدا intent را به structured data تبدیل می‌کند. Policy Decision Point آن intent را با identity، scope، environment، runtime state و policy bundle فعال evaluate می‌کند. Policy Enforcement Point قبل از side effect verdict را اعمال می‌کند.

Policy decision نباید فقط yes/no باشد.

verdictهای مفید:

  • allow: داخل scope مصوب ادامه بده
  • deny: action را با reason ساخت‌یافته block کن
  • require approval: تا تأیید authority مشخص pause کن
  • defer: چون runtime condition لازم موجود نیست فعلاً اجرا نکن
  • degrade: اگر policy اجازه می‌دهد از مسیر کم‌ریسک‌تر یا کم‌هزینه‌تر ادامه بده
  • quarantine: artifact تولید شود اما تا review وارد live path نشود

نام‌ها می‌توانند در هر سازمان فرق کنند. مهم این است که رفتار هر verdict قبل از incident تعریف شده باشد.

verdictی که فقط در log وجود دارد enforcement نیست.

Decision Point باید چه چیزهایی بداند

policy evaluator فقط به اندازه stateای که می‌بیند خوب است.

برای actionهای مهم agent معمولاً چند گروه attribute لازم است.

Identity و delegation

  • agent identity
  • capability identity و version
  • human یا service درخواست‌دهنده
  • delegated authority
  • expiry و scope delegation

Action

  • tool درخواستی
  • operation
  • target resource
  • side effect مورد انتظار
  • data classهایی که read یا write می‌شوند

Environment

  • development، staging یا production
  • tenant یا customer scope
  • region
  • criticality سرویس

Risk و autonomy

  • action class
  • autonomy tier
  • حداکثر blast radius
  • required evidence level
  • human approval requirement

Runtime state

  • cost و token budget باقی‌مانده
  • time یا step budget باقی‌مانده
  • rate-limit headroom
  • incident یا maintenance state
  • recent refusal یا anomaly signal

Governance state

  • policy bundle فعال
  • exception recordها
  • expiry time
  • required controlها
  • owner policy

به همین دلیل runtime governance نمی‌تواند فقط داخل prompt باشد. prompt این state را به‌صورت reliable مالک نیست و حتی اگر آن را ببیند نباید بتواند boundary خودش را waive کند.

Prompt مرز Permission نیست

یک implementation رایج با instruction شروع می‌شود:

«بدون approval به production deploy نکن.»

این instruction مفید است. enforcement mechanism نیست.

model ممکن است بد بفهمد. prompt دیگری با آن conflict داشته باشد. tool path دیگری expose کند. retrieved content agent را manipulate کند. host update precedence instructionها را عوض کند.

هیچ‌کدام نباید production boundary را به suggestion تبدیل کنند.

separation درست:

  • prompt و skill رفتار را guide می‌کنند
  • tool capability را expose می‌کند
  • policy مشخص می‌کند capability در context فعلی قابل استفاده هست یا نه
  • enforcement جلوی side effect غیرمجاز را می‌گیرد

این separation test را هم ساده‌تر می‌کند.

می‌توانید evaluate کنید model معمولاً instruction را رعایت می‌کند.

جداگانه می‌توانید ثابت کنید runtime حتی وقتی model رعایت نمی‌کند action ممنوع را block می‌کند.

این دو guarantee متفاوت‌اند و Governance به هر دو نیاز دارد.

Policy باید در چند Gate حضور داشته باشد

runtime آخرین enforcement boundary است، اما نباید اولین جایی باشد که policy ظاهر می‌شود.

سیستم بالغ policy را در کل delivery lifecycle بازاستفاده می‌کند.

Authoring

policy باید روی چیزی که agent اجازه دارد propose کند اثر بگذارد.

coding agent باید از اول بداند dependency تأییدنشده، restricted data domain یا production secret path خارج از scope است. feedback زودهنگام waste را کم می‌کند.

Pull Request و CI

pipeline باید policyهای machine-checkable را قبل از merge evaluate کند.

architecture boundary، dependency restriction، evidence requirement، security control و required reviewer اینجا قرار می‌گیرند.

Deployment

policy باید تصمیم بگیرد artifact اجازه ورود به environment را دارد یا نه.

risk classification، test evidence، rollout strategy، owner approval و rollback readiness می‌توانند input باشند.

Runtime

runtime action واقعی را با state فعلی evaluate می‌کند.

اینجاست که identity، target، budget، environment، tool، exception و live condition به هم می‌رسند.

policy language لازم نیست در همه layerها یکسان باشد، اما policy model باید coherent باشد.

اگر authoring چیزی را ممنوع کند و runtime allow کند، policy conflict دارید.

اگر runtime چیزی را block کند که CI approve کرده، evidence باید توضیح دهد چه stateای تغییر کرده است.

Behavior خودش Deployment Surface است

Policy باید بداند code تنها چیزی نیست که behavior را تغییر می‌دهد.

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

  • model version
  • system prompt
  • instruction file
  • skill
  • rule
  • tool schema
  • tool permission
  • routing logic
  • retrieval configuration
  • knowledge source
  • policy bundle
  • runtime host version

model swap behavior را تغییر می‌دهد.

skill update behavior را تغییر می‌دهد.

permission جدید behavior را تغییر می‌دهد.

policy bundle هم behavior را تغییر می‌دهد.

اگر behavior تغییر کرده، چیزی deploy شده است.

پس خود policy artifactها هم release discipline می‌خواهند.

version، owner، test، promotion stage، rollback و traceability لازم دارند.

Policy changeای که runtime behavior را تغییر می‌دهد production change است.

Skills، Rules و Instructions خود Governance نیستند

agent frameworkها artifactهایی با نام skill، rule، instruction، guardrail یا policy expose می‌کنند.

این‌ها مفیدند چون human intent را machine-consumable می‌کنند.

اما اسم یک instruction را policy گذاشتن، آن را enforcement boundary نمی‌کند.

سؤال مفید این نیست:

«rules file داریم؟»

سؤال‌های مفید:

  • owner آن کیست؟
  • versioned است؟
  • چگونه test می‌شود؟
  • agent می‌تواند ignore کند؟
  • tool می‌تواند bypass کند؟
  • runtime قبل از side effect آن را evaluate می‌کند؟
  • deny واقعاً execution را متوقف می‌کند؟
  • می‌توانیم ثابت کنیم کدام version فعال بوده؟
  • rollback داریم؟

skill، rule، agent instruction و tool constraint بخشی از behavior surface هستند.

Governance operating system اطراف این artifactهاست.

Exception باید First-Class باشد

هر policy system جدی eventually exception لازم دارد.

اشتباه این است که exception را informal override بدانیم.

«برای این incident موقتاً دسترسی بده» می‌شود Slack message.

«برای migration این tool را allow کن» می‌شود config edit.

«این بار approval را skip کن» می‌شود bypassای که بعداً کسی نمی‌تواند توضیح دهد.

exception governed باید object مشخصی باشد با:

  • requester
  • approver
  • reason
  • policy affected
  • scope دقیق
  • start time
  • expiry time
  • allowed action class
  • evidence requirement
  • revocation path

exception باید از ruleی که override می‌کند narrowتر باشد.

باید خودکار expire شود.

runtime هم باید آن را مثل بقیه policy inputها evaluate کند.

exception بدون expiry یک policy change است که خودش را temporary جا زده.

Policy Change به Progressive Delivery نیاز دارد

policy بد می‌تواند به اندازه code بد production را خراب کند.

deny rule خیلی broad می‌تواند workflow critical را متوقف کند.

condition ناقص می‌تواند action خطرناک را allow کند.

threshold جدید می‌تواند approval flood ایجاد کند.

پس policy نباید مستقیم از authoring به full enforcement برود.

sequence امن‌تر:

  1. test روی scenarioهای شناخته‌شده
  2. replay روی traceهای اخیر
  3. shadow policy جدید بدون enforcement
  4. compare verdict قدیم و جدید
  5. canary enforcement روی scope محدود
  6. promote وقتی evidence قابل قبول است
  7. rollback وقتی refusal، escalation یا incident signal بدتر شد

این همان progressive delivery است که روی Governance اعمال شده.

artifact عوض شده، اصل engineering نه.

هر Verdict باید Evidence بسازد

policy بدون evidence نوع دیگری از mystery تولید می‌کند.

runtime برای actionهای مهم باید decision record فشرده بسازد.

record مفید شامل:

  • root trace ID
  • policy decision ID
  • agent و capability identity
  • structured intent
  • state attributeهای relevant
  • policy bundle و version
  • matched rule یا reason
  • verdict
  • enforcement result
  • human approval reference در صورت نیاز
  • exception reference در صورت نیاز
  • timestamp

قرار نیست همه context را log کنید.

فقط آن‌قدر ثبت کنید که بتوان بازسازی کرد چرا action allow، block یا escalate شده است.

این evidence باید به همان trace model مربوط به execution و change وصل شود.

در incident review سؤال از:

«چه شد؟»

تبدیل می‌شود به:

«کدام policy تحت چه stateای این action را allow کرد و چرا؟»

این سؤال بسیار مفیدتر است.

Failure Modeها تکراری‌اند

وقتی executable policy وجود ندارد، failureها معمولاً آشنا هستند.

Policy-in-a-wiki: rule وجود دارد و همه قبولش دارند، اما runtime هیچ‌وقت آن را نمی‌خواند.

Policy-in-a-prompt: rule هست، اما همان سیستمی که constrained می‌شود مسئول تفسیر و رعایت آن هم هست.

Split enforcement: یک tool policy check دارد و path دیگری به همان side effect بدون check می‌رسد.

Stale state: decision نسبت به state ناقص یا قدیمی منطقی است.

Silent exception: override owner، expiry یا trace ندارد.

Mutable policy: rule in-place تغییر می‌کند و کسی نمی‌تواند ثابت کند دیروز چه versionی حاکم بوده.

Evidence-free deny: سیستم work را block می‌کند اما نمی‌تواند بگوید کدام rule فعال شده و فشار برای bypass ایجاد می‌شود.

Evidence-free allow: action موفق می‌شود اما proofی برای authorization وجود ندارد.

pattern مشترک روشن است.

policy به‌عنوان intent وجود داشته.

به‌عنوان executable control وجود نداشته.

ترتیب عملی ساخت

از encode کردن کل governance manual شروع نکنید.

یک action path مهم را انتخاب کنید و control را واقعی کنید.

۱. Structured Intent تعریف کنید

یک action مهم مثل deploy، write روی customer data، secret rotation یا production tool invocation انتخاب کنید.

action را با typed field نمایش دهید، نه prose.

۲. Policy Decision Point را خارج از Model بگذارید

model propose می‌کند.

evaluator تصمیم می‌گیرد.

authority enforcement را بیرون probabilistic component نگه دارید.

۳. Enforcement Point را قبل از Side Effect بگذارید

deny باید execution را متوقف کند.

روی cooperative refusal حساب نکنید.

۴. حداقل Runtime State را اضافه کنید

identity، action، target، environment، autonomy tier، budget state، policy version و exception state برای شروع کافی‌اند.

attribute جدید را وقتی اضافه کنید که decision واقعی به آن نیاز دارد.

۵. Decision Evidence تولید کنید

برای هر verdict مهم ID بدهید و آن را به execution trace وصل کنید.

allow، deny و approval باید explainable باشند.

۶. Policy Bundle را Version و Test کنید

deterministic policy test اجرا کنید و traceهای اخیر را replay کنید.

bundle را production artifact بدانید.

۷. Shadow، Canary و Promote

قبل از اینکه policy جدید همه‌چیز را کنترل کند ببینید چه خواهد کرد.

progressive rollout داشته باشید و rollback را boring نگه دارید.

این sequence عمداً کوچک است.

هدف ساخت policy empire نیست.

هدف ساخت یک handoff قابل اعتماد بین governance intent و runtime behavior است، بعد توسعه آن.

جمع‌بندی

سخت‌ترین بخش AI Governance نوشتن rule نیست.

سخت‌ترین بخش این است که rule از تماس با execution جان سالم به در ببرد.

policy، principle، review board و approval matrix همه مهم‌اند. اما زمانی Governance می‌شوند که سیستم بتواند قبل از action آن‌ها را با state فعلی evaluate کند، verdict را enforce کند و evidence را نگه دارد.

این همان Executable Policy Layer است.

بین probabilistic behavior و side effect واقعی قرار می‌گیرد.

به runtime state حق رأی می‌دهد.

exception را visible می‌کند.

policy change را deployable و reversible می‌کند.

و به سازمان اجازه می‌دهد در incident به سؤال اصلی پاسخ دهد:

«چرا اجازه داده شد این action اتفاق بیفتد؟»

اگر جواب «چون به agent گفته بودیم درست رفتار کند» باشد، policy layer هنوز وجود ندارد.

اگر جواب به versioned rule، recorded state، enforcement قبل از side effect و trace قابل پیگیری اشاره کند، Governance بالاخره به runtime رسیده است.

Governance چیزی نیست که policy نوشته است. Governance چیزی است که runtime می‌تواند enforce و prove کند.

مقاله بعدی یک لایه به خود agent نزدیک‌تر می‌شود: prompt برای حمل رابطه کامل بین انسان، agent و tool بیش از حد مبهم است.

قسمت بعدی: AI Agents Need Contracts, Not Better Prompts.

نسخه اصلی این مقاله در ۱۸ مه ۲۰۲۶ توسط Reza Arani در Medium منتشر شده است. این نسخه برای Aipolix به‌عنوان بخش چهارم مجموعه AI Governance در یک شرکت نرم‌افزاری AI-Native بازنویسی و بومی‌سازی شده است.