سیاست تیمی، Governance و Adoption مسئولانه

سیاست خوب نه «AI را برای همه اجباری کن» است و نه «هیچ‌چیز را اندازه نگیر». سیاست باید اختیار و مسئولیت را روشن کند: چه ابزار و داده‌ای مجاز است، چه ریسکی نیازمند انسان است، چه auditی نگه داشته می‌شود، و چگونه تیم بدون نظارت تنبیهی بهبود می‌یابد.

## اهداف یادگیری

پس از درس می‌توانی policy تیمی با approved tools/data، risk tier، human owner، audit trail، vendor retention/IP، incident process، adoption تدریجی، DevEx و anti-surveillance بنویسی؛ و بین کنترل معقول و اندازه‌گیری تنبیهی فرق بگذاری.

## جایگاه در چرخه

این درس `Learn → Elicit` را به team scale می‌برد. سیاست، جای قضاوت مهندس یا قوانین امنیتی موجود نیست؛ آن‌ها را قابل‌اجرا و قابل‌ممیزی می‌کند. NIST AI RMF و SSDF زبان risk و governance می‌دهند، اما tierها و ownerهای زیر باید با قانون، قرارداد و دادهٔ واقعی سازمان تطبیق داده شوند.

## اجزای policy حداقلی

**ابزار و دادهٔ مجاز:** فهرست versioned ابزار، surface local/CLI/cloud، MCP allowlist، repositoryهای مجاز، دادهٔ عمومی/داخلی/محرمانه و دادهٔ ممنوع. دادهٔ مشتری و secret در prompt یا log نیست مگر مسیر تاییدشده، کمینه و redacted. **Vendor retention/IP:** چه چیزی ذخیره می‌شود، کجا، چه مدت، برای training استفاده می‌شود یا نه، subprocessors و deletion/export چگونه‌اند؛ Legal و Privacy owner باید ادعا را از قرارداد vendor بررسی کنند، نه از marketing.

**Risk tier:** Tier 0 برای توضیح و draft بدون write؛ Tier 1 برای test/refactor محلی با diff review؛ Tier 2 برای تغییر production code، migration یا دادهٔ داخلی با owner، approval و evidence؛ Tier 3 برای deploy، دسترسی مشتری، export، credential یا تغییر برگشت‌ناپذیر با human-in-the-loop، دو نفر در صورت نیاز، rollback و incident readiness. tier را بر impact و reversibility بگذار، نه برچسب «AI» یا شغل فرد.

**Human owner:** هر task یک owner پاسخ‌گو، reviewer تازه، scope، budget، expiry، approval و stop rule دارد. استفاده از Agent مسئولیت را منتقل نمی‌کند؛ author باید بتواند diff و تصمیم را توضیح دهد.

**Audit trail:** task id، actor/owner، tool/model/version، permission profile، input classification، commit، commands، approvals، outputs، evidence و retention را تا حد لازم نگه دار. secret و دادهٔ اضافی را ثبت نکن. audit immutable یا دست‌کم tamper-evident و دسترسی‌اش محدود باشد.

**Incident process:** stop/revoke، preserve evidence، classify impact، notify owner/security/privacy، contain، recover، review root cause و update control. مثلاً memory poisoning یا prompt injection فقط «prompt بد» نیست؛ اگر داده خارج شده یا deploy ناخواسته رخ داده، incident واقعی است.

## Adoption بدون اجبار کور

با pilot داوطلبانه و کار کم‌خطر شروع کن؛ baseline، eval خصوصی، guardrail و feedback channel داشته باش. سپس دامنه را فقط وقتی گسترش بده که defect، review، cost، user outcome و DevEx قابل‌قبول‌اند. مسیر opt-out، fallback انسانی و آموزش باید وجود داشته باشد. ابزار را به‌خاطر novelty نگه ندار؛ sunset و rollback سیاست هم لازم است.

**DevEx** شامل friction برای setup، زمان feedback، فهم‌پذیری diff، دسترسی به اسناد، استقلال و رضایت کاری است. اگر policy audit سخت یا permission profile نامفهوم باشد، مهندس راه فرعی می‌سازد و ریسک بیشتر می‌شود. اندازه‌گیری باید تیمی/سیستمی و برای بهبود باشد، نه رتبه‌بندی افراد.

## ضدنظارت و anti-surveillance

token، prompt count، LOC، تعداد approval یا زمان حضور را quota بهره‌وری فرد نکن. این‌ها ممکن است telemetry عملیاتی باشند، اما کیفیت و context ندارند و رفتار gaming می‌سازند. دادهٔ telemetry را کمینه، aggregate، retention-limited و شفاف کن؛ هدف، دسترسی، owner و حق اعتراض را اعلام کن. outcomeهای team-level، defect، review burden و user success را با مصاحبه و signalهای کیفی کنار هم بخوان. privacy کارکنان بخشی از security است.

## مثال بد و اصلاح‌شده

بد: «همه باید از یک Agent استفاده کنند؛ هرکس کمتر از ۵۰۰ خط در هفته تولید کرده تحت بررسی است؛ MCP unrestricted است.» این سیاست هم اجبار بی‌دلیل دارد، هم LOC را outcome فرض می‌کند و هم capability خطرناک می‌دهد. خوب: Tier 0/1 pilot، ابزار و data allowlist، owner و fresh review، eval ثابت، opt-out، audit کمینه و dashboard team-level دارد؛ Tier 2/3 بدون approval و rollback اجرا نمی‌شود.

## سناریوی booking-platform

