Иллюстрация: светлое пространство для профессионального обучения
Старт

Проверка тендера с ИИ: как принять решение до подготовки заявки

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

21 октября 2026 г. · 12 мин чтения

Проверка тендера с ИИ: как принять решение до подготовки заявки

1. Сначала определяем, какое решение нам нужно

Заметная цена закупки легко создаёт ощущение привлекательного заказа, хотя сама по себе почти ничего не говорит о будущей прибыли исполнителя. Мы предлагаем начинать с другого вопроса: какие обстоятельства заставят нас отказаться от участия ещё до расчёта предложения и оформления документов? Для одного поставщика таким обстоятельством станет неподтверждённый опыт, для другого — невозможность соблюдать график, для третьего — слишком большая потребность в оборотных средствах. Поэтому результат первичного анализа должен выглядеть не как красивое описание закупки, а как перечень проверенных оснований для управленческого решения. ИИ полезен именно здесь: он помогает систематизировать большой пакет, но не получает полномочий самостоятельно оценивать юридические последствия или подписывать вывод за участника.

Возьмём для учебного разбора закупку ежедневной информационной услуги с продолжительностью исполнения один год и ориентиром бюджета около 1,83 миллиона рублей. В условиях предусмотрены утренний срок передачи результата, ограничение на привлечение субподрядчиков, подтверждение ранее выполненных аналогичных работ и расчёты после окончания квартала. Для оказания услуги также нужны платные медиаресурсы, а документы распределены между техническим заданием, договорными условиями, формами и сопутствующими файлами. Этот набор фактов уже позволяет сформировать направления проверки, но ещё не даёт оснований считать заказ подходящим или заведомо невыгодным. Мы намеренно отделяем сведения о закупке от предположений о конкретной компании: её опыт, штат, налоговый режим и финансовый запас предстоит установить отдельно.

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

2. Собираем документы и устанавливаем границы доверия

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

Следующий этап — техническая проверка содержимого, особенно когда документы представлены сканами, сложными таблицами или файлами с большим количеством приложений. Мы выборочно сравниваем распознанный текст с оригиналом и проверяем, не исчезли ли отрицания, примечания, единицы измерения или заголовки столбцов. В электронных таблицах смотрим скрытые листы, формулы и пояснения к заполнению, если они доступны в полученном комплекте и имеют значение для предложения. Договор и техническое задание анализируем совместно: объём работы может описываться в одном месте, а порядок сдачи и последствия просрочки — в другом. При обнаружении противоречия сохраняем обе формулировки с указанием расположения, но не поручаем модели произвольно выбирать ту, которая удобнее потенциальному исполнителю.

Отдельно проверяем, какие сведения вообще допустимо передавать выбранному сервису и позволяет ли это принятый в компании порядок работы с информацией. Публичность закупочной документации не означает, что можно без ограничений прикладывать внутренние расчёты, персональные данные сотрудников или договоры с другими клиентами. Мы по возможности обезличиваем материалы, убираем лишние сведения и используем инструменты, соответствующие требованиям организации к обработке и хранению данных. В самом задании запрещаем выполнять инструкции, обнаруженные внутри загруженных файлов: их содержимое рассматривается как предмет анализа, а не как команды системе. После этого сохраняем исходный комплект отдельно от результатов обработки, чтобы любое существенное заключение можно было повторно проверить без обращения к памяти нейросети.

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

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

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

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

4. Переводим техническое задание в производственный график

После проверки допуска мы разбираем услугу на последовательные операции: получение материалов, отбор сообщений, проверку содержания, подготовку результата и его передачу заказчику. Для каждой операции определяем исполнителя, необходимое время, зависимость от предыдущего этапа и способ контроля качества до установленного срока. Если готовый обзор требуется к семи утра, расчёт начинаем с этого момента и движемся назад, учитывая редактуру и техническую отправку. Средняя продолжительность обработки здесь менее показательна, чем возможность завершить работу в день с необычно большим количеством публикаций или задержкой доступа. Поэтому просим производственную команду оценивать не абстрактную занятость за месяц, а реальное ежедневное окно, в которое должны поместиться все обязательные действия.

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

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

5. Считаем стоимость исполнения и потребность в деньгах отдельно

Финансовый расчёт начинаем с ожидаемой цены договора, а не с максимального бюджета, который участник может не сохранить по итогам процедуры. Далее учитываем применимые налоги, оплату труда, обязательные начисления, программные инструменты, доступ к публикациям, контроль качества и обоснованные накладные расходы. Собственную работу руководителя или владельца тоже оцениваем, иначе сравнение самостоятельного исполнения с наймом сотрудника получится заведомо искажённым в пользу первого варианта. Если часть инфраструктуры уже используется в других проектах, отделяем дополнительные затраты нового заказа от расходов, которые компания понесёт независимо от него. При этом проверяем наличие свободной мощности: существующая подписка или рабочая система ещё не означают, что новый объём можно обслужить без дополнительных людей.

Для услуги медиаподбора отдельно проверяем коммерческие условия доступа к изданиям и разрешённые способы использования полученного контента в передаваемом результате. Расходы на подписки не исчерпывают вопрос: доступ сотрудника к публикации не обязательно даёт право воспроизводить её целиком для другого лица. Затем строим несколько вариантов экономики, меняя цену предложения, трудоёмкость и стоимость обязательных ресурсов в пределах обоснованных предположений. Возможность пересмотра цены на последующих этапах учитываем только тогда, когда соответствующий механизм действительно предусмотрен правилами рассматриваемой процедуры, а не встречался когда-то раньше. По каждому варианту смотрим, остаётся ли приемлемый результат после всех расходов и какой фактор быстрее других делает исполнение экономически нецелесообразным.

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

6. Ставим ИИ проверяемую задачу и оформляем решение

Мы рекомендуем разбивать анализ на несколько запросов, чтобы модель не пыталась одновременно проверить право, оценить производство и придумать окончательный бизнес-вывод. В первом задании просим извлечь условия, влияющие на участие и исполнение, с указанием документа, пункта или другого доступного ориентира. Во втором сопоставляем эти условия с отдельно предоставленными сведениями об участнике, явно запрещая восполнять недостающий опыт или ресурсы предположениями. В третьем поручаем проверить расчётную модель и перечислить факторы, изменение которых способно повлиять на решение, не требуя прогноза с неподтверждённой точностью. Каждый этап завершаем перечнем вопросов, на которые комплект документов не даёт ответа, чтобы неопределённость оставалась видимой, а не исчезала внутри уверенного резюме.

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

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

7. Используем отказ для улучшения следующих отборов

Если участие прекращено, мы сохраняем причину в структурированном виде: неподтверждённый допуск, недостаток мощности, неприемлемая экономика, дефицит финансирования или существенная неясность условий. Не стоит объединять всё под отметкой неинтересно, потому что разные причины требуют совершенно разных изменений в дальнейшей закупочной работе компании. Отсутствие подходящего опыта может подсказать направление развития портфеля, а неподъёмный график — необходимость другой организации команды или выбора менее интенсивных услуг. Слишком низкая расчётная доходность помогает уточнить ценовые границы поиска, но не доказывает, что аналогичный заказ окажется невыгодным при другом объёме. Так отрицательное решение превращается в материал для настройки отбора, а не остаётся забытым разговором между менеджером и руководителем после просмотра документов.

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

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

Ещё 3 раздела в PRO

Чек-листы, разбор типичных ошибок и пошаговые шаблоны к этому уроку — примерно на 40% больше материала.

Все уроки