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

Комплексная проверка ИИ отличается от обычной проверки программного обеспечения тем, что система ИИ может выдать уверенный неправильный ответ, быть убеждена отступить от собственных правил, утечь данные или изменить поведение после обновления модели, которое поставщик развёртывает во вторник. Вы обнаруживаете эти риски путём тестирования поведения и контролируете их с помощью условий контракта, которые определяют, что происходит, когда поведение отклоняется.

Почему комплексная проверка поставщика ИИ теперь формальное ожидание

Покупка ИИ когда-то рассматривалась как закупка программного обеспечения с дополнительным абзацем о данных. Государственные покупатели и законодатели по обе стороны Атлантики изменили это.

US federal покупатели: OMB меморандум M-25-22

3 апреля 2025 года Офис управления и бюджета Белого дома издал меморандум M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government. Он применяется к контрактам, присуждённым по запросам предложений, выданным в течение 180 дней или более после выпуска меморандума, и к опциям продления, осуществляемым после этого момента. Раздел 4(d) говорит, что агентства "должны включать условия, которые касаются" перечня тем в контрактах на системы и услуги ИИ. Среди них:

• Постоянный мониторинг производительности. Контракты должны позволять агентству регулярно контролировать и оценивать производительность системы, риски и эффективность, с ежеквартальными или двухгодичными проверками в качестве примеров.
• Независимое тестирование. Агентства должны проводить тестирование с использованием своих наборов данных, которые "не должны быть доступны поставщику", поставщики должны предоставить "доступ и время, необходимые агентствам для проведения независимой оценки", и результаты тестирования должны быть "достаточно подробными, чтобы тестирование можно было независимо проверить или воспроизвести, если возможно".
• Защита от привязки к поставщику. Условия могут включать передачу знаний, "переносимость данных и модели" и прозрачность в отношении лицензирования и ценообразования.
• Ограничения на обучение с использованием ваших данных. Раздел 3(e) требует, чтобы контракты "окончательно запретили использование непубличных введённых данных агентства и выходных результатов" для дальнейшего обучения общедоступных или коммерчески доступных ИИ, если агентство явно не дало согласие.
• Уведомление перед изменениями. Агентства должны рассмотреть возможность требования от поставщиков уведомления перед интеграцией новых улучшений ИИ, и им рекомендуется требовать от поставщиков соответствия стандартам производительности перед развертыванием новых версий и откатом при необходимости.

Второй меморандум, OMB M-26-04 от 11 декабря 2025 года, указывает, что он "дополняет" M-25-22. Для контрактов на большие языковые модели в нем указывается информация, которую агентства должны запрашивать у поставщиков: политика допустимого использования, карточки моделей, систем или данных, ресурсы для конечных пользователей и механизм обратной связи конечных пользователей. Он также позволяет агентствам запрашивать дополнительные данные, такие как результаты оценки.

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

Организации в ЕС, использующие ИИ: требования Закона об ИИ к покупателю

Европейский закон об ИИ, Регламент (ЕС) 2024/1689, именует организацию, которая использует систему ИИ под своей собственной ответственностью, "развертывающей организацией". Если вы приобретаете высокорисковую систему ИИ и вводите ее в эксплуатацию, Статья 26 возлагает на вас обязательства, отдельные от обязательств поставщика. В консолидированном тексте, опубликованном на портале Служба поддержки Закона об ИИ Европейской комиссии, Статья 26 гласит:

• Развертывающие организации "принимают надлежащие технические и организационные меры для обеспечения использования таких систем в соответствии с инструкциями по эксплуатации, сопровождающими системы" (Статья 26(1)).
• Развертывающие организации "назначают надзор человека лицам, обладающим необходимой компетентностью, обучением и полномочиями" (Статья 26(2)).
• Развертывающие организации "осуществляют мониторинг работы высокорисковой системы ИИ на основе инструкций по эксплуатации", и если у них есть основания полагать, что система представляет риск, они должны проинформировать поставщика или дистрибьютора и соответствующий орган рыночного надзора и приостановить использование (Статья 26(5)).
• Развертывающие организации "сохраняют журналы, автоматически создаваемые высокорисковой системой ИИ", в той степени, в которой эти журналы находятся под их контролем, в течение как минимум шести месяцев, если иное не предусмотрено другим законодательством (Статья 26(6)).
• Развертывающие организации систем Приложения III, которые принимают или помогают принимать решения о людях, "проинформируют физических лиц о том, что на них распространяется использование высокорисковой системы ИИ" (Статья 26(11)).

