Чек-лист комплаенса видеонаблюдения: GDPR, BIPA

Автор: Николай СапуновОбновлено: август 202622 мин чтения
Содержание статьи +

Это инженерное руководство, а не юридическая консультация. Уточняйте конкретику у квалифицированного юриста.

Кратко

Комплаентная система наблюдения – это не одна проверка в конце, а короткий упорядоченный набор решений, которые вы принимаете до того, как заработает первая камера: цель, правовое основание, оценка рисков, уведомление, биометрический шлюз, хранение, контроль доступа и процесс прав субъектов. Самые дорогие ошибки – выбирать правовое основание после развёртывания, пропустить оценку воздействия на защиту данных (DPIA), которую закон делает обязательной для масштабного мониторинга общественных мест, и включить распознавание лиц без отдельного, куда более тяжёлого согласования, которого оно требует. Эта статья превращает весь блок приватности и комплаенса в один чек-лист перед запуском, который может пройти и не-юрист, с указанием закона у каждого шага. Это инженерное руководство, которое вы несёте своему юристу и команде разработки, а не замена ни тому, ни другому.

Почему это важно

Если вы задаёте, покупаете, строите или эксплуатируете систему управления видео – софт, который записывает и управляет множеством камер, называемый VMS, – комплаенс это часть, которая решает, законно ли вообще включать систему, а не только работает ли она. Ошибётесь – и расходы реальны: регулятор может предписать остановить систему, в некоторых местах люди в кадре вправе судиться с оператором напрямую, а функция распознавания лиц, выпущенная без проверки, превращает апгрейд безопасности в коллективный иск. Эта статья – для системных интеграторов, продакт-менеджеров и руководителей безопасности в ритейле, умных зданиях и городах, которым нужно развернуть камеры и отвечать за них. Она собирает весь privacy by design для видеонаблюдения в один упорядоченный список, чтобы ничего несущего не осталось на конец. Считайте её итоговым разбором, связывающим весь блок приватности.

Чек-лист, а не юридическое заключение

Большинство страниц про «комплаенс CCTV» в сети – это либо смутное напоминание «повесьте знак и соблюдайте GDPR», либо стена текста закона без порядка действий. Ни то, ни другое не помогает команде, которой надо реально разворачивать. Полезный артефакт – это упорядоченный чек-лист: шаги в той последовательности, в которой их надо делать, потому что несколько из них шлюзуют следующие.

Порядок важен, потому что у комплаенса есть зависимости. Нельзя написать знак, пока не знаешь цель. Нельзя понять, обязательна ли оценка воздействия, пока не знаешь, делает ли система биометрию. Нельзя задать срок хранения, пока не знаешь правовое основание, которому он служит. Сделаете шаги не по порядку – будете переделывать.

Рамка всего чек-листа – одна идея из GDPR для видеонаблюдения: видео идентифицируемого человека – это персональные данные, а запуск биометрии на этом видео – распознавание лиц прежде всего – это вторая, гораздо более чувствительная обработка поверх. Почти каждый пункт ниже тяжелеет в тот момент, когда в кадр входит биометрия. Поэтому самый полезный вопрос, на который надо ответить первым: эта система идентифицирует людей по их телам или просто записывает то, что видят камеры?

Ниже – ворота комплаенса: девять контролей между «нам нужны камеры» и «система работает». Остальная статья проходит каждый из них по порядку, с указанием закона рядом.

Рисунок 1. Ворота комплаенса: девять контролей между «нам нужны камеры» и «система работает». Каждый питает следующий, а биометрический шлюз (шаг 5) делает несколько других гораздо тяжелее.

1. Цель и правовое основание

Всё начинается с одной фразы на камеру или зону: зачем эта камера существует? «Выявлять и расследовать кражи у разгрузочного дока». «Следить за вестибюлем на предмет проникновения в нерабочее время». Цель – это не бумажка; это то, что решает, необходим ли каждый последующий шаг или избыточен. Камеру без заявленной цели нельзя обосновать, а цель вроде «общая безопасность» слишком расплывчата, чтобы её защитить.

