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

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

Николай Павлов — архитектор MLSecOps и AI Governance, участник разработки ГОСТов и законопроектов по ИИ в РФ

Ключевой принцип защиты

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

Трёхуровневая архитектура доверия

1. Юридический уровень

При заключении договора с облачным провайдером необходимо зафиксировать основные юридические меры защиты:

• запрет на использование ваших данных для дообучения моделей;

• обязательство удалить данные сразу после обработки;

• право на внеплановый аудит;

• требование вести и хранить логи операций;

• готовность провайдера предоставить эти логи по вашему запросу в любое время.

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

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

Как дополнительную меру важно прописать в договоре SLA по инцидентам и возможные штрафные санкции, то есть зафиксировать сроки уведомления (например, от 1 ч до 12 ч по внутренним правилам согласно договору, и как минимум 72 ч по ФЗ №152). В идеале прописать и финансовую ответственность за нарушение запрета на обучение или утечку, как следствие - право на одностороннее расторжение без компенсаций в случае доказанных утечек.

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

2. Технический уровень: шлюз-фильтр

3. Уровень аудита и соответствия требованиям регуляторов

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

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

Практический сценарий безопасного шаринга

В заключение отметим, что на практике возможно применить подход, при котором конфиденциальные данные никогда не покидают локальный контур:

• внутренние документы индексируются в локальной векторной базе данных;

• при поступлении запроса система ищет релевантные фрагменты локально;

• в облачную LLM отправляется только промпт вида: «На основе предлагаемого контекста ответь на вопрос...», где контекст уже отфильтрован от персональных данных и коммерческой тайны;

• ответ модели возвращается, проходит проверку и доставляется пользователю.

Важные принципы такого сценария:

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

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

• локальное хранение эмбеддингов исключает их попадание в публичные датасеты.

Николай Павлов
Архитектор MLSecOps и AI Governance 
Telegram 
VK