Безопасность данных при внедрении ИИ в компании

Внедрение ИИ упирается не в модель, а в один вопрос от службы безопасности: «Куда уйдут наши данные?» Если ответа нет, проект замораживают. Безопасность данных ИИ — это не галочка после запуска, а условие, без которого договоры, переписку клиентов и первичку нельзя отдавать алгоритму. Ниже разберём, где данные реально утекают, как выглядит модель угроз и какие меры закрывают риск так, чтобы проект прошёл согласование с юристами и ИБ.

Где утекают данные при работе с ИИ

Основная ошибка — считать, что риск только в «хакерах». Чаще данные уходят легально, по условиям сервиса, которые никто не читал.

Облачные ChatGPT и Claude. Запрос уходит на серверы за рубежом. Даже если провайдер обещает не обучаться на ваших данных, физически информация покидает периметр компании и попадает под чужую юрисдикцию. Для персональных данных это нарушение 152-ФЗ, для объектов критической инфраструктуры — отдельный состав.

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

Логи и кэш. Запросы и ответы хранятся в логах провайдера и в логах ваших же интеграций. Утечка часто происходит не из модели, а из забытого debug-лога или скриншота в мессенджере.

Теневое использование. Сотрудники сами носят рабочие документы в публичные чат-боты, чтобы «быстрее сделать». Это самый частый и самый недооценённый канал: данные утекают без ведома руководства и без единой записи в журнале.

Интеграции и подрядчики. Когда ИИ подключают к 1С или CRM через сторонний коннектор, ключи доступа и выгрузки оседают у посредника.

Модель угроз: от чего защищаемся

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

Что защищаем	От кого	Главный риск	Базовая мера
Персональные данные клиентов	Внешний провайдер, регулятор	Передача за периметр, штраф по 152-ФЗ	Закрытый контур, обезличивание
Коммерческая тайна (договоры, цены)	Конкуренты, подрядчики	Утечка через логи и обучение	On-premise, контроль выгрузок
Учётные данные и ключи к 1С/CRM	Внутренний нарушитель	Эскалация доступа	RBAC, ротация ключей
Целостность данных в системах	Ошибка ИИ-агента	Запись неверных данных в учёт	Подтверждение операций, журнал

Отдельная категория — внутренний нарушитель. Сотрудник с легальным доступом опаснее внешнего, потому что он уже внутри. Поэтому контроль доступа и журналирование важнее, чем кажется на старте.

Закрытый контур и отечественные LLM

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

On-premise или закрытый контур означает, что языковая модель развёрнута на ваших серверах или в изолированном сегменте арендованной инфраструктуры. Запросы не уходят в интернет, обучения на ваших данных нет по определению, логи остаются у вас. Это снимает вопрос юрисдикции и закрывает требования к КИИ.

Поскольку зарубежные ChatGPT и Claude в России недоступны и в закрытом контуре неприменимы, рабочая замена — отечественные модели: GigaChat, YandexGPT, Cotype. Их можно разворачивать в периметре компании. OVEERMOON строит ИИ-агентов именно на этих моделях в закрытом контуре, поэтому данные не покидают компанию, а проект проходит согласование с ИБ без исключений и «костылей».

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

Меры защиты, которые работают на практике

Закрытый контур убирает внешний канал, но внутренние риски остаются. Их закрывают слоями.

1. Обезличивание данных. Перед передачей в модель из текста удаляют или заменяют ФИО, телефоны, номера счетов, адреса. Модель работает с обезличенными данными, а исходные значения подставляются обратно уже в вашей системе. Это резко снижает цену любой утечки.
2. Разграничение доступа (RBAC). У каждого сотрудника и каждого ИИ-агента — своя роль и свой набор прав. Менеджер видит своих клиентов, агент по первичке не имеет доступа к зарплатным данным. Доступ выдаётся по принципу минимальных привилегий.
3. Журналирование. Каждый запрос, ответ и действие агента записываются: кто, когда, что спросил, что система сделала. Без журнала вы не докажете регулятору соответствие и не расследуете инцидент.
4. Контроль промптов и выгрузок. Фильтры на входе блокируют попытки вытащить данные за пределы роли. Фильтры на выходе не дают агенту выгрузить массив данных туда, куда нельзя. Это защита и от ошибки, и от злоупотребления.
5. Договорные гарантии. С подрядчиком фиксируются обязательства по защите данных, запрет на обучение на ваших данных, право на аудит, ответственность за утечку. Устных обещаний недостаточно.
6. Ротация ключей и сегментация сети. Ключи доступа к 1С и CRM меняются по расписанию, ИИ-сегмент изолирован от остальной сети.

152-ФЗ и КИИ кратко

Два правовых блока определяют рамки. По 152-ФЗ персональные данные граждан России обрабатываются с их согласия, хранятся на территории страны и защищаются техническими мерами. Передача данных в зарубежное облако без выполнения этих условий — нарушение с реальными штрафами, которые в 2024–2025 годах заметно выросли.

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

Чек-лист безопасности перед запуском ИИ

Пройдите по списку до того, как первый реальный документ попадёт в модель. Защита данных при внедрении ИИ дешевле в проектировании, чем при разборе инцидента.

• Описана модель угроз: что защищаем, от кого, какой риск приоритетный.
• Определено, где разворачивается модель: закрытый контур или on-premise для ПД и КИИ.
• Выбрана отечественная LLM, совместимая с требованиями (GigaChat, YandexGPT, Cotype).
• Настроено обезличивание чувствительных полей до передачи в модель.
• Внедрён RBAC: у каждого пользователя и агента минимально необходимые права.
• Включено журналирование запросов, ответов и действий агентов.
• Работают фильтры промптов и контроль выгрузок.
• Закрыто теневое использование: публичные чат-боты заблокированы, есть легальная внутренняя альтернатива.
• В договоре с подрядчиком зафиксированы гарантии, запрет на обучение и право аудита.
• Назначен ответственный за ИБ ИИ-контура и регламент реагирования на инцидент.

Как посчитать эффект и риск

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

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

Часто задаваемые вопросы

Можно ли безопасно использовать облачный ChatGPT для рабочих задач?

Для публичной, не чувствительной информации — да, с осторожностью. Для персональных данных, коммерческой тайны и объектов КИИ — нет: данные покидают периметр и юрисдикцию, что нарушает 152-ФЗ. Здесь нужен закрытый контур на отечественной модели.

Что такое обезличивание и зачем оно нужно, если есть закрытый контур?

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

Насколько отечественные LLM уступают зарубежным по качеству?

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

Кто отвечает за безопасность: мы или подрядчик?

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

Что сделать дальше

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