152-ФЗ и on-device ML: что важно ИБ-службе ритейла

Что реально обрабатывает продукт

Целевой сценарий Zorky — чтение кодов и этикеток для операционного поиска в МПС. Пайплайн на устройстве: кадр → детекция/OCR → сопоставление со сценарием → подсветка в UI.

Юридическая квалификация отдельных полей (в том числе споры вокруг биометрии) зависит от конфигурации заказчика и применимого права. Итоговую оценку дают юрист и ИБ заказчика. Детали уточняются на ИБ-брифинге.

Что остаётся на устройстве

По архитектуре продукта кадры обрабатываются локально и не выгружаются в облако Zorky как изображения. Инференс не требует сети — это же свойство делает жизнеспособным сценарий склада без покрытия.

Идентификатор сотрудника, если включается, — решение и политика заказчика. ФИО и телефон сотрудника вне скоупа продукта.

Что уходит в бэкенд

В бэкенд предусмотрены агрегированные события и метрики сценария (например, время поиска, количество попыток) — для админки и аналитики. Распознанные коды — в агрегированном виде в рамках метрик, а не как поток кадров.

Таблица потоков и осторожные формулировки модели угроз собраны на посадочной приватности и в whitepaper. Расширять её выдуманными KMS/HSM/сертификатами ФСТЭК мы не будем.

152-ФЗ: зона продукта и зона заказчика

Мы не публикуем гарантийные формулы соответствия 152‑ФЗ на лендинге и в статьях: такие обещания не заменяют due diligence.

• Продукт — минимизация данных, покидающих устройство; прозрачный data flow; готовность ответить на опросный лист.
• Заказчик — определение целей обработки, правовые основания, внутренние политики, решение включать ли ID сотрудника.
• Сделка — NDA/DPA по шаблону заказчика или согласованное приложение; состав обязательств уточняется в юридическом контуре.

Не является юридическим заключением. Актуальная практика применения 152-ФЗ — к юристу заказчика.

Что запросить у вендора до пилота

Формат ИБ-брифинга (45–60 минут) описан на странице для ИБ. Письменные ответы фиксируем после сессии.

1. Архитектурную схему on-device обработки.
2. Описание data flow.
3. Ответы на опросный лист ИБ.
4. NDA/DPA по вашему шаблону.
5. Контакт технического ответственного.

Модель угроз без маркетинговых усилителей

Типовые угрозы и как архитектура их снижает. Утечка кадров из облака — кадры по дизайну не выгружаются как изображения. Перехват трафика распознавания — шаг инференса не требует сети. Подмена модели — процесс целостности поставки уточняется на брифинге. Утечка через логи — политика логов уточняется на брифинге.

Мы намеренно избегаем заявлений об абсолютной защищённости или абсолютной безопасности. Меры снижают риск, но не отменяют ответственность заказчика за конфигурацию и эксплуатацию. Любая фраза о «гарантии соответствия» на сайте была бы вредной для зрелой ИБ-оценки.

Если ИБ требует шифрование at-rest на устройстве, конкретный KMS или сертификаты регулятора — это предмет опросного листа, а не абзаца в блоге. Неподтверждённые детали мы не выдумываем и не украшаем текст стандартами «для солидности».

Роль конфигурации заказчика

Включение идентификатора сотрудника, расширение синка, собственные логи МПС — всё это может изменить картину данных. Архитектура Zorky задаёт базовый минимум; финальный контур рисуется вместе с вашей сборкой.

Как читать whitepaper и эту статью

Статья — обзор для быстрой ориентации ИБ. Whitepaper — тот же каркас в формате документа для due diligence, со ссылкой на скачивание PDF. Оба материала содержат дисклеймер: не юридическое заключение.

Следующий шаг после чтения — ИБ-брифинг и ваш опросный лист. Без них «соответствие» остаётся словом на сайте. Операционный смысл on-device дополнительно раскрыт на посадочной склада без сети: меньше зависимости от канала связи — меньше соблазна слать кадры «чтобы заработало».

Для команды МПС полезно читать этот материал вместе с описанием SDK: технические и комплаенс-границы должны совпадать в одном пилоте. Иначе разработка обещает облачный фолбэк «на всякий случай», а ИБ согласовывала локальный контур.

Итоговая рекомендация простая: используйте публичные страницы как карту вопросов, а ответы фиксируйте письменно после брифинга. Так due diligence остаётся управляемым, а маркетинг не подменяет юридическую оценку.

Практика вопросов на ИБ-брифинге

ИБ обычно спрашивает: где выполняется инференс; покидают ли кадры устройство; какие события уходят в бэкенд; кто оператор данных; как обновляется модель; что в логах; как выглядит DPA. Готовьте ответы фактами архитектуры, а не слоганами.

Полезно заранее принести свой опросный лист — даже черновик. Тогда сессия 45–60 минут заканчивается списком письменных follow-up, а не общими словами. Контакт технического ответственного фиксируйте в протоколе.

Если часть ответов ещё не подтверждена командой продукта, так и пишите: уточняется. Лучше честный пробел, чем красивая догадка, которая разъедется с договором через месяц.

Whitepaper можно приложить к внутреннему тикету due diligence как стартовый пакет. Финальные формулировки сделки всё равно будут в NDA/DPA и приложениях заказчика.

Минимальный пакет для внутреннего тикета ИБ

Положите в тикет: ссылку на посадочную приватности, whitepaper, краткое описание сценариев пилота, вопрос о необходимости NDA до обмена опросным листом, желаемую дату брифинга. Так ИБ получает управляемый вход, а не переписку из десяти писем.

Если юридический блок заказчика требует отдельной оценки оператора и обработчика — зафиксируйте это как открытый вопрос сделки. Продуктовая архитектура on-device упрощает обсуждение, но не заменяет роли сторон в договоре.

Краткий итог для CISO и DPO

Архитектура Zorky минимизирует необходимость выгружать кадры. Оценка по 152‑ФЗ остаётся за заказчиком. Перед пилотом запросите data flow, ответы на опросный лист и контур NDA/DPA.

Используйте посадочную приватности и whitepaper как входные документы, а брифинг — как место, где пробелы закрываются письменно, без гарантийных формул на сайте.

Что не обещает этот материал

Он не заменяет политику обработки данных заказчика, не является офертой и не перечисляет сертификаты, которых нет в подтверждённом комплекте поставки. Его задача — ускорить одинаковое понимание архитектуры у ИБ, юристов и команды МПС до пилота.