Самый безопасный запрос к AI — не тот, где длиннее предупреждение о конфиденциальности. Это запрос, в который вообще не попали лишние данные.
Поэтому защита информации начинается до обращения к модели. Система должна определить тип данных, права пользователя, необходимые поля, места появления копий и срок их удаления.
Сначала нарисуйте полный путь данных
Отметьте путь от системы-источника до пользователя: временные файлы, очереди, prompts, найденные фрагменты, ответы модели, логи, аналитику и экран проверки человеком. Надёжный договор с поставщиком не защищает забытый экспорт на ноутбуке разработчика.
Руководство ICO по безопасности AI и минимизации данных рекомендует документировать перемещение и хранение персональной информации и удалять промежуточные файлы, когда они больше не нужны.
Для каждого компонента укажите владельца, цель, категории данных, расположение, срок хранения, субподрядчиков и способ удаления.
Классифицируйте данные до prompt
Небольшой компании не нужна громоздкая схема. Для работы часто достаточно четырёх уровней: публичные, внутренние, конфиденциальные и ограниченные данные.
- Публичные данные можно передавать одобренным инструментам под обычным контролем.
- Внутренние требуют корпоративной учётной записи и правил хранения.
- Конфиденциальные требуют описанного сценария, владельца и минимальных прав.
- Ограниченные данные — пароли, исходные документы личности или защищённая медицинская информация — блокируются без специально одобренной архитектуры.
Минимизируйте контекст, а не только базу
Право сотрудника видеть всю карточку клиента ещё не означает, что карточку целиком нужно отправлять модели. Выберите поля для конкретной задачи, остальные уберите до поиска и генерации.
NIST AI RMF относит минимизацию, деидентификацию и агрегацию к методам поддержки приватности в AI-системах. Конкретный контроль зависит от сценария и требований к точности.
Для ответа о доставке могут понадобиться номер заказа и текущий статус. История адресов, платёжные заметки и посторонние обращения только увеличивают риск.
Оставьте авторизацию за пределами модели
Модель может предположить, какая запись релевантна. Детерминированный код приложения должен решить, имеет ли текущий пользователь право её читать.
Это особенно важно при подключении AI к CRM. Сохраняйте ограничения по компании, роли и конкретной записи. Семантическая близость не является разрешением.
Используйте отдельные сервисные учётные записи, короткоживущие ключи, узкие API scopes и явные списки разрешённых инструментов. Не помещайте секреты в prompts и системные инструкции.
Редактируйте и токенизируйте данные заранее
Редактирование должно выполняться отдельным контролируемым этапом. Найдите email, телефоны, номера счетов и стороны договора, затем удалите или замените их, если исходные значения не нужны задаче.
Токенизация полезна, когда нужно сохранить связи. Модель работает со стабильным псевдонимом, а защищённый сервис возвращает настоящее значение только после проверки.
OWASP по раскрытию чувствительной информации рекомендует очистку данных, строгий контроль доступа, ограничение источников и понятные сроки хранения. Инструкция в prompt сама по себе не является защитным контуром.
Считайте RAG новой копией знаний компании
RAG-система создаёт индексы, embeddings, фрагменты и метаданные. Эти производные активы могут раскрывать ту же информацию, что и исходные документы.
Переносите права источника в ingestion и retrieval. Разделяйте клиентов, исключайте устаревшие документы, храните идентификаторы источников и проверяйте, что пользователь не получает фрагмент закрытой для него записи.
Данные из конвейера обработки документов также должны пройти проверку полей и жизненного цикла до индексации.
Выбирайте поставщика по поведению данных
Выясните, где обрабатываются и хранятся prompts, файлы, embeddings, ответы и логи защиты от злоупотреблений. Проверьте хранение по умолчанию, использование для обучения, регион, шифрование, удаление, аудит доступа, уведомление об инцидентах и список субподрядчиков.
Зафиксируйте конкретный тариф и конфигурацию API. Потребительский чат, корпоративное пространство и API одного поставщика могут иметь разные условия.
Требования закона зависят от страны и категории данных. При работе с персональной или регулируемой информацией подключайте ответственного специалиста по приватности или юриста до запуска.
Делайте логи полезными, но не опасными
Логи должны показать, кто использовал систему, какой источник был открыт, какой инструмент вызван, было ли подтверждение человека и какая версия работала. Для этого не обязательно бесконечно хранить каждый сырой prompt.
Отделите операционные метаданные от чувствительного содержимого. Маскируйте значения, ограничивайте доступ, задайте сроки по цели и проверяйте удаление. Те же правила действуют для резервных копий и выгрузок аналитики.
Инструментарий ICO по управлению AI рекомендует картировать потоки, назначать технические и операционные роли, контролировать изменения и проводить риск-ориентированные аудиты.
Подготовьте практический план инцидента
NIST Privacy Framework помогает связать риски приватности обработки данных с существующими практиками безопасности и управления AI.
- отозвать затронутую сервисную учётную запись или API-ключ;
- отключить конкретный инструмент или процесс;
- сохранить минимально достаточные доказательства;
- определить источники, prompts, ответы, логи и получателей;
- выполнить договорные и юридические процедуры уведомления;
- исправить границу доверия и добавить регрессионный тест.
Как я отделяю секреты от автоматизации публикаций
В многоязычном конвейере публикаций bearer token используется только во время загрузки и вызовов API статей. Он не попадает в payload статьи, журнал Trello, отчёт Slack или сгенерированный исходный файл.
Публичный каталог читается отдельно для поиска дублей и внутренних ссылок. Права записи появляются только на точных шагах загрузки, создания черновика и полного обновления, а каждый ответ проверяется до продолжения.
Это небольшой пример, но принцип масштабируется: рабочий контекст проходит по процессу, а пароли и посторонние записи — нет.
Вопросы и ответы
Можно ли сотрудникам вставлять конфиденциальные данные в корпоративный AI?
Только если компания одобрила именно этот продукт, категорию данных и сценарий. Корпоративная подписка не заменяет классификацию, минимизацию и права доступа.
Достаточно ли шифрования?
Нет. Шифрование защищает отдельные состояния и каналы, но не мешает разрешённому процессу отправить лишние данные или вернуть их не тому пользователю.
Нужно ли хранить каждый prompt для аудита?
Не всегда. Храните минимум доказательств для эксплуатации, безопасности и требований закона, а чувствительные payloads ограничивайте отдельным сроком.
Безопасны ли embeddings, поскольку это не обычный текст?
Нет. Считайте embeddings и индексы производными чувствительными активами. Ограничивайте доступ и тестируйте retrieval по правам источника.
С чего начать малому бизнесу?
Опишите один процесс, классифицируйте данные, уберите лишние поля, назначьте владельца и проверьте обычный доступ и попытку получить чужую запись.