Тендерный специалист тратит на разбор одного пакета документов от двух часов до полного рабочего дня. Большая часть этого времени уходит не на решения, а на механику: найти в техническом задании все параметры, сверить их с тем, что есть у поставщика, вычитать проект контракта, поймать расхождение между извещением и приложением. Именно эту механику ИИ забирает почти целиком — при условии, что процесс выстроен, а результат проверяется.
Ниже — рабочий порядок разбора закупки: что подготовить, в какой последовательности задавать вопросы, как формулировать запросы, чтобы нейросеть не додумывала, и как за пять минут убедиться, что ответу можно доверять. Без общих слов про «трансформацию отрасли».
Статья отвечает на вопрос «как выстроить процесс», а не «стоит ли вообще применять ИИ» и «какой инструмент выбрать». Если вы ещё на этапе оценки — сначала прочитайте разбор что ИИ реально умеет в тендерной работе и где не заменит специалиста: там границы применимости, устройство технологии и критерии выбора сервиса.
Что меняет ИИ в разборе закупки
Ручной разбор устроен линейно: специалист читает документы подряд и держит в голове десятки требований одновременно. Ошибка возникает не там, где сложно, а там, где внимание уже израсходовано — на сорок седьмой странице приложения, в примечании мелким шрифтом, в расхождении между двумя редакциями одного пункта.
ИИ меняет не скорость чтения, а структуру работы. Вместо «прочитать всё и запомнить» появляется «извлечь в таблицу и проверить построчно». Специалист перестаёт быть парсером документов и становится контролёром: он проверяет не сто страниц, а сорок строк таблицы, из которых спорны две.
Шаг 0: что подготовить до первого запроса
Половина неудачных разборов проваливается здесь. Нейросеть не умеет читать то, чего нет: если файл — это скан без текстового слоя, модель получит на вход изображение и в лучшем случае распознает его с ошибками, а в худшем — достроит нечитаемые фрагменты «по смыслу». Именно так появляются пункты, которых в документации не было.
| Что на входе | Что с этим делать | Риск, если пропустить |
|---|---|---|
| Текстовый PDF, DOCX, XLSX | Загружать как есть, без предварительной чистки | — |
| Скан или фотография | Сначала распознать, затем выборочно сверить числа с оригиналом | Подмена цифр и единиц измерения при распознавании |
| Таблица со сложной разметкой | Загружать целиком; не резать объединённые ячейки вручную | Потеря привязки значения к строке требования |
| Архив со всей закупкой | Разложить по ролям: извещение, техническое задание, проект контракта, формы | Модель смешивает требования из разных документов |
| Две редакции одного документа | Пометить, какая действующая, и работать только с ней | Разбор устаревшей версии — самая дорогая из ошибок подготовки |
Отдельно про объём. Заманчиво загрузить весь архив закупки одним куском и попросить «разобрать всё». На практике это худший из возможных сценариев: чем больше разнородного текста в одном запросе, тем выше шанс, что требование к участнику из извещения будет процитировано как пункт технического задания. Документы разного назначения разбираются раздельно — и сводятся только на этапе поиска противоречий.
Порядок разбора: восемь шагов
Последовательность не произвольная. Она построена так, чтобы самые дешёвые проверки шли первыми: если закупка отсекается на втором шаге, вы не потратите час на разбор технического задания.
Резюме закупки на одной странице
Первый запрос — не «проанализируй», а «изложи». Предмет закупки, начальная цена, сроки поставки, место, обеспечение заявки и контракта, ключевые даты. Это тридцать секунд чтения вместо десяти минут пролистывания извещения, и именно с этого резюме принимается решение, стоит ли идти дальше.
Требования к участнику и быстрый отсев
Лицензии, членство в СРО, опыт исполнения аналогичных контрактов, отсутствие в реестре недобросовестных поставщиков, национальный режим. Просите вывести их списком с пометкой, где каждое зафиксировано. Одно непроходимое требование закрывает лот — и дальше можно не читать. Тонкости подтверждения происхождения товара разобраны отдельно в статье про национальный режим в закупках.
Извлечение требований технического задания построчно
Основной этап. Задача — превратить сплошной текст в таблицу, где каждая строка это одно проверяемое требование с указанием пункта-источника. Важно требовать разделения на «жёсткие» значения и диапазоны: «не менее 2000 Вт» и «от 1800 до 2200 Вт» проверяются по-разному, а в исходном тексте выглядят одинаково буднично.
Сверка с документами вашего оборудования
К извлечённым требованиям добавляется вторая колонка — фактические характеристики из ваших документов, со ссылкой на страницу источника. На выходе получается матрица соответствия; её структура разобрана ниже. Именно здесь всплывают расхождения, которые при ручном чтении теряются: не противоречия, а «почти совпадения».
Проект контракта — отдельным заходом
Проект контракта разбирается не вместе с техническим заданием, а после него, и по своему списку вопросов: сроки и порядок приёмки, размер и основания начисления неустойки, условия одностороннего отказа, гарантийные обязательства, порядок оплаты. Требования к товару в контракте и в техническом задании обязаны совпадать — расхождение между ними часто и есть главная находка разбора.
Поиск противоречий между документами
Единственный шаг, где документы сводятся вместе. Запрос строится как сопоставление: сравнить требования к товару из технического задания, проекта контракта и форм заявки, найти пункты, где значения, сроки или единицы измерения расходятся. Противоречие в документации — не повод угадывать: это повод отправить запрос на разъяснение через ЕИС в установленный срок.
Первичная оценка рисков
Не «оцени шансы на победу» — такой прогноз ничем не обоснован. Полезный запрос звучит иначе: перечислить пункты, формулировка которых допускает несколько толкований, и требования, подтверждение которых потребует документов, которых у поставщика может не оказаться. Это список тем для юриста и снабженца, а не оценка вероятности.
Сравнение версий и финальный чек-лист
Если заказчик вносил изменения — сравнивайте редакции по пунктам, а не перечитывайте документ заново. Финальный шаг: свести всё в чек-лист «что приложить к заявке», где напротив каждого требования стоит конкретный документ. Ручную проверку по 44-ФЗ поверх этого списка не отменяет никто — она разобрана в пошаговом чек-листе проверки документов.
Формулировки запросов, которые работают
Качество разбора определяется формулировкой запроса сильнее, чем выбором конкретной нейросети. Работают четыре принципа: задать роль и предмет, ограничить источник, задать формат ответа и явно разрешить ответ «не найдено». Последнее важнее остальных: если модели не дать права не найти ответ, она его придумает.
| Слабая формулировка | Рабочая формулировка | Что изменилось |
|---|---|---|
| «Проанализируй это техническое задание» | «Выпиши все требования к товару в таблицу: требование, значение, единица измерения, номер пункта» | Задан формат результата вместо свободного пересказа |
| «Какие есть требования к поставщику?» | «Перечисли требования к участнику только из раздела 3 извещения, с цитатой по каждому» | Ограничен источник — исключено смешивание документов |
| «Всё ли соответствует?» | «Сравни столбцы "требование" и "факт" построчно, отметь строки, где значение не соответствует или не подтверждено» | Проверка стала построчной и проверяемой |
| «Найди риски» | «Перечисли пункты, формулировка которых допускает более одного толкования, с цитатой и объяснением неоднозначности» | Вместо оценки — конкретный перечень для юриста |
| «Есть ли требование по гарантии?» | «Есть ли требование по гарантийному сроку? Если в документе его нет — ответь "не найдено", не предполагай» | Разрешён отрицательный ответ — снят стимул выдумывать |
Ниже — три заготовки, которые закрывают основную часть разбора. Их достаточно адаптировать под свой предмет закупки.
Извлечение требований технического задания:
Ты работаешь с техническим заданием закупки. Используй только текст
приложенного файла, ничего не добавляй от себя.
Выпиши все требования к товару в таблицу с колонками:
1) требование, 2) значение, 3) единица измерения,
4) тип (точное значение / не менее / не более / диапазон),
5) номер пункта, 6) дословная цитата.
Если значение указано словами без числа — так и запиши,
не переводи в число. Если раздел не содержит требований —
напиши «требований не найдено».Поиск противоречий между документами:
Перед тобой техническое задание и проект контракта одной закупки.
Сравни требования к товару, срокам поставки и приёмке.
Выведи только те пункты, где документы расходятся, в формате:
что требует техническое задание (пункт, цитата) — что требует
проект контракта (пункт, цитата) — в чём расхождение.
Совпадающие пункты не перечисляй. Если расхождений нет —
напиши об этом одной строкой.Разбор проекта контракта:
Разбери проект контракта и ответь строго по пунктам,
с указанием номера пункта и цитаты:
1. Срок поставки и порядок приёмки
2. Размер неустойки и основания начисления
3. Основания одностороннего отказа заказчика
4. Гарантийные обязательства и их срок
5. Порядок и сроки оплаты
6. Обеспечение исполнения контракта
По каждому пункту, которого в контракте нет,
напиши «в проекте контракта не установлено».Нейросеть не знает ни состава участников, ни их ценовой политики, ни закупочной практики конкретного заказчика. Ответ на такой вопрос всегда будет выглядеть уверенно и никогда не будет обоснован. Оценка перспектив лота — работа человека, у которого есть история торгов по этому заказчику.
Матрица соответствия: ради чего всё затевалось
Резюме и списки — промежуточный результат. Настоящий артефакт разбора — таблица, по которой видно, чем именно вы подтверждаете каждое требование заказчика. Она же становится основой технического предложения и рабочим документом для приёмки.
| Требование | Пункт ТЗ | Факт по нашему товару | Чем подтверждается | Статус |
|---|---|---|---|---|
| Мощность не менее 2000 Вт | п. 4.2.1 | 2200 Вт | Техническое описание, с. 7 | Соответствует |
| Гарантийный срок не менее 24 мес. | п. 6.1 | 24 мес. | Гарантийное письмо производителя | Соответствует, впритык |
| Класс защиты IP54 | п. 4.2.9 | IP55 | Техническое описание, с. 9 | Требует пояснения в заявке |
| Наличие в реестре российской продукции | п. 2.4 | Реестровая запись № … | Выписка из реестра | Соответствует |
| Комплект поставки: 4 позиции | п. 5.3 | 3 позиции | — | Не подтверждено |
Обратите внимание на третью и пятую строки. «IP55 вместо IP54» — параметр лучше требуемого, и это обычно допустимо, но обязано быть проговорено в предложении, иначе комиссия читает несовпадение как несоответствие. «Комплект из 3 позиций вместо 4» — прямое основание для отклонения, и обнаружить его нужно за неделю до подачи, а не в день окончания приёма заявок. Как из такой таблицы собирается техническое предложение, разобрано в статье про заполнение формы технического предложения, а подробный разбор самого артефакта — на странице таблицы соответствия техническому заданию.
Пять правил проверки результата
Разбор без проверки бесполезен: заявку подаёте вы, и отвечаете за её содержание тоже вы. Проверка занимает пять–десять минут, если знать, где именно ошибается ИИ. Ошибается он предсказуемо — вот пять мест.
Требуйте цитату и номер пункта по каждой строке
Утверждение без ссылки на источник проверить невозможно, а значит, использовать нельзя. Если в ответе есть цитата и номер пункта — проверка сводится к тому, чтобы открыть документ и убедиться, что пункт существует и звучит именно так.
Числа и единицы измерения проверяйте всегда
Это самое частое место ошибки, особенно при работе со сканами: «2000» превращается в «200», киловатты в ватты, миллиметры в сантиметры. Смысл фразы при этом сохраняется, и глазами подмена не ловится — ответ выглядит совершенно правдоподобно.
Перепроверяйте отрицания и исключения
Конструкции «не допускается», «за исключением случаев», «кроме поставок, осуществляемых…» относятся к сложным для любой автоматической обработки. Потеря частицы «не» переворачивает смысл требования на противоположный, а в пересказе это незаметно.
Задайте контрольный вопрос с несуществующим требованием
Простой тест на добросовестность: спросите про пункт, которого в документе заведомо нет — например, про требование к цвету корпуса или к сертификату, не относящемуся к предмету закупки. Корректный ответ: «в документе не найдено». Развёрнутый ответ по существу означает, что модель достраивает недостающее, и всему разбору доверять нельзя.
Критичные пункты читайте в оригинале сами
Обеспечение заявки и контракта, сроки поставки, условия приёмки, основания одностороннего отказа, национальный режим. Это пункты, цена ошибки в которых — контракт целиком, поэтому по ним разбор ИИ используется как навигация к нужной странице, а не как замена чтению.
Результат разбора — это предварительный анализ, а не заключение, на которое можно сослаться. Ни один вывод ИИ не должен попадать в заявку, не будучи сверенным с оригиналом документа. Экономия времени возникает не оттого, что вы перестаёте проверять, а оттого, что знаете, что именно проверять.
Три решения, которые нельзя делегировать
Границы применимости ИИ подробно разобраны в обзоре возможностей ИИ в тендерной работе. Здесь — только то, что касается процесса разбора напрямую: три точки, где ответственность не передаётся инструменту ни при каких условиях.
- Юридическая квалификация требования. Вопрос «правомерно ли заказчик установил это требование» — предмет работы юриста и, при необходимости, жалобы в ФАС. ИИ может найти формулировку и показать, что она неоднозначна, но не может оценить её законность.
- Ценовое решение. Насколько снижать цену, идти ли ниже порога антидемпинговых мер, чем подтверждать добросовестность — это решение с деньгами и риском, у которого нет правильного ответа в документации. Механика порога разобрана в статье про антидемпинговые меры по 44-ФЗ.
- Финальное решение о подаче. Заявку подписывает и подаёт человек, и отклонение по несоответствию — тоже его результат. Разбор ИИ входит в основание решения, но не является им.
Универсальный чат или специализированный сервис
Всё описанное выше воспроизводится в любом чате с ИИ, куда можно загрузить файл. Разница между таким разбором и специализированным сервисом — не в «уме» модели, а в трёх свойствах, которые в тендерной работе стоят дороже качества отдельного ответа.
Универсальный чат
- Порядок разбора каждый раз выстраивается заново вручную
- На один и тот же файл возможны разные ответы
- Ссылка на пункт документа — только если её потребовать
- Результат приходится переносить в таблицу руками
- Ноль затрат на внедрение, годится для разовой закупки
Специализированный сервис
- Фиксированный сценарий разбора — результат воспроизводим
- Ссылка на пункт-источник по каждой строке по умолчанию
- Таблица соответствия на выходе, без ручного переноса
- История разборов по проекту и сравнение редакций
- Оправдан от нескольких закупок в месяц
Честный критерий выбора простой: если вы разбираете одну-две закупки в квартал, выстроенного процесса и хороших формулировок запросов достаточно. Если закупок десятки, узким местом становится не разбор, а перенос результата в таблицу и повторяемость — и здесь ручная сборка съедает всю выигранную экономию. TenScan закрывает именно этот участок: извлекает требования из технического задания, сверяет их с документами оборудования и отдаёт готовую таблицу соответствия со ссылкой на пункт по каждой строке.
Частые вопросы
С какого документа начинать разбор закупки?
С извещения, а не с технического задания. В извещении собраны отсекающие условия: способ закупки, обеспечение, сроки, требования к участнику. Если хотя бы одно непроходимо, разбирать техническое задание уже не нужно — на большом потоке лотов эта последовательность экономит больше времени, чем любая другая оптимизация.
Почему нейросеть выдумывает пункты, которых нет в документации?
Две основные причины. Первая — загружен скан без текстового слоя, и нечитаемые фрагменты достраиваются по смыслу. Вторая — запрос сформулирован так, что предполагает наличие ответа: на вопрос «какое требование к гарантии?» модель ищет требование, а не проверяет, есть ли оно. Лечится проверкой распознавания файла и явным разрешением ответить «не найдено».
Можно ли доверить нейросети проверку соответствия товара техническому заданию?
Извлечение требований и первичную сверку — да, это и есть основная экономия времени. Итоговое решение о соответствии остаётся за специалистом: числовые допуски, единицы измерения и формулировки с отрицанием требуют проверки по оригиналу. Практически это выглядит так: ИИ готовит таблицу из сорока строк, вы проверяете числа и разбираетесь с двумя-тремя спорными.
Что делать, если заказчик внёс изменения в документацию?
Сравнивать редакции по пунктам, а не перечитывать документ заново. Загрузите обе версии, запросите таблицу отличий с номерами пунктов и проверьте вручную только те строки матрицы соответствия, которых изменения коснулись. Один изменённый параметр в техническом задании способен обнулить заранее собранную заявку — и заметить это нужно до подачи.
Обязательно ли загружать документы в сервис — что с конфиденциальностью?
Документация государственных закупок по 44-ФЗ публикуется в ЕИС и не является закрытой. Осторожность нужна с другим: с вашими внутренними документами — ценовыми расчётами, письмами производителей, условиями дистрибуции. Перед внедрением любого сервиса проверьте, где хранятся загруженные файлы и используются ли они для обучения; для закупок по 223-ФЗ с закрытой документацией этот вопрос решается до первой загрузки, а не после.
Сколько времени реально экономит такой процесс?
На среднем лоте из 5–10 позиций: 2–4 часа ручного разбора против 30–50 минут с ИИ, включая обязательную проверку. На крупном лоте разрыв больше — день против полутора-двух часов. Но экономия появляется только при выстроенном порядке: бессистемные вопросы в чате дают ощущение работы и почти не сокращают время.
Перестаньте проверять документы вручную
TenScan анализирует ТЗ и сверяет документы оборудования с требованиями за 10 минут. Каждое несоответствие выявлено до подачи заявки — а не после её отклонения.