دو شکست متقارن در طراحی دسترسی کداماند؟
شکست اول، بازبودن بیش از حد است. وقتی هر ثبتی برای کل سازمان قابل مشاهده باشد، افراد در جلسه محتاط میشوند: اختلاف نظر بیان نمیشود، تردید ثبت نمیشود و آنچه در حافظه میماند نسخهٔ رسمی و بیخطر ماجراست. حافظهای که فقط نتیجه را دارد و استدلال را ندارد، همان بایگانی است.
شکست دوم، بستگی بیش از حد است. وقتی هر تیم فقط دانش خودش را میبیند، سازمان چند حافظهٔ موازی پیدا میکند که هیچکدام تصویر کامل ندارند. پرسشهای میانواحدی — که معمولاً گرانترین پرسشهای سازماناند — بیپاسخ میمانند.
این دو شکست متقارناند و بنابراین راهحل، حرکت روی یک محور نیست. راهحل، افزودن یک بعد دوم به طراحی است: تفکیک میان اینکه چه چیزی وجود دارد و اینکه محتوای آن چیست.
چرا باید قابلیت کشف را از قابلیت خواندن جدا کرد؟
بیشتر سامانهها یک سطح دسترسی دارند: یا میبینی یا نمیبینی. اما در دانش سازمانی سه حالت مفید وجود دارد: میدانم که چنین چیزی هست و میتوانم بخوانمش؛ میدانم که هست و میدانم از چه کسی باید درخواست کنم؛ اصلاً نمیدانم که هست.
حالت میانی همان چیزی است که بیشترین ارزش را میسازد و کمترین ریسک را دارد. کارشناسی که میفهمد موضوع مورد نظرش پیشتر در کمیتهٔ دیگری بررسی شده، حتی بدون خواندن محتوا، از دوبارهکاری نجات پیدا میکند و میداند سراغ چه کسی برود.
پیادهسازی این حالت یعنی فراداده — عنوان، تاریخ، مرجع تصمیمگیر، مالک — در سطح گستردهتری از محتوا قابل مشاهده باشد. این طراحی هم دیوارهای سازمانی را میشکند و هم محرمانگی محتوا را حفظ میکند.
چرا دسترسی باید به تیم بسته شود، نه به فرد؟
دسترسی فردی در روز اول دقیق است و در ماه ششم آشوب. افراد جابهجا میشوند، پروژهها تمام میشوند و کسی دسترسیهای قدیمی را پس نمیگیرد. نتیجه انباشت اختیار است: افرادی که به دلایل تاریخی به چیزهایی دسترسی دارند که هیچکس دیگر در نقش فعلیشان ندارد.
دسترسی مبتنی بر تیم و موضوع این مسئله را حل میکند چون تغییر نقش فرد بهطور خودکار دسترسیاش را تغییر میدهد. مرزها هم پایدارترند: یک کمیته یا یک پروژه، موجودیتی است که سازمان بههرحال آن را مدیریت میکند.
استثناها اجتنابناپذیرند، اما باید مدتدار باشند. دسترسی موقتی که تاریخ انقضا ندارد، دسترسی دائمی است با نامی دیگر — و بازبینی دورهای اختیارات، بدون انقضای خودکار، در عمل تقریباً هرگز انجام نمیشود.
دستیار هوش مصنوعی چگونه باید در این مرز قرار گیرد؟
این نقطهای است که بیشترین اشتباه در آن رخ میدهد. اگر دستیار به کل پایگاه دانش دسترسی داشته باشد و پاسخ را پس از تولید فیلتر کند، نشت اطلاعات تقریباً حتمی است: خلاصهای که از سند محرمانه ساخته شده، حتی بدون نقل مستقیم، محتوای آن را منتقل میکند.
طراحی درست، اعمال دسترسی در مرحلهٔ بازیابی است: مجموعهٔ اسنادی که برای پاسخ به پرسش یک فرد بازیابی میشود، همان مجموعهای است که او مجاز به دیدنش است. آنچه هرگز بازیابی نشود، نمیتواند در پاسخ ظاهر شود.
پیامد این طراحی آن است که دو نفر با دسترسی متفاوت، از یک پرسش پاسخ متفاوت میگیرند — و این درست است، نه یک نقص. آنچه باید صریح باشد این است که پاسخ ممکن است ناقص باشد، تا کاربر بداند غیبت اطلاعات میتواند به معنای نبود دسترسی باشد و نه نبود اطلاعات.
یک طراحی عملی از کجا شروع میشود؟
از فهرست کردن پرسشهای میانواحدی که امروز بیپاسخ میمانند. هر پرسش نشان میدهد کدام مرز باید نفوذپذیر شود، و معمولاً معلوم میشود که برای بیشترشان دیدن فراداده کافی است و نیازی به باز کردن محتوا نیست.
سپس سه سطح را تعریف کنید — عمومی سازمان، قابل کشف با درخواست، محدود — و هر خانوادهٔ جلسه را در یکی از آنها قرار دهید. تعداد سطوح را کم نگه دارید؛ مدلی با هفت سطح در عمل به دو سطح تقلیل پیدا میکند، چون کسی تفاوتشان را به یاد نمیآورد.
و در پایان، سازوکار درخواست دسترسی را ساده کنید. اگر گرفتن دسترسی به یک سند سه روز طول بکشد، افراد راههای دور زدن آن را پیدا میکنند — و آن راهها، برخلاف سامانه، هیچ سیاههای تولید نمیکنند.
