Как измерить качество ИИ-системы: ГОСТ Р 72664-2026 и практический аудит

С 1 августа 2026 года действует ГОСТ Р 72664-2026 «Программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модель качества для систем искусственного интеллекта». Для бизнеса это не очередной общий перечень принципов, а рабочая основа для проверки конкретной ИИ-системы.

Что именно изменилось

Стандарт утвержден приказом Росстандарта от 13 мая 2026 года № 482-ст и соответствует ИСО/МЭК 25059:2023. Он относится к семейству SQuaRE — стандартам о требованиях и оценке качества систем и программного обеспечения.

Практическое значение этой модели хорошо видно на обычной приемке. Формулировки вроде «ответ должен быть релевантным», «модель должна быть устойчивой» или «ошибки недопустимы» звучат убедительно, но почти бесполезны в споре. Нельзя однозначно понять, выполнено ли требование, на каких данных это проверяли и что обязан исправить поставщик.

ГОСТ предлагает сначала описать значимые характеристики качества, затем связать их с требованиями к системе. За счет этого разговор о качестве перестает быть спором впечатлений между заказчиком, разработчиком и юридической службой.

Почему одного ГОСТ Р ИСО/МЭК 42001-2024 недостаточно

ГОСТ Р ИСО/МЭК 42001-2024 отвечает прежде всего на управленческий вопрос: знает ли организация, какие ИИ-системы она использует, кто за них отвечает, как оцениваются риски и что происходит после инцидента. Это каркас системы менеджмента ИИ.

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

Поэтому два стандарта полезно применять вместе: ГОСТ 42001 выстраивает управление, а ГОСТ 72664 помогает сформулировать и проверить требования к качеству самой системы.

Как выглядит аудит качества ИИ-системы

1. Зафиксировать границы системы

Сначала нужно договориться, что именно проверяется. Объектом может быть собственная модель, внешний API, RAG-контур, агент с доступом к корпоративным системам или вся цепочка сразу. Если оценить только модель и оставить за периметром поиск, промпты, фильтры и действия агента, результат аудита мало скажет о качестве продукта, который видит пользователь.

2. Описать назначение и цену ошибки

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

3. Перевести свойства в проверяемые требования

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

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

4. Собрать воспроизводимые тесты

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

5. Проверить эксплуатационный контекст

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

6. Настроить повторную оценку

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

Пример: AI-ассистент службы поддержки

Предположим, ассистент отвечает клиентам по тарифам и возвратам. Требование «давать корректные ответы» слишком широкое. Рабочая карточка качества разделит его на несколько проверок:

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

Такой протокол позволяет увидеть не только среднюю долю верных ответов, но и качество там, где ошибка создает юридический или финансовый риск.

Как связать аудит с договором

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

В договоре или приложении к нему стоит закрепить:

1. назначение системы и согласованные ограничения использования;
2. метрики, контрольные данные, методику испытаний и порог приемки;
3. классификацию критичных и некритичных отклонений;
4. порядок повторного тестирования после обновлений;
5. обязанность сообщать об изменении модели, провайдера или значимых компонентов;
6. сроки устранения дефектов и последствия недостижения согласованного уровня качества;
7. доступ заказчика к отчетам, журналам и другим доказательствам проверки.

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

Где заканчивается техническая оценка

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

Поэтому полноценная проверка обычно состоит из нескольких слоев:

Обязателен ли ГОСТ Р 72664-2026

По общему правилу документы национальной системы стандартизации применяются добровольно, если законодательство не устанавливает иное. Это прямо следует из статьи 26 Федерального закона от 29 июня 2015 года № 162-ФЗ.

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

Поэтому неверно говорить, что с 1 августа 2026 года каждая ИИ-система в России обязана соответствовать ГОСТ Р 72664-2026. Но и считать стандарт необязательной теорией не стоит: согласованная модель качества может стать основой приемки, аудита поставщика и доказательной базы при споре.

Что подготовить компании сейчас

Начать можно с трех документов.

1. Реестр ИИ-систем. Какие модели и сервисы используются, для чего, на каких данных и кто отвечает за результат.
2. Карточка качества. Значимые свойства системы, критерии, метрики, допустимые отклонения и условия передачи решения человеку.
3. Протокол проверки. Контрольные сценарии, версии компонентов, результаты, замечания, корректирующие меры и дата следующего теста.

Если система поставляется внешним подрядчиком, карточку качества нужно сопоставить с договором и SLA. Для собственной разработки ее лучше утверждать до релиза, пока требования еще можно учесть в архитектуре и процессе тестирования.

Вывод

ГОСТ Р 72664-2026 дает российским компаниям общий язык для разговора о качестве ИИ. Его ценность не в формальной ссылке на стандарт, а в дисциплине: определить границы системы, выбрать значимые свойства, установить пороги, проверить их воспроизводимым способом и связать результат с управленческими и договорными решениями.

Команда «ИИ Право» проводит правовой и организационный аудит ИИ-систем. Мы инвентаризируем сценарии использования ИИ, проверяем требования к качеству, данные, роли, воздействие, прозрачность и договоры с поставщиками. Результат — карта рисков с приоритетами, доказательствами и планом корректирующих мер.