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

Подобные случаи уже фиксировались у десятков крупных корпораций.

Живой пример

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

Почему это происходит

Большие языковые модели (LLM — large language models) — это системы, которые анализируют текст и формируют ответ на основе миллиардов примеров, изученных во время обучения. Чтобы ответить пользователю, модель передаёт его запрос на сервер, где он обрабатывается и сохраняется. Именно в этот момент корпоративные данные покидают защищённый периметр компании.

Разработчики LLM часто заявляют, что не используют пользовательские данные для обучения моделей. Но на практике любая публичная версия ИИ хранит часть запросов и ответов для диагностики и улучшения качества работы. Эти данные попадают в технические журналы — по сути, во внутренние копии обращений. В публичных облачных сервисах такие журналы могут храниться у провайдера для телеметрии — удалённого сбора данных и анализа работы модели. Режимы хранения и удаления зависят от политики конкретного поставщика.

Проблему усугубляет и так называемый теневой ИИ — когда сотрудники используют публичные нейросети для рабочих задач без ведома службы безопасности. В этом случае компания теряет контроль над тем, какие именно данные уходят в сеть. Так корпоративные тайны, персональные данные и внутренние документы оказываются за пределами компании — без возможности удалить их или отследить путь.

К чему приводят утечки данных

Около 4,44 млн долларов — средняя стоимость одной утечки данных в 2025 году
По данным IBM, уровень ущерба остаётся одним из самых высоких за всю историю наблюдений. Для сравнения: столько стоит годовая зарплата примерно пятидесяти высококвалифицированных инженеров или маркетинговый бюджет крупного регионального банка. Ниже — реальные кейсы, показывающие, что риски касаются даже технологических гигантов.

38 ТБ данных — Microsoft
Ошибка конфигурации в облачном хранилище, используемом при работе над ИИ-проектами, открыла доступ к резервным копиям сотрудников GitHub.
Последствия: в сеть попали ключи и пароли, потребовалась масштабная проверка инфраструктуры.
Реакция: компания изменила политику доступа и усилила контроль над хранилищами Azure.

Фрагменты исходного кода — Samsung
Инженеры загрузили служебный код в нейросеть для поиска ошибок. Файлы могли попасть в общие обучающие наборы.
Последствия: риск утечки внутренних алгоритмов, потенциальный ущерб — миллионы долларов.
Реакция: полный запрет использования публичных ИИ-сервисов сотрудниками, внедрение внутреннего корпоративного ассистента.

История запросов пользователей — OpenAI
Сбой в инфраструктуре ChatGPT сделал видимой часть заголовков чатов и платёжных данных примерно 1,2% подписчиков ChatGPT Plus.
Последствия: временная приостановка сервиса, рост внимания регуляторов к политике хранения данных.
Реакция: пересмотр архитектуры сессий и изоляции данных по пользователям.

Клиентские данные — Toyota Motor
В течение десяти лет часть пользовательских данных оставалась доступной из-за неправильно настроенного облачного контейнера.
Последствия: раскрытие информации более чем о 2 млн клиентов.
Реакция: обновление систем хранения, усиление контроля доступа и аудита облаков.

Как выстроить защиту: от политики до технологий

Чтобы советы не выглядели теорией, важно уточнить: рекомендации ниже основаны на признанных международных стандартах — NIST ИИ Risk Management Framework (США), ISO/IEC 27001 и 27701 (информационная и персональная безопасность), а также на корпоративных практиках Microsoft, Google, IBM, Apple и JPMorgan Chase. Эти документы и кейсы используются в индустрии как эталон построения безопасных систем искусственного интеллекта.

1. Начните с политики и правил

Любая защита начинается не с технологий, а с управления.
Ключевой принцип: Govern first, automate later (NIST ИИ RMF): сначала создаётся политика, потом внедряются инструменты.

• Пропишите внутренние правила работы с ИИ. Microsoft и IBM внедрили формальные процессы оценки и согласования ИИ-проектов по безопасности данных до запуска. Определите, какие инструменты разрешены, а какие находятся под запретом.
• Разделите данные по уровням чувствительности. Этот подход из ISO 27001 позволяет заранее определить, что можно выгружать во внешние системы, а что нет.
• Назначьте ответственного за ИИ-безопасность. Крупные компании создали внутренние комитеты и команды по Responsible ИИ — точки пересечения служб безопасности, юристов и аналитиков. В небольших организациях эту роль можно закрепить за CIO или руководителем отдела данных.
• Добавьте пункт об ИИ в NDA и должностные инструкции. Так сделали JPMorgan Chase и Deutsche Bank после введения ограничений на ChatGPT — чтобы юридически закрепить ответственность за утечки.
• Политика должна быть живым документом, а не архивным PDF. Сотрудники должны понимать не только что нельзя, но и почему это важно.

