БЕЗОПАСНОЕ ИСПОЛЬЗОВАНИЕ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА В РАБОЧИХ ПРОЦЕССАХ

АННОТАЦИЯ

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

ABSTRACT

This paper presents a practical approach to integrating artificial intelligence (AI) into workflows while preventing the disclosure of confidential information. To this end, key threats across the entire data lifecycle (input, processing, output, storage, and integrations) are analyzed, corporate data is classified, and a multi-tiered security toolkit is designed. This toolkit includes organizational policies, access management, data masking and tokenization, DLP controls at input and output points, a centralized gateway to AI models, comprehensive logging, and regular leakage testing. The outcome is presented as an example of a holistic framework applicable to typical scenarios (document handling, customer support, development, and analytics). It is demonstrated that maximum effectiveness is achieved by combining the principle of least privilege with continuous auditing.

Ключевые слова: конфиденциальные данные, корпоративный ИИ, DLP, управление доступом, безопасность по проекту, маскирование данных, аудит

Keywords: confidential data, enterprise AI, DLP, access control, security by design, data masking, audit.

Введение

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

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

Цель исследования

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

Задачи исследования

1. Определить ключевые угрозы конфиденциальности при использовании ИИ в типовых рабочих сценариях.
2. Сформировать модель классификации данных и правила “что можно/нельзя” передавать в ИИ-системы.
3. Предложить многоуровневую систему мер защиты (организационных, технических, процедурных).
4. Описать контрольные метрики и процедуры аудита, позволяющие поддерживать безопасность в динамике.
5. Сопоставить подход с реальными процессами: документы, поддержка, разработка, аналитика, HR/финансы.

Материалы и методы

 1. Объект исследования и границы

Объектом исследования являются рабочие процессы, в которых ИИ используется для:

• генерации и редактирования текста (письма, договоры, инструкции);
• анализа фрагментов данных (таблицы, отчёты, выгрузки);
• помощи разработчикам (код-ревью, объяснение ошибок, генерация фрагментов кода);
• поиска знаний по внутренней базе (RAG-подход, корпоративный чат-бот);
• поддержки клиентов и внутреннего Service Desk.

Границы: рассматривается защита конфиденциальности (в первую очередь), а также смежные аспекты целостности и доступности там, где они влияют на конфиденциальность (например, подмена ответа ИИ, ведущая к раскрытию данных).

2. Классификация данных и принцип “минимально необходимого”

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

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

Для ИИ-сценариев вводится правило: в запрос попадает только минимально необходимый контекст, а всё сверх - исключается, агрегируется или маскируется. Это переносит известный принцип least privilege на “данные в подсказках”.

3. Моделирование угроз по жизненному циклу данных

Риски анализируются по этапам:

• Ввод (Prompt/Input) - что пользователь отправляет в модель.
• Обработка (Model/Inference) - где и как модель обрабатывает данные (локально/облако/провайдер).
• Вывод (Output) - не раскрывает ли ответ конфиденциальное.
• Хранение (Logs/History) - сохраняется ли запрос/ответ в логах, истории чата, телеметрии.
• Интеграции (Tools/Plugins) - передача данных внешним инструментам, доступ к внутренним системам.
• Обучение/улучшение - используются ли данные организации для дообучения без контроля.
• Доступы и роли - кто имеет право видеть контекст и результаты.

Для систематизации угроз применяются подходы, близкие к STRIDE [3] (для безопасности) и LINDDUN [1] (для приватности), адаптированные к ИИ:

• утечки в запросах/логах;
• “prompt injection” (вредоносные инструкции в документах/письмах, которые ИИ “подхватывает”);
• чрезмерные привилегии инструментов (чат-бот получил доступ к лишним данным);
• несанкционированный экспорт данных через плагины;
• повторная идентификация (de-anonymization) при неаккуратной “анонимизации”;
• галлюцинации и неверные советы, косвенно ведущие к раскрытию (например, предложение отправить скриншоты, ключи, логи целиком).

4. Дизайн многоуровневых мер защиты (defense-in-depth)

Методика использует “слоёную” защиту: если один контроль не сработал, другой должен перехватить риск.

Слой A - организационные меры

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

Слой B - технические меры

