فراتر از SSNها: ناشناس‌سازی شناسه‌های داخلی سازمان شما
ابزار GDPR شما آدرس‌های ایمیل را حذف می‌کند. شماره تلفن‌ها را حذف می‌کند. نام‌ها را حذف می‌کند. صادرات پشتیبانی را از آن عبور می‌دهید. سپس خروجی را با تیم تحلیل خود به اشتراک می‌گذارید.
شماره‌های حساب مشتری شما همچنان در هر تیکت است. شناسه‌های سفارش شما همچنان آنجاست. شناسه‌های کاربری داخلی شما هم همچنان آنجاست.
این شناسه‌ها به تنهایی بی‌خطر به نظر می‌رسند. بدون جدول جستجو، یک شخص را نام‌گذاری نمی‌کنند. اما تیم تحلیل شما آن جدول را دارد. CRM شما آن را دارد. پایگاه داده پشتیبانی شما آن را دارد. هر کسی با دسترسی می‌تواند در چند ثانیه شخص را پیدا کند.
این یک شکست GDPR است. ابزار خراب نشد. هرگز به آن گفته نشد که شناسه‌های شما را جستجو کند.
آنچه ابزارهای PII استاندارد تشخیص می‌دهند
ابزارهای PII استاندارد فرمت‌های جهانی را پوشش می‌دهند. آنچه هر سازمانی استفاده می‌کند را می‌گیرند.
ابزارهای استاندارد تشخیص می‌دهند:
- شماره‌های امنیت اجتماعی (SSN آمریکا، NINO انگلیس، فرمت‌های شناسه ملی اروپا)
- آدرس‌های ایمیل
- شماره تلفن‌ها
- شماره‌های کارت اعتباری
- نام‌ها
- شماره‌های گذرنامه و گواهینامه رانندگی
ابزارهای استاندارد تشخیص نمی‌دهند:
- شناسه‌های کارمندی در فرمت EMP-XXXXX شما
- شماره‌های حساب مشتری در فرمت ACC-XXXXXXXX-XX شما
- شناسه‌های سفارش در فرمت ORD-XXXXXXX شما
- شناسه‌های کاربری داخلی در UUID یا فرمت‌های سفارشی
- کدهای مرجع خاص شریک
ابزارهای استاندارد الگوهای جهانی را پیدا می‌کنند. شناسه‌های داخلی شما جهانی نیستند. برای پیدا شدن به راه‌اندازی سفارشی نیاز دارند.
ریسک شناسایی مجدد
یک شرکت تیکت‌های پشتیبانی را برای بررسی کیفیت صادر می‌کند. حذف PII استاندارد نام‌ها، ایمیل‌ها و شماره تلفن‌ها را حذف می‌کند. شماره‌های حساب در فرمت ACC-XXXXXXXX-XX لمس نمی‌شوند.
صادرات به تیم تحلیل می‌رود. یک تحلیلگر جدول تیکت را با پایگاه داده مشتری روی شماره حساب ادغام می‌کند. شخص فوراً پیدا می‌شود. هیچ ترفند خاصی لازم نیست. یک join معمولی SQL است.
ماده ۴(۵) GDPR شبه‌ناشناس‌سازی را به عنوان پردازشی تعریف می‌کند که داده‌ها «دیگر نمی‌توانند بدون استفاده از اطلاعات اضافی به یک موضوع داده خاص نسبت داده شوند.» شماره‌های حساب در آن آزمون شکست می‌خورند. اطلاعات اضافی — پایگاه داده مشتری شما — درست آنجا در سازمان شما است.
صادرات «ناشناس» ناشناس نبود.
ساختن الگوهای موجودیت سفارشی
راه‌اندازی موجودیت سفارشی سریع است. تیم‌های انطباق می‌توانند بدون کمک مهندسی آن را انجام دهند.
مرحله ۱: لیست فرمت‌های شناسه خود را بنویسید.
هر کدام را یادداشت کنید. برای مثال: حساب ACC-XXXXXXXX-XX، شناسه سفارش ORD-XXXXXXX، شناسه کارمند EMP-XXXXX.
مرحله ۲: فرمت را به زبان ساده توضیح دهید.
«شماره‌های حساب با ACC شروع می‌شوند، سپس یک خط تیره، سپس ۸ رقم، سپس یک خط تیره، سپس ۲ حرف بزرگ.»
تولید الگوی مبتنی بر هوش مصنوعی برمی‌گرداند: ACC-\d{8}-[A-Z]{2}
مرحله ۳: روی داده‌های نمونه آزمایش کنید.
۲۰ تا ۳۰ سند آپلود کنید. تأیید کنید که تمام موارد پیدا می‌شوند. تأیید کنید که مثبت کاذب ظاهر نمی‌شود.
مرحله ۴: یک روش انتخاب کنید.
برای شناسه‌هایی که به عنوان کلید ادغام استفاده می‌شوند، جایی که تحلیل نیاز به پیوند رکوردها دارد:
- شبه‌ناشناس‌سازی. ACC-00123456-AB را با ACC-99876543-XY هر بار جایگزین کنید. همان ورودی همیشه همان خروجی را می‌دهد. ادغام‌ها همچنان کار می‌کنند.
برای شناسه‌هایی که در تحلیل لازم نیستند:
- تحریر. با [REDACTED] جایگزین کنید. ساده. دائمی.
مرحله ۵: به عنوان یک پیش‌تنظیم مشترک ذخیره کنید.
موجودیت سفارشی — یا مجموعه‌ای از آنها — را در یک پیش‌تنظیم مشترک ذخیره کنید.
مطالعه موردی: ۱۸۰٬۰۰۰ تیکت پشتیبانی
یک شرکت ۱۸۰٬۰۰۰ تیکت پشتیبانی در انبار تحلیلی خود پیدا کرد. نام‌ها و ایمیل‌ها حذف شده بودند. شماره‌های حساب نه. هر تیکت همچنان یک مقدار زنده ACC-XXXXXXXX-XX داشت.
جدول زمانی حل‌وفصل:
- افسر انطباق الگوی ACC را تعریف می‌کند — ۱۵ دقیقه
- آن را روی ۳۰ تیکت نمونه آزمایش می‌کند — ۲۰ دقیقه
- دقت را تأیید می‌کند — ۱۰ دقیقه
- ۱۸۰٬۰۰۰ تیکت را در یک دسته شبانه پردازش می‌کند
- جداول انبار را با نسخه‌های تمیز جایگزین می‌کند
زمان کل برای افسر انطباق: ۴۵ دقیقه. بدون پشتیبانی موجودیت سفارشی، راه‌حل به یک تیکت مهندسی، بررسی کد و استقرار نیاز داشت. این هفته‌ها طول می‌کشد، نه ساعت‌ها.
برای نگاه دقیق‌تر به اینکه شناسه‌های سفارشی چگونه در ابزارهای پشتیبانی هوش مصنوعی ریسک ایجاد می‌کنند، راهنمای GDPR و پشتیبانی هوش مصنوعی را ببینید.
کجا شناسه‌های سفارشی گسترش می‌یابند
شناسه‌های داخلی در مکان‌های بیشتری نسبت به انتظار اکثر تیم‌ها ظاهر می‌شوند.
اسناد داخلی:
- یادداشت‌های جلسه با ارجاعات شناسه حساب یا سفارش
- رشته‌های ایمیل درباره پرونده‌های مشتری
- ارائه‌ها با داده‌های مطالعه موردی
به اشتراک گذاشته‌شده با اشخاص ثالث:
- گزارش‌ها به نظارت‌گران با شماره‌های مرجع پرونده
- فایل‌های حسابرسی با ارجاعات مشتری
- فایل‌های فروشنده که شناسه‌های مشتری حمل می‌کنند
تحقیق و تحلیل:
- مجموعه داده‌های سفر مشتری
- صادرات بررسی کیفیت پشتیبانی
- داده‌های آموزشی برای مدل‌های ML داخلی
هر زمینه به همان راه‌اندازی موجودیت سفارشی نیاز دارد تا خروجی واقعاً ناشناس تولید کند.
شبه‌ناشناس‌سازی در برابر ناشناس‌سازی
GDPR یک خط روشن می‌کشد.
شبه‌ناشناس‌سازی شناسه‌ها را با جانشین‌ها جایگزین می‌کند. اگر کسی جدول جستجو داشته باشد می‌توان شخص اصلی را دوباره پیدا کرد. این داده همچنان داده شخصی است. ریسک را کاهش می‌دهد. وظایف GDPR شما را حذف نمی‌کند.
ناشناس‌سازی توانایی شناسایی مجدد را حذف می‌کند. داده‌های ناشناس داده شخصی نیستند. GDPR برای آنها اعمال نمی‌شود.
شماره‌های حساب و شناسه‌های سفارش وقتی جدول‌های جستجو وجود دارند شبه‌ناشناس هستند. جایگزین کردن آنها با جانشین‌های ثابت ریسک را کاهش می‌دهد، اما GDPR همچنان اعمال می‌شود.
نتیجه‌گیری
شکاف یک شکست ابزار نیست. یک شکاف راه‌اندازی است. هیچ ابزاری نمی‌تواند فرمت شماره حساب شما را بداند مگر اینکه به آن گفته شود.
راه‌اندازی موجودیت سفارشی شکاف را در چند ساعت پر می‌کند. تیم‌های انطباق فرمت‌ها را تعریف می‌کنند، آنها را روی داده‌های نمونه آزمایش می‌کنند، و آنها را در تمام حالت‌های استفاده اعمال می‌کنند. به کمک مهندسی نیازی نیست.
۱۸۰٬۰۰۰ شماره حساب تحریرنشده آنجا نبودند چون ابزار شکست خورد. آنجا بودند چون هرگز به ابزار گفته نشد که آنها را جستجو کند.