2. Обучите команду и измените культуру работы

Значительная доля утечек связана с человеческим фактором (по данным Verizon DBIR 2024 — более 68% инцидентов). Поэтому обучение — ключевой элемент любой защиты.

Что реально работает:

• Поясните принцип внешней обработки. Как напоминает Google ИИ Principles, любой ввод в публичную нейросеть физически уходит за пределы корпоративной сети.
• Разъясните, что даже безопасный сервис сохраняет журналы запросов. Внутренние руководства Microsoft Copilot прямо указывают, что запросы логируются для диагностики — это значит, их могут видеть администраторы.
• Приведите реальные примеры утечек. После инцидента в Samsung компания не ограничилась запретом, а провела серию внутренних обучений и запустила корпоративного ИИ-ассистента на закрытых серверах.
• Создайте простую памятку. IBM рекомендует формат «три уровня риска» — что можно вставлять, что можно только через шлюз и что категорически запрещено.

Когда люди понимают последствия, а не просто читают запреты, количество нарушений снижается в разы.

3. Технологические меры: минимум, который должен быть у каждой компании

Эти меры отражают принципы Secure ИИ Framework (SИИF) от Google Cloud и практики корпоративных провайдеров.

• Контроль доступа. Принцип минимальных прав (least privilege) из ISO 27001 — стандартная практика Microsoft Azure и IBM Cloud. Только те, кому нужно, могут передавать данные во внешние модели.
• Маскирование данных. Google Cloud ИИ использует токенизацию (подмена имён и сумм на обозначения вроде CLIENT_A). Это простая защита, которая предотвращает раскрытие конкретных клиентов.
• Корпоративные шлюзы для ИИ. Так работает Microsoft Copilot for Business: все запросы проходят через внутренний шлюз, где автоматически удаляются персональные данные и ведётся журнал обращений.
• Хранение и шифрование. ISO 27701 и NIST RMF требуют хранить рабочие данные только в проверенных облаках и использовать шифрование «на покое» и в транзите. Apple и JPMorgan Chase хранят внутренние ИИ-запросы исключительно в закрытых дата-центрах.
• Мониторинг и аудит. Корпоративные платформы IBM Watson и Watsonx предусматривают возможности аудита и журналирования обращений: кто, когда, к какой модели обращался. Это позволяет расследовать инциденты и оценивать риски.

4. Постоянный контроль и обратная связь

Как подчёркивает McKinsey в отчёте Securing the Generative ИИ Enterprise (2024), политика безопасности без регулярного пересмотра быстро устаревает. Компании-лидеры проводят аудит использования ИИ на постоянной основе: проверяют, какие модели применяются, какие данные уходят наружу, и обновляют правила. Такой подход внедрён в IBM и Google Cloud — у них есть комитеты по ИИ-комплаенсу, которые собирают обратную связь от сотрудников и корректируют внутренние инструкции.

Главное

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

Что можно и нельзя делать с ИИ внутри компании

Большинство инцидентов с утечками происходят не из-за сложных хакерских схем, а потому что кто-то просто хотел сэкономить время и отправил в нейросеть служебный документ. Поэтому важно не только прописать правила, но и донести до сотрудников, где граница между безопасным и опасным использованием ИИ.

1. Что категорически нельзя вставлять в нейросети

Даже если сервис кажется безопасным и приватным, всё, что вы вводите, уходит на сервер разработчика и может быть сохранено. Поэтому под строгим запретом:

• Персональные данные — имена, телефоны, e-mИИl, паспортные данные, контакты клиентов.
• Финансовая информация — суммы сделок, себестоимость, маржинальность, счета, реквизиты.
• Исходный код и документация — фрагменты программ, внутренние алгоритмы, технические задания.
• Внутренние отчёты и презентации — особенно с грифом «внутренне», «для служебного пользования» или содержащие цифры по продажам и клиентам.
• Любые данные из CRM, ERP, BI и аналитических систем. Даже один экспорт таблицы может раскрыть коммерческую стратегию компании.

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

2. Что можно — при условии обезличивания данных

Если вы хотите использовать ИИ для ускорения рутинных задач, есть безопасный компромисс — обезличенные данные.

Это значит, что вы можете:

• Подставлять в текст условные обозначения (CLIENT_01, PROJECT_X, BUDGET_A).
• Использовать агрегированные данные (например, “по региону в среднем 5 000 лидов”, а не “в Москве 4 827 лидов от клиента N”).
• Работать с синтетическими данными — то есть наборами, где цифры похожи на реальные, но не совпадают с ними.

Такой подход используют Google и IBM, когда обучают внутренние модели: данные проходят через этап токенизации — имена, суммы и внутренние идентификаторы заменяются на нейтральные маркеры. Это можно реализовать даже без сложных инструментов: через промежуточный слой (например, в n8n или собственной панели), который автоматически маскирует конфиденциальные поля перед отправкой запроса.

