Zero Data Retention کافی نیست؛ هر قابلیت API قرارداد ذخیره‌سازی خودش را دارد

برای ارسال دادهٔ حساس به OpenAI API یا Claude API، فعال بودن Zero Data Retention یا ZDR در حساب کافی نیست. باید بدانید سیاست پیش‌فرض چیست، کنترل برای سازمان و پروژه یا فضای کاریِ فرستندهٔ درخواست فعال شده یا نه، مدل و قابلیت انتخابی واجد شرایط‌اند یا نه، و چه فایل یا وضعیت برنامه‌ای پس از پاسخ باقی می‌ماند. نگهداری محتوای درخواست، لاگ پایش سوءاستفاده و شیء ذخیره‌شدهٔ برنامه سه موضوع جدا هستند.

مبنای تصمیم، مسیر واقعی داده در برنامه است: درخواست از کدام کلید و تنظیم عبور می‌کند، به چه endpoint و ابزاری می‌رسد، آیا فایل یا کار دسته‌ای می‌سازد و حذف هر شیء بر عهدهٔ کیست. یک پاسخ موفق از API فقط نشان می‌دهد درخواست اجرا شده است؛ دربارهٔ پوشش ZDR برای همهٔ اجزای آن حکم نمی‌دهد.

در OpenAI، پیش‌فرض را از کنترل فعال جدا کنید

طبق مستندات کنترل دادهٔ OpenAI، لاگ‌های پایش سوءاستفاده ممکن است به‌طور پیش‌فرض محتوای مشتری را تا ۳۰ روز نگه دارند؛ دادهٔ پاسخ در Responses نیز، جز در استثناهای مستند، به‌طور پیش‌فرض دست‌کم ۳۰ روز به‌عنوان وضعیت برنامه ذخیره می‌شود. این دو دوره به دو نوع نگهداری تعلق دارند. حذف محتوا از لاگ پایش سوءاستفاده به‌خودی‌خود شیء ساخته‌شده برای اجرای یک قابلیت را حذف نمی‌کند.

دریافت ZDR به تأیید قبلی OpenAI نیاز دارد. پس از تأیید، کنترل می‌تواند در سطح سازمان یا پروژه تنظیم شود؛ پروژه ممکن است تنظیم سازمان را به ارث ببرد، کنترل دیگری انتخاب کند یا آن را غیرفعال کند. بنابراین وجود قرارداد یا تنظیم سازمانی را باید با تنظیم همان پروژه‌ای تطبیق داد که کلید API آن در برنامه استفاده می‌شود.

در مسیرهای واجد شرایط، ZDR محتوای مشتری را از لاگ پایش سوءاستفاده کنار می‌گذارد و مقدار store را برای Responses و Chat Completions همواره false در نظر می‌گیرد، حتی اگر درخواست true بفرستد. کنترل Modified Abuse Monitoring نیز محتوا را، با محدودیت‌های مستند، از این لاگ‌ها کنار می‌گذارد، اما همان تغییر رفتار store را اعمال نمی‌کند. در هر دو حالت، وضعیت یک قابلیت فاقد صلاحیت را باید مستقل از تنظیم لاگ بررسی کرد.

در Claude، سازمان، فضای کاری و مدل تعیین‌کننده‌اند

راهنمای نگهداری Claude API برای مدل‌های Covered Models الزام نگهداری ۳۰روزه، برای پردازش Batch نگهداری ۲۹روزه و برای دادهٔ محیط اجرای کد نگهداری تا ۳۰ روز را ثبت می‌کند. محتوای گفت‌وگو در مسیر معمول به‌طور پیش‌فرض پس از پاسخ نگهداری نمی‌شود، اما این قاعده شامل مدل‌ها و قابلیت‌هایی که به ذخیره‌سازی نیاز دارند نیست.

ZDR در Claude برای هر سازمان جداگانه فعال می‌شود و خودکار به سازمان دیگری در همان حساب گسترش نمی‌یابد. سازمان دارای ZDR می‌تواند برای استفاده از Covered Models نگهداری استاندارد را در یک فضای کاری مشخص فعال کند؛ در این صورت همان فضای کاری شرایط متفاوتی از بقیه دارد. نام سازمان، فضای کاری و مدل باید کنار هم ثبت شوند تا تنظیم یک مسیر به مسیر دیگر تعمیم داده نشود.

Messages API برای قابلیت‌های واجد شرایط زیر پوشش ZDR قرار می‌گیرد، ولی هر ابزاری که از مسیر Messages فراخوانی می‌شود همان صلاحیت را ندارد. اجرای کد و اتصال MCP در جدول صلاحیت خارج از پوشش‌اند؛ در مقابل، برخی ابزارهای سمت کاربر داده را در محیط خود کاربر نگه می‌دارند. Claude درخواست دارای قابلیت فاقد صلاحیت ZDR را الزاماً مسدود نمی‌کند، پس موفقیت درخواست نشانهٔ پوشش آن قابلیت نیست.

فایل و وضعیت گفت‌وگو مسیر حذف خود را دارند

راهنمای وضعیت گفت‌وگوی OpenAI توضیح می‌دهد که شیء Conversation و اجزای آن تابع مهلت ۳۰روزهٔ پاسخ‌های معمول نیستند؛ پاسخِ متصل به Conversation نیز همراه همان وضعیت ماندگار می‌شود. بنابراین false شدن store در یک درخواست Responses نباید با حذف Conversation اشتباه گرفته شود. شناسهٔ شیء گفت‌وگو و راه حذف آن باید در طراحی برنامه مشخص باشد.

