Оценка рисков поставщика ИИ: анкета, модель оценки и список подтверждающих материалов (2026)
Оценка рисков поставщика ИИ — это проверка, которую проводят до того, как сторонний ИИ-продукт или API получит доступ к вашим данным: вы определяете уровень риска сценария использования, задаёте вопросы, связанные с ИИ (обучение на ваших данных, хранение, субобработчики и поставщики моделей, тестирование безопасности, риски результатов, регулирование), собираете подтверждения каждого ответа, выставляете поставщику оценку, определяете условия договора и порядок мониторинга. От обычной проверки поставщика она отличается тем, что при работе с поставщиками ИИ нужно дополнительно учитывать поведение моделей, повторное использование данных и цепочку поставщиков моделей, которым передаются данные. В этом руководстве приведены готовая анкета, модель оценки и список подтверждающих материалов, актуальные на 26 октября 2026 года.
Руководство предназначено для команд безопасности, закупок и платформенной инфраструктуры, которые согласовывают использование ИИ-API, ИИ-шлюзов и SaaS-инструментов с функциями ИИ. Оно не является юридической консультацией.
Чем отличаются риски поставщиков ИИ
Традиционная проверка контрагента охватывает управление доступом, шифрование, доступность сервиса и сертификацию. Для поставщиков ИИ ко всему этому добавляются следующие вопросы:
| Новый риск | Почему это важно | Пример вопроса |
|---|---|---|
| Повторное использование данных для обучения | Ваши промпты могут улучшать модель, которой пользуются другие | Используются ли данные клиентов для обучения или оценки моделей по умолчанию? |
| Контрагенты поставщика | Поставщик может передавать данные поставщикам моделей | Какие поставщики моделей обрабатывают наши данные и в каких регионах? |
| Поведение модели | Ответы могут быть ошибочными, небезопасными или раскрывать данные | Как система тестируется на инъекции в промпты и утечки данных? |
| Быстрые изменения | Модели и их версии могут меняться без уведомления | Как вы сообщаете об изменениях моделей и ведёте учёт версий? |
| Регулирование | EU AI Act и отраслевые нормы вводят дополнительные обязанности | Как вы классифицируете эту систему в соответствии с EU AI Act? |
| Риск роста затрат | При оплате по объёму использования расходы могут резко вырасти | Есть ли квоты, лимиты расходов и оповещения? |
Концепция управления рисками ИИ NIST прямо рассматривает риски сторонних ИИ-решений в рамках функций Govern и Map, а профиль NIST для генеративного ИИ (AI 600-1) относит риски цепочки создания ценности и интеграции компонентов к рискам генеративного ИИ.
Шаг 1: Определите уровень риска поставщика с учётом сценария использования
Не каждый ИИ-инструмент требует одинаково глубокой проверки. Сначала определите уровень риска, затем подберите объём анкеты.
| Уровень | Критерии | Глубина проверки |
|---|---|---|
| Уровень 1 (высокий) | Данные клиентов, персональные данные, данные, подпадающие под требования регулирования, либо ИИ выполняет действия (отправляет сообщения, проводит платежи, изменяет записи) | Полная анкета, подтверждающие материалы, тестирование безопасности, юридическая проверка |
| Уровень 2 (средний) | Внутренние данные, каждый результат проверяет человек | Основная анкета + ключевые подтверждающие материалы |
| Уровень 3 (низкий) | Только общедоступные данные, без интеграции | Краткая анкета + проверка условий |
Зафиксируйте уровень риска и его обоснование в досье поставщика. Пересматривайте уровень при изменении сценария использования.
Шаг 2: Отправьте анкету для оценки рисков поставщика ИИ
Используйте эти вопросы в дополнение к стандартной анкете по безопасности (например, Shared Assessments SIG или матрице мер контроля ИИ CSA).
Обработка данных и конфиденциальность
- Используются ли наши данные (промпты, файлы, результаты) для обучения или оценки каких-либо моделей? Какова настройка по умолчанию? Можно ли отказаться от такого использования или закрепить запрет в договоре?
- Как долго хранятся промпты, результаты и журналы? Можно ли отключить хранение или установить короткий срок?
- Где обрабатываются и хранятся данные (регионы)? Можно ли закрепить конкретный регион?
- Какие субобработчики и поставщики моделей получают наши данные? Как нас уведомляют об изменениях?
- Предоставляете ли вы соглашение об обработке данных (DPA) и охватывает ли оно обработку с использованием ИИ и трансграничную передачу?
Управление моделями и системой
- Какие модели используются в продукте: ваши собственные или сторонние?
- Как вы сообщаете об изменениях моделей или версий и тестируете эти изменения?
- Как вы оцениваете точность, предвзятость и безопасность и можете ли предоставить результаты?
- Есть ли у вас документация о предполагаемом использовании и известных ограничениях (карточки моделей или систем)?
Безопасность
- Какие сертификаты или аудиторские заключения распространяются на ИИ-сервис (SOC 2 Type II, ISO 27001, ISO 42001)? Входит ли ИИ-продукт в область их действия?
- Как вы тестируете систему на инъекции в промпты, утечки данных и чрезмерную автономность (например, по OWASP Top 10 для LLM-приложений)?
- Как выдаются API-ключи, ограничиваются их права, выполняются ротация и отзыв?
- Что содержат журналы, у кого есть к ним доступ и можем ли мы их экспортировать?
- Каков ваш порядок реагирования на инциденты, связанные с ИИ, и в какие сроки вы уведомляете о них?
Эксплуатация и затраты
- Каковы условия SLA и распространяется ли оно на функции ИИ и поставщиков моделей, от которых зависит сервис?
- Что происходит при недоступности поставщика модели: переключение на резерв, работа с ограниченными возможностями или отказ?
- Есть ли квоты для отдельных ключей, лимиты расходов и оповещения об использовании?
- Каковы условия прекращения работы с сервисом: экспорт данных, подтверждение удаления, сроки уведомления?
Регулирование
- Как вы классифицируете систему в соответствии с EU AI Act и какие обязанности выполняете как поставщик либо в рамках поддержки организации, применяющей систему? Согласно текущему графику введения требований, требования к системам высокого риска из Приложения III начинают применяться со 2 декабря 2027 года.
- Сопровождаются ли результаты уведомлением или маркировкой о том, что контент создан ИИ, там, где это требуется?
Шаг 3: Собирайте подтверждения, а не только ответы
Каждый ответ «да» при проверке поставщика уровня 1 должен подкрепляться материалом, который можно сохранить в досье.
| Ответ | Какие подтверждения запросить | Что проверить |
|---|---|---|
| «Мы не обучаем модели на ваших данных» | Положение договора, DPA, документация по настройкам продукта | Действует ли запрет по умолчанию или требует отказа от обучения; распространяется ли он на субобработчиков |
| «Данные хранятся 30 дней» | Политика хранения, скриншот настройки администратора | Распространяется ли срок на журналы и резервные копии |
| «SOC 2 Type II» | Отчёт под NDA, письмо о состоянии мер контроля за период после окончания аудита | Входит ли ИИ-сервис в область аудита; дата окончания отчётного периода; выявленные отклонения |
| «Мы тестируем систему на инъекции в промпты» | Краткие результаты тестирования или отчёт о тестировании на проникновение | Дата, охват, выявленные проблемы, повторная проверка |
| «Квоты для отдельных ключей» | Документация или скриншот консоли; собственный тест | Действительно ли лимиты блокируют запросы |
| «Поставщики моделей перечислены» | Список субобработчиков с указанием регионов | Соответствует ли он вашим требованиям к размещению данных |
Сертификат помогает при предварительном отборе, но не доказывает безопасность вашего сценария использования. Подтверждающие материалы для шлюзов рассмотрены в статьях подтверждение соответствия SOC 2 для шлюза ИИ-API, чек-лист DPA для ИИ-шлюза и чек-лист хранения данных ИИ-API.
Шаг 4: Выставьте поставщику оценку
Оцените каждое направление по шкале 1-5 (5 = надёжные меры, подтверждённые материалами) и назначьте веса с учётом вашего сценария использования:
| Направление | Вес (пример для уровня 1) | Оценка 1 | Оценка 5 |
|---|---|---|---|
| Использование и хранение данных | 25% | Обучение на данных по умолчанию, неясные сроки хранения | Без обучения, настраиваемое хранение, обязательства закреплены в договоре |
| Безопасность и тестирование | 25% | Нет тестирования с учётом специфики ИИ | Свежие подтверждения тестирования с повторной проверкой |
| Контрагенты поставщика и размещение данных | 15% | Поставщики моделей неизвестны | Полный список, регионы, уведомления об изменениях |
| Управление и изменения | 15% | Модели меняются без уведомления | Версии фиксируются, изменения объявляются и оцениваются |
| Эксплуатация и контроль затрат | 10% | Нет SLA и квот | SLA, резервный маршрут, квоты, лимиты расходов |
| Готовность к требованиям регулирования | 10% | Позиция не определена | Классификация и обязанности задокументированы |
Простой скрипт расчёта оценки, который можно хранить в досье поставщика:
WEIGHTS = {"data": .25, "security": .25, "fourth_parties": .15,
"governance": .15, "operations": .10, "regulatory": .10}
def vendor_score(scores: dict, evidence: dict) -> dict:
"""scores: 1-5 per domain; evidence: True if the score is backed by filed evidence"""
capped = {d: (s if evidence.get(d) else min(s, 2)) for d, s in scores.items()} # no evidence -> max 2
total = sum(WEIGHTS[d] * capped[d] for d in WEIGHTS)
decision = "approve" if total >= 4 else "approve with conditions" if total >= 3 else "reject or escalate"
return {"score": round(total, 2), "decision": decision, "capped": capped}
print(vendor_score(
{"data": 5, "security": 4, "fourth_parties": 4, "governance": 3, "operations": 4, "regulatory": 3},
{"data": True, "security": True, "fourth_parties": True, "governance": False, "operations": True, "regulatory": False},
))
Правило ограничения оценки важно: неподтверждённое заявление никогда не должно получать столько же баллов, сколько проверенное.
Шаг 5: Самостоятельно проверьте заявления, от которых зависит риск
Перед подписанием договора с поставщиком уровня 1 проверьте несколько вещей в тестовой среде:
- Отзыв ключа: отзовите тестовый ключ и убедитесь, что запросы сразу перестают выполняться.
- Квоты: установите низкую квоту и убедитесь, что при её достижении запросы блокируются.
- Список разрешённых моделей: вызовите модель, которая не должна быть разрешена, и убедитесь, что доступ отклонён.
- Содержимое журналов: проверьте, что сохраняется в журнале запросов (только метаданные или полный промпт).
# After revoking the test key in the vendor console, this should return 401
curl -s -o /dev/null -w "%{http_code}\n" https://api.vendor.example/v1/chat/completions \
-H "Authorization: Bearer $REVOKED_TEST_KEY" -H "Content-Type: application/json" \
-d '{"model":"any-model","messages":[{"role":"user","content":"ping"}]}'
Анкета показывает, что заявляет поставщик; эти тесты позволяют напрямую проверить часть заявлений. Полноценное тестирование безопасности вашего ИИ-приложения — отдельная задача, рассмотренная в нашем руководстве по аудиту безопасности ИИ.
Шаг 6: Закрепите меры контроля в договоре
| Положение | Зачем оно нужно |
|---|---|
| Запрет на обучение на данных клиентов (в том числе для субобработчиков) | Предотвращает повторное использование данных |
| Ограничение срока хранения и удаление при прекращении сотрудничества | Ограничивает риски, связанные с хранением данных |
| Уведомление о смене субобработчиков и поставщиков моделей | Позволяет возразить против привлечения новых контрагентов поставщика |
| Срок уведомления об утечках и инцидентах, связанных с ИИ | Ускоряет реагирование |
| Право на аудит и получение подтверждающих материалов | Позволяет повторно проверять заявления |
| SLA, охватывающее функции ИИ | Закрепляет юридические обязательства по доступности |
| Размещение данных | Обеспечивает соблюдение правил передачи данных |
Шаг 7: Продолжайте мониторинг после одобрения
- Повторно проверяйте поставщиков уровня 1 ежегодно, а также при изменении моделей, субобработчиков или условий.
- Отслеживайте использование и затраты по каждому поставщику и ключу.
- Следите за инцидентами и бюллетенями безопасности.
- Ведите список одобренных моделей, чтобы новые модели проходили проверку (процесс согласования ИИ-моделей).
Оценка шлюза ИИ-API как поставщика
Шлюз находится между вашими приложениями и несколькими поставщиками моделей, поэтому оценивайте оба уровня: сам шлюз (ключи, журналы, квоты, биллинг, поддержка) и каждого поставщика, к которому он направляет запросы. Запросите список маршрутов и сведения о том, какие поставщики получают какие данные. Например, в Flatkey можно посмотреть модель, токены, стоимость и ключ для каждого запроса на панели использования, экспортировать журналы в CSV/JSON в качестве подтверждающих материалов, а также создавать или отзывать ключи для каждой среды в разделе управления API-ключами. Сохраните эти выгрузки в закупочном досье рядом с анкетой. В нашем пакете подтверждающих материалов для закупки ИИ-шлюза приведён полный перечень, а руководство по проверке подтверждающих материалов поставщиков моделей посвящено поставщикам, от которых зависит работа шлюза.
Частые вопросы
Что такое оценка рисков поставщика ИИ?
Это структурированная проверка стороннего ИИ-продукта или API перед одобрением, которая охватывает использование данных, безопасность, поставщиков моделей в цепочке контрагентов, управление, эксплуатацию и готовность к требованиям регулирования и подкрепляется подтверждающими материалами и оценкой риска.
Какие вопросы должна содержать анкета поставщика ИИ?
Как минимум: используются ли ваши данные для обучения моделей, сроки хранения, регионы обработки, субобработчики и поставщики моделей, сертификаты, охватывающие ИИ-сервис, тестирование безопасности с учётом специфики ИИ, управление ключами и журналами, SLA и резервные механизмы, контроль затрат, условия прекращения сотрудничества и классификация по EU AI Act.
Чем управление рисками поставщиков ИИ отличается от обычного TPRM?
ИИ добавляет повторное использование данных для обучения, поставщиков моделей в цепочке контрагентов, непредсказуемые результаты работы моделей, частые изменения моделей и специальное регулирование ИИ. Стандартные меры управления рисками третьих сторон (TPRM) по-прежнему применяются.
Может ли ИИ помочь в управлении рисками поставщиков?
Да, ИИ-инструменты могут составлять сводки по анкетам и отмечать недостающие подтверждения, но решение об одобрении и проверку подтверждающих материалов должен выполнять человек, особенно для поставщиков уровня 1.
Достаточно ли отчёта SOC 2 для одобрения поставщика ИИ?
Нет. Убедитесь, что ИИ-сервис охвачен областью и периодом отчёта, а затем всё равно задайте вопросы, связанные с ИИ: об обучении, хранении данных, поставщиках моделей и тестировании. В обзоре SOC 2 от AICPA объясняется, что охватывает отчёт SOC 2.
Какие стандарты и методики помогают оценивать риски поставщиков ИИ?
NIST AI RMF и его профиль для генеративного ИИ, OWASP LLM Top 10 для технических рисков, матрица мер контроля ИИ CSA, ISO/IEC 42001 для систем управления ИИ и анкета Shared Assessments SIG.
Источники
Проверено 26 октября 2026 года: NIST AI RMF, NIST AI 600-1, OWASP Top 10 для LLM-приложений, матрица мер контроля ИИ CSA, Shared Assessments SIG, график введения требований EU AI Act, чек-лист соответствия GDPR для шлюза ИИ-API.
