Короткий ответ: подтверждайте факт, а не собирайте архив фотографий
Безопасная проверка личности начинается с вопроса: какой факт нужен компании для конкретной операции? Иногда достаточно подтвердить имя и полномочия представителя, в другом случае требуется сверить ИИН или возраст, а для отдельного регулируемого процесса — выполнить предусмотренную законом идентификацию. Фото удостоверения, отправленное в рабочий чат, редко является лучшим способом решить эту задачу. Оно создаёт дополнительную копию документа, расширяет круг доступа и не гарантирует, что документ предъявляет его владелец.
Практичный подход — отделить проверку от хранения. Клиент или сотрудник предъявляет документ через допустимый канал, уполномоченный работник либо интегрированный сервис проверяет необходимые сведения, а в CRM или системе документов сохраняется результат: что проверено, когда, каким способом и кем. Само изображение оставляют только тогда, когда для этого есть подтверждённое основание и установленный срок.
Почему фотография в мессенджере создаёт отдельный риск
Рабочий чат удобен для быстрого общения, но плохо подходит для документов с идентификационными данными. Изображение может автоматически сохраниться на телефоне, попасть в резервную копию, остаться в истории у бывшего сотрудника или быть переслано в другой канал. Руководитель при этом часто не может точно ответить, сколько копий существует, кто их скачал и когда они будут удалены.
Есть и процессный риск. Сотрудник видит похожую на удостоверение картинку и воспринимает её как доказательство личности. Но изображение можно изменить, повторно использовать или отправить от имени другого человека. Поэтому входящий файл нужно рассматривать как чувствительные данные, а не как завершённую идентификацию. Если документ уже поступил в чат, не копируйте его дальше «для удобства»: зафиксируйте инцидент по внутреннему порядку, перенесите проверку в утверждённый канал и удалите лишние экземпляры там, где это допустимо.
Проверка, идентификация и хранение — три разных действия
Проверка отвечает на ограниченный вопрос: совпадает ли предъявленный документ с нужными сведениями и условиями операции. Идентификация связывает человека с установленной личностью по правилам конкретного процесса. Хранение создаёт долговременную копию или набор данных, доступный после завершения проверки. Эти действия требуют разных решений и не должны автоматически следовать одно из другого.
Казахстанское регулирование ограничивает использование копий документов для идентификации и требует, чтобы состав персональных данных соответствовал заранее определённой законной цели. Для бумажных копий предусмотрены отдельные ограничения и исключения. Точный порядок зависит от отрасли, услуги и основания обработки, поэтому юридически значимые сценарии следует согласовать с ответственным за персональные данные и юристом. Для проектирования системы полезен безопасный базовый принцип: не хранить изображение только потому, что его было легко получить.
Начните с карты сценариев, а не с одной формы для всех
Один универсальный запрос «пришлите удостоверение» обычно скрывает несколько задач. Отдел продаж хочет исключить ошибку в реквизитах, склад — выдать товар нужному получателю, бухгалтерия — оформить документ, HR — подтвердить сведения сотрудника. Сначала опишите каждый сценарий отдельно: действие, проверяемый факт, допустимый способ, ответственная роль, результат и срок хранения.
После этого станет видно, где документ вообще не нужен. Для обратного звонка достаточно контакта и темы обращения. Для получения заказа может хватить кода выдачи и проверки имени по установленному правилу. Для подписания документа важнее полномочия и действительная электронная подпись, чем фотография удостоверения. Если основание требует расширенной идентификации, этот маршрут выделяют отдельно и не распространяют его на все заявки.
| Сценарий | Что нужно подтвердить | Что сохранять |
|---|---|---|
| Первичная консультация | Контакт и согласие на связь | Имя, канал и тема обращения |
| Выдача заказа | Право получить конкретный заказ | Факт проверки и номер операции |
| Подписание договора | Личность, полномочия и волеизъявление | Реквизиты документа и результат подписания |
| Регулируемая услуга | Факты по отраслевым требованиям | Только предусмотренный состав и срок |
Собирайте поля, которые меняют решение
Минимизация данных — это не удаление всего подряд, а связь каждого поля с действием бизнеса. Если дата рождения нужна только для проверки возраста, системе может быть достаточно результата «условие выполнено», а не полной даты и изображения документа. Если сотрудник сверяет имя получателя, не обязательно сохранять адрес, фотографию и все номера, видимые на удостоверении.
Для каждого поля задайте четыре вопроса: какое решение оно меняет, откуда поступает, кто его видит и когда оно удаляется. Поле без ответа не должно попадать в обязательную форму. Отдельно проверьте скрытые копии: вложения в задачах, экспорт таблицы, журнал интеграции, скриншоты поддержки и резервные копии. Минимизация не работает, если интерфейс хранит три поля, а технический журнал — весь исходный документ.
Предусмотрите безопасный канал предъявления
Канал проверки должен соответствовать чувствительности данных. Для личного обслуживания это может быть предъявление оригинала или цифрового документа уполномоченному сотруднику без создания копии. Для дистанционного сценария используют утверждённый организацией способ, который поддерживает согласие, проверку источника, защиту передачи и фиксацию результата. Технический вариант выбирают после проверки требований конкретной отрасли.
Сервис цифровых документов позволяет предъявлять юридически значимые цифровые сведения и документы с согласия пользователя в предусмотренных сценариях. Для бизнеса важен не внешний вид экрана, а проверяемый обмен: пользователь инициирует предоставление, система получает допустимые сведения, а сотрудник видит результат. Фотография экрана или скриншот снова превращает проверяемое предъявление в обычную копию. Поэтому нельзя подменять интеграцию просьбой «сделайте снимок и отправьте менеджеру».
Храните доказательство процесса, а не весь документ
После проверки бизнесу обычно нужен воспроизводимый след операции. Запишите идентификатор заявки или договора, время, способ проверки, ответственного, набор подтверждённых фактов и результат. Если использовался внешний или государственный сервис, храните предусмотренный технический идентификатор ответа, но не расширяйте журнал полным содержимым запроса без необходимости.
Статус должен быть понятным: «проверено», «требуется уточнение», «отказано по установленной причине» или «невозможно проверить». Не используйте расплывчатую отметку «документы есть», если никто не понимает, какие именно сведения были подтверждены. В CRM статус помогает продолжить клиентский процесс, а в системе документов — связать проверку с конкретным договором или заявлением. Доступ к деталям оставляют только ролям, которым он нужен для работы или контроля.
Настройте доступ, срок и удаление как единый цикл
Защита заканчивается не в момент загрузки файла. Назначьте владельца набора данных и роли, которым доступна проверка. Менеджеру может быть достаточно результата, специалисту контроля — причин и журнала, администратору — технического состояния без просмотра содержания. Выгрузка и массовый просмотр требуют отдельного разрешения и регистрации действий.
Срок хранения связывают с целью, договором, обязательными требованиями и правилами архива. По его окончании данные удаляют или обезличивают по утверждённому порядку, учитывая рабочие копии и резервное восстановление. Проверьте удаление на тестовой записи: исчезла ли она из интерфейса, вложений, поискового индекса и доступных экспортов. Отдельно запускайте пересмотр доступа при увольнении, смене роли или завершении проекта.
Исключения должны быть редкими и наблюдаемыми
Иногда основной способ недоступен: сервис не отвечает, клиент не может пройти цифровую проверку или закон предусматривает иной порядок. Для таких случаев нужен запасной маршрут, а не импровизация сотрудника. Укажите, кто разрешает исключение, какие сведения допустимо получить, куда их загрузить, как проверить подлинность и когда удалить временный файл.
Каждое исключение отмечают в журнале с причиной. Если их доля растёт, проблема находится не у клиентов, а в основном процессе: неудобный интерфейс, неверные права, нестабильная интеграция или неподходящее правило. Не превращайте резервный канал в постоянную отправку документов по личным номерам. Временная мера должна иметь владельца, срок и план возврата к штатной проверке.
Условный пример: выдача оборудования представителю клиента
Представим условную сервисную компанию. Раньше менеджер просил представителя клиента отправить фото удостоверения в мессенджер, пересылал его на склад и сохранял в карточке сделки. После пересмотра процесса компания фиксирует в заказе получателя и основание выдачи. Перед визитом клиент получает номер операции, а на месте сотрудник сверяет необходимые сведения по утверждённому способу.
В CRM остаются время, ответственный, результат проверки и связь с заказом. Склад видит разрешение на выдачу, но не получает изображение документа. Если сведения не совпали, оборудование не передают автоматически: создаётся задача ответственному менеджеру на уточнение полномочий. Для исключительного случая действует отдельный маршрут. Это условный пример проектирования, а не заявленный клиентский кейс ZXC.
План перехода за десять рабочих дней
В первые два дня найдите все точки, где сотрудники просят копии: формы сайта, почту, мессенджеры, CRM, папки и инструкции. Затем выберите один частый сценарий и определите минимальный факт, который действительно нужен. На четвёртый и пятый день согласуйте основной и резервный способы проверки, роли и правовое основание.
Во второй неделе настройте карточку результата, ограничения доступа, срок хранения и журнал исключений. Проведите тест от имени клиента, менеджера, контролёра и уволенного сотрудника с отозванными правами. Проверьте мобильный путь и неудачные случаи: неверные данные, недоступность сервиса, повторная заявка. После запуска ежедневно разбирайте исключения, а через месяц решите, какой сценарий переводить следующим.
- Определён проверяемый факт и момент принятия решения.
- Копия документа не создаётся по умолчанию.
- Утверждены основной и резервный каналы.
- В системе сохраняется результат и ответственный.
- Доступ выдан по роли и проверяется при смене сотрудника.
- Срок, удаление и исключения контролируются на практике.
Частый вопрос: можно ли просто закрыть доступ к папке с копиями?
Ограничение доступа необходимо, но не решает вопрос цели и избыточности. Сначала определите, нужна ли копия вообще и есть ли основание для её хранения. Если достаточно результата проверки, перенесите процесс на него. Для обязательных копий задайте отдельный защищённый контур, роли, срок и аудит действий.
Частый вопрос: цифровой документ можно заменить скриншотом?
Нет, скриншот не сохраняет свойства проверяемого цифрового предъявления и снова создаёт обычную копию. Используйте предусмотренный сервисом способ предоставления и проверки с согласием пользователя. Если интеграция недоступна, применяйте заранее согласованный резервный маршрут, а не снимок экрана в чате.
Частый вопрос: нужно ли удалять уже собранные изображения?
Сначала проведите инвентаризацию и определите основание, цель и обязательный срок для каждого набора. Не удаляйте материалы, которые должны сохраняться по закону или необходимы для незавершённого разбирательства. Избыточные и утратившие цель копии удаляйте по утверждённому порядку с фиксацией результата и проверкой резервных контуров.
Следующий шаг: замените запрос копии на управляемую проверку
Выберите один сценарий, где сотрудник сейчас пишет клиенту или коллеге «пришлите фото удостоверения». Зафиксируйте необходимый факт, допустимый способ предъявления, минимальный результат, роли доступа, срок и резервный порядок. Уже эта схема покажет, какие копии лишние, а где требуется отдельное юридическое и техническое решение.
ZXC SECURE помогает выстроить управление доступом и контроль чувствительных данных, ZXC DOCS — связать проверку с документом и маршрутом, а ZXC CRM — сохранить результат в клиентском процессе без лишних вложений. Начинайте с одного повторяемого сценария и проверяйте его от запроса до удаления данных.