Можно ли отправлять клиентские данные в ИИ: правила, обезличивание, альтернативы

Введение – Что такое LLM и почему возникает вопрос о данных
Что такое LLM (Large Language Model)
2.1. Примеры зарубежных LLM: OpenAI, Anthropic, Google Gemini и др.
2.2. Примеры российских LLM: ЯндексGPT, Сбер GigaChat, другие отечественные модели
Виды клиентских данных и их чувствительность
3.1. Персональные данные (ПДн) и категории информации о личности
3.2. Коммерческая тайна и конфиденциальная корпоративная информация
3.3. Чувствительные данные и поведенческие профили клиентов
Правовые ограничения на передачу данных в LLM
4.1. Российское законодательство: 152-ФЗ и требования Роскомнадзора
4.2. Трансграничная передача данных: локализация в РФ, требования к передаче за рубеж
4.3. Международные нормы: GDPR и другие регламенты при работе с зарубежными LLM
4.4. Разъяснения регуляторов: позиции Минцифры РФ, Роскомнадзора и зарубежных регуляторов
Риски отправки клиентских данных в облачные LLM
5.1. Утечки и несанкционированный доступ к данным
5.2. Отсутствие гарантий удаления и длительное хранение данных
5.3. Передача данных третьим лицам и возможное использование без контроля
5.4. Примеры инцидентов: утечки через ChatGPT и реакции компаний
Обезличивание (анонимизация) данных: понятия и стандарты
6.1. Обезличивание по российскому праву (деперсонализация ПДн)
6.2. Анонимизация vs. псевдонимизация: стандарты ISO/NIST и практические отличия
6.3. Методы обезличивания: маскирование, агрегация, шифрование, дифференциальная приватность
6.4. Риски деанонимизации: достаточность обезличивания и примеры восстановления данных
Что разрешено: передача данных в LLM по закону и на практике
7.1. Можно ли отправлять обезличенные данные в LLM (юридические аспекты)
7.2. Ограничения на передачу даже обезличенных данных: формальные и фактические
7.3. Требуется ли согласие клиента или иной правовой базис для использования данных в LLM
Альтернативы: как работать с LLM, не нарушая конфиденциальность
8.1. Self-hosted LLM (развёртывание модели на своей инфраструктуре)
8.2. Тонкая настройка (fine-tuning) моделей на обезличенных данных
8.3. Локальный inference: использование локальных моделей без отправки данных
8.4. Российские API и решения с гарантией конфиденциальности (пример: GigaChat, Яндекс)
8.5. Промежуточные решения: прокси-анонимайзеры, шифрование, доверенная среда выполнения
8.6. Таблица: Обзор альтернативных решений и их характеристики
Практические рекомендации по минимизации рисков
9.1. Политики и регламенты внутри компании: что прописать и внедрить
9.2. Обучение сотрудников: цифровая гигиена и осведомлённость о рисках ИИ
9.3. Технические меры: ограничение доступа, DLP, мониторинг использования ИИ
9.4. Как безопасно экспериментировать с LLM в бизнесе
Заключение – Баланс инноваций и безопасности: выводы для предпринимателей

1. Введение

Активное развитие технологий искусственного интеллекта поставило перед бизнесом новый вопрос: можно ли отправлять клиентские данные в LLM-модели (Large Language Models) и как делать это законно и безопасно. LLM – это большие языковые модели, способные генерировать связный текст и отвечать на вопросы, обученные на огромных массивах данных. Они используются в чат-ботах, системах поддержки, анализе документов и множества иных задачах. Предприниматели видят большой потенциал LLM для улучшения клиентского сервиса и внутренних процессов, но работа с реальными данными клиентов вызывает обоснованные опасения в области конфиденциальности и комплаенса.

В России вопрос особенно актуален, поскольку законодательство о персональных данных строго регулирует обращение с информацией о клиентах. В то же время глобальный рынок предлагает мощные LLM-сервисы, большинство из которых – зарубежные (OpenAI ChatGPT, Google Gemini, Anthropic Claude и др.). Перед компанией возникает дилемма: как извлечь пользу из современных ИИ-моделей, не нарушая закон и не рискуя утечкой данных. В этой статье мы подробно рассмотрим: какие правила действуют в РФ и мире, что такое обезличивание (анонимизация) данных и как его применять, какие существуют альтернативы прямой отправке данных в чужие LLM, и какие практические шаги может предпринять бизнес для безопасного использования таких технологий.

Мы приведём реальные примеры: от публичных кейсов (утечка данных Samsung через ChatGPT, рекомендации регуляторов не делиться конфиденциальной информацией с ИИ) до практик компаний, которые нашли баланс – например, с помощью промежуточных прокси-систем для анонимизации запросов. Ссылки на нормативные акты (152-ФЗ, GDPR и др.), разъяснения государственных органов (Роскомнадзор, Минцифры) и стандарты (ISO, NIST) помогут понять нормативную сторону вопроса. Также мы представим сравнительную таблицу вариантов внедрения LLM (собственная инфраструктура, облачные решения в РФ и за рубежом, методы защиты) с их характеристиками – это поможет предпринимателю выбрать оптимальный путь.

Цель статьи – дать целостное руководство для владельцев бизнеса и менеджеров, как грамотно и безопасно интегрировать LLM в работу с клиентскими данными. Материал изложен в нейтральном деловом стиле, с акцентом на практичность: чек-листы, рекомендации по политике безопасности, обучению сотрудников. Начнём с основ: что представляют собой LLM и какие данные клиентов вообще бывают с точки зрения законодательства и бизнеса.

2. Что такое LLM (Large Language Model)

Large Language Model (LLM) – это класс моделей искусственного интеллекта, обученных на гигантских корпусах текстовых данных для понимания и генерации естественного языка. По сути, LLM – это нейросеть с очень большим числом параметров, способная предсказывать следующую часть текста на основе предыдущей. Благодаря этому LLM умеют поддерживать диалог, писать связные тексты, отвечать на вопросы, переводить, анализировать содержание документов и выполнять многие другие сложные языковые задачи.

В последние годы LLM стали основой множества чат-ботов и ИИ-сервисов. Зарубежные технологические компании инвестируют огромные ресурсы в разработку таких моделей, и появились массово популярные продукты:

OpenAI – разработчик ChatGPT (модель GPT-3.5/GPT-4). ChatGPT стал синонимом продвинутого диалогового ИИ, способного от сочинения писем до написания кода. OpenAI также предоставляет API для разработчиков и корпоративные версии.
Anthropic – создатели ассистента Claude, позиционирующегося как безопасный и качественный собеседник. Claude конкурирует с моделями OpenAI, а Anthropic заявляет принципы «конституционального ИИ» для снижения токсичности.
Google – развивает семейство моделей вроде PaLM; их свежий проект – Gemini, заявленный как мультимодальный ИИ нового поколения. Google уже интегрирует LLM (например, Bard, основанный на LaMDA/Palm) в свои продукты и облачные сервисы.
Microsoft – стратегический партнер OpenAI, интегрировал GPT-4 в Bing Chat, Office Copilot и другие инструменты. Также развивает собственные наработки и предлагает Azure OpenAI Service для корпоративного использования ИИ.
Amazon – помимо своих ассистентов (Alexa), запустил сервисы вроде Bedrock с доступом к моделям AI21, Anthropic и собственным LLM (например, Amazon Titan), фокусируется на бизнес-применениях.
Другие: Meta (LLama2, открытая модель, которую могут разворачивать компании локально), IBM (проекты в области нейросетевого NLP), множество стартапов и open-source сообществ (HuggingFace, BigScience BLOOM и др.).

Российские компании также активно работают над LLM, стремясь обеспечить альтернативы западным решениям и учесть русский язык и локальные требования:

Яндекс – ещё с 2017 развивал генеративные модели (YaLM). В 2023 представлена YandexGPT, которую интегрировали в голосового ассистента «Алиса» и другие продукты. YandexGPT доступна для разработчиков, обучена на русскоязычных данных и понимает контекст российской реальности.
Сбер – группа компаний Сбера запустила весной 2023 г. модель GigaChat, позиционируемую как ответ ChatGPT. GigaChat построена на собственной архитектуре SBER, уделено внимание безопасности и мультимодальности. Сбербанк (через Sber AI) ранее создавал семейство моделей ruGPT-3, а теперь предлагает GigaChat 2.0 и даже GigaChat 3 (в превью) как отечественную платформу ИИ.
Другие игроки: компании вроде Just AI, DeepPavlov, SberDevices и др. разрабатывают модели разговорного ИИ, часто узкоспециализированные. Например, для обработки звонков, поддержки клиентов на русском и т.д. Также появляются стартапы, адаптирующие открытые модели (как Llama) под российскую специфику.

Важно понимать, что LLM – это модель общего назначения, обученная на данных из интернета, книг, Википедии, кодовых репозиториев и т.п. Для бизнеса ценность LLM в способности обобщать знания и выполнять интеллектуальные операции без специального программирования. Но та же особенность создаёт риски: модель не «знает» границ, она запоминает фрагменты обучающих данных и пользовательских диалогов. Например, крупное исследование показало, что LLM могут запоминать и воспроизводить фрагменты приватной информации, присутствовавшей в обучающем наборе. Поэтому, когда мы даём модели новый ввод, особенно содержащий уникальные данные (например, сведения о клиенте или код программы), мы должны учитывать – куда эта информация попадёт и как может быть использована моделью.

Подводя итог: LLM – мощный инструмент для обработки языка, с примерами как мировых (ChatGPT, Claude, Bard), так и российских (ЯндексGPT, GigaChat) реализаций. Для предпринимателя они открывают новые возможности автоматизации и аналитики. Однако взаимодействие LLM с реальными клиентскими данными – зона повышенного внимания, поскольку затрагивает приватность, законы о данных и информационную безопасность. Далее рассмотрим, какие типы данных бывают и чем они отличаются в контексте рисков и регуляций.

3. Виды клиентских данных и их чувствительность

Прежде чем отправлять какую-либо информацию в LLM, важно классифицировать, о каких данных идёт речь. В бизнесе под «клиентскими данными» могут пониматься самые разные сведения – от имени клиента до истории его покупок. Разные категории данных имеют разный правовой статус и уровень конфиденциальности:

3.1. Персональные данные (ПДн)

Персональные данные – это любая информация, относящаяся к определённому или определяемому физическому лицу (субъекту данных). Иными словами, если по сведениям можно прямо или косвенно идентифицировать конкретного человека, эти сведения считаются персональными данными. К персональным данным относятся, например:

Основные идентификаторы: ФИО, дата и место рождения, пол, гражданство.
Контактные данные: адрес проживания, телефон, электронная почта, аккаунты в соцсетях.
Документные данные: паспортные данные (серия, номер), СНИЛС, ИНН, водительское удостоверение, загранпаспорт и пр. – любые государственные идентификаторы личности.
Биометрия: фотография лица, отпечатки пальцев, образец голоса, данные о радужке глаза и т.д.
Медицинские данные: история болезней, диагнозы, результаты анализов, сведения о лечении.
Финансовые данные: номера банковских счетов и карт, сведения о доходах и расходах, кредитная история, покупки.
Образование и карьера: дипломы, сертификаты, место работы, должность, опыт работы.
Данные о передвижениях: геолокация, история поездок, маршруты (например, данные от транспортных приложений).
Предпочтения и поведение: история посещения сайтов, поисковые запросы, интересы, покупки, отклики на рекламные рассылки.

Часть такой информации клиенты сами добровольно предоставляют компаниям (анкеты, профили), другая часть генерируется в процессе обслуживания (история заказов, обращения в поддержку). Все персональные данные строго защищаются законом – в России это Федеральный закон № 152-ФЗ «О персональных данных», в Европе – GDPR, и т.п. (подробно о правовых аспектах – в следующем разделе). Несанкционированное раскрытие или неправильная обработка ПДн несёт юридические риски. Поэтому отправлять LLM необработанные персональные данные крайне рискованно, особенно если речь о внешнем (чужом) сервисе: по сути, это будет разглашение информации третьей стороне.

Отдельно закон выделяет специальные категории ПДн – особенно чувствительные сведения: расовая/этническая принадлежность, политические взгляды, религиозные убеждения, здоровье, интимная жизнь. Их обработка запрещена без особых оснований. Также есть биометрические ПДн (фото, голос) – для них тоже особый режим. Передача таких данных куда-либо (тем более в иностранный ИИ-сервис) практически всегда запрещена или требует явного согласия субъекта.

3.2. Коммерческая тайна и конфиденциальная корпоративная информация

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

Коммерческая тайна – сведения, связанные с бизнесом, которые имеют ценность именно в режиме ограниченного доступа. В законе о коммерческой тайне перечислено: сведения о стратегии развития, маркетинговые планы, данные о клиентах и контрактах, незапатентованные разработки, ноу-хау, перечни поставщиков и т.п. Если компания ввела режим коммерческой тайны (проставляет гриф «Коммерческая тайна» на документах, уведомила сотрудников), то такие данные защищаются законом от разглашения.
Финансовая информация (конфиденциальная) – внутренние финансовые отчёты, прогнозы, бюджеты, информация о прибыли/убытках до их публичного раскрытия. Например, данные управленческого учёта, инвестпланы.
Интеллектуальная собственность (в стадии разработки) – технические чертежи, исходный код программ, алгоритмы, формулы, заявки на патенты до их публикации. Если такая информация утечёт, компания может потерять технологическое преимущество.
Операционные данные – сведения о внутренних процессах: технологии производства, логистические схемы, базы клиентов, внутренние регламенты, данные об эффективности подразделений и т.д. Эти вещи не всегда формально отнесены к коммерческой тайне, но, как правило, тоже считаются конфиденциальными внутри компании.