Зафиксировав цель, вы выбираете правовое основание – юридическую причину, по которой вам вообще позволено обрабатывать изображения людей. По GDPR, Регламент (EU) 2016/679, статья 6 перечисляет шесть возможных оснований, и для наблюдения важны два. Большинство частных операторов опираются на легитимный интерес (ст. 6(1)(f)): у вас есть подлинный интерес, например предотвращение преступлений, и обработка необходима для него и не перевешивается правами на приватность снятых людей. Государственные органы при исполнении обычно не могут использовать легитимный интерес для этой роли и опираются на публичную задачу (ст. 6(1)(e)) или конкретный закон.

Если вы опираетесь на легитимный интерес, закон ожидает документированную оценку легитимного интереса (LIA) – короткий письменный тест из трёх частей. Первая: каков интерес (безопасность персонала и товара). Вторая: необходима ли камера для него, или подошла бы менее интрузивная мера (лучшее освещение, запертая дверь). Третья: перевешивает ли ваш интерес вторжение в снятых людей, учитывая, куда смотрит камера и кого захватывает. Камера над кассой может пройти; камера в сад соседа – почти никогда. Тест на баланс – там, где проваливается большинство избыточных развёртываний, и его запись делает основание защитимым.

Глубокий разбор каждого основания – в GDPR для видеонаблюдения; здесь пункт чек-листа прост. Назовите цель по камере, выберите основание, и если это легитимный интерес – напишите LIA до того, как что-либо смонтируете. Выбранное основание также ограничивает следующие шаги: оно формирует уведомление, которое вы обязаны дать, и хранение, которое можете обосновать.

2. Оценка воздействия на защиту данных (DPIA)

Следующий контроль – тот, который команды чаще всего пропускают, и он часто не опционален. Оценка воздействия на защиту данных (DPIA) – это структурированное исследование рисков приватности обработки, сделанное до её начала. Статья 35 GDPR делает DPIA обязательной там, где обработка «вероятно повлечёт высокий риск» для людей, и явно называет случай наблюдения: DPIA требуется при «систематическом мониторинге общедоступной зоны в больших масштабах». Камеры общественных мест больших масштабов – учебниковый триггер, как и масштабная обработка спец-категории данных, например лиц (ст. 9). Регуляторы добавляют ещё триггеры: нательные камеры со звуком, автоматическое распознавание лиц, автоматическое распознавание номеров (ANPR), дроны и камеры очень высокого разрешения или мультисенсорные – всё это UK ICO называет примерами, требующими DPIA.

DPIA – это не форма для штампа. Статья 35(7) задаёт, что она должна содержать, и четыре части чисто ложатся на инженерный обзор: систематическое описание того, что система обрабатывает и зачем; оценка необходимости и пропорциональности этой обработки относительно цели; оценка рисков для снятых людей; и меры, которые вы примете для снижения этих рисков – маскирование, лимиты хранения, контроль доступа, шифрование. Результат – документ, с владельцем и датой, который можно вручить регулятору.

В процесс встроен жёсткий стоп. Если DPIA находит высокий риск, который вы не можете снизить до приемлемого уровня, статья 36 требует консультации с органом по защите данных до развёртывания – предварительная консультация, не уведомление постфактум. На практике вы почти никогда не доходите до этой точки, потому что сам акт DPIA вскрывает исправления (сократить хранение, замаскировать окна, убрать звук), которые снижают риск. DPIA – это не столько барьер, сколько рабочий лист, где решается остальная часть этого чек-листа.

Рисунок 2. Когда DPIA обязательна? Масштабный мониторинг общественных мест, биометрия, ANPR, звук или другие высокорисковые функции запускают её. Остаточный высокий риск, который нельзя снизить, запускает предварительную консультацию по статье 36.

3. Минимизация данных и privacy by design

С исследованием рисков на руках следующий контроль – урезать систему до того, что ей реально нужно – принцип, который GDPR зовёт минимизацией данных (ст. 5(1)(c)) и защитой данных по дизайну и по умолчанию (ст. 25). Инстинкт на проекте безопасности – захватить всё в максимальном разрешении, всё время, со звуком, на всякий случай. Закон считает этот инстинкт проблемой, а не безопасной нормой.

Минимизация в системе наблюдения – это серия конкретных решений. Направляйте камеры на обоснованную зону и не дальше; там, где поле зрения залезает в пространство, на которое у вас нет права смотреть – соседская собственность, частный кабинет, коридор уборной – закройте его приватной зоной, которую камера никогда не записывает. Записывайте лишь то, что нужно цели: режим по движению или по событию вместо непрерывного, где он подходит, – рычаг стратегии записи из блока хранения. Выключайте звук, если у вас нет конкретной, отдельно обоснованной причины для него, потому что запись звука более интрузивна и часто требует своего основания. И сопротивляйтесь биометрии: не запускайте распознавание лиц потому, что камера может, а только потому, что цель действительно требует идентифицировать людей, а не просто видеть их.

