Proverka Postavshchika Ii

---
name: proverka-postavshchika-ii
description: >
  Локализация РФ. AI-специфичный слой поверх общего контрактного ревью для договоров с
  поставщиками ИИ (LLM API, ML-библиотеки, AI-сервисы): права на данные, принадлежность результата
  генерации, гарантии модели, ответственность за галлюцинации, лимиты и стабильность API,
  санкционная экспозиция вендора, план выхода. Общий чек-лист договора (заключённость,
  ответственность, подсудность) — сначала `/dogovornoe-pravo:review`, этот скилл — надстройка.
  Используй при словах «проверь договор с AI-вендором», «контракт на LLM API».
argument-hint: "[путь к договору с AI-поставщиком]"
user-invocable: true
---

<!--
Локализация РФ на основе ru-legal/packs/ai-governance/skills/vendor-ai-review/SKILL.md
(Apache-2.0). Существенно переработано: исходник дублировал общий чек-лист SaaS-договора внутри
себя вместо явной передачи в существующий в этом форке `dogovornoe-pravo:review` (маршрутизирующий
к `vendor-agreement-review` и, для подписок, `saas-msa-review`) — здесь общий чек-лист прогоняется
там, а этот скилл добавляет только AI-специфичный слой поверх готового результата, без повтора.
Раздел про 152-ФЗ переписан под реальные обязанности оператора/поручителя (ст. 6 ч. 3 и ч. 5, ст.
18 ч. 5, ст. 18.1, ст. 21 ч. 3.1 152-ФЗ) вместо общей фразы источника «vendor accepts role as
processor». Убрана таблица «типичного поведения по вендорам» (OpenAI Enterprise / ChatGPT
consumer / Anthropic API) — она специфична для американского рынка и быстро устаревает; заменена
общим правилом проверки условий обучения на данных клиента, применимым к любому вендору.
-->

# Проверка договора с поставщиком ИИ (AI-специфичный слой)

## Контекст дела

Прочитай `~/.claude/plugins/config/claude-for-legal-ru/regulirovanie-ii/CLAUDE.md`. Файла нет или
в нём остались `[ЗАПОЛНИТЬ]` — стоп: «Плагину нужна настройка, запусти
`/regulirovanie-ii:cold-start-interview-rii`.»

Если включён режим `vedenie-del` и есть активное дело — результат пиши в папку дела.

## Порядок обязателен: сначала общий чек-лист, потом AI-слой

**Этот скилл не заменяет `/dogovornoe-pravo:review`.** Прогони договор через него первым —
заключённость, ответственность, заверения, форс-мажор, подсудность, для подписочной модели ещё и
`saas-msa-review` (квалификация договора, абонентская модель ст. 429.4 ГК, одностороннее изменение
условий ст. 310/424 ГК, SLA). Только после этого добавляй AI-специфичный разбор ниже — он смотрит
на то, чего общий чек-лист не видит.

## Pre-flight

- **Вендор:** [имя + тип: гипермасштабный зарубежный LLM API / российский LLM / open-source
  self-hosted / SDK-библиотека]
- **Санкционная экспозиция:** зарубежный вендор с ограниченным доступом из РФ? (см. реестр —
  `reestr-sistem-ii`)
- **Сценарий использования:** [для чего будет использоваться AI]
- **Чувствительность передаваемых данных:** [ПДн / коммерческая тайна / публичные]

## AI-специфичные пункты проверки договора

### A. Права на наши данные у вендора

**Обучение на наших данных.** Ключевой вопрос: может ли вендор использовать наш ввод/вывод для
обучения будущих моделей?
- **Хорошо:** прямой запрет — «вендор не использует данные клиента для обучения моделей».
- **Приемлемо:** есть опция отказа (opt-out), и она реализована.
- **Проблема:** обучение по умолчанию без возможности отказа.
- **Плохо:** обучение прямо разрешено, право безотзывно.

Условия по обучению сильно различаются даже у одного вендора между тарифами (enterprise/API vs
потребительский тариф) и меняются со временем — не полагайся на репутацию вендора, проверяй
конкретный пункт актуального договора.

**Срок хранения данных.** Как долго вендор хранит запросы/ответы? Рекомендуется короткий срок
(до 30 дней), минимум логов для отладки.

**Место обработки данных.** Где физически хранятся данные? Если среди них ПДн субъектов из РФ —
применяется требование локализации (ст. 18 ч. 5 152-ФЗ): первичный сбор и запись ПДн граждан РФ —
в базах данных на территории РФ. Трансграничная передача — отдельное основание и, для отдельных
случаев, уведомление РКН.

### B. Права на результат — кому принадлежит вывод модели

**Принадлежность сгенерированного контента.** Лучший вариант — прямая передача всех прав на
результат клиенту в договоре. Частая двусмысленность: результат формально «принадлежит» клиенту,
но использование всё равно ограничено условиями сервиса.

**Ограничения на использование результата.** Можно ли использовать коммерчески? Можно ли
перераспространять? Может ли вендор использовать результат для обучения других моделей? Требуется
ли указание авторства?

### C. Гарантии модели (или их отсутствие)

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

### D. Ответственность за ошибки модели

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

### E. Лимиты запросов и стабильность API

Что происходит при превышении лимита (мягкое/жёсткое ограничение)? Политика версионирования — есть
ли обратная совместимость при обновлениях? Достаточен ли срок уведомления о прекращении поддержки
версии для миграции? SLA по доступности — реалистичен ли, есть ли компенсация за простой.