Утечка любой из этих категорий может нанести прямой ущерб бизнесу – от потери конкурентного преимущества до штрафов и судебных исков. Поэтому компании заключают NDA (соглашения о неразглашении) с сотрудниками и партнёрами. В контексте LLM это означает, что запрещено вводить в публичные ИИ-сервисы информацию, покрытую NDA или режимом конфиденциальности. Например, было бы грубой ошибкой попросить ChatGPT проанализировать внутренний отчёт с грифом «коммерческая тайна» – фактически вы раскрыли его разработчикам модели.

Следует помнить: передача любой информации третьему лицу (даже ИИ-сервису) – это потенциальное нарушение обязательств о конфиденциальности. Во многих трудовых договорах прямо указано, что работник не имеет права разглашать коммерческую тайну и служебные сведения, в том числе через Интернет. Поэтому отправка таких данных в чат-бот без специальных мер – нарушение трудовой дисциплины, за которое могут последовать санкции.

Даже если сотрудник решит «проконсультироваться» с ИИ по личному поводу, надо фильтровать информацию. Категорически недопустимо сообщать чат-боту пароли, доступы, PIN-коды или другие критичные секреты – их разглашение несёт прямой ущерб (мошенники могут использовать, ИИ может их сохранить). Об этом мы поговорим подробнее в разделе о рисках.

3.3. Чувствительные данные и поведенческие профили

Помимо классических ПДн и коммерческой тайны, есть данные, находящиеся на стыке и также требующие осторожности:

Поведенческие профили клиентов. Компании часто собирают и анализируют большие массивы данных о поведении клиентов: что и когда покупает, как реагирует на акции, какие страницы сайта посещает, с какого устройства. Эти профили ценны для маркетинга и персонализации. Формально, если профиль обезличен (не содержит имени клиента, только параметры), то это может не считаться ПДн. Но на практике поведенческий профиль часто можно сопоставить с конкретным человеком при наличии идентификаторов (cookie, email и т.д.). GDPR, например, считает онлайн-идентификаторы (IP-адрес, куки, рекламный ID) – персональными данными. В РФ тоже, если можно по профилю вычислить субъекта, профиль становится ПДн. Такие данные очень чувствительны: их утечка подрывает доверие, а неправомерное использование (например, передача без согласия) нарушает закон.
Специальные категории данных о клиентах. Например, данные о здоровье клиента, если вы медицинская компания; данные об его детях; религиозные взгляды (можно узнать из потребления контента). Эти сведения требуют особенно бережного обращения. Их нельзя просто так «скормить» модели для анализа текста – требуется как минимум анонимизация или согласие клиента.
Данные платежных карт и счетов. Здесь помимо закона о ПДн действует стандарт безопасности индустрии платежей (PCI DSS). Ни в коем случае нельзя вводить полный номер карточки, CVV-код, PIN в чат-бот – ни свой, ни тем более клиентский. Комитет Московской области по цифровой безопасности прямо рекомендовал гражданам не передавать ИИ финансовую информацию: PIN-коды, CVV, реквизиты счетов, сведения о сбережениях. Для бизнеса утечка таких данных – не только репутационный удар, но и возможные штрафы от регуляторов финансового рынка.
Идентификаторы документов (серия и номер паспорта, водительских прав, страховых полисов). Как отмечал Минцифры и эксперты, ФИО, паспортные данные, СНИЛС, ИНН – не место в запросах к ИИ. Это тоже персональные данные, которые, будучи скомбинированными, открывают дорогу к злоупотреблениям (оформление кредита на имя человека и др.).
Фото- и видео- данные клиентов. Фотографии, видео с лицами – биометрические ПДн. Отправлять их внешнему ИИ (например, сервису распознавания лиц) можно только при наличии согласия субъекта на обработку биометрии. В РФ с 2021 года ужесточён режим биометрических данных – они требуют отдельного согласия, и храниться должны, как правило, в аккредитованных информационных системах. Передача биометрии на иностранный сервис – практически очевидное нарушение 152-ФЗ, если только человек сам публично не выложил эти фото (но даже в этом случае могут быть нюансы).

Резюме по разделу: клиентские данные бывают разного рода, но золотое правило – чем информация более личная или более ценная для бизнеса, тем осторожнее с её использованием в ИИ. Персональные данные – под защитой закона и требуют либо согласия, либо обезличивания перед использованием в LLM. Коммерческая тайна и конфиденциальные сведения – вообще не должны покидать контур организации без крайне веской причины (и разрешения руководства). В следующем разделе мы детально рассмотрим правовые ограничения, чтобы понимать не только здравый смысл, но и букву закона.

4. Правовые ограничения на передачу данных в LLM

Использование клиентских данных в любых системах регулируется законодательством о защите этих данных. В контексте LLM, особенно облачных, ключевыми являются законы о персональных данных (в РФ – 152-ФЗ, в ЕС – GDPR), а также законы о тайне связи, коммерческой тайне и т.д. Рассмотрим основные правовые нормы, касающиеся передачи данных в сторонние сервисы ИИ.

4.1. Российское законодательство: 152-ФЗ и требования Роскомнадзора

В России базовым актом является Федеральный закон № 152-ФЗ «О персональных данных». Он устанавливает принципы обработки ПДн и обязанности компаний-операторов (т.е. тех, кто собирает и использует ПДн клиентов). Ключевые моменты применительно к вопросу об LLM:

Обработка персональных данных допускается только на законных основаниях. Статья 6 152-ФЗ перечисляет случаи: согласие субъекта, исполнение договора, обязанность по закону, жизненно важные интересы и др. Отдельно есть пункт 9: обработка в статистических или иных исследовательских целях при условии обязательного обезличивания персональных данных. То есть закон прямо говорит: для исследований (под которые можно подвести и обучение моделей ИИ) персональные данные должны быть предварительно обезличены. Без этого – незаконно.
Трансграничная передача ПДн. Если компания хочет передать данные из России за рубеж (а серверы OpenAI, Google и т.д. – как правило, за рубежом), она должна убедиться, что в стране-получателе обеспечивается адекватная защита ПДн. Роскомнадзор ведёт список стран с адекватной защитой. США, кстати, в таком списке не состоят. Передача в страну без адекватного режима возможна только либо при согласии самого субъекта ПДн, либо если это нужно для договора с субъектом (например, купить авиабилет – передать его данные иностранной авиакомпании), либо в ряде других узких случаев (ст.12 152-ФЗ). Отправка данных в OpenAI или Anthropic, не получив согласия клиента – нарушение, поскольку США не гарантируют уровень защиты, требуемый нашим законом.
Хранение ПДн российских граждан – по требованию «закона о локализации данных» (поправки к 152-ФЗ от 2015 года) первичная база персональных данных граждан РФ должна храниться на территории России. Если мы используем зарубежный LLM-сервис, мы фактически загружаем данные на зарубежный сервер, минуя российскую базу, что конфликтует с требованием локализации. Даже если компания формально хранит данные в РФ, единичная передача их копий за рубеж уже может рассматриваться как трансграничная передача.
Ответственность и надзор. Роскомнадзор (РКН) – основной надзорный орган. В 2023–2025 гг. требования сильно ужесточились: с 1 сентября 2025 введены новые регламенты обезличивания (Приказ РКН № 140) и резко повышены штрафы за нарушения. Например, с 2025 года штраф за утечку ПДн начинается от 1,5 млн руб (для юрлиц). Максимальные штрафы могут достигать до 20 млн руб или % от годовой выручки в случае крупных нарушений – практически на уровне GDPR. Причём отдельный акцент на трансграничной передаче: нарушения при пересылке данных за рубеж теперь обойдутся крайне дорого. РКН получил полномочия проводить внезапные проверки кибербезопасности, требовать доказательства защиты данных. Поэтому для бизнеса вопрос не академический – санкции реальны.

Что всё это значит применительно к LLM: если клиентские данные – ПДн, их передача во внешний сервис ИИ должна соответствовать 152-ФЗ. На практике, поскольку ни OpenAI, ни Google не находятся в РФ, единственный более-менее законный вариант – обезличивать данные (анонимизировать их) перед отправкой. Либо получать от каждого клиента информированное согласие, что его ПДн будут отправлены на обработку, например, в OpenAI API (и то есть сомнения, будет ли это полностью легитимно). В разделах об обезличивании мы раскроем требования подробнее, но забегая вперёд: с 2025 года под обезличиванием РКН понимает именно необратимую анонимизацию. Псевдонимизация (когда данные заменены кодами, но есть возможность восстановления) – по сути, не освобождает от статуса ПДн. Значит, просто убрать имя и оставить, скажем, номер телефона – недостаточно.

Кроме закона о ПДн, есть и другие: например, Закон о коммерческой тайне (№ 98-ФЗ) – если информация отнесена к коммерческой тайне, её разглашение третьим лицам незаконно и может повлечь гражданско-правовую, а в некоторых случаях и уголовную ответственность. Закон об охране тайны связи (например, переписка, сообщения клиентов операторов связи не могут передаваться кому попало). Закон о банках (установлена банковская тайна на сведения о счетах клиентов) – банку запрещено раскрывать информацию о счетах и операциях без согласия клиента. Таким образом, для определённых отраслей есть специальные нормы: например, банку нельзя загрузить в чат-бот выписку со счета клиента, это нарушит режим банковской тайны.

Важно отметить, что пока российские регуляторы прямо не выпустили отдельного закона или инструкции по ИИ-моделям. Но работа идёт: обсуждаются поправки об экспериментальных правовых режимах для ИИ, о специальных условиях для разработчиков (тот самый п.9.1 ст.6 152-ФЗ про эксперименты в Москве). Минцифры РФ вместе с регионами уже ведут разъяснительную работу для пользователей о безопасном обращении с ИИ (пример – рекомендации Московской области, о которых ниже). Уже очевидна позиция: не передавать ИИ никаких персональных и конфиденциальных данных, если нет уверенности в защите.

4.2. Трансграничная передача данных: локализация и иностранные облака

Стоит подчеркнуть отдельно аспект “где находятся сервера LLM”. Вопрос не праздный: если они за границей, мы имеем трансграничную передачу. Почему это важно:

Локализация данных: Персональные данные россиян должны первоначально собираться и храниться в РФ (ст.18(5) 152-ФЗ). Если компания использует иностранный сервис напрямую, минуя российское хранилище, она нарушает это требование. Теоретически, можно сначала сохранить ПДн в базе в РФ, а потом копию отправить ИИ – но тогда включаются правила трансграничной передачи (см. выше).
Отсутствие юрисдикции: Отправив данные в иностранную модель, вы фактически вывели их из-под контроля российских законов. Если завтра случится утечка или злоупотребление, Роскомнадзор не сможет напрямую воздействовать на OpenAI или другую иностранную компанию (кроме как ограничить доступ к сервису в РФ). Нет механизма потребовать удалить данные или наложить штраф на иностранного провайдера. Это потенциально опасно для прав субъектов данных.
Облачный закон (№ 236-ФЗ): В 2022 г. принят закон, ограничивающий деятельность иностранных лиц в российском сегменте интернета. В частности, он требует от иностранных владельцев информационных систем (к которым можно отнести и глобальные ИИ-сервисы) исполнять российские законы, регистрировать филиалы в РФ и т.п. Пока OpenAI и другие этого не сделали, их сервисы официально не представлены в России. Это привело к тому, что прямой доступ к ChatGPT в РФ сейчас ограничен – без VPN многие не могут зайти. С одной стороны, это вопрос санкций и политики, с другой – защиты данных (РКН возможно опасается неконтролируемого сбора данных россиян).

Таким образом, использование зарубежных LLM несёт в себе юридическую неопределённость: формально компания будет нарушать требования по локализации и, если без согласия, по трансграничной передаче. Практически, Роскомнадзор пока не штрафовал компании именно за использование ChatGPT (случаи еще не афишировались). Но известны косвенные меры: например, Главный радиочастотный центр (структура при РКН) в 2023 предложил заблокировать сбор данных GPT-ботом (сканером интернета OpenAI) на сайтах РФ. Т.е. надзорные органы внимательно смотрят на деятельность ИИ. Бизнесу разумнее не дожидаться показательных дел, а самим позаботиться о соответствии закону.

4.3. Международные нормы: GDPR и другие регламенты при работе с зарубежными LLM

Если компания оперирует не только в России, но и на международном рынке (или обрабатывает данные граждан ЕС, США и т.д.), надо учесть и иностранные законы о данных. Кратко основные моменты:

