Чек-лист договора на внедрение ИИ: 46 пунктов перед подписанием

Договор на внедрение ИИ стоит проверить по девяти блокам: предмет и измеримый результат, приёмка на эталонном наборе, данные и персональные данные, права на код, датасеты и модели, сторонние модели и их лицензии, расходы на эксплуатацию, безопасность, поддержка и выход из проекта. Главное отличие от обычного ИТ-договора — результат вероятностный: «бот отвечает правильно» без набора тестовых вопросов и порога качества принять невозможно. Ниже — 46 пунктов с ответственными и критериями «готово», которые можно скопировать в рабочий документ.

Материал подготовлен AIrassvet 19 октября 2026 года для руководителей, ИТ-директоров, юристов и специалистов по закупкам на стороне заказчика. Чек-лист опирается на нормы Гражданского кодекса РФ (ст. 720, 1235, 1296), 152-ФЗ «О персональных данных» (ст. 6, 12, 18), лицензии открытых моделей и документацию OpenAI о выводе моделей из эксплуатации. Структура и формулировки пунктов — методика редакции, а не результат исследования. Это не юридическая консультация: итоговую редакцию договора согласуйте с юристом, знакомым с вашей отраслью.

Содержание

Кратко
Для кого чек-лист и что в него не входит
Чем договор на ИИ отличается от обычного ИТ-договора
Какой у вас тип договора
Что подготовить до старта
Чек-лист по этапам
Копируемый шаблон
Типовые ошибки
Как составлен чек-лист
Частые вопросы
Первоисточники

Кратко

Без эталонного набора нет приёмки. Статья 720 ГК РФ обязывает заказчика осмотреть и принять работу в порядке, предусмотренном договором, — для ИИ этот порядок нужно описать через тестовые запросы и пороги.
Права на результат по умолчанию у заказчика, но не на всё. По ст. 1296 ГК РФ программа, созданная по заказу, принадлежит заказчику, если договор не говорит иное; веса сторонней модели остаются под её лицензией.
Персональные данные требуют отдельного поручения. Часть 3 ст. 6 152-ФЗ перечисляет, что обязательно должно быть в поручении обработки.
Цена владения — это не только разработка. Токены, GPU, мониторинг и переобучение должны быть посчитаны до подписания.
Выход из проекта планируют в начале. Код, промпты, датасеты и инструкции по развёртыванию передаются по списку, а не «по запросу».

Для кого чек-лист и что в него не входит

Чек-лист рассчитан на заказчика, который заключает договор на разработку и внедрение ИИ-решения: ИИ-агента, RAG-системы, чат-бота, модели прогнозирования или компьютерного зрения. Он помогает не пропустить условия, специфичные для ИИ. Мы не разбираем общие условия любого договора подряда (неустойки, подсудность, порядок расчётов), отраслевое регулирование вроде медицины и финансов, а также требования к госзакупкам по 44-ФЗ и 223-ФЗ — для них нужна отдельная проверка.

Если вы ещё выбираете подрядчика, начните с материала «Как выбрать LLM-интегратора»: там разобраны критерии оценки команды. Этот чек-лист — следующий шаг, когда исполнитель выбран и на столе лежит проект договора.

Чем договор на ИИ отличается от обычного ИТ-договора

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

Качество как порог, а не как функция. Нужны эталонный набор запросов, метрика и минимальное значение, при котором результат считается принятым.
Данные заказчика как сырьё. Документы, переписка и записи разговоров становятся обучающими или поисковыми данными, и их обработка регулируется 152-ФЗ.
Чужие модели внутри решения. Подрядчик почти всегда использует модель третьей стороны — облачную по API или открытую с собственной лицензией.
Переменные расходы. Стоимость эксплуатации зависит от числа запросов и длины ответов, а провайдер может изменить цену или вывести модель из эксплуатации.

Какой у вас тип договора

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

Тип договора	Что покупаете	Самые важные блоки	Когда подходит
Заказная разработка	Код, интеграции, настройки под ваш процесс	Права на результат, приёмка, выход	Процесс уникален, решение должно остаться у компании
Подписка на готовую платформу (SaaS)	Доступ к сервису и поддержку	Данные, SLA, выход, изменение цены	Типовая задача, важна скорость запуска
Пилот с фиксированным объёмом	Проверку гипотезы на одном процессе	Приёмка, критерий успеха, судьба данных после пилота	Эффект неочевиден, нужен замер до масштабирования
Сопровождение и развитие	Поддержку, мониторинг, доработки	SLA, переобучение, смена модели	Решение уже работает в production

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

