Гладиаторы - меню

Стратегия защиты компании от утечки данных с учетом внедрения ИИ агентов подразделениями

Стратегия защиты компании составлена с учетом специфики страхового рынка и с фокусом на использование GPT‑агентов в разных подразделениях. Основная цель и бизнес-риск - минимизацию утечки данных с учетом рисков, что перечень агентов не утвержден и сотрудники могут использовать те GPT-сервисы, которые “найдут”. Также акцент сделан на построении on-premise инфраструктуры.

Содержание:

Команда редакторов "Гладиаторы ИБ"

Дата публикации: 22.12.2025
Время прочтения 7 минут

Основные цели

Не допустить передачи защищаемой информации (ПДн, коммерческая тайна, служебная информация, медданные) в неконтролируемые GPT‑сервисы.
Использовать только контролируемые каналы (российские вендоры, локальные модели, интеграция через корпоративные шлюзы).
Соответствовать требованиям Банка России и ГОСТ Р 57580.1‑2017 по защите информации в финансовых организациях.
Снизить финансовые последствия инцидента через киберстрахование и страхование рисков утечек ПДн, которые сейчас активно развиваются на рынке

1 - Организационная стратегия

1.1 - Политика использования ИИ/ GPT в компании
Принять отдельный корпоративный стандарт использования ИИ‑сервисов, включающий:

Четкое определение:
какие типы данных запрещено передавать внешним ИИ (ПДн по 152‑ФЗ, биометрия, медданные, результаты скоринга, закрытые тарифы, внутренние отчёты и т.п.);
какие данные можно передавать только в локальные/корпоративные модели;
какие данные можно использовать в публичных GPT (общие тексты без привязки к клиентам, обезличенные и агрегированные данные).
Перечень разрешённых провайдеров ИИ и их режимов (он‑prem, частное облако, российские облака)
корпоративный ИИ‑портал (на базе российской платформы);
локальные LLM (RuGPT, Сбер, Яндекс и др. в on‑premise);
внешние российские сервисы (только при наличии договора, локализации данных и режима «no‑training»).
Запрет на:
использование личных аккаунтов (ChatGPT, Gemini, Copilot и др.) для рабочих задач;
загрузку в ИИ‑сервисы файлов с клиентскими базами, выгрузками из АБС, CRM, медицинских систем, отчётами по убыткам и пр.

1.2 - Классификация данных и матрица доступа
Утвердить классификацию информации:

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

для каждого класса - правила обращения с ИИ:

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

1.3 - Регламент для подразделений
Для ключевых подразделений (продажи, андеррайтинг, урегулирование убытков, медэкспертиза, риск‑менеджмент, ИТ, маркетинг):

Описать разрешённые сценарии использования ИИ:
продажи - генерация общих скриптов, писем без ПДн;
андеррайтинг - аналитика на обезличенных агрегированных данных;
урегулирование - шаблоны писем, разъяснения законодательства без данных конкретных клиентов;
ИТ - генерация кода без вставки конфиденциальных фрагментов архитектуры.
Внедрить процедуру согласования новых ИИ‑сервисов:
инициатор → ИБ/ИТ → оценка рисков и юристов → тестовый режим в «песочнице» → утверждение ИТ-комитетом и службой ИБ → включение в реестр разрешённых.

1.4 - Обучение и мотивация сотрудников

Ежегодное обучение:
базовые правила защиты ПДн и коммерческой тайны;
реальные кейсы утечек через ИИ;
примеры «как можно / как нельзя» работать с GPT.
Тестирование и включение соблюдения ИБ‑требований в KPI руководителей подразделений.
Отдельный курс для ИТ/аналитиков по безопасному использованию LLM.

2 - Техническая стратегия (российский рынок)

2.1 - Общий архитектурный подход

Все обращения к внешним и внутренним ИИ‑сервисам должны идти:
через корпоративный прокси/шлюз безопасности (Web Proxy + DLP + SSL‑инспекция);
с аутентификацией по корпоративной учётке (AD/LDAP/SSO);
с журналированием запросов и ответов (с учетом требований по ПДн и гостайне — если применимо).
прямой доступ сотрудников к внешним GPT-сервисам запретить (ChatGPT, Gemini, Copilot, YandexGPT, GigaChat и др.)
как временная мера разработать временную политику (на 3-6 месяцев) с перечнем запрещенных действий и последствий за нарушение (например, дисциплинарные).

2.2 - DLP и контроль каналов
Рекомендуемые классы решений (все имеют аналоги на российском рынке):