GDPR (ЕС): Общий регламент по защите данных в Евросоюзе. Во многом похож на 152-ФЗ по духу, но ещё строже прописывает требования. Под GDPR любая обработка персональных данных требует основания (consent, contract, legal obligation и т.п.), субъектам даны широкие права (узнавать, удалять свои данные). Если российская компания, работая с данными европейцев, загрузит их в ChatGPT, она совершит трансфер данных за пределы ЕС. После решения Суда ЕС Schrems II (2020) передачи данных в США крайне осложнились – нужны Standard Contractual Clauses и дополнительная оценка, ведь американские сервисы подпадают под законы типа Cloud Act (власти США могут запрашивать данные). Поэтому европейские регуляторы осторожно относятся к таким практикам.
Показательный случай – блокировка ChatGPT в Италии в марте 2023. Итальянский регулятор Garante отметил, что ChatGPT нарушает GDPR: не прозрачно сообщает, какие данные собирает и как их использует, и произошла утечка данных пользователей. Доступ к сервису в Италии приостановили до тех пор, пока OpenAI не реализовала требования (ввела возможность для европейцев отключать использование своих данных для обучения и др.). OpenAI выполнила условия, и через месяц ChatGPT разблокировали. Этот инцидент показал, что европейские власти способны очень быстро применить санкции к ИИ-сервису, если увидят угрозу приватности. Для бизнеса, работающего с ЕС, это сигнал: нужно быть особенно внимательным, если вы планируете как-то использовать личные данные европейцев в ИИ – последствия могут быть серьёзными (штрафы по GDPR до 20 млн евро или 4% оборота).
Законы других стран: В США нет единого федерального закона о данных, но штаты принимают свои (CCPA в Калифорнии, VCDPA в Вирджинии и др.). Эти законы пока мягче GDPR, но тоже требуют раскрытия, с кем вы делитесь данными. Если компания вдруг решит отправить данные клиентов (калифорнийцев) внешнему ИИ, она обязана уведомить их, иначе рискует нарушить CCPA, который даёт право запретить «продажу» данных третьим лицам. Тут ИИ-сервис может трактоваться как получатель данных в коммерческих целях – тонкий момент.
Конфиденциальность и ИИ – новая область, где правил пока мало. Сейчас в мире обсуждается AI Act (Акт об ИИ) в ЕС, который будет регулировать применение ИИ-систем. Предполагается требование прозрачности: разработчики LLM должны раскрывать, на каких данных обучены модели, как они защищают данные. Уже появились добровольные AI Cards (карточки модели), где прописываются источники данных и ограничения модели, но пока это не строго и не про пользовательские данные, а про обучающие датасеты.

В общем, если бизнес международный, то нужно учитывать законы каждой юрисдикции. Универсальный совет: анонимизируйте персональные данные, если собираетесь использовать их в LLM, тогда формально это уже не ПДн и многие ограничения снимаются. Но важно, чтобы анонимизация была действительно надёжной (об этом далее).

4.4. Разъяснения регуляторов: позиции Минцифры РФ, Роскомнадзора и зарубежных регуляторов

На момент написания статьи профильные ведомства РФ не выпускали отдельной публичной инструкции типа «Как можно/нельзя использовать нейросети с данными». Однако, есть косвенные сигналы и рекомендации:

Минцифры РФ вместе с регионом (Московская область) подготовили памятку для граждан о безопасном использовании ИИ. Там прямым текстом говорится: «не передавайте искусственному интеллекту персональные данные (ФИО, СНИЛС, ИНН, адреса, телефоны, паспортные данные)», а также «не раскрывайте финансовую информацию и пароли». То есть на уровне просвещения пользователей государство уже предупреждает о рисках. Если экстраполировать на бизнес: органам власти явно не нравится идея, что конфиденциальные данные гуляют в глобальных ИИ. Позже этот же документ советует относиться к общению с открытым ИИ как к публичному пространству: «общайтесь с общедоступным ИИ (ChatGPT, DeepSeek, GigaChat, YandexGPT) так, как будто всё написанное сразу становится достоянием интернета». Это важное указание на философию регулятора: считать, что приватности при использовании чужого ИИ нет, и потому не говорить ничего такого, что вы не готовы увидеть в открытом доступе.
Роскомнадзор пока ограничивался общими напоминаниями про защиту ПДн. В 2023 году он выпустил методические рекомендации по выполнению 152-ФЗ, но там нет прямого упоминания ИИ. Тем не менее, РКН обновил требования по обезличиванию (Приказ № 140 от 19.06.2025) – фактически устанавливает стандарты анонимизации, которых должны придерживаться операторы, если хотят использовать данные в исследованиях или делиться с кем-то. Этот приказ мы ещё рассмотрим, но его суть: обезличенные данные не должны позволять ре-идентифицировать человека никаким способом. РКН также собирает сведения об утечках: по его данным, только в 2022 году было около 150 крупных утечек ПДн в РФ. Это создало нервозность вокруг любого необдуманного обращения с данными.
Зарубежные регуляторы активно интересуются, не нарушают ли LLM конфиденциальность. Кроме упомянутого итальянского, расследования стартовали в Испании, Франции, Канаде против OpenAI. Корпорации тоже реагируют: Samsung после инцидента с утечкой исходного кода через ChatGPT запретила своим сотрудникам использовать публичные ИИ на рабочих устройствах. В служебной записке они отметили, что данные, загруженные в такие платформы, «хранятся на внешних серверах, их легко найти, но трудно удалить». Сотрудникам Samsung теперь нельзя ни на рабочих компьютерах, ни даже на личных (для рабочих задач) пользоваться любыми чат-ботами типа ChatGPT. Нарушение карается вплоть до увольнения. Этот пример – не закон, но лучшие практики корпоративной безопасности.

Подытоживая раздел: правовые ограничения достаточно строги. В России отправлять данные клиентов во внешний LLM можно только либо а) после надёжной анонимизации, либо б) получив информированное согласие от каждого на такую передачу (и убедившись, что страна, куда передаём, защищает данные). На практике вариант (b) почти нереализуем, остаётся (a) – обезличивание. Поэтому следующий раздел посвящён именно обезличиванию: что оно означает в законе и в технике, как его проводить и какие есть подводные камни.

5. Риски отправки клиентских данных в облачные LLM

Прежде чем обсуждать способы смягчения рисков, важно ясно понимать характер угроз, возникающих при передаче данных в облачные LLM (особенно зарубежные). Какие опасности существуют, если игнорировать требования закона и отправить реальные пользовательские данные напрямую в ИИ-сервис:

5.1. Утечки и несанкционированный доступ к данным

Утечка данных – страшный сон любого бизнеса. Отправляя данные во внешний сервис, мы теряем полный контроль, и остаётся надеяться на меры безопасности провайдера. Но даже крупнейшие ИИ-компании не застрахованы от инцидентов:

В марте 2023 года произошёл сбой у OpenAI: из-за ошибки в библиотеке Redis пользователи ChatGPT могли видеть куски чужой истории чатов и некоторые личные данные других пользователей. В том числе утекли имена, email и частично платежные данные ~1,2% подписчиков ChatGPT Plus. Итальянский регулятор упомянул эту утечку как причину блокировки сервиса.
СМИ сообщали об утечке в Samsung: разработчики случайно скопировали в ChatGPT фрагменты внутреннего исходного кода, чтобы получить помощь, – тем самым “слили” код на внешние серверы. Это не классическая хакерская утечка, а утечка по вине пользователей, но эффект тот же – конфиденциальная информация покинула компанию. Реакция Samsung была жёсткой (запрет AI-инструментов на рабочих местах).

Даже если сами провайдеры ИИ заботятся о безопасности, всегда есть риск, что злоумышленники взломают сервис. В той же марте 2023 хакеры попытались атаковать ChatGPT – некоторые источники интерпретировали сбой как «взлом». Если хакерам удастся проникнуть в облако LLM, они потенциально получат доступ ко всем хранимым там данным (к истории запросов пользователей, загруженным файлам и пр.). А это могут быть и личные, и платежные данные, и разного рода секреты. После такого доступного варианта развития событий – публикация данных в сеть или продажа на чёрном рынке.

Стоит учитывать и внутренние угрозы: доступ к пользовательским данным имеют сотрудники компаний-разработчиков LLM. Политики конфиденциальности OpenAI, Google прямо говорят, что чаты пользователей могут проверяться людьми (например, для модерации или улучшения сервисов). Пользователям даже показывают предупреждение: «не вводите информацию, которую не хотели бы показывать другим». Это означает, что любая информация, которую вы ввели в чат, теоретически может быть прочитана оператором или модератором сервиса. Если среди этих данных – клиентские персональные сведения или коммерческая тайна, вы уже их раскрыли постороннему лицу. Корпоративные версии LLM обещают более строгую приватность, но в бесплатных/публичных такого ожидать не приходится.

Итак, риск утечки включает: хакерские атаки на провайдера, ошибки системы, любопытство инсайдеров. Вероятность не нулевая, а ущерб может быть колоссальным (штрафы, суды, репутация). Поэтому первым делом нужно предотвращать попадание чувствительных данных в такие ситуации.

5.2. Отсутствие гарантий удаления и длительное хранение данных

Что происходит с данными после того, как вы отправили их LLM? К сожалению, гарантий удаления практически нет. Большинство сервисов сохраняют историю взаимодействий на своих серверах. Например, Google хранит диалоги с их чат-ботом Gemini по умолчанию 18 месяцев (пользователь может поменять на 3 или 36 месяцев). Чаты, которые проверены модераторами, Google хранит минимум 3 года. OpenAI и Microsoft в политике пишут расплывчато: данные могут храниться для обеспечения “trust & safety” неопределённое время. Amazon просто говорит: данные хранятся “для улучшения услуг”.

Проще говоря, отправив информацию раз, вы не знаете, сколько лет она пролежит в архивах компании. Даже если удалить ее из интерфейса (например, очистить историю чатов), скорее всего на серверах она остаётся. OpenAI недавно ввёл настройку, позволяющую отключить сохранение истории для обучения – тогда чаты хранятся всего 30 дней, но только для отслеживания нарушений, затем обещают удалять. Однако это на доверии – проверить нам сложно.

Отсутствие гарантий удаления означает и невозможность выполнить требования закона, если субъект данных потребует удалить его данные. В случае с LLM, у оператора бизнеса просто нет контроля – он не сможет удостовериться, что, скажем, из всех резервных копий OpenAI удалены отправленные ранее сведения о клиенте. А по тому же GDPR или 152-ФЗ субъект имеет право на удаление (право быть забытым и т.п.).

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

5.3. Передача данных третьим лицам и возможное использование без контроля

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

Использование данных для обучения моделей. Почти все крупные AI-компании признают, что пользовательские запросы и ответы могут быть добавлены в обучающие датасеты для улучшения моделей. Из анализа политик конфиденциальности 5 крупнейших LLM (Amazon, Google, Anthropic, OpenAI, Microsoft) выяснилось: все они по умолчанию используют диалоги пользователей для обучения будущих версий моделей. OpenAI и Microsoft позволяют корпоративным клиентам отказаться, Google вообще не даёт чёткого механизма отказа, Anthropic и Amazon тоже используют, хотя Amazon в политике явно не пишет, но интерфейс Nova предупреждает об этом. То есть если вы не предприняли специальных действий (например, не купили бизнес-тариф с отключённым сбором), скорее всего ваши данные станут частью массива, на котором модель учится.
Чем это опасно? Тем, что спустя время модель может случайно выдать фрагменты этих данных другим пользователям. Это не теория – исследователи из Google показали, что LLM могут непреднамеренно запоминать и затем раскрывать конфиденциальную информацию из трейнинга. Также был пример: в модель Meta Imagine включили 1,1 млрд изображений с Facebook и Instagram пользователей. Если кто-то из пользователей в 2017 выкладывал фото кота, то сгенерированные моделью картинки могут случайно очень походить на того кота. С текстом аналогично: LLM могут воспроизвести кусок исходного текста, увиденного в обучении. Были показательные эксперименты, когда из GPT-2 извлекали номера социального страхования, имена, адреса, которые были в обучающих данных. Таким образом, данные клиента, отправленные сегодня, завтра могут всплыть в ответе чужому человеку. Это и есть риск “оказаться в датасете”.
Передача третьим лицам по API или по закону. Политики сервисов могут предусматривать передачу сведений подрядчикам. Например, обработку данных могут аутсорсить (расшифровка голосовых данных, модерация контента силами внешних компаний). Тогда ваши данные увидят ещё и подрядчики. Кроме того, иностранные компании могут предоставить данные правительственным органам по запросу – например, в США действует Cloud Act, позволяющий органам запрашивать данные у провайдеров. В политике OpenAI оговорено, что они могут раскрывать данные, если требуется по закону или для расследований нарушений (например, если вы ввели что-то, попадающее под проверку). Не будем далеко спекулировать, но факт остаётся: данные, переданные в чужое облако, уже не подчиняются нашей политике безопасности, а регулируются политикой провайдера.
Отсутствие прозрачности. Как пользователь сервиса, мы почти ничего не знаем о том, какие алгоритмы безопасности там стоят. Есть ли шифрование на хранении? Кто имеет доступ? Удаляются ли логи? – полной информации обычно нет, или она скрыта глубоко в технической документации. Исследование политик ИИ-гигантов показало, что общественность очень мало осведомлена, на каких конкретно данных обучены модели и что с пользовательскими диалогами происходит внутри. Карточки моделей, о которых говорилось, добровольны и поверхностны. Например, знать бы точно, удаляет ли OpenAI раз в квартал старые данные – но этого не публикуют.