Техники, которые позволяют сохранить полезную аналитику и сбросить риск приватности – маскирование на лету, редактирование для экспорта, аналитика на деперсонализированных данных – разобраны в маскировании лиц, редактировании и privacy-preserving аналитике. Пункт чек-листа – заложить их сейчас, на этапе спецификации, когда это настройка, а не прикручивать после жалобы, когда это переделка.

4. Уведомление и прозрачность

У людей есть право знать, что их снимают, кто снимает и зачем – до того, как они войдут в кадр. Статьи 12 и 13 GDPR требуют давать эту информацию кратко и доступно, а Европейский совет по защите данных (EDPB) – орган, выпускающий официальное толкование GDPR, – в своих Guidelines 3/2019 по видеоустройствам точно прописывает, как это сделать для камер: многослойное уведомление.

Первый слой – это предупреждающий знак. Он стоит на границе зоны наблюдения, примерно на уровне глаз, размещён так, что человек видит его до входа. Он несёт суть: что ведётся запись, кто оператор (контролёр), цели, важнейшие последствия обработки и где найти остальное. Мысль EDPB в том, что знак должен позволить человеку «легко распознать обстоятельства наблюдения до входа в зону мониторинга» – знак, видимый лишь когда вы уже в кадре, – это слишком поздно.

Второй слой – это полная детализация, требуемая статьёй 13: правовое основание, срок хранения, кому видео может передаваться, какие у людей права (доступ, стирание, возражение) и как пожаловаться. Он не идёт на знак; он лежит там, где человек может до него добраться без входа в зону наблюдения: уведомление на ресепшн, лист на столе или веб-страница по короткому URL или коду на знаке. Механику получения согласия там, где основание – согласие, и грань между тем, где достаточно уведомления, и где требуется согласие, разбирает согласие и уведомление для видеонаблюдения. Для чек-листа: спроектируйте оба слоя, ставьте знаки до начала охвата камер и убедитесь, что названный на знаке оператор – это юрлицо, которое реально контролирует видео.

Рисунок 3. Многослойное уведомление, которого ожидает EDPB. Знак первого слоя на границе несёт суть до входа человека; второй слой держит полную детализацию по статье 13, доступную без захода в зону наблюдения.

5. Биометрический шлюз: самый тяжёлый контроль

Это шаг, который меняет вес всего проекта, и он заслуживает своего шлюза. В законе о приватности есть чёткая грань между записью людей и их узнаванием. Обычная камера, захватывающая лицо, обрабатывает персональные данные. Система, превращающая это лицо в математический шаблон и сопоставляющая его с базой, обрабатывает биометрические данные с целью уникально идентифицировать человека – и почти везде это считается особой, более рисковой категорией.

По статье 9 GDPR биометрические данные, используемые для идентификации человека, – это «спец-категория», обработка которой запрещена, если не применимо конкретное условие – чаще всего явное согласие человека или существенный общественный интерес, установленный законом. Легитимного интереса для этого недостаточно. Так что развёртывание распознавания лиц требует двух правовых слоёв: основания по статье 6 и условия по статье 9. Это существенно более высокая планка, чем обычные камеры в остальном здании.

В США этот шлюз обеспечивают люди, а не только регуляторы. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14, требует информированного письменного согласия до того, как вы захватите шаблон лица (раздел 15(b)), опубликованного графика хранения и уничтожения (раздел 15(a)) и – уникально – позволяет самим людям судиться, со штрафами $1,000 за небрежное и $5,000 за безрассудное или умышленное нарушение. Поправка 2024 года (SB 2979) ограничила это одним взысканием на человека, а не за каждое сканирование, но для любого крупного развёртывания экспозиция всё равно измеряется миллионами, и поэтому распознавание лиц – самая рисковая функция во всём этом разделе. Полная механика – Техас, Вашингтон, волна штатных законов о «чувствительных данных» и доктрина ущерба – в BIPA и биометрических законах США, а техническая пайплайн – в распознавании лиц в видеонаблюдении.