Что подготовить до старта

Прежде чем садиться за чек-лист, соберите четыре документа. Без них большинство пунктов будет нечем заполнить.

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

Чек-лист по этапам

У каждого блока указаны ответственные со стороны заказчика и критерий «готово» — условие, при котором блок можно считать закрытым.

1. Предмет и измеримый результат

Кто отвечает: владелец процесса и ИТ-директор. Готово, если: результат описан так, что независимый человек может проверить его по документу без участия подрядчика.

☐ Назван конкретный процесс и границы решения: какие запросы система обрабатывает, а какие передаёт человеку.
☐ Перечислены интеграции с системами компании и уровень доступа к каждой: чтение, запись, действие.
☐ Зафиксирован текущий уровень показателя (время обработки, доля ошибок, объём ручной работы), с которым будут сравнивать результат.
☐ Указано, что считается результатом этапа: прототип, пилот на части пользователей или промышленная эксплуатация.
☐ Описано, какие действия ИИ выполняет только после подтверждения человеком.

2. Приёмка и качество

Кто отвечает: владелец процесса и эксперты предметной области. Готово, если: в приложении к договору есть эталонный набор, метрика, порог и порядок повторной проверки.

☐ Эталонный набор реальных запросов с правильными ответами передаётся до начала работ и не используется для обучения.
☐ Для каждой задачи выбрана метрика: доля верных ответов, полнота извлечения полей, оценка эксперта по чек-листу.
☐ Указан порог приёмки и что происходит, если он не достигнут: доработка, повторное испытание, право отказаться от этапа.
☐ Описан порядок приёмки по ст. 720 ГК РФ: кто проверяет, в какой срок и как фиксируются выявленные недостатки в акте.
☐ Предусмотрена проверка на «запрещённых» сценариях: вопросы вне темы, попытки получить конфиденциальные данные, провокационные запросы.
☐ Зафиксировано, на какой версии модели проводилась приёмка, и что смена версии требует повторной проверки.

3. Данные и персональные данные

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

☐ Составлен перечень данных, которые получает подрядчик, с отметкой о персональных данных и коммерческой тайне.
☐ Если подрядчик обрабатывает персональные данные, в договор включено поручение по ч. 3 ст. 6 152-ФЗ: перечень данных, действий, целей, обязанность конфиденциальности и требования к защите.
☐ Определено, куда физически уходят данные при работе модели; при трансграничной передаче учтена обязанность уведомить Роскомнадзор до её начала (ч. 3 ст. 12 152-ФЗ).
☐ Учтён запрет вести базы с персональными данными граждан РФ за рубежом при их сборе (ч. 5 ст. 18 152-ФЗ) — это касается в том числе логов и векторных индексов.
☐ Запрещено использовать данные заказчика для обучения моделей подрядчика или третьих лиц без отдельного письменного согласия.
☐ Указаны сроки хранения и порядок удаления данных, логов и копий после завершения договора, с актом об удалении.

Подробнее о передаче данных зарубежным ИИ-сервисам — в статье «152-ФЗ и зарубежные ИИ».

4. Права на результат

Кто отвечает: юрист и ИТ-директор. Готово, если: для каждого артефакта проекта указано, кому принадлежит исключительное право или на каких условиях заказчик его использует.

☐ Перечислены артефакты: исходный код, промпты и системные инструкции, конфигурации агентов, датасеты, разметка, адаптеры дообучения, отчёты об испытаниях.
☐ Для заказной разработки прямо указано, что исключительные права переходят заказчику; по ст. 1296 ГК РФ это правило действует по умолчанию, но явная формулировка снимает споры.
☐ Отдельно перечислены компоненты, которые остаются у подрядчика (его библиотеки, платформа), и условия лицензии на них для заказчика.
☐ Если права остаются у подрядчика, оформлен лицензионный договор в письменной форме с территорией, сроком и способами использования (ст. 1235 ГК РФ).
☐ Зафиксировано, что датасеты, собранные из данных заказчика, принадлежат заказчику, даже если подрядчик их очищал и размечал.

5. Сторонние модели и сервисы

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

☐ Подрядчик раскрывает список моделей и внешних API, которые использует решение, с версиями и провайдерами.
☐ Для открытых моделей приложены лицензии и проверены ограничения: например, лицензия Llama 3.1 требует отдельного разрешения Meta для компаний с аудиторией более 700 млн активных пользователей в месяц.
☐ Описано, кто заключает договор с провайдером модели и на кого оформлен аккаунт: заказчик или подрядчик.
☐ Предусмотрено действие при выводе модели из эксплуатации: провайдеры отключают старые версии — у OpenAI даже дообученные модели работают только до вывода базовой.
☐ Решение спроектировано так, чтобы модель можно было заменить без переписывания всей системы, и это проверяется при приёмке.