DLP‑системы:
InfoWatch Traffic Monitor
Solar Dozor
SearchInform DLP
и др.
Настройки:
создание отдельных политик на HTTP(S)‑трафик к ИИ‑сервисам (по доменам/категориям);
блокировка отправки (по шаблонам ПДн):
ФИО + телефон/паспорт/полис;
реквизитов договоров;
фрагментов БД (регулярки, словари, цифровые шаблоны);
ключевых слов/шаблонов коммерческой тайны.
мониторинг вложений (doc/xls/pdf) в веб‑форм (запрет отправки файлов с расширениями .xls, .xlsx, .csv, .pdf, .doc, .docx в веб‑формы ИИ);
категории: «Искусственный интеллект», «Генеративные модели», «Облачные ИИ‑сервисы» — блокировать.
Мониторинг запросов к API‑эндпоинтам ИИ‑сервисов.

2.3 - Ограничение и сегментация доступа к ИИ

На уровне прокси/МСЭ:
заблокировать доступ к всем зарубежным ИИ‑платформам, кроме тех, которые согласованы (если вообще нужны);
Блокировка доменов:chat.openai.com, gemini.google.com, copilot.microsoft.com, giga.chat, yandex.ru/gpt и т.п.
Разрешение только к:
внутреннему ИИ‑порталу;
доверенным российским сервисам (по списку).
разрешить доступ только к списку доверенных российских ИИ‑провайдеров и/или вашему корпоративному ИИ‑порталу.
Для внутренних LLM:
разместить модель в отдельном сегменте сети, доступ к которому идет только из корпоративной сети/VPN;
использовать RBAC: не все сотрудники видят все функции (например, отдел урегулирования не видит аналитические модели андеррайтинга).

2.4 - журналирование доступов и контроль

с помощью SIEM использовать централизованный журнал событий и сбор с систем:
DLP;
прокси;
ИИ‑портала;
систем доступа.
при этом настройка отдельных сценариев логирования (инцидентов):
попытки доступа к запрещенным ИИ‑сервисам;
попытки передачи ПДн в ИИ.
Контроль на рабочих станциях:
DLP‑агенты на всех ПК
Блокировка:
копирования ПДн в буфер обмена;
отправки ПДн в мессенджеры, почту, веб‑формы.
Сегментация сети:
Выделенный сегмент для ИИ‑инфраструктуры (как описано выше).
Ограничение доступа к ИИ‑порталу и LLM только из корпоративной сети/VPN.

2.5 - Использование российских GPT‑решений
Варианты (примеры, не реклама):

Облачные российские LLM‑сервисы:
GigaChat (Сбер),
YandexGPT,
VK,
«Сбер Клауд»
«Яндекс Облако» и др.
On‑premise / частное облако:
развертывание моделей (например, RuGPT, отечественные LLM от Сбера/VK/Яндекса в корпоративном контуре) с управлением через Kubernetes/Openshift и т.п.
Требования к провайдерам:
дата‑центры в РФ;
договор с прописанными обязанностями по защите ПДн и коммерческой тайны;
сертифицированные средства защиты (по ФСТЭК/ФСБ, где применимо);
возможность отключить обучение модели на ваших данных или обеспечить изоляцию (no‑training mode).

2.6 - Интеграция ИИ через корпоративный слой

Не давать сотрудникам «голый» веб‑доступ к GPT.
Реализовать единый корпоративный ИИ‑портал:
сотрудники работают через внутренний веб‑интерфейс;
бэкенд маршрутизирует запросы:
часть — на локальные модели;
часть — на внешних российских провайдеров;
перед отправкой данные проходят:
маскирование (обезличивание ПДн, хэширование идентификаторов);
фильтрацию по правилам.
Логировать:
кто, когда, с какого подразделения и какие запросы делал;
использовать эти логи для аудита и расследований.

2.7 - Защита инфраструктуры и аутсорсинга (если этот вариант приемлем)
ЦБ РФ уже указывает на высокие риски при аутсорсинге ИТ и облаков для финансовых организаций и готовит регулирование в этой части.

При использовании облаков для ИИ:
прописать в договорах:
запрет передачи данных третьим лицам;
требования к уровню защиты (по ГОСТ Р 57580.1‑2017 и внутренним стандартам ИБ);
обязательство уведомления об инцидентах.
провести аудит ИБ‑провайдера (по чек‑листу ГОСТ/ЦБ, возможно с привлечением внешнего аудитора).
Для внутренних систем:
сегментация сети;
двухфакторная аутентификация для админов и доступа к ИИ‑инфраструктуре;
централизованный журнал событий (SIEM, например, Solar SIEM, MaxPatrol SIEM и др.).

2.8 - примеры систем и варианты интеграций
Пример платформ для on‑premise / private cloud:

