AI в разработке и управлении продуктом

Регулирование (штрафы, доверие пользователей). GDPR, AI Act — фазовый запуск с 2026. Ответственность на компании, но проверяют dev/PM (архитектура, логи, доки). Опрос: «Сталкивались ли вы с GDPR/AI Act?»

Принципы: законность, минимизация данных, ограничение цели, сроков хранения, безопасность. Какие поля в БД не должны храниться, Роль PM: фиксировать эти решения в требованиях.

Права доступа, исправления, удаления, ограничения и переноса данных; запрет чисто автоматизированных решений без человека. Требования к продукту: найти данные по пользователю, выгрузить, удалить. Для PM — учесть это в user stories; для dev — продумать API/скрипты.

Понятие AI-системы, риск-ориентированный подход: запрещённые, high-risk, ограниченные. Что такое high-risk (кредиты, HR, биометрия, критическая инфраструктура и др.) и почему финтех/HR/health особо уязвимы. Роли: provider, deployer, integrator и на ком ответственность.

Что требуется: управление рисками, качество данных, документация, логирование, human-in-the-loop, пост-мониторинг. Как это разбивается на задачи: модельный/фиче-реестр, логи решений, описания ограничений в документации, правила, когда нужен human review. PM — владелец процессов, dev — владельцы реализаций.
 

Какие артефакты обычно смотрят: data flow, описание систем, таблицы обработок (RoPA), DPIA, логирование, описания ролей и процессов. Почему отсутствие документации трактуется как отсутствие контроля. Как превратить доки в обычный deliverable спринта (Confluence/Notion + схемы + репозитории).

Ответы на вопросы. Action items:

1. составить список систем, где обрабатываются персональные данные;
2. понять, есть ли внутри high-risk AI-сценарии;
3. для одного ключевого сервиса — набросать data flow и проверить, реализуемы ли права пользователя.

Краткое повторение ключевой мысли: право — часть архитектуры, а не внешний «надзор».