GDPR для хостов краткосрочной аренды: что реально нужно сделать

Когда я первый раз открыл текст GDPR, я хостил на Airbnb всего два месяца. Закрыл вкладку через двадцать страниц и продолжил собирать сканы паспортов гостей из ЕС в папку в Telegram. Три года спустя эта папка — самая позорная часть моего хостинга.

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

А он на меня вообще распространяется?

Если ваша квартира в ЕС и вы её сдаёте — да.

Если квартира вне ЕС, но вы принимаете гостей из ЕС — тоже да, из-за экстерриториального охвата GDPR. Статья 3(2) распространяет регламент на любого контролёра, «обрабатывающего персональные данные субъектов в Союзе», когда им предлагают товары или услуги. Листинг Airbnb в Ташкенте, который принимает бронирование от гостя из Берлина, формально обрабатывает данные субъекта ЕС и значит подпадает. Обзор Еврокомиссии о том, на кого распространяется регламент, про это однозначен; European Data Protection Board выпускает рекомендации, ориентированные на не-европейских контролёров.

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

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

Политика приватности (одна фраза, потом страница)

Большинство хостов либо вообще пропускают этот пункт, либо копируют шаблон со словами «субъект данных» и «контролёр», который никто не может прочитать.

Минимально работающий вариант — два слоя:

1. Одна фраза в момент сбора. Когда просите фото паспорта, отправьте короткое сообщение: «Храню до 30 дней после выезда, потом удаляю. Подробнее: ссылка». Отправляете до того, как гость загрузит файл.
2. Полная страница на /privacy. Перечислены категории данных, цель, законное основание, срок хранения и контакт для запросов на удаление. Без юридического жаргона. Простой язык выигрывает, потому что надзорные органы явно его предпочитают.

Наша страница /privacy — пример, который маленький хост может скопировать почти дословно. Около 600 слов. Ключевые секции:

• Какие данные: скан паспорта, даты бронирования, история переписки.
• Зачем: легальная регистрация гостя, разрешение споров, логистика проживания.
• Как долго: конкретное число дней, не «по необходимости».
• Кто ещё: площадки (Airbnb, Booking) и инструменты, которыми вы пользуетесь (RentTools, если используете).
• Как удалить: email, который вы реально читаете.

Не пишите дисклеймеры. Не пишите «ваша приватность нам важна». Надзорные органы такое называют демонстративным. Излагайте факты.

Типовая ошибка: хосты переиспользуют шаблон, рассчитанный на интернет-магазин. Эти шаблоны предполагают cookies, маркетинговую аналитику, сторонние трекеры. У большинства маленьких хостов ничего этого нет. Чем проще страница приватности, тем правдоподобнее она читается.

Рисунок 1: Двуслойный шаблон уведомления. Короткое сообщение в момент сбора; полная страница /privacy ниже. Скриншот появится по адресу /blog/gdpr-for-vacation-rental-hosts/figure-1.png.

Законное основание: договор, законодательная обязанность, почти никогда — согласие

Статья 6 GDPR перечисляет шесть законных оснований. Для хостов краткосрочной аренды ровно два покрывают почти все случаи.

1. Исполнение договора. Когда гость бронирует вашу квартиру, обработка имени, дат и контактных данных нужна для исполнения договора. Дополнительное согласие не требуется. Это покрывает данные на момент бронирования.
2. Законодательная обязанность. Когда местный закон требует регистрации гостя (parte de viajero в Испании, alloggiati web в Италии, fiche d’hôtel во Франции, форма ФМС в России, OVIR в Узбекистане), сбор паспорта попадает под «законодательную обязанность». Согласие тоже не нужно.

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

Практическое правило: если гость не может сказать «нет», не лишившись услуги, основание — договор или законодательная обязанность, а не согласие. Выберите правильное в политике приватности — и весь вопрос отпадает.

Срок хранения: выберите число

В большинстве privacy-уведомлений написано «столько, сколько необходимо». Технически это допустимо по статье 5(1)(e) GDPR и практически бесполезно. Надзорный орган спросит: необходимо для чего и сколько по времени? Нужно число.

Три числа, на которых я остановился, и логика за каждым:

