Главная проблема корпоративного использования нейросетей — не в том, что сотрудники ими пользуются. Проблема в том, что вместе с запросом в ИИ-сервис может уйти информация, которую компания не собиралась передавать за пределы своего контура.
Для сотрудника такая передача часто выглядит совершенно безобидно: он решает рабочую задачу привычным способом и не всегда задумывается, что текст, файл или фрагмент кода отправляется стороннему сервису. В результате граница между рабочим инструментом и неконтролируемым каналом утечки оказывается очень тонкой.
Масштаб проблемы уже заметен на практике. По данным исследований, в первом полугодии 2026 года 38% обращений сотрудников к публичным ИИ-сервисам содержали конфиденциальную информацию. В исследовании проанализировали 12 тысяч взаимодействий в 150 крупных компаниях в рамках пилотов DLP-системы.
Поэтому вопрос для бизнеса сегодня звучит гораздо конкретнее: какие данные можно отправлять во внешний ИИ-сервис, а какие должны оставаться внутри корпоративного контура.
Разберём шесть основных категорий таких сведений, возможные правовые последствия и практические меры защиты. В конце — таблица и чек-лист, которые можно использовать как основу для внутреннего регламента.
Масштаб: сколько данных уходит и кто это делает
Среди конфиденциальных обращений чаще всего встречаются технические данные:
- 41% — исходный код и конфигурационные файлы;
- 30% — персональные и финансовые данные;
- 18% — интеллектуальная собственность;
- 11% — пароли, токены и API-ключи.
По подразделениям картина неравномерная. На команды разработки приходится 43% таких обращений, на коммерческий блок — 26%.
Компании видят проблему, но не закрывают её
Совместное исследование УЦСБ и ГК «Солар» на выборке из 102 организаций даёт другой срез. Больше половины компаний подозревают или фиксируют утечки через ИИ-инструменты: 42,4% говорят о подозрениях, 8,1% — о подтверждённых инцидентах. Главной нехваткой 63,6% респондентов называют обучение сотрудников и внутренние политики.
Это и есть теневой ИИ (shadow AI) — использование внешних моделей вне контура, который компания не контролирует. Запрет сам по себе его не убирает. Пока рабочую задачу быстрее решить через внешний сервис, сотрудник будет искать способ получить к нему доступ — в том числе с личного аккаунта.
Что происходит с данными после отправки в нейросеть
После отправки запроса информация передаётся сервису, а дальнейшая обработка зависит от его архитектуры, тарифа, настроек хранения и условий использования.
Логи, обучение модели и условия тарифа
Условия хранения, использования запросов для улучшения моделей и сроков удаления различаются в зависимости от конкретного сервиса и тарифа. Поэтому перед передачей рабочей информации необходимо проверять не только название модели, но и правила обработки данных для используемого аккаунта.
Корпоративные тарифы тех же сервисов могут предусматривать иные условия обработки: например, ограничения на использование данных клиента для обучения моделей, дополнительные настройки хранения и договорные обязательства поставщика. Но сам факт наличия корпоративного тарифа не отменяет требований законодательства и внутренних правил компании.
Удаление чата не означает автоматическое удаление всех данных
В июне 2025 года OpenAI публично сообщила, что по судебному предписанию обязана хранить данные потребительских продуктов бессрочно. Предписание распространялось на ChatGPT Free, Plus, Pro, Team и API без соглашения Zero Data Retention. Тарифы Enterprise и Edu оно не затронуло. Обязанность прекратила действовать 26 сентября 2025 года.
Вывод для регламента простой: удаление чата из интерфейса само по себе не означает, что все связанные данные немедленно удалены со стороны сервиса.
Ошибки самих сервисов
Публичные ИИ-сервисы — обычное облачное ПО, и в них случаются инциденты.
- Март 2023, OpenAI. Из-за бага в клиентской библиотеке redis-py часть пользователей видела заголовки чатов и первое сообщение нового диалога чужого пользователя. OpenAI указывала, что затронутыми могли оказаться 1,2% подписчиков ChatGPT Plus, активных в конкретном девятичасовом окне.
- Январь 2025, DeepSeek. Исследователи Wiz обнаружили открытую базу данных ClickHouse без аутентификации: больше миллиона записей логов с историей чатов и API-ключами.
- Июль 2025, ChatGPT. В индекс Google попали около 4500 диалогов, которые пользователи сделали доступными для поиска через функцию шеринга. Функция была добровольной, но её название вводило в заблуждение, и OpenAI её убрала.
Шесть категорий данных, которые нельзя отправлять в публичный чат
Дальше — разбор по категориям. В каждой врезке указаны нормы, на которые опирается запрет, чтобы юрист компании мог проверить формулировку и перенести её в регламент.
Персональные данные
Фамилии, телефоны, паспортные данные, адреса, даты рождения, сведения о здоровье и семейном положении. Это относится и к сотрудникам, и к клиентам, и к кандидатам.
Загрузка такого документа во внешний ИИ-инструмент фактически означает передачу сведений третьей стороне. Если сервис зарубежный, к этому могут добавляться требования к трансграничной передаче.
Что говорит закон. Персональные данные — «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу» (ст. 3 п. 1 152-ФЗ). Операторы обязаны «не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта» (ст. 7 152-ФЗ). Обработка требует одного из оснований, предусмотренных ст. 6 закона.
Для зарубежных сервисов действует ст. 12 152-ФЗ, регулирующая трансграничную передачу персональных данных. В зависимости от страны назначения и обстоятельств передачи могут потребоваться уведомление Роскомнадзора и соблюдение дополнительных требований закона.
За неправомерную передачу персональных данных юридическому лицу могут грозить штрафы, размер которых зависит от состава нарушения и количества субъектов или идентификаторов. В частности, ч. 12–14 ст. 13.11 КоАП РФ предусматривают для юридических лиц санкции от 3 до 15 млн рублей в зависимости от масштаба нарушения.
Коммерческая тайна и внутренние стратегии
Финансовые прогнозы, планы выхода на рынки, условия ценообразования, результаты внутренних исследований, нераскрытые продуктовые планы.
Соблазн здесь самый высокий. Модель хорошо причёсывает черновик стратегии и находит слабые места в бизнес-плане. Именно в таких задачах сотрудник отправляет документ целиком, а не выдержку из него.
Отдельный юридический эффект касается не только сотрудника, но и самой компании. Правовая охрана коммерческой тайны зависит от того, установлен ли в организации соответствующий режим и соблюдаются ли предусмотренные законом меры защиты. Если организация допускает передачу таких документов во внешние сервисы и не контролирует её, защищать эту информацию в споре становится сложнее.
Что говорит закон. Разглашением считается действие, в результате которого информация становится известной третьим лицам «в любой возможной форме… в том числе с использованием технических средств» (ст. 3 п. 9 98-ФЗ). Правомерно передать сведения вне компании можно только по договору с условием «о принятии контрагентом установленных договором мер по охране её конфиденциальности» (ст. 3 п. 6).
Меры защиты признаются разумно достаточными, если «исключается доступ к информации, составляющей коммерческую тайну, любых лиц без согласия её обладателя» (ст. 10 ч. 5 п. 1 98-ФЗ).
Для ноу-хау норма жёстче. Секрет производства охраняется, пока обладатель «принимает разумные меры для соблюдения конфиденциальности» (ст. 1465 ГК РФ). С момента утраты конфиденциальности исключительное право «прекращается у всех правообладателей» (ст. 1467 ГК РФ).
Финансовая информация
Здесь три разных режима, и в регламенте их лучше не смешивать.
- Зарплатные ведомости и данные о доходах работников — это персональные данные. Режим тот же, что в предыдущем разделе про 152-ФЗ.
- Выписки и данные о счетах клиентов банка — банковская тайна. Норма связывает саму кредитную организацию и её служащих.
- Данные из налоговой отчётности, полученные от налогового органа — налоговая тайна с отдельным режимом хранения и доступа.
Собственная финансовая отчётность компании банковской или налоговой тайной не является. Её может защищать режим коммерческой тайны, если компания его установила.
Что говорит закон. «Кредитная организация… гарантирует тайну об операциях, о счетах и вкладах своих клиентов и корреспондентов. Все служащие кредитной организации обязаны хранить тайну…» (ст. 26 ФЗ № 395-1). Налоговую тайну составляют полученные налоговым органом сведения о налогоплательщике, кроме предусмотренного законом перечня исключений; её утрата или разглашение влечёт ответственность (ст. 102 НК РФ).
Поэтому правила работы с финансовой информацией зависят не только от содержания документа, но и от того, откуда эти сведения получены и какой режим конфиденциальности на них распространяется.
Исходный код и технические секреты
Фрагменты проприетарного кода, ключи API, пароли и токены, конфигурационные файлы, схемы внутренней инфраструктуры. По данным «Солара», это самая частая категория утечек — 41% конфиденциальных обращений к ИИ-сервисам.
Причина не всегда в халатности разработчиков, а в скорости. Отправить функцию в чат быстрее, чем собрать минимальный воспроизводимый пример без секретов.
Опасность создаёт содержимое кода. Вместе с логикой могут уйти ключи в переменных, строки подключения к базе и внутренние адреса серверов. Вычистить их вручную из большого фрагмента получается не всегда.
Скомпрометированный ключ может дать доступ не только к чтению данных, но и к активным операциям: от использования ресурсов привязанного облачного аккаунта до доступа к продуктивной инфраструктуре.
Что говорит закон. Отдельной нормы про исходный код нет. Код и техническая документация могут защищаться как секрет производства (ст. 1465 ГК РФ) или как коммерческая тайна, если компания установила соответствующий режим по ст. 10 98-ФЗ. Утечка ключей и паролей сама по себе является техническим инцидентом. Правовые последствия зависят от характера информации, установленного режима защиты и последствий инцидента.
Договоры и юридические документы
Договоры с контрагентами, соглашения о неразглашении, судебные материалы, переписка с юристами.
Такие документы почти всегда содержат прямое обязательство не раскрывать условия третьим лицам. Загрузка договора в публичный чат может нарушать обязательство, которое компания взяла на себя перед контрагентом. Ответственность здесь может наступать не по закону о персональных данных, а по самому договору — вплоть до неустойки, если она предусмотрена.
Анонимизация в этой категории часто не решает проблему. Названия сторон и суммы убрать можно, но точные формулировки, даты и цифры — именно то, ради чего юрист обращается к модели.
Что говорит закон. Условия договора могут составлять коммерческую тайну сторон, и тогда передача их третьему лицу подпадает под определение разглашения (ст. 3 п. 9 98-ФЗ). Правомерная передача возможна при соблюдении условий о конфиденциальности. За нарушение NDA компания отвечает в объёме, который зафиксирован в самом соглашении.
Клиентские данные
Выгрузки из CRM, списки контактов, история обращений в поддержку, переписка с клиентами.
Категория пересекается с персональными данными, но требует отдельной строки в регламенте. Клиентские базы могут защищаться и законом, и договорными обязательствами перед клиентами.
Типичный сценарий — сотрудник поддержки вставляет переписку в чат, чтобы быстрее сформулировать ответ. Вместе с текстом жалобы во внешний сервис могут уйти имя, контакты и обстоятельства обращения.
Что говорит закон. Поручить обработку персональных данных другому лицу можно «с согласия субъекта персональных данных… на основании заключаемого с этим лицом договора» (ст. 6 ч. 3 152-ФЗ). В поручении фиксируются перечень данных, перечень операций, цели обработки и обязанность соблюдать конфиденциальность. Передача клиентских данных в публичный чат без соответствующего правового основания и договорных условий может не соответствовать требованиям закона.
При сборе персональных данных граждан РФ необходимо соблюдать требования ст. 18 ч. 5 152-ФЗ к использованию баз данных, находящихся на территории России. Если информация передаётся за рубеж, дополнительно применяются требования о трансграничной передаче.
Таблица для регламента: категория, риск и допустимая замена
| Категория данных | Риск для компании | Что делать вместо публичного чата |
|---|---|---|
| Персональные данные сотрудников, клиентов, кандидатов | Раскрытие третьему лицу без основания; дополнительные требования при трансграничной передаче; штрафы в предусмотренных законом случаях | Корпоративный шлюз с маскированием полей; для типовых задач — обезличенный шаблон без реальных данных |
| Коммерческая тайна, стратегии, ценообразование | Разглашение; ослабление режима охраны и сложности в споре | Модель в изолированном контуре или на инфраструктуре компании; согласование через ИБ |
| Финансовая информация: ведомости, выписки, отчётность | Режим ПДн для ведомостей, банковская тайна, налоговая тайна — в зависимости от источника сведений | Расчёты в учётной системе; в модель — только агрегаты без привязки к людям и счетам |
| Исходный код, ключи, конфигурации | Утрата охраны ноу-хау; компрометация доступа к продуктивной инфраструктуре | Минимальный пример без секретов; ротация ключей при инциденте; корпоративный ИИ-ассистент для разработки |
| Договоры, NDA, судебные материалы | Нарушение обязательства о конфиденциальности перед контрагентом, вплоть до неустойки по договору | Юридический анализ в контролируемом контуре; согласование с юридической службой |
| Клиентские базы и переписка | Обработка без соответствующего основания или поручения; претензии клиентов по договору | Корпоративный канал с логированием; шаблоны ответов вместо реальной переписки |
Таблица работает как отдельный слой документа. Первую колонку удобно переносить в перечень сведений ограниченного доступа, третью — в инструкцию для сотрудников.
Чек-лист для сотрудника: три вопроса перед отправкой
Этот блок можно выдать сотрудникам как есть.
- Показал бы я этот документ человеку не из компании? Если нет, публичной нейросети его отправлять нельзя.
- Есть ли в документе данные конкретных людей — имена, контакты, суммы выплат, сведения о здоровье? Если да, нужен согласованный корпоративный канал или замена реальных данных на условные.
- Относится ли документ к коммерческой тайне, финансам, договорам или коду? Если да, вопрос решает не сотрудник, а руководитель или служба безопасности.
Дополнительное правило для рабочих задач: личный аккаунт в публичном сервисе не используется, пока компания прямо не разрешила это для конкретного типа сведений.
Как защитить данные компании при использовании нейросетей
Памятка работает там, где у сотрудника есть альтернатива. Без неё запрет превращается в формальность: рабочая задача остаётся, а быстрый способ решить её сотрудник всё равно будет искать.
Если компания разрешает использование ИИ в рабочих задачах, безопаснее организовать единый контролируемый канал доступа вместо набора личных аккаунтов и разрозненных сервисов. Такой подход позволяет перенести контроль с самого сотрудника на корпоративную архитектуру.
Почему анонимизация — не универсальное решение
Замена имён и сумм на условные обозначения снижает риск, но не снимает его. Обезличивание в смысле 152-ФЗ и «ручная» анонимизация — разные вещи. По косвенным признакам вроде даты рождения, пола и почтового индекса человека иногда можно определить заново.
Надёжнее, когда маскирование делает не сотрудник, а система на стороне шлюза. Подробнее об этом — в статье про маскирование персональных данных перед отправкой во внешние LLM.
Четыре шага, которые закрывают канал
- Зафиксировать перечень сведений ограниченного доступа и режим коммерческой тайны. Без этого внутренний запрет сложно сделать юридически и технически исполнимым.
- Определить, какие данные и через какой канал разрешены. Основой может стать таблица выше.
- Поставить технический контроль. DLP-система (Data Loss Prevention) показывает, что и куда уходит, и может блокировать отправку по заданным правилам.
- Дать сотрудникам легальный инструмент. Иначе шаги 1–3 создают теневой ИИ вместо того, чтобы его убрать.
Единая точка доступа вместо личных аккаунтов
Рабочая схема — не полный запрет нейросетей, а перевод доступа к ним в контролируемый канал. Такую точку входа даёт платформа AIaaS от ITGLOBAL.COM: единый API к 100+ языковым моделям, российским и зарубежным, вместо десятков личных аккаунтов.
Риск здесь снижается на уровне архитектуры, а не только корпоративными правилами:
- DLP-фильтрация промптов и ответов в реальном времени;
- ролевая модель доступа и логирование запросов;
- квоты и бюджеты по подразделениям и пользователям;
- работа в соответствии с требованиями 152-ФЗ и обработка данных в РФ;
- подключение от нескольких часов до трёх дней в зависимости от сложности контура.
Для задач, где данные не должны покидать контур компании вообще, подходит Private AI Cloud — изолированная среда на GPU ITGLOBAL с возможностью дообучения на своих данных. Если требуется инфраструктура под обработку персональных данных, эту задачу можно закрыть облаком с соответствием требованиям 152-ФЗ.
FAQ
Не всегда. Удаление имен, телефонов, сумм и других очевидных идентификаторов может снизить риск утечки, но само по себе не гарантирует безопасность данных. Ручная анонимизация не равна обезличиванию персональных данных: человека иногда можно повторно идентифицировать по сочетанию должности, дат, места работы, реквизитов сделки, редкой формулировки или других косвенных признаков.
Кроме того, в договорах, финансовых документах и исходном коде такая замена иногда меняет смысл и делает материал непригодным для корректной обработки. Перед загрузкой рабочих файлов во внешний AI-сервис важно оценить не только содержание документа, но и правила передачи данных, корпоративную политику и условия обработки данных конкретным поставщиком.
Да, если данные действительно обезличены: без использования дополнительной информации невозможно определить, к какому конкретному человеку они относятся.
При этом удаления имени, номера телефона или нескольких полей недостаточно. Если человека можно установить по сочетанию должности, работодателя, периода работы, региона, контактных данных, редкого события или иных косвенных признаков, риск повторной идентификации сохраняется. Перед передачей таких данных в нейросеть следует оценить метод обезличивания, цель обработки, состав доступной дополнительной информации и вероятность обратной идентификации.
Без подтвержденного правового основания и разрешенного корпоративного канала не следует загружать в публичные нейросети паспортные данные, номера телефонов, адреса, сведения о зарплате, здоровье, семейном положении, кадровые документы и другие сведения, по которым сотрудника можно прямо или косвенно идентифицировать.
Для рабочих задач безопаснее использовать обезличенные данные либо корпоративный AI-контур с управляемым доступом к моделям, журналированием запросов, ограничением источников и средствами защиты информации. Это особенно важно для документов, которые одновременно содержат персональные данные, коммерческую тайну, финансовую информацию или внутренний исходный код.
Нет. Корпоративный тариф может предусматривать более подходящие для бизнеса условия хранения, доступа и использования данных, но сам по себе не отменяет требования законодательства о персональных данных, внутренние политики компании и ограничения на передачу информации третьим лицам.
Если обрабатываются персональные данные граждан России, нужно отдельно проверить требования к организации обработки и локализации данных. При передаче данных за пределы России также необходимо учитывать правила трансграничной передачи персональных данных.
Перед подключением корпоративного тарифа изучите договор и документацию сервиса: где хранятся данные, используются ли они для обучения моделей, кто получает доступ к запросам, в каких странах находятся обработчики и можно ли отключить сохранение истории.
Последствия зависят от состава переданных данных, масштаба инцидента, настроек сервиса, правового основания обработки и характера нарушения. Для юридических лиц возможна административная ответственность за нарушения законодательства о персональных данных. Размер санкций зависит от конкретного состава нарушения и его масштаба.
Также риски могут быть связаны с несвоевременным выявлением, фиксацией и устранением инцидента, а также с выполнением обязанностей по уведомлению уполномоченных органов. Для сотрудника возможны дисциплинарные меры в соответствии с трудовым договором, локальными актами компании и обстоятельствами разглашения защищаемой информации.
Если данные уже были отправлены, компании следует зафиксировать инцидент, определить, какие именно сведения и в какой сервис переданы, ограничить дальнейшую передачу, проверить настройки аккаунта и хранения истории. Затем нужно оценить дальнейшие действия совместно с юристами, службой информационной безопасности и ответственным за обработку персональных данных.
Проверить фактическое использование нейросетей можно через аудит сетевого трафика, DLP-системы, прокси-серверы, CASB- или SSE-инструменты, а также журналы корпоративного AI-шлюза. Такой анализ помогает установить, к каким AI-сервисам обращаются сотрудники, какие подразделения используют их чаще и через какие каналы могут передаваться документы или фрагменты корпоративной информации.
Опрос сотрудников обычно не показывает полной картины: часть запросов может выполняться через личные аккаунты, браузерные версии сервисов, несанкционированные расширения или мобильные приложения. Поэтому контроль лучше начинать с анализа реальных каналов передачи данных, а затем предложить сотрудникам безопасную корпоративную альтернативу.
Предыдущая статья