Итак, данные могут выйти из-под контроля и «жить своей жизнью»: попасть в обучающий набор, сохраниться навечно на сервере, быть просмотренными людьми, переданными партнёрам или даже попасть под надзор спецслужб. К слову, недавно в совет директоров OpenAI вошёл бывший глава АНБ (Агентства нацбезопасности США). Это лишь косвенный факт, но для многих компаний он сигнализирует: доверять, что зарубежный ИИ не поделится ничем с госорганами, нельзя наивно. Эксперты отмечают, что такой шаг может повысить вероятность сотрудничества сервиса с госструктурами.

5.4. Примеры инцидентов: утечки через ChatGPT и реакции компаний

Мы уже упомянули некоторые конкретные случаи, резюмируем самые показательные:

Samsung (март 2023) – инженеры компании трижды за три недели загрузили в ChatGPT конфиденциальные данные: исходный код новой программы, записи внутренних планёрочных совещаний и техническую задачу для диагностики оборудования. Всё это стало достоянием OpenAI. Узнав об этом, руководство Samsung ввело тотальный запрет на использование внешних генеративных ИИ для рабочих нужд. Они мотивировали: данные хранятся на внешних серверах и «их легко найти, но сложно удалить». Этот случай стал хрестоматийным – его обсуждали по всему миру как пример риска необдуманного использования ИИ.
Утечка данных пользователей ChatGPT (март 2023) – ошибка в ПО OpenAI привела к тому, что некоторые пользователи видели чужие запросы и ответы в своей истории чатов. Более того, случилась утечка платежной информации части платных подписчиков. Компания признала баг и исправила его через день, но доверие было подорвано. Именно на этот эпизод ссылался регулятор Италии, обвиняя OpenAI в нарушении правил конфиденциальности. В итоге OpenAI пришлось быстро добавить уведомления о сборе данных и форму для европейцев, где они могут запретить использование своих чатов в обучении (privacy portal).
Revolut, JPMorgan, Verizon – ряд крупных западных компаний заблокировали доступ сотрудников к ChatGPT на корпоративных устройствах, опасаясь утечек. Финансовые компании особенно строги из-за комплаенс: они боятся, что работники случайно раскроют клиентские данные или инсайдерскую информацию ИИ-моделям. В России, как писали СМИ, некоторые госорганизации тоже вводили запреты для служащих обсуждать что-либо рабочее в публичных нейросетях (особенно после новостей про возможное использование ChatGPT в кибератаках).
Рекомендации Московской области (октябрь 2025) – как уже отмечалось, региональный Минуправления в сотрудничестве с Минцифры выпустил открытую рекомендацию гражданам. Это фактически признание: проблема назрела, люди активно пользуются ИИ, нужно срочно повысить цифровую грамотность. В рекомендации прямым текстом названо, что «ИИ никогда и ни при каких обстоятельствах нельзя сообщать конфиденциальную информацию, которая может быть использована против пользователя» – перечислены паспорт, ИНН, права, данные карт, пароли, контакты. Советуются даже хитрости: «при регистрации и общении с нейросетями лучше использовать вымышленные данные (например, указывать вымышленные имя, адрес)». То есть даже для частных лиц советуют маскироваться, чтобы снизить риски. Это хороший принцип и для бизнеса: если очень нужно протестировать кейс – попробуйте сначала на вымышленных данных, а не настоящих.
Слова экспертов отрасли. Евгений Осадчук (АНО «Цифровая экономика») в комментарии отметил, что помимо персональных и финансовых данных компаниям нельзя передавать ИИ и интеллектуальную собственность: алгоритмы, незапатентованные изобретения, стратегии развития – всё, что может утечь и лишить компанию эксклюзивности. Иными словами, ИИ – как дыра, сквозь которую ваши ноу-хау могут стать достоянием публики, опередив вашу патентную заявку. Другой специалист сравнил: общаясь с ChatGPT или GigaChat, представляйте, что всё написанное появляется у вас на странице в интернете. Конфиденциальности там нет, так что пишите только то, что готовы обнародовать.

Вывод из этих примеров и комментариев: риски реальны и многообразны. От прямых утечек, доступных хакерам, до постепенного расползания информации по моделям и чужим глазам. Компании, которые уже сталкивались с этим, приняли жёсткие меры (запрет, ограничение). Регуляторы усилили надзор. Поэтому для предпринимателя, желающего внедрять LLM, первая задача – минимизировать эти риски. Одно из главных средств – обезличивание данных. О нём и поговорим подробно.

6. Обезличивание (анонимизация) данных: понятия и стандарты

Обезличивание (синонимы: деперсонализация, анонимизация) – это процесс преобразования персональных данных таким образом, чтобы идентифицировать по ним конкретное лицо стало невозможным без дополнительной информации. Проще говоря, после обезличивания связь между данными и личностью разрывается. Этот механизм – ключевой для законного использования клиентских данных в исследованиях, статистике и обучении ИИ, поскольку анонимные данные уже не считаются персональными и их оборот не ограничен.

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

6.1. Обезличивание по российскому праву (деперсонализация ПДн)

В законе 152-ФЗ термин определён в статье 3 (п.9): обезличивание – это «действия, в результате которых невозможно определить принадлежность персональных данных конкретному субъекту без использования дополнительной информации». То есть убираем или изменяем идентификаторы так, что из оставшегося набора нельзя понять, о ком шла речь.

Однако долгое время эта норма была размыта, не ясно было, какие методы считать достаточными. С 1 сентября 2025 вступили поправки и подзаконные акты, внёсшие ясность:

Приказ Роскомнадзора № 140 (19.06.2025) утвердил новые требования к обезличиванию. В нём прямо сказано: обезличивание должно осуществляться «без возможности преобразования обезличенных данных к исходному виду, позволяющему определить их принадлежность конкретному субъекту ПДн». То есть никакого обратного хода быть не должно – это фактически требование полной необратимой анонимизации.
Ранее существовавшее разграничение на деперсонализацию/анонимизацию и псевдонимизацию стало чётче. ISO/IEC 29100 (международный стандарт по приватности) различает два подхода:
- Псевдонимизация – замена идентифицирующих атрибутов (имя, телефон) на псевдонимы (коды). При наличии ключа сопоставления личность можно восстановить. Стандарт прямо говорит: псевдонимизированные данные всё равно считаются персональными, просто риск утечки снижен. Пример: заменить имена клиентов номерами (ID1, ID2) и хранить отдельно таблицу соответствия. Если злоумышленник не получит таблицу, ему будет трудно понять, кто есть кто, но теоретически связь существует.
- Анонимизация – более строгий процесс, когда связь с субъектом удаляется полностью. Согласно ISO 29100, при анонимизации данные изменяются так, что обладатель информации не может определить субъект даже имея все исходные данные. Иными словами, нет ключа сопоставления, нечего восстанавливать.
Российское законодательство в обновлённой трактовке фактически приравняло обезличивание к анонимизации. То есть требование – убрать возможность идентификации даже у самого оператора, не говоря о третьих лицах. Теперь обезличенные данные = анонимные данные. А псевдонимизация рассматривается скорее как метод защиты, но не освобождающий от статуса ПДн.
В Постановлении Правительства РФ №1154 от 01.08.2025 уточнено, что результат обезличивания должен соответствовать заявленной цели и сохранять целостность данных. Это значит, что анонимные данные должны по-прежнему быть полезными (не просто стереть всё), но при этом ни в коем случае нельзя вернуть их к исходному состоянию.
Вывод: в контексте российского закона теперь обезличивание предполагает необратимость. Если ваша методика даёт шанс восстановления (например, вы заменили имя на уникальный код, зная который можно пойти в исходную базу и узнать имя) – регулятор скорее всего не признает это полноценным обезличиванием. Это останется ПДн с точки зрения контроля.

Для практических целей бизнесу это ставит задачу: превратить персональные данные в “обезличенные” так, чтобы никакой внешний наблюдатель, да и вы сами, не могли опознать личность без несоразмерных усилий. Это единственный путь свободно использовать такие данные, в том числе отправлять их внешнему ИИ.

6.2. Анонимизация vs. псевдонимизация: стандарты ISO/NIST и практические отличия

Рассмотрим подробнее различия, потому что на практике часто путают эти понятия:

Псевдонимизация – заменяем идентификаторы на другие значения, храним ключ отдельно. Примеры: вместо ФИО ставим случайный UUID; вместо телефона – строку “TEL_12345”. В базе остаются записи, у которых вроде нет прямых имен, но где-то в сейфе лежит табличка, позволяющая связать UUID обратно с ФИО. Если эта табличка защищена и не утечёт, то для постороннего данные выглядят анонимно. Однако при утечке и этой таблички – всё раскрывается. Нюанс: даже без таблички, иногда по совокупности псевдонимизированных данных можно догадаться о личности (например, уникальная комбинация “мужчина, 42 года, проживает на ул. Ленина, дом 5” – возможно, только один клиент подходит). Поэтому псевдонимизация – лишь частичная защита. ISO 29100 относит её к методам обезличивания, но подчёркивает, что псевдонимизация не снимает статуса ПДн.

Анонимизация – процесс, после которого данных, указывающих на конкретную личность, не остаётся вовсе или они настолько обобщены, что определить человека невозможно. Отличие практическое: нет секретного ключа, по которому можно всё вернуть. Если что-то и хранится для контроля качества, то это не позволит восстановить исходные ПДн. Международные стандарты (ISO, а также рекомендации NIST) вводят понятие анонимности: свойство информации, при котором идентификация субъекта исключена. NIST (Национальный институт стандартов США) выпустил в 2015 г. специальное руководство NISTIR 8053 по де-идентификации, где описал методы и подчеркнул важность оценки рисков ре-идентификации.

Простыми словами:

Псевдонимизация – “спрятать имя под ковёр, но ковёр в той же комнате”.
Анонимизация – “вынести всё, что указывает на имя, из дома и уничтожить”.

Для бизнеса это означает: если мы хотим считать данные обезличенными и свободно их использовать, нужно реализовать именно анонимизацию. Все идентификаторы удаляются или случайно перестраиваются без сохранения маппингов. Псевдонимизацию можно применять как промежуточный шаг (например, в процессе обработки), но конечный набор, отправляемый в LLM, должен быть анонимен.

6.3. Методы обезличивания: маскирование, агрегация, шифрование, дифференциальная приватность

Существует множество техник обезличивания/анонимизации. Перечислим основные, с их плюсами и минусами:

Маскирование данных (Data Masking) – замена реальных данных на вымышленные или усечённые. Бывает:
- Статическое маскирование: создаётся копия базы, где реальные значения заменены фиктивными (но правдоподобными). Например, все фамилии заменены на “Иванов”, телефоны – на “+7 (000) 000-00-00” или случайные номера из того же диапазона. Статическое маскирование необратимо, т.к. настоящих значений в копии нет. Используется для подготовки обезличенных данных, пригодных для тестирования, анализа. Это хороший способ передать набор данных разработчикам или внешнему анализатору без риска раскрытия личности.
- Динамическое маскирование: данные обезличиваются “на лету” при запросе, оригинал в базе не меняется. Например, сотрудник поддержки видит в CRM не полный паспорт клиента, а ****1234 (звёздочки скрывают часть) – то есть система маскирует поле в интерфейсе в зависимости от прав доступа. Для LLM это тоже применяется: можно настроить прокси, который при вызове API будет маскировать чувствительные детали (как мы увидим дальше).
Агрегация и обобщение – вместо конкретных значений оставляем обобщённые. Например, вместо точного возраста “34 года” указать диапазон “30-35”, вместо точного адреса “г. Казань, ул. Ленина, д.10” указать только “г. Казань”. А вместо уникального ID клиента можно, скажем, вообще не указывать ID, только суммарные показатели по группе. Обобщение снижает точность, но часто резко сокращает вероятность идентификации. Метод K-анонимности: данные группируются так, чтобы каждый записей было не менее K с одинаковым набором quasi-identifier (полуидентификаторов). Например, если K=5, можно сделать, чтобы в наборе не было уникальной комбинации “пол+возраст+город” – каждое сочетание встречалось минимум у 5 людей. Тогда внешнему наблюдателю трудно выделить конкретного человека.
Удаление/сокрытие – самый простой метод: просто убрать персональные поля. Например, удалить ФИО, телефон, email. Но тут важно не забыть и о непрямых идентификаторах: уникальный заказ №12345 тоже может быть связан только с одним клиентом, геолокация с точностью до дома тоже де-факто идентифицирует (если человек – единственный житель этого дома). Нередко компании удаляют только прямые идентификаторы и считают данные обезличенными – это ошибка, так как контекст может выдавать личность (см. разд. 6.4).
Шифрование – криптографический метод, при котором данные преобразуются по алгоритму с ключом. Если хранить зашифрованными, то без ключа они выглядят как случайный набор символов. Для обезличивания может применяться, но тут тонкость: шифрование обратимо (расшифровать же можно при наличии ключа), поэтому само по себе оно скорее метод защиты, чем анонимизации. Однако, если компания зашифровала идентификаторы и уничтожила ключ – фактически получилась необратимая анонимизация (но уничтожение ключа – фактически тот же подход, что удаление данных). Иногда делают хитрее: хранят ключ у доверенной третьей стороны, чтобы сам оператор тоже не мог легко сопоставить личность – но это уже сложные схемы.
Хэширование – одностороннее крипто-преобразование (например, SHA-256). Из хэша нельзя напрямую получить исходное значение (если алгоритм надёжен), поэтому хранить вместо паролей принято их хэши. В контексте ПДн хэширование можно применить к строковым идентификаторам: например, вместо email ivanov@mail.com хранить hash_XYZ. Однако, хэши уязвимы для перебора и атак по словарю. Если поле имеет ограниченное множество (например, СНИЛС – 11 цифр, всего 10^11 вариантов), то злоумышленник может пересчитать хэши всех вариантов и сопоставить. Поэтому хэширование надо использовать с солью (добавлять случайный секрет перед вычислением хэша). Но тогда при обезличивании мы должны забыть соль, иначе это обратимо для оператора.
Дифференциальная приватность – современный статистический метод, активно развиваемый в крупных IT. Идея: к данным добавляется случайный шум, так что невозможно с высокой точностью восстановить индивидуальную запись, но агрегированные статистики остаются верными в определённых пределах. Например, если у вас есть таблица клиентов с доходами, вы можете каждому доходу прибавить/вычесть пару случайных тысяч рублей. Анализ в целом покажет средние значения правильно, но точно сказать доход Иванова нельзя. Дифференциальная приватность даёт математически измеримую гарантию защиты (параметр ε, “эпсилон”, контролирует уровень приватности – чем меньше, тем сильнее защита, но меньше точность данных). Этот подход использовали Apple, Google для сбора телеметрии, переписи населения в США тоже применяли. Для LLM тоже возможно – добавлять шум в запросы, делая их менее конкретными. Но в бизнес-практике дифф. приватность пока редкость, требует экспертизы.
Генерация синтетических данных – создание искусственного набора, статистически похожего на реальный, но не содержащего записи об реальных людях. Например, взять датасет клиентов и сгенерировать на его основе “похожие”, но вымышленные профили (методами машинного обучения). Синтетические данные не относятся ни к кому конкретно, поэтому персональными не являются. Однако проверить, не просочились ли реальные фрагменты, сложно. Да и синтетика не всегда сохраняет всю ценность данных для анализа. Тем не менее, направление развивается – например, в маркетинге создают синтетические профили клиентов, чтобы обучать рекомендательные алгоритмы без использования реальных персональных данных.

