---
title: "حاکمیت داده در دانابات: ABAC، ماسک اطلاعات شخصی و واژگان حساس، پیش از آنکه سوال به مدل برسد"
description: "حاکمیت داده دانابات: ABAC روی چارت سازمانی، ماسک اطلاعات شخصی، واژگان حساس پیش از مدل، سه سیاست دسترسی و حسابرسی با خروجی Excel و CSV."
url: "https://artinmag.ir/articles/danabot-data-governance-abac-pii-masking"
author: "مرتضی علیزاده"
category: "چت بات"
published: "2026-10-11T05:51:36.9425446"
updated: "2026-10-11T05:51:36.9425447"
lang: "fa"
publisher: "مجله آرتین — شرکت هوش گستر فردا آرتین"
---

# حاکمیت داده در دانابات: ABAC، ماسک اطلاعات شخصی و واژگان حساس، پیش از آنکه سوال به مدل برسد

> حاکمیت داده ماژول دانابات برای کنترل دسترسی و حفاظت از اطلاعات حساس در پرسش و پاسخ سازمانی است. چهار بخش دارد: ABAC روی چارت سازمانی (واحد، پست و سطح طبقه‌بندی کاربر در برابر ویژگی‌های سند)، ماسک اطلاعات شخصی در پاسخ، بررسی واژگان حساس پیش از ارسال سوال به مدل با بازبینی گفتگو و مسدودسازی در شدت بالا، و ردپای حسابرسی با خروجی Excel و CSV.

## سوالی که مدیر امنیت اول می‌پرسد

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

این سوال بی‌جاست؟ نه. یک دستیار هوشمند که به اسناد سازمان دسترسی دارد، در عمل جست‌وجوگری است که هر چیزی را که در دسترسش باشد پیدا و خلاصه می‌کند. اگر دسترسی درست کنترل نشود، همین توانایی که مفید است، به یک نشت اطلاعات سریع و مودبانه تبدیل می‌شود.

