Как защищать данные при внедрении ИИ

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

Содержание

1. Кому актуален этот подход
2. Признаки риска
3. Экономика контроля
4. Варианты архитектуры
5. Готовый сервис или свой контур
6. Схема движения данных
7. План внедрения
8. Ошибки и чек-лист
9. FAQ

Кому актуально

Практически любому проекту, который обрабатывает внутренние документы, переписку, звонки, клиентские обращения, договоры, данные сотрудников или коммерческие справочники. Риск возникает не только у «секретных» систем. Даже без очевидных персональных данных набор названий, объёмов, цен и дат может раскрывать отношения с контрагентом или планы компании.

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

Особое внимание требуется, если система:

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

Признаки незрелого контура

Первый сигнал — никто не может нарисовать путь одного документа. Второй — тестовая команда использует реальные выгрузки «для удобства», но не знает, где появились копии. Третий — модель подключена под общей технической учётной записью с широкими правами. Четвёртый — удаление документа из исходной папки не удаляет его из поискового индекса.

Проверьте вопросы:

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

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

Экономика безопасности: оценивать ожидаемый риск

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

| Сценарий, условный пример | Вероятность за год до мер | Условный ущерб | Остаточная вероятность после мер | Ожидаемое снижение риска | |---|---:|---:|---:|---:| | Избыточная выдача внутреннего документа | 10% | 1 000 000 ₽ | 2% | 80 000 ₽ | | Случайная отправка лишнего поля поставщику | 15% | 400 000 ₽ | 3% | 48 000 ₽ | | Неверное автоматическое действие | 20% | 250 000 ₽ | 5% | 37 500 ₽ |

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

К полной стоимости защиты относятся:

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

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

Варианты архитектуры

Обработка открытых или обезличенных данных

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

Управляемый внешний сервис

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

Выделенный контур

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

Гибридная схема

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

Что можно доверить готовому сервису

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

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

Текстовая схема движения данных

[Пользователь / системное событие]
                 │
                 ▼
       [Аутентификация и роль]
                 │
                 ▼
 [Политика цели: какие поля и действия разрешены]
                 │
                 ▼
 [Фильтрация / маскирование / защита от вредного ввода]
                 │
        ┌────────┴────────┐
        ▼                 ▼
 [Допустимый контур]   [Запрет / ручная обработка]
        │
        ▼
 [Модель + только разрешённые источники]
        │
        ▼
 [Проверка ответа и полномочий действия]
        │
   ┌────┴─────┐
   ▼          ▼
[Черновик] [Подтверждённое действие]
   └────┬─────┘
        ▼
[Журнал без лишних данных + мониторинг + срок удаления]

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

План внедрения

1. Ограничить сценарий

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

2. Создать карту данных

Для каждого элемента отметьте источник, класс, владельца, цель, получателя, место обработки, копии, срок и способ удаления. Отдельно нанесите секреты, вложения, метаданные и журналы.

3. Сформировать модель угроз

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

4. Выбрать минимальные права

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

5. Подготовить тесты

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

6. Запустить в режиме черновика

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

7. Организовать эксплуатацию

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

Частые ошибки

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

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

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

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

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

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

Чек-лист

• [ ] Сценарий, пользователи и действия ограничены.
• [ ] Создана карта данных и копий.
• [ ] У каждого набора есть владелец и цель.
• [ ] Передаётся минимально необходимый состав.
• [ ] Права проверяются вне модели.
• [ ] Чтение, черновик и действие разделены.
• [ ] Проверены условия и настройки поставщика.
• [ ] Источники фильтруются по роли до извлечения.
• [ ] Ответ проверяется перед показом и действием.
• [ ] Журнал не превращается в лишнее хранилище.
• [ ] Протестированы атаки, ошибки и повторные события.
• [ ] Есть отзыв доступа, удаление и план инцидента.

Частые вопросы

Можно ли использовать публичный AI-сервис с корпоративными данными?

Решение принимают после проверки конкретного сервиса, настроек, условий и требований компании. Без такой проверки безопасный вариант — не передавать чувствительные данные и использовать обезличенный тестовый набор.

Достаточно ли удалить имя клиента?

Нет. Идентифицирующими могут быть адрес, реквизиты, номер объекта, редкое событие и их комбинация. Нужен анализ всего набора и контекста.

Что важнее: размещение или права?

Безопасность складывается из слоёв. Размещение влияет на маршрут и хранение, права — на допустимый доступ, а фильтры и подтверждение — на использование. Ни один слой не заменяет остальные.

Как тестировать утечки через ответы?

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

Следующий шаг

Перед пилотом нарисуйте путь одного реального объекта данных и отметьте все копии и права. Запросить разбор безопасного AI-контура — UNIT AI поможет связать цель процесса, архитектуру, человеческий контроль и проверяемые меры защиты.