ИИ для специалистов по закупкам: рабочие сценарии и готовые промпты

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

Что ИИ уже делает в закупках и какие задачи закрывает

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

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

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

На этапе поиска и отбора процедур задача меняется. Специалист тонет в потоке извещений, из которых реально подходят единицы. Фильтры по кодам работают грубо, потому что заказчики ставят их по-разному, и половина релевантных закупок уходит мимо. Модель читает текст извещения и документации так, как это сделал бы человек, и отвечает на вопрос о пригодности закупки, а не о совпадении кода.

• Отбор процедур по смысловому описанию предмета закупки, а не только по ОКПД2 и КТРУ.
• Первичный скоринг перспективности с учётом требуемого обеспечения, сроков поставки и наличия лицензий.
• Отсев закупок с признаками заточенности под конкретного участника, например с нереалистичными сроками или уникальными сочетаниями характеристик.
• Краткая сводка по каждой подходящей процедуре на половину страницы, чтобы руководитель принял решение за минуту.

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

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

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

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

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

Как выбрать задачи для первого этапа внедрения

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

1. Выпишите десять операций, которые отнимают больше всего времени у специалистов отдела за неделю.
2. Для каждой операции определите, кто и как проверяет результат сегодня. Если проверки нет, автоматизировать её рано.
3. Отметьте операции, где ошибка приводит к отклонению заявки, штрафу или жалобе в антимонопольную службу. Это зона обязательного ручного контроля.
4. Из оставшегося выберите две или три задачи и доведите их до стабильного результата, прежде чем браться за следующие.
5. Зафиксируйте в цифрах, сколько времени уходило до и сколько уходит после. Без этого разговор с руководством превращается в обмен впечатлениями.

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

Чем отличаются чат-модели, ИИ-ассистенты и ИИ-агенты

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

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

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

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

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

Какой уровень автоматизации соответствует вашей зрелости

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

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

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

Анализ закупочной документации с ИИ: пошагово и с промптами

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

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

Резюме закупки и требования к участникам

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

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

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

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

Проверка технического задания на противоречия и скрытые ограничения

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

• Расхождения в сроках, объёмах и единицах измерения между техническим заданием, извещением и проектом контракта.
• Характеристики, которые в совокупности соответствуют единственной модели на рынке, хотя формально описаны как требования к свойствам.
• Требования, выполнение которых невозможно подтвердить ни одним документом, то есть заведомо спорные при приёмке.
• Ссылки на стандарты и регламенты, которые утратили силу или не относятся к предмету закупки.
• Условия приёмки, допускающие отказ по субъективному усмотрению заказчика.

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

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

Первичная оценка рисков и проект контракта

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

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

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

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

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

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

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

Сравнение версий документации и чек-лист перед подачей

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

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

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

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

1. Попросите модель собрать таблицу, где в первой колонке требование документации, во второй — пункт, в котором оно установлено, в третьей — документ или действие, которое его закрывает.
2. Отдельно выделите требования к форме документов, то есть к наличию подписи, печати, срока действия справки и количества экземпляров.
3. Добавьте колонку с отметкой о готовности и проходите список непосредственно перед подачей, а не за неделю до неё.
4. Проверьте сроки действия всех справок на дату подачи, а не на дату их получения. Это самая частая причина отклонения при полном комплекте.
5. Сверьте наименования и характеристики в заявке с техническим заданием дословно, включая единицы измерения.

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

Сравнение коммерческих предложений за 5 минут: инструкция и промпт

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

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

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

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

Как не получить красивую, но бесполезную таблицу

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

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

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

Параметр сравнения	Что проверяет модель	Что обязательно проверяет человек
Цена за единицу	Пересчёт из упаковок, выделение налога, вычет доставки	Итоговую цифру у двух лучших предложений по исходному файлу
Срок поставки	Приведение рабочих дней к календарным, учёт срока с момента оплаты	Реалистичность срока с учётом прошлого опыта работы с поставщиком
Комплектация	Сопоставление характеристик и выявление расхождений с заявкой	Техническую применимость аналога, если он предложен вместо заявленного
Условия оплаты	Структурирование аванса, отсрочки и этапности	Соответствие внутренней политике платежей и лимитам
Надёжность поставщика	Сведение формальных данных из предложения	Проверку по реестрам, истории поставок и репутации на рынке

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

Как встроить ИИ в рабочий процесс отдела закупок

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

Библиотека промптов как главный актив отдела

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

1. Создайте общее хранилище, доступное всему отделу. Подойдёт любая внутренняя система, где можно вести структурированные документы с историей изменений.
2. Для каждого запроса фиксируйте название задачи, сам текст, пример входных данных и пример хорошего результата. Без примера результата новый сотрудник не поймёт, что считается нормой.
3. Указывайте ограничения. Например, что этот запрос не применяется к закупкам с государственной тайной или к документам с персональными данными.
4. Назначьте ответственного за библиотеку. Не обязательно отдельного человека, достаточно роли у одного из специалистов с выделенным временем раз в две недели.
5. Раз в квартал пересматривайте запросы. Нормативная база меняется, модели обновляются, и формулировки, которые работали год назад, могут давать худший результат.

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

