Введение

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

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

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

Поэтому возникает фундаментальное противоречие. Чем больше контекста получает LLM, тем лучше она обычно способна решить задачу. Но чем больше корпоративного контекста передается внешней системе, тем выше потенциальный риск раскрытия информации.

Для организаций это постепенно превращается из частной проблемы пользователей в самостоятельную архитектурную задачу.

Новая граница корпоративного периметра

В традиционной модели информационной безопасности граница между внутренней и внешней средой была относительно хорошо определена.

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

«Проанализируй этот договор».
«Найди риски в техническом решении».
«Подготовь краткое резюме совещания».
«Сравни предложения двух поставщиков».
«Помоги подготовить ответ клиенту».

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

Именно поэтому распространение LLM создает новую границу корпоративного периметра — границу между внутренними данными и AI-сервисами.

Запрет использования LLM проблему не решает

Наиболее простая реакция организации — запретить сотрудникам использовать внешние LLM для работы с корпоративной информацией. С точки зрения безопасности такая позиция понятна. Но практически она плохо масштабируется. Если инструмент дает сотруднику возможность выполнить за двадцать минут работу, которая раньше занимала несколько часов, давление на запрет будет постоянно возрастать. Возникает знакомая ситуация Shadow IT.

Сотрудники начинают использовать:

личные аккаунты;
сторонние AI-сервисы;
мобильные приложения;
браузерные расширения;
собственные API-ключи.

В результате организация не устраняет риск, а наоборот теряет возможность его контролировать. Поэтому более зрелая стратегия состоит не в попытке полностью запретить использование AI, а в создании безопасного способа его использования.

Ручное обезличивание — временное решение

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

Например, заменить:

ООО «Альфа» на Компания А
Иванов Сергей Петрович на Сотрудник 1.

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

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

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

Третья проблема намного менее очевидна.

Удаление чувствительной информации может разрушать смысл документа.

Конфиденциальность — это не только отдельные слова

Классические средства защиты информации хорошо работают с данными, которые можно определить формально.

Например:

номер телефона;
адрес электронной почты;
паспортные данные;
номер банковской карты;
ИНН;
СНИЛС;
IP-адрес;
определенный формат идентификатора.

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

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

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

Необходимо понимать: что именно означает информация в данном контексте.

Почему простого удаления данных недостаточно

Предположим, необходимо передать внешней модели договор. Один из возможных способов обезличивания:

[УДАЛЕНО] заключило договор с [УДАЛЕНО] на сумму [УДАЛЕНО].

С точки зрения конфиденциальности задача частично решена. С точки зрения анализа документа он почти потерял смысл.

Модель уже не понимает:

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

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

Например: CUSTOMER_1 заключил CONTRACT_1 с SUPPLIER_1 на сумму CONTRACT_AMOUNT_1.

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

Если CUSTOMER_1 встречается на тридцати страницах документа, модель понимает, что речь идет об одной и той же сущности. Именно здесь появляется пространство для AI-native подхода.

От обезличивания к семантическому преобразованию

AI-native система могла бы воспринимать документ не как последовательность символов, которые необходимо найти и заменить, а как набор связанных сущностей, фактов и отношений.

Например, в исходном документе присутствуют:

организация-заказчик;
организация-поставщик;
директор;
номер договора;
сумма договора;
название внутреннего проекта;
сервер;
внутренний адрес информационной системы.

Система определяет назначение каждого элемента и преобразует документ примерно следующим образом:

ООО «Альфа» → CUSTOMER_1
АО «Бета» → SUPPLIER_1
Иванов Сергей Петрович → CUSTOMER_CEO_1
№ 457/26 → CONTRACT_1
128 450 000 рублей → CONTRACT_AMOUNT_1
Project Aurora → INTERNAL_PROJECT_1

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

Если модель возвращает:

основной риск CONTRACT_1 связан с ответственностью SUPPLIER_1 при нарушении сроков…

локальная система преобразует результат обратно:

Основной риск договора № 457/26 связан с ответственностью АО «Бета» при нарушении сроков… Для пользователя вся операция выглядит практически прозрачной.

Как может выглядеть принцип работы такой системы?

Между пользователем и внешней LLM появляется доверенный внутренний слой. Упрощенно цепочка выглядит следующим образом:

