Договор с провайдером ИИ-агента: ключевые клаузулы и риски
Стандартные ToS большинства AI-провайдеров написаны в интересах провайдера, а не оператора. Они ограничивают ответственность провайдера суммой подписки, разрешают менять модель без предупреждения и не дают оператору инструментов защиты при инциденте. Разбираем, что нужно проверить и согласовать до подписания — и что грозит, если этого не сделать.
Подписывая стандартные ToS AI-провайдера, оператор принимает условия, разработанные исключительно в интересах провайдера. Это нормально с точки зрения бизнеса провайдера — но создаёт серьёзные пробелы в защите компании, использующей агента.
Ответственность ограничена подпиской
Стандартный лимит ответственности — сумма, уплаченная за последние 12 месяцев. При серьёзном инциденте это $100–10 000, тогда как реальный ущерб может быть на порядки больше.
Модель меняется без уведомления
Большинство ToS прямо оговаривают право провайдера изменять модели, параметры и функциональность в любое время. Поведение агента меняется — оператор узнаёт постфактум.
Данные могут использоваться для обучения
Часть провайдеров по умолчанию использует запросы и ответы для улучшения модели. Для корпоративных и персональных данных это может нарушать GDPR и условия конфиденциальности.
Главный принцип работы с договорами AI-провайдеров
Стандартный ToS — это отправная точка, а не финальный документ. Enterprise-планы большинства крупных провайдеров предполагают согласование ключевых условий. Даже если полный пересмотр невозможен — правильно выбранные приоритеты переговоров дают оператору существенно лучшую позицию при инциденте.
Ключевой вопрос при работе с AI-провайдером: что происходит с данными, которые агент обрабатывает? Используются ли они для обучения модели? Передаются ли третьим лицам? Кто владеет правами на входящие и исходящие данные?
Широкое право на использование данных
Многие стандартные ToS содержат право использовать данные для «улучшения сервиса» без ограничений.
«We may use content you submit to improve our models and services.»Явный запрет использования для обучения
Enterprise-DPA должен прямо запрещать использование корпоративных данных для обучения моделей провайдера.
«Provider shall not use Customer Data to train, improve, or fine-tune AI models.»Три типа данных в контексте агента — каждый требует отдельного анализа:
Это наиболее критичный раздел договора с точки зрения защиты оператора. Стандартные лимиты ответственности провайдеров катастрофически малы по сравнению с реальным ущербом, который может причинить агент.
Например: $1 200/год
Например: $500K–$5M
Практическая рекомендация: если полный пересмотр лимитов невозможен — сфокусируйтесь на трёх приоритетах: (1) IP indemnity на вывод агента, (2) отдельный лимит для data breach, (3) обязанность провайдера уведомлять об инцидентах в течение 72 часов. Эти три пункта дают наибольшую практическую защиту при минимальных переговорных усилиях.
Одна из наиболее опасных особенностей стандартных ToS — право провайдера обновить или изменить модель в любое время без уведомления оператора. Поведение агента меняется, продукт начинает работать иначе, клиенты получают непредвиденные результаты.
Типичный сценарий без change control
Провайдер выпускает обновление модели — новая версия даёт другие результаты на тех же промптах, меняет тон, точность или поведение в edge cases. Агент начинает систематически ошибаться. Оператор замечает через несколько дней по жалобам клиентов — договор не предусматривал ни уведомления, ни rollback. Ущерб уже нанесён, претензии к провайдеру ограничены стандартным лимитом ответственности.
Обязательное уведомление о материальных изменениях
Провайдер обязан уведомить оператора о любом изменении модели, влияющем на функциональность, за согласованный срок.
«Provider shall give Customer at least 30 days' written notice prior to any material change to the AI model.»Право на тестирование перед обновлением
Оператор должен иметь возможность протестировать новую версию в sandbox-среде до её применения в продакшн.
«Customer shall have access to the updated model in staging for 14 days prior to production deployment.»Право на rollback
При существенном ухудшении качества оператор должен иметь возможность вернуться к предыдущей версии модели на согласованный срок.
«Customer may request rollback to the prior model version within 30 days of a material update.»Version pinning (фиксация версии)
Для критичных сценариев — право зафиксировать конкретную версию модели на согласованный период, исключив автоматические обновления.
«Customer may pin a specific model version for up to 12 months upon written notice.»Важно понимать: крупные провайдеры (OpenAI, Anthropic, Google) предоставляют версионирование моделей через API — например, `gpt-4-0125-preview` вместо просто `gpt-4`. Это частичная защита, но не замена договорному change control: конкретные версии поддерживаются ограниченное время и также могут быть выведены из обращения.
Если агент интегрирован в бизнес-процессы или клиентский продукт — его недоступность это операционный ущерб. Стандартные ToS почти никогда не предусматривают компенсацию за downtime, ограничиваясь декларативными обязательствами «коммерчески разумных усилий».
Uptime SLA
Минимальная гарантированная доступность сервиса в процентах. Разница между 99% и 99.9% — это 8.7 часов vs 52 минуты простоя в год.
RTO / RPO
Recovery Time Objective (время восстановления) и Recovery Point Objective (допустимая потеря данных). Критично для агентов с состоянием.
Service credits
Компенсация за нарушение SLA — обычно в форме кредитов на счёт. Нужно проверить: автоматические или требуют заявки, реальны ли суммы.
| Параметр SLA | Стандартный ToS | Что согласовать |
|---|---|---|
| Uptime | «commercially reasonable efforts» | ≥ 99.9% monthly uptime |
| Incident response time | Не определён | P1: 1ч, P2: 4ч, P3: 24ч |
| Плановые работы | По усмотрению провайдера | Уведомление ≥ 48ч, вне пиковых часов |
| Service credits за нарушение SLA | Отсутствуют или формальны | 10–30% от месячной оплаты за каждый % нарушения |
| Уведомление об инцидентах | Status page без прямых уведомлений | Прямое уведомление в течение 2ч + RCA в 72ч |
| Право на расторжение при систематических нарушениях | Не предусмотрено | Право расторгнуть при нарушении SLA ≥ 3 раза в квартал |
Кому принадлежат документы, тексты, код и решения, созданные агентом? Этот вопрос имеет два измерения: авторское право (может ли output вообще охраняться как объект IP?) и договорное право (что говорит ToS провайдера о праве использования output?).
Авторское право на AI-generated output
Большинство юрисдикций пока не признают AI-generated контент объектом авторского права — он создан не человеком. Это означает:
- Output агента может оказаться в public domain
- Конкуренты могут свободно использовать результаты
- Защита через патент или trade secret — альтернативные пути
- Позиция меняется: суды и регуляторы уточняют подходы
Что говорит ToS о правах на output
Большинство провайдеров передают оператору права на использование output с оговорками. Нужно проверить:
- Scope лицензии: коммерческое использование разрешено?
- Ограничения: нельзя использовать для обучения конкурирующих моделей?
- Схожий output: провайдер может давать одинаковые ответы разным клиентам
- IP indemnity: защищает ли провайдер от претензий за IP в output?
Практический совет: если output агента является ключевым бизнес-активом — фокусируйтесь не на авторском праве (его может не быть), а на trade secret защите процесса: уникальные промпты, fine-tuning данные, архитектура агента. Именно это создаёт реальное конкурентное преимущество и поддаётся правовой защите.
Не все пункты одинаково важны. Вот приоритизация по критичности — что закрыть в первую очередь, что важно, но терпит, и что хорошо иметь при возможности.
- Training restrictions — явный запрет на обучение модели на ваших данных
- DPA — обязательно при работе с персональными данными ЕС
- Уведомление об инцидентах безопасности ≤ 72ч
- Уведомление о материальных изменениях модели
- Право расторгнуть договор при нарушении ключевых условий
- Увеличенный лимит ответственности (выше суммы подписки)
- IP indemnity на output агента
- SLA с конкретными метриками uptime
- Service credits за нарушение SLA
- Право на тестирование перед обновлением
- Список sub-processors и согласие на их изменение
- Version pinning для критичных use cases
- Право на rollback после обновления
- Аудит-права для проверки соответствия
- Mutual NDA на условия договора
- Dedicated support с именным менеджером
- SCC / Binding Corporate Rules для трансграничной передачи
- Провайдер не использует данные для обучения модели (явно прописано)
- DPA подписан и содержит актуальные SCC для передачи данных в США
- Лимит ответственности провайдера выше суммы подписки
- Есть обязанность уведомить об инциденте в течение 72ч
- Есть обязанность уведомить о материальном изменении модели
- Определены метрики uptime и компенсации при нарушении
- Права оператора на использование output в коммерческих целях — явно прописаны
- Список sub-processors известен и контролируется
- Порядок расторжения и возврата/удаления данных при прекращении договора
- Права оператора на fine-tuned модель (если применимо)
Договор с провайдером — часть более широкой правовой системы агента.
Юридическое сопровождение ИИ-агентов
Полный цикл: оценка рисков, договор с провайдером, GDPR, Governance.
Договорное распределение рисков ИИ
ToU, MSA, DPA — полный пакет договорной защиты оператора.
Ответственность за действия ИИ-агента
Цепочка ответственности и как договор с провайдером влияет на вашу позицию.
ИИ-агент и GDPR
DPA с провайдером — детальный разбор требований GDPR к договору.
Multi-agent системы: правовые риски
Как усложняется договорная структура при нескольких провайдерах агентов.
Гайд: ИИ-агенты — правовое регулирование
Полный разбор: определение, виды, EU AI Act, GDPR, договоры, multi-agent.
Пришлите ToS или опишите провайдера и сценарии использования. Проанализируем ключевые риски, выделим приоритеты для переговоров и подготовим редлайн с согласованными клаузулами.
Материал подготовлен для общего информирования и не является юридической консультацией или заключением по конкретной ситуации.