ИИ в закупках и бизнес-процессах

Короткий ответ

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

В тендерной работе это важное различие.

Чат-сценарий

Пользователь вручную:

• скачал документы;
• выбрал нужные файлы;
• сформулировал вопрос;
• загрузил данные;
• получил ответ.

Полезно, но большая часть процесса остаётся ручной.

Агентный сценарий

Система получает задачу:

проверить закупку по заданному регламенту.

Дальше она может:

1. собрать документы;
2. определить, какие файлы нужны;
3. извлечь сведения;
4. сопоставить их с чек-листом;
5. отметить неизвестные;
6. сформировать вывод;
7. сохранить доказательства;
8. отправить человеку на подтверждение.

Что делает агент «агентом»

Не магическая автономность, а сочетание:

• цели;
• контекста;
• инструментов;
• состояния процесса;
• правил доступа;
• критерия завершения;
• проверки результата.

Что не меняется

Агент не становится автоматически:

• юристом;
• ответственным за цену;
• ответственным за решение об участии;
• подписантом.

Ответственность бизнеса остаётся у человека.

Вывод

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

Практический следующий шаг

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

Короткий ответ

ИИ полезнее всего там, где задача требует обработки большого объёма информации, но результат можно проверить.

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

Можно делегировать глубже

• классификацию документов;
• извлечение фактов;
• поиск расхождений;
• подготовку чек-листа;
• первичную сводку;
• маршрутизацию;
• заполнение черновых данных;
• сравнение версий;
• подготовку проекта отчёта.

Нужна обязательная проверка человеком

• соответствие ТЗ;
• вывод по национальному режиму;
• проверка существенного условия договора;
• интерпретация спорной нормы;
• расчёт рекомендуемой цены;
• решение о замене товара.

Не отдавать автономно

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

Почему граница важнее модели

Даже очень сильная модель может ошибиться.

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

Рабочий принцип

ИИ предлагает → доказательства показываются → человек подтверждает → система выполняет техническое действие.

Вывод

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

Практический следующий шаг

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

Короткий ответ

Сильный промпт не заменяет архитектуру агента.

Для рабочего бизнес-процесса нужны как минимум четыре слоя.

1. Контекст

Агент должен получать только релевантные:

• документы;
• правила;
• справочники;
• историю задачи;
• состояние процесса.

Лишний контекст может мешать не меньше, чем недостаточный.

2. Инструменты

Нужно заранее определить, может ли агент:

• читать файлы;
• искать данные;
• работать с СРМ;
• запускать скрипт;
• создавать задачу;
• сохранять отчёт.

3. Права

Агенту не нужно давать полный доступ только потому, что так проще настроить.

Минимально необходимый доступ снижает риск случайного изменения данных.

4. Критерий завершения

Фраза:

«проанализируй закупку»

не задаёт критерия готовности.

Лучше:

• все документы классифицированы;
• все позиции обработаны;
• все неизвестные помечены;
• доказательства приложены;
• итоговый отчёт прошёл проверку.

Почему это важно

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

Вывод

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

Практический следующий шаг

Для выбранного агента опишите четыре вещи отдельно: что он знает, что умеет делать, что ему запрещено и как доказать завершение.

Короткий ответ

Проверка человеком должна быть частью процесса, а не экстренной мерой после ошибки.

У агента должны существовать заранее определённые точки, где он обязан остановиться и передать решение человеку.

Где проверка человеком особенно важна

Право

Если вывод зависит от толкования нормы или судебной практики.

Цена

Если результат влияет на коммерческий минимум или маржу.

Соответствие

Если агент оценивает техническое соответствие сложному ТЗ.

Внешнее действие

Если нужно отправить сообщение, изменить СРМ, подать документ или создать обязательство.

Низкая уверенность

Если исходные данные противоречат друг другу или неполны.

Что должен видеть проверяющий

Не только итог:

«соответствует».

А:

• исходные документы;
• извлечённые факты;
• ссылки;
• спорные места;
• неизвестные;
• уровень уверенности;
• предложенный вывод.

Контроль подтверждения

Правильный контрольный барьер — не «нажмите ОК».

Он должен отвечать:

• что подтверждается;
• на основании чего;
• какие последствия;
• что произойдёт после подтверждения.

Вывод

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

Практический следующий шаг

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

Короткий ответ

Несколько агентов полезны, когда задача действительно состоит из разных типов работы.

Например:

• сбор контекста;
• нормативная проверка;
• анализ данных;
• расчёт;
• контроль качества.

Что даёт разделение

Ограниченные границы задачи

Каждый агент работает только со своей задачей.

Разные инструменты

Аналитик может работать с таблицами, а нормативный проверяющий — с базой источников.

