# Как составить анкету оценки поставщика ИИ

> Эта анкета оценки поставщика ИИ проверяет заявления о данных, моделях, инцидентах, подтверждениях, договоре и рабочем плане выхода.

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

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

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

## Сначала определите сервис, затем спрашивайте о мерах защиты

Поставщик сможет отвечать последовательно, только если вы назовете конкретный продукт, вариант развертывания и предполагаемый сценарий. Формулировка «оценить поставщика X» слишком широка. Одна компания может продавать публичный чат, корпоративное рабочее пространство, API и закрытое развертывание. Для каждого варианта будут свои сроки хранения, субподрядчики, модели и административные настройки.

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

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

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

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

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

NIST AI RMF делит работу на Govern, Map, Measure и Manage. Здесь такое разделение полезно: оно не дает выдавать политику за измерение или готовность к реагированию. Двадцать вопросов намеренно выясняют, что делает система, как поставщик это проверяет и кто действует при сбое.

## Вопросы 1-5 устанавливают границу данных

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

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

Полный ответ на вопрос 1 должен выглядеть как небольшой реестр данных, а не как абзац о шифровании. Попросите поставщика отделить содержимое от технических метаданных. Даже без хранения текста запроса метаданные могут раскрывать названия проектов, личности пользователей, время, имена файлов, IP-адреса, объем токенов и цели интеграций.

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

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

## Вопросы 6-10 позволяют проверить заявления о моделях

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

6. Какие семейства и версии моделей, варианты размещения и резервные модели могут обрабатывать наши данные, и можем ли мы закрепить версию или согласовывать существенные изменения модели?
7. Какие оценки вы проводите до выпуска для нашего сценария, включая точность, вредные результаты, утечку данных, инъекции в запросы и неправильное применение инструментов, и какие пороги выпуска установлены?
8. Как вы отслеживаете поведение модели и приложения после выпуска, расследуете ухудшения и откатываете модель, системный запрос, источник базы знаний или настройку инструмента?
9. Где сервис принимает или рекомендует значимые решения, какие сведения объясняют результат и какие решения требуют одобрения человеком?
10. Какие технические ограничения не дают модели или агенту получить данные и выполнить действия за пределами прав текущего пользователя и поставленной задачи?

Не принимайте фразу «мы используем новейшую модель» как ответ на вопрос 6. Автоматические обновления дают операционное удобство ценой непроверенного изменения поведения. Если закрепить версию нельзя, запросите уведомление, журнал изменений, результаты проверок для вашего процесса и способ отката. Поставщик может дать достаточный контроль, не раскрывая веса модели или собственные системные запросы.

Вопрос 7 отделяет название оценки от рабочего порога. «Мы проверяем галлюцинации» означает лишь заявление. В содержательном ответе указаны владелец набора тестов, метод выборки, метрика, порог приемки, порядок работы со сбоем и дата последнего запуска. Ошибка помощника для черновиков может только раздражать. Та же ошибка агента, который оформляет возвраты, попадает в учетную систему. Оценка должна соответствовать действию.

В OWASP Top 10 for LLM Applications инъекции в запросы, раскрытие чувствительной информации, слабости цепочки поставок, неправильная обработка результатов и избыточные полномочия считаются разными видами сбоев. Это правильное разделение. Системный запрос с указанием игнорировать вредоносные инструкции не контролирует права доступа. Ответ на вопрос 10 должен подтверждать применение ограниченных учетных данных, серверных проверок прав, списков разрешенных инструментов, проверки аргументов, лимитов операций, точек одобрения и изоляции клиентов.

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

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

## Вопросы 11-15 показывают готовность к защите и инцидентам

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

11. Какие меры защищают данные заказчика при передаче, хранении и разделении между клиентами, и как вы проверяете изоляцию клиентов и привилегированный доступ?
12. Какие события сервиса вы записываете для аутентификации, администрирования, доступа к данным, запросов к модели, поиска по базе знаний, вызовов инструментов, блокировок по правилам и экспорта, и какие журналы может получить заказчик?
13. Как вы обнаруживаете и обрабатываете специфические злоупотребления ИИ, включая инъекции в запросы, вывод чувствительных сведений, отравленные материалы в базе знаний, извлечение модели и несанкционированные действия агента?
14. Как устроен ваш процесс работы с инцидентами, кто дежурит, какие подтверждения вы можете сохранить и в какой договорный срок уведомите нас об инциденте, затронувшем наши данные или сервис?
15. Что не сработало во время последнего подходящего инцидента или учения, сколько заняли обнаружение и локализация и какие исправления еще не завершены?

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

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

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

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

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