Третий слой теперь лежит сверху в Европе: EU AI Act. С 2 февраля 2025 его статья 5 запрещает некоторые биометрические применения прямо – распознавание в реальном времени в общественных местах для правоохраны (с узкими санкционированными исключениями), нецелевой сбор лиц для построения баз распознавания и распознавание эмоций на работе и в учёбе. Обязанности для высокорисковых биометрических систем, остающихся легальными – оценка соответствия, логирование, человеческий надзор – применяются с 2 декабря 2027 по согласованному графику Акта. Пункт чек-листа прямой: если система идентифицирует людей по лицам (или другой биометрии), остановитесь и проведите отдельный биометрический обзор раньше всего остального, потому что согласие, хранение и правовое основание – всё меняется, а в некоторых местах применение может быть запрещено независимо от согласия.

Рисунок 4. Биометрическая эскалация. Обычному видео нужны правовое основание, уведомление и лимит хранения. В момент, когда система узнаёт людей по телам, добавляются условие статьи 9, письменное согласие в духе BIPA и проверка по EU AI Act – куда более тяжёлый шлюз.

6. Хранение и законное удаление

Следующий контроль задаёт, как долго живёт видео, и доказывает, что оно исчезло, когда его время вышло. Пределов два, а не один: пол, заданный доказательствами и отраслевыми правилами, говорит, как долго вы обязаны хранить видео, и потолок, заданный принципом ограничения хранения закона о приватности (ст. 5(1)(e) GDPR), говорит, как долго вы вправе. EDPB читает этот потолок как несколько дней для обычных камер в большинстве случаев, и всё дольше требует задокументированной причины. Вы выбираете число внутри полосы, фиксируете его по группе камер и даёте рекордеру исполнять его автоматически.

Два инженерных факта делают это реальным пунктом чек-листа, а не строчкой политики. Первый: «удалить» – это не «исчезло»: рутинное удаление убирает указатель файла, но оставляет видео восстановимым, пока его не перезапишут, а копии в бэкапах, репликах и экспортированных клипах обычно его переживают. Законное удаление должно дойти до каждой копии. Второй: право на стирание GDPR (ст. 17) позволяет человеку попросить удалить его видео, и вы обязаны ответить за один месяц – что возможно, только если вы знаете, где лежит каждая копия его данных. Полная модель пола-и-потолка, механика удаления и процесс права на стирание – в лимитах хранения и законном удалении. Для чек-листа: задайте окно, автоматизируйте истечение на всех уровнях хранения, держите отдельную полосу legal hold для редкого клипа, который должен выжить, и умейте стереть производные данные одного человека по запросу.

7. Контроль доступа, безопасность и аудит

Видео настолько приватно, насколько приватны контроли вокруг него, и статья 32 GDPR требует «соответствующих технических и организационных мер» для защиты персональных данных. Для системы наблюдения это переводится в короткий конкретный список, и регулятор спросит про каждый пункт после любого инцидента.

Начните с того, кто что видит. Доступ должен быть по минимальным привилегиям: охранник видит живые виды своего объекта, следователь видит записи по делу, администратор управляет системой, и ни у кого нет больше, чем нужно его роли. Каждый аутентифицируется как он сам – общие логины «диспетчерской» – самая частая находка, потому что они делают невозможным следующий пункт. Этот следующий пункт – журнал аудита: защищённая от подмены запись о том, кто смотрел, экспортировал или удалял видео и когда. Без него вы не ответите на «кто это смотрел?» – а после жалобы на злоупотребление это первый вопрос.

Дальше идёт защита данных в канале и на диске: шифруйте связи камера-рекордер и рекордер-клиент, чтобы видео нельзя было перехватить в сети, и шифруйте хранимые записи, чтобы украденный диск не был утечкой. Отслеживайте экспорт – каждый клип, который оператор копирует на USB или шлёт письмом, – это копия, ускользающая от правил хранения и доступа системы, так что ей нужны журнал и причина. Наконец, любой, кому вы позволяете обрабатывать видео от вашего имени – облачный VSaaS-провайдер, вендор аналитики, подрядчик обслуживания – это процессор, и статья 28 GDPR требует письменного договора, обязывающего его использовать данные только по вашим инструкциям и защищать их. Пункт чек-листа: минимальные привилегии, личные логины, аудит-след, шифрование в обе стороны, отслеживание экспорта и подписанный договор с каждым процессором.

8. Права субъектов на практике

