Разделение по шагам, а не по приложению
Агент на устройстве — это не одна программа с единой политикой приватности. Это последовательность шагов: retrieval по локальному контексту, первичная классификация, редактирование, планирование, синтез, вызов инструментов, сборка ответа. Каждый шаг имеет свой профиль данных и свой профиль вычислений. Рассматривать границу между устройством и сервером как свойство уровня приложения — это приложение локальное, то облачное — первая ошибка моделирования, потому что один и тот же агент будет по-разному перемещать данные через границу в зависимости от поставленной задачи.
Retrieval по локальному контексту — очевидный кандидат на выполнение на устройстве. Индекс уже находится в памяти, запрос мал, а результат — это набор указателей на локальное хранилище. Первичная классификация также локальна: определить, содержит ли сообщение персональный идентификатор, есть ли на изображении лицо, является ли фрагмент документа чувствительным, можно с помощью компактной модели, единственный выход которой — метка и уверенность. Редактирование — это локальное преобразование: имея span и политику, заменить или замаскировать его до того, как что-либо покинет устройство.
Многошаговое планирование и синтез с длинным контекстом обычно не могут выполняться локально с приемлемым качеством. Планирование требует удержания графа задач в рабочей памяти, сравнения кандидатов на декомпозицию и их пересмотра по промежуточным результатам. Синтез с длинным контекстом требует внимания над большим числом токенов, чем ускоритель устройства может удержать при интерактивной задержке. Поэтому граница смещается вместе с задачей, и правильный вопрос проектирования — не «это приложение локальное?», а «какие шаги в этой задаче локальны и что именно пересекает границу?»
Что определяет границу
Три фактора задают линию, и они тянут в разные стороны.
Класс данных. Персональные идентификаторы, изображения и содержимое сообщений несут разные обязательства. Идентификатор устройства в диагностическом логе — не то же самое, что текст личного сообщения, даже если оба являются строками. Классификация должна быть по полю и по span, а не по полезной нагрузке: один запрос может содержать отредактированное тело сообщения, неотредактированную метку времени и грубую геолокацию, каждое с своим правилом обработки. Обязательство привязано к классу данных, а не к транспорту.
Бюджет задержки. Локальный арбитраж добавляет миллисекунды. Круговой рейс к удалённому планировщику добавляет сотни. Эта асимметрия — причина, по которой граница является решением о задержке в той же мере, что и о приватности. Если шаг может быть решён локально в рамках бюджета взаимодействия, отправка наверх мало что даёт и стоит раскрытия. Если шаг не может быть решён локально без превышения бюджета, компромисс меняется. Инженерная задача — измерить обе стороны для каждого шага, а не предполагать одну.
Разрыв в возможностях модели. Стоимость ошибочного локального решения не симметрична стоимости раскрытия. Локальный классификатор, ошибочно помечающий безобидный span как чувствительный, вызывает ненужное редактирование; локальный классификатор, ошибочно помечающий чувствительный span как безобидный, вызывает раскрытие. Разрыв между возможностями локальной и удалённой модели определяет, как часто происходит каждая ошибка, а политика определяет, какая ошибка хуже. Там, где разрыв мал, а стоимость раскрытия высока, побеждает локальное выполнение. Там, где разрыв велик, а шаг низкочувствителен, побеждает выполнение наверху.
Конкретный механизм: представить каждый шаг как запись с объявленным классом данных, объявленным бюджетом задержки и объявленным fallback. На этапе проектирования запись разрешается в размещение — устройство, сервер или устройство с эскалацией на сервер. Во время выполнения агент обращается к размещению, а не выводит его заново. Это делает решение проверяемым и освобождает путь выполнения от логики политики, которую нельзя протестировать.
Как сделать границу проверяемой
Граница, которая не записана, не может быть проверена. Каждая исходящая полезная нагрузка должна логироваться вместе с шагом, который её создал, и версией применённой политики. Запись в логе — это не сама полезная нагрузка; это метаданные, позволяющие аудитору восстановить, почему эти данные покинули устройство на этом шаге по этому правилу.
Правила редактирования должны быть версионированными артефактами. Когда правило меняется, меняется версия, и любая регрессия в том, что редактируется, становится обнаружимой путём сравнения исходящих логов между версиями. Без версионирования изменение правила невидимо, пока не приведёт к инциденту. С версионированием оно даёт diff.
Тестирование границы требует состязательных входных данных, а не только репрезентативных. Репрезентативные входные данные подтверждают, что happy path остаётся локальным. Состязательные входные данные исследуют края: сообщение, содержащее персональный идентификатор, разделённый между двумя span, изображение, метаданные которого несут геолокацию, документ, чувствительный раздел которого чувствителен только в сочетании с более ранним результатом retrieval. Это случаи, где граница по приложению терпит неудачу, а граница по шагам выдерживает.
Полезный тестовый стенд рассматривает границу как контракт: для заданных входных данных и задачи утверждать, какие шаги выполняются локально и какие поля появляются в исходящей полезной нагрузке. Утверждение касается формы полезной нагрузки, а не вывода модели, поэтому оно остаётся стабильным при и
Где это терпит неудачу
Политика на стороне устройства, которая молча деградирует до отправки всего, когда локальная модель недоступна, — не политика. Это fallback, который инвертирует замысел проектирования именно в тех условиях — ограниченное устройство, отсутствующая модель, деградировавший ускоритель, — где данные наиболее вероятно чувствительны. Сбой незаметен, потому что агент всё ещё выдаёт ответ; сместилась только граница.
Честный компромисс в том, что строгая граница может сделать агента непригодным на некоторых устройствах. Если локальная модель отсутствует, а политика запрещает выполнение чувствительного шага наверху, шаг должен завершиться неудачей, а не деградировать. Видимый сбой хуже для продукта и лучше для пользователя. Решение проектирования — какие шаги могут завершаться с отказом, и это решение принимается на этапе проектирования, для каждого шага, вместе с классом данных и бюджетом задержки.
Та же логика применима к эскалации. Размещение «устройство с эскалацией на сервер» законно только если эскалация сама является объявленным шагом с собственным классом данных и собственным редактированием. Эскалация, обходящая редактирование, — не эскалация; это раскрытие с дополнительными шагами.
На этапе проектирования, а не во время выполнения
Фильтры приватности во время выполнения привлекательны, потому что они централизованы и легко обновляются. Они также являются неправильным местом для этого решения, потому что к моменту, когда фильтр во время выполнения видит полезную нагрузку, шаг, который её создал, уже зафиксировал форму данных. Фильтр может замаскировать поля, но он не может восстановить бюджет задержки, потраченный на их сборку, и не может знать, какие из этих полей шагу действительно были нужны.
Арбитраж на этапе проектирования инвертирует порядок. Шаг объявляет, что ему нужно, политика разрешает, где он выполняется, и полезная нагрузка собирается в соответствии с этим разрешением. Путь выполнения тогда — это поиск, а не суждение. Это больше работы на старте и меньше в продакшене, и это единственная версия границы, которую можно проверить постфактум.
Практическое следствие в том, что граница становится артефактом спецификации. Её можно проверять, версионировать и тестировать, как любой другой интерфейс. Это стандарт, которому должен соответствовать агент, работающий с персональными данными, и он достижим без изобретения метрик: механизм — это запись, версия и состязательный тест, и каждый из них проверяем на своих собственных условиях.