Корпоративный документ
Локальная AI-модель внутри доверенного периметра
Определение сущностей, связей и чувствительных фактов
Применение детерминированной политики безопасности
Псевдонимизация, удаление или обобщение данных
Контроль результата обезличивания
- Только после этого документ пересекает границу организации
Обезличенный контекст
Облачная LLM
Результат обработки
- Возврат в доверенный периметр
Локальное восстановление исходных сущностей
Конечный результат для пользователя

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

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

Здесь необходимо зафиксировать принципиальное архитектурное ограничение.

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

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

То есть схема не выглядит следующим образом:

конфиденциальный документ > облачная LLM > обезличивание > работа с документом.

Такой подход не имел бы смысла: к моменту обезличивания исходные данные уже были бы переданы внешнему сервису. Правильная последовательность обратная:

конфиденциальный документ > локальная AI-модель внутри организации > обезличенный документ > внешняя LLM.

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

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

Например, локальная модель должна уметь понять, что:

«ООО „Альфа“» — это контрагент;
«Иванов Сергей Петрович» — физическое лицо и подписант;
«128 450 000 рублей» — стоимость договора;
«Проект Север» — название внутреннего проекта;
10.34.7.12 — адрес внутреннего информационного ресурса.

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

Почему локальная модель здесь принципиально важна

Использование локального AI-компонента — это не просто вариант развертывания системы и не попытка снизить стоимость вызовов облачной LLM. Это одно из базовых требований безопасности предлагаемой архитектуры. Чтобы определить, является ли информация конфиденциальной, системе сначала необходимо эту информацию прочитать. Если для такого анализа передать исходный документ внешней LLM, возникает логическое противоречие: средство предотвращения утечки само становится каналом передачи защищаемой информации.

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

Ни один исходный конфиденциальный фрагмент не должен передаваться внешней модели для того, чтобы определить, является ли он конфиденциальным.

Все операции, которым необходим доступ к оригинальным данным, выполняются внутри доверенного контура:

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

За пределы контура выходит только подготовленное представление документа.

Локальная и облачная модели решают разные задачи

Это также позволяет избежать другого распространенного заблуждения: будто организации придется локально развернуть модель уровня крупнейших облачных LLM и тем самым потерять все преимущества облачного AI.

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

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

локальный AI обеспечивает понимание, необходимое для защиты данных;
внешний AI предоставляет наиболее мощные возможности reasoning и генерации.

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

Оригинальные корпоративные данные существуют только внутри доверенного периметра. AI-компоненты, которым необходимо видеть оригинал, также исполняются внутри этого периметра. Внешним моделям передается только семантически эквивалентное, но безопасное представление данных.

Это принципиально отличает предлагаемую систему от обычного облачного AI-сервиса с функцией «анонимизации». В первом случае организация сначала передает данные поставщику, а затем надеется на правильность его обработки и договорные ограничения. Во втором случае технически реализуется иной принцип:

Поставщик внешней LLM изначально не получает информацию, которую организация решила не выпускать за свой периметр.

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

AI понимает, система принимает решение

При этом было бы ошибкой поручить LLM полностью самостоятельно решать, какие данные являются секретными и можно ли их отправлять наружу. Любая модель вероятностна.

Она может:

неправильно классифицировать сущность;
не заметить чувствительный фрагмент;
ошибочно определить контекст;
интерпретировать неоднозначный термин неверно.

Поэтому AI-native подход не означает, что AI становится единственным механизмом безопасности. Напротив. Разумная архитектура должна сочетать две природы системы.

AI-компонент понимает содержание документа.

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

Детерминированный компонент применяет правила.

Он решает, что разрешено передавать, что необходимо скрыть, какую модель разрешено использовать и когда операция должна быть запрещена полностью. Таким образом AI отвечает прежде всего на вопрос: что находится перед нами? А политика безопасности — на вопрос: что с этим разрешено делать? Это существенное разделени ответственности.

Не только скрывать, но и преобразовывать

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

Например,

точная сумма: 128 437 912 рублей, может быть заменена на: около 130 млн рублей.
точная дата: 17 ноября 2026 года на: IV квартал 2026 года.
название клиента: ООО «Альфа» на: крупный промышленный заказчик.
IP-адрес: 10.43.17.28 на: INTERNAL_SERVER_1.

Такое преобразование позволяет сохранить ровно столько информации, сколько необходимо модели для решения задачи. Это уже не классическое обезличивание.

Управляемое снижение точности данных при сохранении необходимого смысла.

Политики могут зависеть от контекста

