Черновик — не является публикуемой редакцией

Политика обработки персональных данных Careeroom

Это черновик, не финальный документ. Готовился для внутренней сверки перед запуском сайта и требует проверки юристом перед публикацией. Реквизиты оператора, адреса, контакты и дата вступления в силу оставлены как [ЗАПОЛНИТЬ: ...] — их дозаполняет заказчик. Формулировки, для которых не нашлось основания в коде или согласованном спеке, отмечены [УТОЧНИТЬ У ЗАКАЗЧИКА: ...] — вместо того чтобы придумывать правдоподобный текст.
Документ описывает систему в том виде, в котором она спроектирована (согласованный спек и планы реализации), а не только то, что уже написано в коде на сегодняшний день: часть элементов (четыре формы, отправка в S3/Telegram, обращение к модели GigaChat, Langfuse) на момент составления черновика ещё в разработке. Публиковать документ и открывать сайт для сбора персональных данных можно только когда описанное здесь поведение работает фактически — это отдельный пункт чек-листа запуска (план 8), не забота этого документа.

Действует в отношении сайта careeroom.ru («Сайт») и диалога с ИИ-агентом на нём.

1. Оператор персональных данных

[ЗАПОЛНИТЬ: полное наименование юридического лица/ИП, ОГРН/ОГРНИП, ИНН, юридический адрес]

Ответственный за организацию обработки персональных данных: [ЗАПОЛНИТЬ: ФИО/должность]. Контакт для обращений по вопросам обработки персональных данных: [ЗАПОЛНИТЬ: email].

2. Правовые основания

Обработка ведётся в соответствии с Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных». Основание обработки — согласие субъекта персональных данных, полученное перед отправкой любой формы с контактными данными (раздел 5).

[УТОЧНИТЬ У ЗАКАЗЧИКА/ЮРИСТА: требуется ли дополнительно основание из ст. 6 152-ФЗ помимо согласия — например, если резюме кандидата обрабатывается в рамках преддоговорных отношений; нужно ли уведомление в Роскомнадзор об обработке персональных данных до запуска — организационный пункт чек-листа запуска (план 8), сам по себе документ его не заменяет].

3. Какие данные обрабатываются

3.1 Уже работает на сайте

Идентификатор сессии диалога — техническая cookie cr_session. Содержит только случайный идентификатор записи в базе, без каких-либо сведений о посетителе. Никогда не читается и не отправляется куда-либо, кроме сервера Careeroom.
Транскрипт диалога — то, что посетитель написал агенту, и ответы агента (таблица sessions, поля transcript и canvasHistory). Если посетитель сам написал в чате своё имя, телефон или почту — это попадает в транскрипт как часть переписки. Отдельного поля «имя» или «контакт» вне форм на сайте нет, но переписка может содержать такие сведения по инициативе самого посетителя.
UTM-метки и источник перехода — из какой рекламной кампании или ссылки пришёл переход (поля utm, referrer той же записи сессии).

3.2 Будет собираться после включения форм (план 7, на момент черновика в разработке)

Сайт предусматривает четыре формы обращения — заявка на встречу, запрос звонка, бриф на вакансию (для клиентов) и отклик с резюме (для кандидатов). При отправке любой из них собирается:

имя (если указано);
как минимум один канал связи — почта, телефон или телеграм (форма требует хотя бы один);
содержимое обращения: параметры брифа, выбранный слот встречи или направление вакансии;
для отклика с резюме — файл резюме (pdf/doc/docx/rtf, до 10 МБ);
факт и версия согласия на обработку персональных данных (раздел 5 и docs/legal/consent.md);
UTM-метка, источник перехода, ссылка на сессию диалога, из которой пришло обращение.

Без отмеченного согласия форма не отправляется технически — кнопка отправки неактивна.

4. Цели обработки

