Согласие на обработку персональных данных: требования Казахстана

Самая сложная проверка согласия начинается не на экране с галочкой, а после обращения клиента: «Я отзываю согласие. Покажите, что именно вы получили и где это хранится». По действующей редакции статьи 8 Закона Республики Казахстан «О персональных данных и их защите» у организации есть пятнадцать рабочих дней, чтобы прекратить обработку, если данные больше не требуются по закону, либо направить мотивированный отказ.

В этот момент запись consent=true почти бесполезна. Она не отвечает, какую версию условий видел человек, охватывала ли она селфи и передачу подрядчику, действует ли согласие сейчас и какие системы должны остановиться. Компания может показать красивую форму и всё равно не суметь воспроизвести решение по конкретной сессии.

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

Коротко

• Статья 8 задаёт обязательные сведения согласия, а статья 7 отдельно требует конкретной цели и запрещает избыточный сбор.

• Электронное согласие допустимо, если компания может подтвердить его получение и восстановить показанную человеку версию.

• Для данных из цифровых объектов государственных органов используется государственный сервис согласий; обычная галочка в интерфейсе его не заменяет.

• После отзыва недостаточно изменить статус в CRM: решение нужно довести до всех систем и третьих лиц, связанных с данным согласием.

• Селфи, видео, биометрический шаблон и результат проверки — разные объекты. Для каждого определяют цель, основание, доступ и срок.

Что закон требует указать в согласии

Пункт 4 статьи 8 перечисляет сведения, которые включает согласие. В прикладной форме их удобно проверять как восемь отдельных полей:

1. наименование собственника и (или) оператора, а также его БИН либо ИИН;

2. фамилия, имя и отчество субъекта, если отчество указано в удостоверении личности;

3. срок или период действия согласия;

4. наличие или отсутствие передачи данных третьим лицам;

5. наличие или отсутствие трансграничной передачи;

6. наличие или отсутствие распространения в общедоступных источниках;

7. перечень собираемых данных;

8. другие сведения, которые определит собственник или оператор.

В доступной редакции Правил сбора и обработки 2020 года перечень заканчивается на седьмом пункте. Это не повод убрать восьмой: действующая в сентябре 2026 года редакция закона уже содержит подпункт об иных сведениях. При расхождении формы с подзаконным документом проверяйте актуальную редакцию закона и дату изменений, а не копируйте старый перечень автоматически.

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

Срок нельзя задавать автоматически «навсегда». По пунктам 5 и 6 статьи 8 он не должен превышать период, необходимый для цели обработки, если другой срок не установлен законом или договором. Если срок вообще не указан, согласие действует до достижения цели, определённой при его предоставлении. Значит, системе всё равно нужно уметь определить, когда эта цель достигнута.

Электронная галочка может быть согласием, но доказательством служит не она одна

Закон допускает письменную форму, государственный или негосударственный сервис и иной способ, позволяющий подтвердить получение согласия. Для обычного цифрового сервиса это означает, что нажатие кнопки может быть частью доказательства. Но само по себе оно не показывает содержание решения.

Минимальная запись события должна связывать:

• человека или подтверждённую пользовательскую сессию;

• собственника или оператора данных;

• неизменяемую версию условий;

• цель и перечень данных;

• время и канал подтверждения;

• способ подтверждения;

• статус согласия и последующие изменения.

Текст согласия лучше хранить отдельно как неизменяемую версию, а в журнале — ссылку на неё. Если редактор исправил форму, старые события не должны автоматически «переехать» на новый текст. Иначе компания покажет клиенту документ, которого в момент согласия ещё не существовало.

Для данных, содержащихся в цифровых объектах государственных органов или государственных юридических лиц, статья 8 устанавливает более узкий маршрут: согласие предоставляется посредством государственного сервиса. Поэтому собственный чекбокс нельзя считать заменой государственного механизма доступа. Это особенно важно, когда eKYC-процесс объединяет государственный источник, документ, селфи и проверки частного поставщика: у разных действий могут быть разные основания и разные доказательства.

Не каждое действие нужно обосновывать одним согласием

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

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