На практике часто применяют комбинацию методов: сначала удалить прямые идентификаторы, затем маскировать некоторые поля, обобщить значения других, а оставшиеся закодировать. В Приказе РКН 2025 приведены списки методов, признанных допустимыми. Там упоминаются и шифрование, и деперсонализация через обобщение, и замещение атрибутов. Главное – чтобы в результате выполнилось требование необратимости.

6.4. Риски деанонимизации: достаточность обезличивания и примеры восстановления данных

Просто применить метод мало – нужно убедиться, что обезличивание достаточно надёжно. В противном случае данные хоть и формально “обезличены”, но кого обманываем? Умелый аналитик или алгоритм сможет сопоставить факты и вычислить личность. В чём могут быть проблемы:

Сохранение уникальных комбинаций признаков. Пример: вы убрали имена, но оставили адрес и дату рождения. Возможно, по сочетанию “родился 5 мая 1990, проживает на ул. Зеленой, д.7” – в вашем городе всего один человек подходит. Тогда данные хоть и без имени, но по сути идентифицируют того самого клиента. Реальный случай: Netflix как-то выложил обезличенные данные о том, какие рейтинги пользователи ставили фильмам (без имён, только ID). Ученые из Техасского университета смогли сопоставить эти данные с профилями на IMDb и восстановили кто какие фильмы оценивал. Урок: внешние открытые источники (OSINT) позволяют рекомбинировать информацию и “раскрывать” личности из казалось бы анонимных датасетов. Поэтому обезличивая, надо убирать или сильно размывать редкие или специфические комбинации.
Неполная маскировка. Бывает, оставляют часть поля незамаскированной “для удобства”. Например, показывают первые буквы фамилии: Иванов -> “Ив****”. Это уже дает подсказку. Или номер телефона: “+7 912 *** ** 34” – мы узнали код оператора и последние цифры, что сузило поиск. Если целью является отдать данные ИИ, то такие частичные маски больше вредят – лучше уж полностью заменить.
Фоновые знания. Тот, кто будет анализировать данные (например, ИИ), может обладать дополнительной информацией. Например, вы обезличили чат с клиентом, убрав имя, но в тексте диалога клиент упоминал “моя машина BMW X5”. Если аналитик знает, что только один клиент с BMW X5 у вас был – он догадается. Это проблема неявных идентификаторов: предпочтения, манера речи, упоминания отдельных фактов (например: “я живу возле вокзала в зеленом доме” – кажется безадресно, но в вашем городе, возможно, один зеленый дом у вокзала, и поиск по внешним данным легко найдет жильцов). Чтобы обезличивание было полным, нужно просматривать и содержимое текстов, документов – нет ли там личных деталей. Иногда приходится либо редактировать, либо вовсе не использовать слишком подробные тексты.
Атаки реидентификации растут в эффективности. С развитием ИИ стало легче сопоставлять большие объемы данных. Методы cross-correlation, кластеризация позволяют из “обезличенных” больших данных вычленять вероятных индивидов. Поэтому просто выполнить формальные требования недостаточно – нужно думать, как бы подошёл к этой задаче злоумышленник. Например, если у вас датасет покупок: дата, сумма, товар – без имён. Зная из другого источника, что клиент N покупал 5 января дорогой телевизор, можно найти в обезличенных данных транзакцию 5 января ~100k ₽ – скорее всего, это он. Дальше по этому ID транзакции проследить историю и узнать о нём ещё что-то.

В силу этого возникает парадокс анонимности: чтобы полностью исключить определяемость личности, нужно скрыть максимум деталей (до “обезличивания в ноль”), но тогда и полезность данных снижается. А если оставить хоть немного информативности, растёт риск деанонимизации. Например, переписка с клиентом: если удалить все слова, которые могут связать с человеком (имя, адрес, упоминания), возможно, текст станет мало ценным. Но если оставить смысл, контекст – возможно, по деталям можно понять, кто это (особенно если переписка уникальная).

Задача оператора – найти разумный баланс. В новом Приказе РКН есть намёк на использование “криптографических методов вычислений на данных” как будущего решения дилеммы. Речь о том, что можно анализировать данные в зашифрованном виде (например, технологии Secure Multi-party Computation, гомоморфное шифрование), чтобы не раскрывать их никому. Это перспективно, но пока сложно и редко доступно на практике.

Вывод: обезличивание – мощный инструмент, но требующий грамотного применения. Недостаточное обезличивание – это ложное чувство безопасности, чреватое нарушениями. Поэтому перед использованием обезличенных данных стоит провести оценку риска ре-идентификации: попытаться восстановить личности самим или проконсультироваться со специалистами. В идеале – соблюсти формальные критерии (к-анонимность, дифф. приватность с ε), тогда будет уверенность.

Мы подробно остановились на анонимизации, потому что именно она – ключ к легальному использованию данных в LLM. Далее, в следующем разделе, обсудим практически: можно ли после обезличивания отправлять данные в LLM, или всё равно остаются ограничения? А также что делать, если даже обезличивание нежелательно.

7. Что разрешено: передача данных в LLM по закону и на практике

Накопив понимание законодательства и методов обезличивания, ответим на главный вопрос: можно ли всё-таки отправлять клиентские данные в LLM – и в каком виде, чтобы это было законно? Здесь рассмотрим, что формально допускается законом, а также как это трактуется на практике компаниями.

7.1. Можно ли отправлять обезличенные данные в LLM (юридические аспекты)

С точки зрения закона, если данные надёжно обезличены (анонимизированы) – они перестают быть персональными. Соответственно, 152-ФЗ не распространяется на них (закон регулирует только персональные данные). Это означает:

Нет ограничений на хранение/передачу таких данных, в том числе за границу, т.к. формально это уже не ПДн.
Не нужно получать согласие субъектов на обработку анонимных данных, ведь субъект как таковой не определяется.
Можно использовать эти данные для обучения моделей ИИ, статистики и т.д. – закон это прямо поощряет (п.9 ч.1 ст.6 позволяет обрабатывать ПДн в исследовательских целях при условии обезличивания).
Можно передавать их третьим лицам (например, загружать в облачный API), не уведомляя регулятора о трансграничной передаче (поскольку официально вы не “передаёте ПДн” – это просто набор обезличенной информации).

Таким образом, обезличенные данные можно отправлять в LLM – на бумаге. Именно так многие и поступают: прежде чем отправить запрос во внешний сервис, из него вычищают все персональные сведения. В разделе 8.5 мы рассмотрим конкретно архитектуру, как компании внедряют анонимизацию на лету.

Однако, есть важное условие: обезличение должно быть полным и соответствовать требованиям. Если регулятор посчитает, что данные были обезличены ненадлежащим образом (т.е. остаётся возможность восстановления), он может квалифицировать это как несанкционированную обработку ПДн или их передачу. С 2025 года, как мы отмечали, у Роскомнадзора появились чёткие критерии (Приказ № 140, Постановление № 1154). Например, если компания заявит “мы передали только обезличенные данные”, а проверка покажет, что по ним легко найти конкретных лиц, – её привлекут к ответственности.

Поэтому на практике часто поступают так: обезличивают настолько сильно, насколько нужно для устранения идентификаторов, но данные частично остаются уникальными. Например, заменили имена на псевдоимена, но оставили содержание обращений. Формально это не 100% анонимизация (ведь псевдоимена можно вернуть при желании – значит, псевдонимизация). Однако компания может считать это допустимым компромиссом, если третья сторона (например, OpenAI) всё равно не знает, кто такие “Client123” и “Client124”.

Закон же потребует: у компании самой тоже не должно остаться способа сопоставить. То есть, если вы храните ключ “Client123 -> Иванов И.И.” и параллельно посылаете “Client123” в LLM, для регулятора это не обезличивание, а передача ПДн под псевдонимом. Такое разрешено только если выполнены условия трансграничной передачи и пр.

Впрочем, один момент: 152-ФЗ п.9 ст.6 – говорит об обязательном обезличивании при исследовательской обработке. Если строго, обучение чужой модели – это как раз исследовательская цель. Значит, должно быть обезличено. GDPR аналогично: анонимные данные – не личные. Но псевдонимизированные данные по GDPR остаются личными, хоть и подлежащими более мягкой обработке. Поэтому европейские компании, используя ИИ, тоже стараются вычищать данные или заключать жёсткие соглашения с провайдерами.

Вывод юридический: после качественной анонимизации – можно. Никаких норм, запрещающих обмен анонимной информацией с ИИ, нет. Напротив, государство заинтересовано в развитии технологий на обезличенных данных. Пример – проект “Цифровой профиль” и эксперименты в Москве: бизнес обязали предоставлять обезличенные датасеты государству для нужд ИИ. Они видят в этом пользу для экономики данных. Просто контроль за обезличиванием усиливается.

7.2. Ограничения на передачу даже обезличенных данных: формальные и фактические

Хотя закон не против обмена анонимной информацией, остаются практические ограничения:

Контрактные и этические обязательства. Даже если персональные данные убраны, информация может оставаться конфиденциальной или представлять коммерческую ценность. Например, у вас база транзакций клиентов (обезличенная – без имён). Это не ПДн, но это коммерчески чувствительные сведения: они отражают поведение клиентов, структуру продаж. Передавая их чужому ИИ, вы фактически раскрываете некоторые секреты своего бизнеса, пусть и без имён клиентов. Например, ИИ может “увидеть”, что в таком-то месяце резкий рост продаж товара X – это может знать только ваша компания, а теперь и у провайдера ИИ эти данные лежат. В политике большинства ИИ-сервисов говорится, что права на пользовательский контент остаются у пользователя (OpenAI так пишет), но компания получает лицензию на его использование. То есть вы даёте OpenAI право использовать (в том числе, как мы знаем, обучать модель) ваш контент. И если даже в контенте нет ПДн, там могут быть служебные тайны. Ваш NDA с партнёрами может запрещать разглашение определённых сведений, даже обезличенных. Например, проектная документация (без имён, но содержащая know-how). Так что обезличивание не снимает всех ограничений – только тех, что про персональные данные.
Опасение утечки контекста. Представим, вы обезличили медицинские карты пациентов (убрали ФИО, контакты). Вроде можно отдать ИИ для анализа. Но карты содержат редкие диагнозы, описание случаев. Если вдруг ИИ сгенерирует подобное описание при общении с другим человеком, тот сможет узнать чей-то медицинский случай. Да, без имени, но человек может себя узнать или знакомого (особенно если случай уникальный). Это тонкая грань: вроде ПДн нет, но privacy violation может произойти (нарушение приватности, если кто-то узнает о чьей-то болезни). GDPR, например, считает такие ситуации чувствительными. В практике был случай: алгоритм Netflix рекомендовал документалку про рак женщине, у которой была редкая форма рака – она поняла, что данные о её болезни куда-то утекли. Хотя ей никто имени не называл, сама ситуация раскрыла факт болезни.
Регуляторное недоверие. Пока не утрясётся практика, компании могут опасаться, что Роскомнадзор или суд не поверит, что данные были полностью обезличены. Будучи под инспекцией, придётся доказывать. Новый приказ требует методику и подтверждение соответствия. Возможно, в будущем будет нужна экспертиза обезличивания – т.е. заключение специалиста, что анонимизация выполнена по стандарту. Если вы просто на словах скажете “мы обезличили”, а регулятор найдет обратное, штрафы обеспечены. Поэтому, например, банковский сектор (очень осторожный) может даже запретить передачу данных в ИИ вообще, независимо от анонимизации, просто чтобы не рисковать.
Случайное включение идентификаторов. Даже при отладке процесса могут быть ошибки. Например, забыли убрать фамилию в одном поле, или ИИ по косвенным признакам вывел имя. В любом случае, человеческий фактор может привести к тому, что уйдёт лишнее.

