Комплаенс как системный анализ: как формулировать требования по 152-ФЗ, ФСТЭК и КИИ, чтобы их можно было реализовать в highload-системе

Я системный аналитик, и моя основная задача — перевести 152-ФЗ, Приказ ФСТЭК №117 и 187-ФЗ в метрики, критерии приёмки и зоны ответственности команд. Без этого разработка встанет, а регулятор не примет систему. Расскажу на трёх живых примерах, как я это делала. Первый — локализация данных. Мы разложили «хранить ПДн в РФ» на NFR. На реализации выяснилось, что синхронная отправка во внешний сервис добавляет 300 мс латентности. Я переписала критерий: ответ пользователю не ждёт внешний сервис, достаточно подтверждения из РФ-БД. Формулировка изменилась — и система заработала. Второй — мониторинг ИИ по ФСТЭК. Мы спроектировали требования к логам для LLM. Объём логов вырос в 10 раз — исходные требования по retention пришлось пересобрать с компрессией и выгрузкой в холодное хранилище. Ещё одна правка: гардрейлы должны проверять не только вход, но и выход модели. Третий — согласия на обучение моделей. Мы сформулировали сценарии: базовое согласие, отдельное согласие на обучение, отзыв согласия. На практике удаление данных из модели невозможно. Я переформулировала требование: дообучение идёт только на данных с активным согласием, исторические данные остаются в модели. Регулятор принял этот компромисс. Главный вывод: качественные требования спасают проект. Нельзя передать закон разработчикам — нужно превратить его в проверяемые условия. И честно фиксировать технические ограничения как согласованные риски.