Каждое из этих обязательств зависит от информации, которую вы можете получить только у поставщика. Вы не можете следовать инструкциям по использованию, которые никогда не получали, сохранять журналы, которые система не экспортирует, или мониторить поведение, которое вы не можете измерить. Статья 13 представляет сторону поставщика в той же сделке: высокорисковые системы должны поставляться с инструкциями по эксплуатации, которые включают, помимо прочего, "уровень точности, включая его метрики, надежность и кибербезопасность" (Статья 13(3)(b)(ii)). Надлежащая проверка - это способ убедиться, что эти материалы существуют и достаточно хороши для того, чтобы вы могли выполнить свою часть работы.

Сроки имеют значение. Согласно поправкам Digital Omnibus, Статья 113 теперь применяет правила для высокорисковых систем со 2 декабря 2027 года для отдельных систем, указанных в Приложении III, и со 2 августа 2028 года для ИИ, встроенного в продукты, охватываемые Приложением I. Контракты, которые вы подписываете сегодня, часто будут действовать и в эти даты, поэтому имеет смысл прописать обязательства сейчас. Отдельно, Статья 4 просит поставщиков и развертывающих организаций систем ИИ в целом, не только высокорисковых, "принимать меры в поддержку развития грамотности в области ИИ" персонала, который их использует и управляет ими. Для более полного понимания правовой базы см. наше полное руководство по Закону об ИИ ЕС и законам об ИИ США.

Добровольные рамки указывают в том же направлении

Основа управления рисками NIST AI RMF предусматривает отдельную категорию для ИИ третьих сторон. GOVERN 6.1 гласит "На месте политики и процедуры, которые устраняют риски ИИ, связанные с субъектами третьих сторон", GOVERN 6.2 гласит "На месте процессы непредвиденных обстоятельств для обработки сбоев или инцидентов в данных или системах ИИ третьих сторон, считающихся высокорисковыми", а MANAGE 3.1 говорит, что риски от ресурсов третьих сторон должны быть "регулярно мониторируются, и применяются и документируются средства контроля рисков." Если ваша организация уже согласуется с NIST AI RMF или использует систему управления ISO/IEC 42001, надлежащая проверка поставщика - это способ выполнить эти ожидания для ИИ, который вы приобретаете. Наше руководство по NIST AI RMF, ISO/IEC 42001 и связанным стандартам охватывает то, как рамки согласуются.

Шесть областей оценки

Каждый обзор поставщика ИИ сводится к шести областям.

1. Что представляет собой система и для чего она нужна

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

2. Доказательства безопасного поведения

Это область, которую большинство покупателей обрабатывают хуже всего, потому что об этом трудно спросить в вопроснике. "Вы тестируете на предвзятость?" получит положительный ответ от всех. Лучшие вопросы запрашивают метод и результат: что было протестировано, против каких сценариев, с каким процентом успеха, кем и когда. Поведенческие риски, достойные внимания, соответствуют семи столпам рамки A.E.G.I.S.™:

• Hallucination Integrity: излагает ли система ложные утверждения как факты, особенно под давлением, неясности или при специализированных вопросах?
• Guardrail Resistance: можно ли ее манипулировать, чтобы она вела себя небезопасно, посредством попыток jailbreak или инъекции подсказок?
• Data Handling & Privacy: что она собирает, сохраняет и раскрывает, включая персональные данные?
• Ethical Alignment: ведет ли она себя надлежащим образом с уязвимыми пользователями и чувствительными темами?
• Autonomy & Control: насколько далеко она может действовать самостоятельно, и может ли человек остановить ее?
• Adversarial Robustness: как система ведёт себя перед лицом мотивированного нападающего?
• Explainability and Transparency: можно ли понять её поведение и провести аудит постфактум?

