Персональные данные в AI-консьерже: что собирать, где хранить и когда удалять

AI-консьержу не нужен весь профиль гостя. Ему нужен минимальный набор данных для конкретного действия: ответить на вопрос, связать обращение с бронированием, создать заявку или передать её сотруднику. Отель должен заранее определить цель каждого поля, законное основание, систему-источник, получателей, срок хранения и способ удаления — отдельно для диалога, PMS, CRM, телефонии, аналитики и журналов.

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

Короткий ответ: составьте реестр потоков данных; отделите обязательное для проживания от удобного для сервиса и от аналитики; передавайте модели только необходимый контекст; не используйте реальные диалоги для обучения автоматически; установите срок и событие удаления для каждой копии; проверьте подрядчиков и субподрядчиков; журналируйте доступ и удаление; предусмотрите запрос гостя и инцидент.

Почему «данные AI-консьержа» находятся не в одной системе

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

Поэтому вопрос «где хранится переписка?» слишком узкий. Нужна карта полного маршрута: вход, временная обработка, долговременное хранение, резервные копии, журналы, аналитика, ручная выгрузка и передача поставщикам. Мониторинг AI-консьержа помогает восстановить операционный исход, но сам по себе не определяет законность и срок хранения каждой записи.

Начните с реестра потоков, а не со списка систем

Список «PMS, CRM, чат, телефония, AI» показывает поставщиков, но не цели обработки. Реестр строят по операциям: подтвердить бронь, заказать уборку, сообщить время завтрака, проверить право на доступ, зарегистрировать гостя, разобрать жалобу. Для каждой операции фиксируют одинаковые поля.

Реестр не обязан начинаться как сложная GRC-система. Для первого сценария достаточно контролируемой таблицы с владельцем и датой пересмотра. Важно, чтобы поля соответствовали фактическому потоку, а не только договору или презентации поставщика.

Какие данные действительно нужны AI-консьержу

Информационный ответ

Чтобы сообщить время завтрака или правила парковки, обычно не требуется идентифицировать гостя. Контекстом могут быть объект, язык, канал и актуальная база знаний. Передача модели ФИО, телефона, номера комнаты и истории проживания только потому, что они доступны в PMS, расширяет риск без улучшения результата.

Заявка на услугу

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

Операция повышенного риска

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

Аналитика и улучшение качества

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

Псевдонимизация не равна анонимизации

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

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

Как назначить сроки хранения без выдуманной нормы

Нет одного срока «для AI-диалогов отеля». Срок выводят из цели, применимого закона, договора, требований к претензиям и реальной технической необходимости. В России статья 5 закона № 152-ФЗ закрепляет хранение не дольше, чем этого требует цель, если иной срок не установлен законом или договором. Статья 18.1 требует описывать для каждой цели сроки обработки и хранения, а также порядок уничтожения.

В ЕС статья 5 GDPR содержит принцип storage limitation: идентифицируемые данные хранят не дольше необходимого для цели. Это не готовое число дней. Отель должен обосновать собственный период и отличить активную операцию от архива, юридической блокировки и резервной копии.

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

Удаление должно быть проверяемым

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

1. Получить событие. Достигнута цель, истёк срок, отозвано согласие там, где оно было основанием, или удовлетворён применимый запрос субъекта.
2. Найти связанные записи. Использовать контролируемый идентификатор маршрута, а не ручной поиск по имени во всех системах.
3. Проверить исключения. Отделить обязательное хранение или юридическую блокировку от данных, которые можно удалить.
4. Удалить или необратимо обезличить. Выполнить действие в собственных системах и передать поручение обработчикам.
5. Зафиксировать результат. Сохранить минимум доказательства операции без повторного сохранения удалённого содержимого.
6. Проверить восстановление. Убедиться, что резервная копия не возвращает данные в активный контур без повторной очистки.

Роли отеля, AI-поставщика и субподрядчиков

Название договора не определяет роль автоматически. В GDPR-контуре controller определяет цели и существенные средства обработки, processor действует по его инструкциям, а subprocessor подключается по разрешённой договорной цепочке. EDPB отдельно указывает, что договор с обработчиком должен описывать инструкции, конфиденциальность, безопасность, помощь по запросам и инцидентам, удаление или возврат данных, аудит и условия привлечения субобработчиков.

Для РФ отель-оператор также должен описать поручение на обработку и фактические обязанности сторон в соответствии с применимым правом. Не ограничивайтесь фразой «поставщик соблюдает закон». Запросите конкретику: какие данные принимает модель, где проходит обработка, используются ли входы для обучения, кто субподрядчики, как меняется их список, где находятся базы и резервные копии, как выполняются удаление, экспорт, блокировка и расследование.

География: какие правила нельзя смешивать

Россия

Для объекта, работающего с персональными данными в РФ, базовый контур строится вокруг закона № 152-ФЗ и связанных требований. Актуальная на дату исследования редакция статьи 5 требует конкретных законных целей, соответствия объёма данных цели, неизбыточности, точности и ограничения хранения. Статья 18.1 требует локальных документов по целям, категориям, срокам, уничтожению, контролю и обучению работников. Для данных граждан РФ отдельно проверяйте требования к базам данных и трансграничной передаче: с 1 июля 2025 года общее правило локализации было ужесточено. Конкретную архитектуру следует согласовать с профильным юристом и специалистом по защите информации.