Комплаентная система не только корректно построена; она может отвечать людям в ней. GDPR даёт людям права, которые оператор наблюдения должен уметь исполнить по запросу, за один месяц (ст. 12(3)), и пункт чек-листа – иметь рабочий процесс для каждого, а не обнаруживать пробел, когда придёт первый запрос.

Два, которые бьют сильнее всего для камер – доступ и стирание. Запрос на доступ субъекта позволяет человеку запросить копию видео себя; чтобы исполнить, вы должны найти нужные клипы и, что критично, замаскировать других людей в кадре до выдачи, потому что приватность третьего лица не исчезает оттого, что попросил кто-то другой. Эта возможность редактирования – та же технология маскирования, что вы заложили на шаге 3, теперь используемая в обратную сторону. Право на стирание (ст. 17) позволяет человеку попросить удалить его видео, с учётом исключений legal hold выше. У людей также есть права возразить против обработки и, где основание – согласие, отозвать его. Пункт чек-листа операционен: назначьте, кто обрабатывает запросы, запускайте месячный отсчёт в момент прихода запроса и убедитесь, что ваш VMS реально умеет искать, маскировать, экспортировать и удалять по субъекту – потому что система, которая этого не умеет, не может эксплуатироваться законно, как бы хорошо её ни специфицировали.

9. Управление, записи и трансграничная реальность

Последний контроль – бумаги, доказывающие, что остальное произошло, плюс пункты, появляющиеся, когда система вырастает за один объект. Принцип подотчётности GDPR (ст. 5(2)) означает, что вы должны уметь продемонстрировать комплаенс, а не просто утверждать его. На практике это небольшой набор живых документов: Реестр операций обработки (RoPA) (ст. 30), перечисляющий, что делают камеры и зачем; DPIA и LIA из ранних шагов; договоры с процессорами; и план реагирования на утечки, потому что статья 33 даёт вам всего 72 часа на сообщение о квалифицирующей утечке персональных данных регулятору.

Ещё два пункта появляются на масштабе. Если видео покидает свой регион – чаще всего потому, что записывается в облако или анализируется в нём – глава V GDPR регулирует эту трансграничную передачу, и «облачный регион внутри страны» сам по себе это не решает, потому что доступ поддержки откуда-то ещё всё равно может быть передачей. И поскольку правила действительно различаются по юрисдикциям, система, продаваемая или эксплуатируемая в разных регионах, должна следовать строжайшему применимому правилу, а не самому удобному; карта того, где эти правила расходятся, – в карте регионального регулирования. Для чек-листа: держите записи актуальными, проведите учения на 72 часа до того, как они понадобятся, задокументируйте любой трансграничный поток и проектируйте под строжайший регион, где вы работаете.

Пример: ритейл-сеть разворачивает камеры

Пройдём ворота на конкретном кейсе. Ритейлер ставит систему из 40 камер в новом магазине: входы, кассы, склад и парковка. Команда проходит чек-лист по порядку.

Цель и основание. Каждая зона получает фразу – «сдерживать и расследовать кражи у касс», «следить за дверью склада», «покрыть парковку на предмет инцидентов с авто». Основание – легитимный интерес, и команда пишет одностраничный LIA, показывающий, что камеры необходимы и направлены только на пространство ритейлера. Камеры парковки наклонены вниз, чтобы не снимать общественный тротуар.

DPIA. Это крупная система в общедоступном месте, так что команда делает DPIA, а не гадает, обязательна ли она. Исследование отмечает один реальный риск: кто-то предложил распознавание лиц на входных камерах, чтобы засекать известных воров. Одно это предложение превратило бы проект в обработку спец-категории – так что оно идёт в биометрический шлюз, и для первого запуска команда его отбрасывает.

Минимизация, уведомление, хранение. Кассы пишут по движению плюс непрерывная база с низкой частотой кадров; склад пишет только по движению; звук выключен везде. Многослойные знаки встают у обеих дверей и въезда на парковку до начала охвата камер, называя ритейлера и ссылаясь на полное уведомление на сайте магазина. Хранение задано на 30 дней – комфортно внутри потолка приватности и выше реального окна, в котором всплывает кража или падение, – и рекордер перезаписывает автоматически.