На практике ряд компаний занимает позицию: «Даже обезличенные данные клиентов мы не хотим никуда отдавать, кроме как по требованию закона». Это позиция консервативная, но безопасная. Другие, наоборот, говорят: «Мы можем делиться агрегированными инсайтами, трендами – это не нарушает ничьих прав». Например, e-commerce может отдать ИИ-анализатору сводную статистику продаж по категориям товаров (без каких-либо данных о конкретных покупателях) – это действительно безопасно и законно.

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

7.3. Требуется ли согласие клиента или иной правовой базис для использования данных в LLM

Если вы всё же хотите использовать необезличенные персональные данные в LLM (что крайне нежелательно), единственный шанс легально – это наличие соответствующего согласия клиента или иного основания. Рассмотрим:

Согласие субъекта ПДн. Теоретически, можно включить в пользовательское соглашение пункт: “клиент разрешает компании передавать его персональные данные на обработку в автоматизированные системы партнеров, включая сервисы искусственного интеллекта, с целью такой-то (например, для предоставления ответов на запросы клиента)”. Если клиент явно и информированно согласился, то по 152-ФЗ обработка допустима. Но! Согласие должно быть конкретным и информированным. Что вы напишете? “...в сторонние сервисы типа ChatGPT (OpenAI, США)” – клиент может испугаться и не дать согласие. Кроме того, согласие не освобождает от обязанности обеспечить безопасность. Если данные утекут, клиент может отозвать согласие и подать иск, что вы не обеспечили сохранность. Согласие – не индульгенция от утечки. Поэтому полагаться на согласие как защиту – слабая позиция.
Договорное основание. Некоторые виды обработки можно обосновать необходимостью исполнения договора с субъектом. Например, клиент спросил вопрос – компания чтобы ответить использует ИИ, это мол для исполнения услуги консультации. Но это притянуто за уши. Более корректно: если клиент сам общается с ИИ (например, чат-бот на сайте, где написано, что он работает на базе внешнего ИИ), то отправка его данных – часть сервиса, и можно прописать в оферте. Однако, опять же, нужно раскрыть риски. Плюс иностранный сервис – трансграничная передача, тут договор не поможет обойти требование про адекватную защиту за рубежом.
Обезличивание как условие. Как отмечалось, закон прямо требует обезличивать для исследований. То есть без обезличивания – нельзя, даже с согласием, если это просто “для лучшего ответа”. Исключение – если действительно нужно человеку ответ дать только персонализировав, тогда лучше не звать внешний ИИ, а делать это вручную или локально.
Исключения. Если вдруг у вас случай, подпадающий под исключения ст.6 (например, данные общедоступные, или нужна защита жизни – маловероятно применимо к LLM), тогда можно. Но такие экзотические основания вряд ли подходят для бизнес-задач.

Прецедентных примеров нет: пока ни одна компания явно не афишировала “мы собираем согласия и отправляем ПДн клиентов в ChatGPT”. Скорее всего, юристы всех крупных компаний советуют так не делать. Даже если клиент вдруг дал согласие, завтра он может передумать – надо будет удалять всё у OpenAI, что невозможно.

Рекомендация: избегать использования неанонимизированных данных в LLM вообще. Исключение – когда данные сами по себе не персональные или вы работаете строго внутри РФ с провайдером, с которым заключён договор и всё согласно 152-ФЗ (например, российский облачный провайдер с удостоверением на хранение ПДн). Тогда хотя бы трансгранички нет, и договором можно оговорить защиту. Но и в этом случае лучше информировать клиентов в политике, что вы привлекаете AI-сервисы (без деталей, но чтобы не было сюрпризом).

Подведём итог этого раздела: отправлять клиентские данные можно только либо в анонимном виде, либо не отправлять вовсе – всё остальное слишком рискованно юридически. Теперь, исходя из этого, давайте рассмотрим доступные альтернативы: как ещё можно пользоваться LLM и AI-технологиями, не нарушая приватность. Это будет полезно тем, кто не хочет полностью отказываться от преимуществ ИИ, но и не готов жертвовать данными.

8. Альтернативы: как работать с LLM, не нарушая конфиденциальность

Есть несколько стратегий, позволяющих бизнесу применять возможности LLM с минимальным риском для данных. Ниже разберём эти подходы, от полного контроля (самостоятельное развёртывание) до компромиссных решений (анонимизация, доверенные сервисы). Также приведём сравнительную таблицу, чтобы наглядно увидеть плюсы и минусы.

8.1. Self-hosted LLM (развёртывание модели на своей инфраструктуре)

Self-hosted LLM – это когда компания сама разворачивает модель на своих серверах (локальных или в закрытом облаке), и все данные обрабатываются внутри, не выходя во внешний мир. Это наилучший вариант с точки зрения конфиденциальности: данные остаются под полным контролем компании.

Что для этого нужно: либо использовать доступные открытые модели, либо приобрести коммерческую версию модели для on-premises установки. Благо, после выхода LLaMA от Meta (2023) появилось множество открытых моделей отличного качества (Llama-2, Falcon, GPT-J, RuGPT3, Сберевские модели и т.д.). Их можно запустить на своих серверах или мощных рабочих станциях. Например, Llama-2 13B способна выполнять многие задачи, её можно развернуть в SberCloud или Яндекс Облаке в изолированном контуре.

Плюсы self-hosting:

Данные никуда не уходят, нет трансграничной передачи.
Не нужно беспокоиться о политике чужого сервиса – вы сами себе хозяин.
Можно донастраивать модель под себя (fine-tune) без опасения утечки.
Соответствие 152-ФЗ легче обеспечить: данные в вашей ИСПДн, можно сертифицировать систему по требованиям безопасности ПДн.

Минусы:

Требуется мощное оборудование (GPU) и специалисты, которые смогут развернуть и поддерживать модель. LLM большие – например, 13-миллиардная модель требует десятки гигабайт памяти GPU. Для качеств GPT-4 открытых аналогов пока нет, приходится мириться с меньшей мощностью.
Обновление и поддержка – на вас. Внешние сервисы постоянно улучшаются, а локально вы застрянете на текущей версии, если не вкладываться в обновления.
Некоторые задачи (например, сложная генерация кода) могут быть не по силам небольшим моделям. То есть возможна потеря качества.

Тем не менее, многие крупные компании идут этим путём. Например, Сбер для себя развивает GigaChat и внутренние модели – очевидно, ни Сбербанк, ни др. банки не отправляют клиентские данные в ChatGPT, они используют свои ИИ (пусть и менее мощные пока). Just AI отмечает: у заказчиков запрос “модель должна крутиться локально (on-premises)” встречается очень часто. Это отражает общий тренд: бизнес предпочитает private AI, даже если это дороже и сложнее, ради гарантий безопасности.

8.2. Тонкая настройка (fine-tuning) моделей на обезличенных данных

Близкий к self-hosted вариант – fine-tuning. Это когда берут предобученную модель (например, ту же Llama-2 или YandexGPT) и дообучают её на своих данных, чтобы она лучше решала специфичные задачи. Fine-tuning можно делать либо тоже на своей инфраструктуре, либо у доверенного провайдера, но важно, что для обучения лучше использовать обезличенные или синтетические данные.

Например, вы хотите обучить модель отвечать на вопросы ваших клиентов. Можно взять переписку прошлых обращений в поддержку и дообучить модель. Но переписка содержит имена, контакты, детали заказов – перед training набор нужно почистить: заменить имена на нейтральные (“Иванов”->“<NAME>”), удалить адреса или заменить на шаблон (“г.<CITY>”), и т.д. В итоге модель научится правильным ответам, но не запомнит личные сведения, т.к. их в датасете не будет.

Преимущества fine-tuned модели:

Она обучена именно на вашем домене, отвечает с учётом специфики продукта. Это лучше, чем звать внешний универсальный ИИ, который может ошибаться в ваших реалиях.
Модель после обучения может работать офлайн (опять же, без передачи данных наружу).
Обезличивание исходных данных перед обучением защитит от того, что модель “протечёт” секретами. К тому же, в offline модели никто не будет копаться извне.

Недостатки:

Обучение – затратный процесс (нужны мощные GPU, много времени). Особенно если модель большая.
Не каждая открытая модель поддаётся качественной донастройке без деградации – нужен ML-специалист, гипер-параметры подобрать, датасет подготовить.
Каждый раз при существенном обновлении данных придётся снова обучать или дообучать.
И всё равно база модели – открытая (возможно, она сама содержала что-то из интернета лишнее). Но тут уж мы немного доверяем разработчику, что он почистил training data.

Fine-tuning – популярный подход, его предлагают и облачные провайдеры (типа Amazon Bedrock или СберCloud ML Space). Но с точки зрения конфиденциальности, лучше делать это либо on-prem, либо в сертифицированном облаке в РФ.

8.3. Локальный inference: использование локальных моделей без отправки данных

Если не тянуть на себя тяжёлую инфраструктуру, есть и промежуточный вариант: локальный inference с помощью оптимизированных моделей на CPU. Существуют урезанные версии LLM (quantized), которые способны работать на обычных ПК или серверных CPU без GPU, пусть медленнее. Например, Llama-2 в 4-битном квантовании запускают на компьютерах с 16 ГБ RAM. Есть проекты вроде GPT4All, позволяющие скачать ассистента и запускать локально на ноутбуке.

Для бизнеса это вариант: встроить локальную LLM в приложение, чтобы она обрабатывала данные, не обращаясь к API. Например, система документооборота может содержать модуль AI, который резюмирует документ. Если там стоит локальная модель, документ никуда не уходит.

Плюсы:

Полная автономность. Работает даже офлайн.
Нет внешних расходов на API (которые у OpenAI могут значительными быть).
Контроль над тем, что модель делает – можно интегрировать логику, ограничивать выходы и т.п.

Минусы:

Скорость и мощность ограничены. На CPU модель генерирует медленнее, чем в облаке на GPU.
Качество может быть ниже, особенно если модель сильно ужата.
Ограниченный контекст: мелкие модели не могут держать в уме большие документы, в отличие от GPT-4 с контекстом 32k токенов.

Тем не менее, для многих задач (короткие ответы, классификация, извлечение информации) локальные модели подходят. По крайней мере, для начала внедрения ИИ стоит попробовать open-source модель на тестовых данных: оценить, справляется ли она. Часто оказывается, что на 80% задач хватает и её, а 20% требуют что-то серьёзнее.

8.4. Российские API и решения с гарантией конфиденциальности (пример: GigaChat, Яндекс)

Если нужен всё-таки мощный ИИ, сравнимый с зарубежным, но нельзя передавать данные за рубеж, логично рассмотреть отечественные сервисы. В России и дружественных юрисдикциях появились LLM-API, позиционирующиеся как соответствующие требованиям локальных законов:

Сбер GigaChat API – Сбербанк обещал открыть API к GigaChat. Пока (конец 2025) он есть в тестовом режиме. Сбер заявляет особое внимание безопасности в своей LLM. Вероятно, использование GigaChat через SberCloud будет соответствовать 152-ФЗ: дата-центры Сбера в РФ сертифицированы, есть облако для ПДн (УЗ-1). Можно заключить с Сбербанк-Сервис договор обработки ПДн (как с любым аутсорсером ИТ). В таком случае передача данных Сберу – это не трансграничка и не разглашение третьей стороне, а поручение обработки (ст.6 ч.3 152-ФЗ) – закон позволяет передавать ПДн обработчику по договору. Конечно, обработчик обязан соблюдать конфиденциальность и меры защиты. Сбер – организация доверенная (крупный игрок, ответственность понимает). Так что вариант: использовать российский облачный LLM-сервис и оформить всё документально (договор, гарантия, что данные не утекут).
Яндекс GPT – Яндекс недавно открыл доступ к YandexGPT 5.1 Pro. Можно попробовать через API, либо через облако Яндекс. Ситуация похожа: Яндекс – резидент РФ, выполняет закон о ПДн (хранит всё на российских серверах). Заключив договор, можно легально обрабатывать ПДн через сервис Яндекса. Насколько сама модель мощна – время покажет, но в задачах на русском она, возможно, лучше понимает контекст локальный (как заявлялось, у российских LLM меньше галлюцинаций по юридическим нюансам РФ).
Sputnik, Silero, etc. – Есть и другие решения: например, “Спутник” от Rostelecom (бывший проект по поисковику, возможно, у них есть AI), модели от AI-институтов. Если они доступны, их плюс – они гарантированно подчиняются нашим законам или могут быть развёрнуты внутри страны.

