Закупка ИИ-решений: как прописать данные, метрики качества и права на ПО в техническом задании

Закупка систем на базе искусственного интеллекта (ИИ) принципиально отличается от приобретения стандартного программного обеспечения. Главная сложность — описать в техническом задании (ТЗ) не только функционал, но и требования к данным для обучения, критерии точности работы модели и условия передачи прав на создаваемый код. Без четких формулировок заказчик рискует получить «черный ящик», который невозможно проверить и использовать.

Материал ориентирован прежде всего на заказчиков, работающих в рамках 44-ФЗ и 223-ФЗ. Мы разберем, как составить ТЗ так, чтобы закупить действительно работающее ИИ-решение, а не просто обещание инноваций.

Почему стандартное ТЗ не подходит для закупки ИИ

Классическое техническое задание описывает конечный продукт с заранее известными характеристиками: размер, вес, скорость отклика, перечень функций. ИИ-система — это обучаемый инструмент. Ее поведение зависит от качества и объема данных, архитектуры модели и процесса обучения. Если заказчик просто укажет «система должна распознавать дефекты с точностью 95%», он не получит работающего механизма проверки этого параметра.

Основные отличия ИИ-решения от обычного ПО:

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

Пошаговый алгоритм составления ТЗ на ИИ-решение

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

Шаг 1. Формализация задачи и определение типа ИИ

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

Шаг 2. Требования к данным для обучения и валидации

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

• Формат и структуру данных (CSV, JSON, DICOM для медицины).
• Требования к разметке (кто выполняет, по каким правилам, какой инструмент используется).
• Объем обучающей и тестовой выборки.
• Критерии репрезентативности данных (отсутствие смещения, баланс классов).
• Порядок проверки качества исходных данных перед началом обучения.

Если поставщик использует собственные данные, пропишите обязательство передать описание датасета и подтверждение законности его использования.

Шаг 3. Метрики качества и порядок их измерения

Метрики качества — это единственный объективный способ оценить результат. Для задачи классификации можно использовать точность (accuracy), полноту (recall) и F1-меру. Для регрессии — среднюю абсолютную ошибку (MAE) или коэффициент детерминации (R²). В ТЗ нужно указать не только целевое значение метрики, но и методику ее расчета на отложенной тестовой выборке.

Важно прописать пороговые значения: например, «полнота обнаружения дефектов — не менее 0.95, точность — не менее 0.90». Без конкретных цифр приемка превратится в субъективную оценку.

Шаг 4. Права на ПО, модель и данные

Раздел о правах критически важен для ИИ-закупок. Заказчику нужно четко разделить три объекта:

• Исходный код программного обеспечения (интерфейс, интеграционные модули).
• Обученная модель (веса, архитектура нейронной сети).
• Датасет, использованный для обучения.

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

Шаг 5. Требования к документированию и воспроизводимости

ИИ-решение не должно быть «черным ящиком». В ТЗ включают требования к документации: описание архитектуры модели, инструкция по дообучению, руководство администратора. Отдельно стоит прописать условие воспроизводимости результата — возможность повторить обучение и получить модель с теми же метриками качества.

Шаг 6. Порядок приемки и тестирования

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

Практический пример: закупка системы видеоаналитики для контроля качества

Рассмотрим условный кейс. Производственное предприятие закупает ИИ-решение для автоматического обнаружения брака на конвейере. В ТЗ включаются следующие блоки:

Данные: заказчик передает 10 000 размеченных изображений деталей (годные/брак) в формате PNG. Разметка выполнена сотрудниками ОТК. Поставщик обязан провести аудит датасета и сообщить о некачественных примерах до начала обучения.

Метрики качества: на тестовой выборке из 2 000 изображений, не использованных при обучении, модель должна показать recall по классу «брак» не ниже 0.97 при precision не ниже 0.92. Время обработки одного кадра — не более 100 мс.

