AI для заявок на закупку: классификация, согласование и аудит

Почему заявкам на закупку нужен контролируемый workflow

AI-автоматизацию закупок часто описывают как быстрый способ прочитать заявку и отправить её нужному согласующему. В таком описании теряется операционная задача. В заявке могут быть неполное описание потребности, ссылка на поставщика, центр затрат, срочность, вложение и просьба об исключении. Она может прийти из формы, письма, общего inbox или внутренней системы. Ценный результат — не красивое резюме, а проверяемый proposal, который можно принять, исправить или остановить, не потеряв исходную заявку.

Широкий сервисный запрос об AI-автоматизации принадлежит странице AI-автоматизации. Этот материал отвечает на узкий вопрос: как для одного controlled pilot классифицировать заявку на закупку, провести её через согласование и сохранить audit evidence. Он не должен незаметно утверждать расходы, создавать purchase order или обещать ROI.

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

Предпосылки и входные данные

До выбора модели зафиксируйте request contract. Каждая входящая заявка должна иметь неизменяемый request ID, scope организации или бизнес-единицы, время приёма, source channel, версию источника и ссылку на retention. Сохраните исходный текст и вложения либо их разрешённые references. Позже reviewer должен увидеть именно полученные данные, а не реконструированный prompt.

Минимально полезные inputs обычно включают requester, юридическое лицо или cost centre, товар или услугу, цель, сумму и валюту при наличии, признаки поставщика, требуемую дату, taxonomy категорий и версию approval policy. Не каждое поле обязано быть заполнено. Contract должен отличать отсутствующее значение от значения, предположенного моделью. Неизвестный центр затрат — это exception, а не пустота, которую можно угадать.

У reference data должен быть собственный owner. Категории, cost centres, состояние бюджета, группы согласующих, поставщики и пороги policy меняются. Workflow должен читать утверждённый актуальный snapshot и записывать использованную версию. Свободный текст заявки не должен обновлять справочник. Если источник устарел, недоступен или неоднозначен, безопасный результат — очередь named reviewer.

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

• Можно ли после решения идентифицировать source request и версию вложения?
• Есть ли поддерживаемая taxonomy категорий и согласующих с owner?
• Какие поля обязательны для routing proposal, а какие допустимо оставить пустыми?
• Какие классы заявок всегда требуют human review?
• Возвращает ли destination system authoritative receipt после записи?

Если этих ответов нет, сначала исправляют process contract. AI не превращает отсутствие полномочий на согласование в достоверные данные.

Проектирование workflow PROCURE-7

PROCURE-7 — пошаговый workflow для controlled procurement pilot. Он отделяет вероятностный classification proposal от policy и consequential action.

1. Receive. Дедуплицируйте заявку по source ID или безопасному content-based idempotency key. Сохраните receipt, source version и разрешённые references на вложения.
2. Normalize. Извлеките только разрешённый текст и поля. Redact или исключите данные, не нужные для классификации.
3. Classify. Верните typed proposal: category, request type, candidate cost centre, urgency label, confidence или uncertainty, evidence spans и missing fields. Модель предлагает, но не устанавливает финальный accounting или approval state.
4. Validate. Проверьте schema, required fields, taxonomy membership, версию policy и сопоставление с current reference data. Валидируйте валюту и суммы детерминированно, если они входят в scope.
5. Route. Примените детерминированные правила согласования. Заявки с отсутствующими, конфликтующими или высокорисковыми данными идут named reviewer, а не default approver.
6. Review. Покажите source evidence, proposal, policy decision, личность reviewer, причину решения и expiry. Reviewer может принять, исправить или отклонить proposal.
7. Commit and verify. Создайте idempotent draft, approval task или разрешённую downstream record. Прочитайте её из authoritative destination и сохраните receipt, либо откройте recovery item.

Такой workflow можно представить как contract, а не как обещание автономной закупки:

request -> bounded proposal -> deterministic policy -> named decision -> verified destination state

Эта последовательность предотвращает типовую ошибку: принять удачный ответ модели или зелёный run workflow за доказательство корректного согласования. Только destination read-back подтверждает, что разрешённое действие действительно существует.

Интеграции и контракты

Реализация обычно связывает источник intake, identity и master-data references, approval destination и audit store. Конкретное ПО менее важно, чем contracts между ним. Intake connector должен давать stable identifiers и receipts. Reference-data connector обязан делать заметными freshness, ownership и failure. Approval connector принимает idempotency key и возвращает authoritative ID или state. Audit layer хранит достаточно evidence для восстановления решения, но не копирует лишние персональные данные.

