PII/Privacy در Inbox

1. مسئله واقعی: Inbox واحد یعنی سطح تماس بزرگ‌تر با داده شخصی

وقتی پیام‌های چند کانال در یک Inbox جمع می‌شوند، نام، تلفن، آدرس، متن آزاد و حتی مدرک هویتی ممکن است کنار هم قرار بگیرند. خطر اصلی فقط «وجود PII» نیست؛ مشکل زمانی شروع می‌شود که همان فیلدها بدون دلیل روشن به Search، Analytics، Dashboard یا AI Context کپی شوند. این درس یک Guardrail تصمیم‌گیری می‌سازد، نه یک برچسب مبهم «private».

2. مرز درس و Artifact مالک

خروجی این درس Inbox PII Processing & Disclosure Guardrail Matrix v1 است. برای هر فیلد، Source، Purpose، Necessity، Access Role، Disclosure Target، Redaction/Pseudonymization، Retention/Deletion، Search Scope، AI Context Scope، Policy Version و Decision ثبت می‌شود. Executive Docket متعلق به PLN-007 و Rolling Planning Horizons متعلق به PLN-009 است.

3. Personal Data را فیلدبه‌فیلد ببین، نه پیام‌به‌پیام

یک پیام می‌تواند هم داده لازم و هم داده اضافی داشته باشد. «نام تماس» شاید برای داشبورد تعهد لازم باشد، اما تصویر مدرک هویتی برای همان داشبورد لازم نباشد. پس واحد تصمیم، فیلد و Processing Context است؛ نه اینکه کل پیام را یک‌جا مجاز یا ممنوع اعلام کنیم.

4. Purpose قبل از دسترسی می‌آید

قبل از هر استفاده downstream باید Purpose مشخص و قابل‌ردیابی باشد. اگر Purpose خالی، مبهم یا ناسازگار با استفاده پیشنهادی است، دسترسی فنی دلیل کافی برای استفاده نیست. در این حالت Decision باید REVIEW_REQUIRED یا BLOCKED بماند تا شاهد معتبر اضافه شود.

5. اصل Purpose Limitation در مرز حقوقی این درس

Article 5 GDPR می‌گوید داده شخصی باید برای اهداف مشخص، صریح و مشروع جمع‌آوری شود و استفاده بعدی با آن اهداف ناسازگار نباشد. این گزاره فقط مرز اصل حقوقی را توضیح می‌دهد؛ این درس ادعا نمی‌کند هر استقرار MAKNOW مشمول GDPR است یا از نظر حقوقی compliant است.

6. Data Minimisation یعنی «فقط آنچه لازم است»

Article 5 همچنین بر adequate، relevant و limited to what is necessary تأکید می‌کند. در Matrix، Necessity باید جدا از Convenience ثبت شود. اگر یک AI Drafting Feature برای ساخت پیش‌نویس فقط به خلاصه تعهد نیاز دارد، ارسال تصویر مدرک هویتی صرفاً چون در Inbox موجود است قابل‌قبول نیست.

7. Access Role و Disclosure Target را از هم جدا کن

اینکه یک کاربر داخلی مجاز به دیدن یک فیلد است، خودبه‌خود به معنی مجازبودن ارسال آن فیلد به یک Search Index یا AI Context نیست. Access Role می‌گوید «چه کسی می‌تواند ببیند» و Disclosure Target می‌گوید «داده به کجا می‌رود». هر دو باید با Purpose و Necessity سازگار باشند.

8. Redaction و Pseudonymization ابزار کاهش افشا هستند

وقتی شناسایی مستقیم لازم نیست، می‌توان بخشی از داده را Mask/Redact کرد یا شناسه جایگزین به‌کار برد. این تکنیک‌ها مجوز پردازش ایجاد نمی‌کنند؛ فقط پس از روشن‌شدن Purpose و Scope می‌توانند Exposure را کم کنند. اگر اساس استفاده نامعلوم است، Mask کردن نباید REVIEW_REQUIRED را به ALLOW تبدیل کند.

9. Search Scope و AI Context Scope باید مستقل باشند

یک فیلد ممکن است برای نمایش عملیاتی لازم باشد ولی نباید در Search Index طولانی‌مدت یا Prompt Context یک مدل قرار گیرد. Matrix باید جداگانه مشخص کند چه چیزی searchable است و چه چیزی وارد AI Context می‌شود. «همه چیز برای راحتی جست‌وجو» یک shortcut مردود است.

10. Retention و Deletion بخشی از تصمیم هستند، نه housekeeping

Storage Limitation یعنی نگهداری باید با Purpose و نیاز واقعی محدود شود. Retention Rule، Retention Until و Deletion Trigger باید قابل‌بررسی باشند. اگر Rule منقضی شده اما نسخه مشتق‌شده در Search Index باقی مانده، تصمیم BLOCKED است تا حذف لازم انجام و Audit Event ثبت شود.

11. Policy Version و Provenance جلوی تصمیم بی‌تاریخ را می‌گیرند

هر Decision باید به Policy Version و Source Evidence مشخص متصل باشد. اگر Policy Version وجود ندارد یا معلوم نیست کدام قاعده اعمال شده، نتیجه نباید «ALLOW» حدسی باشد. REVIEW_REQUIRED یعنی سیستم صادقانه می‌گوید شواهد تصمیم هنوز بسته نشده است.

12. Worked Example: Dashboard کمینه، AI Context محدود

فرض کنید Inbox شامل contact_name، phone، delivery_address، message_body و identity_document است. Dashboard فقط contact_name و obligation_status لازم دارد؛ AI Drafting فقط خلاصه غیرحساس تعهد را می‌گیرد. identity_document برای AI ضروری نیست و BLOCKED می‌شود. تلفن می‌تواند در نمای مجاز نمایش داده شود اما از AI Context حذف یا Mask شود.

13. سه حالت تصمیم را دقیق نگه دار

ALLOW_MINIMIZED یعنی Purpose، Necessity، Role، Target و Retention شواهد کافی دارند و فقط حداقل فیلد لازم منتشر می‌شود. BLOCKED یعنی یک مانع قطعی مثل Role غیرمجاز، داده غیرضروری یا Retention منقضی وجود دارد. REVIEW_REQUIRED یعنی اطلاعات تعیین‌کننده مثل Purpose، Policy Version یا Authority هنوز حل نشده است.

14. Failure Probeهای قطعی

چهار shortcut باید رد شوند: (۱) ارسال فیلد غیرضروری مدرک هویتی به AI Context؛ (۲) حذف Purpose در حالی که full downstream access باقی مانده؛ (۳) منقضی‌شدن Retention Rule در حالی که Search Index copy حفظ شده؛ (۴) تغییر Recipient Role به نقشی بدون Access بدون تغییر Disclosure Plan. هیچ‌کدام نباید بی‌صدا به ALLOW تبدیل شوند.

15. Transfer: حذف Message Body، حفظ Minimal Obligation Record

در Transfer، متن‌های قدیمی پیام باید از یک Search Index مشتق‌شده حذف شوند اما یک رکورد حداقلی و auditable از تعهد طبق Retention Rule متفاوت باقی می‌ماند. Baseline را کپی نکن: allowed fields، Search Scope، deletion evidence و Audit Event را از نو محاسبه کن. خروجی باید نشان دهد چه چیزی حذف شد، چه چیزی ماند، برای چه Purpose و تحت کدام Rule.