Zero Data Retention یک کنترل است، نه معماری داده

«ارائه‌دهنده مدل پرامپت ما را نگه نمی‌دارد» جمله مفیدی است. با «فیچر AI ما داده مشتری را نگه نمی‌دارد» یکی نیست. تیم‌ها این دو را قاطی می‌کنند چون صدای مدل قسمت دیدنی ایجنت است. رد داده دور و بر آن است که بیشتر سیستم واقعاً آنجا زندگی می‌کند.

Zero Data Retention، جایی که ارائه‌دهنده برای مشتری واجد شرایط API وعده می‌دهد پرامپت و پاسخ بعد از پردازش نماند، مرز مهمی را عوض می‌کند. کپی داخل لاگ درخواست خودت، trace در ابزار مشاهده‌پذیری، آرگومان ابزار در صف، job شکست‌خورده در dead-letter، یا رونوشتی که گردش کار پشتیبانی برای بعد ذخیره کرده را پاک نمی‌کند.

جواب عملی این نیست که ZDR را بی‌ارزش بدانی. این است که دقیق از آن استفاده کنی: یک کنترل در معماری داده‌ای که هنوز مال خودت است.

از مسیر واقعی شروع کن، نه از پنجره چت

برای یک درخواست پروداکشن مسیر را بکش. مشتری سند می‌فرستد، بک‌اند متن را درمی‌آورد، ایجنت زمینه داخلی را می‌گیرد، مدل را صدا می‌زند، ابزار را اجرا می‌کند، نتیجه را می‌نویسد، و متریک می‌فرستد. هر فلش می‌تواند داده را کپی کند. هر retry می‌تواند دوباره کپی کند.

در سیستم واقعی فهرست معمولاً بلندتر از چیزی است که کسی سر جلسه حدس می‌زند: لاگ reverse-proxy و اپ، لاگ پلتفرم serverless و گزارش exception، صف و رکورد تلاش دوباره و پیام dead-letter، trace مدل که پرامپت و ابزار و پاسخ را برمی‌دارد، vector store و فایل موقت، رویداد آنالیتیکس و session replay و تیکت پشتیبانی، و جدول‌هایی که وضعیت مکالمه یا خروجی تولیدشده را نگه می‌دارند.

ZDR یک جعبه از این نمودار را عوض می‌کند. برای پرامپت حساس و بار مقرراتی جعبه ارزشمندی است. اجازه نمی‌دهد بقیه نمودار را نکشی.

تمرین مفید این است که بپرسی هر جزء حداقل به چه داده‌ای نیاز دارد. لاگ معمولاً به شناسه درخواست، تأخیر، شناسه مدل، تعداد توکن، و نتیجه نیاز دارد. به متن کامل پرامپت مشتری نه. trace شاید به نام ابزار و دلیل شکست پاک‌شده نیاز داشته باشد، نه به آرگومان خام. رکورد حسابرسی محصول شاید به عمل نهایی و هویت تأییدکننده نیاز داشته باشد، نه به زنجیره استدلال پنهان.

وقتی این سؤال را بپرسی، معماری هم ساده‌تر می‌شود هم امن‌تر.

مشاهده‌پذیری جایی است که قول حریم خصوصی می‌میرد

مشاهده‌پذیری ایجنت مفید است چون شکست را از روی یک status code بازسازی نمی‌کنی. مهندس می‌خواهد پرامپت، هر قطعه بازیابی‌شده، ورودی ابزار، خروجی ابزار، و پاسخ مدل را ببیند. برای دیباگ عالی است. به‌عنوان سیاست نگهداری پیش‌فرض افتضاح است.

trace با محتوای کامل را استثنا کن. فقط در محیط توسعه محافظت‌شده نمونه‌برداری کن، یا پشت پرچم حادثه موقت با تاریخ انقضا. در پروداکشن فراداده ساخت‌یافته را ترجیح بده: شناسه trace، مسیر، مدل، تأخیر، تعداد توکن، برخورد کش، نام ابزار، کلاس نتیجه ابزار، و کد خطا. اگر برای یک حادثه محتوا لازم شد، قبل از خروج از زیرساخت redact کن و نگهداری را کوتاه بگذار.

این یعنی کور پرواز کردن نیست. یعنی مشاهداتی را انتخاب کنی که سؤال عملیاتی واقعی را جواب بدهند. آیا صدای مدل مهلت خورد؟ آیا ابزار مجوز نداشت؟ آیا بازیابی صفر نتیجه داد؟ آیا تأیید بیش از حد معطل ماند؟ هیچ‌کدام به کپی دائمی هر مکالمه مشتری نیاز ندارند.

همین نظم را روی خطا هم بگذار. خیلی فریمورک‌ها وقتی exception بالا می‌آید شیء درخواست را برمی‌دارند. یکپارچه‌سازی گزارش خطا می‌تواند پرامپت، نام فایل، توکن دسترسی، یا محموله ابزار را بدون هیچ کد مخصوص ایجنت صادر کند. گزارش خطا را بخشی از بازبینی داده بدان، نه یک ابزار خنثی که کنار سیستم نصب شده.

داده خصوصی را از راه ابزار قاچاق نکن

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

