Как я тестировал ИИ для анализа закупок и понял, что он полезен не там, где от него ждут “магии”

Вокруг ИИ сейчас много ожиданий. Иногда кажется, что от него хотят невозможного: чтобы он сам нашёл закупку, оценил её, принял решение, подготовил заявку, предсказал конкурентов и гарантировал победу.

В реальности закупки так не работают.

Даже опытный специалист не принимает решение только по одному документу или одному признаку. Нужно смотреть предмет закупки, требования к участнику, состав заявки, сроки, оплату, приёмку, риски, проект контракта, техническое задание, приложения, изменения, разъяснения. И всё это ещё нужно соотнести с возможностями команды.

Поэтому, когда я начал тестировать ИИ в закупках, я довольно быстро отказался от идеи «пусть он решит, участвовать или нет». Это слишком грубая постановка задачи.

Гораздо полезнее оказался другой подход: использовать ИИ как помощника на первом проходе по документации.

Не финальное решение. Не юридическое заключение. Не гарантия. А быстрый структурный разбор: что закупают, какие требования, какие сроки, какие документы нужны, где риски и что стоит проверить вручную.

Именно на этом этапе ИИ оказался действительно полезным.

Проблема первичного анализа закупок в том, что он одновременно простой и трудоёмкий. Простая часть — понять, что написано в документах. Трудоёмкая — сделать это внимательно, быстро и много раз подряд.

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

Человек всё это может прочитать. Вопрос — сколько времени он потратит и не устанет ли на потоке.

Первый сценарий, где ИИ мне помог, — быстрое определение предмета закупки. Это особенно важно, когда название сформулировано широко. Например, «сопровождение информационной системы» может означать что угодно: от консультаций до серьёзной доработки функционала.

Я просил ИИ не пересказывать название, а найти в документах признаки реальных работ: разработка, доработка, интеграции, интерфейсы, личный кабинет, портал, API, базы данных, документация, поддержка. Так становится понятнее, подходит закупка по профилю или нет.

Второй сценарий — извлечение сроков и этапов. В закупках важно смотреть не только конечную дату, но и логику исполнения. Когда начинается срок? Есть ли этапы? Что должно передать заказчик? Сколько времени на приёмку? Сколько на исправление замечаний?

Если ИИ просто пишет «срок исполнения — 30 дней», это мало. Но если он показывает, где этот срок указан, от какого события считается и какие рядом есть условия, это уже рабочая информация.

Третий сценарий — анализ требований к заявке. Это очень полезный слой, потому что ошибки здесь могут стоить допуска. Какие документы нужны? Есть ли формы? Нужен ли опыт? Нужно ли подтверждать квалификацию? Есть ли специальные требования к участнику?

ИИ может быстро собрать этот список. Потом человек всё равно проверяет, но стартовая структура уже есть.

Четвёртый сценарий — поиск рисков. Я не прошу ИИ «оценить всё». Я прошу искать конкретные типы рисков:
размытая приёмка;
оплата только после полного исполнения;
жёсткие сроки; неясные обязанности заказчика;
ограничение субподряда;
требования к лицензиям или опыту;
передача исключительных прав;
поддержка после сдачи;
противоречия между документами.

Такой формат работает лучше, потому что ИИ ищет не абстрактные «минусы», а конкретные условия.

Пятый сценарий — подготовка вопросов заказчику. Иногда закупка не плохая, а просто недоописанная. Например, непонятно, кто предоставляет исходные данные, есть ли доступ к системе, какие интеграции уже существуют, как будет проходить приёмка, какие материалы нужно передать.

ИИ может быстро сформировать список уточнений. Это удобно, потому что вопросы лучше задавать до подачи заявки, а не после победы.

Но есть важный момент: ИИ не должен делать выводы без оснований.

Если он пишет «есть риск по срокам», рядом должен быть пункт документа. Если пишет «нужна проверка прав», нужно понимать, из какой формулировки это следует. Если пишет «закупка подходит по профилю», должны быть признаки из ТЗ.

Без привязки к документам такой анализ превращается в красивый пересказ. А красивый пересказ в закупках почти бесполезен.

Поэтому для себя я сформулировал правило: любой вывод должен быть проверяемым.

Именно с этой логикой я начал смотреть на специализированные инструменты для анализа закупок. Не на универсальный чат, куда можно загрузить документ, а на сервис, который изначально заточен под закупочную документацию и типовые проверки.

Один из примеров такого подхода — gos-tender-ai.ru. Я смотрю на подобные системы не как на замену тендерному специалисту, а как на рабочий слой между большим комплектом документов и человеческим решением.

Правильная ценность здесь, на мой взгляд, не в обещании «ИИ всё сделает». Правильная ценность — в ускорении первичного разбора.

Специалисту всё равно нужно принимать решение. Но ему уже не нужно каждый раз начинать с пустого листа. Система может помочь быстро увидеть:

что закупают; какие документы приложены; какие требования к участнику; какие сроки; какая логика оплаты; какие условия приёмки; где возможны риски; что нужно проверить вручную.

Это не магия. Это нормальная аналитическая работа, просто часть рутины делегируется машине.

Самый полезный формат, который я вижу, — не «вердикт одной строкой», а разбор с пояснениями. Например: закупка потенциально подходит, потому что в документах есть признаки разработки личного кабинета и интеграции; при этом нужна проверка по срокам, потому что срок короткий и зависит от передачи доступов; также есть риск по правам, потому что требуется передача исходного кода.

Такой вывод можно обсуждать. Его можно проверить. Его можно дать команде. Он не заменяет человека, но экономит время.

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

Поэтому я бы не доверял ему финальное решение об участии. Но доверял бы первичный разбор, если выводы подкреплены фрагментами документов.

В закупках вообще опасны любые инструменты, которые создают иллюзию полной уверенности. Лучше честное «нужна проверка», чем уверенное, но слабое «всё подходит».

На практике ИИ полезнее всего там, где у специалиста много повторяющихся действий: открыть документы, найти сроки, собрать требования, выписать риски, подготовить вопросы, сделать краткое резюме для команды.

Это не самая эффектная часть работы. Зато именно она съедает много времени.

Мне кажется, что будущее ИИ в закупках не в том, чтобы заменить тендерных специалистов. Скорее, в том, чтобы убрать у них часть механической нагрузки и дать больше времени на решения, где нужен опыт.

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

Если ИИ помогает быстрее добраться до этих вопросов — он уже полезен.

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

Для себя я пока вижу самый здравый сценарий так: ИИ делает черновой анализ, человек проверяет ключевые пункты, команда принимает решение.

Без громких обещаний. Без фантазий про автоматическую победу. Просто более быстрый и структурный способ работать с закупочной документацией.

А в закупках иногда этого уже достаточно, чтобы не тратить время на неподходящие процедуры и внимательнее смотреть те, где действительно есть шанс.