Бесконтактное заселение обычно начинают обсуждать с замков: заменить карты мобильным ключом и убрать очередь у стойки. Но с 1 марта 2026 года действует Постановление Правительства РФ № 1912, которое заменило прежние правила предоставления гостиничных услуг. С 1 апреля 2026 года заработали и его положения об идентификации гостя через мобильное приложение Госуслуг. Теперь первый вопрос другой: как отель подтверждает личность гостя и что потом происходит с его данными.

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

Начать стоит с идентификации. По данным отраслевого издания Hotgrade, отели с номерным фондом больше 50 номеров с 1 сентября 2026 года обязаны обеспечить подтверждение личности гостя через цифровой документ в национальном мессенджере MAX. Для объектов до 50 номеров срок наступает 1 сентября 2028 года. Источник отраслевой, а не официальный, так что даты лучше сверить с текстом постановления. Если они верны, крупный отель обязан обеспечить гостю возможность подтвердить личность через MAX, но сам гость не обязан пользоваться этим каналом. Небольшому объекту такую возможность нужно закладывать в план подготовки.

Дальше нужно решить, где хранятся данные. При онлайн-сборе оператор обязан использовать базы данных на территории России для записи, систематизации, хранения и других операций с персональными данными граждан РФ, за исключением случаев, предусмотренных законом. Если паспортные данные гостя попадают в форму регистрации, облако замков или сервис рассылок, отелю нужно проверить, где хранятся данные в каждой из этих систем и какой правовой статус у каждого подрядчика, с учётом конкретной схемы передачи данных и поручения обработки.

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

В форму регистрации гость попадает по ссылке из welcome-письма, через личный кабинет или по ссылке, которую отель присылает после бронирования. Там он проверяет данные, прикладывает документ и подтверждает согласие с политикой конфиденциальности и обработкой персональных данных. TravelLine описывает автозаполнение формы при авторизации через T-ID: подставляются ФИО, дата рождения, гражданство, телефон, паспортные данные, место рождения и адрес регистрации. Проверить сведения перед отправкой гость всё равно должен. Ввод становится быстрее, но ошибок в данных автозаполнение не исключает.

Собранные сведения нужно передать дальше, причём требования для разных гостей различаются: данные иностранных гостей передаются для миграционного учёта, а регистрация граждан России по месту пребывания осуществляется по отдельным правилам. PMS может передавать сведения через ЕПГУ или через специализированных посредников. В качестве примеров посредников TravelLine называет СКАЛА-ЕПГУ, СБИС и Контур ФМС. От выбора канала зависит, сколько компаний получат персональные данные гостя и у скольких из них придётся проверять локализацию.

Интеграция PMS с электронными замками привязывает ключ к бронированию, датам проживания и номеру. TravelLine также описывает контроль доступа к номерам и служебным зонам, блокировку и программирование карт. Bnovo перечисляет, что нужно для интеграции: PMS, совместимые замки, энкодер и промежуточное программное обеспечение. Ключ активируется на срок проживания, его можно продлить или заблокировать досрочно. Ключ создаётся на основе брони в PMS, поэтому без стабильной интеграции он не работает.

Поставщики PMS автоматизируют и смежные процессы: оплату по ссылке, выдачу чеков, отправку welcome-сообщений. Гость видит одну цепочку сообщений. У отеля за ней стоит несколько отдельных интеграций, и каждая работает с данными гостя.

Звенья у всех схем одни и те же. Различается распределение работы: что делает гость, что берёт на себя техника и что остаётся персоналу. Схемы удобно сравнивать по пяти пунктам: где подтверждается личность, какое оборудование и интеграции нужны, куда уходят персональные данные, насколько всё зависит от смартфона гостя и что происходит при сбое.

• Личность: гость заполняет данные заранее, а при заселении сотрудник проверяет документ или цифровой способ идентификации.
• Оборудование и интеграции: форма онлайн-регистрации, PMS и канал передачи данных в МВД. Для карт нужны совместимые замки, энкодер и при необходимости промежуточное ПО.
• Данные: проходят через форму регистрации, PMS и канал миграционного учёта.
• Смартфон: нужен только для заполнения формы, ключ гость получает на руки.
• Сбой: если онлайн-регистрация не сработала, сотрудник заселяет гостя в обычном порядке.

