Я потратил годы на внедрение комплаенса в продукты безопасности. Авторизации FedRAMP и Уровня воздействия Министерства обороны, конвейеры управления уязвимостями: все они следуют одной схеме. Сначала создаешь продукт, а затем доказываешь, что он соответствует требованиям. Слой комплаенса находится вне рабочего процесса разработки. Он проверяет то, что уже существует.
Эта модель работала, когда продукт оставался статичным между аудитами. Она не работает для ИИ.
Системы ИИ меняются, даже если базовая модель остается прежней. Индекс поиска обновляется за ночь. В пространство действий агента добавляется новый инструмент. Оценка, пройденная во вторник, уже не отражает того, что система делает в четверг. Подход «комплаенс как проверка» предполагает, что объект проверки остается неизменным между циклами проверки. Для ИИ это предположение в корне неверно. Большинство организаций, с которыми я общаюсь, все еще пытаются управлять ИИ так же, как традиционным программным обеспечением: создать, выпустить, а затем попросить юристов поставить галочку. Для ИИ это оставляет процесс выпуска слепым к тому, что, скорее всего, изменится.
Когда я начал исследовать, как другие страны решают эту проблему для моей предстоящей книги об экосистеме ИИ в Китае, я обнаружил нечто, что поколебало мои представления. Китайские компании, занимающиеся ИИ, не рассматривают управление как ворота, которые они проходят после того, как модель заработала. Они рассматривают его как инфраструктуру выпуска: контрольные точки комплаенса, встроенные непосредственно в конвейер развертывания. Нет разрешения контрольной точки — нет запуска продукта. Слой управления не проверяет продукт. Он является частью продукта.
В одном обзоре развертывания ИИ, в котором я участвовал, у продуктовой команды было все, что обычно поощряется на совещании по запуску: показатели производительности, сценарии использования клиентами, данные о задержках и твердая дата выпуска. Отсутствовали некие недостающие элементы, которых не было ни в чьем списке. Никто не мог указать на текущую, сгенерированную конвейером запись индекса поиска, питающего модель. Никто не владел пороговыми значениями мониторинга вывода. Никто не связал результаты оценки модели с принудительным шлюзом выпуска. Команда не игнорировала управление. У управления просто не было места в фактическом процессе выпуска.
Слой проверки уже терпит неудачу
Эта сцена не является чем-то необычным. Когда управление находится вне рабочего процесса разработки, оно конкурирует со сроками поставки. Сроки поставки выигрывают каждый раз. Структура управления рисками ИИ NIST определяет управление, картирование, измерение и администрирование как основные функции для управления рисками ИИ, но не предписывает, где эти функции располагаются в процессе выпуска. Это оставляет сложный архитектурный вопрос на усмотрение организации по безопасности. Большинство компаний по умолчанию выбирают то, что им знакомо: периодический цикл проверки, заимствованный из традиционного ИТ-комплаенса. Этот цикл был разработан для систем, которые остаются неподвижными между аудитами.
Системы ИИ не остаются неподвижными. Модель, дообученная на клиентских данных прошлого квартала, выдает иные результаты, как только данные этого квартала попадают в конвейер. Система генерации с дополненным поиском выдает разные ответы в зависимости от того, какие документы находятся в ее индексе сегодня по сравнению со вчера. Агентский рабочий процесс, связывающий три модели вместе, порождает эмерджентное поведение, которое не может уловить оценка одной модели. Управление в виде периодической проверки было создано для мира, где объект проверки не меняется. Мы развертываем артефакты, которые меняются непрерывно.
Разрыв между скоростью эволюции систем ИИ и медлительностью циклов управления на уровне проверки — это основная уязвимость. Каждую неделю этот разрыв увеличивается, и организации накапливают «долг управления», который им в конечном итоге придется погасить либо на своих условиях, либо на условиях регулятора.
Как выглядит инфраструктура выпуска на практике
Когда я исследовал процесс развертывания ИИ в Китае, я ожидал увидеть жесткую систему утверждений, которая замедляет компании. Я увидел обратное.
Китай требует, чтобы компании, развертывающие генеративный ИИ, заполнили регуляторную заявку до того, как их продукт попадет к потребителям. Заявка требует документации об источниках обучающих данных, механизмах обеспечения безопасности контента, контроле вывода и раскрытии информации для пользователей. Компании, прошедшие процесс, выпускаются. Компании, которые этого не сделали, ждут.
Что меня удивило, так это скорость. Baidu выпустила Ernie Bot для широкой публики 31 августа 2023 года, через шестнадцать дней после вступления в силу правил Китая о генеративном ИИ. Десятки компаний последовали их примеру в течение нескольких недель. Процесс подачи заявки не остановил развертывание. Он отсортировал компании по тем, кто уже построил механизмы сбора доказательств для прохождения. Фирмы, которые рассматривали комплаенс как юридическое упражнение на последнем этапе, отстали.
Этот вывод важен для западных руководителей служб безопасности. Нам не следует копировать регуляторную модель Китая. Однако лежащая в основе операционная проблема идентична. Закон ЕС об ИИ приходит к тому же выводу из другой регуляторной традиции: его требования к оценке соответствия и постоянному управлению рисками для систем ИИ высокого риска предполагают непрерывное соответствие, а не однократную сертификацию. Операционный вопрос, который разделяют обе структуры, тот же, с которым я сталкиваюсь в своей работе: где в процессе разработки на самом деле находится управление? Если ответ: «после того, как модель обучена и до того, как она будет выпущена», вы воссоздали узкое место слоя проверки. Инженерные команды найдут способы обойти это.
Я видел ту же закономерность с SBOM. Когда команды рассматривали SBOM как документ, который кто-то собирает для опросника клиента, он устаревал почти немедленно. Когда они генерировали его из конвейера сборки, он становился частью текущей операционной записи продукта. Документация модели должна двигаться так же. Карточка модели, написанная вручную после выпуска, — это снимок. Карточка модели, сгенерированная из конвейера, — это доказательство.
Три сдвига, которые руководители служб безопасности должны предпринять немедленно
Я начал применять этот принцип в своей работе и в том, как я консультирую команды, оценивающие готовность к развертыванию ИИ. Три операционных сдвига имеют решающее значение.
Во-первых, переместите документацию модели в конвейер CI/CD. Относитесь к карточкам моделей, записям о происхождении обучающих данных и базовым показателям поведения вывода так же, как к SBOM: как к артефактам, автоматически генерируемым в процессе сборки, а не как к документам, написанным аналитиком по комплаенсу постфактум. Если ваша документация модели не версионируется вместе с кодом, она уже устарела. Каждый цикл переобучения модели, который не приводит к обновлению артефактов комплаенса, увеличивает ваш разрыв в управлении.
Во-вторых, сделайте доказательства комплаенса шлюзом развертывания, а не элементом аудита после запуска. Ваш конвейер выпуска, вероятно, уже блокирует развертывание, если не проходят модульные тесты или если образ контейнера несет критическую уязвимость. Добавьте контрольные точки управления ИИ в тот же конвейер. Прошла ли модель текущую оценку рисков по пороговым значениям, определенным вашей организацией? Документировано ли и прослеживается ли происхождение обучающих данных? Настроены ли, протестированы ли и контролируются ли средства управления выводом? Если ответ на любой из этих вопросов отрицательный, развертывание не продолжается. Конвейер уже блокирует уязвимые контейнеры. Контрольные точки управления ИИ должны находиться в том же слое. Это расширение вашей существующей архитектуры безопасности для охвата нового класса рисков.
Проблема обостряется, когда система ИИ перестает генерировать рекомендации и начинает предпринимать действия. В-третьих, рассматривайте идентификацию агента как первоклассный элемент контроля безопасности. По мере того как агенты ИИ переходят в производственные среды, каждому из них требуется идентификатор в вашей системе IAM с ограниченными разрешениями, аудиторскими журналами и подотчетностью на уровне сеанса. Агент, вызывающий внешние API, считывающий данные клиентов или запускающий автоматизированные рабочие процессы, является действующим лицом в вашей среде. Он требует такого же управления идентификацией, которое вы применяете к пользователям-людям и служебным учетным записям. Ранее в этом году я писал здесь, на CSO, о проблемах с идентификацией и сохранением в операциях скрытого программ-вымогателя. Применимы те же принципы: если вы не можете идентифицировать действующее лицо, вы не можете управлять действием.
Ничто из этого не требует ожидания регулирования. Организации, которые будут в наилучшем положении, когда появятся нормативные акты, специфичные для ИИ, будь то сроки вступления в силу Закона ЕС об ИИ, новое законодательство штатов США в Колорадо и Калифорнии или отраслевые правила от финансовых и медицинских регуляторов, — это те, кто уже встраивает управление в свою инфраструктуру выпуска. Те, кто все еще рассматривает его как слой проверки, будут судорожно пытаться доработать то, что их конкуренты уже выпускают.
Я усвоил этот урок, изучив, как очень разная система решила эту проблему первой. Регуляторные традиции различны. Операционная логика одна и та же: управление, которое поставляется с продуктом, лучше управления, которое проверяет его постфактум.
Эта статья публикуется в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Collin Hogue-Spears
