Поставщик загружает договор, просит модель найти риски и через десять секунд показывает аккуратную таблицу. Демонстрация отвечает на вопрос может ли система однажды дать хороший результат. Покупателю нужен другой ответ: насколько предсказуемо она работает на его данных, кто отвечает за ошибку и что произойдет после обновления или расторжения договора.
NIST строит добровольную рамку управления рисками ИИ вокруг четырех функций: govern, map, measure и manage. В профиле для генеративного ИИ ведомство отдельно рассматривает риски, усиленные такими системами, и рекомендует документировать тестирование, источники, роли, инциденты и мониторинг. Это хороший каркас закупки, даже если компания не обязана применять американский стандарт.
1. Какую задачу решаем
Запишите решение без слова ИИ: сократить время первичной классификации писем, извлекать поля из счетов, готовить черновик ответа, искать по внутренним инструкциям. Укажите пользователя, объем, допустимую задержку и последствия ошибки. Помощник для идей и система, влияющая на кредит, здоровье или увольнение, требуют разной строгости.
Определите метрику до пилота. Это может быть доля правильно извлеченных полей, время сотрудника, процент ответов, которые приняты без исправлений, или число критических пропусков. Экономия времени без учета проверки часто оказывается фикцией.
2. Какие данные уходят поставщику
Нарисуйте путь запроса, вложения, контекста, ответа, журналов и резервных копий. Где они хранятся, кто имеет доступ, используются ли для обучения, каков срок удаления, можно ли отключить сохранение? Отдельно спросите о субподрядчиках и регионах обработки.
В договоре должны совпадать обещания продавца и техническая настройка аккаунта. Фраза мы не обучаемся на ваших данных может не покрывать журналы диагностики, обратную связь пользователя или сторонний модуль фильтрации.
3. Какая модель работает сегодня
Уточните поставщика и версию модели, правила обновления, доступ к журналу изменений и возможность отложить миграцию. Облачный продукт под тем же названием способен завтра отвечать иначе. Для критичного процесса нужен повторный тест после существенного изменения.
Спросите, какие компоненты дополняют модель: поиск по базе, системные инструкции, фильтры, внешние инструменты. Ошибка может находиться не в языковой модели, а в устаревшем индексе или чрезмерных правах подключенного агента.
4. На чем проверяли качество
Средний публичный benchmark редко отражает документы компании. Дайте поставщику обезличенный набор обычных, сложных и заведомо провокационных примеров. Сохраните ожидаемый результат и оцените не только точность, но уверенные выдумки, пропуски и устойчивость к небольшому изменению формулировки.
Тестовый набор не должен полностью становиться известен команде настройки, иначе результат подгонят. Оставьте закрытую часть для приемки. Проверяйте группы пользователей и языки, которые реально будут в работе.
5. Может ли ответ сослаться на основание
Для поиска по внутренним документам требуйте ссылку на конкретный источник, версию и фрагмент. Ссылка не гарантирует верный вывод, но ускоряет проверку. Если документ изменился, индекс должен обновиться с понятной задержкой и удалить старую версию.
Для творческой задачи происхождение отдельных фраз тоже важно: договор должен объяснять права на входные и выходные данные, обработку претензий и ограничения использования.
6. Где обязателен человек
Назначьте действия, которые система не выполняет самостоятельно: отправка денег, публикация, изменение прав, медицинское или юридическое решение. Кнопка подтверждения не является контролем, если сотрудник видит сотни ответов и не имеет исходных данных.
Человеку нужны время, полномочия отклонить ответ и понятные признаки риска. Интерфейс должен отличать черновик от подтвержденного результата.
7. Какие есть журналы
Для разбора инцидента понадобятся пользователь, время, версия модели, системная инструкция, подключенные документы, вызванные инструменты и итоговое действие. Секреты и персональные данные в журнале защищают и минимизируют. Срок хранения согласуют с расследованием и требованиями приватности.
8. Как система сопротивляется опасному вводу
Документ из внешнего источника может содержать команду игнорировать правила и отправить данные. Проверьте prompt injection, вредные вложения, чрезмерные права инструментов и утечку между клиентами. Агенту дают минимальные разрешения, отдельные тестовые учетные записи и лимиты операций.
9. Как сообщат об инциденте
В договоре фиксируют срок уведомления, контакт 24/7, состав первичной информации и обновления. Инцидент у модели, облака или субподрядчика должен доходить до покупателя. Попросите пример обезличенного уведомления и отчет прошлой тренировки.
10. Что происходит при недоступности
Определите ручной режим, очередь запросов, максимальную потерю данных и приоритет восстановления. Если процесс не может работать без сервиса два часа, это должно влиять на архитектуру и цену. Маркетинговый процент доступности сравнивают с исключениями и компенсацией.
11. Как уйти от поставщика
Экспорт должен включать документы, метаданные, инструкции, журналы и результаты в пригодном формате. Проведите пробный экспорт в пилоте. Укажите срок удаления копий и подтверждение. Без выхода низкая стартовая цена превращается в зависимость.
12. Кто владеет риском
Назначьте владельца со стороны бизнеса, безопасности, данных и права. Поставщик отвечает за платформу в пределах договора, но не выбирает допустимость конкретного решения за клиента. Реестр должен содержать цель, данные, модель, тесты, ограничения, инциденты и дату повторной оценки.
В 2026 году рамка NIST AI RMF пересматривается, а новые профили продолжают разрабатываться. Это еще одна причина не превращать чек-лист в разовый сертификат. Закупка заканчивается не подписью, а наблюдением: качество, данные и модель меняются, значит контроль должен повторяться.
Хороший пилот иногда заканчивается отказом. Если поставщик не раскрывает маршрут данных, не допускает проверку на реальных случаях и не дает забрать результаты, эффектная демонстрация становится предупреждением. Ценность ИИ измеряется не длиной ответа, а надежностью процесса вокруг него.