Если подрядчик использует нейросети в работе с вашими данными — текстами, базами клиентов, договорами — в договор стоит внести четыре блока: какие данные разрешено передавать в модель, какие модели допустимы, кто отвечает за утечку и как проверяется соблюдение условий. Разбираем формулировки, которые реально проверяются на практике, без юридического жаргона.
Какие данные нельзя
Четыре обязательных блока в договоре про использование ии подрядчиком: перечень запрещённых к передаче данных, список разрешённых моделей, ответственность за утечку и право на аудит — без них спор после инцидента решается в вашу пользу заметно реже, по нашей практике консультаций.
Первый блок договора — точный список данных, которые подрядчик обязан держать вне любой модели без вашего отдельного согласия: персональные данные клиентов, коммерческую тайну, реквизиты счетов, тексты договоров с третьими лицами.
- Персональные данные сотрудников и клиентов — ФИО, телефоны, паспортные данные
- Коммерческая тайна — цены, условия сделок, внутренние регламенты
- Реквизиты счетов, платёжные данные и данные банковских карт
- Тексты договоров и переписка с третьими лицами без их согласия
Подбор самого подрядчика — отдельная задача, разобранная в статье про то, как выбрать ии-подрядчика. Здесь — конкретные формулировки договора уже с выбранным подрядчиком.
Формулировку перечня удобно делать закрытым списком вместо общей фразы вроде «конфиденциальная информация» — общая фраза чаще трактуется по-разному сторонами уже после инцидента. Конкретный список из четырёх-пяти категорий данных читается однозначно и подрядчиком, и заказчиком.
Требование про локализацию данных особенно важно при работе с персональными данными сотрудников или клиентов — здесь дополнительно действует 152-ФЗ, и договор с подрядчиком стоит явно увязать с этой нормой вместо общих формулировок о конфиденциальности.
В приложении удобно сразу указать контактное лицо, которое подрядчик уведомляет при любом отклонении от согласованного перечня, — так реакция на инцидент идёт сразу нужному адресату внутри компании, без промежуточного поиска контакта.
Какие модели допустимы
Второй блок — список моделей, которые подрядчик вправе использовать в работе с вашими данными. Для конфиденциальных задач разумно требовать российские модели с обработкой данных внутри РФ — GigaChat, YandexGPT — или локальные модели без выхода в интернет вообще, подробнее — в статье про локальный ИИ для конфиденциальных данных.
| Тип модели | Где хранятся данные | Когда указывать в договоре |
|---|---|---|
| Российское облако (GigaChat, YandexGPT) | Дата-центр в РФ | Работа с персональными данными по 152-ФЗ |
| Зарубежное облако (ChatGPT, Claude) | Дата-центр за пределами РФ | Только с обезличенными данными |
| Локальная модель на сервере подрядчика | Сервер, который вы можете проверить | Максимально чувствительные данные без исключений |
Формулировка в договоре может быть простой: «Подрядчик обязан использовать только модели из перечня, согласованного в приложении, и обязан уведомить заказчика перед добавлением новой модели в рабочий процесс».
Перечень моделей стоит пересматривать минимум раз в полгода — рынок моделей меняется быстро, и сервис, который считался безопасным год назад, может изменить условия хранения данных без явного уведомления клиентов. Обязанность подрядчика сообщать об изменении условий у выбранного сервиса стоит включить в тот же пункт договора.
Отдельно стоит указать, что происходит с данными после завершения проекта — подрядчик обязан удалить историю обращений к модели, связанную с вашими данными, в согласованный срок после закрытия договора.
Если подрядчик привлекает субподрядчика для части задач, каждый субподрядчик должен подписаться под тем же перечнем допустимых моделей — иначе цепочка передачи данных остаётся непрозрачной для заказчика.
Ответственность за утечку
Третий блок — кто отвечает, если данные всё же оказались в чужом сервисе по ошибке подрядчика.
Без явного пункта об ответственности спор решается по общим нормам о причинении убытков, а доказать размер ущерба от утечки в модель третьей стороны непросто. Прямая формулировка в договоре — фиксированная неустойка за нарушение перечня разрешённых моделей плюс обязанность подрядчика уведомить заказчика в короткий срок после обнаружения инцидента.
Формулировка про уведомление работает только с конкретным сроком — «в течение суток с момента обнаружения» звучит однозначнее, чем расплывчатое «незамедлительно», которое каждая сторона трактует по-своему в суде.
Полезно заранее прописать порядок совместных действий при инциденте — кто уведомляет регулятора, если утечка затрагивает персональные данные, и в какой срок стороны согласовывают публичное заявление, если оно потребуется.
Какие данные ваш подрядчик уже передаёт в нейросети?
Право на аудит
Четвёртый блок — право заказчика проверить, как модели используются на практике, помимо устных заверений подрядчика в отчёте.
- Периодический запрос списка используемых моделей и сервисов
- Право затребовать лог обращений к модели по конкретному проекту
- Право провести внешний аудит при подозрении на нарушение условий
- Обязанность подрядчика хранить историю согласований новых моделей
Пункт про аудит редко используется на практике целиком, но его наличие в договоре меняет поведение подрядчика ещё на этапе подбора инструмента — знание о возможной проверке дисциплинирует само по себе.
Право на аудит стоит закрепить как периодическую процедуру с фиксированной частотой — раз в квартал или перед продлением договора на новый срок — вместо права «на всякий случай» без реального графика проверок.
Отчёт по итогам аудита стоит оформлять письменно и хранить у обеих сторон — это упрощает разговор при повторной проверке и снимает вопрос о том, что именно проверялось в прошлый раз.
Полезно заранее договориться о формате лога обращений к модели — таблица с датой, типом запроса и категорией данных читается быстрее, чем полный текстовый экспорт переписки с моделью.
Как внести пункты
Все четыре блока можно оформить отдельным приложением к основному договору вместо переписывания всего документа — так же проще обновлять перечень моделей по мере появления новых сервисов на рынке. Дата подписания приложения фиксируется отдельно от даты основного договора — это упрощает отслеживание версии условий, если приложение потом обновляется.
Возьмите шаблон из четырёх блоков выше, впишите конкретные данные и модели вашего проекта и предложите подрядчику подписать приложение к уже действующему договору.
Если подрядчик отказывается подписывать такое приложение, это само по себе полезный сигнал о том, как компания относится к работе с чужими данными — стоит обсудить причину отказа отдельно, до начала проекта.
Хранить подписанные приложения удобнее вместе с основным договором в одной папке — юрист или новый сотрудник компании быстро видит полную картину условий работы с конкретным подрядчиком.
Если своего юриста для такой правки нет или нужен независимый взгляд на риски конкретного подрядчика — разбор рисков и формулировок для конкретного случая в разделе про ИИ-консалтинг.