- BrainTools - https://www.braintools.ru -
Договор с клиентом, фрагмент кода, медицинская карта — отважные пользователи нейросетей каждый день загружают данные, которые никогда бы не отправили незнакомому человеку. При этом мало кто понимает, куда физически они попадают, кто может их увидеть и использовать, что происходит после нажатия «удалить».

Меня зовут Дарья Лушкина, я редактор и исследователь в «Рейтинге Рунета». Чтобы стало понятно, откуда я взяла тему конфиденциальности — сначала пара слов о том, с чем мы работаем.
«Рейтинг Рунета» ежегодно собирает и анализирует данные компаний-участников: финансовые показатели — выручку за услуги и её динамику год к году; данные о заказчиках — их размер, бюджеты проектов, продолжительность сотрудничества; экспертизу и репутацию — специализацию, отраслевой опыт [1], награды профильных конкурсов, разнообразие используемых инструментов, площадок и подходов.
В этом году мы решили подключить нейросети к анализу и проверке участников рейтинга. Одна проблема: у нас есть обязательства по конфиденциальности в отношении большей части этих данных. Я как человек, работающий с этими данными, задумалась: Загружает данных во внешний сервис — это уже раскрытие информации? Мы понимаем, куда они попадают после загрузки и как хранятся? Кто их видит?
И проблема эта явна не только наша. Зимой видела исследование: авторы проанализировали трафик 150 российских компаний и выяснили, что в 2025 году сотрудники загрузили [2] в публичные нейросети в 30 раз больше корпоративных данных, чем годом ранее. Там были презентации, аналитика, фрагменты кода, внутренняя переписка — много чего.
Правда, авторы не уточняют, в чём они это измеряли — в гигабайтах или токенах, но проблема очевидная. И там же, кстати, приводится ещё факт: 60% компаний до сих пор не имеют никаких правил работы с ИИ-сервисами. Просто пользуются, особо не задумываясь, что они отдают и кому.
Ну и что, спросите вы? Ну, вот в июле топ-менеджера московской инженерной компании уволили [3] за то, что она загружала служебные документы в DeepSeek. Суд встал на сторону работодателя: разглашение коммерческой тайны.
Чтобы разобраться в том, как нейросеть «переваривает» и использует наши данные, я задала вопросы человеку, который прекрасно в этом всём разбирается — Ярославу Шмулёву, техническому директору интегратора R77 AI [4]. Ниже рассказываю, что я поняла из этого разговора — местами его словами, местами своими.
Когда мы что-то загружаем, это сначала проходит через обычную ИT-инфраструктуру: входной шлюз, backend, системы логирования, хранилища. Если это PDF или презентация — сервис парсит содержимое, извлекает текст и структуру. Дальше текст разбивается на фрагменты и превращается в эмбеддинги — векторные представления семантического смысла, которые позволяют системе находить близкие по смыслу фрагменты, например, «корова» и «молоко» будут ближе друг к другу, чем «корова» и «поезд».
Поэтому данные могут существовать сразу в нескольких формах: исходный файл, извлеченный текст, фрагменты текста, эмбеддинги, логи обработки и служебные метаданные.
Разберём на конкретном примере. Сотрудник загрузил в ChatGPT договор с клиентом и попросил найти риски. Снаружи — одно действие. Внутри — целый пайплайн.
Сначала файл попадает в интерфейс сервиса и отправляется на backend. Там он принимается, проверяется, логируется, сохраняется в хранилище и связывается с конкретным пользователем и диалогом.
После этого начинается обработка. Из PDF или Word-документа извлекается текст, структура, таблицы, заголовки, сноски. Если это скан — дополнительно применяется OCR. То есть модель не «читает файл» напрямую: сначала сервис превращает его в текст и технически удобное представление.
Дальше документ разбивается на фрагменты. Большой договор нельзя просто целиком положить в запрос к модели: у моделей есть ограничения по объёму контекста. Поэтому сервис делит текст на части, выбирает релевантные фрагменты и передаёт модели только то, что нужно для ответа на конкретный вопрос.
После этого формируется финальный запрос: инструкция пользователя («найди риски»), системные правила сервиса и выбранные фрагменты документа. Модель генерирует ответ — и возвращает его в интерфейс.
Упрощённо весь пайплайн выглядит так: файл загружен → попал на сервер → сохранился и залогировался → извлекли текст → разбили на фрагменты → нашли релевантные части → передали модели → получили ответ.
На каждом этапе остаются следы — и не все из них очевидны. Ярослав выделяет несколько наиболее уязвимых мест.
1. Момент хранения исходного файла. Пока договор лежит в хранилище
сервиса в исходном виде, это наиболее чувствительная форма данных: коммерческая тайна, персональные данные, реквизиты, условия сделки — всё это существует как обычный файл на стороне внешнего сервиса.
2. Логи и служебные хранилища. Пользователь обычно думает только о самом
файле, но в ИТ-системах остаются следы: кто загрузил файл, когда, какой был запрос, какие фрагменты были извлечены. Иногда в логах может оказаться часть содержимого документа.
3. Цепочка третьих сторон: облачные провайдеры, подрядчики по
модерации и аналитике качества. Это не обязательно означает, что кто-то вручную читает документ, но технически цепочка доступа становится длиннее с каждым звеном.
4. Использование данных для обучения [5]. Если данные попали не просто в
хранилище, а в обучающий пайплайн, удалить их последствия гораздо сложнее. Сам документ может уже не храниться внутри модели в исходном виде, но он мог повлиять на её параметры.
«Файл загружен» и «файл попал в обучение» — разные события, которые часто путают. Данные могут просто храниться для работы сервиса или обрабатываться для генерации ответа и только при определённых условиях отбираться для дообучения.
У обучения есть несколько стадий с разной логикой [6] отбора. На первой — предобучении — модель учится на терабайтах текстов из интернета, книг, кода. Это как дать человеку прочитать всю библиотеку: он получает знания о языке и мире, но конкретные тексты не запоминает дословно. На следующих стадиях — supervised fine-tuning и RLHF — модель учат понимать инструкции и давать полезные ответы. Данных здесь на порядок меньше, зато требования к качеству гораздо выше: каждый пример напрямую влияет на поведение [7] модели.
Пользовательские диалоги, если и используются, проходят предварительную обработку: из них убирают мусор, стандартизируют формат, удаляют или заменяют персональные данные, сортируют по типам задач. Плюс сэмплирование — в обучение попадает не всё подряд, а выбранные примеры.
Нажать «удалить диалог» и реально удалить данные с серверов — не одно и то же. У сервиса есть резервные копии, логи, очереди обработки, своя политика хранения. Между «удалено из интерфейса» и «удалено из всей инфраструктуры» — существенная техническая разница. Обычно крупные сервисы описывают сроки и правила удаления в политиках конфиденциальности, но пользователь снаружи проверить это не может.
Если данные просто хранятся — их теоретически можно удалить, ограничить к ним доступ или исключить из дальнейшей обработки. Но если данные уже использовались для обучения модели — ситуация принципиально другая. Нельзя «открыть» модель и убрать из неё один конкретный документ как файл из папки: информация уже статистически повлияла на параметры, и это необратимо.
Для этой проблемы существует отдельное направление исследований — machine unlearning, или «машинное разучивание». Идея в том, чтобы удалить влияние конкретных данных из уже обученной модели без полного переобучения с нуля. Звучит круто, но на практике для больших языковых моделей это всё ещё открытая исследовательская задача: точно верифицировать, что данные «забыты» крайне сложно, а частичное переобучение может изменить поведение [8] модели непредсказуемым образом.
А если включить настройку «не использовать мои данные для обучения» — что происходит технически? В идеальном сценарии такая настройка означает, что данные пользователя не должны попадать в пайплайн обучения или дообучения модели. То есть сервис может использовать их для текущего ответа и хранения истории, но не должен включать их в обучающие датасеты.
Мы снаружи не видим, как именно устроены фильтры, логи, исключения, синтетическая переработка данных и контроль доступа. И никто не может знать наверняка, как сервис обращается с данными, так что полностью полагаться на его честность не стоит.
Во-первых, это, конечно же, владельцы и сотрудники сервиса. Мы остаёмся правообладателем своих данных, но в момент принятия пользовательского соглашения — того самого, которое никто не читает — даёте разрешение на их хранение, обработку и использование для обучения модели. Косвенно это может означать, что выводы на основе загружаемой информации, становятся частью общего «знания» системы.
Кроме того, в некоторых версиях часть диалогов просматривают живые модераторы — для улучшения качества ответов. Так устроен, например, Gemini от Google. Как именно диалог попадает на просмотр: через пользовательский фидбэк, случайное сэмплирование, автоматическую классификацию, когда модель сама флагирует рискованный или чувствительный контент — неизвестно. Точные механизмы сервисы обычно не раскрывают.
Во-вторых, доступ к данным есть у инфраструктурных партнёров. Почти все сервисы передают [9] данные партнёрам: для хостинга на мощностях облачных провайдеров вроде Google Cloud или Azure, для техподдержки или анализа качества. Это не «продажа данных», а рабочая необходимость. Но факт передачи — налицо.
В-третьих, хакеры. Да это редкость, и персональные чаты — цель скорее тренировочная. Но взлом серверов возможен, и абсолютной кибербезопасности не существует. Так например, в прошлом году исследователи Wiz Research обнаружили [10] базу данных DeepSeek в открытом доступе — больше миллиона строк: история чатов, секретные ключи, данные серверной части. Это не целевая атака, а классическая ошибка [11] конфигурации, уязвимость сразу закрыли, но утёкшие данные не вернуть.
Хочется верить, что данные передаются партнерам в минимально необходимом объеме и после анонимизации. Но на практике многое зависит от типа партнера.
Если это инфраструктурный партнер, например облачный провайдер, он может физически хранить или обрабатывать данные на своих мощностях. В этом случае речь не обязательно о том, что кто-то вручную читает ваши файлы, но технически данные находятся в инфраструктуре этого партнера.
Если это подрядчик по разметке, модерации или анализу качества, он может получать выборки диалогов или фрагменты данных. Скорее всего, они проходят автоматическую анонимизацию, но при больших объемах нельзя гарантировать, что все чувствительные детали будут удалены идеально.
По словам Ярослава, главный риск не в том, что «данные продают», а в том, что для работы большого AI-сервиса возникает цепочка инфраструктурных и операционных участников, у которых потенциально может быть доступ к части данных.
Передача персональных данных в зарубежный сервис без соблюдения 152-ФЗ — нарушение закона. Исходный код, финансовая отчётность, детали закрытых переговоров, незапатентованные алгоритмы — всё это категории, утечка которых может стоить дорого. Это понятно. Но на практике граница размыта, и именно здесь происходит большинство инцидентов.
Показательно, что это случается даже с мировыми компаниями. Инженеры Samsung отправляли [12] в ChatGPT исходный код на проверку и записи совещаний — фрагменты секретных разработок оказались на серверах OpenAI. В США руководитель агентства по кибербезопасности загрузил в публичный ChatGPT служебные документы с пометкой «Только для официального использования» — это заметили системы внутреннего контроля.
Если это происходит там, где с безопасностью работают профессионально, то что уж говорить об остальных. Как рассказывает Ярослав, когда R77 AI приходят к клиентам, они раз за разом видят одну и ту же проблему: данные хаотично лежат в разных системах, плохо описаны, не имеют понятного владельца и используются без чётких правил.
Один из таких визитов обернулся показательным кейсом. Компания хотела внедрить AI для анализа внутренних документов — договоров, писем, коммерческих материалов. Сотрудники, не дожидаясь официального внедрения, начали проверять гипотезу сами: загружали фрагменты в публичные сервисы, просили обобщить, найти риски. С их точки зрения [13] — это просто рабочий черновик. С точки зрения безопасности — передача конфиденциальной информации во внешний сервис: реальные имена клиентов, условия сделок, суммы, внутренние комментарии.
Реальные последствия были не в том, что данные сразу куда-то утекли. Главный риск проявился иначе: компания поняла, что не может ответить на базовые вопросы — кто именно что загружал, в какие сервисы, какие документы, были ли там персональные данные, можно ли это удалить. Потеря контроля произошла уже в момент загрузки.
В результате компании пришлось вводить правила: какие типы данных запрещено отправлять во внешние AI-сервисы, какие можно использовать только после обезличивания, какие задачи нужно решать через корпоративный контур, а для каких допустимы публичные инструменты. Плюс отдельно описывать процесс: кто владелец данных, кто согласует выгрузку, где хранится результат и как очищаются чувствительные поля.
Понимание того, как устроена система, меняет то, как компании начинают с ней работать. Ярослав наблюдает этот сдвиг в реальных проектах: локальные и гибридные модели становятся всё популярнее. Правда пока локальные версии уступают топовым облачным по качеству рассуждений и работе с длинным контекстом. Но зато дают контроль над данными — и для ряда задач это важнее.
В ближайшие годы для малого и среднего бизнеса они станут доступнее, но не как «поставили и забыли». Всё равно нужны инфраструктура, настройка, интеграция, мониторинг качества и понимание ограничений.
В корпоративном сегменте очевиден тренд на прозрачность: B2B-клиенты хотят знать, где хранятся данные, используются ли они для обучения, кто имеет доступ и можно ли развернуть решение в частном контуре. Провайдеры это чувствуют и поэтому ясности будет явно больше: появятся более понятные настройки, улучшенные корпоративные режимы, инструменты удаления, возможность управления данными.
Позволю себе немного выводов. Я думаю, крупные компании адаптируются к работе с ИИ быстрее всего — у них огромные риски, в том числе при работе с клиентскими данными, и есть ресурсы на локальные модели, корпоративные контуры и контроль за сотрудниками. До всех остальных чек-листы безопасной работы с ИИ будут доходить долго: люди не любят меняться, а нейросети всё ещё воспринимаются как что-то безобидное: ну, подумаешь, загрузил файл.
Посмотрим, сколько будет таких случаев, как с топ-менеджером московской компании. Если истории будут громкими и публичными — может, что-то и сдвинется быстрее. Что касается нас, когда мы начнём использовать нейросети для анализа данных участников, я первая буду топить за правила работы с ИИ. Увольняться не хочется :)
А вот вы задумывались о том, что отдаёте ИИ и куда это потом попадает? Что думаете?
«Рейтинг Рунета» (РР) — это аналитический сервис, который помогает заказчикам и закупщикам оценивать и подбирать подрядчиков в маркетинге, диджитале и ИТ. Всего у нас 49 рейтингов, включая рейтинг компаний, которые занимаются внедрением ИИ [14].
Автор: neperfect
Источник [15]
Сайт-источник BrainTools: https://www.braintools.ru
Путь до страницы источника: https://www.braintools.ru/article/34114
URLs in this post:
[1] опыт: http://www.braintools.ru/article/6952
[2] загрузили: https://rt-solar.ru/events/news/6366/
[3] уволили: https://www.vedomosti.ru/society/news/2026/07/27/1216651-razglashenie-taini
[4] R77 AI: https://r77.ai/
[5] обучения: http://www.braintools.ru/article/5125
[6] логикой: http://www.braintools.ru/article/7640
[7] поведение: http://www.braintools.ru/article/9372
[8] поведение: http://www.braintools.ru/article/5593
[9] передают: https://cmsmagazine.ru/journal/items-reiting-konfidencialnosti-populyarnyh-neirosetei/
[10] обнаружили: https://www.rbc.ru/life/news/679b32609a7947536994a238
[11] ошибка: http://www.braintools.ru/article/4192
[12] отправляли: https://www.cnews.ru/news/top/2026-02-04_sotrudniki_rossijskih_kompanij
[13] зрения: http://www.braintools.ru/article/6238
[14] внедрением ИИ: https://ratingruneta.ru/ai-development/
[15] Источник: https://habr.com/ru/companies/ratingruneta/articles/1068006/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1068006
Нажмите здесь для печати.