Опыт Локо-Банка: как защитить корпоративные данные от ИИ

Двусторонний вектор атаки

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

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

Где заканчивается контроль

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

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

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

Что никогда не должно оказаться в облаке

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

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

Когда обфускация не работает

Маскирование, токенизация и обфускация часто воспринимаются бизнесом как панацея — универсальный способ безопасно «скормить» любые данные облачной нейросети. Однако на практике понимание разницы между реальной защитой и иллюзией безопасности критически важно для инфраструктуры. Безопасная обфускация действительно эффективна, когда речь идет об агрегированных данных. Например, при сегментации базы и выявлении клиентов с высоким кредитным риском банк может заменить ФИО и конкретные суммы на счетах абстрактными идентификаторами. Внешняя модель успешно проанализирует агрегированные данные и построит аналитическую выборку, не привязываясь к конкретным личностям и балансам. В таких сценариях маскировка полностью оправдана и не несет рисков.

Но ситуация кардинально меняется, когда речь заходит об анализе конкретных транзакционных эпизодов физических или юридических лиц. Если банк обезличит ФИО клиента или уберет название условного ООО «Ромашка», но при этом сохранит в промпте ИНН, вид деятельности, город и специфику перевода, облачная модель легко сопоставит этот запрос с реальным субъектом по совокупности косвенных признаков. В дальнейшем эти реквизиты могут быть деобфусцированы злоумышленником, перехватившим данные из внешнего сервиса. Если в отправляемом массиве сохраняется достаточный объём косвенных идентификаторов, формальная маскировка превращается в опасную фикцию, не обеспечивающую никакой реальной анонимизации.

Деобфускация: почему ИИ может остаться игрушкой

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

Наиболее ярко это проявляется в процессах ИТ-разработки. Сгенерированный облачной LLM обезличенный код абсолютно непригоден для внедрения: в нём отсутствуют реальные переменные, внутренние пути и креды, описывающие корпоративную архитектуру. Чтобы разработчик мог его использовать, фрагмент должен пройти обязательную автоматическую деобфускацию, в ходе которой обезличенные токены заменяются на подлинные инфраструктурные параметры. Именно поэтому в Локо-Банке процесс двустороннего преобразования — скрытие на входе и безопасное обогащение на выходе — закладывается в сам фундамент работы с ИИ.

Как RAG ломает классическую модель доступа

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

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

LLM-гейтвей как новый архитектурный стандарт

Развитие всех описанных сценариев — от необходимости деобфускации до контроля векторных баз — приводит ИБ