هوش مصنوعی با داده خصوصی

وقتی قابلیت AI به داده مشتری، قراردادها یا سابقه کاربران وصل می‌شود، سؤال اول «مدل چقدر خوب است» نیست؛ «داده کجا می‌رود، کجا می‌ماند، چه کسی می‌بیند و چطور پاک می‌شود» است. این مقاله مرز دسترسی، نگه‌داری و حذف را از روی جریان داده بررسی می‌کند و فهرست پرسش‌هایی برای قرارداد و ارائه‌دهنده می‌دهد.

مرجع: مستندات «API and data retention» از Anthropic و «Data controls» از OpenAI، خوانده‌شده در ۱۹ اکتبر ۲۰۲۶، و راهنمای RAG در AWS. سیاست‌ها تغییر می‌کنند و به نوع حساب، سازمان و ویژگی وابسته‌اند؛ پیش از تصمیم باید صفحهٔ روز و قرارداد خودتان را ببینید. این متن مشاورهٔ حقوقی نیست و ما قوانین حفاظت داده و حریم خصوصی ایران را بررسی نکرده‌ایم؛ هر ادعای انطباق را با مشاور حقوقی بسنجید. ترتیب‌بندی، مثال‌ها و پرسش‌های قرارداد توصیهٔ نویسنده‌اند. برای معماری کلی انتخاب معماری اپلیکیشن وب را ببینید.

نقشهٔ جریان داده

ابتدا هر جایی که داده شخصی یا محرمانه می‌گذرد را رسم کنید (توصیهٔ نویسنده):

کاربر → [برنامهٔ شما] → [ذخیره‌گاه سند / پایگاه داده] 
           ↓                         ↓ (embedding)
     [لاگ و مانیتورینگ]       [نمایه برداری]
           ↓                         ↓ (قطعه‌های بازیابی‌شده)
        [API ارائه‌دهندهٔ مدل] ← prompt = دستور + داده + پرسش
           ↓
   [لاگ ارائه‌دهنده / نگه‌داری وضعیت] → پاسخ → کاربر

هر فلش یک سؤال است: چه داده‌ای؟ رمزنگاری انتقال (HTTPS) و ذخیره؟ چه مدت؟ چه کسی دسترسی دارد؟ AWS یادآوری می‌کند منبع RAG می‌تواند مخزن سند، پایگاه داده یا API باشد و سند و پرسش به embedding تبدیل می‌شوند؛ یعنی نمایهٔ برداری هم نسخه‌ای از دادهٔ شما را در خود دارد و باید مثل منبع اصلی کنترل و حذف شود.

مرز دسترسی

1. حداقل داده در prompt: فقط آنچه برای پاسخ لازم است ارسال کنید؛ شناسه‌های مستقیم را حذف یا جایگزین کنید.
2. مجوز کاربر در بازیابی: کاربر فقط قطعه‌هایی را که اجازه دارد ببیند به prompt بیاورد؛ فیلتر را پیش از ارسال به مدل اعمال کنید.
3. جداسازی مشتری‌ها: داده مشتری A هرگز در زمینهٔ مشتری B نیاید (فضای نام یا فیلتر اجباری در نمایه).
4. حساب سرویس: کلید API ارائه‌دهنده با حداقل دسترسی و در مدیر اسرار.
5. ابزارها و عامل‌ها: اگر مدل ابزار فراخوانی می‌کند، همان محدودیت‌های مجوز روی ابزار هم اعمال شود.

سیاست نگه‌داری ارائه‌دهنده

این جدول خلاصهٔ صفحه‌هاست و جزئیات (فهرست ویژگی‌ها، استثناها) در منبع‌اند. نکتهٔ مهم: اگر مدل را از طریق Amazon Bedrock یا Google Cloud مصرف می‌کنید، Anthropic می‌گوید ارائه‌دهندهٔ ابر پردازشگر داده است و باید به مستندات همان پلتفرم رجوع کنید. برای هر ارائه‌دهنده بپرسید و مکتوب کنید که کدام ترتیب (استاندارد، ZDR، HIPAA) برای شما فعال است؛ ZDR معمولاً با درخواست و تأیید است نه خودکار.

نگه‌داری در سیستم خودتان

غیر از ارائه‌دهنده، خودتان هم داده نگه می‌دارید: لاگ‌های prompt و پاسخ، نمایهٔ برداری، کش، دیتاست ارزیابی، ردیابی (trace) و پشتیبان. توصیه‌ها (نویسنده):

