Безопасность школьных ботов: что хранит CampusHub и чего никогда не хранит

Когда мы предлагаем учебному заведению подключить бота, в 9 из 10 первых разговоров возникает один и тот же вопрос: «А что с безопасностью данных?». Школы и вузы боятся проверок РКН, родители — утечек ФИО и оценок. Расскажем по пунктам, что мы храним, как, и почему ничего лишнего у нас в базе нет.

Что мы храним — короткий список

В базе CampusHub лежит ровно три типа данных:

• Связка MAX‑идентификатор → группа/класс. Когда студент или родитель пишет боту «я из 5Б», мы запоминаем, что пользователь с этим внутренним ID мессенджера привязан к группе 5Б. Никаких ФИО.
• Расписание учреждения. Это публичные данные, они и так доступны всем, мы просто индексируем их для быстрого поиска.
• Краткосрочный контекст диалога. До 30 последних сообщений в чате — чтобы бот понимал follow‑up вопросы «а завтра?» после «что у меня сегодня?». Хранится в оперативной памяти приложения и автоматически удаляется через 30 минут после последнего сообщения, при перезапуске сервиса или при блокировке бота.

Всё. Больше — ничего.

Privacy by default: анонимность по умолчанию

Пользователь, который ни разу не выполнял привязку к группе (команда /группа), для системы полностью анонимен. Хранится только числовой ID мессенджера — никакого контекста, никакой группы, никаких настроек. Это значение по умолчанию.

Чтобы данные о пользователе появились в базе, требуется явное действие со стороны самого пользователя.

Что мы НЕ храним — даже если вы попросите

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

ФИО ученика или студента

Внутри нашей базы у пользователя нет имени и фамилии. Есть внутренний идентификатор MAX (это случайная строка, выданная самим мессенджером) и привязка к группе. Когда бот пишет «Иван, вот твоё расписание» — это потому, что мессенджер передаёт имя из профиля пользователя при запросе, и бот использует это имя только в текущем ответе. В базу оно не записывается.

Оценки, аттестация, успеваемость

У нас нет интеграции с электронным журналом и нет планов её делать в стандартной поставке. Это область компетенции специализированных систем (Дневник.ру, ЦПС, БАРС). Бот отвечает на вопросы про расписание и общую информацию — не про учёбу конкретного человека.

Содержание разговоров после 30‑минутного окна

Бот не ведёт «историю диалогов» в долгосрочном смысле. Если 31 минуту назад пользователь спросил «когда у меня экзамен?», а сейчас — «что у меня завтра?», для бота это два независимых запроса. Контекст обнуляется. Поэтому даже если кто‑то получит доступ, восстановить «о чём думал и спрашивал ученик» невозможно — этих данных просто нет.

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

Телефоны, email‑адреса, домашние адреса родителей и преподавателей — мы их не запрашиваем и не храним. Если бот должен сказать «звоните в учебную часть, +7 (XXX)», эти контакты лежат в вашем публичном регламенте или на сайте — и оттуда их видит бот, в свою базу не копирует.

Биометрия и медданные

Голос, лицо, любые медицинские данные — даже близко не приближаемся. У бота нет ни функции голосовой авторизации, ни анализа фото, ни работы со справками. Это вне нашего scope.

Как технически защищено то, что всё‑таки хранится

Архитектура: минимум данных, обезличенные идентификаторы

Главный принцип защиты — отсутствие чувствительных полей. В коллекциях CampusHub нет ни ФИО, ни паспортов, ни оценок, ни контактов. Хранится:

• числовой идентификатор пользователя в мессенджере;
• короткое название группы (например, «Б‑204»);
• статистика активности (последний визит, число запросов).

Это не персональные данные согласно 152‑ФЗ. Лучшая защита от утечки — отсутствие самих данных.

Контексты диалогов: только в памяти, без диска

Текст разговора каждого пользователя живёт в отдельной ячейке оперативной памяти приложения (структура Map по уникальному ID мессенджера) с TTL 30 минут. Контексты разных пользователей физически не пересекаются — это разные ключи в Map.

Контекст никогда не записывается на диск и стирается автоматически:

• через 30 минут после последнего сообщения от пользователя;
• при перезапуске сервиса;
• при блокировке пользователем бота.

Это сильнее, чем persisted‑хранилища (Redis с RDB/AOF, отдельная база): у нас восстановить контекст из бэкапа невозможно — бэкапа просто нет.

Шифрование на уровне диска

Шифрование at‑rest реализуется на уровне хост‑системы или провайдера: LUKS / dm‑crypt для bare‑metal развёртываний, шифрование облачного тома для cloud. Конкретный механизм согласовывается на этапе внедрения и фиксируется в техническом приложении к договору.