تیم می‌خواهد reschedule را سریع عرضه کند. policy باید کد repository داخلی را در ابزار approved با retention و IP بررسی‌شده مجاز کند، calendar provider و tenant PII را در pilot ممنوع یا anonymize کند، race/migration/deploy را Tier 2/3 بگذارد، owner product و security داشته باشد، audit evidence را نگه دارد و pilot را با flag cohort شروع کند. معیار موفقیت accepted/released time همراه defect، review، cost، user success و DevEx است؛ تعداد خط و prompt معیار فردی نیست.

## آزمایشگاه گام‌به‌گام

۱) ماتریس ابزار/داده/retention/IP بساز. ۲) چهار tier با example، owner، approval، audit و rollback تعیین کن. ۳) incident card برای export ناخواسته و package آلوده بنویس. ۴) adoption pilot با entry/exit criteria، opt-out و fallback مشخص کن. ۵) dashboard team-level طراحی کن که LOC و prompt را performance score نکند. ۶) policy را با دو مهندس، security، privacy و legal بازبینی کن.

خروجی مورد انتظار policy یک‌صفحه‌ای، risk register، audit schema، incident runbook و eval/adoption plan است. **Recovery:** اگر vendor retention نامعلوم است، دادهٔ حساس را متوقف و فقط fixture استفاده کن. اگر pilot defect یا DevEx بد دارد، cohort را pause، rollback و retrospective کن؛ metric را برای پنهان کردن failure تغییر نده.

برای تمرین، policy را در یک فایل محلی و بدون اتصال به سامانهٔ واقعی بررسی کن:

set -euo pipefail
test -f docs/ai-policy.yaml
rg -n 'owner:|risk:|approved|retention|rollback|incident|opt.out' \
  docs/ai-policy.yaml

این فرمان فقط **local/ephemeral read-only check** است و policy نمونه را می‌خواند؛ deploy، ارسال داده یا تغییر permission انجام نمی‌دهد. **Pseudo-command (اجرا نشود):** `policy lint --file docs/ai-policy.yaml --no-network --require-owner --require-expiry --redact-audit` قرارداد lint را نشان می‌دهد. خروجی قابل‌بررسی باید برای هر tier owner، approval، expiry، دادهٔ مجاز، retention/IP، audit، incident و rollback را نشان دهد و موارد مفقود را با line number گزارش کند. اگر retention vendor نامعلوم است، verdict باید `BLOCKED` باشد و pilot با دادهٔ حساس شروع نشود.

برای جلوگیری از تبدیل policy به مانع، هر control را با یک مسیر appeal و owner زمان‌دار همراه کن. بازبینی ماهانه باید بپرسد آیا rule هنوز ریسک واقعی را کاهش می‌دهد، آیا مهندس‌ها workaround می‌سازند، و آیا دادهٔ audit بیش از نیاز نگه داشته می‌شود. تغییر policy نیز باید version، effective date، rationale و rollback داشته باشد؛ governance خودش یک artifact قابل‌بررسی است.

## خطاهای رایج

• policy عمومی بدون owner، expiry و enforcement.
• یک tier برای همهٔ taskها.
• فرض قراردادن vendor retention یا IP.
• audit پر از secret و بدون access control.
• اجباری‌کردن ابزار یا LOC quota.
• rollout سراسری پیش از pilot و fallback.

## Verification

• [ ] approved tools/data، version و vendor retention/IP بررسی شده‌اند.
• [ ] tier، owner، approval، audit و rollback برای هر risk روشن است.
• [ ] incident process و مسیر revoke/notify/preserve evidence وجود دارد.
• [ ] pilot تدریجی، opt-out، fallback و exit criteria دارد.
• [ ] DevEx و outcome تیمی سنجیده و anti-surveillance اعمال شده است.

## تمرین و Rubric

policy اجباری با MCP unrestricted، LOC target، self-approval و بدون incident process را جایگزین کن. پاسخ خوب allowlist و retention/IP، tier و owner، fresh review، audit redacted، incident runbook، pilot/opt-out، معیارهای outcome و منع رتبه‌بندی بر اساس LOC/prompt را مشخص می‌کند.

## جمع‌بندی

Governance خوب اختیار را حذف نمی‌کند؛ آن را به scope، owner، evidence و accountability تبدیل می‌کند. adoption باید تدریجی و قابل‌برگشت باشد و DevEx و حریم کارکنان را همان‌قدر جدی بگیرد که امنیت کد و داده را.

## منابع مستقیم

• [NIST AI RMF 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — چارچوب مدیریت ریسک؛ policy آماده نیست.
• [NIST GenAI Profile](https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.600-1.pdf) — ملاحظات GenAI؛ باید contextualize شود.
• [NIST SSDF](https://csrc.nist.gov/pubs/sp/800/218/final) — توسعهٔ امن؛ جای HR/privacy policy نیست.
• [DORA metrics](https://dora.dev/guides/dora-metrics/) — metricهای delivery؛ برای surveillance فردی طراحی نشده‌اند.
• [SPACE framework](https://doi.org/10.1145/3453928) — productivity چندبعدی؛ metric واحد کافی نیست.

به زبان ساده

Policy مسئولانه ابزار و دادهٔ مجاز، tier ریسک، owner، retention، audit، incident و مسیر opt-out را روشن می‌کند. استفاده از Agent مسئولیت review و تصمیم‌گیری را از انسان یا تیم حذف نمی‌کند.

مثال واقعی

در سیاست فرضی دوره، pilot reschedule با دادهٔ anonymized و flag cohort شروع می‌شود و race، migration و deploy به tierهای نیازمند approval و rollback می‌روند؛ LOC معیار رتبه‌بندی مهندس نیست.