Привычный процесс здесь меняется меньше всего. Данных на стойке вводят меньше, но встреча с сотрудником остаётся.

• Личность: схема рассчитана на цифровые способы идентификации. Но поддержка цифрового документа не означает подтверждения личности без сотрудника: в государственном сценарии с MAX сотрудник гостиницы сканирует QR-код цифрового документа через Госкан. Мобильный ключ может позволить гостю обойтись без стойки, а нужен ли сотрудник для идентификации, зависит от конкретной интеграции и сценария.
• Оборудование и интеграции: к звеньям первой схемы добавляется облачная выдача мобильных ключей. Например, dormakaba BlueSky Access передаёт мобильный ключ гостю до прибытия через облачную систему. Поставщик предлагает комплекс из программного обеспечения, замков, установки, обучения и сервисного обслуживания.
• Данные: в цепочке появляется облачный сервис ключей, и у него тоже нужно проверить, где хранятся данные.
• Смартфон: нужен и для идентификации, и для входа в номер.
• Сбой: сотрудника на месте нет, поэтому запасной способ попасть в номер нужно подготовить заранее. Без него при сбое интеграции или неработающем телефоне гость не сможет заселиться.

• Личность: основной путь цифровой. Гость, который не может или не хочет им воспользоваться, подтверждает личность у сотрудника.
• Оборудование и интеграции: всё, что нужно для второй схемы, плюс энкодер и карты для резерва.
• Данные: те же участники цепочки, что во второй схеме.
• Смартфон: нужен только гостям, которые выбрали цифровой путь.
• Сбой: гость идёт на стойку. PMS умеет досрочно блокировать ключи и программировать карты, так что мобильный ключ можно заменить картой.

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

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

Вопросы к поставщикам PMS, замков и онлайн-регистрации:

1. Какие модели замков и энкодеров совместимы с нашей PMS? Нужно ли промежуточное ПО и кто отвечает за него при сбое?
2. Как сведения о гостях попадают в МВД: напрямую через ЕПГУ или через посредника? Если через посредника, то через какого?
3. Где физически находятся базы данных формы регистрации, PMS, облака ключей, сервиса рассылок и посредника по миграционному учёту? Локализацию и правовой статус каждого участника цепочки стоит проверить с учётом того, как именно ему передаются данные и поручается их обработка.
4. Можно ли из PMS продлить ключ или заблокировать его досрочно? Ведётся ли журнал доступа к номерам и служебным зонам?
5. Какие способы цифровой идентификации поддерживает решение? Есть ли подтверждение личности через MAX, если отель уже обязан его обеспечивать?

Вопросы к собственным процессам:

• Обновлены ли политика обработки персональных данных и тексты согласий под онлайн-форму? Определены ли цели, перечень данных, сроки хранения и уничтожения? Назначен ли ответственный?
• Есть ли резервный ключ и описанный порядок ручного заселения? Кто заселяет гостя, если постоянного сотрудника на стойке нет?
• Куда обращается гость, если регистрация не прошла или ключ не открывает дверь?
• Что измерять в пилоте? Например, долю гостей, завершивших онлайн-регистрацию, число переходов на ручное заселение, обращения в поддержку по регистрации и ключам, сбои при передаче данных и выдаче ключей. Отраслевых ориентиров по этим показателям в использованных источниках нет, поэтому целевые значения лучше установить по итогам собственного пилота.

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

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

Важен и размер номерного фонда. По данным Hotgrade, отели больше 50 номеров должны поддерживать идентификацию через MAX уже сейчас. У небольших объектов есть время до сентября 2028 года, и цифровую идентификацию им логично выстроить раньше, чем менять замки. Порядок подготовки у всех один: сначала идентификация, работа с данными и миграционный учёт, а ключ в последнюю очередь.