Вы когда-нибудь пробовали засунуть research-проект с непредсказуемым результатом в прокрустово ложе государственного контракта с жесткими сроками и штрафами? Закупка разработки ИИ по 44-ФЗ и 223-ФЗ: как обосновать НМЦК и не написать ТЗ под одного подрядчика — это не юридический квест, это попытка обмануть саму природу инженерии данных. Скажу прямо: шансы успешно сдать нейросеть с нуля по классической водопадной модели без отдельного этапа исследований равны абсолютному нулю.
Возьмем реальный профиль нагрузки. Промышленный объект, закрытый периметр, требуется predictive-analytics для узлов конвейера. Заявленный бюджет — 40 миллионов рублей. Срок — полгода. Цена фиксированная. Штрафные санкции — классические пени за просрочку. На торги заявляются три игрока. Первый оценивает работу в 38 миллионов, второй — в 25, третий роняет цену до 12 миллионов рублей, чтобы гарантированно забрать лот. Выигрывает, разумеется, третий.
Что происходит дальше? Через шесть месяцев заказчику приносят черную коробку: обертку над базовым алгоритмом градиентного бустинга, натренированным на синтетических логах. На приемо-сдаточных испытаниях (ПСИ) модель выдает фантастические метрики, потому что подрядчик прогнал тесты на тех же данных, на которых обучался. Система уходит в промышленную эксплуатацию. На вторые сутки реальной работы на заводе модель начинает сыпать ложноположительными срабатываниями (False Positives), останавливая производственную линию из-за несуществующих вибраций. Убытки от простоя превышают стоимость контракта за смену. Систему тихо отключают. Формально закупка успешна, бюджет освоен, фактически — деньги сожжены.
Искусственный интеллект категорически не ложится в фикс-цену и фикс-срок. Классическая разработка софта предсказуема: понятна архитектура, понятны человеко-часы на поднятие базы и написание микросервисов. Машинное обучение — это непрерывный эксперимент. Никто в здравом уме не скажет, есть ли в сырых логах вибрации станка тот самый математический сигнал, который позволит предсказывать деградацию подшипника за две недели до отказа. Но контракт подписан, сроки горят, угроза попасть в реестр недобросовестных поставщиков (РНП) маячит на горизонте. Подрядчик начинает подгонять реальность под бумаги.
Обоснование НМЦК на ИИ: почему метод сопоставимых цен мертв
Разница между 44-ФЗ и 223-ФЗ в контексте машинного обучения фундаментальна. 223-ФЗ позволяет маневрировать рамками корпоративного положения о закупках: дробить проект, проводить конкурентные переговоры, использовать гибкие методологии, если это прописано в регламенте. 44-ФЗ бьет по рукам кувалдой регламентов.
Первый барьер — начальная максимальная цена контракта. Стандартный рефлекс отдела закупок: применить метод сопоставимых рыночных цен. Разослать запросы коммерческих предложений (ЗКП) трем вендорам, получить ответы, высчитать среднее. Для поставки серверов это работает. Для уникальной разработки ИИ — нет.
Спецификация «система предиктивной аналитики» не имеет артикула. Вендор А заложит в КП интеграцию готового API облачной нейросети, которая не пройдет требования информационной безопасности заказчика. Вендор Б посчитает обучение тяжелой модели с нуля на кластере из сорока видеокарт A100. Вендор В предложит посадить студентов писать эвристики на Python. Разброс цен составит десятки раз. Профессиональные AI-команды просто проигнорируют запрос, так как оценить трудозатраты без доступа к сырым данным и проведения разведочного анализа (EDA) невозможно.
Единственный легальный и технически честный инструмент для ML-проекта — затратный метод, подкрепленный экспертной оценкой. Вы декомпозируете проект на роли, железо и часы. Бюджет собирается из прозрачных блоков: стоимость разметки (человеко-часы асессоров, умноженные на объем выборки), зарплаты Data Scientist, ML Engineer, MLOps, аренда GPU-мощностей или амортизация on-premise железа заказчика. Контролирующие органы прекрасно принимают такие расчеты: часы, рыночные ставки из открытых IT-исследований, налоги, нормированная прибыль. Это железобетонная защита от обвинений в нецелевом расходовании средств.
Как структурировать этапы закупки: пилот, НИР и метрики вместо вендор-лока
Написать техническое задание без заточки под одного подрядчика — отдельное искусство. Требования вида «система должна использовать фреймворк PyTorch 2.1» или «архитектура нейросети должна базироваться на YOLOv8» — это грубое ограничение конкуренции, которое сносится первой же обоснованной жалобой в ФАС. Технологии устаревают за месяцы. К моменту внедрения появится алгоритм, работающий быстрее и точнее, но юридически вы будете привязаны к устаревшему стеку.
Правильное ТЗ на алгоритмы машинного обучения фиксирует не процесс и не инструменты, а аппаратные ограничения и математические метрики качества. Вы прописываете hardware-лимиты для инференса. Например: нейросеть должна обеспечивать время отклика (latency) менее 50 миллисекунд, потребляя не более 4 ГБ видеопамяти на видеокарте уровня Nvidia T4, работая полностью в закрытом контуре без доступа к внешним API.
Метрики качества должны быть привязаны к бизнес-логике. Забудьте про абстрактную точность (Accuracy). На несбалансированных классах, где поломка происходит в 1% случаев, модель, всегда предсказывающая «все нормально», покажет точность 99%, оставаясь абсолютно бесполезной. ТЗ обязано оперировать полнотой (Recall) и долей ложных срабатываний (False Positive Rate).
Сращивать research-составляющую и продакшен в один контракт — самоубийство. Честный трейд-офф заключается в разделении рисков. Оптимальный путь: закупать первый этап как научно-исследовательскую работу (НИР). Цель НИР — не готовый софт, а ответ на вопрос: решаема ли задача на предоставленных данных. Если бюрократия требует единого контракта, жизненно необходимо жестко структурировать этапы, привязав приемку к проверяемым артефактам.
- Этап первый: сбор исторических данных, очистка и разметка датасета. Артефакт — верифицированный массив данных, который переходит в собственность заказчика. Даже если проект умрет на следующем шаге, у вас останется размеченный фундамент, за который заплачены деньги.
- Этап второй: обучение baseline-модели и доказательство концепции. На этом рубеже фиксируются реальные, достижимые на ваших данных метрики. Становится понятно, нужен ли алгоритм сложнее или придется устанавливать дополнительные датчики на оборудование для обогащения датасета.
- Этап третий: оптимизация модели под целевое железо (квантование, прунинг), разработка обвязки, API-интерфейсов и интеграция в IT-ландшафт предприятия.
- Этап четвертый: приемо-сдаточные испытания строго на отложенной тестовой выборке, которая физически хранится у заказчика и к которой у команды разработки не было доступа на этапе обучения.
Пилот с метриками как стартовый этап отсекает любителей осваивать бюджеты на презентациях. Если модель падает на скрытом датасете, акт не подписывается, проект останавливается с минимальными потерями времени.
У нас в Morana Labs мы решаем это прагматично: отказываемся от проектов с фиксированной ценой, где заказчик требует гарантировать F1-score на уровне 95% до того, как открыл доступ к логам. Мы заходим в суровые индустриальные задачи исключительно через короткий аудит данных. Если сигнал есть — идем в полноценный инференс, edge-вычисления и хайлоад, фиксируя SLA и отвечая за latency. Если данные представляют собой белый шум — говорим об этом прямо, экономя клиенту бюджеты и годы судебных разбирательств.