فکر می‌کنید AI Governance دارید؟ ندارید.

اگر یک ایجنت pull request را باز کند، ایجنت دیگری آن را deploy کند و هیچ‌کس نتواند دقیق توضیح دهد چرا آن تغییر وارد production شد، شما AI Governance ندارید.

شما automation دارید که فقط اسم بهتری روی آن گذاشته‌اید.

این تفاوت مهم است، چون توسعه نرم‌افزار agentic با سرعتی جلو می‌رود که بسیاری از کنترل‌های عملیاتی سازمان‌ها برای آن طراحی نشده‌اند. خیلی از تیم‌ها تصور می‌کنند governed هستند چون ایجنت‌ها با SSO یا service account وارد می‌شوند، repository permission دارند و هنوز یک انسان deployment را approve می‌کند. این‌ها کنترل‌های مفیدی هستند، اما یک سیستم Governance نیستند.

این نوشته بخش اول از مجموعه ده‌قسمتی AI Governance در یک شرکت نرم‌افزاری AI-Native است.

مدل، operating system شما نیست. pipeline اطراف آن است.

یک عصر سه‌شنبه آشنا

یک شرکت fintech متوسط را تصور کنید. یک مهندس ارشد از IDE agent می‌خواهد مسیر checkout را سریع‌تر کند. ایجنت سرویس را می‌خواند، یک database call را بازنویسی می‌کند، pull request می‌سازد و summary تمیزی تحویل می‌دهد. تست‌ها سبز هستند. هم‌تیمی diff را مرور می‌کند و approve می‌کند.

تغییر merge می‌شود.

یک deploy agent آن را برمی‌دارد، روی canary می‌فرستد، error spike واضحی نمی‌بیند و rollout را ادامه می‌دهد. همه‌چیز عادی است تا زمانی که latency بالا می‌رود و کاربران timeout می‌گیرند. تیم on-call rollback می‌کند و سرویس برمی‌گردد.

از نظر فنی، incident حل شده است.

اما از نظر ساختاری، Governance شکست خورده است.

حالا سؤال‌ها شروع می‌شوند: واقعاً چه کسی این تغییر را نوشته؟ ایجنت قبل از تصمیم چه contextی را خوانده بود؟ کدام model version، prompt، skill و tool configuration فعال بود؟ چرا deploy agent با وجود اولین نشانه‌های drift تغییر را promote کرد؟ چند تغییر دیگر در همین ماه دقیقاً از همین مسیر عبور کرده‌اند؟

بیشتر تیم‌ها برای بخشی از این سؤال‌ها جواب دارند، اما تعداد کمی می‌توانند همه را سریع و با evidence پاسخ دهند.

خطر دقیقاً همین‌جاست. لازم نیست کسی بی‌احتیاط باشد. هر تصمیم محلی می‌تواند منطقی به نظر برسد، در حالی که کل سیستم همچنان ungoverned است.

یک نیروی کار غیرانسانی وارد pipelineای شده که برای انسان طراحی شده است. کنترل‌هایی که در سرعت انسانی قابل تحمل بودند، در سرعت ایجنت شکننده می‌شوند.

ریسک فقط خود ایجنت نیست. این pipeline است که blast radius را تعیین می‌کند.

چرا AI Safety برای سازمان مهندسی کافی نیست

AI Safety مهم است، اما با operational governance داخل یک شرکت نرم‌افزاری یکی نیست.

برای یک engineering leader که مدل را از API یا developer tool مصرف می‌کند، سطح اصلی کنترل معمولاً model weights نیست. چیزی که سازمان کنترل می‌کند سیستم اطراف مدل است: identity، tool scope، data access، skillها، policyها، approval gateها، deployment flow، log، rollback و kill switch.

این تفاوت تعیین می‌کند Governance باید کجا ساخته شود.

۱. Safety به مدل نگاه می‌کند؛ عملیات باید سیستم را govern کند

سؤال «آیا مدل aligned است؟» می‌تواند مهم باشد، اما VP Engineering معمولاً نه وزن‌های مدل را می‌بیند و نه می‌تواند آن‌ها را تغییر دهد.

