В закупке дорогая ошибка часто возникает не в строке с самой высокой ценой. Она прячется в формулировке «аналог», в исключённой из поставки позиции, в сроке, который начинается после дополнительного согласования, или в версии технического задания,…
В закупке дорогая ошибка часто возникает не в строке с самой высокой ценой. Она прячется в формулировке «аналог», в исключённой из поставки позиции, в сроке, который начинается после дополнительного согласования, или в версии технического задания, которую один из поставщиков вообще не видел.
Когда на столе лежат три–пять коммерческих предложений, несколько приложений и ТЗ на десятки страниц, закупщик тратит время не на выбор, а на сбор сопоставимых данных. Большая языковая модель может снять именно эту рутину. Она извлечёт характеристики, соберёт таблицу расхождений, найдёт отсутствующие условия и подготовит вопросы поставщикам.
Выбирать победителя, трактовать договор и подтверждать техническую выполнимость она не должна. Экспертом остаётся закупочная команда, технический заказчик и юрист. ИИ здесь работает как стажёр с красным дипломом: быстро читает большой массив документов, аккуратно раскладывает его по полкам, но нуждается в проверке результата.
Где ИИ действительно полезен в закупке
БЯМ хорошо справляется с задачами, где нужно прочитать много текста, привести разрозненные формулировки к единой структуре и показать человеку, что именно требует внимания. Для закупок это означает четыре практических результата.
- Карточка каждого документа с реквизитами, версией и ключевыми условиями.
- Матрица соответствия ТЗ и каждого коммерческого предложения.
- Реестр рисков с цитатой из исходного документа и вопросом для уточнения.
- Черновик протокола выбора поставщика, который затем проверяет и утверждает комиссия.
Это не магия и не автоматизация решения. Модель предсказывает наиболее вероятное продолжение текста. Поэтому она может уверенно написать то, чего нет в документе, перепутать версии приложений или назвать эквивалентным оборудование с похожим, но неполным набором характеристик. NIST называет такой риск confabulation — правдоподобный, но ошибочный ответ генеративной модели. Особенно он опасен в задачах, где решение зависит от контекста и предметной экспертизы. NIST Generative AI Profile
Отсюда следует важный рабочий принцип: результат ИИ должен быть проверяемым. В каждой существенной строке нужны ссылка на файл, номер страницы или раздел и короткая цитата. Если подтверждения нет, в ячейке должно стоять «не найдено в документе», а не догадка модели.
Начинать нужно с границ задачи, а не с загрузки файлов
Плохой сценарий выглядит просто. Сотрудник загружает в чат папку с документами и пишет «сравни предложения, выбери лучшее». В ответ приходит гладкая таблица с цветными отметками. Она может выглядеть убедительно, но никто не понимает, какая версия ТЗ использована, где модель увидела цену и почему посчитала условие выполненным.
Нормальный процесс начинается с фиксации входящих материалов. Для каждого файла нужен идентификатор, название, дата получения, версия, источник, ответственный сотрудник и статус. Если приложений несколько, важно явно указать, какие из них обязательны для оценки, а какие справочные. До анализа полезно согласовать перечень критериев и обязательных требований, допустимые источники для подтверждения каждого критерия, состав людей, которые будут проверять техническую, коммерческую и юридическую части.
Сканированный PDF сначала нужно распознать, затем выборочно сверить OCR с оригиналом. Таблицы с мелким шрифтом, примечания к спецификации, подписи на схемах и зачёркнутые условия часто меняют смысл сильнее, чем основной текст. Модель может извлечь их неверно, а закупщик должен увидеть эту проблему до формирования выводов.
Отдельно определяется контур обработки. В коммерческих предложениях встречаются контакты, подписи, банковские реквизиты, сведения о сотрудниках и другая чувствительная информация. Перед передачей документов во внешнюю систему нужно определить допустимый маршрут данных вместе с ИБ и юристами, проверить внутреннюю политику, договорные ограничения и применимое регулирование персональных данных. Базовый правовой ориентир для российских организаций — Федеральный закон № 152-ФЗ. Сам ИИ не должен делать юридический вывод о том, можно ли передавать конкретный пакет документов.
Для задач с особенно жёстким контуром пригодится отдельный материал об ИИ в финансовой организации и требованиях к данным.
Сначала превратите ТЗ в структуру
Техническое задание редко написано как готовая таблица для сравнения. В одном разделе характеристики указаны численно, в другом — через ссылку на стандарт, в третьем — через описание результата работ. Первое задание для модели состоит не в том, чтобы оценить поставщиков, а в том, чтобы разложить ТЗ на атомарные требования.
Для производственного оборудования это могут быть производительность, диапазон рабочих температур, габариты, совместимость, состав поставки, пусконаладка, документация, обучение персонала и гарантия. В строительной закупке добавятся объём работ, допуски, этапность, материалы, исполнительная документация и условия доступа на площадку.
| Поле | Что фиксируем |
|---|---|
| Код требования | Уникальный номер для ссылки в таблице и протоколе |
| Требование ТЗ | Дословная или аккуратно нормализованная формулировка |
| Тип | Обязательное, оцениваемое, справочное |
| Единица измерения | Штуки, метры, киловатты, дни, проценты |
| Источник | Файл, страница, раздел, цитата |
| Проверяющий | Технический заказчик, закупки, юрист, ИБ |
В промте важно запретить модели дополнять ТЗ знаниями из интернета или «типовыми характеристиками». Если параметр не указан, это пробел ТЗ, который должен увидеть заказчик.
Работай только с приложенным ТЗ. Выдели атомарные требования в таблицу. Для каждого требования укажи файл, страницу, раздел и цитату до 25 слов. Не объединяй разные характеристики. Не предполагай отсутствующие значения. Если информация неоднозначна, пометь «требует уточнения».
Такой подход кажется медленнее одного большого запроса, но на практике он быстрее. Сначала появляется проверяемая база сравнения. Затем можно обрабатывать предложения поставщиков по одинаковой схеме. Это продолжение учебного принципа «несколько простых промтов лучше одного идеального»: отдельно извлечь данные, отдельно нормализовать, отдельно сопоставить, отдельно подготовить вопросы.
Коммерческие предложения нужно читать по одному шаблону
Каждое КП извлекается в ту же структуру, что и ТЗ. Модель не получает задачу «соответствует или нет» на первом шаге. Её задача проще и надёжнее: найти фактическое утверждение поставщика и показать, откуда оно взято.
Минимальная карточка предложения включает предмет поставки, модель или артикул, характеристики, комплектацию, цену и валюту, НДС, срок действия предложения, срок поставки, условия оплаты, гарантию, исключения, обязательства заказчика и приложенные документы.
Особое внимание стоит уделить словам, которые часто выглядят как подтверждение, но ими не являются. «Соответствует ТЗ», «аналог», «по согласованию», «в стандартной комплектации», «ориентировочный срок», «при наличии на складе» — это маркеры для дополнительной проверки. Рядом с ними должна появляться отдельная строка «что именно подтверждено» и «чего не хватает для подтверждения».
Числа тоже требуют дисциплины. Модель может пересчитать стоимость комплекта, привести единицы измерения или построить сравнительную цену. Но закупщик должен проверить, включены ли НДС, доставка, монтаж, упаковка, запасные части и обязательные работы. Цена за единицу и цена за весь объём могут быть несопоставимы, если один поставщик считает комплект, а другой — позицию.
Полезно задавать модели правило: любое преобразование единиц показывать отдельной формулой и исходным значением. Если для расчёта не хватает данных, модель должна формулировать вопрос, а не достраивать цифру.
Матрица соответствия должна показывать доказательства
После извлечения ТЗ и КП начинается собственно сравнение. В этом месте ИИ уже полезно попросить найти расхождения, но решение нужно строить на исходных строках, а не на его итоговой оценке.
| Критерий | Требование ТЗ | Поставщик А | Поставщик Б | Поставщик В | Статус | Действие |
|---|---|---|---|---|---|---|
| Производительность | Не менее указанного значения | Значение и страница | Значение и страница | Не найдено | Проверить | Запросить характеристику |
| Комплект поставки | Перечень обязательных позиций | Полный перечень | Есть исключение | Формулировка общая | Риск | Сверить спецификацию |
| Срок поставки | Указанный срок | Подтверждён | После согласования | Не указан | Риск | Уточнить дату |
| Гарантия | Минимальный срок | Подтверждена | Подтверждена с условиями | Не найдена | Проверить | Запросить письмо |
Ключевая колонка здесь — источник. Без неё таблица превращается в мнение модели. С ней она становится навигатором для специалиста, который за несколько минут переходит к нужному месту документа и подтверждает или исправляет запись.
Сопоставь карточки поставщиков с требованиями ТЗ. Для каждого вывода укажи код требования, цитату из ТЗ, цитату из КП и статус «подтверждено», «частично подтверждено», «не найдено» или «противоречие». Не используй статус «соответствует», если решение требует технической или юридической оценки.
Этот запрет важен. «Подтверждено документом» — факт извлечения. «Соответствует ТЗ» — решение предметного эксперта. Между ними лежит ответственность, которой у модели нет.
Сначала вопросы, затем новая версия матрицы
После первого сравнения полезно не пытаться объяснить все пробелы внутри комиссии. Лучше сформировать короткий, одинаково структурированный запрос каждому поставщику. ИИ помогает подготовить этот черновик, но отправляет его сотрудник закупок. Вопрос должен ссылаться на конкретный код требования и документ, а поставщику нужно дать понятный формат ответа: подтверждение, значение параметра, ссылка на приложение или причина, по которой условие не выполняется.
Запрос «подтвердите соответствие ТЗ» почти всегда даёт слабый результат. Поставщик отвечает общей формулой, а неопределённость остаётся. Рабочий запрос звучит иначе: «По требованию ТЗ R-17 необходим монтаж на площадке заказчика. В КП такая работа отдельно не указана. Подтвердите включение, объём работ, цену и срок выполнения либо укажите исключение». Здесь модели достаточно извлечь факт и собрать вопрос. Оценку достаточности ответа делает закупщик вместе с техническим заказчиком.
Ответы поставщиков не должны заменять исходное КП бесследно. Каждому письму, уточнённой смете и новой спецификации нужен свой идентификатор и дата. В матрице остаётся первоначальная строка, рядом появляется уточнение, источник и статус проверки. Иначе через несколько недель невозможно восстановить, было ли важное условие частью предложения с самого начала или появилось после дополнительного запроса.
Это особенно полезно в строительных и производственных закупках, где часть условий зависит от обследования площадки, рабочего проекта или согласования интерфейсов между системами. Модель способна сгруппировать эти зависимости, но не может принять риск от имени заказчика. Если срок поставки начинается после события, комиссия должна видеть само событие, владельца действия и предельный срок, а не только обещание поставщика «оперативно согласовать».
Какие риски ИИ должен находить
Модель хорошо работает как второй читатель документов. Она не заменяет инженера или контрактного менеджера, зато удерживает внимание на типовых пробелах, которые легко пропустить в конце рабочего дня. Риски стоит собирать в четыре группы.
- Технические — неподтверждённые характеристики, несовместимость, неполная комплектация, отсутствие обязательных сертификатов или документации.
- Коммерческие — разная база цены, НДС, упаковка, минимальный объём заказа, валюта, условия оплаты и логистика.
- Исполнительские — расплывчатые сроки, зависимость от согласований, ограничения гарантии, неуказанные работы на площадке.
- Документные — конфликт версий, нечитабельный скан, ссылка на отсутствующее приложение, разная терминология для одной позиции.
Для каждой записи полезно фиксировать не только предполагаемую серьёзность, но и причину. Хороший формат — «риск», «источник», «возможное последствие», «вопрос поставщику», «владелец проверки», «статус». Тогда модель не раздаёт абстрактные красные флажки, а готовит конкретную работу.
Например, «срок поставки не подтверждён» — слабая запись. «В КП указан срок после согласования рабочей документации, а срок согласования не определён. Уточнить календарную дату готовности и зависимые действия заказчика» — уже рабочий вопрос.
В учебных разборах документов модель быстро собирает номер файла, название договора, основные риски и краткий вывод. Но финальная проверка остаётся обязательной. Галлюцинации не исчезают после удачного промта, поэтому контроль качества должен быть частью процесса, а не последним необязательным действием.
Протокол выбора поставщика ИИ готовит, а комиссия утверждает
Протокол нужен не для красивой фиксации уже принятого решения. Он должен показать, на каких критериях строился выбор, какие отклонения были выявлены и кто принял решение по спорным моментам.
До получения КП команда согласует критерии и, если используются баллы, вес каждого критерия. Менять веса после чтения предложений рискованно: так легко подогнать методику под уже понравившегося поставщика.
Черновик протокола, который готовит ИИ, включает четыре блока.
- Состав полученных документов и их версии.
- Критерии, методику оценки и подтверждающие источники.
- Результаты сравнения, расхождения и открытые вопросы.
- Решения комиссии, ответственных и перечень приложений.
Модель можно использовать для стандартизации формулировок, заполнения реквизитов и переноса подтверждённых строк из матрицы. Ей нельзя поручать фразу «рекомендуется признать победителем». Это решение принимает уполномоченный сотрудник или комиссия после проверки технических, коммерческих и юридических оснований.
Здесь полезна простая логика RACI из учебных материалов по бизнес-процессам. У каждого значимого шага должен быть один Accountable — человек, отвечающий за результат. Закупщик может быть исполнителем анализа, инженер — консультантом по характеристикам, юрист — консультантом по условиям договора, руководитель закупки — ответственным за соблюдение процедуры. Если ответственными названы все, то по факту не отвечает никто.
В статье и в локальном регламенте стоит прямо назвать роль ИИ: инструмент подготовки материалов. У него нет полномочий, допуска к утверждению и ответственности за решение.
Что ИИ не должен решать самостоятельно
Есть четыре запрета, которые лучше закрепить в регламенте и системном промте.
- Выбор победителя или рекомендация заключить договор с конкретным поставщиком.
- Юридические выводы о договоре, соответствии нормам, допустимости условия или правовой квалификации риска.
- Подтверждение характеристик, наличия товара, цены, гарантии, сертификата или срока поставки без проверки первичного источника.
- Отправка поставщикам запросов, изменение данных в ERP, согласование условий и иные действия во внешних системах.
По каждому из этих направлений ИИ может быть полезен. Он подготовит сравнительную записку, сформулирует перечень вопросов, соберёт ссылки на пункты договора и покажет противоречия. Но человек должен прочитать первоисточник, принять решение и оставить след в протоколе.
Это совпадает с подходом NIST к управлению рисками ИИ: роли, человеческий контроль и документация должны быть определены заранее, а не появляться после инцидента. NIST AI RMF
Учебный кейс для производственной закупки
Представим учебную ситуацию. Производственная компания выбирает поставщика оборудования. Есть утверждённое ТЗ, уточняющая версия приложения, три КП и каталог производителя. В одном предложении цена дана за базовую комплектацию, во втором заявлен «эквивалент», в третьем указаны пусконаладочные работы, но нет отдельного срока поставки.
Сначала закупщик присваивает документам идентификаторы и фиксирует версии. Затем технический специалист и закупки согласуют перечень обязательных параметров. В него входят производительность, питание, габариты, комплектность, интеграция с действующим оборудованием, доставка, монтаж, пусконаладка, гарантия и документация.
Модель получает ТЗ и формирует реестр требований с цитатами. Отдельно по каждому поставщику она заполняет карточку предложения. После этого появляется матрица.
Из неё видно следующее. У поставщика А заявлена нужная характеристика, но непонятно, входит ли в цену монтаж. У поставщика Б характеристика описана иначе, поэтому нельзя автоматически признать её эквивалентной. У поставщика В есть пусконаладка, но срок поставки начинается после согласования документации без указанного срока согласования.
Ни один из этих выводов не определяет победителя. Они формируют три действия. Технический заказчик проверяет допустимость альтернативной характеристики у поставщика Б. Закупки уточняют состав работ у поставщика А. Контрактный менеджер запрашивает у поставщика В календарный план и зависимые действия заказчика.
После ответов поставщиков в систему добавляются новые письма с собственными идентификаторами. Матрица обновляется, но первоначальные данные не перезаписываются. Это важно для следа решения: через месяц должно быть понятно, что именно было в исходном КП и какие уточнения пришли позднее.
В финальном протоколе комиссия видит не «лучшее предложение по мнению нейросети», а последовательность фактов. Какие требования подтверждены, какие отклонения признаны допустимыми, где есть дополнительные условия и кто принял решение по каждому существенному вопросу.
Как запустить пилот без большого внедрения
Для первого пилота лучше взять повторяющуюся закупку с понятным ТЗ и несколькими документами. Не нужно начинать с самого конфликтного тендера года или сложного договора EPC. Цель пилота — проверить не модель, а процесс.
Сначала команда создаёт шаблон ТЗ-матрицы, карточки КП, реестра рисков и протокола. Затем проводит несколько закупок в параллельном режиме: старый процесс остаётся основным, а ИИ готовит материалы для сравнения. После каждой процедуры стоит обсудить, какие поля модель извлекла корректно, какие формулировки постоянно вызывают ошибки и какие вопросы действительно помогли сократить переписку.
Оценивать полезно четыре показателя: долю существенных строк с точной ссылкой на источник, число найденных и подтверждённых расхождений, время специалиста на первичное сравнение документов, число исправлений после проверки.
Если инструмент экономит время только на красивой презентации таблицы, а проверка занимает столько же, пилот нужно доработать. Обычно проблема не в конкретной БЯМ, а в неясном ТЗ, смешанных версиях документов и отсутствии правил, что считать подтверждением.
Для регулярной работы с внутренними документами можно развивать этот подход через базу знаний и поиск по утверждённым источникам. Объяснение такой архитектуры есть в статье «Как научить нейросеть отвечать по документам компании — что такое RAG». Автоматизацию маршрута файлов, напоминаний и обновления матрицы имеет смысл обсуждать после того, как ручной процесс доказал свою полезность. Для этого подойдёт материал об автоматизации на n8n и ИИ-агентах.
Итог
ИИ в закупках полезен там, где нужно быстро разобрать пакет документов, свести разные формулировки в одну матрицу и не потерять вопрос к поставщику. Он не заменяет техническую экспертизу, полномочия закупочной комиссии и юридическую проверку.
Надёжный результат строится на простом правиле: любая существенная строка должна вести обратно к документу. Тогда ИИ ускоряет подготовку решения, а не создаёт новый непрозрачный риск.
Корпоративное обучение ИИ для закупочной команды можно собрать вокруг ваших ТЗ, КП и формы протокола. Посмотрите программу «Нейросети для бизнеса» и пришлите обезличенный пример пакета документов для обсуждения пилота. Для госструктур и организаций, работающих по 44-ФЗ и 223-ФЗ, есть отдельная программа с учётом специфики согласований и уровня допуска — «ИИ для государственных организаций».