Подробнее о том, как именно это тестируется, см. как системы искусственного интеллекта тестируются на безопасность. Ключевое различие для покупателя состоит в том, получены ли результаты самим поставщиком или независимой стороной. Внутреннее тестирование имеет ценность, но это поставщик, проверяющий собственные домашние задания. M-25-22 высказывает то же самое с позиции покупателя, требуя тестирования достаточно подробного, чтобы быть "независимо проверяемым или воспроизводимым".

3. Обработка данных

Узнайте, куда идут ваши данные, как долго они хранятся, кто может их видеть и обучают ли они что-либо. Федеральный стандарт M-25-22 служит полезным ориентиром: поставщики могут собирать и хранить информацию агентства только если это "разумно необходимо" для контракта, а непубличные входные и выходные данные не могут использоваться для обучения публичных или коммерческих моделей без согласия. Также узнайте, доступны ли вам логи системы, так как операторы высокорисковых систем в ЕС должны держать логи под своим контролем.

4. Надзор и контроль

Выясните, что может сделать человек, когда система ошибается. Может ли оператор пересмотреть или переопределить результаты, либо приостановить систему? Статья 26(2) предполагает, что вы назначите компетентных людей для надзора; поставщик должен предоставить им инструмент для работы.

5. Управление изменениями и мониторинг

AI-продукты меняются за вашей спиной: новая базовая модель или переобучение, и поведение, которое вы одобрили, больше не совпадает с поведением в production. Узнайте, как поставщик сообщает вам о существенных изменениях, можете ли вы провести тестирование до выпуска новой версии вашим пользователям и может ли версия быть откачена. M-25-22 рекомендует агентствам рассмотреть или потребовать всё три. Затем узнайте, какой мониторинг существует после запуска и делятся ли результаты с вами.

6. Инциденты и ответственность

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

Список вопросов, который вы можете отправить AI-поставщикам

Скопируйте их в ваш RFP. Каждый требует чего-то, что вы можете проверить.

Область и назначение

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

Тестирование и доказательства

5. Против каких рисков безопасности вы тестировали продукт (например, галлюцинации, jailbreaks и prompt injection, утечки приватности, поведение с уязвимыми пользователями, пределы автономии, adversarial attack, объяснимость)? Для каждого: какой метод был использован и каков результат?
6. Были ли какие-либо из этих тестов проведены независимой стороной? Кем, когда, против какой версии, и можем ли мы сами проверить результат?
7. Предоставите ли вы нам доступ и время для проведения собственной оценки, используя тестовые данные, которые вы не видите?
8. Каковы задокументированные уровни точности, надёжности и кибербезопасности, и как они измерялись?

Данные

9. Какие данные из вашего использования вы собираете и сохраняете, как долго, и почему необходим каждый элемент?
10. Будут ли наши входные или выходные данные использоваться для обучения или улучшения какой-либо модели, вашей или третьей стороны? Можно ли это запретить контрактом?
11. Какие субпроцессоры, включая поставщиков моделей, получают доступ к нашим данным?
12. Какие журналы логирования создает система, и можем ли мы их экспортировать и сохранять?

Управление, изменения и инциденты

13. Какие возможности контроля и переопределения доступны нашим операторам?
14. Как и когда вы уведомите нас об существенном изменении модели или её поведения? Можем ли мы протестировать новую версию перед её развёртыванием для пользователей, и можем ли мы откатиться к предыдущей?
15. Как вы отслеживаете продукт после развёртывания, и будете ли вы делиться с нами результатами мониторинга?
16. Каков ваш процесс реагирования на инциденты, вызванные сбоями ИИ, и каковы ваши обязательства по уведомлению?
17. Если мы уходим, как мы получаем наши данные и любые настройки, и в каком формате?

Преобразование ответов в условия контракта

Ответы в анкете - это утверждения. Контракт - это то, где они становятся обязательствами. M-25-22 предоставляет шаблон по темам, и частные покупатели могут адаптировать его без значительных изменений.