Считайте любой connector ошибающимся. Timeout после создания approval task неоднозначен: retry без idempotency key может создать duplicate, а статус success без проверки потеряет задачу. Безопасный дизайн ищет запись по ключу, фиксирует результат и отправляет неразрешённую неоднозначность в recovery. Так же и модель не должна выбирать cost centre только потому, что label знакомо: она возвращает evidence и uncertainty, чтобы validation мог остановить proposal.

Пример входа и выхода

Допустим, сотрудник пишет: «Нужны ноутбуки для двух новых сотрудников в следующем месяце; quotation во вложении; используйте engineering budget». Контролируемый workflow сохраняет заявку как evidence и возвращает ограниченный proposal:

{
  "requestId": "pr_1042",
  "proposal": {
    "requestType": "equipment",
    "category": "IT hardware",
    "candidateCostCentre": "engineering",
    "missingFields": ["approved amount", "supplier match"],
    "evidence": ["laptops", "two new hires", "engineering budget"],
    "requiresReview": true
  },
  "policy": "route to procurement reviewer; do not create purchase order"
}

Пример намеренно неполный. Он не утверждает поставщика, доступность бюджета, финальную сумму или approval. Procurement reviewer может исправить category, выбрать approved supplier, приложить требуемое quote evidence и принять решение по текущей policy.

Проверки перед запуском

До любого live action прогоните acceptance checks на representative historical или synthetic requests. Проверьте обычные заявки, отсутствующие вложения, duplicate submissions, конфликтующие имена поставщиков, неподдерживаемые категории, устаревшие policy data, недоступные references, reviewer timeout и destination failures. Включите языки, которые принимает процесс: смешанные Armenian, Russian и English labels не должны молча нормализоваться в неверную category.

Acceptance criteria нужно сформулировать явно:

• Каждый workflow run имеет source receipt, version, policy version и correlation ID.
• Proposal соответствует документированной schema и отмечает missing или uncertain fields.
• Решения по category, approver и threshold используют approved current reference data.
• Заявка, требующая review, не может стать approved action через retry или fallback.
• Повторная delivery создаёт не более одной destination record на idempotency key.
• Destination record читается обратно и связана с workflow evidence.
• Failed или ambiguous actions попадают в owned recovery queue с видимым status.
• Access, retention и redaction следуют утверждённым правилам организации.

Не заменяйте эти проверки одной метрикой accuracy. Важен вопрос, объясним ли каждый разрешённый route, корректен ли он по policy и восстанавливается ли при сбое dependency. Для пилота можно отслеживать review rate, correction rate, причины exceptions, предотвращённые duplicates, time-to-owned-review и verified read-back coverage. Это операционные сигналы, а не обещание выручки.

Эксплуатация и улучшение

Запускайте пилот на ограниченном объёме и с определённым review cadence. Проверяйте accepted classifications так же, как exceptions: иначе команда учится только на явных отказах. Когда reviewer исправляет proposal, сохраните причину в контролируемой taxonomy: «нет source», «taxonomy mismatch», «policy change» или «ambiguous request». Так corrections становятся evidence для улучшения процесса, а не недокументированным prompt churn.

Версионируйте prompts, schemas, reference snapshots и policy rules независимо. Изменение taxonomy category может потребовать новую reference version, но не изменение модели. Новое output field может потребовать migration и acceptance tests. У каждого изменения должны быть owner, evaluation set, rollback decision и production window. Сохраните возможность отключить AI proposal, не выключая ручной маршрут.

После стабильного pilot решайте, расширять ли его по request type, business unit или глубине integration. Расширение оправдано, только если текущая граница подтверждена evidence: review outcomes проверяемы, у exceptions есть owners, downstream writes проходят reconciliation и команда умеет объяснить recovery. Для обсуждения controlled pilot и integration boundaries можно обратиться к практике AI-автоматизации aicoding.am или посмотреть подтверждающие материалы в case studies.

Вывод

AI может сделать intake закупок более структурированным, не становясь согласующим. Полезная первая реализация хранит source request, выдаёт bounded classification proposal, валидирует его по актуальным правилам, оставляет human authority там, где она нужна, и подтверждает destination state. Это практический переход от демонстрации AI к аудируемому операционному workflow.