در OpenAI، مسیرهای Files و Batches واجد شرایط ZDR نیستند و می‌توانند وضعیت برنامه را تا حذف نگه دارند؛ برای فایل می‌توان حذف دستی یا انقضای تنظیم‌شده تعیین کرد. در Claude نیز Files API فایل را تا حذف صریح یا انقضای پیکربندی‌شده نگه می‌دارد و نشست‌های Claude Managed Agents تا حذف نشست ماندگارند. فرستادن محتوای فایل در یک درخواست واجد شرایط با بارگذاری و نگهداری یک شیء در Files API یک تصمیم ذخیره‌سازی یکسان نیست.

ابزار متصل مرز دیگری به مسیر داده اضافه می‌کند. اگر درخواست به سرور MCP یا سرویس شخص ثالث برسد، نگهداری داده نزد آن مقصد تابع رویهٔ همان سرویس است. برای ابزار سمت کاربر نیز محل ذخیرهٔ فایل، تصویر یا حافظهٔ ایجادشده باید در محیط خود برنامه مشخص شود؛ ZDR ارائه‌دهندهٔ مدل برای آن محل، سیاست حذف تعیین نمی‌کند.

ماتریس تصمیم را برای هر مسیر درخواست بسازید

برای هر کاربرد، یک ردیف با ستون‌های «دادهٔ ورودی»، «سازمان و پروژه یا فضای کاری»، «مدل»، «endpoint و ابزار»، «شیء ماندگار»، «شرط انقضا یا حذف» و «مسئول حذف» ثبت کنید. ردیف باید مسیر اجراشده را توصیف کند، نه کل محصول را؛ افزودن ابزار، فایل یا مدل تازه می‌تواند نتیجهٔ همان مسیر را عوض کند.

• تولید پاسخ: در OpenAI تنظیم پروژه و رفتار store را برای Responses یا Chat Completions ثبت کنید. در Claude، سازمان، فضای کاری، مدل و قابلیت‌های فراخوانی‌شده در Messages را کنار هم بگذارید.
• وضعیت ماندگار: برای Conversation یا نشست عامل، شناسهٔ شیء و عملیاتی را که واقعاً آن را حذف می‌کند بنویسید. مدت نگهداری پاسخ معمول را به این اشیا تعمیم ندهید.
• فایل و Batch: ورودی بارگذاری‌شده، خود کار و خروجی ذخیره‌شده را جدا ثبت کنید. برای هرکدام معلوم کنید انقضای خودکار وجود دارد یا حذف صریح لازم است.
• ابزار و مقصد بیرونی: دادهٔ ارسالی به اجرای کد، اتصال MCP یا ابزار سمت کاربر را مشخص کنید. مالک نگهداری و حذف داده در مقصد ممکن است با مالک درخواست اصلی فرق داشته باشد.

پیش از استقرار، تنظیم و حذف را قابل بررسی کنید

1. محتوای لازم برای هر درخواست را محدود کنید. شناسه‌های اضافی و دادهٔ حساس در نام فایل، فراداده یا آرگومان ابزار را حذف یا جایگزین کنید، مگر آنکه برای انجام کار ضروری باشند.
2. تأیید ZDR و مقدار فعال آن را برای همان سازمان و پروژه یا فضای کاری ثبت کنید. تنظیم به‌ارث‌رسیده را نیز مشخص کنید تا تغییر در سطح بالاتر یا انتخاب یک استثنا پنهان نماند.
3. فهرست مدل‌ها، endpointها و ابزارهای مسیر را با جدول صلاحیت ارائه‌دهنده تطبیق دهید. قابلیت فاقد صلاحیت را با سیاست نگهداری خودش ارزیابی کنید، حتی اگر درخواست اصلی از endpoint واجد شرایط عبور کند.
4. برای هر فایل، کار یا نشست ماندگار، شناسه، شرط انقضا و مسئول اجرای حذف را در سامانهٔ خود نگه دارید. مقصدهای شخص ثالث را نیز در همین فهرست بیاورید.
5. با دادهٔ ساختگی یک شیء بسازید، حذف یا انقضای آن را اجرا کنید و امکان بازیابی همان شیء را بررسی کنید. این آزمون دسترسی به شیء را می‌سنجد؛ نتیجه‌اش را اثبات حذف همهٔ لاگ‌ها یا نسخه‌های پشتیبان تلقی نکنید.

اگر برای مسیری محل ذخیره، شرط حذف یا صلاحیت یکی از قابلیت‌ها روشن نیست، پیش از ارسال دادهٔ حساس همان بخش از طراحی یا تنظیم را مشخص کنید. تصمیم نگهداری باید به درخواست و اشیایی که واقعاً می‌سازد متصل باشد.

بیشتر بخوانید:

• Joplin یا Obsidian؛ همگام‌سازی آسان با مالکیت فایل یک انتخاب نیست
• رمز WhatsApp را فعال کنید؛ کد یک‌بارمصرف به‌تنهایی کافی نیست
• گفتار فارسی را دقیق‌تر متن کنید؛ WER به‌تنهایی کافی نیست