ماژول «حاکمیت داده» در [دانابات](https://dana-bot.ir) برای جواب دادن به همین سوال طراحی شده است. هدف این مقاله این است که ببینید دقیقاً چه کار می‌کند، چه چیزی را کنترل نمی‌کند و پیش از فعال‌سازی چه چیزهایی باید در خود سازمان آماده باشد.

## حاکمیت داده یعنی بیشتر از دادن و گرفتن دسترسی

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

ماژول حاکمیت داده به این چهار سوال جواب می‌دهد: ABAC روی چارت سازمانی، ماسک اطلاعات شخصی، واژگان حساس، و ردپای حسابرسی. در ادامه هر کدام را جداگانه می‌بینیم.

## چرا کنترل باید بیرون از خود مدل باشد

یک راه‌حل رایج و ضعیف برای امنیت دستیارهای هوشمند این است که در دستور مدل بنویسند: «اطلاعات محرمانه را فاش نکن.» این روش به قضاوت خود مدل تکیه می‌کند، و مدل یک سامانه‌ی قطعی نیست. ممکن است ده بار درست رفتار کند و بار یازدهم، با یک بازنویسی هوشمندانه‌ی سوال، اشتباه کند.

طراحی دانابات این منطق را وارونه می‌کند: کنترل‌های مهم بیرون از مدل و با قواعد قطعی انجام می‌شوند. دسترسی پیش از جست‌وجو و پیش از نمایش چک می‌شود، یعنی سندی که کاربر مجاز نیست اصلاً در مسیر ساخت پاسخ نمی‌آید. واژگان حساس پیش از ارسال سوال به مدل بررسی می‌شوند. در نتیجه، مدل هیچ‌وقت در موقعیتی قرار نمی‌گیرد که باید «تصمیم بگیرد» آیا چیزی را بگوید یا نگوید.

این فرق مهمی است. در یک مورد، امنیت شما به رفتار احتمالی یک مدل بستگی دارد. در مورد دیگر، به قواعدی که می‌توانید بخوانید، آزمایش کنید و ردپایشان را بررسی کنید.

## ABAC: دسترسی بر اساس ویژگی، نه فقط نقش

مدل‌های ساده‌ی دسترسی بر پایه‌ی نقش‌اند: «مدیر مالی»، «کارشناس»، «ادمین». این مدل در سازمان‌های کوچک کار می‌کند، اما در سازمان‌های بزرگ کم می‌آورد. ABAC یا کنترل دسترسی مبتنی بر ویژگی، تصمیم را بر پایه‌ی ویژگی‌ها می‌گیرد: واحد سازمانی کاربر، پست او، سطح طبقه‌بندی‌اش، و در طرف دیگر ویژگی‌های خود سند.

در دانابات این ویژگی‌ها روی چارت سازمانی سوار می‌شوند. فرض کنید یک سند «محرمانه» برای واحد مالی تعریف شده است. کارشناس مالی با سطح مناسب آن را می‌بیند. همکار او در واحد فروش، حتی اگر نقش مشابهی داشته باشد، نمی‌بیند. و مدیر ارشد یک واحد دیگر با سطح طبقه‌بندی بالا، فقط اگر ویژگی‌هایش با ویژگی‌های سند هم‌خوان باشد دسترسی می‌گیرد.

این روش انعطاف بیشتری دارد: به‌جای نوشتن صدها قاعده‌ی دستی برای هر سند و هر نقش، ویژگی‌ها یک بار تعریف می‌شوند و تصمیم‌ها از روی آن‌ها گرفته می‌شود.

## دو مرحله‌ی کنترل: قبل از جست‌وجو و قبل از نمایش

دسترسی در دانابات فقط یک‌جا چک نمی‌شود. دو مرحله دارد. مرحله‌ی اول پیش از جست‌وجو است: بر اساس نقش، واحد و سطح طبقه‌بندی، فقط اسنادی که کاربر مجاز است در نتایج جست‌وجو وارد می‌شوند. مرحله‌ی دوم پیش از نمایش است: پیش از اینکه پاسخ به کاربر برسد، دسترسی از خود سامانه‌ی سازمان استعلام می‌شود.

نتیجه‌ی این طراحی دو لایه، یک رفتار مهم است: اگر کاربر مجاز به دیدن سندی نباشد، آن سند حتی در فهرست منابع پاسخ هم ظاهر نمی‌شود. این مهم است چون گاهی خود وجود یک سند اطلاعات است. اگر در فهرست منابع بنویسد «قرارداد شماره‌ی فلان با شرکت فلان»، حتی بدون محتوا، کسی که نباید بداند، می‌داند. این همان چیزی است که در مقاله‌ی [SmartConnect؛ دستیار برای هر سامانه بدون بازنویسی](https://artinmag.ir/articles/danabot-smartconnect-integration) هم بیان شد: دسترسی پیش از پاسخ، نه پنهان کردن بعد از پاسخ.

## ماسک اطلاعات شخصی

بخش دیگری از حاکمیت داده، ماسک اطلاعات شخصی در پاسخ‌هاست. حتی وقتی کاربر مجاز به دیدن یک سند است، ممکن است لازم نباشد همه‌ی جزئیات شخصی داخل آن را ببیند. شماره‌ی تماس یک مشتری یا اطلاعات شخصی یک همکار، می‌توانند در پاسخ پوشانده شوند.

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

## واژگان حساس: پیش از آنکه سوال به مدل برسد

یکی از ویژگی‌های متمایز این ماژول، بررسی واژگان حساس است. سازمان فهرستی از واژه‌ها و عبارت‌های حساس تعریف می‌کند. هر سوالی که کاربر می‌پرسد، پیش از ارسال به مدل با این فهرست تطبیق داده می‌شود.

ترتیب اینجا مهم است. اگر کنترل بعد از مدل انجام شود، سوال حساس به مدل رسیده است، و اگر مدل ابری باشد، از شبکه‌ی سازمان خارج شده است. بررسی پیش از مدل یعنی در موارد جدی، سوال اصلاً از سازمان بیرون نمی‌رود.

اگر سوالی با فهرست مطابقت کند، گفتگو برای بازبینی علامت می‌خورد و به صف بررسی می‌رود. و در شدت «بالا»، پاسخ مسدود می‌شود. مثال کلاسیک: «رمز عبور سامانه‌ی فلان چیست؟» این سوال هم بالقوه خطرناک است و هم نشانه‌ی یک رفتار غیرعادی که سازمان باید از آن مطلع شود. مسدود شدن پاسخ فقط نیمی از ماجراست؛ نیمه‌ی دیگر این است که مسئول امنیت آن گفتگو را ببیند.

## سه سیاست دسترسی و تصمیم برای زمان قطعی

دانابات سه سیاست دسترسی دارد که هر سازمان بسته به فرهنگ و حساسیتش انتخاب می‌کند: سخت‌گیرانه، نیمه‌باز و کاملاً باز. این یعنی سازمانی که اسناد بسیار حساس دارد می‌تواند سخت‌گیر باشد و سازمانی که فرهنگ شفاف‌تری دارد می‌تواند بازتر.

یک تصمیم مهم دیگر هم وجود دارد که اغلب نادیده گرفته می‌شود: وقتی سامانه‌ای که دسترسی را استعلام می‌کند از کار بیفتد، دستیار چه کار کند؟ اجازه بدهد (fail-open) یا ببندد (fail-closed)؟ هر دو گزینه بهایی دارند. اگر ببندد، کارمندان در زمان قطعی از دستیار محروم می‌شوند. اگر باز بگذارد، در همان بازه ممکن است دسترسی کنترل‌نشده رخ دهد. دانابات این تصمیم را به عهده‌ی سازمان می‌گذارد و آن را به‌صورت یک تنظیم صریح در اختیارش قرار می‌دهد، نه یک رفتار پنهان.

## ردپای کامل حسابرسی

آخرین لایه، ردپای حسابرسی است. هر پرسش، هر پاسخ و هر تصمیم دسترسی ثبت می‌شود و می‌توان آن را به صورت Excel یا CSV خروجی گرفت. این همان چیزی است که در زمان بروز یک مشکل، یا حتی در یک بازرسی داخلی، به شما اجازه می‌دهد بگویید چه کسی چه چیزی را پرسید و چه جوابی گرفت.

بدون حسابرسی، همه‌ی کنترل‌های بالا فقط اعتماد به حسن‌نیت‌اند. با حسابرسی، قابل‌راستی‌آزمایی می‌شوند.

## برای دانش‌نامه‌های حساس: مرحله‌ی دوم و استقرار داخلی

برای دانش‌نامه‌هایی که حساسیت بالاتری دارند، دانابات یک لایه‌ی اضافه‌ی احراز هویت هم دارد: رمز یک‌بارمصرف (OTP) به‌عنوان مرحله‌ی دوم. کاربر علاوه بر ورود عادی، باید یک بار دیگر خودش را تایید کند تا آن دانش‌نامه باز شود.

و برای داده‌های طبقه‌بندی‌شده، یعنی اطلاعاتی که اصلاً نباید از شبکه‌ی سازمان خارج شود، پاسخ صریح محصول این است: استقرار کامل On-Prem. در این حالت، با مدل محلی، داده از شبکه‌ی سازمان بیرون نمی‌رود. هیچ تنظیم نرم‌افزاری جای این تصمیم زیرساختی را نمی‌گیرد.

اگر برای تماس‌های ضبط‌شده هم نگران حریم خصوصی هستید، نگاهی به مقاله‌ی [دانش‌کاوی دانابات](https://artinmag.ir/articles/danabot-knowledge-mining-call-recordings) هم بیندازید، چون آنجا هم ملاحظات حقوقی را جدی گرفته‌ایم.

## سه سناریو از یک سازمان معمولی

این‌ها نمونه‌ی مشتریان واقعی نیستند؛ سناریوهایی‌اند که نشان می‌دهند این ماژول در عمل چه شکلی پیدا می‌کند.

شرکت با چند واحد و قراردادهای محرمانه. واحد حقوقی قراردادهای طبقه‌بندی‌شده دارد. کارشناس فروش در دستیار می‌پرسد «شرایط قرارداد با شرکت فلان چیست؟» به‌خاطر ABAC، آن قرارداد حتی در فهرست منابع هم ظاهر نمی‌شود و پاسخ بر پایه‌ی آن سند ساخته نمی‌شود. کاربر نمی‌داند قراردادی وجود دارد یا نه. همین ندانستن، حفاظت است.

کارمندی که سوال خطرناک می‌پرسد. کاربری می‌پرسد «رمز عبور سرور پشتیبان چیست؟» این عبارت در فهرست واژگان حساس با شدت بالا ثبت شده است. سوال پیش از رسیدن به مدل شناسایی می‌شود، پاسخ مسدود می‌شود و گفتگو در صف بازبینی مسئول امنیت قرار می‌گیرد. نتیجه این است که هم سوال جواب نگرفته و هم سازمان می‌داند چنین سوالی پرسیده شده است.

سازمان با ممیزی داخلی. مسئول حسابرسی می‌خواهد بداند در یک ماه گذشته چه کسی درباره‌ی یک پروژه‌ی خاص سوال پرسیده است. خروجی حسابرسی را به صورت Excel می‌گیرد و بر اساس واحد و تاریخ بررسی می‌کند. ردپا همان چیزی است که این بازرسی را ممکن می‌کند.

## محدودیت‌هایی که باید از قبل بدانید

ABAC به اندازه‌ی ویژگی‌هایی که تعریف شده‌اند خوب است. اگر چارت سازمانی ناقص یا قدیمی باشد، یا اسناد طبقه‌بندی نشده باشند، ماژول نمی‌تواند حفاظتی بر پایه‌ی آن‌ها فراهم کند. بخش بزرگی از کار، آماده‌سازی داده‌ی سازمان است، نه نصب نرم‌افزار.

فهرست واژگان حساس را سازمان تعریف و به‌روز می‌کند. این فهرست چیزهایی را می‌گیرد که در آن آمده است؛ هر بازنویسی یا تعبیر ناشناخته‌ای را نمی‌تواند حدس بزند. آن را یک لایه‌ی مفید بدانید، نه یک سد کامل.

ماسک اطلاعات شخصی یک لایه‌ی محافظ است و ضمانت انطباق قانونی نیست. مسئولیت تفسیر مقررات با خود سازمان است.

سیاست‌های بازتر، یعنی نیمه‌باز و کاملاً باز، ریسک را بالا می‌برند. انتخاب آن‌ها باید آگاهانه باشد و با سطح حساسیت اسناد هم‌خوان باشد.

و تصمیم درباره‌ی رفتار در زمان قطعی سامانه‌ی استعلام را نمی‌توان به پیش‌فرض سپرد. هر دو گزینه هزینه دارند و سازمان باید انتخاب کند.

## از کجا شروع کنیم

پیش از فعال‌سازی، سه کار را انجام دهید. اول، چارت سازمانی را بازبینی کنید و ببینید آیا با واقعیت می‌خواند. دوم، فهرست اولیه‌ی واژگان حساس را با مدیر امنیت تهیه کنید و شدت هر کدام را تعیین کنید. سوم، سیاست دسترسی و رفتار زمان قطعی را با تصمیم آگاهانه انتخاب کنید.

سپس با یک واحد شروع کنید که اسناد حساس دارد، و ابتدا سیاست سخت‌گیرانه را امتحان کنید. با تماس‌ها و سوال‌های واقعی آن واحد ببینید چه چیزی مسدود شد، چه چیزی علامت خورد، و آیا آن‌ها واقعاً سوال‌های خطرناک بودند یا هشدار کاذب. بر اساس این تجربه فهرست و سیاست را اصلاح کنید و بعد به واحدهای دیگر بروید.

اگر می‌خواهید خودتان امتحان کنید، [دانابات](https://dana-bot.ir) نسخه‌ی آزمایشی 14 روزه دارد که همه‌ی ماژول‌ها در آن باز است، با محدودیت مقیاس.

## جمع‌بندی

حاکمیت داده در دانابات یعنی چهار لایه: ABAC روی چارت سازمانی، ماسک اطلاعات شخصی، بررسی واژگان حساس پیش از رسیدن سوال به مدل، و ردپای کامل حسابرسی. دسترسی در دو مرحله چک می‌شود، سند غیرمجاز حتی در فهرست منابع ظاهر نمی‌شود و رفتار سیستم در زمان قطعی یک تنظیم صریح است. مرزهایش هم روشن است: وابسته به ویژگی‌های تعریف‌شده، فهرست واژگان که سازمان نگه می‌دارد، و مسئولیت حقوقی که با خود سازمان است.

برای دیدن این ماژول روی ساختار واقعی سازمان خودتان، به [دانابات](https://dana-bot.ir) سر بزنید.

## پرسش‌های متداول

### حاکمیت داده در دانابات چیست؟

ماژولی برای کنترل دسترسی و حفاظت از اطلاعات حساس: ABAC روی چارت سازمانی، ماسک اطلاعات شخصی، بررسی واژگان حساس پیش از مدل و ردپای حسابرسی.

### ABAC چه فرقی با دسترسی مبتنی بر نقش دارد؟

تصمیم را بر پایه‌ی ویژگی‌های کاربر (واحد، پست، سطح طبقه‌بندی) و ویژگی‌های سند می‌گیرد، نه فقط نقش.

### واژگان حساس چطور کار می‌کنند؟

سوال کاربر پیش از ارسال به مدل با فهرست واژگان سازمان تطبیق داده می‌شود؛ گفتگو برای بازبینی علامت می‌خورد و در شدت بالا پاسخ مسدود می‌شود.

### سند غیرمجاز در فهرست منابع ظاهر می‌شود؟

خیر. سند غیرمجاز حتی در فهرست منابع پاسخ هم نمایش داده نمی‌شود.

### اگر سامانه استعلام دسترسی از کار بیفتد چه می‌شود؟

رفتار (fail-open یا fail-closed) یک تنظیم صریح است که سازمان انتخاب می‌کند؛ هر دو گزینه هزینه‌ی خود را دارند.

### حاکمیت داده چه محدودیت‌هایی دارد؟

وابسته به چارت سازمانی و ویژگی‌های دقیق است، فهرست واژگان را سازمان نگه می‌دارد و ماسک اطلاعات شخصی ضمانت انطباق قانونی نیست.

---

منبع: [حاکمیت داده در دانابات: ABAC، ماسک اطلاعات شخصی و واژگان حساس، پیش از آنکه سوال به مدل برسد](https://artinmag.ir/articles/danabot-data-governance-abac-pii-masking) — مجله آرتین