Статья 94 44-ФЗ требует от заказчика провести экспертизу результатов закупки — своими силами или с привлечением внешних экспертов и экспертных организаций. Для традиционного ПО экспертиза сверяет функции с ТЗ. С ИИ сложнее: часть поведения модели вероятностная, «правильный ответ» не гарантирован на каждом запросе, а качество зависит от данных. Поэтому критерии приёмки ИИ нужно проектировать заранее — на этапе техзадания.
Таблица: что проверять в ИИ-компонентах
| Компонент | Что проверять | Подтверждение |
|---|---|---|
| Модель | точность, полнота, доля автоматических ответов на тестовом наборе | протокол испытаний |
| Данные | права на обучающие данные, обезличивание, провенанс | реестр датасетов, согласия |
| Интеграции | корректность обмена с ГИС, 1С, СМЭВ | акты испытаний интерфейсов |
| Безопасность | устойчивость к промпт-инъекциям и утечкам через модель | отчёт по OWASP LLM Top-10 |
| Документация | инструкции, регламент эксплуатации, границы применения | комплект документации |
Как задать метрики в ТЗ
Правило простое: метрика должна быть измеримой и проверяемой на наборе, которого исполнитель не видел. «Ассистент должен отвечать точно» — не критерий; «доля корректных ответов не ниже 85% на контрольном наборе из 200 обращений, оценённая по согласованной методике» — критерий. Какие метрики приняты для ассистентов и RAG-систем (доля автозавершений, точность выдачи, экономия часов) и как их фиксировать в задании — разбираем в гайде ТЗ на разработку ПО.
Внутренняя или внешняя экспертиза
Заказчик вправе провести экспертизу силами своих сотрудников, но для сложных ИТ-решений 44-ФЗ предусматривает привлечение внешних экспертов. Для ИИ-систем внешняя экспертиза почти всегда оправдана: нужны компетенции одновременно в данных, машинном обучении и безопасности. Поставщику внешний эксперт тоже полезен: заключение с измеримыми метриками закрывает спор о «качестве» лучше переписки.
Экспертиза ИИ имеет и второе дно — подготовку к будущим проверкам. Документы, собранные на приёмке (реестр датасетов, права на данные, регламент эксплуатации, отчёт о безопасности), — это тот же комплект, который понадобится по 243-ФЗ с 1 марта 2027 года и при любых аудитах ИБ. Заказчик, который однажды правильно провёл приёмку ИИ-компонентов, получает актив, работающий на следующих стадиях жизненного цикла системы; экономия на экспертизе превращается в двойные расходы позже.
Наконец, фиксируйте в контракте судьбу артефактов: кому принадлежат обученные модели и датасеты, как передаются веса и код, что происходит при расторжении. Спор о правах на модель после успешной приёмки — самый дорогой вид споров в ИИ-закупках, и решается он пунктом договора, а не экспертизой.
Что делать при разногласиях
- Возврат к ТЗ. Всё, что не измерено критериями, не может быть основанием отказа в приёмке.
- Повторные испытания на том же контрольном наборе — с фиксацией условий и методики.
- Дефектный акт с классификацией замечаний: критично / некритично / не является предметом контракта.
- Экспертное заключение третьей стороны, если позиции сторон не сходятся.
Для заказчиков госсектора у нас есть готовый контур проверки: ИИ для госсектора и разбор 243-ФЗ и госзакупки — как происхождение ИИ-компонентов проверять до заявки, а не после.
Как мы помогаем
НЬЮ-ССТ выступает и исполнителем, и экспертом: аудит ИИ-систем по OWASP LLM Top-10 — от 150 000 ₽, ИИ red teaming — от 300 000 ₽, приёмочные испытания с протоколами метрик — в составе проектов. Исполнителям помогаем подготовить систему к чужой экспертизе: прогоны на контрольных наборах, документация, регламенты.