Архитектура безопасного ИИ. Риски, управление и защита искусственного интеллекта
- -
- 100%
- +
Для каждой ИИ-системы в реестре следует фиксировать набор атрибутов, которые позволяют оценить риски, определить ответственных и отследить изменения. Идентификатор и название системы — кажется очевидным, но в организации, где десятки команд используют разные модели, отсутствие единой номенклатуры быстро создаёт путаницу. Назначение и бизнес-процесс: какую задачу решает система и в каком контексте. Тип системы: LLM, компьютерное зрение, предиктивная модель, мультимодальная система, агент — классификация из второй главы. Происхождение модели: собственная разработка, дообученная внешняя модель, внешний сервис через API, модель из открытого репозитория. Способ развёртывания: облако поставщика, собственная инфраструктура, гибридный вариант, периферийное устройство. Данные: какие категории данных обрабатывает система, содержат ли они персональные сведения, коммерческую тайну или иную чувствительную информацию. Интеграции: с какими корпоративными системами связана, через какие протоколы, с какими полномочиями. Владелец системы и владелец рисков. Уровень автономности: система рекомендует, система решает с подтверждением человеком, система действует автономно. Дата развёртывания и дата последнего обновления. Результаты оценки рисков: уровень риска, принятый остаточный риск, дата последней оценки.
Перечень атрибутов может показаться длинным, но большинство из них заполняются один раз при включении системы в реестр и обновляются при изменениях. Организация, которая пытается собрать всю информацию одновременно для всех систем, рискует увязнуть в проекте инвентаризации на месяцы. Более работоспособный подход — начать с минимального набора (название, назначение, тип, владелец, уровень риска) и расширять записи постепенно, начиная с систем высокого риска. Реестр, заполненный на 70% для всех систем, полезнее, чем реестр, заполненный на 100% для трёх систем из двадцати.
Ведение реестра — процесс, а не разовое мероприятие. Новые ИИ-системы должны включаться в реестр до развёртывания, а не после. Процедура утверждения новых сценариев, описанная в разделе 5.2, должна включать обязательную регистрацию в реестре как условие запуска. Изменения в существующих системах — обновление модели, расширение полномочий, изменение обрабатываемых данных — должны отражаться в реестре через процесс управления изменениями. Вывод системы из эксплуатации должен сопровождаться обновлением статуса в реестре, а не молчаливым исчезновением записи. Без этих процессов реестр устаревает в течение нескольких месяцев и превращается в исторический документ, не отражающий действительность.
Отдельная задача — определить, где вести реестр. Некоторые организации расширяют существующий реестр ИТ-активов или CMDB (Configuration Management Database), добавляя ИИ-специфические поля. Другие создают отдельный реестр, связанный с CMDB через ссылки. Третьи используют специализированные платформы для управления ИИ-портфелем. Выбор инструмента менее важен, чем три принципа: реестр должен быть единым (одна запись для каждой системы, а не дублирование в нескольких подразделениях), доступным (ответственные за безопасность, управление рисками и соответствие могут получить информацию без запроса к владельцу) и актуальным (процессы обновления встроены в жизненный цикл системы).
На практике самым сложным оказывается не выбор формата и не определение атрибутов, а обнаружение систем, которые уже работают, но о которых центральные подразделения не знают. Об этом — в следующем разделе.
6.2. Теневой ИИ: как обнаружить и взять под контроль
Теневой ИИ (Shadow AI) — это использование ИИ-систем и сервисов в организации без ведома, согласования или контроля со стороны подразделений, ответственных за информационные технологии, безопасность и управление рисками. Термин образован по аналогии с теневыми ИТ (Shadow IT), но масштаб проблемы и скорость её нарастания существенно выше. Облачный сервис для хранения файлов, подключённый сотрудником без согласования, создавал риск утечки данных. Генеративная модель, в которую сотрудник вводит конфиденциальные документы организации для получения сводки, создаёт тот же риск, но с двумя отличиями: данные передаются третьей стороне мгновенно и могут быть использованы для дообучения модели, то есть встроены в её параметры навсегда.
Причины возникновения теневого ИИ понятны. Генеративные модели доступны любому сотруднику через браузер без установки программного обеспечения и без согласования с ИТ. Они дают ощутимый результат за секунды: черновик документа, анализ таблицы, ответ на сложный вопрос, перевод текста. Сотрудник, который обнаружил, что внешний ИИ-сервис экономит ему час работы ежедневно, не будет ждать, пока организация сформулирует политику и выберет корпоративное решение. Он начнёт использовать сервис сейчас, и вопросы безопасности для него вторичны, потому что он не видит рисков, которые видит специалист по ИБ.
К индивидуальному использованию добавляется подразделенческое. Маркетинг подключает генеративную модель для создания контента. HR использует внешний сервис для предварительного анализа резюме. Юридический отдел загружает контракты во внешнюю LLM для быстрого анализа условий. Каждое подразделение решает свою задачу и не считает нужным информировать ИТ или безопасность, потому что воспринимает ИИ-сервис как рабочий инструмент, аналогичный поисковой системе. Между тем данные, которые попадают в эти сервисы, могут включать персональные сведения клиентов, коммерческую тайну, стратегические планы и юридически привилегированную информацию.
Третий источник теневого ИИ — встроенные ИИ-функции в закупленных продуктах. Поставщик офисного пакета добавляет ИИ-ассистента при очередном обновлении. Платформа для управления проектами интегрирует генеративную модель для автоматического создания отчётов. CRM-система получает функцию предиктивного анализа клиентской базы. Эти функции активируются по умолчанию или включаются администратором подразделения без оценки рисков. Организация может не знать, что её данные обрабатываются ИИ-моделью, встроенной в продукт, который она использует уже несколько лет.
Обнаружение теневого ИИ требует сочетания технических и организационных мер. Ни одна из них по отдельности не даёт полной картины.
Технические методы обнаружения начинаются с анализа сетевого трафика. Обращения к известным ИИ-сервисам (API-эндпоинты поставщиков LLM, домены генеративных платформ) можно выявить через прокси-серверы, системы мониторинга трафика и DLP-решения. Это позволяет обнаружить случаи, когда сотрудники обращаются к внешним ИИ-сервисам с корпоративных устройств. Ограничение метода в том, что он не покрывает использование с личных устройств, через мобильные приложения или через VPN, а также не выявляет ИИ-функции, встроенные в уже разрешённые сервисы.
Анализ закупок и подписок помогает обнаружить подразделенческий теневой ИИ. Если подразделение оплачивает подписку на ИИ-сервис через корпоративную карту или запрашивает бюджет на «инструменты повышения продуктивности», это может указывать на использование ИИ, не прошедшего оценку. Финансовый контроль закупок, дополненный ключевыми словами, связанными с ИИ, создаёт ещё один канал обнаружения.
Рисунок 17. Три основных канала появления теневого ИИ: самостоятельное использование публичных сервисов, неучтённые интеграции и встроенные функции корпоративных продуктов.
Аудит установленного ПО и браузерных расширений выявляет клиентские приложения ИИ-сервисов и плагины, которые сотрудники устанавливают на рабочие станции. Многие ИИ-ассистенты работают как расширения браузера и перехватывают содержимое веб-страниц, электронных писем и документов, открытых в браузере. Организация может обнаружить, что десятки сотрудников используют браузерные расширения, которые передают содержимое экрана внешнему ИИ-сервису для анализа.
Проверка конфигураций закупленных продуктов позволяет выявить ИИ-функции, активированные в существующих системах. Это требует систематического пересмотра продуктов, используемых организацией, на предмет появления ИИ-компонентов в последних обновлениях. Задача непростая, потому что поставщики добавляют ИИ-функции в свои продукты непрерывно, и каждое обновление может изменить способ обработки данных.
Организационные методы обнаружения не менее важны. Опрос подразделений — прямой способ выяснить, какие ИИ-инструменты используются на местах. Опрос работает лучше, когда он проводится в формате помощи, а не контроля: «мы хотим понять, какие инструменты вам полезны, чтобы предложить безопасные корпоративные альтернативы» вместо «мы проверяем, не нарушаете ли вы политику». Угрожающий тон загоняет использование в тень ещё глубже.
Канал добровольного сообщения, описанный в разделе 5.3, тоже работает на обнаружение. Если сотрудники знают, что могут сообщить об использовании ИИ-инструмента без негативных последствий, часть теневого ИИ выявляется через самодекларацию.
Для этого необходима культура, в которой использование нового инструмента воспринимается как инициатива, заслуживающая оценки, а не как нарушение, заслуживающее наказания.
Обнаружив теневой ИИ, организация стоит перед выбором: запретить, легализовать или заменить. Полный запрет редко оказывается устойчивым решением. Если сотрудник получает ощутимую пользу от ИИ-инструмента, запрет без предложения альтернативы вызывает сопротивление и обход. Более зрелый подход — оценить обнаруженные сценарии использования, определить, какие из них создают приемлемый риск при соблюдении условий, и предложить корпоративную альтернативу для остальных.
Корпоративные версии ИИ-сервисов с контролем данных, ограничением на использование запросов для дообучения, журналированием и интеграцией с системами безопасности организации — это вариант, который всё чаще выбирают зрелые организации. Он позволяет сохранить продуктивность сотрудников, взяв под контроль потоки данных. Стоимость корпоративной подписки сопоставима с потерями от одного инцидента утечки данных через неконтролируемый внешний сервис.
Для сценариев, которые создают неприемлемый риск (передача персональных данных клиентов, использование ИИ для принятия решений о людях без человеческого контроля, обработка юридически привилегированной информации), запрет должен быть подкреплён техническими контролями: блокировка доступа к определённым сервисам, DLP-правила, контроль браузерных расширений. Запрет, существующий только в тексте политики и не подкреплённый техническими мерами, остаётся пожеланием.
Теневой ИИ — это не разовая проблема, которую можно решить одной кампанией инвентаризации. Новые ИИ-сервисы появляются ежемесячно. Поставщики встраивают ИИ в существующие продукты при каждом обновлении. Сотрудники находят новые инструменты и применяют их в работе. Организация должна выстроить непрерывный процесс обнаружения, который сочетает технический мониторинг, периодические опросы подразделений, контроль закупок и пересмотр конфигураций закупленных продуктов. Этот процесс интегрируется с ведением реестра, описанным в предыдущем разделе: каждая обнаруженная система проходит через процедуру оценки и либо включается в реестр с соответствующими контролями, либо блокируется с предложением альтернативы.
6.3. Классификация по уровню риска: критерии и методы
Реестр даёт организации видимость. Классификация даёт приоритеты. Когда в реестре двадцать ИИ-систем и ресурсы ограничены, организация не может применить одинаковый уровень контролей ко всем. Чат-бот, рекомендующий статьи для внутренней базы знаний, и модель, оценивающая кредитоспособность заёмщиков, создают принципиально разные уровни риска и требуют принципиально разного внимания. Классификация по уровню риска определяет, какие системы проходят полную оценку рисков и тестирование безопасности, какие требуют утверждения на уровне руководства, а какие могут быть развёрнуты по упрощённой процедуре.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.