WhyBee отвечает на вопросы детей 3–14 лет. Мы строим продукт на трёх принципах: безопасность раньше ответа, родитель — заказчик, ребёнок — пользователь и минимизация данных. Эта страница честно и проверяемо описывает, какие данные и куда уходят.
AI-disclosure.
Ответы формирует искусственный интеллект (модель Claude от Anthropic), а не человек, и ИИ может ошибаться. В детском интерфейсе ребёнок узнаёт об этом на понятном для его возраста языке; безопасному использованию ИИ посвящены отдельные детские обучающие материалы.
Это исчерпывающий allow-list. Он не «обещание в тексте»: список закреплён кодом и проверяется тестами (ниже раздел «Как это закреплено»).
Allow-list держится архитектурой, а не договорённостью. Любой может проверить исходники:
backend/internal/llm/imports_test.go
backend/internal/transparency/binding_test.go
backend/Makefile
backend/Makefile
.github/workflows/ci.yml
Сверх этого: узкая сигнатура запроса к LLM (§5) не несёт объекта ребёнка, и это закреплено binding-тестом — любое новое поле в запросе к модели обязано быть объявлено в allow-list «уходит» или помечено транспортным, иначе CI краснеет. Сама эта страница тоже покрыта тестами, которые валят CI, если её allow-list разойдётся с arch-тестом или CI-гардами. Страница обязана оставаться честной по построению.
Третьи стороны, обрабатывающие данные, связанные с ребёнком.
| Субпроцессор | Роль | Получает | Не получает | Хранение |
|---|---|---|---|---|
| Anthropic PBC | Генерация ответов (LLM Claude) и постмодерация. | текст вопроса, возрастную полосу, ходы беседы, темы интересов, описания родительских стоп-тем; на независимую пост-модерацию — сгенерированный ответ и его части, режим ответа и флаг ранее заблокированных вопросов беседы; для недельного письма — локаль, темы и счётчик вопросов. | имя, год рождения, e-mail, идентификаторы, голос. | инпуты и аутпуты интерактивного API (вопрос-ответ и модерация) — до 30 дней (формальная политика Anthropic; фактический дефолт снижен до 7 дней с 2025-09-14, финальная сверка — по подписанному DPA); результаты Message Batches для недельного дайджеста (только обезличенные агрегаты — темы и счётчик, без текста вопросов) — удаляем сразу после забора (верхняя граница — до 29 дней). Ничего не используется для обучения (коммерческие условия); заключён DPA. Исключение поверх этих окон: контент, помеченный автоматическими trust&safety-системами Anthropic (например заблокированный небезопасный вопрос), может храниться до 2 лет, а классификационные скоры — до 7 лет; это применяется поверх ZDR/DPA и вне нашего контроля. ZDR не требуется: PII не попадает в промпты by design — поля выбирает код по allow-list §10.1. Одно уточнение к «by design»: тема интересов — единственное поле, которое формулирует модель, а не код. Ей запрещено называть имя частного лица (KQA-057), и при недоступном извлечении тема — «misc», а не слово из вопроса; но этот запрет живёт в промпте, а не в проверке кода, поэтому для темы «by design» означает правило модели. Для недельного письма это и есть весь текст, который уезжает: текста вопроса там нет. Covered Models Anthropic (например Fable 5 / Mythos 5) требуют обязательной 30-дневной ретенции без ZDR — мы на них не работаем. |
| Amazon Web Services (Amazon SES) | Доставка родительских уведомлений и писем аутентификации (KQA-213): код подтверждения адреса и код восстановления доступа физически уходят через этого же вендора. | e-mail родителя, категорию события, счётчики, темы интересов и текст недельного письма (рассказ, собранный из тем и счётчиков). Отдельно — письма аутентификации: e-mail родителя и одноразовый код, подтверждающий адрес при регистрации или восстанавливающий доступ (KQA-213). Эти письма отправляет контур Supabase, но через этого же вендора доставки. | текст вопроса и текст ответа, идентификатор ребёнка и его возрастную полосу — продуктовая почта их не несёт, родитель видит их только в приложении, за auth. Исключение — переписка с поддержкой: наши ответы уходят через этого же вендора, поэтому написанное родителем в этой переписке он видит. | письма уходят из региона eu-north-1 (Стокгольм) — доставка обрабатывается в ЕС. Адрес, на котором доставка отбита или на который пришла жалоба на спам, попадает в suppression list SES и хранится там до явного удаления: у этого списка нет срока давности — поэтому удаление аккаунта отдельно требует у SES убрать оттуда адрес (KQA-156). Выгрузка событий доставки (event publishing) не включена, поэтому SES не отдаёт логи доставки ни нам, ни третьим сторонам. Отдельная подпись DPA не требуется и не существует: AWS Service Terms §1.14.1 включают Data Processing Addendum в сами условия сервиса. канал шифруется принудительно: у нашего configuration set политика TLS Required, то есть письмо не будет отправлено вовсе, если сервер получателя не даёт защищённое соединение (дефолт SES — оппортунистический TLS, при котором письмо ушло бы открытым текстом). Удаление аккаунта доходит до этого списка: вместе с данными в нашей базе мы просим SES удалить адрес из suppression list, и запрос не выполняется один раз — при сбое он повторяется с нарастающими интервалами на протяжении недель (KQA-156). Оговорка честности: сам список — не наш, поэтому подтверждением служит ответ SES «адреса больше нет», а не наша запись; по той же причине мы не обещаем гарантированный успех — если SES так и не подтвердит удаление, повторы заканчиваются, а сбой попадает в наш журнал ошибок и разбирается вручную по ран-буку деплоя. Тема — короткий ярлык, который формулирует модель; ей запрещено называть имя частного лица — вместо «Александра» она обязана вернуть то, о чём вопрос («слёзы»), а если ничего другого в вопросе нет — «misc» (KQA-057). Недоступное извлечение больше не берёт слово из вопроса: фолбэк отдаёт «misc», то есть теряет запись карты интересов, а не публикует слово ребёнка (§4.3). Оговорка честности: запрет живёт в промпте, а не в валидаторе — отличить имя сестры от «Марса» может только модель, читающая вопрос, поэтому остаточный риск ошибки модели остаётся. Имена публичных и вымышленных фигур, места и планеты запретом не покрыты: это настоящие интересы, ради которых карта и существует. |
| Porkbun | Приём почты на адреса домена: письмо пересылается в наш ящик. | письмо, пришедшее на адреса домена: обратный адрес, тему, текст и вложения. Сюда же приходит ответ родителя на недельное письмо. | доступа к нашей базе: тексты вопросов и ответов, темы интересов, год рождения и идентификаторы ребёнка туда не уходят — вендор видит то, что написано в самом письме. Исходящая почта продукта — уведомления и недельные письма — идёт через вендора доставки, мимо пересылки. | срок хранения пересылаемой почты провайдер не публикует — поэтому мы его и не обещаем. адрес поддержки — обычная электронная почта: письмо идёт по общим правилам e-mail, а не через защищённый канал приложения. |
| Google (Gmail) | Почтовый ящик, в который приходит пересланная почта поддержки. | то же письмо целиком — обратный адрес, тему, текст и вложения. | доступа к нашей базе: данные ребёнка попадают к нему только в том объёме, в каком родитель назвал их в письме сам. Продуктовая почта — уведомления и недельные письма — через этот ящик не проходит. | переписка лежит в ящике, пока мы её не удалим; после удаления провайдер заявляет около 2 месяцев на полное стирание из активных систем и до 6 месяцев жизни в зашифрованных резервных копиях. наши ответы отправляются из этого же ящика; сам ответ уходит через того же вендора доставки, что и продуктовая почта. |
| Supabase | Аутентификация родителя (вход, восстановление пароля). | e-mail родителя и его учётные данные (пароль хранится хешированным на стороне Supabase), идентификатор auth-пользователя, а также одноразовый код подтверждения адреса и восстановления доступа — его выпускает и хранит Supabase, а доставляет наш почтовый вендор (KQA-213). | данные детей — имя, год рождения, тексты вопросов и ответов, темы интересов: они живут в нашей базе (управляемый Postgres, следующая запись), а не в Supabase. Наш бэкенд читает из токена только идентификатор родителя. | учётная запись живёт, пока существует аккаунт: удаление аккаунта (KQA-014) сносит наши данные в одной транзакции и затем отдельным админ-вызовом удаляет auth-пользователя. оговорка честности: удаление auth-пользователя делает служебный ключ окружения. Если он не настроен, наши данные всё равно удаляются полностью, а запись в Supabase остаётся — это открытый долг KQA-169, а не обещание, и до его закрытия мы не утверждаем, что e-mail исчезает у этого субпроцессора при каждом удалении. Проекты боевого и тестового окружений раздельны, поэтому тестовые аккаунты не смешиваются с настоящими. Письма этого контура — код подтверждения адреса и код восстановления доступа — Supabase отправляет не сам: с 2026-08-02 он настроен на нашего вендора доставки, Amazon Web Services (Amazon SES), то есть код доступа физически проходит через него. |
| Railway | Хостинг бэкенда и управляемый PostgreSQL. | всё, что хранит продукт: профили детей (имя, год рождения), тексты вопросов и ответов до обезличивания, темы интересов, события активности, состояние подписки. Это инфраструктура, на которой стоит сама база, — не отдельный получатель выборки. | отдельной выгрузки не делается: доступ ограничен нашим сервисом и административным доступом команды. | по срокам самого продукта: тексты обезличиваются по окну хранения, остальное удаляется вместе с профилем или аккаунтом. Резервные копии платформы живут по её собственным срокам. перечислен как субпроцессор именно потому, что данные детей физически лежат у него, а не потому что мы что-то ему отправляем. Окружения (integration / staging / production) разделены; боевые данные не попадают в тестовые. |
| RevenueCat | Учёт подписки: валидация покупок и вебхуки о её состоянии. | идентификатор родителя (тот же UUID, что у нас) и события подписки — покупка, продление, отмена, истечение, перенос. | имя и год рождения ребёнка, тексты вопросов и ответов, темы интересов, e-mail родителя. Подписка привязана к родителю как к плательщику, о детях сервис не знает ничего. | события подписки хранятся у сервиса по его условиям; на нашей стороне остаётся производное состояние доступа и журнал событий, который удаляется вместе с аккаунтом родителя. платёж проходит мимо нас: карту и платёжные данные принимает Apple (следующая запись), мы получаем только факт «подписка активна/неактивна». |
| Apple | Приём платежа за подписку и доставка уведомлений на устройство. | платёжные данные родителя — напрямую, средствами App Store: они не проходят через наш сервер и мы их не видим. Дополнительно — push-токен устройства и текст уведомления (см. запись «Apple (Apple Push Notification service)»). | имя и год рождения ребёнка, тексты вопросов и ответов, темы интересов. | по условиям App Store. перечислен отдельно от провайдера push, потому что это две разные роли одного вендора: платёж — обязательная часть подписки в приложении iOS, push — доставка уведомлений. Мы не можем ни выбрать другого платёжного посредника, ни увидеть данные карты. |
| Hugging Face | Публичное хранилище файлов голосовых моделей. | IP-адрес устройства и адрес запрошенного файла — в момент, когда приложение один раз скачивает файл нейронной модели озвучки. Запрос идёт с устройства напрямую, наш сервер в нём не участвует. | текст вопроса и текст ответа, имя и год рождения ребёнка, темы интересов, e-mail родителя — озвучка работает на устройстве, наружу для неё ничего не отправляется. | по условиям самого сервиса: это обычная загрузка публичного файла, аккаунта у нас там нет. перечислен не потому, что получает данные семьи, а потому что видит запрос конкретного устройства — и список субпроцессоров обещает быть исчерпывающим. Асимметрия, из-за которой запись появилась только сейчас: в политике этот вендор был назван с самого начала, а гвард сверял лишь одно направление (канон → политика) и молчал об обратном (KQA-178). |
| Apple (Apple Push Notification service) | Доставка push-уведомлений. | push-токен устройства и текст самого уведомления: для эскалации — статический шаблон-предупреждение (без имени ребёнка и без текста вопроса), для дайджеста — обобщённое «готов новый обзор» без тем и счётчиков. | текст вопроса и текст ответа, темы интересов, счётчики, идентификатор и возрастную полосу ребёнка — детальный дайджест родитель видит только в приложении, за auth. | уведомление хранится у Apple только до доставки на устройство: если оно выключено или офлайн, APNs держит ПОСЛЕДНЕЕ сообщение ограниченное время и отбрасывает его по истечении. Push-токен живёт у нас в `parent_devices`, удаляется вместе с семьёй (KQA-005) и снимается при выходе из аккаунта (KQA-052) — последнее по мере возможности: если запрос на снятие не прошёл (например, устройство офлайн), токен остаётся до следующей удачной попытки или до момента, когда на этом устройстве войдёт другой родитель и токен перепривяжется к нему. Отдельного соглашения на обработку не подписывается — условия APNs входят в Apple Developer Program License Agreement. push-токен, факт активности и текст обобщённого уведомления — данные, связанные с ребёнком, поэтому провайдер перечислен как субпроцессор. Android (FCM) остаётся schema-ready и в списке не назван: отправителя нет, и до его появления push-данных Google не получает. |
Продукт спроектирован под требования защиты данных детей (COPPA в США, GDPR-K в ЕС). Минимизация данных: о ребёнке мы храним только имя и год рождения; персональные данные не попадают в LLM-промпты by design.
Аутентифицируется только родитель. Точка согласия — регистрация первого ребёнка: без активного родительского согласия детские функции недоступны.
Честная оговорка: текущая чекбокс-аттестация согласия сама по себе не является verifiable parental consent по стандарту COPPA (FTC требует более строгих методов). Это осознанная MVP-заглушка; целевой метод — предмет юридического решения (R4). Мы не заявляем большего, чем реально закреплено.
Возрастную полосу задаёт родитель; отдельной верификации возраста ребёнка нет — это следствие минимизации данных, а не пробел. IP сознательно не фиксируется (сам по себе PII).
Редакции, проверенные при оценке допустимости детского сценария (R3). Указаны даты версий, которые мы читали.
GET /v1/export, не чаще раза в час.Никакой рекламной слежки: скрытых поведенческих профилей сверх карты интересов, которую родитель видит явно, нет.
Мы предоставляем детям уровневые обучающие материалы о безопасном использовании ИИ — прямо в детском интерфейсе: что такое ИИ-помощник, что он может ошибаться, что личные секреты рассказывать не нужно. Родительский гайд «как говорить с ребёнком про ИИ» готовится — в приложении его пока нет.