Урок 5: RFP-шаблон для закупки industrial AI — что спрашивать у вендоров, чтобы не купить воздух

Чему вы научитесь

• Строить RFP по industrial AI так, чтобы на выходе получить не красивую презентацию, а сравнимые коммерческие и технические ответы
• Формулировать вопросы к вендору по архитектуре, данным, ownership, ИБ, санкциям, SLA и exit clauses
• Отделять «мы всё умеем» от реально проверяемых обязательств в контракте и приложениях к нему
• Сразу закладывать RACI: кто отвечает за данные, модель, интеграцию, обучение пользователей и production-поддержку
• Выявлять красные флаги в ответах вендора до пилота, а не после подписания договора

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

Хороший RFP устроен наоборот. Он заставляет вендора назвать:

• где живут данные и модель;
• кто владеет кастомной моделью и артефактами;
• как считается SLA и качество;
• как выглядит трёхлетний TCO;
• как вы выходите из договора без потери данных, модели и логики процесса.

Ниже — рабочий шаблон, который можно брать за основу для закупки industrial AI. Он не заменяет юриста и ИБ, но резко повышает шанс купить не «воздух», а управляемый проект.

Структура RFP: какие блоки должны быть обязательно

Блок 1. Архитектура — 5 обязательных вопросов

1. В каком контуре разворачивается решение: public cloud, private VPC, dedicated tenant, on-prem, edge или hybrid?
2. Какие компоненты работают в нашем контуре, а какие остаются у вас или у третьей стороны?
3. Как выглядит схема интеграции с нашими SCADA, MES, ERP, historian, CMMS, DWH и корпоративным AD/IDM?
4. Какие протоколы и интерфейсы вы поддерживаете: REST, OPC UA, MQTT, Kafka, файловый обмен, SQL, API-шлюзы?
5. Какие части системы являются обязательными, а какие могут быть заменены нашими собственными компонентами?

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

Блок 2. Модели — 5 обязательных вопросов

1. Какие именно модели используются: точное название, версия, дата релиза и лицензия?
2. Какие модели являются внешними зависимостями: open-source, third-party API, proprietary models?
3. Возможна ли замена модели без полной пересборки всей системы?
4. Как устроены дообучение, fine-tuning, prompt updates и rollout новой версии модели?
5. Кто несёт ответственность за деградацию качества после обновления модели или пайплайна?

Блок 3. Данные — 5 обязательных вопросов

1. Какие данные вы запрашиваете на пилот и на промышленный rollout: raw, агрегаты, документы, логи, изображения, телеметрию?
2. Будут ли наши данные использоваться для обучения общей модели или только для нашего выделенного контура?
3. Где физически и логически будут храниться данные, embeddings, feature store и журналы запросов?
4. Какой механизм удаления данных, артефактов и резервных копий при расторжении договора?
5. Какие данные остаются нашей собственностью, а какие становятся частью вашего сервиса или модели?

Для юридического блока эти вопросы связываются с уроком p.3/01. Для технологического — с ownership модели и будущим lock-in.

Блок 4. ИБ и compliance — 7 обязательных вопросов

1. Подходит ли решение для объектов КИИ и какие ограничения у вас есть по 187-ФЗ?
2. Есть ли on-prem или полностью локальный вариант для regulated-контура?
3. Какие меры защиты вы применяете по требованиям ФСТЭК и как отражаете AI-угрозы в модели угроз?
4. Как устроены журналирование, аудит действий, разграничение прав и интеграция с SIEM/SOC?
5. Какие внешние зависимости используются: облака, SDK, контейнерные образы, SaaS-сервисы, сторонние API?
6. Каков ваш санкционный статус: есть ли риск блокировки лицензии, поставок, модели или техподдержки для РФ?
7. Есть ли у вас SBOM, результаты сканирования контейнеров и порядок уведомления о критических уязвимостях?

Здесь уже нельзя экономить на точности формулировок. Для ПД — p.3/01. Для КИИ — p.3/02. Для ФСТЭК и AI-угроз — p.3/03.

Блок 5. SLA и качество — 6 обязательных вопросов