جایی که می‌شود، شناسه پایدار بده نه رکورد خام. ابزاری که سفارش را نگاه می‌کند باید شناسه سفارش و زمینه مجوز بگیرد، نه کل پروفایل مشتری داخل آرگومان JSON. ابزار پردازش سند باید ارجاع فایل کوتاه‌عمر بگیرد، نه سند base64 داخل رونوشت ایجنت. ابزار نوشتن باید شناسه رکورد ساخته‌شده و وضعیت نتیجه را برگرداند، نه اینکه ورودی ارسال‌شده را دوباره پژواک کند.

فایده قابلیت اطمینان هم دارد. schema کوچک‌تر یعنی پرامپت کوچک‌تر، retry روشن‌تر، بررسی مجوز ساده‌تر، و کپی تصادفی کمتر در لاگ. حریم خصوصی و کیفیت عملیاتی اغلب یک جهت را نشان می‌دهند وقتی سیستم وضعیت اتفاقی کمتری حمل می‌کند.

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

«فقط وقتی لازم است نگه می‌داریم» سیاستی نیست که دیتابیس اجرا کند. هر ذخیره به مالک، دلیل وجود، و برنامه حذف نیاز دارد. اگر سیستم نتواند بگوید رکورد کی منقضی می‌شود، آرام دائمی می‌شود.

برای آپلود موقت، محموله صف، نشست ایجنت، و trace دیباگ TTL صریح بگذار. حذف را job عادی کن و اندازه‌اش بگیر. رکورد حسابرسی حداقلی را که برای امنیت یا پشتیبانی لازم است از رونوشت کامل اجرا که فقط موقع دیباگ لازم است جدا نگه دار. به دوره نگهداری پیش‌فرض فروشنده تکیه نکن که با قول محصول یکی باشد. پیش‌فرض عوض می‌شود و یکپارچه‌سازی زیاد می‌شود.

استثنا هست. مشتری می‌خواهد سند بماند، تحقیق حقوقی hold می‌خواهد، یا گردش کار مقرراتی تاریخچه حسابرسی بلندتر می‌خواهد. این‌ها را وضعیت نام‌دار کن با کنترل دسترسی و تاریخ بازبینی. «محض احتیاط» دسته استثنا نیست.

ZDR شکل دیباگ را هم عوض می‌کند

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

برای سناریوهایی که مال خودت است ورودی بازپخش قطعی بساز: سند مصنوعی، fixture پاک‌شده، و قرارداد ابزار ضبط‌شده بدون راز. روی هر مرز شناسه همبستگی لاگ کن تا حادثه از فراداده بازسازی شود. برای جریان پرریسک، به‌جای ترافیک خام نامحدود، بسته بازتولید redactشده و تأییدشده توسط مشتری را برای مدت کوتاه نگه دار.

این مدل دیباگ منضبط‌تری است. از مهندس می‌خواهد رفتار پروداکشن قابل مشاهده باشد بدون اینکه محتوای مشتری خوراک رایگان تله‌متری شود. حتی اگر ZDR را روشن نکنی هم به درد می‌خورد، چون شعاع انفجار یک اشتباه لاگ را کم می‌کند.

یک عرضه عملی

یک ایجنت را انتخاب کن که داده‌ای را لمس می‌کند که نمی‌خواهی در اسکرین‌شات باشد. کپی‌هایش را سر به سر نقشه بکش. لاگ پرامپت کامل را در پروداکشن خاموش کن. قبل از اینکه trace و گزارش خطا از زیرساخت خارج شوند redact بگذار. محموله خام ابزار را با شناسه یا فیلد حداقلی عوض کن. روی صف، فایل موقت، و trace ساعت انقضا بگذار. بعد تنظیم نگهداری واجد شرایط ارائه‌دهنده را روشن کن و دقیق بنویس چه چیزی را پوشش می‌دهد و چه چیزی را نه.

در آخر حذف را تست کن. یک رکورد آزمون شناخته‌شده بساز، در محیط امن دوره نگهداری‌اش را بگذران، و مطمئن شو از هر ذخیره‌ای که نام بردی ناپدید شده. سیاست حریم خصوصی بدون تست حذف فقط امید است که job پس‌زمینه درست پیکربندی شده باشد.

ZDR اهرم معناداری برای سیستم AI است. از آن استفاده کن. فقط نگذار یک تنظیم سطح فروشنده تبدیل به داستانی شود که اپلیکیشن نمی‌تواند صادقانه تعریف کند. مشتری به مسیر داده اهمیت می‌دهد، نه به اینکه کدام جزء صدای مدل را زده.

پرسش‌های کوتاه

**ZDR را روشن کنم و تمام؟** نه. اول نمودار کپی را بکش. ZDR فقط جعبه ارائه‌دهنده را عوض می‌کند.

**trace پروداکشن باید پرامپت را داشته باشد؟** پیش‌فرض نه. فراداده ساخت‌یافته کافی است. محتوای کامل را استثنا، redactشده، و کوتاه‌عمر کن.

**ابزار چرا شناسه بهتر از رکورد کامل است؟** چون مجوز، retry، و لاگ همه روی سطح کوچک‌تر ساده‌تر و کم‌کپی‌تر می‌شوند.