Приказ ФСТЭК № 117 действует с 1 марта 2026 года и заменил приказ № 17 от 2013 года. Для государственных информационных систем он впервые вводит прямые требования к ИИ-компонентам: контроль достоверности ответов нейросетей, фильтрацию пользовательских запросов и запрет на облачные ИИ-сервисы для гостайны и информации ограниченного доступа. Методические документы пока не закрывают всю технику реализации, поэтому аудит превращается в задачу: собрать доказательства того, что модель работает предсказуемо и проверяемо. Ниже – что конкретно проверять и какие артефакты готовить.

Что доказывает аудит по № 117

Аудитор и заказчик хотят видеть не декларацию, а трассируемую цепочку. Минимальный пакет доказательств включает четыре блока.

  • Происхождение модели и данных. Откуда веса, на каких датасетах шло обучение и дообучение, где физически находятся данные. Для суверенных моделей все стадии разработки и обучения должны проходить на территории РФ силами российских лиц – это нужно подтвердить документально, а не на словах.
  • Контур обработки. Архитектурная схема, доказывающая, что данные ограниченного доступа не уходят в облачные сервисы. Сетевая сегментация, логи, точки фильтрации запросов.
  • Контроль галлюцинаций. Метрики достоверности на эталонной выборке, пороги отсечения, поведение системы при низкой уверенности – отказ, эскалация на человека или пометка ответа.
  • Журналирование. Неизменяемые логи входов, выходов и версий модели, по которым можно восстановить любое решение постфактум.

Без этих артефактов аудит превращается в спор о намерениях. С ними – в проверку фактов.

Объяснимость как инженерное требование

Объяснимость для регулятора и для заказчика – это разные глубины. Регулятору достаточно показать, что у каждого автоматического решения есть журнал, версия модели и человек, отвечающий за результат. Заказчику в госсекторе нужно больше: почему система отклонила заявку, на какие признаки она опиралась, можно ли оспорить вывод.

Мы закладываем объяснимость на этапе проектирования, а не прикручиваем после. Для классических моделей это атрибуция признаков и понятные правила отсечения. Для больших языковых моделей – фиксация промптов, источников в RAG-контуре и обязательная ссылка на документ-первоисточник в каждом ответе. Такой подход к проектированию ИИ-агентов мы разбирали на примере ИИ-агента в продажах: агент, который не может показать основание ответа, в регулируемом контуре нежизнеспособен.

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

Как мы проводим аудит и доводим систему

Onepoint работает в два шага: сначала диагностика разрыва между текущим состоянием ИИ-системы и требованиями № 117, затем дорожная карта устранения. Мы инвентаризируем модели и потоки данных, тестируем устойчивость к галлюцинациям и инъекциям в промпт, проверяем контур на утечки, оформляем пакет доказательной документации для регулятора. Если объяснимости недостаёт на уровне архитектуры, мы перепроектируем модель и пайплайн под доказуемые решения, а не маскируем проблему отчётами.

Вывод

№ 117 не запрещает ИИ в госсекторе – он требует доказуемости. Выигрывают те, кто относится к объяснимости и журналированию как к инженерным требованиям с первого дня, а не как к нагрузке перед проверкой. Аудит при таком подходе подтверждает то, что уже встроено в систему, и не превращается в аврал.