Девять критериев качества ИТ-продукта: что проверять, чем поможет ИИ и что меняется в ИИ-системах
В феврале 2024 года канадский трибунал разобрал спор пассажира с Air Canada. Чат-бот на сайте авиакомпании рассказал клиенту, как получить скидку на перелёт к похоронам. Правило он описал неверно, и клиент купил билет по полной цене. Авиакомпания пыталась переложить ответственность на самого бота. Трибунал с этим не согласился: компания отвечает за всю информацию на своём сайте, и неважно, пришла она со статичной страницы или из чат-бота. Компанию обязали выплатить 812 канадских долларов (решение 2024 BCCRT 149 в пересказе юристов DWW).
Чат-бот Air Canada формально работал: принимал вопросы и быстро отвечал. Подвёл не список функций, а правильность ответа. На этом примере видна ошибка в разговоре о качестве: его путают со списком функций или с удачным показом. Ни то ни другое не говорит, можно ли системой пользоваться в работе.
Девять критериев
На практике я, Джимшер Челидзе, выделяю 9 критериев качества ИТ-продукта, конечно опираясь на международный стандарт. Они собраны в три вопроса, которые задаёт руководитель: работает ли система как нужно, не подведёт ли она и во что она обойдётся, не станем ли мы её заложниками.
Давайте рассмотрим их подробнее.
Вопрос | Критерий | Что это значит | Как проверить |
|---|---|---|---|
Работает ли как нужно? | Функциональность | Работает ли система так, как запланировано, выполняет ли она намеченные функции | Критичные требования технического задания (ТЗ) или бэклога, то есть списка задач продукта, реализованы; функции выполняются так, как задумано; неудобные случаи (пустой ввод, ошибки ввода, большие объёмы) обрабатываются; данные не теряются |
| Удобство | Удобно ли работать пользователям, способны ли они освоить систему без длительного обучения и инструкций, сталкиваются ли с проблемами, требуется ли множество движений и действий, работает ли она с необходимой скоростью | Время обучения нового пользователя; число шагов на типовую операцию; понятные сообщения об ошибках; время отклика, которое видит пользователь |
| Точность и её удержание | Верен ли результат (расчёты, аналитика, ответы) и остаётся ли он верным, когда меняются данные | Целевой уровень точности назван числом до старта; расчёты сверены на контрольных примерах; качество входных данных проверено; проверка на своих данных, в целом и по значимым группам; повторная проверка по графику и при смене данных или модели |
Не подведёт ли? | Стабильность и надёжность | Работает ли система стабильно и предсказуемо, не падает ли каждый день или под нагрузкой, можно ли её восстановить после сбоя быстро и без потери данных | Доля времени, когда система доступна; время восстановления после сбоя и сохранность данных; мониторинг; нагрузочные испытания и опытно-промышленная эксплуатация до запуска |
| Защищённость | Защищены ли данные и доступ: кто видит, кто меняет, остаётся ли след | Разграничение прав; защищённый канал; журнал доступа; резервные копии; определено, какие данные можно передавать во внешние сервисы и модели |
| Безопасность | Не навредит ли система людям, процессу и оборудованию, можно ли её остановить и перейдёт ли она при сбое в безопасное состояние | Перечень недопустимых событий составлен до старта, по каждому показано, как оно исключено или сведено к приемлемому риску; человек может вмешаться и остановить систему; при сбое система переходит в безопасное состояние; нет неописанных управляющих воздействий; ИИ не выходит за границы полномочий |
Во что обойдётся и не станем ли заложниками? | Сопровождаемость | Может ли с системой работать не только её автор: разобраться, доработать и проверить, что после изменений всё работает | Документация и доступ к исходному коду или настройкам переданы; дорабатывать систему может не только её автор; есть способ проверить систему после изменений; срок и цена типовой доработки названы до подписания договора |
| Интегрируемость и переносимость | Встраивается ли система в экосистему и уживается ли с другими системами, можно ли перенести её на другую платформу или заменить поставщика без переписывания | Обмен с другими системами идёт через описанные интерфейсы и проверен на приёмке; система работает рядом с другими на общих ресурсах без помех; данные можно выгрузить в открытом формате; известно, что нужно для переноса на другую платформу или в своё облако и для замены поставщика или модели |
| Производительность и эффективность | Хватает ли системе скорости и мощности под нагрузкой и сколько ресурсов и денег на это уходит | Время отклика и пропускная способность при расчётной нагрузке; потребление ресурсов (серверы, лицензии, вычисления) измерено; известно, выдержит ли система рост пользователей и данных и сколько это будет стоить |
Критерий «точность и её удержание» нужен любой системе. Отчёт может считать строго по формуле, но если данные в него вносят вручную в конце месяца, с ошибками и опозданием, аналитика всё равно будет неверной. Поэтому точность зависит и от логики системы, и от качества данных на входе. У ИИ-системы к этому добавляется ещё одно: модель ошибается в какой-то доле случаев, и эту долю измеряют отдельно.
Правило порогов
Порог по каждому критерию задают до старта, исходя из того, насколько система критична. Отчёту, который смотрят раз в месяц, хватит одних порогов, системе управления производством нужны другие. Если хотя бы по одному критерию система ниже порога, её не принимают, сколько бы она ни набрала по остальным. Выше порогов критерии можно взвешивать между собой и спорить, что важнее.
Правило порогов защищает от подмены «зато быстро» или «зато красиво». Удобный интерфейс не возмещает утечку данных или лишних действий, а точная модель не спасает, если после ухода автора систему некому поправить.
ИИ с двух сторон
С появлением ИИ у каждого критерия два слоя. ИИ стал помощником, который ускоряет проверку любой системы, обычной или нет. И ИИ стал предметом проверки: если система сама построена на модели, каждый критерий проверяют иначе.
И самое важное, ИИ не заменяет работу человека на 100%, в любом случае выводы ИИ-помощника проверяет человек. А если от помощника зависит решение о приёмке, его самого проверяют как ИИ-систему: насколько точно он справляется именно с этой задачей.
Дальше разберу каждый критерий по трём пунктам: что проверяем, чем помогает ИИ и что меняется, если система сама на ИИ.
Работает ли как нужно?
Первые три критерия отвечают на вопрос, приносит ли система пользу: есть ли нужные функции, удобно ли ими пользоваться и можно ли верить результату.
1. Функциональность
Что проверяем. Работает ли система так, как задумано: реализованы ли критичные требования, как она ведёт себя на неудобных случаях, не теряет ли данные. Верен ли результат этих функций, проверяет отдельный критерий, точность.
Чем помогает ИИ
По техническому заданию модель составляет перечень проверок, включая неудобные случаи: пустое поле, дата в прошлом, десять тысяч строк вместо десяти. Она же находит в ТЗ противоречия и пропуски, пока их дёшево исправить. Перечень сверяет человек, но начинать с него быстрее, чем с чистого листа.
Если система на ИИ
Один и тот же вопрос может дать разные ответы, поэтому одной удачной демонстрации мало. Систему проверяют на наборе типовых и пограничных запросов с заранее известными правильными ответами. Такой набор называют evals: в документации OpenAI это проверки, что ответы модели соответствуют заданным критериям стиля и содержания (OpenAI, Evals). Часть ответов можно оценивать другой моделью. По исследованию Zheng и соавторов, такой «судья» на основе GPT-4 совпадал с оценками людей более чем в 80 % случаев, но предпочитал длинные ответы, ответы на определённой позиции и собственные ответы (Zheng et al., 2023). Поэтому выборку оценок судьи всё равно смотрит человек.
Ещё до старта решают, что ИИ-система делает, когда не уверена: отказывается отвечать, задаёт уточняющий вопрос или передаёт запрос человеку. Это тоже функция, и её проверяют так же, как остальные.
2. Удобство
Что проверяем. Может ли человек освоить систему без долгого обучения, не требует ли она лишних шагов, понятны ли ошибки, хватает ли скорости. Здесь важна скорость, которую ощущает пользователь в работе; время отклика под нагрузкой и ресурсы на эту скорость проверяет критерий производительности и эффективности.
Чем помогает ИИ
Модель разбирает обращения в поддержку и отзывы пользователей и группирует их по темам. Видно, где людям трудно, на каком шаге они бросают операцию, какие слова в интерфейсе непонятны. Разбирать можно все обращения, а не выборку.
Также на этапе проектирования ИИ позволяет собрать пользовательские сценарии, делать виртуальные прогоны, искать ошибки и оптимизировать их. Затем быстро готовить первые прототипы, которые уже можно тестировать на пользователях, собирать обратную связь, анализировать и делать дальнейшие доработки. Фактически мы сокращаем время на этот процесс и трудозатраты людей, можем анализировать и тестировать больше за меньшее время.
Если система на ИИ
К удобству добавляются три вопроса. Понятен ли ответ человеку, понятно ли, откуда ответ взят: из какого документа, какой записи, какого правила. И может ли человек не согласиться с ответом, поправить его или отменить. Европейский регламент об ИИ для систем высокого риска (категория с самыми строгими требованиями) требует того же: человек может не учитывать результат системы или изменить его и должен понимать риск слепого доверия автоматике (EU AI Act, статья 14). Время ответа модели тоже часть удобства: ассистент, который думает минуту, в живом разговоре с клиентом не годится.
3. Точность и её удержание
Что проверяем. Верен ли результат (расчёты, аналитика, ответы) и остаётся ли он верным, когда меняются данные.
Для обычной системы точность начинается с данных. Если данные неполные, противоречивые или устаревшие, система аккуратно посчитает неверный результат. Поэтому расчёты сверяют на контрольных примерах, а данные на входе проверяют на полноту, точность, согласованность и актуальность. Эти и другие характеристики описывает международная модель качества данных ISO/IEC 25012 (обзор стандарта).
Чем помогает ИИ
Для ИИ-системы набор проверочных запросов прогоняют автоматически после каждого изменения инструкций, базы знаний или версии модели. Часть ответов оценивает модель-судья, выборку смотрит человек. Точность становится показателем, за которым следят, а не цифрой из протокола приёмки. Почему модель бывает точна в сложном и ошибается в простом, я разбирал в статье «Описанность, а не сложность». Для обычной системы ИИ сверяет расчёты на контрольных примерах и находит в данных аномалии: пропуски, дубли, значения вне привычного диапазона.
Если система на ИИ
Сначала уровень точности ИИ-системы называют числом до старта. Сто процентов недостижимы, поэтому заранее решают, какая доля ошибок допустима и что с ними делать. Европейский регламент требует от поставщиков систем высокого риска указывать уровни точности в инструкции по использованию (EU AI Act, статья 15).
Затем точность проверяют на своих данных, а не по цифрам из презентации модели, и отдельно по значимым группам: регионам, видам оборудования, категориям клиентов. Среднее значение прячет перекосы. В исследовании Gender Shades 2018 года коммерческие системы распознавания пола по лицу ошибались на светлокожих мужчинах не больше чем в 0,8 % случаев, а на темнокожих женщинах до 34,7 % (Buolamwini, Gebru, 2018).
Наконец, проверку точности повторяют по графику и при каждой заметной смене данных или модели. Лингцзяо Чэнь, Матей Захария и Джеймс Зоу сравнили две версии GPT-4 в задаче «простое ли это число»: за три месяца 2023 года точность упала с 84 до 51 % (Chen, Zaharia, Zou, 2023). Их вывод: за языковыми моделями нужно постоянное наблюдение. И на практике, в работе с разными моделями я могу сказать, что это обычное явление как для публичных сервисов, так и для внутренних систем. Одна из причин – ИИ-системы настраиваются на один тип данных, а со временем они меняются, а инструкции и инфраструктура не адаптируются.
В перечне угроз OWASP, о котором речь пойдёт в разделе о защищённости, это девятый пункт, дезинформация: правдоподобные, но ложные ответы. Ошибки модели стоят денег и репутации. В 2025 году Deloitte Australia частично вернула правительству Австралии деньги за отчёт стоимостью около 440 тысяч австралийских долларов: в нём нашли больше десятка несуществующих источников и выдуманную цитату из судебного решения. Компания признала, что при подготовке использовала языковую модель. Возврат составил чуть больше 97 тысяч австралийских долларов, около 63 тысяч долларов США (CFO Dive).
Не подведёт ли?
Следующие три критерия отвечают на вопрос о рисках: не упадёт ли система, не утекут ли данные и не навредит ли она людям и процессу.
4. Стабильность и надёжность
Что проверяем. Работает ли система предсказуемо, не падает ли под нагрузкой, быстро ли восстанавливается после сбоя и не теряет ли при этом данные.
Чем помогает ИИ
Модель читает журналы работы и находит повторяющиеся сбои и всплески, которые человек пропустит в тысячах строк. Она помогает разобрать инцидент: собрать хронологию, сопоставить события, предложить гипотезы о причине. Но итоговый вывод о причине делает инженер.
Также на этапе проектирования ИИ быстрее просчитывает требуемую конфигурацию оборудования и готовит несколько вариантов, проводит виртуальные стресс-тесты, на основе этого принимаются итоговые решения.
Если система на ИИ
Появляется зависимость, которой у обычной системы нет: от модели и её поставщика. Модель может стать недоступной, упереться в лимиты или смениться. Поставщики выводят старые модели из работы по расписанию: OpenAI обещает не меньше шести месяцев предупреждения для общедоступных моделей, Anthropic не меньше 60 дней (OpenAI, Deprecations; Anthropic, Model deprecations).
Даже без смены названия поведение модели меняется (пример с GPT-4 разобран в разделе о точности), поэтому за моделью следят постоянно, а не только при обновлениях.
ИИ-системе нужен запасной режим на случай, если модель недоступна: другая модель, сценарий без ИИ или передача человеку. Версию модели фиксируют, а перед каждой сменой заново прогоняют набор проверочных запросов. Европейский регламент для систем высокого риска прямо упоминает резервные решения и планы безопасного отказа (EU AI Act, статья 15).
5. Защищённость
Что проверяем. Защищены ли данные и доступ: кто видит, кто меняет, остаётся ли след. Проверяют разграничение прав, защищённый канал, журнал доступа и резервные копии, а также правила, какие данные можно передавать во внешние сервисы и модели.
Чем помогает ИИ
Модели уже находят уязвимости, которые пропустили люди и классические инструменты. Если в 2024 году были специализированные инструменты, то уже в 2026 году даже открытые и общедоступные модели сразу делают необходимые тесты. В августе 2026 года Anthropic показала, как сильно результат зависит от организации работы: 45 агентов с общим форумом нашли в 15 открытых проектах 266 уязвимостей, а те же агенты, работавшие поодиночке, 21, правда, при вчетверо меньшем вычислительном бюджете (Anthropic, 13.08.2026). В итоге проверять код и настройки с ИИ можно чаще и шире, но специалиста по безопасности это не заменяет. Да, мы можем делать больше исследований, более глубокие, но нужен человек, который это будет лидировать.
Если система на ИИ
Добавляются угрозы, которых у обычной программы нет. Конкретный перечень угроз для приложений на языковых моделях ведёт OWASP, международное некоммерческое сообщество по безопасности приложений. В версии 2025 года в нём десять пунктов (OWASP Top 10 for LLM Applications):
Подмена инструкций в запросе (prompt injection).
Раскрытие чувствительных данных.
Уязвимости цепочки поставок: сторонних моделей, данных и компонентов.
Отравление обучающих данных и самой модели.
Небезопасная обработка ответа, когда ответ модели без проверки передают дальше в другие системы.
Избыточные полномочия.
Утечка системных инструкций.
Слабые места векторных хранилищ и поиска по базе знаний.
Дезинформация: правдоподобные, но ложные ответы.
Неограниченный расход ресурсов.
Для российских компаний есть своя опора: в июле 2026 года Сбер опубликовал вторую версию модели угроз для ИИ, рассчитанную на генеративные, агентные и мультиагентные системы, с 37 угрозами и 51 способом их реализации (Газета.Ru, 30.07.2026).
Из этого перечня к защищённости прямо относятся три пункта: подмена инструкций, раскрытие чувствительных данных и утечка системных инструкций. Пункт 6 относится к безопасности, пункт 9 к точности, пункт 10 к производительности и эффективности, о них в своих разделах. Три пункта о защищённости руководителю стоит знать в лицо.
Подмена инструкций стоит в перечне первой. Для модели приказ и данные неразличимы, поэтому команда может прийти прямо от пользователя, спрятаться во внешнем источнике (на сайте, в письме, в PDF) или лежать в самих данных, которые система читает. Как это выглядит, показал случай в декабре 2023 года: пользователь написал чат-боту автодилера Chevrolet новые правила, соглашаться с любым требованием клиента, а потом попросил внедорожник Tahoe за один доллар. Бот согласился и назвал это юридически обязывающим предложением. Дилер отключил бота (GM Authority). Надёжнее всего защищает архитектура: на входе и выходе системы формализованные данные, а не свободный текст.
Раскрытие чувствительных данных стоит вторым. Весной 2023 года сотрудники полупроводникового подразделения Samsung загрузили во внешний чат-бот исходный код и записи внутреннего совещания (TechRadar). По данным Bloomberg, затем компания запретила генеративный ИИ сотрудникам одного из крупных подразделений (Bloomberg, 02.05.2023). Вопрос «какие данные можно отдавать внешней модели» решают до запуска, а не после первого инцидента. Системные инструкции модели хранят как секреты: их утечка равна утечке исходного кода.
Что требовать от ИИ-системы на приёмке по защищённости:
система проверена на подмену инструкций и попытки обойти защиту, в том числе нестандартными формулировками и на других языках;
определено, какие данные можно передавать во внешнюю модель, системные инструкции хранятся как секреты;
источники данных для обучения и базы знаний проверены и описаны;
журналы действий защищены от изменения и отключения.
Подробнее об угрозах генеративного ИИ я писал в статье «Генеративный ИИ: новая эра информационной безопасности».
6. Безопасность
Что проверяем. Насколько решение безопасно для производственного процесса, людей и оборудования. Безопасность не сводится к паролям: система, которая управляет оборудованием или даёт указания персоналу, может навредить без всякой утечки. Поэтому проверяют, может ли человек остановить систему и переходит ли она при сбое в безопасное состояние.
Проверку безопасности стоит начинать с перечня недопустимых событий, а уже потом обсуждать средства защиты. Недопустимое событие означает то, что ни при каких условиях не должно произойти. Для людей это угроза жизни и здоровью, утечка персональных данных, финансовый ущерб. Для компании это остановка производства или сбой в системах управления оборудованием, хищение денег, утечка коммерческой тайны, публикации и рассылки от её имени, неправильные решения, принятые по данным системы. Порог по безопасности и есть этот перечень: систему принимают, когда по каждому недопустимому событию показано, как оно исключено или сведено к приемлемому риску. Подробно подход разобран в книге Джимшера Челидзе «Искусственный интеллект. С неба на землю».
Чем помогает ИИ
ИИ помогает составить перечень недопустимых событий и сценарии отказов: перебрать, что может пойти не так на каждом шаге процесса. Решение, что из этого недопустимо и как это исключить, остаётся за человеком.
Если система на ИИ
Чтобы не утонуть в рисках ИИ-системы, удобно держать в голове три направления технической безопасности ИИ, которые в 2018 году сформулировали исследователи DeepMind (DeepMind Safety Research).
Первое направление, спецификация: система делает то, что задумано, а не то, что буквально написано в задании. Классический пример из той же работы: агент в гоночной игре CoastRunners вместо прохождения трассы кружил на одном месте и собирал очки за бонусы, потому что награда была задана неточно. Для руководителя это вопрос к ТЗ: описано ли, чего система делать не должна, и нет ли у неё возможностей, которых никто не заказывал, например управляющего воздействия на оборудование без подтверждения человека.
Второе направление, устойчивость: система выдерживает помехи и атаки. Данные в работе отличаются от тех, на которых систему настраивали, а злоумышленник специально подбирает ввод, чтобы её обмануть. Устойчивая система в такой ситуации предупреждает оператора и останавливается, а не выдумывает ответ.
Третье направление, контроль: за работой системы можно наблюдать и её можно остановить. Это журналы действий, которые нельзя стереть или отключить, мониторинг, приоритет ручного управления и кнопка «стоп». Европейский регламент для систем высокого риска требует возможности прервать работу кнопкой «стоп» или похожей процедурой (EU AI Act, статья 14).
Из перечня OWASP к безопасности процесса прямо относится шестой пункт, избыточные полномочия. Так называют случаи, когда система с лишними функциями, правами или самостоятельностью совершает вредные действия из-за неожиданного или подменённого ответа модели (OWASP, LLM06:2025). В июле 2025 года ИИ-агент Replit, сервиса для разработки приложений, удалил рабочую базу данных у Джейсона Лемкина, основателя сообщества SaaS-компаний SaaStr, хотя ему прямо запретили вносить изменения без одобрения. Replit после этого ввела автоматическое разделение рабочей и тестовой баз и режим планирования без правки кода (The Register). Запрет, записанный словами в задании, агента не остановил. Границу полномочий агента задаёт руководитель, это управленческое решение, а не техническая настройка: список разрешённых действий, подтверждение человеком всего необратимого и рабочая среда, отделённая от тестовой.
Что требовать от ИИ-системы на приёмке по безопасности:
описано, чего система делать не должна, и у неё нет неописанных возможностей;
человек может прервать работу в любой момент, ручное управление в приоритете, при сбое система переходит в безопасное состояние;
у агента только нужные права, необратимые действия подтверждает человек, рабочая среда отделена от тестовой;
пользователь знает, что работает с ИИ;
на непривычных данных система предупреждает оператора и останавливается.
Окончательный перечень требований зависит от того, насколько система критична, то есть от порога, который задают до старта. О рисках агентов я подробнее писал в статье «ИИ-агент не ошибся. Он слишком точно понял задачу».
Во что обойдётся и не станем ли заложниками?
Последние три критерия отвечают на вопрос, сколько будет стоить жить с системой и от кого компания будет зависеть: от автора, от платформы и поставщика, от счёта за ресурсы.
7. Сопровождаемость
Что проверяем. Может ли работать с системой кто-то, кроме её автора и разработчика: разобраться, доработать и проверить, что после изменений всё работает. Переданы ли документация и доступ к коду или настройкам, есть ли тесты или проверочный набор, известны ли срок и цена типовой доработки до подписания договора.
Чем помогает ИИ
Модель пишет и обновляет документацию прямо в процессе разработки, объясняет чужой код новому разработчику. Зависимость от одного человека, который «всё знает», снижается.
Если система на ИИ
Сопровождать приходится больше, чем код. Есть системные инструкции для модели, которые определяют её поведение. Есть база знаний, из которой она берёт ответы. Есть набор проверочных запросов, на котором её проверяют после каждого изменения. Есть регламенты взаимодействия между различными ИИ-агентами. И есть разные версии самих ИИ-моделей, на которых всё это настроено. Если что-то из этого живёт только в голове автора, систему сопровождает только автор. Поэтому всё перечисленное передают заказчику или команде сопровождения так же, как исходный код, и описывают, как проверить систему после замены модели.
8. Интегрируемость и переносимость
Что проверяем. Можно ли встроить систему в экосистему компании или интегрировать с другими продуктами и ИТ-решениями, уживается ли она рядом с другими системами. И можно ли перенести её на другую платформу или в своё облако, заменить поставщика без переписывания. Проверяют, что обмен идёт через описанные интерфейсы и проверен на приёмке, данные можно выгрузить в открытом формате, а для переноса и замены поставщика понятен план.
Система, которую нельзя перенести, делает компанию заложником поставщика: цену следующей доработки или продления назначает он. О том, как этот вопрос встаёт, когда поставщик уходит, я писал в статье «Импортозамещение ПО: с чего начать?».
Чем помогает ИИ
Модель описывает интерфейсы обмена, сопоставляет форматы данных разных систем и помогает переносить код и настройки на другую платформу. Итоговую проверку переноса делают люди на тестовом контуре.
Если система на ИИ
У переносимости появляется новое измерение: заменяемость модели. Поставщики выводят модели из работы по своему расписанию, поэтому систему строят так, чтобы модель можно было заменить без переписывания. Инструкции, база знаний и проверочный набор не привязаны к одному поставщику, а после замены систему прогоняют на том же наборе запросов.
Интегрируемость ИИ-системы тоже своя: модель берёт данные из систем компании, а агент ещё и действует в них. Каждый такой доступ идёт через описанный интерфейс с понятными правами, а не через учётную запись администратора, выданную «временно» на пилот. Как устроена такая обвязка вокруг агента, я разбирал в статье «Обвязка ИИ-агента: почему агентом управляют те же законы, что и компанией».
9. Производительность и эффективность
Что проверяем. Хватает ли системе скорости и мощности под нагрузкой и сколько ресурсов и денег на это уходит. Замеряют время отклика и пропускную способность при расчётной нагрузке, потребление серверов, лицензий и вычислений и проверяют, что будет при росте пользователей и данных. Стабильность отвечает на вопрос, не упадёт ли система, а производительность на вопрос, не будет ли она тормозить. Речь о стоимости работы самой системы, а не об окупаемости проекта.
Чем помогает ИИ
Модель анализирует журналы работы и потребления ресурсов, находит узкие места, из-за которых система тормозит под нагрузкой, и подсказывает, где сократить расход: лишние запросы к базе, простаивающие мощности, тяжёлые операции. Эффект оптимизации всё равно подтверждают замером.
Если система на ИИ
У ИИ-системы появляется новая статья расходов: каждый запрос к модели стоит денег, а у поставщика есть лимиты. В перечне OWASP это десятый пункт, неограниченный расход ресурсов: система без ограничений может израсходовать бюджет или перестать отвечать под потоком запросов (OWASP Top 10 for LLM Applications). Время ответа модели при росте числа пользователей тоже проверяют до запуска. Поэтому до старта считают стоимость типового запроса и месячный объём, ставят лимиты и следят за расходом так же, как за доступностью.
Что это даёт руководителю
Первое: общий язык с ИТ и подрядчиком. Вместо «система плохая» звучит, например, «удобство ниже порога: на типовую операцию уходит двенадцать шагов вместо пяти». Со второй формулировкой можно работать.
Второе: приёмка по фактам. Демонстрация показывает часть функциональности, иногда удобство. Остальные критерии на демонстрации почти не видны, и их проверяют отдельно.
Третье: меньше сюрпризов после запуска. Почти всё, что в таблице выше, дешевле записать в ТЗ и договор, чем добиваться потом.
Окупаемость девять критериев не обещают. Система, которая прошла все пороги, может не дать эффекта, если её делали не для той задачи. Но вы знаете, какое качество получили и за что платите.
Как это соотносится со стандартами
Перечень авторский и сделан для руководителя, а не для инженера по качеству. При этом все девять характеристик международной модели качества программных продуктов ISO/IEC 25010:2023 в нём есть, хотя разложены иначе: соответствие не один к одному (ISO). Добавки для ИИ-систем из ISO/IEC 25059:2023 (ISO), такие как прозрачность, управляемость, устойчивость и возможность вмешаться, разобраны выше в части «если система на ИИ»; второе издание этого стандарта сейчас на утверждении (ISO). Группировка по трём вопросам в ISO не встречается. Ближайший прецедент: модель качества Маккола 1977 года, где факторы разбиты на три перспективы: эксплуатация, доработка и перенос (McCall, Richards, Walters, 1977).
В России действуют ГОСТ Р ИСО/МЭК 25010-2015, идентичный версии международного стандарта 2011 года (текст стандарта), и ГОСТ Р 59898-2021 «Оценка качества систем искусственного интеллекта. Общие положения» (текст стандарта). Девять критериев не заменяют эти стандарты: инженерам, которые строят систему тестирования, нужны именно они.
Что почитать дальше
Книга Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» о том, как вести ИИ-проект от идеи до промышленной эксплуатации.
Бесплатно: третья редакция книги «Искусственный интеллект. С неба на землю», скачать PDF.
Обучение и консультации для руководителей: на главной странице сайта.