Доступ, права, записи. Создаются три роли – охранник магазина (только живое), следователь по предотвращению потерь (записи, с журналированием экспорта) и администратор. Каждый логин личный; журнал аудита включён. Дежурный менеджер назначен контактом для запросов на доступ и стирание, с месячным отсчётом. Реестр операций обработки, LIA и DPIA лежат в папке, которой владеет управляющий района. Система запускается – без распознавания лиц, которое потребовало бы своего режима согласия, своего графика хранения и BIPA-обзора, к которому сеть была не готова. Эта отсрочка – чек-лист, работающий ровно как задумано: самую тяжёлую функцию вы шлюзуете жёстче всего.

Чек-лист на одной странице

Девять контролей сворачиваются в один список готовности, который можно пройти перед любым развёртыванием, сгруппированный так, как реально идёт работа. Скачиваемая версия ниже – печатная форма этого: основной лид-магнит комплаенса для раздела.

Рисунок 5. Чек-лист комплаенса одной картой – девять контролей как чекбоксы, сгруппированные от цели до управления, с биометрическим шлюзом, отмеченным как шаг, меняющий всё после него.

Проходите по порядку, потому что шаги зависят друг от друга: цель задаёт основание, основание и ответ про биометрию задают, обязательна ли DPIA, DPIA определяет хранение и контроли, а контроли делают возможным процесс прав. Система, которая отмечает каждый пункт – и может показать документы под галочками, – это та, что можно включить и защитить. Скачайте чек-лист приватности и комплаенса видеонаблюдения, чтобы пройти его по своему развёртыванию.

Типичные ошибки, проваливающие ворота

Повторяющиеся провалы предсказуемы, и каждый ложится на пропущенный кем-то контроль. Первый – выбирать правовое основание последним: развернуть камеры и обратной разработкой подобрать обоснование, вместо того чтобы дать цели вести дизайн. Второй – пропустить DPIA в крупной системе общественного места или с биометрией, где статья 35 делает её обязательной, оставив самое рисковое развёртывание без исследования рисков. Третий – знак, который приходит слишком поздно: уведомление, видимое лишь когда вы уже в кадре, проваливает правило «до входа». Четвёртый, и самый дорогой – включить распознавание лиц как обычную функцию, когда оно требует явного согласия, условия спец-категории, BIPA-обзора в США и проверки EU AI Act – и может быть запрещено в любом случае. Пятый – общие логины и нет аудит-следа, так что при заявлении о злоупотреблении система не может сказать, кто смотрел. Развёртывание, которое называет цель, проводит DPIA, ставит уведомление рано, жёстко шлюзует биометрию и журналирует каждый доступ, избегает всех пяти.

Где здесь Фора Софт

Фора Софт строит видеосистемы – наблюдение, стриминг, конференц-связь и компьютерное зрение – с 2005 года, в 250+ проектах, и на проекте наблюдения комплаенс – это вход архитектуры, а не поздний обзор. На практике мы проектируем чек-лист в продукт: роли и доступ по минимальным привилегиям с личными логинами и защищённым от подмены журналом аудита, шифрование в канале и на диске, окна хранения, истекающие автоматически на всех уровнях, маскирование и приватные зоны, доступные на этапе спецификации, и инструменты доступа субъекта и стирания, которые умеют искать, маскировать и удалять по человеку в правовой срок. Когда клиент хочет распознавание лиц или чтение номеров, мы трактуем биометрический шлюз как жёсткую ветку в дизайне, а не переключатель, потому что правовой вес иной и система должна это отражать. Рамка, которой мы держимся, – точность-против-производительности: контроль приватности, который вы не можете продемонстрировать, – это не контроль, а заявление о комплаенсе, которое вы не можете доказать, – это риск. Мы строим так, чтобы честный ответ на «можете показать, что система законна?» был «да», с документами в подтверждение.

Ключевые выводы

  • Комплаенс – это упорядоченный набор решений перед запуском, а не финальная проверка; идите по порядку.
  • Сначала фиксируйте цель, затем правовое основание; пишите LIA, если опираетесь на легитимный интерес.
  • DPIA обязательна для масштабного мониторинга общественных мест или биометрии; делайте её до развёртывания.
  • Распознавание лиц – самый тяжёлый шлюз: явное согласие, условие спец-категории, BIPA-обзор и проверка AI Act.
  • Давайте многослойное уведомление до начала охвата камер; задайте окно хранения и автоматизируйте удаление.
  • Минимальные привилегии, личные логины, журнал аудита, шифрование и рабочий процесс прав субъектов.

Что почитать дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.