Меры контроля корпоративного ИИ могут быть важнее передовых моделей

Забудьте о передовом крае развития ИИ. Клиенты требуют от компаний усилить контроль над уже используемым ИИ, а опыт применения PCI DSS может послужить полезным примером.

Период снисходительного отношения к регулированию ИИ закончился. Недавние заявления вызвали дискуссии о замедлении развития передовых моделей и введении обязательных мер контроля. По одному из немногих вопросов существует согласие: такие меры должны применяться вне самих моделей, а их соблюдение должно проверяться независимо.

Дальнейшие шаги пока обсуждаются, но регуляторы уже действуют. Закон Европейского союза об искусственном интеллекте вводит требования к безопасности поэтапно, в том числе предусматривая ответственность покупателей. В США система управления рисками ИИ NIST становится стандартом должной осмотрительности. Во всем мире OWASP Top 10 для приложений на основе LLM стал общепринятым ориентиром при проверках безопасности, а сертификация по ISO/IEC 42001 появляется в закупочной документации.

Это значит, что ответственность лежит не только на разработчиках моделей. Обязанности по обеспечению безопасности и связанные с ней риски распространяются и на компании, использующие уже выпущенные модели, особенно в сценариях с высоким уровнем риска. Неправильные ответы в анкете клиента по безопасности или в заявке на участие в тендере могут затормозить сделку между компаниями.

PCI DSS показывает путь

К счастью, мы уже проходили через это. Двадцать лет назад безопасность веб-приложений в основном обеспечивали периодические проверки кода, статическое сканирование и дисциплинированность разработчиков. Затем требование 6.6 стандарта PCI DSS, опубликованное в 2006 году и введённое в действие с 2008 года, предписало организациям, работающим с данными держателей карт, либо проверять весь код приложений на уязвимости, либо устанавливать автоматизированные технические средства контроля. Позже возможность ограничиться проверкой кода отменили, и технические меры контроля стали обязательными.

Однако PCI DSS изначально не был законом. Всё началось с договорного стандарта, который преобразил рынок, вероятно, быстрее, чем это сделало бы законодательство: договоры заключаются быстрее, чем принимаются государственные законы.

Похожее давление организации сегодня испытывают в связи с мерами контроля для внедрённого ИИ — оно исходит не от регуляторов, а от клиентов и партнёров и выражается в анкетах по безопасности, требованиях в тендерной документации и условиях страховых полисов.

Решите операционную задачу — и требования соответствия будут выполнены

Справиться с таким давлением бывает непросто, поскольку управление ИИ — это не только правила и политика. Необходимы непрерывно собираемые технические доказательства.

Многие компании, с которыми я общаюсь, используют в рабочей среде полдюжины моделей или больше и часто объединяют их в цепочки либо оркеструют их работу, чтобы выход одной модели становился входными данными для другой. Представьте, как в таких условиях доказать, что одна и та же политика соблюдается во всей системе, например что в ответах моделей не появляются персональные данные. Ручная проверка множества моделей с индивидуальными настройками отнимала бы у разработчиков слишком много времени. Кроме того, большинство организаций сталкивается с несанкционированным и высокорисковым использованием ИИ: например, сотрудники вставляют конфиденциальные данные в потребительские ИИ-инструменты, а поставщики SaaS незаметно включают новые функции ИИ. При этом ответственность полностью лежит на компании.

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

Перенесите безопасность на путь инференса

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

С чего начать

Учитывая направление развития регулирования, организациям уже сейчас нужно начать делать три вещи:

1. Определите границы своей ответственности: от API SaaS-сервисов и размещённых конечных точек до теневого ИИ.
2. Отделите политику безопасности и её применение от моделей и перенесите их на путь инференса.
3. Обеспечьте создание журналов аудита вне контроля моделей и агентов, которые, как было показано, пытаются изменять записи о собственных действиях.

Требования к надлежащему мониторингу и применению мер контроля ещё определяются, но операционные подразделения и команды безопасности вашей компании знают, что действительно можно обеспечить, во что обойдётся контроль с точки зрения задержек и сложности и к каким нежелательным результатам может привести правило, введённое из лучших побуждений. Привлеките их уже сейчас. Риски безопасности и обязательства, связанные с использованием ИИ, вполне реальны, и вашим клиентам и руководителям, несомненно, важнее угрозы, с которыми они сталкиваются сегодня, чем риски, связанные с передовыми моделями, которые могут возникнуть завтра.