6. Стоимость и расходы на эксплуатацию

Кто отвечает: финансовый директор и владелец процесса. Готово, если: посчитана полная стоимость владения на год при ожидаемой и пиковой нагрузке.

☐ Разделены разовые платежи (разработка, интеграция, обучение) и регулярные (токены, GPU, хостинг, поддержка).
☐ Указано, кто оплачивает токены и инфраструктуру и по каким тарифам; изменение тарифа провайдером модели не перекладывается на заказчика без уведомления.
☐ Заложены лимиты расходов и оповещение при их приближении.
☐ Описано, сколько стоят переобучение или донастройка при изменении процесса или данных.
☐ Расходы на мониторинг качества и разбор ошибок включены в смету, а не «по факту».

7. Безопасность и доступы

Кто отвечает: служба информационной безопасности. Готово, если: у ИИ-системы есть отдельные учётные записи, журнал действий и согласованные ограничения прав.

☐ ИИ-агент работает под отдельной учётной записью с минимально необходимыми правами, а не под учёткой сотрудника.
☐ Все действия системы во внешних системах журналируются, журнал доступен заказчику.
☐ Подрядчик описывает защиту от внедрения команд через документы и письма (prompt injection) и тестирует её при приёмке.
☐ Доступы подрядчика к системам заказчика перечислены и отзываются по завершении работ.
☐ Установлен срок, в который подрядчик сообщает об инциденте с данными заказчика.

8. Поддержка, SLA и изменения

Кто отвечает: ИТ-директор. Готово, если: понятно, кто и в какой срок реагирует на сбой и на падение качества ответов.

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

9. Выход из проекта

Кто отвечает: ИТ-директор и юрист. Готово, если: по списку передачи другой команда может развернуть и сопровождать решение без исходного подрядчика.

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

Подробнее о том, как подготовить резервный контур и переход, — в материале «План выхода из ИИ-сервиса».

Копируемый шаблон

Скопируйте список в рабочий документ или таблицу и отмечайте пункты по мере согласования с подрядчиком.

ЧЕК-ЛИСТ ДОГОВОРА НА ВНЕДРЕНИЕ ИИ
Проект: ______  Подрядчик: ______  Версия договора: ______  Дата: ______

1. ПРЕДМЕТ (владелец процесса, ИТ-директор)
☐ Процесс и границы решения
☐ Интеграции и уровень доступа
☐ Текущий уровень показателя
☐ Результат каждого этапа
☐ Действия только с подтверждением человека

2. ПРИЁМКА (владелец процесса, эксперты)
☐ Эталонный набор передан до работ и не используется для обучения
☐ Метрика для каждой задачи
☐ Порог приёмки и последствия недостижения
☐ Порядок приёмки и фиксации недостатков в акте
☐ Проверка запрещённых сценариев
☐ Версия модели при приёмке, повторная проверка при смене

3. ДАННЫЕ (ответственный за ПДн, юрист)
☐ Перечень передаваемых данных
☐ Поручение обработки ПДн по ч. 3 ст. 6 152-ФЗ
☐ География обработки, уведомление о трансграничной передаче
☐ Локализация баз с ПДн, включая логи и индексы
☐ Запрет обучения моделей на данных заказчика
☐ Сроки хранения и акт об удалении

4. ПРАВА (юрист, ИТ-директор)
☐ Перечень артефактов проекта
☐ Переход исключительных прав заказчику
☐ Компоненты подрядчика и лицензия на них
☐ Лицензионный договор, если права у подрядчика
☐ Датасеты из данных заказчика — у заказчика

5. СТОРОННИЕ МОДЕЛИ (ИТ-директор, ИБ)
☐ Список моделей и API с версиями
☐ Лицензии открытых моделей проверены
☐ На кого оформлены аккаунты провайдеров
☐ План на вывод модели из эксплуатации
☐ Замена модели без переписывания системы

6. РАСХОДЫ (финансовый директор, владелец процесса)
☐ Разовые и регулярные платежи разделены
☐ Кто платит за токены и инфраструктуру
☐ Лимиты расходов и оповещения
☐ Стоимость переобучения и донастройки
☐ Мониторинг качества в смете

