Безопасное применение ИИ в ГИС: требования № 117 к контролю запросов и ответов

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

Что № 117 меняет для ИИ в ГИС

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

Первое – каждый запрос к модели и каждый её ответ подлежат регистрации и анализу. Оператор обязан фиксировать, кто обратился, какие данные ушли в контекст и что вернулось пользователю. Без журнала вы не докажете на проверке, что персональные данные граждан не утекли в обучающую выборку внешнего сервиса.

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

Контроль запросов и ответов на практике

Требования № 117 ложатся на конкретный технический контур. Минимальный набор, который мы закладываем в проекты:

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

Этот контур не отменяет базовых мер. Уязвимости в самой обвязке ИИ закрываются в тех же сроках устранения уязвимостей, что и остальные компоненты ГИС, – отдельного послабления для ИИ-сервисов приказ не делает.

Как встроить это без срыва сроков

Главная ошибка – пытаться приделать контроль к готовой модели в последний момент. Слой проверки запросов и ответов проектируется вместе с самим ИИ-сервисом, иначе он становится бутылочным горлышком и его отключают «на время». Фильтры ввода-вывода, изоляция контекста и журналирование закладываются в один проект с прикладной логикой при разработке интеллектуальных систем, а не дорабатываются после.

Тем, кто уже выстраивает соответствие № 117 по остальным направлениям, удобно встроить ИИ-контур в общий план – мы описывали такой подход в разборе спринта по приказу № 117. Так контроль модели не выпадает из общей картины защищённости.

Вывод

№ 117 не запрещает ИИ в ГИС – он требует сделать его прозрачным. Контролируемый запрос, проверенный ответ, полный журнал – этого достаточно, чтобы языковая модель стала легитимным компонентом государственной системы, а не теневым сервисом, который держат на свой страх и риск. Закладывайте контроль в архитектуру с первого дня, и проверка пройдёт без сюрпризов.