Сбер: GigaChat / Сбер ИИ‑платформа
Возможность развёртывания в **частном облаке / on‑premise** (в т.ч. в контуре заказчика).
Поддержка:
генерации текста;
аналитики;
чат‑ботов;
интеграции через API.
Условия:
Договор с Сбером с прописанными обязанностями по защите ПДн и коммерческой тайны.
Режим «без обучения на ваших данных» (no‑training mode).
Интеграция:
Через API в корпоративный ИИ‑портал.
Добавление правил обезличивания перед отправкой.
Яндекс: YandexGPT / Яндекс.Облако (в частном контуре)
Возможность развёртывания в частном облаке / on‑premise (в рамках Яндекс.Облако для бизнеса)
Поддержка:
генерации текста;
аналитики;
чат‑ботов.
Условия:
Договор с Яндексом с локализацией данных в РФ и режимом «без обучения».
Интеграция:
Через API в корпоративный ИИ‑портал.
VK: VK Giga / VK AI
Решения для бизнеса, включая чат‑ботов и аналитику
Возможность развёртывания в частном облаке / on‑premise.
Условия:
Договор с VK, локализация данных, режим «без обучения».
Интеграция:
Через API в корпоративный ИИ‑портал.
СКБ Контур: ИИ‑решения для бизнеса
Решения для автоматизации, аналитики, чат‑ботов
Возможность развёртывания в on‑premise.
Поддержка:
генерации писем, скриптов;
аналитики на обезличенных данных.
Интеграция:
Через API в корпоративный ИИ‑портал.

Как пример локальной LLM (on-premise):

Варианты
RuGPT (Сбер, МФТИ и др.) - русскоязычные модели, которые можно развёртывать on‑premise.
Сбер: LLM в контуре заказчика - Сбер предлагает развёртывание своих LLM в частном облаке / on‑premise.
Яндекс: LLM в частном облаке - аналогично.
Архитектура:
Модели развертываются в отдельном сегменте сети (например, в DMZ или выделенном VLAN).
Доступ только через корпоративный ИИ‑портал.
Перед отправкой в модель:
обезличивание ПДн (замена ФИО, паспортов, полисов на токены);
фильтрация по правилам DLP.

Как пример создания корпоративного ИИ-портала (с единой точкой входа):
Функционал:

Веб‑интерфейс для сотрудников.
Поддержка сценариев:
генерация писем, скриптов, ответов на запросы;
анализ текстов (жалобы, претензии);
поддержка продаж, урегулирования, маркетинга
Интеграция:
с CRM, АБС, системой документооборота (через API)
Безопасность:
Аутентификация по корпоративной учётке (AD/LDAP/SSO).
RBAC: разные роли (продажи, андеррайтинг, урегулирование, ИТ).
Обезличивание данных перед отправкой в LLM.
Журналирование всех запросов и ответов (в SIEM).

Реализация:

Разработка на базе:
фреймворков (например, FastAPI, Django);
с интеграцией API выбранных российских платформ (Сбер, Яндекс, VK, СКБ Контур).
Или использование готовых решений:
Сбер: ИИ‑платформа + портал;
Яндекс: Яндекс.Облако + портал;
СКБ Контур: ИИ‑решения + портал.

3. Правовые и регуляторные аспекты

3.1. Соответствие требованиям ЦБ и ГОСТ

Для страховых компаний с активами > 20 млрд руб. уже обязателен стандартный уровень защиты информации по ГОСТ Р 57580.1‑2017, включая регулярную оценку соответствия каждые три года с привлечением внешних проверяющих.
ЦБ прорабатывает распространение этого уровня на всех страховые компании.
Использование ИИ‑сервисов должно быть учтено:
в модели угроз;
в перечне ИС и каналов передачи информации;
в документации по защите ПДн и коммерческой тайны.

3.2 - Внутренние документы
Обновить/разработать:

Положение о защите ПДн (152‑ФЗ) с учётом ИИ‑сервисов.
Положение о коммерческой тайне — запрет/условия передачи в ИИ.
Политику ИБ, стандарты по использованию облаков и аутсорсинга (можно учесть законопроект ЦБ об ИТ‑аутсорсинге для финорганизаций).
Порядок расследования инцидентов, связанных с ИИ.

4 - Финансовая защита: киберстрахование и страхование утечек

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

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

5 - Приблизительная оценка затрат (укрупнённо)

Зависит от масштаба, но в типовой средней/крупной компании:
1. Организационные меры:

разработка политик, обучение, аудит процессов — условно 0,5–2 млн руб. (если привлекаются внешние консультанты).

2. DLP + донастройка под ИИ:

если DLP уже есть — 0,5–1,5 млн руб. на проект по донастройке и внедрению политик;
если нет — лицензии + внедрение от 5–15 млн руб. в зависимости от масштаба.

3. Корпоративный ИИ‑портал / интеграционный слой:

пилот (на базе готовых решений/SDK вендоров) — от 2–5 млн руб.;
промышленная эксплуатация с интеграцией в СУБП, IAM, SIEM — 5–20 млн руб.

4. On‑prem/частное облако для LLM:

серверные мощности (GPU/CPU), ПО, развёртывание — от 5–30 млн руб. в зависимости от мощности и отказоустойчивости.

5. Киберстрахование / страхование утечек:

взносы зависят от оборота, объёма ПДн и уровня защиты; для ориентира — обычно доли процента от страховой суммы, которая для крупных компаний может быть в диапазоне 100 млн–1 млрд руб.