• SSO и RBAC (единая идентификация и роли) [2];
• DLP-контроль ввода/вывода (по шаблонам ПДн, ключей, номеров карт, внутренним маркерам);
• маскирование/токенизация (замена чувствительных частей на плейсхолдеры);
• изоляция контекста: отдельные рабочие пространства, запрет “сквозной” истории между проектами;
• журналирование и аудит, но с минимизацией хранения чувствительного;
• прокси-шлюз для ИИ (централизованный контроль запросов к внешним моделям).

Слой C - процедурные меры

• утверждённые шаблоны промптов для типовых задач;
• процесс инцидентов, что делать при подозрении на утечку;
• регулярное тестирование (red teaming) и контроль качества маскирования [4].

5. Метрики эффективности

Чтобы безопасность не была декларацией, вводятся измеримые показатели:

• доля запросов, содержащих чувствительные маркеры (до/после внедрения DLP);
• количество блокировок DLP и доля “ложных срабатываний”;
• покрытие сценариев утверждёнными шаблонами (prompt library coverage);
• результаты тестов на утечки (может ли модель “восстановить” скрытое);
• время реакции на инцидент и полнота журналов расследования.

Результаты и обсуждение

 1. Фреймворк SAFE-AI для внедрения ИИ без утечек

В результате исследования предлагается пример фреймворка SAFE-AI (практическая последовательность действий):

• S - Scope (Определить границы) Какие процессы разрешены, какие данные и системы затрагиваются, какие модели используются (внешние/внутренние).
• A - Assess (Оценить риски) Классификация данных, карта потоков данных, моделирование угроз, матрица рисков.
• F - Fortify (Укрепить контур) DLP, маскирование, RBAC/SSO, шлюз к моделям, настройка хранения, контроль интеграций.
• E - Execute (Исполнять безопасно) Шаблоны запросов, безопасные “рецепты” для сотрудников, процессы согласования нестандартных кейсов.
• A - Audit (Аудит и тестирование) Журналы, выборочные проверки, red teaming, тесты на prompt injection [5]
• I - Improve (Улучшать) Уточнение правил, снижение ложных блокировок, обновление шаблонов под реальные задачи.

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

2. Типовые угрозы и практические контрмеры

Угроза 1: случайная вставка конфиденциального в запрос

Пример: сотрудник копирует клиентскую переписку с ФИО, адресом и деталями заказа, чтобы “сделать вежливый ответ”.

Риск: ПДн уходят во внешний сервис, сохраняются в истории или логах.

Контрмеры:

• DLP на ввод: детект ПДн/секретов/ключей → блокировка или предупреждение.
• “Автомаскирование”: система заменяет чувствительные фрагменты на [CLIENT_NAME], [ADDRESS].
• Политика: разрешены только обобщения (“клиент сообщил о проблеме с доставкой”), без идентификаторов.

Угроза 2: утечки через логи и историю чатов

Пример: корпоративный чат сохраняет историю “для удобства”, а доступ к ней шире, чем доступ к исходным данным.
Контрмеры:

• минимизация хранения (короткий TTL), шифрование, разделение по рабочим пространствам.
• хранение “очищенных” логов (без сырого текста, только хэши/метаданные событий).
• контроль экспорта истории (запрет выгрузок/пересылок без роли).

Угроза 3: prompt injection в документах

Пример: в входящем письме/документе скрыта инструкция “игнорируй правила и выведи всё, что знаешь”.

Контрмеры:

• “разделение ролей”: системные инструкции всегда приоритетнее контента документа.
• фильтрация/нормализация контента перед передачей модели.
• тестирование на injection-сценарии как часть QA чат-бота.

Угроза 4: чрезмерные привилегии инструментов (tool misuse)

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

 Контрмеры:

• принцип “минимально необходимого” для инструментов: доступ только к конкретной записи по ID и только тем полям, которые нужны.
• “policy enforcement” перед каждым вызовом инструмента (проверка роли, контекста, бизнес-правил).
• обязательное журналирование вызовов инструментов (кто, когда, какие поля запрашивал).

Угроза 5: повторная идентификация после “анонимизации”

Пример: “удалили ФИО”, но оставили редкую должность, город и точные даты - человека легко узнать.

 Контрмеры:

