Тендерная документация с нейросетью: что проверить до заявки

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

В российской практике важно учитывать, по какой процедуре идет закупка: государственная закупка по 44-ФЗ, корпоративная закупка по 223-ФЗ, коммерческий тендер или запрос предложений по внутреннему регламенту заказчика. Официальные карточки и документы обычно публикуются в ЕИС закупок или на электронной площадке. Нейросеть удобна для чтения и сопоставления документов, но она не должна сама решать, можно ли участвовать, подавать жалобу, менять цену или принимать условия контракта.

1. Сначала соберите полный пакет документов

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

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

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

• скачайте извещение, документацию, приложения, проект контракта, формы заявки и все опубликованные разъяснения;
• переименуйте файлы по смыслу: «01-извещение», «02-инструкция», «03-тз», «04-проект-контракта», «05-формы»;
• сохраните дату скачивания и ссылку на карточку закупки;
• отметьте версию документа, если заказчик уже публиковал изменения;
• не смешивайте документы разных лотов, если закупка разбита на части.

Карта документов: что где искать

2. Разделите анализ на роли, а не на файлы

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

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

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

3. Сделайте матрицу соответствия

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

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

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

4. Отдельно проверьте требования к участнику

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

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

Полезный прием - попросить модель составить не список «что нужно», а список причин для отклонения заявки. Такой взгляд жестче: неподписанный файл, неверная форма декларации, просроченный сертификат, нет подтверждения полномочий, опыт не совпадает с предметом закупки, документ относится к другому юрлицу. Затем этот список используют как предфинальную проверку.

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

5. Техническое задание разбирайте на проверяемые параметры

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

В техническом блоке важно отделять требование от способа подтверждения. «Поставить оборудование мощностью не ниже X» - это требование. «Приложить паспорт изделия» - способ подтверждения. «Обеспечить монтаж на объекте» - обязательство исполнения. «Предоставить гарантийное письмо производителя» - документ для заявки. Когда эти сущности смешаны, команда может подтвердить характеристику, но забыть документ, или подать документ, который не доказывает нужный параметр.

Для сложного ТЗ попросите нейросеть построить таблицу «параметр - наше значение - источник подтверждения - риск - вопрос». Например: требуемая совместимость с системой заказчика, наша версия продукта, ссылка на спецификацию, риск интеграции, вопрос о доступе к тестовому стенду. Такой формат сразу показывает, где нужен инженер, где коммерческий расчет, а где запрос разъяснения.

6. Посчитайте коммерческие ограничения до решения об участии

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

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

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

7. Проект контракта проверьте как отдельный документ риска

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

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

Попросите нейросеть выделить пункты, которые нельзя изменить после подачи без риска. В конкурентных закупках участник часто принимает проект контракта целиком, поэтому замечание «потом поправим договор» может быть самообманом. Если условие неприемлемо, это должно попасть в bid/no-bid, а не остаться в комментарии юриста на полях.

Красные флаги в проекте контракта

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

8. Подготовьте вопросы заказчику до окончания срока разъяснений

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

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

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

Timeline подготовки до подачи

9. Соберите решение bid/no-bid

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

Решение bid/no-bid лучше оформлять как одну страницу для руководителя. В ней должны быть предмет закупки, срок подачи, ожидаемая цена, ключевые преимущества, стоп-факторы, открытые вопросы, минимально приемлемая маржа и ответственные за закрытие рисков. Если документ занимает десять страниц, его перестают читать перед дедлайном; если в нем только «участвуем», он не защищает от плохого решения.

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

Bid/no-bid scorecard

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

10. Финальный контроль перед подачей

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

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

Отдельно проверьте, что заявка не содержит лишнего. Иногда команда прикладывает «на всякий случай» старые сертификаты, лишние презентации, документы другого юрлица или коммерческую информацию, которую заказчик не просил. Лишний файл редко усиливает заявку, зато может создать вопрос, противоречие или риск раскрытия данных.

Финальный чек-лист заявки

1. Матрица соответствия закрыта или все открытые пункты вынесены в решение руководителя.
2. Файлы названы понятно, подписаны нужной электронной подписью и соответствуют формату площадки.
3. Версии документов сверены с последними изменениями и разъяснениями заказчика.
4. Цена учитывает обеспечение, логистику, гарантию, отсрочку оплаты и штрафные риски.
5. Проект контракта проверен юристом, а неприемлемые условия вынесены в bid/no-bid.
6. На площадке сохранены подтверждения загрузки, подачи и время отправки заявки.