• Обязательства по производительности и безопасности. Закрепите протестированное поведение в соглашении: задокументированные уровни точности и безопасности, график периодических проверок и то, что происходит, если результаты ниже этих уровней.
• Право на оценку. Зарезервируйте право проводить собственное тестирование или привлечь независимую сторону для тестирования с доступом и временем от поставщика.
• Ограничения на использование данных. Запретите обучение на ваших входных и выходных данных без письменного согласия, ограничьте хранение необходимым минимумом и укажите субпроцессоров.
• Уведомление об изменениях. Требуйте предварительного уведомления об существенных изменениях модели и периода тестирования перед их развёртыванием в production, с возможностью отката.
• Логирование и документация. Требуйте, чтобы система генерировала и экспортировала нужные вам журналы, и установите, как долго поставщик хранит свои собственные.
• Сотрудничество при инцидентах. Установите сроки уведомления об инцидентах, связанных с ИИ, и обязательство помочь вам выполнить любые установленные вами требования по отчётности.
• Переносимость. Охватите переносимость данных и моделей, передачу знаний и прозрачное лицензирование, чтобы вы могли уйти, если это необходимо.

M-26-04 добавляет полезный приём: он требует от агентств определить определённые требования как "существенные для приемлемости и оплаты по контракту". Указание условий безопасности и прозрачности как существенных придаёт им силу, поскольку их нарушение становится основанием для средств защиты вместо того, чтобы быть просто примечанием.

Где комплексная проверка обычно дает сбой

Большинство неудачных проверок поставщиков ИИ происходят одним из нескольких предсказуемых способов.

Анкета - это форма безопасности с добавленными вопросами об ИИ. Отчёт SOC 2, согласно описанию самой AICPA, является проверкой средств контроля в организации, предоставляющей услуги, относящихся к безопасности, доступности, целостности обработки, конфиденциальности или приватности. Это ценно, и это отвечает на другой вопрос, чем может ли модель быть взломана или как часто она выдумывает факты. Разделяйте информационную безопасность и поведение ИИ на отдельные разделы с отдельными доказательствами.

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

Одобрение рассматривается как постоянное. Через шесть месяцев после покупки поставщик изменил модель, и никто не перепроверил. Как M-25-22, так и NIST AI RMF рассматривают мониторинг как непрерывный именно по этой причине.

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

Почему независимая проверяемая оценка ускоряет процесс

Последние две проблемы - самые дорогостоящие. Когда система искусственного интеллекта была оценена независимой стороной по стандартизированной методике, для покупателя меняются три вещи.

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

Во-вторых, доказательства сравнимы. Каждая оценка A.E.G.I.S.™ оценивает одни и те же семь столпов, и параметры оценки фиксируются в каждом периоде, что обеспечивает сопоставимость оценок во времени. Сертифицированные системы получают карту оценки A.E.G.I.S.™ с общей оценкой безопасности от A (Максимальная безопасность) до F (Опасно), оценку по каждому столпу и сертификационную печать от A-5 Guardian до A-1 Unrestricted. Ваши эксперты смогут увидеть в одном месте, где система сильна, а где требуется осторожность, и сравнить двух поставщиков на одной шкале.

В-третьих, доказательства проверяемы и актуальны. Каждый тестовый случай, голос валидатора и решение о сертификации привязаны хешированием SHA-256 в неизменяемый журнал аудита, поэтому записи не могут быть изменены или датированы задним числом. Любой может проверить сертификацию RateAI в открытом реестре безопасности без входа и подтвердить, что она актуальна и не была понижена. Сертификации также имеют цикл повторной сертификации, и существенные изменения системы инициируют переоценку, что непосредственно решает проблему управления изменениями, описанную выше.

Оценка не заменяет вашу проверку надлежащей осмотрительности. Вы по-прежнему нуждаетесь в информации о масштабе, условиях контракта, потоках данных и соответствии вашему варианту использования, и сертификация RateAI не является юридическим определением: она поддерживает вашу работу по обеспечению соответствия, а нормативные решения остаются с компетентными органами. Уровни Pro и Enterprise RateAI включают сопоставление соответствия EU AI Act, NIST AI RMF и ISO 42001. Проверяемая оценка отвечает на вопросы доказательства, пункты 5-8 в списке выше, с помощью чего-то, что ваша команда может проверить, вместо того чтобы доверять. Для более глубокого понимания того, как работает сертификация третьей стороной, прочитайте что такое сертификация безопасности ИИ и как она работает.

