EU KIDS Act: как новые требования Еврокомиссии изменят архитектуру цифровых продуктов

Документ обязывает разработчиков проектировать архитектуру с предустановленным режимом повышенной конфиденциальности для пользователей до 15 лет. Узкое место — слой приватности: он перестаёт быть опцией и превращается в инвариант платформы.

Архитектурный сдвиг

Требование «безопасности по умолчанию» — не фича, а системное ограничение. Оно диктует перестройку нескольких слоёв стека одновременно.

• Идентификация возраста. Проверка переносится на edge или API gateway. Без отдельного сервиса с аудит-трейлом имплементация не пройдёт архитектурное ревью.
• Политики данных. Минимизация и маскирование PII несовершеннолетних в логах, аналитике, ML-датасетах. Это затрагивает схемы DWH, feature stores и процессы data governance.
• ИИ-компоненты. Диалоговые сервисы на базе LLM попадают в скоуп наравне с соцсетями. Нужны guardrails на уровне системных промптов и выходной фильтрации.
• Конфигурация продукта. Закрытые профили, отключённый публичный discovery, ограниченные DM — baseline, а не toggle в пользовательских настройках.

Узкие места текущего стека

Большинство платформ заточены под opt-in приватность. Переход на by-default ломает несколько устоявшихся паттернов.

• Рекомендательные системы. Обучение на полностью маскированных данных сегмента до 15 лет снижает качество ранжирования. Нужна отдельная ветка пайплайна.
• Аналитика и метрики. Часть событий для несовершеннолетних становится недопустимой к сбору. Событийная схема требует пересборки.
• A/B-тестирование. Эксперименты над сегментом до 15 лет требуют дополнительных гейтов. Это удлиняет цикл релиза в CI/CD.
• Межсервисные контракты. Спецификации gRPC и OpenAPI должны декларировать возрастной класс получателя. Изменение контракта — breaking change для потребителей.

Что отслеживать

• Финальный текст законопроекта и сроки вступления в силу. На текущем этапе это проект.
• Юрисдикция: распространяется ли требование на платформы с EU-резидентами независимо от места регистрации вендора.
• Санкции и механизм сертификации. От этого зависит, нужен ли отдельный compliance pipeline.
• Концентрация рынка верификации возраста. Vendor lock-in на двух-трёх поставщиков снижает переключаемость стека.

Чек-лист для архитектурного комитета

• Определить скоуп продуктов: попадают ли сервисы под определение соцсети, видеохостинга, ИИ-диалога.
• Картировать потоки данных для сегмента до 15 лет: что собирается, где хранится, кто имеет доступ.
• Сверить текущие настройки приватности по умолчанию с требованиями проекта.
• Заложить в бэклог age-gating на edge и расширение audit log.
• Зафиксировать требования к провайдерам верификации возраста в RFP для защиты от vendor lock-in.
• Выделить отдельную ветку рекомендательных моделей под сегмент несовершеннолетних.