Независимая проверка

Проверяющий не обязан принимать объяснение исполнителя как факт.

Управляемая ошибка

Проще понять, на каком этапе появился дефект.

Когда один агент лучше

Если задача короткая и линейная, оркестрация только добавляет:

• задержку;
• стоимость;
• сложность состояния;
• лишние точки сбоя.

Роль оркестратора

Оркестратор не должен быть «главным экспертом по всему».

Его задача:

• разделить границы задач;
• передать правильный контекст;
• собрать результаты;
• проверить контрольные барьеры;
• остановить процесс при недостатке доказательств.

Вывод

Многоагентная архитектура полезна не количеством агентов, а разделением ответственности и независимой проверкой там, где она действительно нужна.

Практический следующий шаг

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

Короткий ответ

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

В рабочей архитектуре разные типы операций выполняются разными инструментами.

Детерминированный слой

Код лучше использовать для:

• скачивания;
• распаковки архивов;
• определения формата;
• хеширования;
• кэша;
• хранения связей;
• проверки наличия файла;
• формирования структуры результата.

Эти операции должны быть воспроизводимыми и не требуют смыслового рассуждения.

Семантический слой

Модель полезна для:

• классификации документа;
• извлечения сложного условия;
• сравнения формулировок;
• поиска противоречий;
• подготовки пояснения;
• анализа ТЗ;
• построения гипотезы.

Слой доказательств

Каждый существенный вывод должен позволять восстановить:

• источник;
• файл;
• фрагмент;
• версию;
• способ получения;
• статус уверенности.

Возобновляемое задание

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

Нужны:

• состояние;
• кэш;
• продолжение;
• отчёт о выполненных шагах;
• контролируемые статусы по проблемным объектам.

Вывод

Рабочий ИИ-агент для документов — это не «модель читает ЗИП». Это конвейер, где точные операции выполняются кодом, смысловые — моделью, а результат остаётся проверяемым.

Практический следующий шаг

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

Короткий ответ

Не каждая сложная автоматизация требует ИИ.

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

Примеры детерминированных задач

• скачать файл по известной ссылке;
• распаковать ЗИП;
• сохранить документ;
• вычислить хеш;
• проверить дубликат;
• переименовать по правилу;
• заполнить техническое поле;
• повторить запрос после временной ошибки.

Где появляется смысловая неопределённость

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

Здесь модель уже имеет смысл.

Почему смешение опасно

Если модель отвечает и за точную загрузку, и за интерпретацию, становится трудно понять:

• где случилась ошибка;
• что можно повторить;
• почему потерян файл;
• можно ли доверять результату.

Практическая формула

точное правило → код неструктурированный смысл → модель критическое решение → человек

Вывод

Самая сильная ИИ-архитектура часто использует меньше ИИ, чем кажется. Модель должна работать там, где нужна модель.

Практический следующий шаг

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

Короткий ответ

В сложной закупке расчёт — это не только арифметика.

До формулы нужно определить:

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

Почему одного Эксель недостаточно

Таблица хорошо считает, когда входные данные уже определены.

Но агент может помогать искать их в:

• ТЗ;
• проекте контракта;
• приложениях;
• обосновании цены;
• спецификациях;
• вложениях сделки.

Каскад расчёта цен

По каждой позиции полезно пройти последовательность источников и присвоить итоговый статус, например:

• подтверждённая цена поставщика;
• подтверждённый рыночный источник;
• обоснованная оценка;
• цена не определена.

Покрытие

Покрытие должно показывать не только процент «что-то посчитано», но и качество источника.

Например:

• подтверждено;
• оценено;
• не покрыто.

Критерий готовности

Агент не должен завершать задачу после обработки случайной первой партии строк.

Готовность наступает, когда:

• все позиции прошли каскад расчёта;
• для каждой есть статус;
• непокрытый остаток выделен;
• допущения описаны;
• итоговая экономика рассчитана.

Вывод

Агент расчёта — это исследователь входных данных + оркестратор ценовых источников + калькулятор, а не просто формула в таблице.

Практический следующий шаг

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

Короткий ответ

Процент покрытия полезен только вместе с типом доказательства.

Фраза:

«покрытие 95%»

может означать принципиально разные результаты.

Более честная структура

Например:

• подтверждено прямыми источниками;
• подтверждено альтернативными источниками;
• ориентировочно оценено;
• не удалось оценить.

Почему это важно

Две закупки с одинаковым покрытием могут иметь разный риск.

В первой почти все цены подтверждены поставщиками.

Во второй большинство значений рассчитано косвенно.

Средний процент одинаковый, надёжность — нет.

Статус агента

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

Это позволяет:

