- 1ГОСТ Р 72664-2026 действует с 1 августа 2026 года и описывает модель качества ИИ-систем. Его можно использовать для определения и оценки требований к продукту.
- 2Качество конкретной системы и управление ИИ в организации — разные объекты проверки. Наличие политики не доказывает, что модель решает рабочую задачу.
- 3До приёмки согласуйте сценарии, критерии, порядок испытаний и реакцию на ошибки. Приведённые ниже примеры — практические предложения, а не дословные требования ГОСТ.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Что даёт стандарт качества
Росстандарт утвердил ГОСТ Р 72664-2026 приказом от 13 мая 2026 года № 482-ст. Он введён в действие 1 августа 2026 года. Модель качества предназначена для определения, измерения и оценки свойств ИИ-систем, а также их сопоставления с требованиями. Это основа для предметного разговора о результате работы продукта.
Вместо условия «модель должна отвечать хорошо» заказчик и разработчик договариваются, что означает приемлемый результат в конкретном процессе. Для помощника юриста важны достоверность ссылки и сохранение смысла документа. Для службы поддержки — правильное решение обращения. Одинаковая средняя оценка может скрывать совершенно разные последствия ошибок.
Использование стандарта предполагает работу с его текстом и выбранной методикой проверки. Примеры в этой статье помогают организовать аудит, но не заменяют перечень характеристик ГОСТ и не подтверждают соответствие продукта всему стандарту.
Отделите качество продукта от системы управления
ГОСТ Р ИСО/МЭК 42001-2024 касается системы менеджмента ИИ в организации. Он действует с 1 января 2025 года. Его предмет — создание и поддержание управления, тогда как проверка качества обращена к свойствам конкретной системы и её рабочему назначению.
Компания может назначить владельца ИИ, описать роли и утвердить порядок изменений. При этом помощник всё ещё способен давать неверные ответы. И наоборот: удачные испытания модели не показывают, кто будет реагировать на ухудшение после обновления. Поэтому результаты двух проверок сопоставляют, а одну не подменяют другой.
Практический вопрос на встрече с командой: кто отвечает за критерий качества и кто вправе остановить функцию, если критерий перестал выполняться? Если ответа нет, даже хороший отчёт об испытаниях трудно использовать при эксплуатации.
Определите, что именно проходит испытания
Объектом может быть модель, помощник с поиском по документам или агент, вызывающий инструменты. Для приёмки полезно описать всю систему: источники данных, настройки, доступные действия и пользователя. Испытание одной модели не охватывает ошибки поиска, интерфейса или внешнего сервиса.
Условный пример: модель правильно отвечает по найденному фрагменту, но поиск извлекает отменённую редакцию документа. Система выдаёт неверный совет, хотя оценка генерации выглядит высокой. Проверку следует построить так, чтобы видеть и промежуточные результаты, и ответ, который получает пользователь.
Зафиксируйте версию модели и корпуса, режим работы и ограничения назначения. Помощник, создающий черновик для сотрудника, и публичный сервис, выдающий готовый результат клиенту, требуют разной оценки последствий. Границы использования должны совпадать с тем, как продукт фактически применяется.
Свяжите критерии с последствиями ошибок
Составьте перечень рабочих сценариев и недопустимых результатов. Полезно отдельно учитывать ошибочную ссылку, потерю существенного условия, ответ без достаточных данных и неверное действие инструмента. Это примеры критериев для проекта, а не обязательная классификация из ГОСТ.
Для каждого критерия определите способ проверки и правило принятия решения. Иногда важна доля правильных ответов, иногда — отсутствие определённой опасной ошибки. Один общий процент не объясняет, можно ли запускать функцию, если большинство справочных вопросов решено верно, но в спорном обращении система совершает недопустимое действие.
Отдельно проверьте поведение при неопределённости. Если данных недостаточно, результатом может быть уточнение, отказ от ответа или передача сотруднику. Такой исход следует оценивать по назначению системы: он может быть правильным завершением сценария, а не недостатком производительности.
Сделайте проверку воспроизводимой
Набор примеров должен отражать реальные вопросы и условия эксплуатации. Наряду с обычными ситуациями включите опечатки, неполные документы, противоречивые источники и нестандартные формулировки. Сохраните входные данные, ожидаемый результат и объяснение оценки, чтобы другой проверяющий мог повторить работу.
Не меняйте правила оценивания после просмотра результата, чтобы искусственно улучшить показатель. Спорные ответы разбирайте по заранее принятому порядку. Если вывод зависит от экспертной оценки, укажите, кто её выполнял и как разрешались разногласия.
Краткий итог испытаний должен показывать версию продукта, проверенные сценарии, ограничения и обнаруженные ошибки. Решение о запуске связывают с этим итогом. Презентация нескольких удачных примеров не заменяет сведения, позволяющие оценить риск использования.
Закрепите критерии в приёмке и контролируйте изменения
В техническом задании стоит связать требования с методикой испытаний, доступными сведениями и порядком устранения отклонений. Тогда заказчик сможет проверить результат, а исполнитель — понять условия приёмки. Ссылка на номер ГОСТ без объёма применения и процедуры может оставить сторонам разные представления об обещанном качестве.
После обновления модели, индекса или инструментов оценка может измениться. Определите, какие изменения требуют повторных испытаний, кто отслеживает рабочие ошибки и как вернуть прежнюю версию. Проверка после запуска нужна не только при полном изменении архитектуры: небольшой внешний апдейт иногда меняет поведение важного сценария.
Проверьте обязательность и пределы заявлений
Статья 26 Закона № 162-ФЗ устанавливает добровольное применение документов национальной системы стандартизации, если законодательством не предусмотрено иное. Она также регулирует обязательность национального стандарта для изготовителя или исполнителя, публично заявившего о соответствии продукции. Поэтому рекламное обещание соответствия требует отдельной проверки.
Оценка выбранных сценариев ещё не означает соответствия всему ГОСТ. В отчёте и маркетинге указывайте действительный объём работы. Техническое качество также не подтверждает законность обработки персональных данных, права на документы или допустимость автоматизированного решения.
Результатом аудита должны стать критерии, подтверждения испытаний и список необходимых изменений. Это позволяет принять проверяемое решение: запустить систему в определённых границах, ограничить функции или сначала устранить выявленные проблемы.