3. Как правильно использовать внутренние ИИ-инструменты

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

Ключевые отличия от публичных сервисов:

• Все запросы идут через корпоративный шлюз. Это прослойка, которая очищает запрос от лишнего, логирует действия и не позволяет вставлять закрытую информацию.
• ИИ получает доступ только к “маркетинговому” или аналитическому слою данных. Он не видит CRM, персональные карточки клиентов или финансовые документы.
• Хранение — на стороне компании. Даже если модель обращается к облаку, результаты и логи запросов сохраняются локально или в согласованном дата-центре.

Так устроен, например, Microsoft Copilot for Business и внутренние решения IBM WatsonX — они используют одну и ту же архитектуру: API-запрос идёт через корпоративный шлюз, где включена токенизация и шифрование, а в модель попадают только разрешённые параметры.

4. Как организовать безопасный доступ к ИИ через API

API — это технический мост между вашим продуктом и внешним ИИ-сервисом. Если его правильно настроить, можно безопасно использовать внешние модели без риска утечек.

Основные принципы:

• Не подключайте API напрямую к рабочим базам. Всегда используйте промежуточный слой (middleware), который фильтрует и анонимизирует запросы.
• Храните ключи доступа в защищённом хранилище. Например, в менеджере секретов (Vault, AWS Secrets Manager, Yandex Lockbox).
• Ограничьте список таблиц или полей, к которым ИИ может обращаться. Это делается в конфигурации API — модель видит только те данные, которые вы явно разрешили.
• Добавьте журналирование запросов. Это позволит быстро понять, кто, когда и какие данные отправил в систему, если произойдёт ошибка.

Большинство корпоративных платформ позволяют внедрить такие правила без участия программистов — через визуальные интерфейсы и готовые коннекторы.

Главное

Безопасная работа с ИИ не требует запрета всего. Достаточно разделить данные на те, что можно использовать, и те, что нельзя, а обращения направлять через защищённый шлюз или API. Тогда команда сможет работать с нейросетями свободно, а компания сохранит контроль над тем, что действительно ценно — своими данными.

Как действуют лидеры рынка

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

• Microsoft и IBM делают ставку на корпоративных ассистентов с контролем доступа: все запросы к моделям проходят через внутренние шлюзы с маскированием данных и журналированием.
• Apple и ряд финансовых групп ограничили использование публичных ИИ-сервисов и перешли на локальные развёртывания моделей внутри корпоративной инфраструктуры.
• Google развивает собственный фреймворк Secure ИИ Framework (SИИF), который совмещает техническую защиту с аудитом и обучением персонала.
• В России похожие меры внедряют крупные банки, телеком-операторы и IT-компании: разворачивают локальные GPT-модели в собственных дата-центрах и создают внутренние шлюзы для безопасного взаимодействия с ИИ.

Общая тенденция одна — компании не отказываются от нейросетей, а встраивают их в свою инфраструктуру по тем же правилам, что и другие критичные системы.

Что делать бизнесу уже сейчас

Свяжем эти тенденции с конкретными шагами, которые можно реализовать без сложных технологий.

• Утвердите правила и ответственность
  Определите, какие данные считаются конфиденциальными, какие ИИ-инструменты разрешены и кто отвечает за политику безопасности.
• Дайте команде безопасный канал работы с ИИ
  Используйте корпоративную версию модели или шлюз, который очищает запросы и сохраняет журнал действий.
• Ограничьте доступ к данным
  Внедрите принцип минимальных прав: сотрудники видят только то, что им нужно для работы.
• Локализуйте чувствительные сценарии
  Для проектов с финансами, персональными данными или кодом — только изолированные серверы или отечественные облака с контролем юрисдикции и условий хранения.
• Обучите сотрудников
  Проведите короткие тренинги с реальными примерами утечек и закрепите памятки «что можно и что нельзя вставлять в ИИ».
• Проводите регулярный аудит
  Раз в несколько месяцев проверяйте, какие модели используются, какие данные уходят наружу, и обновляйте политику.

Заключение

Те, кто научится управлять ИИ так же осознанно, как бюджетами и клиентскими базами, будут выигрывать не только в производительности, но и в доверии клиентов и партнёров. Безопасность — это не ограничение, а способ сделать использование ИИ предсказуемым и управляемым.

Если вам близок этот подход и вы хотите понимать, как выстраивать аналитику, управлять данными и делать маркетинг измеримым и безопасным, присоединяйтесь к Telegram-каналу CyberBrain.

Мы пишем для тех, кто отвечает за результат: маркетологов, аналитиков и руководителей, которые хотят контролировать эффективность рекламы, не теряя контроль над своими данными.