• لاگ prompt/پاسخ را به‌طور پیش‌فرض ماسک یا نمونه‌ای کنید و دسترسی را محدود.
• برای هر ذخیره‌گاه مدت نگه‌داری و مالک مشخص کنید.
• پشتیبان‌ها را در سیاست حذف لحاظ کنید؛ حذف از نمایه‌ای که پشتیبان دارد کامل نیست.
• داده را از دیتاست ارزیابی و محیط آزمایشی جدا و ناشناس کنید.

حذف

وقتی مشتری درخواست حذف می‌کند، فقط پایگاه داده اصلی کافی نیست. فهرست حذف (توصیهٔ نویسنده): سند منبع، قطعه‌ها و embeddingها در نمایه، کش پاسخ، لاگ‌ها، دیتاست‌های مشتق، و بخشی که نزد ارائه‌دهنده است (مطابق سیاست او و قرارداد). برای حذف از نمایه، قطعه‌ها باید شناسهٔ سند منبع داشته باشند تا بتوان همه را پیدا کرد. مهلت‌ها و الزام‌های قانونی ایران را از مشاور حقوقی بپرسید؛ ما بررسی نکرده‌ایم.

پرسش‌های قرارداد و ارائه‌دهنده

1. آیا دادهٔ ما برای آموزش یا بهبود مدل استفاده می‌شود؟ در چه شرایطی (opt-in)؟
2. چه داده‌ای و تا چه مدت نگه‌داری می‌شود (لاگ‌ها، وضعیت برنامه، فایل‌ها)؟
3. آیا ZDR یا معادل در دسترس است، برای کدام ویژگی‌ها و با چه شرایطی؟
4. داده در کدام کشور/منطقه پردازش می‌شود؟ گزینهٔ منطقه‌ای وجود دارد؟
5. پردازشگران فرعی و فرایند اطلاع‌رسانی تغییرات؟
6. روند درخواست حذف و مهلت آن؟
7. گزارش و اطلاع‌رسانی رخداد امنیتی؟
8. آیا ارائه‌دهنده در کشور شما قابل‌استفاده و پرداخت‌پذیر است؟ (تحریم و پرداخت را ما بررسی نکردیم.)

مثال ساختگی: دستیار اسناد قرارداد

شرکت فرضی «آلفا» قراردادهای مشتریان را برای پرسش‌وپاسخ نمایه می‌کند. تصمیم‌ها: قطعه‌ها با شناسهٔ مشتری و سند ذخیره می‌شوند؛ هر پرسش با فیلتر مشتری اجرا می‌شود؛ نام و شماره ملی پیش از ارسال به مدل ماسک می‌شود؛ لاگ ۳۰ روز با دسترسی محدود می‌ماند؛ ارائه‌دهنده طبق قرارداد ZDR دارد و تأیید مکتوب شده؛ هنگام حذف مشتری، سند، قطعه‌ها، embeddingها، کش و لاگ‌ها طبق فهرست پاک و گزارش ثبت می‌شود. هیچ‌کدام از این‌ها تضمین انطباق قانونی نیست؛ فقط طراحی فنی است.

اشتباهات رایج

• فرض اینکه «API آموزش نمی‌دهد» یعنی «هیچ‌چیز نگه‌داری نمی‌شود».
• فراموش‌کردن نمایهٔ برداری و کش در حذف.
• نبودن فیلتر مجوز در بازیابی.
• لاگ کامل prompt با داده شخصی در ابزار پایش.
• استفاده از حساب‌های مصرف‌کننده (مثل محصولات چت) به‌جای API قراردادی برای داده کار.
• نداشتن تأیید مکتوب ZDR یا مبهم‌بودن نقطهٔ پایانی ابری.

چک‌لیست

1. نقشهٔ جریان داده رسم و داده شخصی علامت‌گذاری شده است.
2. حداقل داده در prompt و ماسک شناسه‌ها پیاده شده است.
3. مجوز کاربر و جداسازی مشتری قبل از ارسال به مدل اعمال می‌شود.
4. سیاست نگه‌داری ارائه‌دهنده برای حساب و ویژگی ما از صفحهٔ روز خوانده و مستند شده است.
5. مدت نگه‌داری و مالک هر ذخیره‌گاه خودمان مشخص است.
6. فهرست حذف شامل نمایه، کش، لاگ و ارائه‌دهنده است.
7. پرسش‌های قرارداد پاسخ مکتوب دارند.
8. بررسی حقوقی داده و حریم خصوصی انجام شده است.

برای معیارهای آمادگی انتشار نرم‌افزار آمادهٔ تولید را ببینید.

منابع و مراجع

• API and data retention — Anthropic (Claude Platform Docs)، 2026-10-19.
• Data controls in the OpenAI platform — OpenAI API Docs، 2026-10-19.
• Retrieval Augmented Generation — Amazon SageMaker AI Developer Guide.