Преимущества российских сервисов:

Соответствие ФЗ-152 (данные остаются в РФ, есть возможность контроля).
Локализация по языку и культуре – иногда ChatGPT делает ошибки в реалиях РФ, отечественная модель может быть лучше натренирована на российских данных (законы, именования).
Вы поддерживаете местный AI-бизнес, что в условиях геополитики тоже аргумент.

Недостатки:

Пока качество может уступать мировым лидерам. По независимым тестам, GigaChat 2.0 и YandexGPT хоть и прогрессируют, но “уступают топовым западным или китайским LLM”. Однако, для многих рутинных задач их хватит.
Ограничения по доступу – нужен контракт, аккаунт в облаке, часто закрытый предпросмотр.
Масштаб и дополнительные функции: у зарубежных моделей экосистема богаче (плагины, интеграции). У наших – пока минимальный API.

Тем не менее, для многих компаний российские LLM – оптимальный выбор: с минимальным юридическим риском. Например, государственным организациям, очевидно, запрещено грузить данные граждан в иностранные сервисы – они предпочитают отечественные разработки или open-source on-prem.

8.5. Промежуточные решения: прокси-анонимайзеры, шифрование, доверенная среда выполнения

Существуют гибридные подходы, позволяющие использовать мощь внешних моделей, но не раскрывать реальные данные. Один из таких – внедрение специального прокси-сервера для динамической анонимизации.

Как это работает: между вашим приложением и внешним LLM API ставится прокси, который перехватывает запросы сотрудников и вычищает из них все чувствительные данные на лету. Шаги мы частично упоминали:

Перехват запроса: пользователь вбивает, например, “Сгенерируй письмо клиенту Иванову Ивану по договору №123 о продлении”. Прокси ловит этот текст до отправки.
Обнаружение PII: прокси с помощью правил и моделей NER находит персональные данные и конфиденциальные фрагменты – “Иванову Ивану”, “договор №123”.
Трансформация: все найденные фрагменты заменяются на метки-плейсхолдеры, а соответствия сохраняются во внутренней таблице сопоставления. Например, “Иванову Ивану” -> <NAME1>, договор №123 -> <DOC1>.
Безопасная отправка: очищенный запрос (“Сгенерируй письмо клиенту <NAME1> по <DOC1> о продлении”) уходит во внешний LLM. Внешняя модель не видит реальных имён – для неё это абстракции.
Деанонимизация ответа: ответ от LLM приходит с теми же метками. Прокси берет исходные значения из таблицы и подставляет их обратно вместо меток. Пользователь получает осмысленный ответ уже с реальными именами, даже не подозревая, что на самом деле ИИ обрабатывал искажённый запрос.

Такой подход описан, например, в решении Jay Guard от Just AI. Они сделали прокси-“охранника”, работающего с популярными моделями (ChatGPT, GPT-4, Claude, Google Gemini), а также умеющего с российскими (YandexGPT, Sber GigaChat). То есть универсальный фильтр.

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

Пример архитектуры с анонимизирующим прокси-шлюзом (промежуточный сервер), защищающим данные при обращении к внешнему ИИ-сервису:

Рис. 1: Схема динамической анонимизации данных при запросе к внешнему LLM. Прокси фильтрует чувствительные данные, заменяя их метками, а после получения ответа подставляет оригинальные значения обратно.

Другой подход – шифрование данных перед отправкой. Вариант: поля, которые не критичны для обработки, но содержат личное, можно зашифровать. Например, вы отправляете модель обучаться на email-переписках, можно все email-адреса зашифровать симметрично. Модель увидит нечитаемые строчки и не сможет их осмысленно использовать. Но пользы от них и так нет. Правда, если потом ответ модели нужно расшифровать – придётся ключ держать. Обычно проще заменить на метки, чем шифровать (шифрование имеет смысл, если нужно сохранить строгий формат или не палить даже длину строки).

Также появляются идеи конфиденциальных вычислений: запускать LLM в Trusted Execution Environment (TEE) – то есть даже если модель в облаке, она работает в зашифрованной памяти и данные видны только внутри зашифрованного контейнера. Клиент загружает данные в шифровке, ИИ там как-то их обрабатывает (возможно, с гомоморфным шифрованием), и выдаёт результат, не “увидев” сами данные. Такие технологии ещё очень экспериментальны (например, проект МТС “Купер” для безопасных вычислений). Пока они не применяются массово, но через несколько лет, возможно, будут.

Итог: прокси-анонимизация – уже реально работающий компромиссный инструмент. Он позволяет компаниям пользоваться топовыми моделями ИИ (которые доступны только через API), не раскрывая конфиденциальную информацию. Конечно, надо правильно настроить словари, шаблоны (как находить все номера телефонов, все ФИО в тексте – задача нетривиальная). Но Just AI и другие уже наработали решения. Важно, что такой прокси – не панацея: он снижает риски утечки персональных данных, но всё же не убирает риск утечки обезличенных сведений. Плюс нельзя исключать, что какая-то непризнанная сущность просочится (напр. редкое имя, которое NER не распознал). Поэтому прокси – часть комплексной системы защиты, как отмечают авторы Jay Guard.

Ниже предлагаем таблицу, суммирующую рассмотренные альтернативы:

8.6. Таблица: Обзор альтернативных решений и их характеристиками

РешениеГде обрабатываются данныеКонтроль и безопасностьПримеры/инструментыОсобенности
Self-hosted LLM (On-Premises)	На собственных серверах компании (в РФ)	Полный контроль; данные не покидают контур организации. Требует мощного железа, экспертизы	Llama-2, GPT-J, RuGPT3 на своих серверах; Enterprise версии GPT для on-prem	+ Конфиденциальность, комплаенс	+ Нет зависимости от внешних сервисов	- Высокие затраты на развёртывание и поддержку	- Качество зависит от выбранной модели (может уступать SOTA)
Fine-tuning локальной модели	Обучение на своих данных (обезличенных), далее запуск on-prem	Данные подготовки можно обезличить; итоговая модель хранится у компании.	Обучение Llama-2 на клиентских запросах; AutoML для текста (пример – Sber AI Cloud fine-tuning)	+ Модель адаптирована под задачи компании	+ Не делимся данными с кем-либо	- Нужны ML-специалисты, вычислительные ресурсы	- Риск перетренировки или утечки паттернов, если плохо обезличить данные
Локальный inference (desktop/edge AI)	На устройствах или локальных серверах (возможно, CPU)	Данные не отправляются в сеть, вычисления локально.	GPT4All, Local LLM (например, RWKV, Mistral 7B) на рабочих станциях	+ Максимальная автономность	+ Низкие требования к комплаенсу (нет обмена данными)	- Ограниченная производительность и контекст	- Подходит для простых задач или малых объёмов данных
Российские облачные LLM-сервисы	В дата-центрах РФ (облако провайдера)	Данные остаются в РФ; можно заключить договор Оператора-Обработчика с провайдером.	API Сбер GigaChat, Яндекс GPT, Huawei (Астра) и др.	+ Соответствие 152-ФЗ и локализации	+ Меньший риск вмешательства иностранных органов	- Качество моделей может быть ниже лидеров	- Требует доверия к провайдеру (хотя и юридически подкреплено)
Прокси-анонимайзер + внешний LLM	Обработка в внешнем LLM (зарубеж), но после анонимизации через локальный прокси	Реальные ПДн не выходят наружу; внешний сервис получает только обобщённые/замаскированные данные.	Just AI JayGuard (анонимизация перед GPT-4, Claude и т.д.); самописные прокси с NER (SpaCy) + RegEx	+ Использование самых мощных ИИ с минимальным риском утечки ПДн	+ Не требует своего GPU – используем облачный	- Сложность настройки (надо постоянно поддерживать словари и алгоритмы маскировки)	- Внешний сервис всё равно видит обезличенные, но конфиденциальные данные (напр., тексты обращений без имён)
Шифрование/TEE при использовании внешнего LLM	Внешний LLM (зарубеж) – данные отправляются зашифрованно либо обрабатываются в защищённой среде	Экспериментальные методы: провайдер не видит открытые данные, работает вслепую или в безопасном контейнере.	Механизмы конфиденциальных вычислений (гомоморфное шифрование, Secure Enclave); проектов пока мало в продакшене.	+ Теоретически наивысшая приватность (даже провайдер не узнает данных)	- Пока в стадии исследований / ограниченных пилотов	- Существенно медленнее и сложнее, чем обычная обработка

(Примечание: при любом варианте рекомендуется заключать необходимые договоры о неразглашении, обрабатывать только необходимый минимум данных и соблюдать внутренние политики ИБ.)

Таблица показывает, что альтернатива прямому использованию ChatGPT с сырыми данными есть – от простого “делай всё сам” до хитрого “пусть ChatGPT работает, но ничего личного ему не скажем”. Выбор зависит от возможностей компании: есть ли ресурсы на свою инфраструктуру, насколько критична точность ответов, и конечно, сколько риска приемлемо.

Для малого бизнеса, возможно, оптимально ограничиться российскими или open-source решениями. Для крупного – вложиться в собственную AI-платформу или купить enterprise-версию западных моделей, но в изолированном режиме. Кстати, Microsoft предлагает продукт Azure OpenAI – модель GPT-4 в приватном клауде Azure, где гарантируют, что данные клиента не идут в общую модель. Но это всё равно зарубежный облако, правда под договором с Microsoft (которая в РФ сейчас не работает, увы).

В завершение обзора технологий отметим: безопасность – это процесс. Любое решение требует сопровождения: обновлять модели (чтобы не было уязвимостей), мониторить, какие данные в них попадают, контролировать доступ сотрудников. Об этом – в следующем разделе, посвящённом практическим рекомендациям.

9. Практические рекомендации по минимизации рисков

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

9.1. Политики и регламенты внутри компании: что прописать и внедрить

Первое, с чего стоит начать – это создание внутренних политик по использованию AI. Как когда-то вводили политики информационной безопасности, теперь необходимо добавить раздел про ИИ (или отдельный документ).

Что должно быть в такой политике:

Запрет или ограничения на ввод конфиденциальной информации в несанкционированные ИИ-сервисы. Прямо пропишите: «Запрещено использовать публичные нейросети (ChatGPT, Bing AI, и т.п.) для обработки следующей информации: персональные данные клиентов, коммерческая тайна, финансово-правовые документы компании, исходные коды проектов...». Для особо чувствительных отделов, возможно, полный запрет на использование внешних ИИ в работе. Такая политика может быть жесткой, но необходимой – как отметили в Лаборатории Касперского, для сильно зарегулированных отраслей или департаментов с особыми данными это единственный вариант.
Разрешённые инструменты. Если компания внедрила свой безопасный инструмент (например, корпоративный чат-бот на основе локальной модели), то в политике указать: «Для задач X следует использовать только одобренное решение Y. Использование любых сторонних AI-инструментов для этих задач запрещено.». Некоторые организации создают список разрешённых AI-сервисов (whitelist).
Классификация данных и режимы. Хорошей практикой будет определить категории данных и соответствующий режим использования ИИ. Например: публичные данные – можно в любой ИИ (например, тексты пресс-релизов); внутренние несекретные – можно в утверждённые ИИ-сервисы; конфиденциальные – только во внутренние модели; секретные – никакого ИИ. Эту матрицу стоит формализовать. В Касперском предлагают сделать политику, которая «предусматривает разные режимы применения ИИ для разных видов данных» – наиболее универсальный подход.
Процедура одобрения исключений. Может возникнуть ситуация: сотруднику очень нужно прогнать что-то через ChatGPT (например, код для отладки), а формально это запрещено, но нет другого выхода сейчас. Надо предусмотреть: возможно, через запрос ИБ-отделу или руководителю отдела с обоснованием. Тогда будет контролируемое исключение. Политика должна описывать, как такие запросы рассматриваются.
Обязанность обезличивать перед отправкой. Если всё-таки допускается использование внешних ИИ для некоторых данных, пропишите требование: «Перед отправкой любой информации, содержащей сведения о клиентах или о компании, сотрудник обязан удалить или изменить эти сведения (обезличить)». То есть обучить людей вручную замазывать упоминания имён, контактов. Можно даже пример: было: “Напиши письмо для Иванова с предложением скидки 10% на товар Z”, отправлять: “Напиши письмо для <клиента> с предложением скидки...”. Да, человек – не алгоритм, может ошибиться, но хотя бы регламент обязывает задуматься.
Учет использования ИИ. Полезно ввести правило: сотрудники должны сообщать, какие AI-инструменты они используют в работе, хотя бы для оценки рисков. Возможно, создать реестр таких случаев.
Санкции за нарушение. Чтобы политика не осталась на бумаге, необходимо обозначить ответственность. Например, нарушение запрета (например, загрузка клиентской базы в чат-бот) = дисциплинарное взыскание, вплоть до увольнения за грубое нарушение (как Samsung объявила). Конечно, применять по ситуации, но предупреждён – значит, по идее, подумает дважды.

