Проектирование RFI и RFP с помощью ИИ: требования, вопросы и ограничители

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

Эффективное проектирование RFP с ИИ использует ИИ для организации исходных материалов, поиска пробелов и подготовки измеримых вопросов, а не для установления требований, назначения весов оценки, ранжирования поставщиков или принятия решений о присуждении контракта. Дайте каждому поставщику одинаковые определения, сценарии, таблицы ответов и единицы измерения; требуйте доказательства по существенным заявлениям; и сохраняйте именованные этапы человеческого утверждения на протяжении всего жизненного цикла закупки.

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

Проектируйте от решения назад

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

Прежде чем использовать ИИ для подготовки любого из этих документов, ответьте на пять вопросов:

1. Какой результат должен улучшиться?
2. Каков измеренный базовый уровень?
3. При каких условиях внедрения должно произойти улучшение?
4. Какие доказательства подтвердят это улучшение?
5. Кто может утверждать требование, компромисс и присуждение контракта?

Это один этап более широкого процесса закупок, а не изолированная задача генерации документов. Требования, основанные на результативности, должны определять измеримые стандарты и методы оценки, а не предписывать ненужное техническое решение, в соответствии с FAR Subpart 37.6. Факторы оценки также должны поддерживать содержательное сравнение и раскрывать, что важно для решения, как описано в FAR 15.304.

Обязательные входные данные перед подготовкой проекта

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

Внутренние входные данные заказчика

• Утвержденная формулировка проблемы, бизнес-результат, пользователи и затронутые группы
• Карта текущего процесса и базовые показатели стоимости, длительности цикла, уровня ошибок и уровня сервиса
• Объемы спроса, сезонность, пиковые нагрузки, бюджетные ограничения и целевые даты
• Обязательные, желательные и запрещенные возможности
• Существующие контракты, архитектура, API, средства управления идентификацией и сетевые ограничения
• Инвентаризация данных, классификация, владение, размещение, хранение и разрешенные способы использования
• Контролируемые заказчиком тестовые сценарии, наборы данных, пороги и диапазоны допустимых отклонений
• Факторы оценки, относительная важность, дисквалифицирующие условия и правила для отсутствующих ответов
• Требования к безопасности, конфиденциальности, доступности, учету записей, интеллектуальной собственности и аудиту
• Назначенные утверждающие лица, допустимый уровень риска, пути эскалации и правила хранения документов
• Жизнеспособные не-ИИ альтернативы

Внешние входные данные поставщика

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

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

Разделяйте доказательства, выводы и суждения

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

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

Шаблон ответа с доказательствами

Не засчитывайте доказательственную ценность сводке ИИ или оценке поставщика без прослеживаемого артефакта или успешной валидации.

Практический набор вопросов для RFI и RFP

Используйте единый формат ответов для этих вопросов:

1. Какой измеримый результат улучшается относительно нашего заявленного базового уровня?
2. Какие наблюдаемые доказательства подтверждают это утверждение в сопоставимых условиях?
3. Какие функции существуют сейчас, а какие зависят от дорожной карты?
4. Каковы известные режимы отказа, исключенные способы использования и предсказуемые сценарии неправильного использования?
5. Какие данные заказчика поступают в сервис, выходят из него, обучают его или изменяют его?
6. Как мы можем независимо протестировать надежность, безопасность, стоимость и поведение при отказах?
7. Какой человеческий контроль требуется и какая информация поддерживает вмешательство?
8. Какие изменения модели, потока данных, субпроцессора, политики или цены требуют уведомления?
9. Какие данные, промпты, конфигурации, журналы и оценочные материалы можно экспортировать?
10. Какова полная стоимость при ожидаемых, пиковых и стресс-тестовых объемах?
11. Что запускает исправление, откат, приостановку или прекращение?
12. Какие существенные утверждения станут договорными обязательствами?

Для более широкого контекста по технологически поддерживаемым закупкам см. закупки ИИ. Команды, готовящие последующие обсуждения с поставщиками, также могут ознакомиться с переговорами с ИИ и руководством Negotiations.AI по переговорам о ценах с поставщиками на основе данных.

Где применимы машинное обучение, генеративный ИИ и агентные рабочие процессы

Машинное обучение

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

Генеративный ИИ

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

Агентные рабочие процессы

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

Человеческие решения и этапы утверждения

Фиксируйте ответственное человеческое утверждение для:

• Формулировки проблемы и решения рассматривать ИИ
• Предполагаемых и запрещенных способов использования, а также классификации риска
• Выпуска RFI и анкеты для поставщиков
• Окончательных требований, порогов и методов тестирования
• Факторов оценки, весов, формул и инструкций по выставлению оценок
• Выпуска RFP и каждого существенного изменения
• Допуска или исключения поставщика
• Обработки отсутствующих, условных или непроверяемых доказательств
• Целей переговоров, уступок и окончательных условий
• Выбора источника, присуждения контракта, приемочного тестирования и внедрения
• Существенных изменений модели, потока данных, субпроцессора, сценария использования или цены
• Реагирования на инциденты, приостановки, выхода и вывода из эксплуатации

NIST рассматривает управление рисками как непрерывный процесс на всем жизненном цикле ИИ и требует документированных ролей, человеческого надзора, тестирования, мониторинга и ответственного руководства в своем AI RMF Core.

Сценарий переговоров: сначала сравните измеритель, потом цену

Заказчик ожидает 4 миллиона транзакций с поддержкой ИИ в год. Поставщик A предлагает цену $180,000 в год, включая 3 миллиона транзакций, с превышением лимита по $0.09. Поставщик B предлагает $205,000, включая 5 миллионов транзакций.

При прогнозируемом объеме A стоит $270,000 до внедрения, тогда как B остается на уровне $205,000. Но и это сравнение все еще неполное: A может включать более сильную переносимость, тогда как B может взимать $35,000 за экспорт данных и поддержку перехода.

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

Промпты по ИИ для практики

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

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

Ограничения

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

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

Источники

• NIST AI Risk Management Framework
• OMB Memorandum M-25-22
• FAR Part 10: Market Research
• EU Artificial Intelligence Act

Дополнительное чтение

• GSA: Buy AI
• NIST Generative AI Profile
• UK Government Guidelines for AI Procurement

FAQ

Должен ли ИИ писать весь RFP по одному промпту?

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

Как сделать предложения поставщиков ИИ сопоставимыми?

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

Может ли ИИ оценивать или ранжировать поставщиков?

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

Какие заявления поставщика должны стать условиями контракта?

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

Отказ от ответственности: Эта статья предоставляет общую информацию о закупках и не является юридической или финансовой консультацией.