اما می‌تواند pipeline را تغییر دهد.

می‌تواند تعیین کند ایجنت به چه toolهایی دسترسی دارد، کدام repository را تغییر می‌دهد، چه داده‌ای را می‌خواند، چه evidenceای قبل از merge لازم است، چه شرایطی deployment را block می‌کند و چه کسی می‌تواند دسترسی را revoke کند.

اگر سازمان نمی‌تواند مدل را تغییر دهد، مدل نمی‌تواند control surface اصلی عملیات باشد.

۲. ایجنت معمولاً ضعف‌های موجود را تقویت می‌کند

سیستم agentic لازم نیست یک failure mode کاملاً جدید اختراع کند. کافی است با سرعت بیشتر از credential ضعیف، approval ناقص، provenance گمشده، tool بدون boundary و change control طراحی‌شده برای انسان عبور کند.

ایجنت ضعف را آشکار می‌کند. pipeline میزان خسارت را تعیین می‌کند.

۳. خاموش کردن با مدیریت پیامدها فرق دارد

kill switch لازم است، اما سؤال‌های سخت بعد از استفاده از آن شروع می‌شوند.

ایجنت قبل از توقف چه stateای را تغییر داده؟ چه artifactهایی ساخته؟ کدام downstream systemها را لمس کرده؟ چه چیزهایی خودکار rollback می‌شوند و کدام بخش recovery دستی می‌خواهد؟ آیا می‌توان ثابت کرد همه این اقدامات تحت کدام policy version انجام شده‌اند؟

خاموش کردن ایجنت معادل govern کردن چیزهایی نیست که قبلاً به حرکت درآورده است.

تعریف عملی AI Governance در مهندسی AI-Native

یک تعریف کاربردی این است:

AI Governance مجموعه کنترل‌ها، شیوه‌های عملیاتی و disciplineهای اندازه‌گیری است که کار agent-assisted و agent-autonomous را با سرعت خود ایجنت‌ها قابل توضیح، محدود، قابل بازگشت و قابل بهبود می‌کند.

این چهار ویژگی از یک policy document عمومی مهم‌ترند.

قابل توضیح

برای هر تغییر مهم باید بتوان گفت چه کسی یا چه چیزی عمل کرده، با چه identity، تحت کدام model، prompt، skill، tool و policy version، با چه evidence و با approval چه کسی.

اگر agent-authored change به محض رسیدن به main تبدیل به یک mystery شود، Governance از قبل شکسته است.

محدود

هر ایجنت باید autonomy boundary مشخص داشته باشد: tool scope، repository scope، data scope، credential scope، cost envelope و approval threshold.

اگر ایجنت بتواند بی‌سروصدا خارج از lane خود حرکت کند، شما boundary ندارید؛ فقط intention دارید.

قابل بازگشت

انسان باید بتواند agent-authored change را بدون همکاری خود ایجنت متوقف و undo کند.

canary، auto-rollback، artifact غیرقابل‌تغییر، kill switch مستقل و restore point شناخته‌شده بخشی از این لایه هستند.

قابل بهبود

Governance باید نشان دهد کدام ایجنت ارزش ایجاد می‌کند، کدام drift کرده و کدام باید autonomy بیشتر یا کمتر بگیرد.

usage chart کافی نیست. outcome، incident signal، review quality، escalation rate و evidence واقعی از تأثیر autonomy لازم است.

Trust احساس نیست؛ یک ویژگی سیستم است.

چهار جایی که بیشتر تیم‌ها exposed هستند

Operational agent governance را می‌توان در چهار دسته دید.

Access و Identity می‌پرسد ایجنت کیست، با چه credentialی کار می‌کند و به چه سیستم‌هایی دسترسی دارد. بیشتر سازمان‌ها در این بخش حداقل بخشی از کنترل‌ها را دارند.

Action و Change می‌پرسد ایجنت اجازه چه کاری دارد، blast radius چقدر است و actionها چگونه approve یا block می‌شوند. این کنترل‌ها اغلب از workflow انسانی به ارث رسیده‌اند و برای throughput ایجنت کافی نیستند.

