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

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

Что должна делать AI-автоматизация входящих закупочных запросов

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

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

Именно так работает AI purchase request automation: она готовит данные и делает исключения видимыми, но не выбирает поставщика и не подтверждает расход самостоятельно. В рамках AI-решений и автоматизации POLADO проектирует такие ограниченные и проверяемые процессы.

Разделите подготовку данных и право принимать решение

Что AI может подготовить

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

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

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

Это важно и для безопасности. Входящее письмо поставщика — недоверенный контент: оно может быть неполным или содержать инструкции, рассчитанные на манипулирование AI. Поэтому модели следует дать только минимально нужные права. У неё не должно быть прямого доступа к операциям создания поставщика, изменения банковских реквизитов или выпуска PO. Рекомендации OWASP по риску excessive agency отдельно указывают на опасность избыточной функциональности, прав и автономии AI-агентов.

Как выглядит контролируемый workflow закупочной заявки

  1. Приём и идентификация. Система получает письмо, форму или документ, присваивает неизменяемый intake ID и сохраняет отправителя, время, заголовки, вложения и хэши файлов.
  2. Извлечение и нормализация. OCR и AI document extraction предлагают структурированные значения. Нужно хранить и нормализованное поле, и исходную формулировку из документа.
  3. Проверка правилами. Обязательные реквизиты, пороги сумм, категории, правила юридического лица и матрица согласования проверяются детерминированной логикой, а не только выводом модели.
  4. Оценка уверенности и конфликтов. Модель может уверенно распознать число, но это не означает, что оно верно для закупки. Суммы и даты в письме, форме и счёте нужно сопоставлять между собой.
  5. Маршрутизация или очередь исключений. Полная заявка с низким риском становится черновиком на согласование. Низкая уверенность, новый поставщик, конфликт данных или нарушение политики направляются в очередь сотрудника.
  6. Решение человека. Согласующий видит резюме, источники, результаты проверок и историю правок; он может утвердить, отклонить, вернуть на доработку или изменить запись.
  7. Передача в ERP. Только утверждённая и полная запись передаётся в систему учёта. Ответ ERP и внешний номер сохраняются в карточке заявки.

Пороги уверенности не равны праву на автоматическое решение

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

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

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

Поиск дубликатов должен помогать, а не автоматически отклонять

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

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

Ссылки на источники и аудит — обязательная часть продукта

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

В аудите отдельно хранятся оригинальная заявка, результат извлечения, уровень уверенности, результаты правил, предложенный маршрут, ручные изменения, решения согласующих, комментарии, время действий и ответ ERP. Если байер изменил количество с 10 на 12, история должна содержать оба значения и автора изменения. NIST рекомендует чётко разграничивать роли человека и AI, поддерживать документацию и постоянный контроль рисков; это хорошо совпадает с требованиями закупочного процесса.

Передача в ERP: проектируйте обработку повторов и сбоев

Интеграция с ERP — не просто один API-вызов. Нужно отличать ситуацию «ERP не получила заявку» от ситуации «ERP создала её, но ответ потерялся из-за таймаута». Используйте idempotency key, связанный с утверждённой intake-записью, сохраняйте каждую попытку отправки, ограничивайте повторы и регулярно сверяйте неопределённые статусы с ERP. Повторный запуск не должен создавать вторую реквизицию.

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

План внедрения на практике

  1. Проанализируйте 50–100 последних заявок: каналы поступления, отсутствующие поля, типовые категории и причины исключений.
  2. Определите единую схему реквизиции и управляемые справочники категорий, компаний, центров затрат и проектов.
  3. Зафиксируйте матрицу согласования, жёсткие контроли и поля, по которым AI имеет право только предлагать значение.
  4. Начните пилот с одной-двух категорий, например продление ПО или офисное оборудование.
  5. Измеряйте долю ручных исправлений, незаполненных полей, точность дубликат-алертов, возраст очереди и ошибки ERP handoff.
  6. Улучшайте правила, промпты и сопоставления справочников на основе проверок сотрудников, а затем расширяйте охват.

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