В целом политика должна «охватывать разные департаменты и виды информации», быть подробной, и регулярно пересматриваться, потому что технологии меняются. Кстати, её можно включить в общую Политику обработки ПДн, сделав раздел о применении ИИ – тогда и клиентам в публичной политике будет прозрачно, что вы аккуратно подходите к вопросу. Как советуют специалисты, сейчас «это минимальный набор требований для любой компании, работающей с ПДн… игнорирование грозит штрафами…».

9.2. Обучение сотрудников: цифровая гигиена и осведомлённость о рисках ИИ

Даже лучшая политика не сработает, если сотрудники о ней не знают или не понимают её важности. Поэтому обучение и коммуникация – ключевые элементы.

Что нужно сделать:

Провести тренинг/семинар для персонала о рисках, связанных с использованием ИИ. Объяснить доступно, к чему может привести ввод конфиденциальных данных в публичный сервис: утечки, штрафы, увольнения. Привести примеры (Samsung, утечки и т.д., благо материалов достаточно). В Касперском отмечают, что «в первую очередь это обучение сотрудников тому, какие риски несёт ИИ: от утечек данных до галлюцинаций и промпт-инъекций», и его должны пройти все.
Разослать памятки/напоминания. Например, плакат или PDF: «Никогда не вводи в ChatGPT то, что не готов опубликовать публично!» – это красной нитью должно войти в привычку. Московская область для граждан так и сформулировала: «общайся с ИИ, как будто всё увидят другие». Для сотрудников можно добавить: «Учти, всё, что ты отправил внешнему ИИ, навсегда покидает наш защищённый периметр».
Специальное обучение для руководителей и IT. Менеджеры отделов должны уметь оценивать запросы подчинённых: стоит ли разрешить тот или иной кейс использования ИИ. А специалисты IT/безопасности – понимать технические меры, про которые мы говорили (анонимизация, прокси и т.п.). Возможно, стоит назначить ответственного по AI-комплаенсу, кто будет консультировать коллег.
Регулярность и обновление знаний. В сфере кибербезопасности давно поняли: одноразовой лекции недостаточно, нужно регулярно повторять. То же с ИИ – включить темы по приватности данных в ежегодные курсы ИБ, добавлять новые кейсы. Касперский советует «регулярную коррекцию мер и политики по мере изменения сценариев применения ИИ». Хорошо бы, чтобы сотрудники и сами делились: “нашли новый AI-сервис, можно ли его использовать?” – чтобы формировалась культура осознанного подхода, а не подпольное использование (Shadow AI).
Вовлечь сотрудников. Если просто всё запретить, они могут начать скрывать использование (как люди ставят торренты вопреки запретам). Лучше объяснить, где ИИ реально поможет им в работе безопасно (например, дать внутренний инструмент). И акцентировать внимание на этике: не только штрафы, но и ответственность перед клиентами. Мол, “наши клиенты доверяют нам свои данные, а мы не имеем права их бездумно сливать”.

Важно именно донести, что риски – не абстракция. Как сказал один CEO: «утечка – это не проблема больших, это угроза лично для каждого предпринимателя». Так и для каждого сотрудника угроза потерять работу или нанести вред компании. Обучение должно переводить это из области теории в практику: например, смоделировать ситуацию: “вот ты ввёл запрос с такими-то данными, через месяц эти данные всплыли в чужом ответе – клиент узнал, что мы разгласили… Представь реакцию”. Такие упражнения могут прочно закрепить осторожность.

9.3. Технические меры: ограничение доступа, DLP, мониторинг использования ИИ

Одними политиками и обучением нельзя закрыть вопрос – нужны и технологические барьеры, чтобы минимизировать человеческий фактор:

Ограничить доступ к внешним ИИ-сервисам на корпоративных сетях/устройствах. Можно на уровне сетевого экрана блокировать обращения к известным API (api.openai.com и др.), либо наоборот, разрешать только определённым прокси. Samsung, как мы видели, заблокировал на рабочих устройствах все подобные сервисы. Это крайний шаг, но для организаций с повышенными требованиями (банк, госструктура) – оправдано. Другой вариант – запретить установку ПО типа десктопных AI-приложений (через group policy).
Политика на устройства (MDM): если компания выдаёт ноутбуки/смартфоны, настроить MDM так, чтобы на них нельзя было ставить произвольные AI-приложения, а веб-доступ к ним ограничен. Также запретить использование личных устройств для рабочих задач, чтобы сотрудник не обходил ограничения.
Data Loss Prevention (DLP) системы**. Современные DLP умеют ловить отправку конфиденциальной инфы в интернет – обычно это про email/мессенджеры, но их можно научить и про веб-запросы. Если DLP увидит, что на сайт chat.openai.com отправляется текст, содержащий, например, 16 цифр как у номера карты, она может заблокировать и оповестить безопасников. Конечно, DLP надо настроить под шаблоны ПДн, коммерческой тайны. Это сложный и не дешёвый инструмент, но для крупных компаний полезно иметь. По крайней мере, если кто-то нарушит, DLP зафиксирует факт (доказательство для разбирательства).
Журналирование и анализ логов. Если используете корпоративный прокси или свое AI-решение, логируйте обращения. Можно анонимно, не чтобы шпионить, а чтобы выявлять потенциально опасные – напр, сотрудник попытался вбить паспортные данные. Затем с ним индивидуально провести беседу.
Контроль доступа по ролям. В политике Касперского предлагается продумать «ролевую модель для применения нужной ИБ-политики». То есть кто-то может иметь исключения, кому-то вообще нельзя по должности. Например, ИТ-разработчикам можно разрешить использовать Codex (GitHub Copilot) для несекретного кода, но финансистам – запретить использование ChatGPT для подготовки отчётов с персональными данными сотрудников. Реализовать через разграничение прав: например, у разработчиков есть доступ к интернету на domains X,Y, у финансистов нет.
Безопасная среда для экспериментов. Если компания всё же заинтересована в экспериментах с внешними ИИ (для исследований), можно создать изолированную среду (песочницу): отдельный компьютер/виртуалку без доступа к реальным данным, где сотрудники могут “поиграться” с ChatGPT только на выдуманных или публичных данных. Чтобы они не делали это на основной системе.
Шифрование баз данных и каналов. Это общее требование 152-ФЗ – если всё же какие-то данные передаются (например, между вашим сервисом и прокси-анонимайзером), используйте шифрование каналов (TLS), храните ключи надёжно. Тогда даже при компрометации канала злоумышленник не получит открытые данные. Безопасность инфраструктуры – основа, её нельзя забывать.

Конечно, нулевого риска не будет: самый слабый элемент – человек. Поэтому и комбинируем: научить -> запретить где нужно -> поставить фильтры -> проверять логи. Такая “многоступенчатая система реагирования” упоминается и экспертами.

9.4. Как безопасно экспериментировать с LLM в бизнесе

Многие предприниматели читают про ИИ и хотят сразу попробовать, где он может помочь в их бизнес-процессах. Желание правильное – технология перспективна. Вот небольшой совет пошагово, как внедрять LLM-проекты, минимизируя риски:

Идея и оценка данных: Решите, для какой задачи хотите использовать LLM (например, авто-ответы клиентам, анализ отзывов, генерация маркетинг-текста). Для этой задачи оцените: какие данные нужны модели? Это публичные сведения или данные клиентов? Если последние – насколько они чувствительны? На этом шаге сразу решите: “можем ли мы обезличить эти данные и модель всё равно выполнит задачу?”. Если да – отлично, планируйте обезличивание. Если нет (например, задача – персонализированный совет клиенту) – тогда, вероятно, надо искать решение через внутреннюю модель, т.к. внешней не доверить.
Выбор решения: из рассмотренных альтернатив выберите подходящий. Для начала, часто есть смысл попробовать open-source модель на тестовых данных. Это позволит “не светить” данные и понять, а нужна ли вообще топ-модель. Если результат плох – подумать о fine-tuning или о коммерческой модели. Если решаете пользоваться API, узнайте у провайдера: как они хранят данные, есть ли настройки приватности. Например, у OpenAI API можно включить режим без сохранения данных на обучение, у Anthropic Claude by default не учится на вводимых данных. Возможно, имеет смысл платить за enterprise-тариф, где данные не собираются для обучения (OpenAI предлагает для корпоративных клиентов полную изоляцию).
Юридическое оформление: Обновите свою Политику конфиденциальности (публичную) – добавьте пункт, что используете такие-то технологии, возможно передачу обезличенных данных с такой целью. Чтобы клиенты не были ошарашены. Проверьте договор с внешним провайдером: заключите DPA (Data Processing Addendum) если нужно, убедитесь, что ответственность оговорена. Если российский – впишите условия 152-ФЗ (как в ч.3 ст.6 – что обработчик обязуется защищать, уведомлять об инцидентах и т.п.). Если open-source – лицензии, чтобы можно было коммерчески использовать (многие разрешают).
Тестирование с псевдоданными: Никогда не запускайте сразу на боевых данных. Сделайте выборку, обезличьте, или даже сгенерите данных-двойников (если возможно) и прогоните процесс. Убедитесь, что нигде PII не проскакивает, что модель не отвечает странным раскрытием (например, вы ей обезличенный адрес дали, а она вдруг вернула реально существующий – значит где-то утечка). Проверьте логи – нигде нет явных ПДн.
Поэтапное развёртывание: Внедряйте постепенно. Скажем, сперва новый AI-модуль работает только в тестовом окружении или на малом проценте запросов. Следите за его выводом. Возможно, стоит устроить red-teaming – специально попытаться “взломать” систему, запросив у модели что-то вроде: “покажи необрезанные данные, которые тебе прислали” (если она хоть что-то раскроет – дыра!). Есть компании, которые специализируются на тестировании безопасности LLM (например, llmarena).
Сбор обратной связи: Поговорите с сотрудниками, задействованными в процессе: удобно ли им с новой системой, не ищут ли они обходных путей. Если система слишком строгая (например, прокси-анонимайзер иногда чрезмерно маскирует и ухудшает ответы), может они будут отключать его. Нужно балансировать настройки и слушать пользователей.
Мониторинг и аудит: После запуска регулярно проверяйте, как система функционирует. Анализируйте, нет ли утечек (DLP, отзывы клиентов – вдруг кто-то скажет “мне ИИ-бот выдал мои же персональные данные ошибочно” – такое тоже может быть). Проводите аудит обезличивания (соответствует ли новым требованиям РКН с 2025, может, поменять метод). Готовьтесь к тому, что придёт проверка – держите документы (политики, приказы, договоры) в порядке.

Следуя таким шагам, можно получить выгоду от LLM и не переступить черту безопасности. Ключевое – осознанность на каждом этапе: понимать, какие данные куда идут и зачем, и чем это чревато.

10. Заключение

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

Мы рассмотрели, что при грамотном подходе LLM можно интегрировать в бизнес-процессы:

Понимая категории данных и защищая самые чувствительные (персональные, тайну) от попадания наружу.
Соблюдая требования законодательства РФ (152-ФЗ и др.): либо обезличивая данные перед использованием в ИИ, либо храня их и обрабатывая в пределах России, под контролем договоров с провайдерами.
Учитывая международные нормы, если ваш бизнес глобальный – избегая сценариев, которые могут нарушить GDPR или вызвать вопросы иностранных регуляторов.
Применяя технические решения: от локальных развертываний LLM до прокси-фильтрации запросов, чтобы черпать пользу из мощных моделей, но не выдавать им секреты.
Выбирая альтернативы в зависимости от возможностей: свой ИИ – максимум контроля, отечественный ИИ – компромисс с качеством, анонимизация + внешний ИИ – компромисс с некоторой сложностью, но зато с доступом к лучшему качеству.
Разрабатывая и внедряя внутренние политики, обучая сотрудников кибергигиене в эпоху ИИ. Современный работник должен знать, что облачный ИИ – не магическая чёрная коробочка, а потенциальная “утечка подождёт”.
Документируя и договорно закрепляя все моменты, чтобы и клиенты, и партнеры, и проверяющие органы видели: вы ответственны в обращении с данными, даже когда используете cutting-edge технологии.

В конце концов, всё сводится к балансу инноваций и безопасности. LLM способны приносить огромную пользу бизнесу: экономить время (автосоставление документов, ответы), давать инсайты (анализ данных), улучшать клиентский сервис (умные чат-боты). Отказываться от этого – значит уступить конкурентам. Но и рисковать репутацией и кошельком, бросаясь в ИИ с закрытыми глазами, нельзя. Оптимальное решение – “включить ИИ с умом”: продумать, обезопасить и тогда использовать.

Для предпринимателей в России сейчас важна осведомлённость. Те, кто разберётся в правилах игры (152-ФЗ, GDPR), обеспечит анонимизацию данных, настроит процессы – смогут спокойно применять ИИ и спать без страха проверок и утечек. Те же, кто проигнорирует – рискуют стать героем неприятных новостей.

Надеемся, эта статья помогла пролить свет на сложные аспекты темы. Как показывает практика, придерживаясь принципа “Не навреди (данным)”, бизнес может дружить и с клиентами, и с нейросетями. Будьте инновационны, но ответственны – и тогда современные LLM станут вашим надежным помощником, а не источником проблем.