Практический рабочий процесс проверки надлежащей осмотрительности

1. Классифицируйте вариант использования. Кого затрагивает система, может ли она действовать самостоятельно и может ли она быть высокорисковой в соответствии с EU AI Act? Более высокие ставки означают более глубокую проверку.
2. Отправьте список вопросов на ранней стадии. Включите его в запрос предложений, чтобы поставщики, которые не могут ответить, выбыли до того, как вы потратите время на демонстрации.
3. Проверьте наличие независимых доказательств. Найдите продукт поставщика в любом независимом реестре, в котором, как он утверждает, он зарегистрирован, и убедитесь, что оценка, дата и версия соответствуют тому, что вы покупаете.
4. Протестируйте оставшееся. Если независимые доказательства отсутствуют или не охватывают ваш вариант использования, проведите собственную оценку на данных, которые поставщик не видел, или закажите её.
5. Согласуйте условия. Преобразуйте ответы в обязательства по контракту: производительность, права на тестирование, использование данных, уведомление об изменениях, логирование, инциденты и переносимость.
6. Установите график мониторинга. Согласуйте, как часто вы будете проверять производительность и что инициирует переоценку, такое как изменение модели или сообщённый инцидент.
7. Зафиксируйте решение. Сохраняйте доказательства, вашу оценку и причины одобрения.

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

Часто задаваемые вопросы

Что такое проверка надлежащей осмотрительности поставщика ИИ?

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

Достаточно ли отчёта SOC 2 для одобрения поставщика ИИ?

Обычно нет, самого по себе. Отчёт SOC 2 проверяет средства контроля организации-поставщика услуг, относящиеся к безопасности, доступности, целостности обработки, конфиденциальности или приватности, поэтому вам по-прежнему нужны отдельные доказательства того, как ведёт себя модель ИИ, такие как неправильные ответы, манипуляция и утечка данных через выходные данные.

Что EU AI Act требует от компаний, которые покупают ИИ?

Организации, которые используют высокорисковые системы ИИ, являются "развёртывающими сторонами" в соответствии со статьёй 26, и должны использовать систему в соответствии с её инструкциями, назначить компетентное управление человеком, контролировать её работу, вести журналы под своим контролем и в некоторых случаях информировать затронутых людей. Эти правила для высокорисковых систем применяются с 2 декабря 2027 г. для систем Annex III и с 2 августа 2028 г. для ИИ, встроенного в продукты, охватываемые Annex I.

Какие условия контракта должна включать покупка ИИ?

Как минимум: обязательства в области производительности и безопасности, право на независимое тестирование, ограничения на использование ваших данных для обучения, предварительное уведомление и тестирование изменений модели, доступ к журналам, сотрудничество по инцидентам и переносимость. Меморандум OMB M-25-22 перечисляет большинство из них как обязательные темы для контрактов ИИ США федерального правительства.

Как независимая оценка безопасности ИИ помогает при закупках?

Это заменяет собственные заявления компаний стандартизированными результатами, полученными третьей стороной, которые вы можете проверить. Рейтинг A.E.G.I.S.™ оценивает систему по тем же семи направлениям, что и любую другую оцениваемую систему, что позволяет вам сравнивать поставщиков и подтверждать актуальность сертификации в открытом реестре безопасности.

Делает ли сертификация RateAI систему искусственного интеллекта юридически соответствующей нормам?

Ни одна сертификация не может сделать такое определение; формальные нормативные решения остаются в компетенции компетентных органов. Сертификация RateAI поддерживает работу по обеспечению соответствия, а её уровни Pro и Enterprise включают сопоставление с требованиями EU AI Act, NIST AI RMF и ISO 42001.

Проверьте рейтинг поставщика перед заключением контракта

Самый быстрый вопрос при проведении комплексной проверки, является ли система уже независимо оценённой. Поиск в реестре безопасности RateAI позволяет увидеть, как перечислены сертифицированные системы ИИ, с их рейтингом A.E.G.I.S.™ и статусом сертификации, и спросите у своих поставщиков, находится ли их продукт в реестре.