### F. Модель ценообразования

Токенная (типична для LLM, менее предсказуема при росте использования), за вызов API (более
предсказуема), подписка (фиксированная плата с ограничением объёма), смешанная. Договариваться о
потолке месячных расходов/запросов, если модель токенная.

### G. Безопасность и конфиденциальность

Запрет на обучение — см. пункт A. Доступ персонала вендора к данным клиента — ограничен ли?
Шифрование при передаче и хранении. Право на аудит практик безопасности вендора. Скорость
уведомления об инциденте.

### H. Соответствие 152-ФЗ, если передаются ПДн

Если организация будет направлять ПДн вендору:
- Вендор принимает на себя обязанности **обработчика по поручению** (ч. 3 ст. 6, ч. 3.1 ст. 21
  152-ФЗ) — договор должен содержать перечень действий с ПДн, цели обработки и обязанность
  обработчика соблюдать конфиденциальность и меры защиты (ч. 3 ст. 6).
- Локализация (ст. 18 ч. 5) обеспечена — обработка ПДн граждан РФ вендором происходит в РФ, либо
  для трансграничной передачи есть основание (ч. 1–2 ст. 12) и, если применимо, уведомление РКН.
- Согласие субъекта ПДн на обработку вендором — получено, если это отдельная требуемая мера, а не
  покрыто общим согласием на обработку.

### I. Выход и переносимость

Какие события дают право прекратить договор? Срок уведомления? Может ли организация выгрузить все
свои данные при выходе, в машиночитаемом формате? Принадлежность и переносимость дообученных
(fine-tuned) моделей, если применимо? Содействие вендора в переходе к другому решению?

### J. Санкционная специфика

**Если вендор — из недружественной юрисдикции:** ограничения доступа технически возможны
(геоблокировка), платёжные ограничения (банк может заблокировать транзакцию), односторонне
прекращение вендором из-за санкционного давления, отсутствие гарантии непрерывности доступа. Для
материально значимой зависимости — риск высок: нужен резервный вендор (российский) либо
self-hosted альтернатива.

**Если вендор — российский:** санкционных рисков доступа обычно нет; качество/возможности модели
нужно оценивать отдельно для задачи; риск vendor lock-in ниже.

**Self-hosted open-source:** операционные расходы выше, контроль качества полностью на организации
(и в плюс, и в минус), доступность обычно устойчивее к санкционному давлению.

### K. Заверения вендора об AI-специфичном комплаенсе

Вендор заверяет: соответствие применимому праву (152-ФЗ, если обрабатывает ПДн); надлежащее
лицензирование обучающих данных (для генеративных моделей — риск нарушения авторских прав
переносится на клиента, если вендор недобросовестен, — см. `proverka-obuchayushchih-dannyh`, если
организация сама дообучает модель на данных вендора); отсутствие недокументированных функций
сбора/передачи данных.

## Workflow

### Шаг 1. Определи вендора и объём

```markdown
## Вендор
- **Название:** [...]
- **Тип:** [LLM API / ML SaaS / SDK-библиотека / иное]
- **Страна:** [...]
- **Санкционная экспозиция:** [да/нет]
- **Сценарий использования:** [...]
- **Ожидаемый объём:** [запросы/данные]
- **Чувствительность данных:** [ПДн / конфиденциальные / публичные]
```

### Шаг 2. Пройди пункты A–K

Для каждого — сверь формулировку договора, отметь риск.

### Шаг 3. Сводка рисков

```markdown
## Находки

### 🔴 Критично
1. [обучение на данных клиента по умолчанию без opt-out]
2. [санкционная экспозиция без резервного плана]

### 🟡 Средне
1. [лимиты запросов не прозрачны]
2. [потолок ответственности вендора занижен]

### 🟢 Приемлемо
[список]
```

### Шаг 4. Рекомендуемые правки

```markdown
## Рекомендуемые изменения договора

### Обязательные (не подписывать без них)
- [ ] «Вендор не использует данные клиента для обучения моделей» — добавить
- [ ] Права на результат генерации закреплены за клиентом — добавить
- [ ] Резервный вариант или право прекращения при существенном изменении API

### Желательные
- [ ] Сократить срок хранения данных до 30 дней
- [ ] Повысить потолок ответственности
- [ ] Расширить право на аудит

### Опционально
- [ ] Обсудить объёмную скидку
- [ ] SLA на новые версии модели
```

### Шаг 5. Вывод

```markdown
# Проверка AI-вендора — [вендор + продукт]

## Итог
- **Подписывать / не подписывать / подписывать с правками:** [...]
- **Критичных находок:** [N]

## Разбор находок
[из Шага 3]

## Обязательные правки
[из Шага 4]

## Альтернативные вендоры
- [российская альтернатива]: плюсы/минусы
- [open-source альтернатива]: плюсы/минусы

## Рекомендация
[использовать этого вендора / альтернативу / гибрид]
```

## Чего не делает

- Не ведёт переговоры с вендором — это бизнес-сторона + outside-адвокат для материальных сделок.
- Не проводит аудит безопасности вендора — это служба информационной безопасности.
- Не заменяет `/dogovornoe-pravo:review` — прогоняется после него, не вместо.

---

Проверки перед выдачей:
- [ ] Общий чек-лист `dogovornoe-pravo:review` пройден до этого AI-слоя, а не пропущен
- [ ] Условие про обучение на данных клиента найдено и процитировано дословно, а не предположено
- [ ] Если передаются ПДн — статус вендора как обработчика по поручению и локализация проверены
      явно