Как создать ИИ-агента, когда процесс живёт в голове одного сотрудника: мы сели рядом с закупщиком

Заказчик прислал регламент отдела закупок: четыре страницы, аккуратные пункты, подпись директора. «Вот процесс, сделайте по нему ИИ-агента». Мы сделали. Агент строго следовал регламенту и выбирал поставщиков ровно так, как там написано. Начальник закупок посмотрел первые результаты и сказал: «Половину я бы не подписал». Так начался проект, после которого мы поменяли порядок работы. Теперь создание ИИ-агента у нас начинается с того, что мы сидим рядом с живым человеком и смотрим, как он работает на самом деле.

Что было в регламенте и чего там не было

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

Регламент описывал всё логично: минимум три предложения, сравнение по цене с учётом доставки, выбор самого выгодного. Под такое описание ИИ-агент собирается почти по учебнику. Модель достаёт из документа цену, срок, условия оплаты. Код сводит данные в таблицу. Агент выбирает победителя и пишет обоснование.

Технически всё заработало быстро. Разбор документов мы строили на GigaChat Pro: у заказчика были требования держать данные в российском контуре. Почтовый ящик отдела и справочник номенклатуры из учётной системы подключили к агенту через MCP-серверы. Результаты складывали в PostgreSQL. Через пару недель у нас был агент, который делал ровно то, что написано в регламенте.

И это оказалось проблемой.

Почему «самый дешёвый» не значит «правильный»

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

• «Этот поставщик всегда пишет цену без НДС и не говорит об этом прямо. Надо смотреть на мелкий шрифт в конце».
• «У этих дешевле, но они дважды срывали сроки в прошлом квартале. Для срочных позиций мы их не берём».
• «Стопроцентная предоплата — только если поставщик проверенный. Новому не платим вперёд, даже если он дешевле».
• «Эту позицию мы берём только у производителя, у перекупщиков был брак».

Ничего из этого в регламенте не было. Закупщики знали это и применяли каждый день. На вопрос «почему не записали» ответили честно: «А зачем? Все и так знают».

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

Первая попытка вытащить знания провалилась

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

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

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

Вторая попытка: сидеть рядом и спрашивать «почему» в моменте

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

«Почему вы открыли второй лист PDF?» — «Там обычно условия доставки, на первом только цена». «Почему отложили это письмо?» — «Там цена от дистрибьютора, а у нас с производителем прямой договор, надо сначала спросить у них». «Почему позвонили?» — «Срок поставки написан "по согласованию". Это может значить и неделю, и два месяца».

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

Три корзины вместо одной инструкции

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

Жёсткие правила — в код

«Новому поставщику не платим вперёд», «эту позицию только у производителя», «цену без НДС пересчитываем» — это правила без исключений. Им не место в инструкции модели: модель может их нарушить, если в документе окажется что-то необычное. Мы вынесли их в проверки на Python, которые работают после того, как модель извлекла данные. Если правило нарушено, предложение помечается, и никакое «обоснование» от модели его не спасёт.

Суждения — в память с примерами

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

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

Исключения — человеку

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

Где мы наступили на грабли

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

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

Что поменялось в работе отдела

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

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

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

Главный вывод для тех, кто думает, как создать ИИ-агента

Когда нас спрашивают, как создать ИИ-агента для бизнеса и с чего начать, мы больше не начинаем с выбора модели или архитектуры. Мы начинаем с вопроса: где на самом деле живёт знание о процессе? Если в документах — отлично, можно работать с ними. Если в головах людей, которые «и так знают», — придётся сесть рядом и посмотреть, как они работают.

ИИ-агенты для бизнеса проваливаются не потому, что модель слабая. Чаще всего агента учат по бумаге, а работать ему предстоит в реальности. Разрыв между ними — это и есть та самая «половина, которую я бы не подписал».

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

Похожие статьи

• «Нам нужен ИИ-агент», а нужен был скрипт: как мы проверяем задачу перед созданием ИИ-агента
• С чего начать создание ИИ-агента для бизнеса: как мы выбираем первый пилот
• Обучение ИИ-агента для отдела рекламаций: почему «лучшие ИИ-агенты» из рейтингов не сели на живой поток
• Один ИИ-агент — три модели: как мы разложили шаги между GigaChat Pro, YandexGPT и локальным Qwen