1. Переписка по бронированию: 90 дней после выезда. Достаточно, чтобы разобрать запоздавший спор; недостаточно, чтобы вы вечно копили чаты.
2. Сканы паспортов: 30 дней после выезда, если местный закон не требует дольше. В странах, где требуется многолетнее хранение (Россия, ряд стран ЕС), следуете требованию закона. Сверх этого срока — удаляете. Скан паспорта — самые рискованные данные, которые у вас есть; чем короче хранение, тем меньше последствия утечки, если у вас украдут телефон.
3. Агрегированная история бронирований: бессрочно. Имена, даты, общая выручка. Это нужно для налоговой, а налоговая может прийти через пять лет. Контактные данные внутри этого архива не держите. Email и телефон срезаете перед архивацией.

Страновые правила хранения паспортных данных гостя разрозненные и непоследовательные. Я пишу отдельный пост с табличкой по странам — Испания, Португалия, Италия, Франция, Греция, Хорватия, Россия, Узбекистан. До его выхода — по умолчанию «минимально допустимый по местному закону срок» и сверка с управлением туризма муниципалитета.

Самая большая ошибка с GDPR, которую я вижу у хостов, — папка в WhatsApp со сканами паспортов на четыре года, потому что никто не докручивает скролл вниз и не удаляет старое. Эта папка и есть утечка. Телефон украли, паспорта гостей оказались у плохого человека, а у хоста не было оснований столько их хранить.

Субпроцессоры: кто ещё видит данные

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

• Площадки бронирования (Airbnb, Booking, Vrbo). Это совместные контролёры, не субпроцессоры. Их политики покрывают их сторону.
• Ваш PMS или sync-инструмент. Если вы пользуетесь Hostaway, Lodgify, Smoobu или RentTools — это субпроцессор. Перечислите.
• Ваш облачный хостинг. Если self-host на дроплете — облачный провайдер технически субпроцессор. Перечислите.
• Ваш email-провайдер. Почта, в которую гости шлют сканы. Gmail, Outlook, Fastmail. Перечислите.
• Платёжный процессор. Stripe, Wise, мерчант банка. Перечислите.

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

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

Маленький смежный момент: модуль уборки на маленьком объекте часто подтягивает ещё одного субпроцессора (приложение уборщика, если оно у вас есть). Уборщики видят имена гостей и время заезда, а это персональные данные. Их тоже укажите.

Процесс на запросы об удалении

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

Процесс не обязан быть инструментом. Он должен делать три вещи:

1. Принять запрос. Email-адрес (host@yourdomain или какой вы публикуете в /privacy). Не контактная форма, которая уходит в спам.
2. Верифицировать запрос. Сверить email с бронированием. Если пишет посторонний и просит удалить «данные John Smith» без подробностей — спросите, какое бронирование и с какого email оно пришло. Шаг верификации обязателен по GDPR; нельзя удалять данные по запросу самозванца.
3. Реально удалить. Очистить папку в почте, удалить скан паспорта, отредактировать запись в календаре. Пройдитесь по каждому субпроцессору и подтвердите. Если данные лежат в инструменте, который вы не контролируете (системы Airbnb), направьте заявителя туда. Удалить можно только то, что ваше; вы удаляете свою копию.

По статье 12(3) на ответ — 30 дней, для сложных запросов продлевается до 90. Запрос маленького хоста сложным не бывает; ответьте за неделю — и вы в норме.

Ведите небольшой лог: дата запроса, заявитель, что удалили, дата завершения. Одна строка на запрос. Если надзорный орган когда-нибудь спросит — лог и есть доказательство, что процесс существует.

Одно мнение, не нейтральное

Самое полезное действие по GDPR, которое маленький хост может сделать на этой неделе, — записать срок хранения и его соблюдать. Не политика приватности (нашу можно скопировать). Не выбор законного основания (почти всегда договор или законодательная обязанность). Срок хранения.

Большинство знакомых мне маленьких хостов в порядке по всем остальным пунктам и в просадке по сроку хранения, потому что они никогда не выбирали число. Выберите. Запишите на странице /privacy. Поставьте напоминание в календаре на «зачистку» первого числа каждого месяца. Удалите всё, что просрочено. Остальное по GDPR следует из этой одной привычки.