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 свідомо не фіксується (він сам є персональними даними).
Редакції, перевірені під час оцінки допустимості дитячого сценарію (R3). Зазначені дати версій, які ми читали.
GET /v1/export, не частіше разу на годину.Жодного рекламного стеження: прихованих поведінкових профілів понад карту інтересів, яку батьки бачать явно, немає.
Ми надаємо дітям рівневі навчальні матеріали про безпечне використання ШІ — просто в дитячому інтерфейсі: що таке ШІ-помічник, що він може помилятися, що особисті секрети розповідати не потрібно. Батьківський гайд «як говорити з дитиною про ШІ» готується — у застосунку його поки немає.