Хотел — чтобы финансовые документы разбирала локальная модель и ничего из них не уходило наружу. Это было записано правилом, и я считал, что правило работает: профили настроены на локальные роли, значит запросы никуда не летят.
Споткнулся — открыл журнал шлюза ровно за трое суток и увидел 12 строк о переходе на запасной путь и 6 попыток вызвать облачную модель, все шесть в одну минуту. Роль, которую я считал локальной, имела безусловный fallback: если локальная модель отказывает — а она отказывала на слишком длинных запросах, — запрос молча идёт в облако.
Вывод напрашивался сам: данные уезжают. Журнал сказал другое. Ни одна из шести попыток не дошла до провайдера: каждая упала на проверке параметров внутри самой библиотеки — облачная модель не принимает temperature 0.2, — и эта проверка срабатывает до отправки запроса. Исходящих запросов к облаку ноль, расхода по облаку нет. Данные остались на машине.
Только удержало их не правило приватности, а несовместимость одного параметра. Уберёт кто-нибудь temperature из запроса — и тот же путь уедет в облако без единой правки конфигурации. Приватность держалась случайно, а не по устройству.
Решил — две скучные вещи.
- Роль без fallback. Нет запасного пути — нет тихого ухода в облако.
- Проверка на старте приложения: конфигурация, которая может увести запрос в облако — через нелокальную роль или через ключ с доступом к облачным моделям, — проверку не проходит, и приложение не поднимается.
Чем плачу — приложение теперь не стартует без живого шлюза: проверка ходит по сети, и офлайн-старт стал невозможен. Переключиться на облачную модель, когда локальная действительно упадёт, больше нельзя — придётся идти руками в конфигурацию, осознанно. И вывод стало труднее продать: «шесть попыток, ни одна не дошла» звучит как «ничего не случилось», и соблазн закрыть пункт как неактуальный теперь прямо в тексте.
Замера «стало безопаснее» нет и быть не может. Есть число, которое было: шесть попыток уйти в облако за трое суток, и от утечки их отделял один параметр.