1. Какой SLA по доступности сервиса вы даёте: uptime в процентах, режим плановых окон и исключения?
2. Как измеряется response time и latency для нашего сценария: p50, p95, p99?
3. Какие KPI качества вы готовы фиксировать: accuracy, recall, false positive rate, false negative rate, human acceptance rate?
4. Кто и как проводит приёмку качества на пилоте и в production?
5. Какие штрафы, service credits или иные последствия наступают при нарушении SLA?
6. Как быстро вы обязуетесь реагировать на критический инцидент и эскалировать его до ответственного инженера?

Вендор почти всегда любит обещать «высокое качество». Но procurement-подход требует другой язык: какой именно KPI качества и какая ответственность за его нарушение.

Блок 6. Стоимость и TCO — 6 обязательных вопросов

1. Разложите стоимость на CapEx, OpEx, лицензии, токены, железо, интеграцию, поддержку и обучение пользователей.
2. Что входит в базовую цену, а что продаётся как professional services, premium support, custom integration и retraining?
3. Как выглядит TCO на 3 года с тремя сценариями нагрузки: pilot, scale-out, industrial production?
4. Как меняется цена при росте числа пользователей, активов, камер, документов, GPU или токенов?
5. Какие hidden costs вы видите у нашего ландшафта: доработка сети, серверов, IAM, observability, CMMS/MES integration?
6. Что будет стоить выход из решения: выгрузка данных, миграция, переобучение, перенос на другой стек?

Это уже прямая связь с уроком p.4/01 и уроком p.2/06. Если vendor economics нельзя перевести в 3-year TCO, закупку пока рано защищать перед CFO.

Блок 7. Delivery, support и команда — 6 обязательных вопросов

1. Кто именно будет внедрять проект: ваш staff, локальный партнёр, интегратор или подрядчик подрядчика?
2. Есть ли русскоязычная команда внедрения и поддержки, доступная в нашем часовом поясе?
3. Кто дежурит при production-инциденте ночью, в выходные и на площадке?
4. Как выглядит escalation path: L1, L2, L3, архитектор, vendor management?
5. Кто обучает операторов, инженеров, ИТ и ИБ-команду работе с решением?
6. Какие компетенции вы оставляете нам, а какие останутся у вас как у поставщика?

Блок 8. Exit clauses и ownership — 6 обязательных вопросов

1. Кто владеет кастомно дообученной моделью, prompt templates, retrieval rules, embeddings и feature engineering?
2. В каком формате и в какие сроки вы обязуетесь передать нам данные, артефакты модели и эксплуатационную документацию при выходе?
3. Можно ли перенести решение на другой runtime, облако или интегратора без вашего участия?
4. Какие ограничения по лицензии сохранятся после расторжения договора?
5. Есть ли у нас право на продолжение эксплуатации решения после termination в transitional period?
6. Что именно перестаёт работать при отключении вашей лицензии или подписки?

RACI matrix: кто отвечает за что

Технически хороший RFP почти бесполезен, если внутри проекта не разведена ответственность. Ниже — минимальный RACI-шаблон для industrial AI.

Где:

• A — accountable, конечный владелец результата;
• R — responsible, исполнитель;
• C — consulted;
• I — informed.

Если вендор отказывается заполнять RACI, это серьёзный сигнал. Значит, в случае инцидента начнётся известная игра «это не у нас, это у интегратора / у клиента / у инфраструктуры».

Как запускать RFP-процесс без хаоса

1. Сначала сделайте short list. Не рассылайте RFP рынку целиком. Сначала отфильтруйте по классу задачи и санкционной применимости — см. урок p.10/01.

2. Разведите обязательные и желательные требования. On-prem, ownership, SBOM, интеграция с AD — это не wishlist, а mandatory requirements.

3. Требуйте единый формат ответа. Иначе вы получите пять красивых PDF, которые нельзя сравнить.

4. Сразу закладывайте pilot acceptance criteria. Не «сделать пилот», а «достигнуть KPI X на данных Y в контуре Z».

5. Проверяйте не только vendor demo, но и delivery team. Кто придёт на площадку, кто будет внедрять, кто реально отвечает за production.

6. Фиксируйте выход из решения до входа в него.

Красные флаги в ответах на RFP