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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пайплайн данных строится по принципу фильтрации на вашей стороне:

+ перед отправкой в облако информация проходит через локальный шлюз, который автоматически находит и маскирует конфиденциальные сведения (ФИО, номера счетов, банковских карт, паспортные данные, СНИЛС, коммерческая тайна и другие), заменяя их на специальные коды;

+ соответственно в облако уходит уже обезличенный запрос;

+ модель отрабатывает и возвращает ответ с теми же кодами;

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

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

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

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

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

+ ведение полного журнала событий: фиксация, какие данные, в каком виде и когда передавались;

+ гарантия физического размещения серверов в российской юрисдикции;

+ регулярная проверка и хранение логов.

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

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

Ссылка на полную версию статьи (смотреть без VPN): https://academyit.ru/articles/tematika3/bezopasnaya-integratsiya-s-oblachnymi-ii-modelyami-kak-zashchitit-dannye-pri-peredache-v-oblako/

Архитектор MLSecOps и AI Governance

Николай Павлов

Телеграм: t.me/ainewsline

Источник: academyit.ru

Комментарии: