۶ نقطهٔ کور در وعده‌های «عدم ذخیره‌سازی داده‌ها» توسط ارائه‌دهندگان هوش مصنوعی

اگر امروز برای مدل‌های هوش مصنوعی هزینه پرداخت می‌کنید، احتمالاً بخشی از حریم خصوصی شما در نقاطی پنهان نشت می‌کند. وعده «عدم ذخیره‌سازی داده‌ها» (Zero Data Retention یا ZDR) که ارائه‌دهندگان با اطمینان می‌دهند، در واقع یک حقیقت ناقص است. در حالی که این وعده ممکن است مانع از ورود داده‌های شما به مجموعه‌های آموزشی (Training Sets) شود، اما به‌ندرت شش مکان متمایز را پوشش می‌دهد که در آن‌ها یک بایت از پرامپت شما همچنان می‌تواند ثبت و ذخیره شود.

بسیاری از توسعه‌دهندگان ZDR را مانند یک کلید روشن/خاموش می‌بینند، اما طبق راهنمای فنی منتشر شده در ۱۲ اوت ۲۰۲۶ توسط dev.to، این ادعا معمولاً فقط روی حافظه‌های دائمی (Durable Storage) اعمال می‌شود. در یک محیط عملیاتی، یک پرامپت پیش از رسیدن به مدل، از نقشه پیچیده‌ای از دست‌ها عبور می‌کند و اکثر تعهدات ZDR، نیمی از این مسیر را نادیده می‌گیرند.

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

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های زیرساختی همیشه متغیری هستند که در قراردادهای بازاریابی حذف می‌شوند.

۶ نقطهٔ در معرض خطر

بر اساس تحلیل dev.to، شش نقطه بحرانی وجود دارد که داده‌ها در آن‌ها باقی می‌مانند. شما باید پیش از خواندن هرگونه شرایط خدمات (Terms of Service)، مسیر درخواست خود را ترسیم کنید:

• نقطه ۱: لاگ‌های داخلی شما: ردپاهای اپلیکیشن (Application Traces)، گزارش‌های خطا و لاگ‌های دیباگ.
• نقطه ۲: لایه Gateway/SDK: لاگ‌های درخواست، بافرهای تلاش مجدد (Retry Buffers) و بازه‌های APM.
• نقطه ۳: لایه Edge/CDN/WAF: لاگ‌های دسترسی و نمونه‌برداری از بدنه درخواست (Request Body Sampling) هنگام بروز خطا.
• نقطه ۴: ورودی API ارائه‌دهنده: خط لوله‌های طبقه‌بندی ایمنی و شناسایی سوءاستفاده (Abuse and Safety Classification Pipelines).
• نقطه ۵: خوشه استنتاج (Inference Cluster): KV Cache — شبیه به یادداشت‌های سریع مدل برای به خاطر آوردن کلمات قبلی —، بافرهای دسته‌ای (Batch Buffers) و دامپ‌های کرش (Crash Dumps).
• نقطه ۶: ذخیره‌ساز ارائه‌دهنده: سوابق دائمی درخواست/پاسخ و نسخه‌های پشتیبان (Backups).

تعهد ZDR معمولاً فقط نقطه ۶ و گاهی نقطه ۴ را پوشش می‌دهد. این یعنی محتوای درخواست و پاسخ به حافظه دائمی نوشته نمی‌شود یا وارد خط لوله‌هایی که داده را نگه می‌دارند نمی‌شود. اگرچه این موضوع ارزشمند است، اما بسیار محدودتر از آن چیزی است که عبارت «عدم ذخیره‌سازی» القا می‌کند.

نقطه ۵ — یعنی حافظه‌ای که هنگام اجرای مدل استفاده می‌شود — تقریباً هرگز پوشش داده نمی‌شود چون داده برای پردازش باید در حافظه باشد. اما ریسک واقعی در نقطه ۵، «دامپ هسته» (Core Dump) هنگام کرش کردن سیستم است. سؤالات حیاتی این است که آیا این دامپ‌ها ثبت می‌شوند، به کجا می‌روند و چه مدت باقی می‌مانند؛ جزئیاتی که به‌ندرت در صفحات بازاریابی یافت می‌شوند. این چالش‌ها نشان می‌دهد که مدیریت حافظه در هوش مصنوعی صرفاً یک مسئله فنی نیست، بلکه یک پروتکل اعتماد است که باید به جای یک ویژگی دیتابیس ساده به آن نگریست.

شکاف متاداده‌ها

حتی با یک سیاست سخت‌گیرانه ZDR، تقریباً هر ارائه‌دهنده‌ای متاداده‌ها (Metadata) را نگه می‌دارد. این موارد شامل تعداد توکن — تکه‌های کوچکی از متن شبیه برش‌های کیک که مدل می‌خورد —، نام مدل، برچسب‌های زمانی (Timestamps)، تأخیر (Latency)، شناسه‌های حساب (Account IDs) و کدهای خطا است. این داده‌ها چون برای صورت‌حساب (Billing) و جلوگیری از سوءاستفاده ضروری هستند، حذف نمی‌شوند.

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

استثناهای دائمی

چندین استثنا وجود دارد که تقریباً تمام تعهدات ZDR را باطل می‌کند:

• احکام قانونی (Legal Holds): دستورات قانونی الزام‌آور همیشه بر وعده‌های ذخیره‌سازی اولویت دارند. فروشنده‌ای که خلاف این را وعده دهد، چیزی را قول داده است که نمی‌تواند تحویل دهد.
• بررسی سوءاستفاده: محتوایی که توسط طبقه‌بندهای ایمنی علامت‌گذاری می‌شود، معمولاً از مسیر ZDR خارج شده تا یک انسان آن را بررسی کند. شما باید به‌طور مشخص بپرسید که آیا محتوای علامت‌گذاری شده از تعهد ZDR مستثنی است یا خیر.
• تأخیر در تکثیر (Replication Lag): اگر ZDR به صورت «حذف پس از ۲۴ ساعت» اجرا شود (به جای «عدم ثبت اولیه»)، نسخه‌های پشتیبان تفاوت ایجاد می‌کنند. «حذف در ۲۴ ساعت» و «هرگز نوشته نشدن» دو محصول کاملاً متفاوت هستند.
• پردازش‌کنندگان فرعی (Sub-processors): تعهد فقط برای طرفی است که آن را امضا کرده است. اگر ارائه‌دهنده درخواست شما را به جای دیگری بفرستد، آن پردازش‌کننده فرعی تحت شرایط خودش عمل می‌کند، مگر اینکه قرارداد صراحتاً این تعهد را به لایه‌های پایین‌تر منتقل کرده باشد.

۶ سؤال برای به چالش کشیدن ادعای ارائه‌دهنده

به‌جای خواندن صفحه بازاریابی، این ۶ سؤال را کتباً از فروشنده بپرسید:

۱. آیا عدم ذخیره‌سازی به صورت «عدم ثبت» (Non-persistence) است یا «حذف با تایمر»؟ اگر تایمر است، بازه زمانی چیست و آیا این مورد روی نسخه‌های پشتیبان هم اعمال می‌شود؟
۲. آیا محتوای علامت‌گذاری شده توسط سیستم‌های ایمنی یا شناسایی سوءاستفاده از مسیر ZDR خارج می‌شود؟ اگر بله، چه چیزی و برای چه مدت باقی می‌ماند؟
۳. کدام فیلدها بدون استثنا ذخیره می‌شوند؟ (به‌جای کلمه کلی «متاداده»، لیست دقیق فیلدها را بخواهید).
۴. آیا ZDR در سطح حساب است، برای هر کلید (Per-key) یا برای هر درخواست (Per-request)؟ اگر برای هر درخواست است، در صورت فراموشی فلگ در یک درخواست چه اتفاقی می‌افتد؟
۵. کدام پردازش‌کنندگان فرعی در مسیر مدل‌های ما هستند و آیا تعهد ذخیره‌سازی به صورت قراردادی به آن‌ها منتقل شده است؟
۶. چگونه می‌توانیم این موضوع را به یک حسابرس ثابت کنیم؟ آیا گزارشی وجود دارد، تنظیماتی هست که بتوانیم بازخوانی کنیم یا فقط متن قرارداد ملاک است؟

برای مهندسان، خطرناک‌ترین حالت، فلگِ «در سطح درخواست» است. اگر ZDR فلگی است که باید با هر فراخوانی بفرستید، هر مسیر کدی که آن را فراموش کند — مثل یک تلاش مجدد خودکار در هندلر خطا یا یک اسکریپت تک‌بار در محیط Production — به‌طور خاموش داده‌ها را به حالت ذخیره‌سازی برمی‌گرداند. اگر امکان تنظیم در سطح حساب وجود دارد، حتماً آن را فعال کنید.

نیمی که مسئولیتش با شماست

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

• لاگ‌های اپلیکیشن در سطح debug
• ردیاب‌های استثنا (Exception Trackers) که بدنه درخواست را ضمیمه می‌کنند
• ردیابی APM که ویژگی‌های بازه (Span Attributes) را ثبت می‌کند
• خروجی‌های دیباگ کلاینت HTTP
• صف‌های مورد استفاده برای تلاش مجدد (Retry Queues)
• جداول تاریخچه گفتگو در پایگاه‌داده خودتان
• رویدادهای تحلیلی (Analytics Events) که پیام کاربر را به عنوان یک ویژگی (Property) ذخیره می‌کنند

این تغییر دیدگاه، بار حریم خصوصی را از قرارداد فروشنده به معماری مهندس منتقل می‌کند. شما باید کد خود را برای یافتن نقاط ثبت درخواست (Request-logging call sites) جست‌وجو کنید. یک استاندارد مفید این است که بدنه پرامپت و پاسخ هرگز خارج از یک حالت دیباگِ کنترل‌شده لاگ نشوند و این کنترل، یک تنظیم در زمان استقرار (Deployment-time configuration) باشد، نه یک ثابت در کد (Code constant) که کسی آن را تغییر دهد و فراموش کند. در این راستا، برخی ابزارها برای مدیریت بهینه حافظه محلی تلاش کرده‌اند، مانند رویکرد Cortex در بازسازی حافظه عامل‌ها با SQLite برای کاهش وابستگی به ذخیره‌سازهای خارجی.

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

گام بعدی شما

• تمام نقاط ثبت لاگ (Logging) در کد خود را بررسی کنید و مطمئن شوید بدنه درخواست‌های AI در محیط Production ذخیره نمی‌شود.
• اگر از APIهای تجاری استفاده می‌کنید، ۶ سؤال ذکر شده در این مقاله را برای تیم پشتیبانی فنی آن‌ها ارسال کنید.
• تنظیمات ZDR را از حالت «در سطح درخواست» به «در سطح حساب» تغییر دهید تا ریسک خطای انسانی کاهش یابد.

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