ЕС и Европейская экономическая зона

GDPR применяется не потому, что сервис «облачный», а по условиям территориальной и предметной применимости. Если контур подпадает под GDPR, нужны законность, прозрачность, ограничение цели, минимизация, точность, ограничение хранения, безопасность и подотчётность. Международная передача и отношения controller/processor оцениваются отдельно. Не переносите российское согласие или локализацию как замену европейскому анализу — и наоборот.

Добровольные рамки NIST

NIST Privacy Framework 1.0 предлагает функции Identify-P, Govern-P, Control-P, Communicate-P и Protect-P для управления privacy-risk. Это добровольная межотраслевая рамка США, а не закон и не гостиничная сертификация. На 14 августа 2026 года версия 1.1 всё ещё обозначена NIST как Initial Public Draft / coming soon, поэтому статья не выдаёт её за финальный стандарт.

Как связать приватность с запуском и качеством AI

Приватность нельзя проверять один раз перед договором. В 30-дневном пилоте AI-консьержа карта данных должна входить в критерии go / hold / no-go. Новая интеграция, канал, модель, язык или сценарий меняют состав и получателей данных — значит, требуют пересмотра.

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

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

План внедрения на один сценарий

Шаг 1. Нарисуйте фактический маршрут

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

Шаг 2. Уберите лишнее

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

Шаг 3. Разведите доступ

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

Шаг 4. Настройте сроки и удаление

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

Шаг 5. Проверьте поставщиков

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

Шаг 6. Назначьте пересмотр

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

FAQ

Можно ли передавать модели полный объект бронирования?

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

Согласие гостя решает все вопросы?

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

Можно ли хранить диалоги бессрочно для улучшения сервиса?

Формулировка «улучшение сервиса» не задаёт границу цели и срока. Определите конкретный тест, набор данных, доступ, период пересмотра и удаление. Для многих проверок достаточно маскированного фрагмента или синтетического кейса.

Удаление имени делает диалог анонимным?

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

Нужно ли хранить скрытые рассуждения модели?

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

Кто отвечает, если данные обработал AI-поставщик?

Ответ зависит от роли и юрисдикции; передача поставщику не снимает обязанности отеля автоматически. Определите operator/controller, processor и subprocessor по фактическим целям и действиям, закрепите инструкции и проверяемые обязанности договором.

Какой срок хранения логов считается правильным?

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

Когда нужна отдельная оценка воздействия?

В GDPR-контуре DPIA требуется при обработке, вероятно создающей высокий риск; EDPB приводит критерии вроде систематического мониторинга, чувствительных данных, крупного масштаба, объединения наборов и инновационной технологии. Для РФ и других стран применяются свои процедуры оценки и защиты. Решение принимает компетентный владелец с учётом фактического сценария.

Методология, география и источники

Исследование проведено 14 августа 2026 года. Метод: сверка контент-плана и публичного sitemap Консьерж Академии, desk research нормативных и официальных методических источников, затем проектирование типового реестра потоков для гостиничного AI-сценария. Мы не проводили юридический аудит конкретного отеля, не проверяли его договоры, сеть, базы, поставщиков или сроки и не выводили универсальные периоды хранения.

• Федеральный закон № 152-ФЗ, статья 5 — актуальная на дату доступа редакция принципов обработки в РФ: конкретная цель, соответствие, неизбыточность, точность и ограничение хранения. КонсультантПлюс — авторитетная справочно-правовая система, но не официальный портал опубликования.
• Федеральный закон № 152-ФЗ, статья 18.1 — меры оператора: документы по целям, категориям, срокам и уничтожению, внутренний контроль и обучение работников.
• Обзор изменений по локализации с 1 июля 2025 года — справочный источник о запрете использовать базы за пределами РФ для перечисленных операций при сборе данных граждан РФ по общему правилу; исключения и трансграничную передачу нужно оценивать отдельно.
• GDPR, официальный текст EUR-Lex — право ЕС/ЕЭЗ; использованы статьи 5, 25, 28, 30, 32 и 35. Применимость зависит от роли, территории и фактической обработки.
• EDPB: controller, processor и subprocessor — официальный практический гид европейского регуляторного органа о ролях и договорной цепочке.
• EDPB: data protection by design, реестр и DPIA — официальный guide для малого бизнеса; примеры не являются автоматической классификацией гостиничного AI.
• NIST Privacy Framework — добровольная межотраслевая рамка США. Версия 1.0 финальная; 1.1 на дату исследования всё ещё опубликована как Initial Public Draft / coming soon.
• NIST AI RMF Core — добровольная, law-agnostic рамка управления AI-риском; использованы требования картировать третьи стороны, privacy-risk и жизненный цикл. AI RMF 1.0 пересматривается.

Vendor-sponsored количественные исследования не использовались. В статье нет обещаний снижения риска, средней длительности хранения или универсального состава полей. Таблицы и схема — проектные шаблоны для адаптации; они не заменяют требования конкретной страны, договоры, оценку специалиста по защите информации и юридическое заключение.

Что сделать сегодня

Выберите один сценарий — например, заявку на уборку — и заполните одну строку реестра до конца. Укажите каждое поле, цель, основание, систему, получателя, страну, роль доступа, срок и подтверждение удаления. Затем сравните таблицу с реальным запросом модели и записью в CRM. Первое расхождение и будет вашей приоритетной задачей.