На уровне приложения дополнительного шифрования полей нет — потому что нечего шифровать (см. предыдущий пункт).

Журналирование запросов

Каждый запрос пользователя к ИИ‑ассистенту фиксируется в журнале на уровне приложения:

• текст запроса;
• распознанное намерение (intent: «расписание», «преподаватель», «помещение»…);
• сущность (группа/преподаватель/аудитория);
• ответ бота;
• timestamp.

Журнал нужен для разбора ошибок, обучения моделей и метрик качества ответов. Автоматически удаляется через 90 дней (MongoDB TTL index). Срок хранения настраивается в конфигурации учреждения.

Дополнительно ведётся короткая телеметрия каскада роутеров (как именно бот выбрал маршрут обработки запроса) — она удаляется через 30 дней.

Удаление при блокировке бота

Когда пользователь блокирует бота или удаляет аккаунт в мессенджере (бот получает 403 или 404 от платформы), фоновая служба помечает этого пользователя как unreachable и полностью стирает его данные из всех коллекций: настройки, журнал запросов, метки активности, привязки к группе. Очистка запускается дважды в месяц автоматически.

Юридическая модель: кто оператор ПД, и почему это не мы

В классической модели 152‑ФЗ есть «оператор персональных данных» — тот, кто собирает и обрабатывает информацию, по которой можно идентифицировать конкретного человека. У связки «CampusHub + учебное заведение» эта роль распределена так:

1. Оператор ПД — учебное заведение. Школа, колледж или вуз собирает ФИО, паспортные данные, контакты учеников и родителей при поступлении. У учреждения уже есть согласие на обработку этих данных — оно подписывается при зачислении и покрывает всю работу с информацией о человеке в рамках учебного процесса.
2. CampusHub оператором персональных данных не является. Мы не собираем у пользователей ФИО, паспортные данные, оценки или другую идентифицирующую информацию. Внутренний идентификатор мессенджера и привязка к группе — это не категория персональных данных. Поэтому отдельное уведомление в РКН и отдельное согласие пользователя именно с CampusHub — не требуются.
3. То что мы технически обрабатываем — это публичные данные. Расписание со страницы вашего сайта, контакты учебной части из публичных регламентов, тексты регламентов и положений — это информация, к которой и так есть открытый доступ. Мы её индексируем и подаём в чат — не более.
4. Политика конфиденциальности. На сайте CampusHub опубликована политика обработки информации — что мы делаем с данными мессенджера, как технически храним и как защищаем.
5. Хранение данных в РФ. Бэкенд и база данных размещаются в РФ. ИИ‑классификация запросов — через российского провайдера AI‑инфраструктуры. Возможна полностью offline‑конфигурация через локальную модель (Ollama) для air‑gapped развёртываний — ни один запрос не выходит за периметр учреждения.

Если IT‑отдел учреждения хочет дополнительно зафиксировать наш статус технического подрядчика — заключаем договор, где явно прописано: какие данные мы получаем со стороны учреждения, как технически храним, что не передаём третьим лицам и в каких случаях удаляем.

Сроки хранения — таблица

Что если ваше учреждение хочет хранить меньше — или больше

Стандартная конфигурация — это минимум, который нужен боту, чтобы работать. Но у вас могут быть свои требования:

• Хотите хранить меньше. Можно настроить бота так, чтобы он не помнил даже связку «пользователь → группа» — каждый раз заново спрашивал «вы из какой группы?». Это менее удобно, но максимально безопасно. Особенно для частных школ с детьми младшего возраста.
• Хотите полностью оффлайн. Air‑gapped развёртывание с локальной LLM (Ollama) в вашей инфраструктуре — ни один запрос не выходит за периметр учреждения. Все компоненты на ваших серверах, никаких облачных API.
• Хотите хранить больше. Например, чтобы бот присылал персональные напоминания о домашних заданиях. Это требует более глубокой интеграции с вашими системами и расширенного согласия. Возможно — обсуждаем индивидуально.

Что в итоге

Безопасность школьных и вузовских ботов — это вопрос архитектуры, а не маркетингового лозунга. У CampusHub архитектура заточена под «минимум данных, обезличенные идентификаторы, короткие сроки хранения, российское размещение». А юридически — мы вообще не обрабатываем напрямую идентифицирующие ПД, поэтому претензий со стороны РКН к самому факту использования бота не возникает.

Никаких ФИО, никаких оценок, никакой долгосрочной истории диалогов. Бот знает только то, что нужно для ответа на «что у меня сегодня» — и через 30 минут забывает.

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