وقتی انسان داده را نمی‌بیند؛ آیا واقعاً دسترسی او حذف شده است؟

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

اما اگر همان کارشناس بتواند برنامهٔ آموزش را تغییر دهد و چند سطر از داده را در گزارش خطا قرار دهد، چه اتفاقی افتاده است؟ اگر اجازهٔ دریافت فایل مدل را داشته باشد، اما مدل اطلاعاتی از دادهٔ آموزش را بازگو کند، مرز محرمانگی کجاست؟ و اگر مدیر زیرساخت بتواند حافظهٔ محیط اجرا را بخواند یا کلید رمزگشایی را به دست آورد، حذف حساب کاربری پایگاه داده چه چیزی را تضمین کرده است؟

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

حذف انسان از مسیر داده، یک هدف معماری است

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

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

این برداشت، هدف معماری مورد بحث در این مجموعه است و نباید آن را عین تعریف یک استاندارد مستقل و مصوب ZTAI تلقی کرد. معماری بدون اعتماد NIST نیز از ابتدا منابع، خدمات و گردش کار را در بر می‌گیرد. تأکید اینجا بر بازطراحی فرایند برای حذف نیاز به دخالت مستقیم انسان در داده‌های حساس و محدودکردن اختیاراتی است که می‌توانند این جدایی را بی‌اثر کنند.

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

حق نوشتن کد می‌تواند راهی برای خواندن داده باشد

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

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

در نتیجه، درخواست اجرای یک فرایند باید بیش از نام برنامه یا هویت درخواست‌کننده را مشخص کند. نسخهٔ کد، دادهٔ مجاز، عملیات، مقصد خروجی، مدت اعتبار و محدودیت منابع، اجزای همان درخواست‌اند. مجوز اجرای آموزش روی مجموعه‌ای معین، نباید به مجوز اجرای هر برنامه‌ای با هر خروجی روی آن مجموعه تبدیل شود.

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

سه اختیار را از یکدیگر جدا کنیم

تفکیک نقش‌ها فقط به این معنا نیست که نام سه نفر در سه ستون یک جدول نوشته شود. سه اختیار باید در سازوکار اجرا از یکدیگر مستقل باشند: تعریف پردازش، پذیرش آن برای اجرا و اجازهٔ خروج نتیجه.

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

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

موتور سیاست نیز بخشی از همین مسئله است. استقرار آن در یک سرویس جدا، به‌تنهایی استقلال ایجاد نمی‌کند. اختیار تغییر سیاست، کلید امضا، مسیر انتشار و حساب مدیریتی آن باید بررسی شود. یک کنترل تنها تا جایی مستقل است که جزء تحت کنترل نتواند آن را بازتعریف کند.

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

مرز خروج اطلاعات، از همهٔ خط لوله‌ها عبور می‌کند

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

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

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

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

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

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

خروج مدل، تصمیمی جدا از آموزش مدل است

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

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

پروژهٔ SACRO-ML برای بررسی خطر افشای مدل‌های آموزش‌دیده در محیط‌های پژوهشی حفاظت‌شده، ابزارهایی پیش و پس از آموزش ارائه می‌کند. ارزش این رویکرد، افزودن شواهد افشا به تصمیم انتشار است. بااین‌حال، موفق‌نبودن حمله‌های آزمایش‌شده را نباید تضمین ریاضی عدم افشا دانست یا پوشش یک ابزار را به همهٔ معماری‌های مدل تعمیم داد.

همین دقت دربارهٔ دادهٔ مصنوعی لازم است. داده‌ای که از مجموعهٔ حساس تولید شده، ممکن است اطلاعات همان مجموعه را آشکار کند. راهنمای NIST دربارهٔ ارزیابی تضمین‌های حریم خصوصی تفاضلی، منتشرشده در مارس ۲۰۲۵، این محدودیت را صریحاً بررسی می‌کند. در کاربرد مناسب، حریم خصوصی تفاضلی می‌تواند اثر حضور یک فرد یا واحد تعریف‌شده را در نتایج محدود کند؛ تضمین آن به تعریف واحد حفاظت، پارامترها و پیاده‌سازی وابسته است و همهٔ اسرار عملیاتی سازمان را پوشش نمی‌دهد.

نتیجه‌های کوچک هم می‌توانند اطلاعات بزرگی بدهند

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

از این‌رو، مجوز به یک خروجی منفرد محدود نمی‌شود؛ سابقهٔ درخواست، هم‌پوشانی گروه‌ها، تعداد تکرار و ترکیب اطلاعات نیز اهمیت دارد. حداقل اندازهٔ گروه و محدودیت تعداد درخواست می‌توانند بخشی از دفاع باشند، اما تضمین عمومی ایجاد نمی‌کنند. در روش‌های مبتنی بر حریم خصوصی تفاضلی نیز باید بودجهٔ حریم خصوصی در مجموع انتشارها محاسبه شود، نه اینکه برای هر درخواست از ابتدا آغاز شود. NIST SP 800-226