Особенно важным свойством корпоративной системы может стать контекстная политика. Один и тот же документ допустимо обрабатывать совершенно по-разному в зависимости от того, куда он отправляется.

Например, организация использует:

собственную локальную LLM;
корпоративный облачный AI-сервис;
внешний публичный AI-сервис.

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

Политика может учитывать также:

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

Таким образом система превращается из простого «фильтра текста» в

Политический слой управления использованием корпоративных данных AI-системами.

Когда запрос лучше вообще не выполнять

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

Например, если модель должна анализировать:

стратегию M&A;
материалы расследования;
сведения о критической инфраструктуре;
архитектуру особо защищенной системы;
неизвестную рынку финансовую отчетность;
документы, связанные с государственной тайной или другими жесткими режимами защиты.

В таких случаях попытка удалить несколько имен и номеров не делает документ безопасным. AI-native система должна иметь возможность прийти к выводу: этот запрос невозможно безопасно выполнить через внешнюю модель.

После этого возможны другие варианты:

использовать локальную LLM;
направить запрос в разрешенную корпоративную модель;
потребовать дополнительного согласования;
полностью запретить операцию.

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

Восстановление документа — не менее важная часть задачи

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

Если перед этим он вручную заменил:

названия компаний;
ФИО;
номера договоров;
суммы;
названия проектов,

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

Новый тип корпоративной инфраструктуры

Если посмотреть на проблему шире, становится видно, что речь может идти не об отдельной программе для обработки документов. Между корпоративной средой и LLM может возникнуть новый инфраструктурный слой.

Условно его можно назвать AI Security Gateway или Confidential AI Gateway.

Через него могут проходить обращения:

корпоративных AI-ассистентов;
офисных приложений;
IDE;
внутренних информационных систем;
пользовательских интерфейсов;
API корпоративных приложений.

Его задача — контролировать, какие данные покидают организационный периметр и в каком виде. По своей роли такой компонент отчасти напоминает существующие инфраструктурные средства:

API Gateway контролирует взаимодействие приложений;
IAM контролирует идентификацию и доступ;
DLP контролирует каналы утечки;
WAF контролирует веб-трафик.

AI Gateway мог бы контролировать границу между корпоративной информацией и моделями искусственного интеллекта.

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

Где здесь AI-native подход?

На первый взгляд всю задачу можно представить как очередную интеграцию LLM с существующими средствами защиты. Однако принципиальная особенность заключается в другом. Классическая система видит: строку текста, файл, поле, регулярное выражение. AI-native система должна видеть: клиента, договор, обязательство, стоимость, сотрудника, проект, внутреннюю систему и отношения между ними. То есть AI используется не как дополнительный интерфейс к готовой функции. Он становится частью механизма, позволяющего системе понять смысл объекта, с которым она работает.

При этом детерминированные компоненты сохраняют ответственность за критически важные операции:

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

Получается характерная для AI-native систем архитектура: вероятностное понимание мира + детерминированное исполнение правил. Именно это сочетание позволяет решать задачи, которые плохо укладываются как в исключительно традиционный подход, так и в модель «отдадим всё LLM и попросим ее разобраться».

Что получает организация?

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

Во-вторых, организация снижает зависимость от внимательности конкретного человека.

В-третьих, появляется единая политика использования внешних AI-сервисов.

В-четвертых, становится возможен централизованный аудит:

кто обращался к AI;
с какими категориями информации;
какие преобразования применялись;
какая модель использовалась;
было ли разрешено или запрещено обращение.

Наконец, организация получает возможность постепенно расширять использование AI. Сегодня определенный класс документов может быть разрешен только для локальной модели. Завтра появляется доверенный облачный сервис — и политика меняется. Бизнес-приложения при этом перестраивать не требуется. Меняется политика инфраструктурного слоя.

Это не абсолютная защита

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

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

Заключение

Распространение LLM создает для организаций необычную ситуацию.

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

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

AI может помочь понять данные.

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

Возможно, через несколько лет непосредственная передача корпоративного документа внешней LLM будет выглядеть так же странно, как сегодня прямой доступ внутреннего приложения к публичному сервису в обход API Gateway, IAM и других средств контроля.

Между корпоративными данными и AI почти неизбежно появится собственный слой безопасности. И AI, вероятно, станет не только объектом этого контроля, но и одним из ключевых инструментов, позволяющих этот контроль реализовать.