Разговор про соглашение о неразглашении и ИИ обычно начинается после инцидента: кто-то попросил модель переписать раздел договора, скриншот запроса попал в чат команды, и выяснилось, что документ был под режимом конфиденциальности. Дальше следует спор о том, считается ли отправка текста в модель раскрытием, — и спор этот решается не здравым смыслом, а формулировками конкретного договора.
Ниже — разбор того, как типовое соглашение смотрит на эту ситуацию, и пять способов нарушить его, не заметив. Правовая часть здесь — ориентир: квалификация конкретного эпизода требует проверки у юриста, потому что зависит от текста вашего договора.
#Короткий ответ
Большинство соглашений о неразглашении запрещают передачу конфиденциальной информации третьим лицам без согласия раскрывающей стороны и определяют узкий круг допустимых получателей — обычно сотрудники и консультанты, связанные аналогичным обязательством, и только в объёме, необходимом для цели.
Облачный провайдер языковой модели в этот круг по умолчанию не входит. Он не сотрудник, не подписывал ваше соглашение и получает текст на свои серверы. То, что читает его машина, а не человек, договор обычно не оговаривает вовсе: он оперирует передачей информации, а не тем, чьи глаза её видят.
Отдельный слой — режим коммерческой тайны. Если у обладателя информации введён такой режим по Федеральному закону «О коммерческой тайне», обязанности по его соблюдению существуют независимо от того, подписывали ли вы отдельный NDA, и меры по охране конфиденциальности определяет обладатель, а не пользователь.
#Как договор смотрит на «отправил в нейросеть»
Три конструкции, которые есть почти в любом соглашении и которые вместе закрывают этот вопрос.
Определение раскрытия. Обычно оно широкое: передача, предоставление доступа, публикация, копирование за пределы согласованного контура. Отправка текста на чужой сервер попадает под «предоставление доступа» без всяких натяжек.
Перечень допустимых получателей. Как правило: работники, привлечённые консультанты, аудиторы — и всегда с условием «связанные обязательством о конфиденциальности не менее строгим». Провайдер модели этому условию не соответствует, если с ним не заключён отдельный договор.
Обязанность принимать меры по защите. Часто формулируется как «не менее чем те, которые сторона применяет к собственной конфиденциальной информации». Загрузка документа в сервис, чьи условия вы не читали, этой обязанности не соответствует независимо от последствий.
Вывод, который отсюда следует: инцидент возникает в момент отправки, а не в момент, когда что-то утекло. Отсутствие вредных последствий — аргумент про размер ответственности, а не про наличие нарушения.
#Пять нарушений, которые совершают не задумываясь
Первое: вставить фрагмент договора «на редактуру». Классика. Человек не пересылает документ, он просто просит переформулировать абзац — и этот абзац уезжает провайдеру целиком, вместе с названиями сторон, суммой и сроками.
Второе: скинуть скриншот вместо текста. Ощущение, что изображение «не текст», ложное: файл уходит провайдеру полностью, а модель распознаёт с него всё, включая то, что попало в кадр случайно — соседние окна, имя файла в заголовке, уведомление в углу экрана.
Третье: попросить объяснить код из рабочего репозитория. Исходный код почти всегда прямо назван в перечне конфиденциальной информации. Плюс в конфигурациях регулярно лежат внутренние домены, имена серверов и ключи — они уезжают вместе с кодом.
Четвёртое: забыть про память ассистента. Самый незаметный случай. Вы обезличили сегодняшний вопрос, а ассистент подмешал в контекст фрагмент разговора двухмесячной давности, где название клиента стояло в исходном виде. Механика подмешивания разобрана в статье про состав запроса к языковой модели.
Пятое: включить непрерывный захват экрана на рабочей машине. Здесь нарушение не в отправке, а в накоплении: подробный лог всего, что вы видели, включая чужие документы, оседает в базе. Если контур предписывает хранить конфиденциальное только в согласованных системах, локальный архив в этот перечень не входит.
#Чек-лист допустимого использования при действующем NDA
Порядок такой: сначала три вопроса, потом три технических правила. Вопросы решают, можно ли вообще, правила — как именно.
- Что говорит ваш договор про допустимых получателей? Найдите этот абзац и прочитайте его буквально. Если там есть исключение для «поставщиков услуг, связанных обязательством конфиденциальности», следующий вопрос — заключён ли такой договор с провайдером.
- Введён ли у обладателя информации режим коммерческой тайны? Если да, у него есть свой перечень мер, и он обязателен независимо от вашего мнения о безопасности сервиса.
- Есть ли письменное согласование? Один абзац в переписке с ответственным лицом стоит дороже любой аргументации задним числом. Если использование согласовано — зафиксируйте объём: какие материалы, в каком сервисе, в каком режиме.
- Не отправляйте исходные документы — отправляйте задачу. «Проверь формулировку про ответственность в договоре поставки» с обобщённым текстом решает ту же задачу, что и загрузка файла.
- Обезличивайте до отправки, а не после. Устойчивые метки вместо названий сторон, номеров и сумм; процедура — в гайде про персональные данные в промпте.
- Для всего, что нельзя обезличить, используйте локальную модель. Это единственная конфигурация, где получателя нет: текст обрабатывается на вашей машине и наружу не идёт. Сборка связки — в гайде по подключению Ollama к Persona.
Проверка результата простая: сможете ли вы, если через год спросят, показать, что именно уходило наружу и на каком основании. Если ответ «не помню» — использование за пределами допустимого.
#Где интуиция подводит
«Модель не человек, значит раскрытия нет». Договор оперирует передачей информации третьему лицу. Третье лицо здесь — компания-провайдер, а не модель. Машина обрабатывает, компания получает.
«Я отключил историю, значит не сохранилось». Отключённая история влияет на интерфейс. Хранение на стороне провайдера регулируется его условиями, и удержание на срок разбора злоупотреблений — обычная практика. Что спрашивать у документов — в разборе политик провайдеров по обучению на данных.
«У компании корпоративная подписка, значит всё согласовано». Корпоративный тариф решает вопрос с провайдером, но не с вашим контрагентом. Если информация принадлежит клиенту, а не работодателю, согласие должен дать клиент.
«Ничего не утекло, значит проблемы нет». Нарушение договора и наступление ущерба — разные события. Первое произошло в момент передачи.
«Это была мелочь, один абзац». Соглашения обычно не содержат порога существенности для факта раскрытия. Объём влияет на оценку последствий, не на квалификацию.
#Что здесь честно про нас
Persona не проксирует запросы: текст уходит напрямую тому провайдеру, чей ключ вы вставили, и никому больше. Для разговора с безопасником это существенно — список получателей ровно один и известен заранее.
Дальше неудобное, и его лучше знать до внедрения в рабочем контуре.
Ключи API и токены Telegram-ботов участников хранятся в базе экземпляра в открытом виде. Кто держит файл базы, тот видит ключ. Для рабочего ключа это неприемлемо; заводите отдельный, с лимитом.
Администратор экземпляра имеет полный доступ к базе, включая переписку участников. Если экземпляр держит не ваша компания, конфиденциальная информация в нём находится под контролем постороннего лица — и это, скорее всего, самостоятельное нарушение контура.
Захват экрана и звука доступен только владельцу экземпляра, участникам он не выдаётся вовсе. Для NDA-контура это скорее плюс: подробный лог экрана участника не ведётся.
Проверить эти утверждения чтением кода нельзя — репозиторий закрыт, публичной лицензии нет. Доступны только внешние проверки.
#Частые вопросы
#Считается ли использование ИИ нарушением, если в договоре про него ничего не сказано?
Большинство соглашений писались до появления облачных моделей и прямо о них не говорят — но запрет передачи третьим лицам сформулирован общо и распространяется на любого получателя. Отсутствие упоминания ИИ не создаёт разрешения. Квалификация конкретного случая требует проверки у юриста.
#Спасает ли корпоративный тариф провайдера с соглашением об обработке данных?
Он закрывает отношения между вами и провайдером и часто требуется безопасником. Но если конфиденциальная информация принадлежит вашему клиенту, вопрос согласия остаётся к клиенту, а не к провайдеру. Две проблемы решаются разными документами.
#Можно ли отправлять обезличенный фрагмент документа?
Часто — да, если после замены текст перестаёт определять стороны и предмет. Но обезличивание с сохранённым ключом соответствия не выводит информацию из-под режима конфиденциальности так же, как не выводит персональные данные из-под закона. Проверяйте формулировку договора: часть соглашений защищает и производную информацию.
#Что делать, если конфиденциальный текст уже отправлен?
Прекратить отправку, зафиксировать что и когда ушло, найти в документах провайдера процедуру удаления истории и направить запрос, сообщить ответственному лицу внутри компании. Скрытый инцидент обходится дороже раскрытого — и с точки зрения договора, и с точки зрения отношений.
#Локальная модель полностью снимает вопрос?
Она снимает вопрос передачи третьему лицу: при развёртывании ассистента и модели на одной машине текст запроса наружу не идёт, и это проверяется отключением сети. Остаются вопросы хранения — где лежит база, зашифрован ли диск, кто имеет к нему доступ. Про то, как проходит эта граница, — в статье про приватный ИИ и локальное хранение.
#Почему компании просто запрещают такие сервисы целиком?
Потому что точечное разрешение требует разбора каждого случая, а запрет — одного письма. Обратная сторона известна: запрет не убирает использование, он делает его невидимым. Разбор мотивов и легальных обходов — в статье про корпоративные запреты на ChatGPT.
#Вывод
Если вы работаете под действующим соглашением о неразглашении, исходите из простого правила: отправка текста облачному провайдеру — это передача третьему лицу, пока в договоре не написано обратного. Дальше два пути. Согласовать письменно и зафиксировать объём — тогда облако допустимо. Или держать всё, что нельзя обезличить, на локальной модели, где получателя нет вовсе, — тогда согласовывать нечего.