Права: исключительные права на обученную модель и программный код передаются заказчику. Допускается использование открытых библиотек TensorFlow и OpenCV. Датасет остается в собственности заказчика и не может использоваться поставщиком для других проектов.

Приемка: испытания проводятся на производственной линии в течение 5 рабочих дней. Ежедневно фиксируется количество пропущенного брака и ложных срабатываний. Итоговые метрики рассчитываются по совокупности данных за весь период.

Распространенные ошибки при закупке ИИ-решений

На практике заказчики часто допускают типичные просчеты, которые приводят к срыву проекта или судебным спорам. Вот основные из них.

Ошибка 1. Размытые формулировки метрик. Фразы «высокая точность» или «качественное распознавание» не имеют юридического смысла. Всегда указывайте конкретную метрику, методику расчета и пороговое значение.

Ошибка 2. Игнорирование прав на модель. Если в ТЗ не прописана передача исключительных прав, заказчик может оказаться в зависимости от поставщика при любом обновлении или доработке системы.

Ошибка 3. Отсутствие требований к данным. Поставщик может обучить модель на собственных данных, которые не отражают реальную специфику заказчика. Результат — низкое качество работы на практике.

Ошибка 4. Приемка без тестовой выборки. Проверка на тех же данных, что использовались для обучения, дает завышенные показатели. В ТЗ нужно явно описать процедуру выделения независимого тестового набора.

Ошибка 5. Смешивание требований к ПО и к ИИ-модели. Техническое задание должно четко разделять функциональные требования к интерфейсу и интеграции от требований к точности и стабильности работы самой модели.

Как снизить риски при описании объекта закупки

При работе по 44-ФЗ и 223-ФЗ важно помнить о принципах конкурентной среды. Нельзя указывать конкретные торговые наименования или уникальные характеристики, свойственные только одному продукту. Описывайте объект закупки через функциональные и качественные параметры.

Перед публикацией извещения полезно провести общественное обсуждение или направить проект ТЗ потенциальным разработчикам для сбора замечаний. Это поможет выявить невыполнимые или избыточные требования на раннем этапе.

Для специалистов заказчика, которые хотят глубже разобраться в составлении документации и описании объекта закупки, включая сложные технические продукты, подойдет программа профпереподготовки для заказчиков по 44-ФЗ и 223-ФЗ на 320 часов. В ней детально рассматриваются правила формирования ТЗ, применение КТРУ и минимизация рисков на этапе планирования.

FAQ: частые вопросы о закупке ИИ-решений

Можно ли закупить ИИ-систему как обычное ПО?
Формально да, но без специальных разделов о данных, метриках и правах на модель вы не сможете объективно оценить результат и защитить интересы организации.

Какие метрики качества указывать в ТЗ?
Выбор метрики зависит от задачи. Для классификации обычно используют accuracy, precision, recall и F1-меру. Для задач регрессии — MAE, MSE, R². Главное — указать методику расчета и пороговое значение.

Кому принадлежат права на обученную модель?
По умолчанию права принадлежат разработчику, если иное не указано в контракте. В ТЗ необходимо прямо прописать передачу исключительных прав заказчику на модель и исходный код.

Как проверить качество ИИ при приемке?
Только путем тестирования на независимой выборке данных, которая не использовалась при обучении. Протокол испытаний должен содержать расчет оговоренных в ТЗ метрик.

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

Итог

Закупка ИИ-решений требует от заказчика пересмотра привычных подходов к техническому заданию. Ключевые акценты смещаются с описания интерфейса на требования к данным, объективные метрики качества и четкое распределение прав на создаваемые объекты интеллектуальной собственности. Только детально проработанное ТЗ превращает закупку искусственного интеллекта из лотереи в управляемый процесс с измеримым результатом. Для комплексного освоения всех этапов закупочной деятельности, от планирования до приемки, можно рассмотреть углубленный курс профпереподготовки для заказчиков с дипломом на 520 часов, где разбирается полный цикл работы по 44-ФЗ и 223-ФЗ.