## Вопросы 16-20 определяют, сможете ли вы уйти

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

16. Какие материалы заказчика, настройки, запросы, определения агентов, журналы, записи оценок и метаданные мы можем экспортировать, в каких документированных форматах и через какой интерфейс?
17. Если мы расторгнем договор, каковы сроки отключения доступа, экспорта, удаления из активных систем, истечения резервных копий, удаления у субподрядчиков и письменного подтверждения?
18. Какие компоненты сервиса, функции модели или закрытые форматы придется заменить и какая помощь с переносом доступна по какой закрепленной в договоре цене?
19. Что произойдет с доступом к сервису и нашими данными, если вы закроете функцию, замените модель, столкнетесь с длительным сбоем, смените владельца или прекратите работу?
20. Какие обязательства сохраняются после расторжения, включая конфиденциальность, безопасность, уведомление об инцидентах, юридическое сохранение данных, материалы аудита и ограничения на использование данных?

Если процесс важен, проверьте вопрос 16 до подписания. Запросите пример экспорта или выполните его на синтетических данных. Проверьте наличие стабильных идентификаторов и описанных связей, а также возможность разобрать архив другой системой без восстановления состояния по снимкам экрана. CSV с названиями диалогов не дает переносимости, когда рабочий процесс зависит от описаний инструментов и ссылок на источники.

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

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

## Подтверждения превращают текст в проверяемый ответ

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

Дайте поставщику компактный формат, чтобы ответы было удобно сравнивать. Таблица подойдет, но структурированный текст лучше справляется с длинными оговорками и историей версий. Этот пример намеренно прост:

```json
{
  "question_id": 10,
  "response": "partial",
  "explanation": "Tool access inherits workspace roles; payment actions require a separate customer approval rule.",
  "customer_action": "Enable the approval rule before connecting the payment system.",
  "evidence": ["Agent authorization design v3", "Tool call isolation test 2026-04"],
  "owner": "Head of Product Security",
  "valid_until": "2027-04-30"
}
```

Значение "partial" часто полезнее, чем yes или no. Оно обозначает границу, которую можно закрыть договором, планом развертывания или принятием риска. Не наказывайте за честные оговорки автоматическим снижением оценки поставщика. Если процесс поощряет безусловные ответы «да», поставщики научатся убирать подробности.

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

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

## Оценивайте риск и исключения, а не лоск поставщика

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

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

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

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

Cloud Security Alliance связывает большой набор AI Consensus Assessment Initiative Questionnaire со своей матрицей AI Controls Matrix. Такой каталог мер пригодится, если первый этап выявил высокий риск или регулируемому заказчику нужно подробное сопоставление требований. Сотни вопросов каждому поставщику на входе дают скопированные формулировки политик и недели задержки. Двадцать точных вопросов создают карту для дальнейшей проверки.

## Безупречное «да» может скрывать сломанное развертывание

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

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

Двадцать вопросов выявляют каждый пробел без предположения о злых намерениях. Вопрос 1 учитывает вложения и журналы. Вопрос 2 уточняет срок хранения по категориям. Вопрос 10 спрашивает, как права ограничивают действия. Вопросы 11 и 12 требуют подтверждения изоляции и каталога событий. Вопрос 14 фиксирует срок уведомления, а вопрос 16 проверяет, сможет ли покупатель получить настройки и аудиторский след.

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

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

## Перенесите ответы в договор и рабочий план

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

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

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

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

Основатели без отдельной службы безопасности или закупок могут заказать Team & AI Audit на oleg.is. За пять рабочих дней проверка охватит сценарий, ответы поставщика и внутренние решения по развертыванию в рамках более широкой оценки. Полезный результат выглядит как зафиксированное решение с условиями, ответственными и затратами, а не как очередная папка политик.

## Отправьте двадцать вопросов и требуйте точных существительных

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

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

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

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