Регламент и зоны ответственности

Без письменных правил использование модели остаётся личной инициативой, за которую непонятно кто отвечает. Регламент не должен быть длинным. Хватает двух страниц, где описано, что можно загружать, что нельзя, какие результаты требуют обязательной проверки и кто её выполняет.

Результат работы языковой модели не является основанием для принятия решения. Он является черновиком, который специалист проверяет и присваивает себе. Ответственность за поданную заявку, подписанное техническое задание и выбор поставщика несёт сотрудник, а не инструмент.

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

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

Обучение команды без отрыва от работы

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

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

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

Как проверять результаты работы ИИ

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

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

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

Хорошо работает приём с повторным независимым запросом. Вы задаёте тот же вопрос в новой беседе, другими словами, и сравниваете два ответа. Расхождения показывают места, где модель не уверена, и именно там сосредоточена большая часть ошибок. Способ занимает минуту и заменяет вычитку всего текста.

Модель уверена в неверном ответе точно так же, как в верном. У неё нет интонации сомнения, и это главное отличие от общения с человеком. Поэтому доверие стоит выстраивать не к ответам, а к процедуре проверки ответов.

Типичные ошибки: галлюцинации, устаревшие нормы, потеря контекста

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

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

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

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

Тип ошибки	Как выглядит	Как поймать
Выдуманная ссылка	Точный номер пункта, которого нет в документе или в законе	Открыть указанный пункт и прочитать
Устаревшая норма	Неверный порог, срок или перечень, отменённый поправками	Сверить с действующей редакцией, прикладывать текст нормы к запросу
Пропуск требования	Полный на вид список, в котором отсутствует один пункт	Обратный запрос с просьбой перечислить все пункты раздела и сверка количества
Заполнение пробела догадкой	Данные в ячейке, которых не было в исходном предложении	Прямой запрет на домыслы в запросе и выборочная сверка
Смешивание источников	Условие из одного файла приписано другому	Разделять файлы по запросам, требовать указания источника
Избыточная угодливость	Найденные противоречия там, где их нет	Формулировать запрос с допущением, что проблем может не быть

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

Безопасность данных: что нельзя загружать в ИИ-сервисы

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

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

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

Обезличивание как рабочая практика

Большинство закупочных задач решаются без реальных данных. Модели не нужно знать название вашей компании, чтобы проверить техническое задание на противоречия. Ей не нужны реквизиты, чтобы посчитать неустойку. Поэтому самый простой способ работать безопасно — заменять чувствительные элементы условными обозначениями.

1. Замените наименования организаций на обозначения вида поставщик первый, поставщик второй, заказчик.
2. Уберите реквизиты, банковские данные, фамилии подписантов и номера доверенностей.
3. Если важна пропорция, а не абсолютная сумма, умножьте все цифры на один коэффициент и верните масштаб обратно после получения результата.
4. Сохраняйте таблицу соответствия обозначений отдельно, в своём файле, чтобы корректно перенести результат в рабочий документ.
5. Проверяйте, не осталось ли идентифицирующих признаков в сносках, колонтитулах и свойствах файла.

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

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

Где граница применимости ИИ и что остаётся за специалистом

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

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

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

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

Что меняется в структуре рабочего дня

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

Как меняется роль закупщика и какие навыки нужны

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

Набор навыков, который реально востребован, довольно конкретен.

1. Умение формулировать задачу. Это не про знание секретных формулировок, а про способность точно описать, что нужно получить, в каком виде и с какими ограничениями. Навык полностью переносится на работу с людьми.
2. Критическая проверка информации. Понимание, какие утверждения требуют первоисточника, а какие можно принять. Этот навык всегда был частью профессии, но теперь он стал главным.
3. Знание нормативной базы на уровне логики, а не на уровне заучивания. Модель подскажет пункт, но оценить применимость нормы к ситуации нужно самому.
4. Аналитика расходов и работа с данными. Когда рутина уходит, освобождается время на вопросы о том, почему категория дорожает и где теряется объём.
5. Переговорные навыки и выстраивание отношений с поставщиками. Та часть работы, которая приносит деньги и которая не автоматизируется.
6. Понимание устройства инструментов на базовом уровне. Достаточно знать, почему модель ошибается и в каких случаях, без погружения в технические детали.

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

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

Кейсы: что изменилось после внедрения ИИ

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

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

Типичные результаты по рынку складываются в понятную картину.

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

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

Как посчитать экономику внедрения

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

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

Частые вопросы

Можно ли заменить специалиста по закупкам моделью

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

Нужны ли специальные решения или достаточно обычной чат-модели

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

Можно ли доверять ответам о законодательстве

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

На каких этапах закупки эффект максимален

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

Что делать, если модель ошиблась в важном документе

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

Как начать, если в отделе нет ни регламентов, ни опыта

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

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