7. БЕЗОПАСНОСТЬ (ИБ)
☐ Отдельная учётная запись с минимальными правами
☐ Журнал действий доступен заказчику
☐ Защита от prompt injection и её проверка
☐ Отзыв доступов подрядчика
☐ Срок уведомления об инциденте

8. ПОДДЕРЖКА (ИТ-директор)
☐ Время реакции: доступность и качество
☐ Контроль качества после обновлений
☐ Порядок изменений в production
☐ Пополнение эталонного набора

9. ВЫХОД (ИТ-директор, юрист)
☐ Список передачи артефактов
☐ Срок и формат передачи при расторжении
☐ Период совместной работы
☐ Аккаунты провайдеров на заказчике
☐ Репетиция развёртывания до финальной оплаты

Типовые ошибки

Приёмка «по демонстрации». Подрядчик показывает удачные ответы на своих примерах, акт подписан, а на реальных запросах качество ниже. Лечится эталонным набором заказчика, переданным до начала работ.
Обучение на эталонном наборе. Если тестовые вопросы попали в обучение или в промпт, приёмка покажет завышенный результат. Набор должен храниться у заказчика и выдаваться только для испытаний.
«Права на систему» без перечня. Код передали, а промпты, датасеты и адаптеры остались у подрядчика — без них решение нельзя воспроизвести.
Аккаунт провайдера модели на подрядчике. При расторжении договора решение перестаёт работать, а история запросов остаётся у чужой компании.
Расходы на токены «по факту». Без лимитов и прогноза рост нагрузки превращается в неожиданный счёт.
Нет плана на смену модели. Провайдер выводит версию из эксплуатации, а договор не говорит, кто и за чей счёт переносит решение и повторяет приёмку.

Как составлен чек-лист

Мы разложили договор на этапы жизненного цикла ИИ-решения — от постановки задачи до выхода — и для каждого этапа выписали условия, которые отличают ИИ-проект от обычной заказной разработки. Затем сверили пункты с нормами ГК РФ о приёмке, заказных произведениях и лицензионном договоре, с требованиями 152-ФЗ к поручению обработки, трансграничной передаче и локализации, а также с документацией провайдеров моделей. Пункты, которые одинаковы для любого договора подряда, мы сознательно исключили, чтобы список оставался рабочим.

Ограничения методики: чек-лист не учитывает отраслевые требования, не заменяет проверку конкретного договора юристом и не проверялся нами на собственной выборке договоров. Нормы приведены в редакциях, доступных 19 октября 2026 года.

Частые вопросы

Кому принадлежат права на ИИ-решение, созданное по договору?

По ст. 1296 ГК РФ исключительное право на программу или базу данных, созданную по заказу, принадлежит заказчику, если договор не предусматривает иное. Но решение обычно включает чужие модели и библиотеки подрядчика — на них права не переходят. Поэтому в договоре стоит перечислить артефакты поимённо: код, промпты, датасеты, адаптеры, отчёты.

Как принять ИИ-систему, если она иногда ошибается?

Через порог качества на эталонном наборе. Заранее соберите реальные запросы с правильными ответами, договоритесь о метрике и минимальном значении и проведите испытание на этом наборе. Ошибки ниже порога допустимы, если они описаны в договоре; выше порога — повод для доработки по порядку, установленному договором.

Нужно ли поручение обработки персональных данных, если подрядчик только настраивает модель?

Если подрядчик получает доступ к персональным данным — к примеру, к перепискам клиентов для настройки или проверки — это обработка по поручению, и ч. 3 ст. 6 152-ФЗ требует указать в поручении перечень данных, действий и целей. Безопаснее заранее обезличить данные. Решение принимайте вместе с ответственным за персональные данные.

Что делать, если подрядчик использует зарубежную модель?

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

Стоит ли фиксировать в договоре конкретную модель?

Лучше фиксировать требования и процедуру, а не только название модели. Модели обновляются и выводятся из эксплуатации, поэтому в договоре полезно указать модель на момент приёмки, правило повторной проверки при смене версии и обязанность подрядчика спроектировать решение с возможностью замены модели.

Первоисточники

Нормы и документы проверены 19 октября 2026 года:

Как AIrassvet помогает подготовить ИИ-проект к договору

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

аудит процесса и подготовка данных: что автоматизировать, какие данные нужны и где в них персональная информация;
разработка MVP, интеграция и тестирование — с эталонным набором и критерием приёмки, которые можно перенести в договор;
развёртывание LLM на серверах заказчика, если данные нельзя передавать во внешний сервис;
запуск, обучение команды и поддержка после ввода в эксплуатацию.

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

Обсудить задачу

Итог: договор как продолжение технического задания

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

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