• фильтровать;
• повторно обрабатывать;
• строить отчёт;
• направлять на ручную проверку.

Когда останавливать расчёт

Низкое покрытие не должно автоматически означать:

«работа завершена».

Если ещё не исчерпаны предусмотренные источники, агент продолжает каскад расчёта.

Решение человека

Даже высокое покрытие не означает автоматического решения об участии.

Руководитель должен видеть:

• долю подтверждённых данных;
• оценочные позиции;
• крупнейшие неизвестные;
• влияние неопределённости на маржу.

Вывод

Хороший ИИ-расчёт показывает не только цифру, но и границы своей доказательности.

Практический следующий шаг

Разделите итог на подтверждённое, оценочное и неизвестное. Один общий процент без качества доказательств скрывает риск.

Короткий ответ

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

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

Рабочая цепочка

дата закупки → применимый закон → редакция → документы процедуры → норма → факт → вывод → ограничение

Что агент обязан показывать

• источник нормы;
• дату редакции;
• дату применимости;
• фактическое основание;
• что неизвестно;
• альтернативное толкование, если оно существенно.

Контролируемый статус

Если данных не хватает, допустимый результат:

ручная проверка / не хватает входных данных / частично

лучше, чем догадка.

Что нельзя делать

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

Почему проверка человеком остаётся

Право содержит:

• переходные положения;
• исключения;
• конфликтующие факты;
• судебную оценку конкретных обстоятельств.

Это область, где человек должен проверять не только итог, но и цепочку доказательств.

Вывод

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

Практический следующий шаг

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

Короткий ответ

Не вся повторяемая работа должна становиться навыком ИИ.

Выбор зависит от того, где находится неопределённость.

Когда лучше скрипт

Если задача:

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

Примеры:

• преобразовать файл;
• проверить колонки;
• переименовать документы;
• пересчитать формулу;
• выгрузить данные;
• проверить дубликаты.

Когда навык полезнее

Если задача повторяется, но каждый раз требует:

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

Что должен содержать хороший навык

• чёткое назначение;
• условия активации;
• входные данные;
• процедуру;
• ограничения;
• критерии качества;
• формат результата;
• контролируемые статусы;
• примеры тестов.

Почему не нужно делать «универсальный меганавык»

Чем шире границы, тем труднее:

• тестировать;
• понять причину ошибки;
• управлять правами;
• обновлять правила.

Вывод

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

Практический следующий шаг

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

Короткий ответ

Агент нельзя оценивать по одному удачному запуску.

Для повторяемого рабочего процесса нужен набор реальных тестов и критериев приёмки.

Что включить в тестовый корпус

Обычные случаи

Типовые документы и стандартный рабочий процесс.

Граничные

Редкий формат, большой архив, несколько похожих документов.

Ошибочные

Нет файла, битая ссылка, неполные данные.

Противоречивые

Два документа дают разные сведения.

Регрессионные

Реальные кейсы, на которых агент уже ошибался.

Что измерять

Не только:

«ответ похож на хороший».

А:

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

Перед исправлением ошибки

Полезно сначала расширить границы дефекта:

• повтор;
• другой вход;
• предельное время;
• конкурентный запуск;
• аналогичное состояние.

После этого формулируется нарушенный инвариант.

Набор примеров сбоев

Каждый подтверждённый дефект становится новым тестом.

Тогда качество развивается накопительно, а не по циклу:

ошибка → поправили промпт → через месяц ошибка вернулась.

Вывод

Готовый к эксплуатации агент — это не хороший запрос. Это рабочий процесс, который прошёл реальные приёмочные случаи и не забывает старые ошибки.

Практический следующий шаг

Соберите 10–20 реальных случаев: обычные, граничные, ошибочные и ранее сломанные. Это даст гораздо больше, чем один красивый демонстрационный пример.

Короткий ответ

Полезный личный сценарий ещё не является корпоративным процессом.

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

Что формализовать

Условие запуска

Когда процесс запускается.

Вход

Какие данные обязательны.

Контекст

Какие источники разрешено использовать.

Процедура

Какие этапы проходит задача.

Инструменты

Какие системы доступны.

Права

Что агент может читать и менять.

Подтверждение

Какие действия требуют человека.

Результат

Как выглядит готовый результат.

Тесты

На каких реальных кейсах проверяется.

Ответственный

Кто отвечает за актуальность процесса.

Почему это важно

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

Но масштабирование плохого рабочего процесса только увеличивает количество плохих результатов.

Изменения процесса

Если поменялись:

• бизнес-правило;
• источник;
• формат документа;
• система;
• нормативное требование,

рабочий процесс должен иметь версию и повторную проверку.

Вывод

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

Практический следующий шаг

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