Редакция ПотокаДоговор с поставщиком ИИ: что спросить о сбоях, данных и поддержке
При выборе ИИ-сервиса демонстрация отвечает на вопрос «что умеет». Для рабочего процесса важнее другие вопросы: что происходит при сбое, где хранятся данные, кто помогает вернуть сервис и как меняются условия. Эти темы стоит обсудить до договора и зафиксировать в приложении к нему.
Внедрим ИИ в работу вашей компании
Бесплатно разберём процессы и подготовим план запуска ИИ.
Нарисуйте отказ одного обычного дня
Что увидит сотрудник, если модель или интеграция недоступна? Куда уйдут уже принятые заявки? Может ли команда продолжить работу вручную? Кто получает уведомление и в какой канал? Поставщик может отвечать только за свой API, а восстановление вашего процесса остаётся у вашей команды. Эту границу нельзя скрывать общей фразой «поддержка 24/7».
Список вопросов поставщику
| Область | Что уточнить |
|---|---|
| Доступность | Что измеряется и какие исключения есть в SLA? |
| Данные | Где они обрабатываются, сколько хранятся, как удаляются? |
| Изменения | Как сообщают об обновлении моделей и API? |
| Инцидент | Кто и когда уведомляет о сбое или утечке? |
| Выход | Как выгрузить данные и отключить доступ? |
Ответы зависят от договора и выбранной инфраструктуры; статья не заменяет юридическую проверку. Попросите показать конкретный документ, а не только презентацию отдела продаж.
Проверяйте обещание на своём сценарии
Если агент пишет клиентам, тестируйте задержку и повторную отправку при сбое. Если читает внутренние файлы, проверяйте права и удаление доступа после ухода сотрудника. Для задачи черновиков требования могут быть мягче, чем для действия, которое меняет заказ. NIST AI RMF Playbook предлагает учитывать контекст применения и цепочку ответственности. Вопросы договора должны вытекать из этого контекста, а не из универсального списка галочек.
Где заканчивается ответственность поставщика
Допустим, API модели доступен, но ваш коннектор не может записать карточку CRM. Поставщик модели считает сервис работающим, а ваш отдел продаж видит простой. В договоре и схеме поддержки разделите компоненты: модель, интеграция, ваша база знаний, клиентский интерфейс. Для каждого укажите мониторинг и контакт. Иначе единый обещанный процент доступности не объяснит, кто восстанавливает конкретную цепочку.
Проверьте выход из сервиса заранее
Как получить журналы, тестовый набор, документы и настройки при смене платформы? Какие форматы и сроки доступны? Можно ли отозвать токены и подтвердить удаление данных? Не откладывайте вопросы до прекращения договора. Они влияют и на повседневную безопасность: если экспорт невозможен, анализ инцидента и перенос решения будут сложнее.
Приложение к договору на языке процесса
Опишите один критичный маршрут: входящее обращение, поиск данных, черновик, подтверждение менеджера и запись результата. Для каждого шага отметьте зависимость от поставщика и ожидаемое поведение при сбое. Юрист и ИТ-специалист смогут проверить конкретные обязательства. Общая формулировка «сервис ИИ высокой доступности» не заменяет такой карты.
Что покажет пробный отказ
Попросите поставщика или интегратора вместе пройти тест: сервис недоступен, запрос уже принят, подтверждения нет. Кто видит событие, какая задача появится у сотрудника, можно ли проверить, было ли действие выполнено? Не требуется намеренно ломать продуктивную систему; испытание проводят в тестовой среде. Если ответ сводится к «перезапустим и повторим», для писем, заказов и платежей этого недостаточно: повтор может создать дубль.
Не покупайте неопределённое «сопровождение»
Зафиксируйте, кто обновляет документы, кто повторяет тесты после изменения модели, кто разбирает клиентскую ошибку и в какой срок команда получит сообщение о ней. Эти действия часто лежат между поставщиком и заказчиком. Цена подписки может быть понятной, а стоимость ручной поддержки — нет. Смета и ответственность должны покрывать полный цикл работы, а не только первый успешный запуск.
О материале и источниках
Материал подготовлен редакцией Потока с участием ИИ. Первоисточники проверены 27 сентября 2026 года. Примеры иллюстрируют метод и не являются результатами испытания продукта редакцией. Обложка создана через ImageGen и не документирует реальное событие.
- NIST AI RMF Playbook
Первичный материал для проверки подхода и границ применения; пример в статье подготовлен редакцией.
Опубликовано