تفکیک به‌ازای هر گام است، نه به‌ازای هر اپ
یک agent روی گوشی یک برنامه واحد با یک وضعیت حریم خصوصی واحد نیست. دنباله‌ای از گام‌هاست: retrieval روی زمینه محلی، طبقه‌بندی اولیه، حذف اطلاعات حساس، برنامه‌ریزی، synthesis، فراخوانی ابزار، مونتاژ پاسخ. هر گام پروفایل داده متفاوتی و پروفایل محاسباتی متفاوتی دارد. در نظر گرفتن مرز میان دستگاه و بالادست به‌عنوان یک ویژگی در سطح اپ — این اپ محلی است، آن اپ ابری است — نخستین خطای مدل‌سازی است، زیرا همان agent بسته به وظیفه‌ای که به آن سپرده شده، داده را به شکل متفاوتی از مرز عبور می‌دهد.
retrieval روی زمینه محلی نامزد روشنی برای اجرا روی دستگاه است. ایندکس از قبل مقیم است، query کوچک است، و مجموعه نتایج مجموعه‌ای از اشاره‌گرها به حافظه محلی است. طبقه‌بندی اولیه نیز به همین ترتیب محلی است: تشخیص اینکه آیا یک پیام حاوی شناسه شخصی است، آیا یک تصویر حاوی چهره است، آیا یک بخش از سند حساس است، می‌تواند با یک مدل فشرده انجام شود که تنها خروجی‌اش یک برچسب و یک درجه اطمینان است. حذف اطلاعات حساس یک تبدیل محلی است: با داشتن یک span و یک policy، آن را جایگزین یا پوشانده می‌کنیم پیش از آنکه چیزی از دستگاه خارج شود.
برنامه‌ریزی چندگامی و synthesis با زمینه بلند معمولاً نمی‌توانند با کیفیت قابل قبول به‌صورت محلی اجرا شوند. برنامه‌ریزی مستلزم نگه‌داشتن یک گراف وظیفه در حافظه کاری، مقایسه تجزیه‌های نامزد، و بازنگری آن‌ها بر اساس نتایج میانی است. synthesis با زمینه بلند مستلزم توجه روی توکن‌هایی بیش از آن است که شتاب‌دهنده یک گوشی بتواند در تأخیر تعاملی نگه دارد. پس مرز با وظیفه جابه‌جا می‌شود، و پرسش درست طراحی این نیست که «آیا این اپ محلی است؟» بلکه این است که «کدام گام‌ها در این وظیفه محلی‌اند، و دقیقاً چه چیزی از مرز عبور می‌کند؟»
چه چیزی مرز را تعیین می‌کند
سه عامل خط را تعیین می‌کنند، و در جهت‌های متفاوتی می‌کشند.
طبقه داده. شناسه‌های شخصی، تصاویر و محتوای پیام تعهدات متفاوتی دارند. یک شناسه دستگاه در یک لاگ تشخیصی با متن یک پیام خصوصی یکسان نیست، حتی اگر هر دو رشته باشند. طبقه‌بندی باید به‌ازای هر فیلد و هر span باشد، نه به‌ازای هر payload: یک درخواست واحد ممکن است شامل بدنه پیام حذف‌شده، یک timestamp حذف‌نشده، و یک موقعیت مکانی تقریبی باشد، که هرکدام قاعده رسیدگی متفاوتی دارند. تعهد به طبقه داده می‌چسبد، نه به انتقال.
بودجه تأخیر. داوری محلی میلی‌ثانیه اضافه می‌کند. یک رفت‌وبرگشت به یک planner راه‌دور صدها میلی‌ثانیه اضافه می‌کند. همین عدم تقارن دلیل آن است که مرز به‌اندازه یک تصمیم حریم خصوصی، یک تصمیم تأخیر است. اگر یک گام بتواند در بودجه تعامل به‌صورت محلی تصمیم‌گیری شود، فرستادن آن به بالادست چیز کمی می‌خرد و هزینه‌اش یک افشا است. اگر یک گام نتواند بدون از دست دادن بودجه به‌صورت محلی تصمیم‌گیری شود، توازن برعکس می‌شود. وظیفه مهندسی اندازه‌گیری هر دو سو به‌ازای هر گام است، نه فرض کردن یکی.
شکاف توانمندی مدل. هزینه یک تصمیم محلی نادرست با هزینه افشا متقارن نیست. یک classifier محلی که یک span بی‌خطر را حساس برچسب می‌زند، باعث یک حذف بی‌مورد می‌شود؛ یک classifier محلی که یک span حساس را بی‌خطر برچسب می‌زند، باعث یک افشا می‌شود. شکاف میان توانمندی مدل محلی و راه‌دور تعیین می‌کند هر خطا چند وقت یک‌بار رخ می‌دهد، و policy تعیین می‌کند کدام خطا بدتر است. جایی که شکاف کوچک و هزینه افشا بالا است، اجرای محلی برنده است. جایی که شکاف بزرگ و گام کم‌حساسیت است، اجرای بالادست برنده است.
یک سازوکار مشخص: هر گام را به‌صورت یک رکورد با یک طبقه داده اعلام‌شده، یک بودجه تأخیر اعلام‌شده، و یک fallback اعلام‌شده بازنمایی کنید. در زمان طراحی، رکورد به یک جای‌گذاری حل می‌شود — دستگاه، بالادست، یا دستگاه با escalation به بالادست. در زمان اجرا، agent به جای بازاستخراج آن، جای‌گذاری را مشورت می‌کند. این کار تصمیم را قابل حسابرسی نگه می‌دارد و مسیر زمان اجرا را از منطق policy که قابل آزمون نیست پاک نگه می‌دارد.
قابل حسابرسی کردن مرز
مرزی که ثبت نشود قابل بازبینی نیست. هر payload خروجی باید همراه با گامی که آن را تولید کرده و نسخه policy اعمال‌شده لاگ شود. ورودی لاگ خود payload نیست؛ فراداده‌ای است که به یک حسابرس اجازه می‌دهد بازسازی کند چرا این داده در این گام تحت این قاعده از دستگاه خارج شده است.
قواعد حذف اطلاعات حساس باید آرتیفکت‌های نسخه‌بندی‌شده باشند. وقتی یک قاعده تغییر می‌کند، نسخه تغییر می‌کند، و هر پس‌رفت در آنچه حذف می‌شود با مقایسه لاگ‌های خروجی میان نسخه‌ها قابل تشخیص می‌شود. بدون نسخه‌بندی، تغییر یک قاعده تا زمانی که حادثه‌ای تولید کند نامرئی است. با نسخه‌بندی، یک diff تولید می‌کند.
آزمون مرز مستلزم ورودی‌های خصمانه است، نه فقط ورودی‌های نماینده. ورودی‌های نماینده تأیید می‌کنند که مسیر مطلوب محلی می‌ماند. ورودی‌های خصمانه لبه‌ها را می‌کاوند: پیامی که حاوی یک شناسه شخصی تقسیم‌شده میان دو span است، تصویری که فراداده‌اش یک موقعیت مکانی حمل می‌کند، سندی که بخش حساسش فقط در ترکیب با یک نتیجه retrieval پیشین حساس است. این‌ها مواردی هستند که مرز به‌ازای هر اپ شکست می‌خورد و مرز به‌ازای هر گام دوام می‌آورد.
یک test harness مفید مرز را به‌عنوان یک قرارداد در نظر می‌گیرد: با داشتن یک ورودی و یک وظیفه، تأیید کنید کدام گام‌ها محلی اجرا می‌شوند و کدام فیلدها در payload خروجی ظاهر می‌شوند. تأیید روی شکل payload است، نه روی خروجی مدل، پس
کجا شکست می‌خورد
یک policy سمت دستگاه که بی‌سروصدا به فرستادن همه‌چیز تنزل می‌کند وقتی مدل محلی در دسترس نیست، یک policy نیست. یک fallback است که قصد طراحی را دقیقاً تحت همان شرایطی معکوس می‌کند — دستگاه محدود، مدل غایب، شتاب‌دهنده تنزل‌یافته — که داده به احتمال زیاد حساس است. شکست بی‌سروصدا است زیرا agent هنوز پاسخی تولید می‌کند؛ فقط مرز جابه‌جا شده است.
توازن صادقانه این است که یک مرز سخت می‌تواند agent را روی برخی دستگاه‌ها غیرقابل استفاده کند. اگر مدل محلی غایب باشد و policy اجرای بالادست یک گام حساس را ممنوع کند، گام باید شکست بخورد، نه تنزل کند. شکست آشکار برای محصول بدتر و برای کاربر بهتر است. تصمیم طراحی این است که کدام گام‌ها مجاز به شکست بسته هستند، و آن تصمیم به زمان طراحی تعلق دارد، به‌ازای هر گام، در کنار طبقه داده و بودجه تأخیر.
همین منطق برای escalation اعمال می‌شود. یک جای‌گذاری دستگاه با escalation به بالادست تنها زمانی مشروع است که خود escalation یک گام اعلام‌شده با طبقه داده خودش و حذف اطلاعات حساس خودش باشد. escalationی که حذف اطلاعات حساس را دور می‌زند escalation نیست؛ افشا با گام‌های اضافی است.
زمان طراحی، نه زمان اجرا
فیلترهای حریم خصوصی زمان اجرا جذاب‌اند زیرا متمرکز و به‌روزرسانی‌شان آسان است. همچنین جای اشتباهی برای این تصمیم هستند، زیرا تا زمانی که یک فیلتر زمان اجرا یک payload را می‌بیند، گامی که آن را تولید کرده از قبل به یک شکل داده متعهد شده است. فیلتر می‌تواند فیلدها را پوشانده کند، اما نمی‌تواند بودجه تأخیری را که صرف مونتاژ آن‌ها شده بازیابد، و نمی‌تواند بداند کدام یک از آن فیلدها را گام واقعاً نیاز داشته است.
داوری در زمان طراحی ترتیب را معکوس می‌کند. گام اعلام می‌کند چه چیزی نیاز دارد، policy حل می‌کند کجا اجرا می‌شود، و payload بر اساس آن حل مونتاژ می‌شود. مسیر زمان اجرا سپس یک lookup است، نه یک قضاوت موردی. این کار در ابتدا بیشتر و در تولید کمتر است، و تنها نسخه‌ای از مرز است که می‌تواند پس از واقعه حسابرسی شود.
پیامد عملی این است که مرز به یک آرتیفکت مشخصات تبدیل می‌شود. می‌توان آن را مانند هر رابط دیگری بازبینی، نسخه‌بندی و آزمون کرد. این استانداردی است که یک agent که با داده‌های شخصی سروکار دارد باید به آن پایبند باشد، و بدون اختراع متریک‌ها قابل دستیابی است: سازوکار همان رکورد، نسخه، و آزمون خصمانه است، و هر یک از این‌ها به‌تنهایی قابل بازرسی است.