ведение диалога с посетителем сайта и подбор для него релевантных материалов;
обработка обращений клиентов (заявка на встречу, бриф на вакансию, запрос звонка) — для связи и оказания услуг агентства;
рассмотрение резюме кандидатов и подбор вакансий [УТОЧНИТЬ У ЗАКАЗЧИКА: передаются ли сведения из резюме компаниям-заказчикам в рамках подбора персонала, и на каком этапе — в спеке и планах это не описано, а формулировка цели должна быть точной];
аналитика для улучшения работы сайта и диалога (обезличенные метрики, раздел 7);
исполнение требований законодательства (например, ответ на запрос субъекта персональных данных).

5. Согласие на обработку

Перед отправкой любой формы с контактными данными посетитель отмечает чекбокс согласия — он не предустановлен, без него отправка невозможна. Рядом с чекбоксом — ссылки на настоящую политику и на полный текст согласия (docs/legal/consent.md). С каждым обращением сохраняется дата согласия и версия текста, которую посетитель видел на момент отправки (consentAt, consentVersion — см. раздел «CONSENT_VERSION» в docs/legal/consent.md).

Согласие можно отозвать в любой момент — порядок описан в разделе 9.

6. Кому передаются данные

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

ПАО Сбербанк (сервис GigaChat) — обработчик реплик диалога. Реплики посетителя и подобранные материалы передаются модели GigaChat для формирования ответа агента. [УТОЧНИТЬ У ЗАКАЗЧИКА: поручение обработки персональных данных со Сбербанком должно быть оформлено отдельным документом до запуска — это организационный пункт чек-листа запуска (план 8), настоящая политика фиксирует факт передачи, а не заменяет поручение]. Проектом предусмотрено маскирование контактных данных (почта, телефон, телеграм) перед отправкой реплик модели: сама функция маскирования реализована и проверена юнит-тестами и живым запросом (web/src/llm/mask.ts, 2026-08-05) — в теле запроса к модели вместо контакта уходит [контакт скрыт]. [УТОЧНИТЬ ПЕРЕД ПУБЛИКАЦИЕЙ: на момент черновика функция ещё не подключена к движку диалога — он реализуется отдельной задачей (план 4, задача 8), и до этого мера фактически не действует. Упоминать её в публикуемом тексте как действующую гарантию можно только после того, как движок вызывает маскирование на каждой реплике и это подтверждено фактическим телом запроса, а не наличием функции в коде].
Telegram — уведомления о новых обращениях (лидах) уходят в Telegram-бот агентства.
S3-совместимое хранилище (РФ) — файлы резюме кандидатов.
Langfuse (планируется как часть инфраструктуры проекта, развёрнута отдельно от сайта, на серверах заказчика/агентства) — журнал обращений к модели GigaChat для контроля качества ответов агента; содержит реплики диалога.

Третьим лицам за пределами перечисленных получателей данные не передаются, за исключением случаев, прямо предусмотренных законодательством Российской Федерации (например, по запросу уполномоченных государственных органов).

7. Сроки хранения

Транскрипт диалога без обращения (лида). Хранится 180 дней с момента последнего обновления сессии, затем автоматически обезличивается: сам факт диалога и метрики (сегмент, число ходов) остаются для статистики, но текст переписки удаляется.
Транскрипт диалога, из которого пришло обращение (лид). Хранится, пока действует согласие, данное вместе с обращением — то есть до отзыва согласия или запроса на удаление (раздел 8), а не по TTL выше.
Данные обращения (лида) — имя, контакт, содержимое обращения, файл резюме — хранятся, пока действует согласие: до отзыва согласия, запроса на удаление или до истечения срока, для которого согласие давалось [УТОЧНИТЬ У ЗАКАЗЧИКА: срок хранения обращений, если субъект не отзывает согласие и не запрашивает удаление сам, — например, до завершения подбора плюс какой-то период; в спеке и планах названа только процедура удаления по запросу, общий срок хранения «по умолчанию» не зафиксирован].
Резервные копии базы данных. Хранятся отдельно от рабочей базы и строго меньше срока, объявленного в разделе 8 для уничтожения по запросу (30 дней): ротация раз в 14 дней. Число и обоснование, почему оно обязано быть меньше 30 дней, зафиксированы в плане 8 (docs/superpowers/plans/2026-07-30-careeroom-deploy.md, задача 3, скрипт deploy/backup.sh) — решение по задаче CRS-097. [УТОЧНИТЬ: план 8 на момент черновика ещё не реализован в коде (только в тексте плана) — при его выполнении проверить, что фактический deploy/backup.sh сохранил 14 дней и это число не разошлось с тем, что написано здесь].

