ФСТЭК и безопасность ИИ: что теперь нужно защищать в ИИ‑системе

У российского бизнеса обычно две крайности в отношении безопасности ИИ. Первая: считать языковую модель обычным внешним сервисом и проверять только договор с поставщиком. Вторая: применять к нейросети весь набор классических требований информационной безопасности, не понимая, где именно возникает новый риск.

Методический документ ФСТЭК России от 12 апреля 2026 года предлагает более предметный подход. В нём появился отдельный пункт 3.18 «Обеспечение защиты информации при использовании искусственного интеллекта». Это уже не дискуссия о будущем регулировании: документ утверждён регулятором и используется в контуре требований, для которого предназначен.¹

Кому это обязательно

Сразу нужна юридическая граница. Пункт 3.18 нельзя читать как федеральный закон, который распространяется на каждый стартап, корпоративного помощника или сервис с подключённой языковой моделью. Методический документ детализирует меры защиты для определённого круга информационных систем и значимых объектов КИИ, в том числе в развитие приказа ФСТЭК России № 117, вступившего в силу 1 марта 2026 года.²

Для государственных информационных систем, систем органов и организаций, на которые распространяются эти требования, а также в применимых случаях для значимых объектов КИИ меры ФСТЭК нужно включать в проектирование и эксплуатацию. Для обычной коммерческой компании пункт 3.18 полезен как российская модель разумной осмотрительности: он показывает, какие активы и процессы регулятор считает значимыми. Поэтому первый вопрос компании звучит так: попадает ли наша система в регулируемый контур и какие положения применимы именно к ней.

Защищать нужно не только данные

Самое интересное в пункте 3.18 заключается в перечне объектов. Регулятор рассматривает систему ИИ как цепочку компонентов. На стадии разработки это инфраструктура разработки, входная модель, которая используется для получения или обучения выходной модели, наборы обучающих данных, выходная модель и её параметры, то есть веса, а также программное обеспечение, реализующее технологии ИИ. Отдельно названы ИИ‑агенты, API и системы фильтрации входных и выходных данных.

Это меняет постановку задачи для руководителей безопасности и разработки. Если компания говорит «мы защищаем ИИ», а в реестре активов есть только сервер и база данных, реального перечня ИИ-активов у неё нет. Корпоративный агент, который читает договоры, обращается к базе знаний и создаёт задачи в CRM, уязвим минимум в пяти точках: документ пользователя, поиск по базе знаний, модель, инструмент или API и итоговое действие агента.

Веса и обучающие данные

Для команды машинного обучения веса являются техническим артефактом. Для службы безопасности это объект, изменение которого меняет поведение системы. Если модель дообучается на корпоративных данных, недостаточно хранить её файл в реестре моделей. Нужны контроль версий и целостности, разграничение доступа, фиксация происхождения, порядок изменения и связь рабочей версии с результатами проверки.

Та же логика относится к входной модели. Компания может скачать открытую модель, дообучить её и считать результат собственным решением, но исходная модель остаётся звеном цепочки поставки. ФСТЭК ориентирует на анализ уязвимостей используемого программного обеспечения и их устранение, поэтому происхождение модели и управление зависимостями перестают быть внутренним делом разработчиков.

Для обучающих данных критична не только конфиденциальность, но и целостность. Отравление выборки, подмена источника, неконтролируемое добавление документов в базу знаний способны повлиять на результат модели без классического взлома. Реестр датасетов должен фиксировать владельца, назначение, доступ, версию, порядок обновления и проверку целостности.

Агенты и API

Современная языковая модель уже не просто отвечает текстом. Ей дают инструменты: отправить письмо, изменить карточку клиента, оформить возврат, вызвать платёжный API, запустить внутренний процесс. В такой архитектуре промпт не должен становиться системой управления полномочиями.

Права агента нужно ограничивать технически: перечень разрешённых инструментов, области доступа, лимиты операций, отдельные служебные учётные записи, подтверждение критичных действий, журнал вызовов. Это совпадает с логикой ФСТЭК: защищаются не абстрактный «ИИ», а реальные компоненты, через которые он взаимодействует с информацией и инфраструктурой.

Внешний поставщик модели

Чаще всего компания не разворачивает модель сама, а вызывает внешний API, и часть мер защиты физически выполняет подрядчик. Методический документ отдельно учитывает подрядные организации. Для бизнеса отсюда следует договорный вывод: фразы «поставщик обеспечивает безопасность сервиса» недостаточно.

В договоре стоит закрепить допустимые категории данных, место и режим обработки, доступ персонала поставщика, использование запросов для обучения, субподрядчиков, уведомление об инцидентах, журналирование, сроки хранения и удаления, порядок изменения модели или инфраструктуры и способ подтвердить выполнение мер защиты. Если поставщик не раскрывает ничего из этого, юридическая проблема становится архитектурной: возможно, определённые данные в такой сервис направлять нельзя.

Контрольная точка перед эксплуатацией

Превращать требования в ещё одну политику в PDF не стоит. Рабочая модель: проверка перед выводом в эксплуатацию, в которой у каждой команды есть свой проверяемый результат.

Продуктовая команда описывает сценарий и данные. Команда машинного обучения фиксирует модель, версию, веса и происхождение. Служба безопасности строит модель угроз и проверяет уязвимости, доступ, API и журналирование. Юрист квалифицирует данные, договоры и применимость обязательных требований. Для внешнего поставщика проводится отдельная оценка. После этого принимается решение о допуске конкретной конфигурации. Замена модели, адреса сервиса, набора инструментов агента или существенное изменение датасета запускают повторную оценку, иначе через три месяца компания эксплуатирует уже другую систему.

Практический вывод

Российское регулирование ИИ становится техническим. Пункт 3.18 интересен тем, что вместо общей формулы «обеспечить безопасность» в нём появились конкретные компоненты, которые нужно контролировать. Для компаний из регулируемого контура это вопрос соответствия требованиям. Для остальных это повод проверить, нет ли в компании ИИ‑системы, которая существует только в презентации, а её веса, датасеты, API и полномочия агентов живут без владельца и контроля.

Начать можно с инвентаризации всех сценариев применения ИИ, включая подключённые командами самостоятельно. Затем определить регулируемые системы и данные, составить карту ИИ-активов и связать каждый актив с угрозами и мерами защиты. Внутренние документы и договоры стоит оформлять после этого: такая последовательность даёт больше пользы, чем попытка начать с универсальной политики.