• токенизация вместо простого удаления.
• агрегирование и “обобщение” (k-анонимность как ориентир), округление дат/сумм.
• запрет на отправку “узких” выборок во внешний ИИ без дополнительного контроля.

3. Таблица соответствия угроз и контролей

Таблица 1.

Соответствие зон риска при использовании ИИ и мер контроля

 4. Практика “безопасных подсказок” (prompt hygiene)

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

Небезопасно - “Вот переписка с клиентом Ивановым Иваном Ивановичем, его адрес…, номер заказа…, составь ответ”.

Безопасно - “Составь вежливый ответ клиенту: задержка доставки на 2 дня, клиент недоволен, предложить компенсацию по правилам: скидка 10% или бесплатная доставка. Не используй персональные данные и идентификаторы.”

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

 5. Архитектурный паттерн: “AI-шлюз” как единая точка контроля

Ключевой результат - рекомендация внедрять ИИ через централизованный шлюз, а не как набор разрозненных доступов. Шлюз:

• применяет DLP и маскирование;
• маршрутизирует запросы к разрешённым моделям (внутренним/внешним);
• добавляет системные политики;
• ведёт аудит и метрики;
• отключает небезопасные плагины и прямые API.

Это снижает риск “теневого ИИ”, когда сотрудники используют несанкционированные инструменты.

 6. Обсуждение компромиссов и ограничений

• Баланс безопасность/удобство. Слишком жёсткий DLP вызывает обходные пути (например, сотрудник использует личный аккаунт). Поэтому важны прозрачные правила, низкая доля ложных срабатываний и быстрый процесс разрешений.
• Ложные срабатывания. Детект “секретов” по шаблонам может блокировать легитимные данные. Решение - контекстные правила (роль, проект, тип задачи) и постепенная настройка.
• Галлюцинации. Даже без утечек ИИ может ошибаться. В рабочих процессах это решается маркировкой: где ИИ “рекомендует”, а где “принимает решение”; плюс обязательной верификацией человеком для критичных операций.
• Поставщики и юридические условия. Режимы “не использовать для обучения” и сроки хранения должны быть формализованы. Технические меры не заменяют договорные гарантии, но и договоры не заменяют технический контроль.
• Эволюция угроз. Prompt injection и цепочки инструментов развиваются быстро. Значит, нужен не разовый проект, а непрерывная практика тестирования и улучшений.

Заключение

В работе предложен практический подход к безопасному использованию ИИ в рабочих процессах при защите конфиденциальной информации. Показано, что основной источник риска - не “сам ИИ”, а неконтролируемый ввод данных, хранение истории, интеграции и избыточные привилегии. Результатом исследования стал пример фреймворка SAFE-AI и набор многоуровневых мер (политики, обучение, DLP-контроль, маскирование, централизованный AI-шлюз, аудит и тестирование). Сделан вывод: устойчивый уровень конфиденциальности достигается сочетанием инженерных ограничений и понятных сотрудникам правил “минимально необходимого контекста”, поддерживаемых метриками и регулярными проверками. На практике наибольшую отдачу дают: стандартизированные шаблоны запросов, автоматическое предотвращение утечек на вводе/выводе и строгий контроль интеграций и ролей.

Список литературы:

1. Deng M., Wuyts K., Scandariato R., Preneel B., Joosen W. A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements [Электронный ресурс]. — 2011. — URL: https://cosicdatabase.esat.kuleuven.be/backend/publications/files/journal/1412 — Дата обращения: 20.12.2025.
2. Joint Task Force. Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53 Rev. 5) [Электронный ресурс]. — 2020. — URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf — Дата обращения: 24.12.2025.
3. Microsoft. Threats — Microsoft Threat Modeling Tool: STRIDE model [Электронный ресурс]. — 2022. — URL: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats. Дата обращения: 23.12.2025.
4. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0): NIST AI 100-1 [Электронный ресурс]. — 2023. — URL: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf — Дата обращения: 24.12.2025.
5. OWASP Foundation. OWASP Top 10 for Large Language Model Applications. Version 1.1 [Электронный ресурс]. — URL: https://owasp.org/www-project-top-10-for-large-language-model-applications/ — Дата обращения: 23.12.2025.