8. Уничтожение по запросу («право на забвение»)

Посетитель или кандидат может запросить удаление своих персональных данных, обратившись по контакту из раздела 1.

Данные удаляются из рабочей базы и файлового хранилища в течение 30 дней с момента подтверждённого запроса — это объявленный срок, а не «немедленно», что соответствует сложившейся практике и допускается законом.
Если по техническим причинам уничтожить данные в этот срок невозможно, они блокируются (доступ к ним ограничивается) и уничтожаются в течение шести месяцев — это механизм, прямо предусмотренный 152-ФЗ, а не исключение из правила.
Резервные копии, в которых остаются удалённые данные до своей ротации, не исключаются из процедуры бэкапа: поскольку срок их жизни строго меньше объявленного срока уничтожения (раздел 7), к моменту истечения 30 дней данные отсутствуют и в копиях тоже.
Факт удаления фиксируется в журнале аудита: кто запросил, когда и какие таблицы затронуты — без содержимого удалённых данных, чтобы сам журнал не стал местом хранения персональных данных.

9. Права субъекта персональных данных

Посетитель вправе:

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

Для реализации этих прав нужно обратиться по контакту из раздела 1. [УТОЧНИТЬ У ЗАКАЗЧИКА: срок ответа на такое обращение — в отраслевой практике, на которую ориентируется проект, это 30 календарных дней; зафиксировать здесь тот же срок, если заказчик согласен].

10. Файлы cookie

`cr_session` — техническая cookie, только идентификатор сессии диалога (без содержимого), httpOnly, время жизни 30 дней. Устанавливается без отдельного согласия — без неё диалог на сайте не работает, это аналог технической сессии в любом веб-приложении.
Яндекс.Метрика (если подключена) — включается только после явного согласия в cookie-баннере на аналитику. До согласия счётчик не загружается.

11. Меры по защите персональных данных

Соединение с сайтом и внутренние соединения с сервисом GigaChat защищены TLS с использованием сертификата НУЦ Минцифры — без него защищённое соединение с моделью не устанавливается технически.
Файлы резюме хранятся в приватном бакете S3; ссылка на скачивание временная (действует ограниченное время) и генерируется только по запросу из системы уведомлений.
Загружаемый файл резюме проверяется по фактическому содержимому, а не по расширению; имя файла в хранилище генерирует сервер, а не берёт из загруженного файла.
Доступ к административной панели, где видны обращения и транскрипты, требует входа с паролем; технические меры защиты доступа [УТОЧНИТЬ У ЗАКАЗЧИКА: нужен ли перечень организационных мер по ст. 19 152-ФЗ — обычно это отдельный внутренний документ, на который здесь можно сослаться].

12. Изменение политики

Актуальная версия политики публикуется на этой странице. Дата вступления в силу текущей редакции: [ЗАПОЛНИТЬ: дата]. При существенном изменении состава данных, целей или получателей документ обновляется, а версия согласия (CONSENT_VERSION, см. docs/legal/consent.md) меняется вместе с ним, чтобы для каждого сохранённого обращения было видно, какую редакцию видел человек, давший согласие.

13. Контакты

[ЗАПОЛНИТЬ: наименование оператора, email, почтовый адрес для письменных обращений]