Практика внедрения · 14 минут на чтение

Безопасность данных при внедрении ИИ: чек-лист для бизнеса

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

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

Сначала определить границы ИИ-системы

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

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

1. Пользователь. Кто отправляет запрос: клиент, менеджер, оператор поддержки или руководитель.
2. Вход. Какие сообщения, документы и поля получает система.
3. Источники. Из каких баз знаний и рабочих систем она извлекает сведения.
4. Выход. Что увидит пользователь и что будет записано в другие системы.
5. Действие. Может ли ассистент только предложить ответ или способен отправить сообщение, изменить карточку, создать платёж либо выполнить другую операцию.

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

Карта данных: что действительно нужно системе

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

Минимизировать данные до отправки в модель

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

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

Базовые защитные меры

1. Разделить роли и выдать минимальные права

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

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

2. Изолировать клиентов, отделы и среды

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

3. Шифровать передачу и защищать секреты

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

4. Настроить управляемое хранение

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

5. Вести полезный журнал действий

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

Риски, характерные для ИИ-приложений

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

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

Для модели угроз можно использовать актуальный перечень рисков OWASP Top 10 for LLM and GenAI Applications. Для более широкого управления рисками — материалы NIST AI Risk Management Framework. Эти документы помогают структурировать проверку, но не заменяют требования, применимые к конкретной компании и данным.

Что спросить у поставщика модели или платформы

1. Где обрабатываются и хранятся данные? Нужны регионы, компоненты и привлечённые поставщики, а не только адрес головной компании.
2. Используются ли запросы и ответы для обучения или улучшения сервиса? Уточните режим продукта, настройки и исключения.
3. Какие журналы создаются и каков срок их хранения? Отдельно спросите про файлы, кэш, резервные копии и обращения в поддержку.
4. Как устроены удаление и выгрузка? Проверьте, можно ли удалить данные проекта и подтвердить завершение процедуры.
5. Какие средства контроля доступны? Роли, единый вход, многофакторная аутентификация, аудит, сетевые ограничения, ключи клиента и оповещения.
6. Как сообщают об инцидентах и изменениях? Нужны канал, срок уведомления, ответственные и порядок сохранения доказательств.
7. Какие действия доступны модели? Важно отделить генерацию текста от автономного доступа к почте, CRM, файлам и внешним сайтам.

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

Тесты перед запуском

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

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

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

Чек-лист безопасного пилота

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

Достаточно ли запретить модели использовать персональные данные?

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

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

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

Нужно ли сохранять все диалоги для улучшения качества?

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

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

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