Output و Evidence می‌پرسد ایجنت چه تولید کرده و آیا سازمان می‌تواند input، تصمیم، evidence و approval منتهی به آن output را بازسازی کند. بسیاری از برنامه‌های Governance در این لایه ضعیف می‌شوند.

Outcome و Learning می‌پرسد آیا ایجنت واقعاً سیستم را بهتر کرده، ریسک ساخته، drift کرده یا باید autonomy آن تغییر کند. این بخش اغلب با anecdote و vendor dashboard جایگزین می‌شود.

یک سؤال ساده برای هر چهار دسته:

اگر auditor، regulator یا incident reviewer همین امروز evidence بخواهد، آیا می‌توانیم در کمتر از یک ساعت آن را ارائه کنیم؟

اگر پاسخ منفی است، governance debt دارید.

failure در عمل چه شکلی دارد

این failureها معمولاً عجیب نیستند.

Mystery merge: کدی وارد production می‌شود و کسی نمی‌تواند دقیق توضیح دهد ایجنت چرا آن را ساخت یا چرا approve شد.

Audit surprise: compliance لیست تمام autonomous changeهای یک سرویس حساس را می‌خواهد و تیم چند روز برای بازسازی آن زمان لازم دارد.

Silent capability drift: مدل عوض می‌شود، prompt retune می‌شود، tool جدید اضافه می‌شود یا skill scope بیشتری می‌گیرد، بدون اینکه این تغییر مانند production change مدیریت شود.

Cost runaway: loopهای background و chained agentها بودجه را مصرف می‌کنند چون هزینه بعد از وقوع monitor می‌شود، نه به‌عنوان policy input در runtime.

Trust collapse: senior engineerها دیگر به agent-authored work اعتماد نمی‌کنند و همه‌چیز را با سوءظن review می‌کنند؛ در نتیجه benefit بهره‌وری از بین می‌رود.

این‌ها alignment failure انتزاعی نیستند. operational governance failure هستند.

از دوشنبه از کجا شروع کنیم

برای شروع نیازی به transformation program بزرگ نیست. چهار کار بیشتر gapهای اصلی را آشکار می‌کند.

1. flow واقعی را رسم کنید. مسیر واقعی request تا production را با حضور agentها ثبت کنید، حتی مسیرهای غیررسمی و shadow.
2. agentها را مثل employee inventory کنید. owner، scope، credential، data access، kill-switch owner و last review date.
3. یک blast-radius control واقعی نصب کنید. scoped credential، agent-specific canary rule، auto-rollback یا out-of-band kill switch.
4. append-only decision trail بسازید. برای هر تصمیم غیرtrivial ثبت کنید چه خواسته شد، چه انجام شد، چه evidenceی استفاده شد و چه کسی یا چه چیزی approve کرد.

Visibility قبل از control می‌آید.

چیزی که legible نیست، governable هم نیست.

این مجموعه قرار است به کجا برسد

نه مقاله بعدی این مدل را به یک operating system عملی تبدیل می‌کنند: governance layerها، executable policy، agent contract، containment، traceability، change management، budget، metric و maturity model.

هدف کند کردن engineering با governance theatre نیست.

هدف ساخت سیستمی است که بتوان به agent work در سرعت بالا اعتماد کرد.

برنده‌های دوره AI-Native صرفاً شرکت‌هایی نیستند که agent بیشتری دارند. برنده‌ها شرکت‌هایی هستند که می‌توانند کار agentها را بدون تبدیل هر تغییر به committee meeting قابل توضیح، محدود، قابل بازگشت و قابل بهبود نگه دارند.

این همان trust at speed است.

AI Safety می‌پرسد مدل ممکن است چه کاری انجام دهد. Operational AI Governance کنترل می‌کند سیستم شما همین حالا اجازه انجام چه کاری را می‌دهد.

این دو گفتگو متفاوت‌اند و سازمان مهندسی به هر دو نیاز دارد.

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