Такая карта отделяет юридическое основание от интерфейса. Человек может отказаться от необязательной будущей аутентификации по лицу, но компания при наличии установленной обязанности может продолжать хранить часть журнала уже совершённой операции. В ответе клиенту нужно назвать основание и объём такого сохранения, а не обещать удаление «всего и сразу».

В биометрическом процессе одного пункта «селфи» недостаточно

Биометрическая сессия создаёт несколько объектов, хотя пользователь видит одно действие перед камерой. Следующий список — техническая карта потока, а не отдельная классификация из закона:

• исходное селфи или видеопоток;

• кадры, выбранные для анализа живости;

• фотографию из документа или другого эталонного источника;

• биометрический шаблон либо иное математическое представление;

• оценки живости и сходства;

• итоговое решение и технический журнал.

У этих объектов могут различаться цель, доступ и срок хранения. Например, результат сравнения нужен для решения по заявке, а часть технических материалов — для разбора спорной сессии. Это не означает, что хранить нужно всё: закон требует соотносить объём с заранее определённой целью.

Состав самого дистанционного процесса — распознавание документа, проверка живости и сравнение лица — подробно разобран в статье о внедрении eKYC. Техническую границу между извлечением полей и проверкой владельца показывает материал о распознавании документов. Для банков и МФО дополнительно действует специальный режим: правила биометрической аутентификации АРРФР требуют документировать процессы сбора, хранения и уничтожения биометрических данных.

Поэтому понятная форма не перечисляет названия алгоритмов без объяснения. Она сообщает, какие действия выполняются с данными человека, какие результаты сохраняются и участвует ли внешний поставщик.

Как выполнить отзыв за пятнадцать рабочих дней

Пункт 7 статьи 8 устанавливает результат, а не внутреннюю механику: после уведомления собственник, оператор и третье лицо в течение пятнадцати рабочих дней прекращают обработку, если дальнейшее хранение или обработка не требуются по законодательству, либо представляют мотивированный отказ.

Этот срок нельзя смешивать с другими процедурами. Правила сбора и обработки отводят три рабочих дня на предоставление субъекту информации о его данных или мотивированный отказ в предоставлении сведений; однодневные сроки применяются к блокированию и уничтожению при подтверждённом нарушении. Запрос информации, отзыв согласия и сообщение о нарушении запускают разные маршруты.

Чтобы этот срок был исполним, запрос проходит шесть шагов:

• зарегистрировать обращение и дату начала срока;

• убедиться, что запрос относится к нужному субъекту, не собирая для этого избыточные новые данные;

• найти согласие, его версию и все связанные объекты обработки;

• для каждого объекта определить действие: прекратить обработку, удалить, продолжить на другом основании или подготовить мотивированный отказ;

• передать решение во внутренние системы и третьим лицам, если они участвовали в обработке;

• зафиксировать исполнение и ответить субъекту.

Главная техническая сложность находится в третьем шаге. Если CRM знает только клиента, хранилище — имя файла, а биометрический модуль — отдельный session ID, отзыв превращается в ручной поиск. Связующий идентификатор согласия должен появляться во всех событиях, которые на него опираются.

Архитектура согласия: версия, событие и состояние

Рабочую модель можно собрать из трёх сущностей.

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

Эти сущности нельзя подменять одной строкой в профиле клиента. Новая версия формы не переписывает прошлое событие; отзыв не удаляет доказательство того, что согласие когда-то было получено; окончание срока блокирует будущую операцию, даже если старая галочка всё ещё видна в базе.

В Оркестраторе Biometric.Vision можно собирать последовательность проверок и условия запуска модулей в одном eKYC-потоке. Продуктовая страница не заявляет встроенный юридический реестр согласий: организация сама утверждает цели, основания, сроки и текст формы. До запуска настроенного сценария система заказчика должна проверить состояние согласия, а идентификатор его версии сохранить в собственном журнале сессии.

Шесть тестов перед запуском

Юридическая вычитка формы отвечает на вопрос, что написано. Сквозной тест показывает, что система действительно делает.

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

Материал носит информационный характер и не заменяет юридическое заключение для конкретного процесса. Перед запуском сопоставьте форму с фактической картой данных, присвойте версиям неизменяемые идентификаторы и проведите тестовый отзыв от обращения клиента до последней связанной системы. Именно этот маршрут показывает, работает ли согласие как контроль, а не как декоративная галочка.