ИИ для закупок: где заканчивается чатбот и начинается продукт
ИИ для закупок легко показать как чат: загрузили документ, задали вопрос, получили ответ. Для демо этого достаточно. Для работы с закупками — нет. Настоящая ценность появляется не в красивой формулировке, а в том, что система помогает пройти процесс: разобрать документы, выделить требования, собрать матрицу соответствия, увидеть риски, сохранить основания и оставить человека в точках решения.
В публичном секторе это особенно заметно. OECD в разделе про AI in public procurement рассматривает ИИ не как отдельный чат, а как часть закупочной функции: требования, спецификации, оценка предложений, выбор поставщиков, цены и соответствие правилам. В США GSA выпускала ресурс для закупки генеративного ИИ, где прямо подчеркивается: закупщик должен задавать поставщику вопросы о рисках, данных и ответственном использовании.
Поэтому главный вопрос звучит так: система просто отвечает на вопросы или становится частью закупочного контура?
Чем продукт отличается от чатбота
Чатбот работает вокруг разговора. Продукт работает вокруг объекта. В закупках объектами становятся заявка, техническое задание, критерии, поставщик, требование, риск, протокол, договор, комментарий эксперта. Если система не умеет хранить эти объекты и связи между ними, она остается помощником для черновиков.
Главное:AI-продукт для закупок начинается там, где у системы появляются документы, поля, проверки, роли, журнал действий и понятный маршрут от входного материала к решению. Без этого это просто чат над файлами.
Минимальная архитектура закупочного ИИ
| Слой | Что делает | Что проверяет человек |
|---|---|---|
| Разбор документов | извлекает требования, сроки, критерии, приложения | корректность структуры и пропущенные фрагменты |
| Матрица соответствия | связывает требование с ответом, источником и статусом | спорные требования и исключения |
| Проверка поставщика | собирает карточку, документы, ограничения, историю | юридические и репутационные риски |
| Журнал решений | фиксирует, почему система предложила вывод | можно ли объяснить решение после факта |
| Контур прав | разделяет чтение, правку, публикацию и утверждение | где нужна ручная приемка |
Эта таблица важнее выбора модели. Модель можно заменить. Процесс сложнее. Если нет журнала, непонятно, почему система решила, что требование закрыто. Если нет ролей, сотрудник может случайно отдать агенту действие, которое требует утверждения. Если нет матрицы, ответ выглядит убедительно, но не привязан к конкретному пункту документа.
Как применять это в Codex
Codex здесь полезен не как “магический закупщик”, а как инженер процесса. Ему можно дать задачу: описать объекты закупочного контура, поля, связи, роли и проверки. Например: документ, требование, источник, поставщик, риск, решение, основание, статус. После этого агент может помочь собрать прототип: парсер, таблицу, валидацию, отчет, тестовые вопросы.
Но решение о допуске поставщика, цене, правовом риске или публикации результата должно оставаться под человеческим контролем. В NIST AI Risk Management Framework эта логика читается как управление риском, измерение, контроль и мониторинг. Для закупок это не абстрактная этика, а ежедневная операционная защита.
Где граница
ИИ может быстро читать документы, выделять повторяющиеся требования, сравнивать варианты, находить пробелы и готовить черновики. Но он не должен незаметно превращаться в автоматическое решение о выборе поставщика. Особенно там, где есть деньги, конкуренция, закон, репутация и возможность спора.
Хороший закупочный продукт не обещает “заменить отдел закупок”. Он делает работу видимой: что пришло на вход, какие требования выделены, какие риски найдены, что предложила система, что утвердил человек. Именно этот след отличает рабочий продукт от красивого чата.