در بیشتر پروژه‌هایی که دیده‌ام، امنیت اطلاعات مشتری آخرین چیزی است که بررسی میشود — معمولاً وقتی همه‌چیز ساخته شده و کسی در جلسهٔ آخر می‌پرسد «راستی، این اطلاعات کجا میرود؟»
آن لحظه دیر است. نه به این دلیل که نمیشود اصلاحش کرد، بلکه چون اصلاحش یعنی بازسازی.
نکتهٔ دیگر این است که امنیت اطلاعات مشتری در این پروژه‌ها فقط یک بحث فنی نیست. رمزنگاری و فایروال جای خودشان را دارند، اما آنچه معمولاً نشت می‌کند از راه نفوذ بیرونی نمی‌رود؛ از راه دسترسی‌ای میرود که کسی لازم نداشت و کسی هم نبست.
این نوشته دربارهٔ چیزهایی است که باید از روز اول بدانید — بدون اصطلاح حقوقی و بدون ترساندن.
سه پرسشی که همه‌چیز را روشن می‌کند
یک: چه چیزی ذخیره میشود؟
جواب باید فهرست باشد، نه توصیف. «اطلاعات لازم» جواب نیست.
فهرست واقعی معمولاً این‌هاست: متن پیام‌های مشتری، شمارهٔ تماس یا شناسه‌اش، آنچه پرسیده، آنچه ما گفتیم، و گاهی فایل‌هایی که فرستاده.
اگر نمی‌توانید در پنج خط بنویسید چه چیزی ذخیره میشود، یعنی خودتان هم نمی‌دانید — و این نقطهٔ شروع مشکل است.
دو: کجا ذخیره میشود؟
سه جای ممکن هست و معمولاً هر سه هم‌زمان:
روی زیرساخت خودتان. از نظر کنترل مطلوب‌ترین است و از نظر نگهداری پرهزینه‌ترین.
در سرویسی که خریده‌اید. رایج‌ترین حالت. یعنی آن شرکت هم دارد.
در سرویس مدل. برای اینکه پیام پردازش شود، متنش باید جایی برود که مدل هست. این را خیلی‌ها نمی‌دانند و باید بدانند.
سه: چه کسی می‌بیندش؟
این پرسش را با «کجا ذخیره میشود» یکی نگیرید. داده‌ای که در سرویسی ذخیره شده، ممکن است کارکنان آن سرویس، پیمانکارانش، و در بعضی معماریها سرویس‌های دیگری هم ببینند.
جواب صادقانه معمولاً «چند طرف» است. و اشکالی هم ندارد که چند طرف باشد — اشکال وقتی پیش می‌آید که ندانید.
قوی‌ترین محافظت: کمتر جمع کردن
اگر فقط یک چیز از این نوشته بماند، این باشد: دادهٔ نداشته لو نمی‌رود.
بیشتر سیستم‌هایی که دیده‌ام چیزهایی نگه میدارند که هیچوقت استفاده نمی‌شوند. متن کامل هر گفتگو، برای همیشه، محض احتیاط.
این «محض احتیاط» هم پرهزینه است و هم مسئولیت‌آور. چیزی که در ماه سوم به کار نیامده، احتمالاً هیچوقت نمیآید.
آنچه واقعاً لازم است معمولاً کوچک‌تر است: راه تماس، آنچه پرسید، آنچه گفتیم، و کجا متوقف شد. چهار قلم. با همین چهارتا میشود پیگیری کرد، فروخت، و مشتری را در دفعهٔ بعد شناخت.
و یک قاعدهٔ دوم که همان‌قدر مهم است: هر چیزی که نگه می‌دارید باید تاریخ انقضا داشته باشد. گفتگوی سه سال پیش به چه کار می‌آید؟ اگر جواب روشنی ندارید، پاکش کنید.
چیزهایی که سیستم هرگز نباید بپرسد
این فهرست کوتاه است و استثنا ندارد:
- رمز عبور، هر رمزی
- کد یکبارمصرف پیامکی
- تصویر کارت بانکی یا شمارهٔ کامل کارت
- کد ملی، مگر جایی که واقعاً لازم است و آن‌وقت هم با احتیاط
دلیلش فقط ریسک خودِ شما نیست. وقتی سیستم شما چیزی شبیه این می‌پرسد، مشتری را به این عادت می‌دهد که چنین پرسش‌هایی طبیعی‌اند — و همان عادت است که کلاهبرداری‌های واقعی از آن استفاده میکنند.
و نکتهٔ مهم: این باید در سازوکار بسته باشد. سیستمی که توانایی پرسیدن اینها را دارد و فقط به آن دستور داده شده که نپرسد، حد ندارد؛ درخواست دارد.
وقتی مشتری خودش اطلاعات حساس می‌فرستد
این حالت را کمتر پیش‌بینی میکنند و بیشتر پیش می‌آید.
مشتری، بدون اینکه کسی خواسته باشد، تصویر کارت ملی می‌فرستد. یا وضعیت پزشکی‌اش را می‌نویسد. یا عکسی می‌فرستد که نباید جایی بماند.
سیستم باید برای این آماده باشد. سه رفتار درست:
تشخیص بدهد که این حساس است. دستکم برای دسته‌های روشن مثل تصویر کارت.
ذخیره‌اش نکند. یا اگر ناچار است، جدا از بقیه و با انقضای کوتاه.
به مشتری بگوید. یک جملهٔ ساده: «لطفاً تصویر مدارک را اینجا نفرستید؛ در دفتر تحویل بگیرید.» این جمله هم از شما محافظت می‌کند و هم به مشتری چیزی یاد می‌دهد.
چه کسی داخل سازمان میبیند؟
تا اینجا دربارهٔ بیرون حرف زدم. طرف دیگر ماجرا، که کمتر به آن فکر میشود، داخل خودِ کسب‌وکار است.
وقتی سیستمی راه می‌افتد که همهٔ گفتگوها را در یک پنل جمع می‌کند، چیزی ساخته میشود که قبلاً نبود: جایی که هر کسی دسترسی داشته باشد، همه‌چیز را دربارهٔ همهٔ مشتری‌ها میبیند.
پیش از این، اطلاعات پخش بود — هر فروشنده مشتری‌های خودش را می‌شناخت. حالا متمرکز است. این برای کار خوب است و برای ریسک بد.
سه کار ساده که این را مهار می‌کند:
دسترسی بر اساس نیاز. کسی که کارش پاسخگویی است، لازم نیست پروندهٔ مالی مشتری‌ها را ببیند.
ثبت اینکه چه کسی چه چیزی را دید. نه برای بی‌اعتمادی؛ برای اینکه اگر روزی چیزی درز کرد، بشود فهمید از کجا.
قطع دسترسی در روز خروج. این سادهترین کار است و بیشترین بار فراموش میشود. کارمندی که رفته و هنوز به گفتگوهای مشتری‌ها دسترسی دارد، شایع‌ترین نشتی واقعی است — نه حملهٔ پیچیده.
پرسش‌هایی که پیش از قرارداد باید بپرسید
اینها را به فروشندهٔ هر سرویسی بگویید و جواب‌ها را بنویسید. اگر جوابی مبهم بود، همان ابهام جواب شماست.
۱. متن پیام‌های مشتری‌های من به کجا فرستاده میشود؟ نام سرویسها را بخواهید، نه توصیف کلی.
۲. آیا از دادههای ما برای بهبود مدل استفاده میشود؟ و اگر بله، میشود خاموشش کرد؟
۳. داده چه مدت نگه داشته میشود؟ و آیا می‌توانم زودتر پاکش کنم؟
۴. اگر قرارداد تمام شد، داده‌ها چه می‌شوند؟ هم اینکه به من داده می‌شوند، هم اینکه از آنجا پاک می‌شوند.
۵. اگر نشتی رخ داد، چطور و چقدر زود به من خبر می‌دهید؟
پنج پرسش، و هیچ‌کدام فنی نیستند.
این برای کسب‌وکار ایرانی یعنی چه
اول، بیشتر گفتگوها در پیام‌رسان‌اند و آنجا هم داده می‌ماند. حتی اگر شما چیزی ذخیره نکنید، تاریخچهٔ گفتگو در خود اپ هست. این یعنی محافظت از حساب‌های کاری — رمز قوی، تأیید دومرحله‌ای، و دسترسی محدود کارکنان — بخشی از همین بحث است، نه جدا از آن.
دوم، شمارهٔ شخصی و کاری را جدا کنید. در بسیاری از کسب‌وکارهای کوچک، همان شماره‌ای که مشتری با آن حرف می‌زند شمارهٔ شخصی صاحب کار است. اگر سیستمی روی آن بنشیند، به گفتگوهای شخصی هم دسترسی پیدا می‌کند.
سوم، سرویس واسطه یک طرف اضافه است. دسترسی مستقیم به بعضی سرویسها از ایران ساده نیست و همین باعث شده واسطه‌ها زیاد شوند. هر واسطه یک طرف دیگر است که داده را میبیند. این را بپرسید، پیش از قرارداد.
چهارم، خروج از سرویس را از قبل بسنجید. اگر فردا بخواهید سرویس را عوض کنید، داده‌هایتان با شما می‌آیند؟ اگر نه، شما مالک اطلاعات مشتری‌هایتان نیستید — و این هم مسئلهٔ حریم خصوصی است هم مسئلهٔ کسب‌وکار.
پنجم، صریح بودن با مشتری هزینه ندارد. یک جملهٔ ساده در ابتدای گفتگو که بگوید این پاسخگوی خودکار است و اطلاعات برای پیگیری سفارش نگه داشته میشود، اعتماد می‌سازد. مشتری‌ای که بعداً بفهمد چیزی از او پنهان شده، برنمی‌گردد.
کاری که این هفته میشود انجام داد
بدون پروژه و بدون هزینه، چهار کار که وضع را بهتر میکنند:
۱. فهرست کنید چه چیزی دارید. کجا اطلاعات مشتری‌ها هست — کدام اپ، کدام فایل، کدام سرویس. تقریباً همیشه بیشتر از چیزی است که فکر می‌کردید.
۲. حذف کنید آنچه لازم نیست. فایل‌های قدیمی، گروه‌های منقضی، دسترسی‌های کارکنان سابق.
۳. تأیید دومرحله‌ای را روی حساب‌های کاری فعال کنید. ده دقیقه کار است و بیشترین بازدهی امنیتی را دارد.
۴. یک جمله بنویسید که به مشتری بگویید چه چیزی نگه می‌دارید. اگر نتوانستید در یک جمله بنویسید، یعنی بیش از حد نگه می‌دارید.
دو نکته دربارهٔ آموزش مدل، که زیاد بد فهمیده میشود
این بخش را می‌نویسم چون در جلسه‌ها زیاد پرسیده میشود و معمولاً جواب‌های مبهم می‌گیرد.
نکتهٔ اول: استفاده از یک مدل، آموزش دادن آن نیست. وقتی سیستم شما پیامی را به سرویس مدل می‌فرستد تا جوابی بگیرد، این لزوماً به این معنا نیست که آن پیام وارد آموزش مدل میشود. این دو چیز جدا هستند و در شرایط استفادهٔ هر سرویس جداگانه نوشته شده‌اند.
پس پرسش درست این نیست که «آیا دادههای من به مدل می‌رسد» — می‌رسد، وگرنه جوابی نمی‌گرفتید. پرسش این است که «آیا نگه داشته میشود و آیا در آموزش استفاده میشود».
نکتهٔ دوم: «آموزش دادن مدل با دادههای ما» معمولاً لازم نیست. بسیاری از کسب‌وکارها فکر میکنند برای اینکه سیستم اطلاعات آنها را بداند، باید مدل را با آن اطلاعات آموزش داد. تقریباً همیشه راه بهتری هست: اطلاعات در جای خودش بماند و سیستم هنگام پاسخ از آنجا بخواند.
این راه هم ارزان‌تر است، هم به‌روزرسانی‌اش ساده است، و هم — از نظر این بحث — امن‌تر: اطلاعاتی که در مدل ننشسته، از مدل بیرون هم نمیآید.
اشتباه رایجی که ارزش هشدار دارد
بعضی کسب‌وکارها، وقتی سیستم گفتگو راه می‌اندازند، وسوسه می‌شوند تمام تاریخچهٔ گفتگوهای گذشته را وارد سیستم کنند — «تا سیستم بهتر یاد بگیرد».
دو مشکل دارد. اول اینکه آن گفتگوها با انتظار دیگری انجام شده‌اند؛ مشتری وقتی چیزی می‌گفت، فرض نمی‌کرد جایی بایگانی میشود. دوم اینکه در آن حجم، تقریباً حتماً چیزهایی هست که نباید جایی بروند: شمارهٔ کارت، عکس مدارک، حرف‌های خصوصی.
اگر چنین کاری لازم است، باید انتخابی انجام شود نه یکجا — و پیش از آن باید پاک شود آنچه نباید بماند.
جمع‌بندی
حریم خصوصی داده مشتری در پروژه‌های هوش مصنوعی، بحث حقوقی پیچیده‌ای نیست. سه پرسش است: چه چیزی، کجا، چه کسی میبیند.
و سادهترین راهش هم پیچیده نیست: کمتر جمع کنید، مدت کمتری نگه دارید، و چیزهایی که هرگز نباید پرسیده شوند را از توانِ سیستم بیرون بگذارید — نه از دستورش.
هوش مصنوعی برای مطب دربارهٔ صنفی است که این مرزها در آن از همه‌جا جدی‌ترند، و هوش مصنوعی عاملی و جایی که نباید اختیار داد دربارهٔ همان تفاوت میان حدِ نوشته‌شده در سازوکار و حدِ نوشته‌شده در دستور است.