این مسئله یک پیام معماری دارد: جزء صادرکنندهٔ نتیجه باید به اطلاعات لازم برای ارزیابی درخواست‌های مرتبط دسترسی داشته باشد. اگر هر اجرای کوتاه‌عمر، سیاست را بدون اطلاع از اجراهای پیشین اعمال کند، محدودیتی که در یک اجرا برقرار بوده ممکن است در مجموعهٔ اجراها بی‌اثر شود.

اگر مدیر زیرساخت هم نباید داده را ببیند

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

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

پردازش محرمانه یا Confidential Computing، با استفاده از محیط اجرای مورد اعتماد یا TEE، می‌تواند بخشی از این حفاظت را با پشتوانهٔ سخت‌افزار فراهم کند. الگوی کلی آن چنین است: داده و مدل رمز‌شده باقی می‌مانند؛ شواهد محیط اجرا ارزیابی می‌شود؛ و کلید فقط در اختیار محیطی قرار می‌گیرد که با سیاست پذیرش تطبیق دارد. راهنمای NVIDIA، به‌روزشده در مهٔ ۲۰۲۶، ترکیب محیط‌های محرمانهٔ CPU و GPU، گواهی‌سنجی و آزادسازی مشروط کلید را تشریح می‌کند.

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

در بار کاری هوش مصنوعی، مرز حفاظت ممکن است از حافظهٔ CPU تا حافظهٔ GPU و مسیر انتقال میان آن‌ها امتداد پیدا کند. پشتیبانی یک تراشه کافی نیست؛ سرور، firmware، درایور و شیوهٔ استقرار نیز باید سازگار باشند. پیوند این بحث با امنیت زیرساخت هوش مصنوعی از کرنل تا GPU دقیقاً در همین زنجیره است.

گواهی‌سنجی باید به تصمیم اجرایی متصل شود

گواهی‌سنجی محیط اجرا یا Attestation، زمانی به محدودکردن دسترسی کمک می‌کند که نتیجهٔ آن در تصمیمی مؤثر مصرف شود: برای نمونه، تحویل‌دادن یا ندادن کلید به یک اجرای مشخص. دریافت گزارشی که صرفاً بایگانی می‌شود، مانع استفاده از محیط نامعتبر نخواهد شد.

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

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

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

مسیر تعمیر نباید دسترسی حذف‌شده را دائمی کند

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

برای معماری‌ای که حذف دسترسی انسان را دنبال می‌کند، عیب‌یابی باید از ابتدا طراحی شود: گزارش‌های ساختاریافته و محدود، بازتولید خطا با دادهٔ آزمایشی، اجرای آزمون تشخیصی در همان مرز و بازیابی از نسخهٔ معتبر. نیاز به تعمیر نباید خودکار به تحویل دادهٔ خام تبدیل شود.

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

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

چه شواهدی نشان می‌دهد دسترسی واقعاً محدود شده است؟

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

این آزمون‌ها دامنه و محدودیت دارند. قبولی در مجموعه‌ای از آزمون‌ها، شواهدی دربارهٔ همان سناریوها فراهم می‌کند؛ اثبات بسته‌بودن همهٔ حمله‌های ممکن نیست. حتی زمان اجرا، اندازهٔ خروجی و الگوی خطا می‌توانند در مدل‌های تهدید سخت‌گیرانه به‌عنوان کانال انتقال اطلاعات بررسی شوند. سطح ادعا باید با آنچه واقعاً طراحی و آزموده شده متناسب بماند.

دو شاخص نیز باید جداگانه دنبال شوند: میزان خودکارشدن فرایند و میزان کاهش دسترسی انسانی. ممکن است خط لوله‌ای کاملاً خودکار باشد، اما افراد متعددی بتوانند داده، حافظه یا خروجی نامحدود آن را دریافت کنند. شمار مسیرهای دسترسی مستقیم و غیرمستقیم، اختیارات مدیریتیِ قادر به دورزدن کنترل و دفعات استفاده از استثنا، در کنار شاخص‌های خودکارسازی معنا پیدا می‌کنند.

امکان استفاده از داده را حفظ کنیم

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

نمونهٔ عملی نزدیک به این جهت‌گیری، OpenSAFELY است: کد پژوهش به محل نگهداری داده می‌رود، دادهٔ آزمایشی برای توسعه فراهم می‌شود و پژوهشگر نتایج تجمیعی دریافت می‌کند. دامنهٔ این مثال مشخص است؛ خود پروژه امکان دسترسی مالکان مراکز داده را مستثنا می‌کند. بنابراین شاهدی برای امکان توسعه بدون دسترسی آزاد پژوهشگر به داده است، نه تحقق همهٔ فرض‌های معماری مورد بحث این یادداشت.

در ZTAI، حذف دسترسی انسان زمانی معنای عملی پیدا می‌کند که مشاهدهٔ مستقیم، اختیار تغییر پردازش، خروج اطلاعات و مدیریت زیرساخت در کنار هم بررسی شوند. انسان همچنان دربارهٔ هدف، حدود اختیار و پذیرش ریسک مسئول است؛ اجرای روزمره باید بتواند در همان حدود، بدون مراجعهٔ مکرر به دادهٔ خام ادامه یابد.

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