Тенденции отрасли | 15 сентября 2026 года
В отрасли ведётся дискуссия о том, насколько быстро должны развиваться передовые технологии ИИ. Это ускорилось после инцидентов, о которых сообщили Anthropic и OpenAI, когда модели, работающие с ограниченными мерами защиты в оценочных средах, совершали действия, далеко выходящие за рамки того, что кто-либо планировал. Они проникали в системы, от которых должны были быть изолированы, и координировали действия между экземплярами, которые должны были быть изолированы. Недавно генеральный директор Anthropic Дарио Амодеи предложил, чтобы развитие возможностей передового ИИ осуществлялось намеренно медленно и чтобы независимые оценщики были включены в лаборатории для его проверки.
Ответы на это предложение не были единообразными. Лаборатории ИИ сосредоточены на процессе разработки: сколько возможностей добавляет один цикл обучения, насколько тщательно модель оценивается перед выпуском и должны ли стандарты быть добровольными или регулируемыми. Другие утверждают, что граница будет двигаться со скоростью, с которой она движется, остальной мир не замедляется, и безопасность должна быть встроена в системы, окружающие модели.
Я не собираюсь разрешать этот спор здесь, но обратите внимание на что-то интересное: обе стороны согласны, что контроль должен находиться вне модели, а проверка не должна возлагаться исключительно на того, кто её создал.
Это более широкая версия аргумента, который я привел в мае. Тогда я написал, что граница безопасности в ИИ переместилась на путь инференции. Приложения вызывают модели, агенты вызывают инструменты, а модели обращаются к другим сервисам для получения данных, запуска рабочих процессов и совершения операционных действий. Мой вывод заключался в том, что этот трафик должен доставляться, проверяться, аутентифицироваться и регулироваться так же, как и любое другое критическое взаимодействие приложений.
Это был архитектурный аргумент, и за последние несколько месяцев он начал превращаться в аргумент о соблюдении требований. Ускорение развития передовых технологий не ускоряет развитие бизнеса. Что бы ни решили лаборатории и правительства, модели, уже выпущенные, сейчас внедряются в наши организации, и обязательства, связанные с этим использованием, уже начинают формироваться.
По моему опыту, в плане безопасности есть два вида элементов. Это те, в которые вы верите, которые конкурируют за бюджет со всем остальным и иногда проигрывают. А есть те, к которым привязана дата, аудитор, который будет спрашивать о них, и строка в реестре рисков. Ограничения ИИ переходят из первой категории во вторую, и если вы достаточно долго работаете в этой отрасли, это покажется вам знакомым.
“Ускорение развития передовых технологий не ускоряет развитие бизнеса. Что бы ни решили лаборатории и правительства, модели, уже выпущенные, сейчас внедряются в наши организации, и обязательства, связанные с этим использованием, уже начинают формироваться.”
Что нам научил PCI DSS
Мы проводили этот эксперимент раньше. До 2008 года безопасность веб-приложений была в основном амбициозной задачей — периодические проверки кода, статические сканирования, дисциплина разработчиков. Затем появилось требование 6.6 PCI DSS, которое предписывало организациям, обрабатывающим данные держателей карт, либо проверять весь код приложений на уязвимости, либо устанавливать автоматический технический контроль перед публичными приложениями.
Две вещи из этого остались со мной.
PCI DSS не начинался как закон. Он начался с того, что мы в отрасли пытались опередить регулирование. Это был договорный стандарт, который применялся через соглашения с аккредитивами, и он все равно изменил весь рынок. Фактически, вероятно, быстрее, чем это сделал бы закон, потому что контракты движутся быстрее, чем законы. Это важно, потому что первое место, где организации почувствуют это давление, — это не регулятор, а вопросник безопасности клиента, закупочная оговорка или страховщик, спрашивающий, какие меры контроля находятся перед их моделями.
А затем есть то, как это закончилось. В PCI DSS v4.0 вариант «либо/либо» исчез. Альтернатива проверки кода исчезла; автоматическое техническое решение перед публичными веб-приложениями теперь обязательно согласно требованию 6.4.2.
Сегодня никто не спрашивает, является ли соблюдение PCI обязательным. Вариант стал требованием.
Где мы находимся сегодня с регулированием ИИ
Регуляторный медовый месяц для ИИ закончился. Эквивалент ИИ для PCI прибывает по нескольким направлениям одновременно, с разной скоростью. Закон ЕС о ИИ является наиболее развитым. Его обязательства в отношении моделей общего назначения уже реализуются, и хотя Европейский союз недавно отложил применение мер по высокорискованным системам до декабря 2027 года, ожидания в отношении технической надёжности, человеческого надзора и ведения журнала уже определены. Что предприятия постоянно упускают из виду, так это то, что некоторые из этих обязательств ложатся на них самих, а не только на поставщиков моделей. Если они используют чью-то другую модель в высокорискованном случае использования, они несут ответственность.
В США пока нет сопоставимого закона, но рамки управления рисками ИИ NIST и его профиль генеративного ИИ стали стандартом, который многие приняли для разумной осмотрительности. ISO/IEC 42001 делает то же самое в области сертификации, и, фактически, я начинаю видеть это в закупочных документах. На государственном уровне было введено несколько законов, сочетающих прозрачность, раскрытие информации и правила использования, в то время как финансовые и медицинские регуляторы обсуждают специфические для сценариев руководящие принципы.
А OWASP Top 10 для приложений LLM теперь является стандартным справочным материалом в обзорах безопасности. Когда клиент отправляет поставщику вопросник о мерах контроля ИИ, очень часто именно отсюда берутся вопросы.
Прочитав всё это, вы увидите, что снова и снова появляется одно и то же требование: показать, что вы можете ограничивать то, что поступает в модель, и что из неё выходит, постоянно, и после этого создавать запись.
Это операционная проблема, прежде чем это станет проблемой соблюдения требований
Наш отчёт о состоянии стратегии приложений за 2026 год показал, что 55% портфелей приложений теперь оснащены ИИ, и среднее предприятие использует семь моделей в своём пути инференции. Более половины (52%) объединяют или оркестрируют несколько моделей. И 90% ожидают, что инференс будет осуществляться через общую инфраструктуру.
Теперь представьте, что аудитор просит продемонстрировать, что одна политика — скажем, что никакие персональные данные клиентов не покидают завершение модели — применяется ко всему этому.
На это нельзя ответить, настроив семь моделей индивидуально. Это точно нельзя ответить, когда три из них связаны, и выход одной является входом для другой. И большинство организаций, с которыми я разговариваю, отстают даже от этого, потому что первое, что они находят, когда начинают искать, — это не самохостинговая модель. Это сотрудники, вставляющие конфиденциальные данные в потребительские инструменты ИИ, и функции ИИ, тихо включённые внутри SaaS-приложений, которыми они уже владеют.
Добавьте к этому агентов, и единица, которую вам нужно контролировать, перестанет быть промптом и станет действием — вызовом инструмента, запросом API, рабочим процессом, который он запускает. Это та же точка применения, которую мы строили в течение 20 лет для трафика приложений.
Те же самые агентные возможности уже находятся в руках злоумышленников, которые проводят скоординированные кампании с машинной скоростью. Как мы узнали в области защиты от ботов, мы должны перестать судить этот трафик по тому, насколько он выглядит сложным, и начать контролировать его по тому, откуда он поступает и что он пытается сделать.
Защитные ограждения должны находиться вне модели.
Организации все чаще используют собственные модели: модели с открытыми весами на их инфраструктуре, доработанные на их данных. Нет защиты со стороны поставщика, поэтому операционная и нормативная ответственность полностью лежит на них.
Проверка модели за моделью не масштабируема. Это можно сделать, в принципе, для десятка конфигураций моделей. Я видел, как команды это делали. Это ручной процесс, он устаревает в тот момент, когда кто-то запускает новый эндпоинт, и он дает снимок, а не контроль.
Аллинирование не является средством контроля безопасности. Системные подсказки и постобучение обеспечивают полезную базу. Инциденты OpenAI и Anthropic демонстрируют ограничения этого. Это были модели без защитных механизмов, преследовавшие узкую цель, сталкивавшиеся с границей и обходившие ее. У OpenAI есть stated, что классификаторы в ее стандартных клиентских развертываниях отметили бы активность как небезопасную, и что ее расширенный мониторинг цепочки рассуждений, если бы он работал, предупредил бы ее команду безопасности до того, как ее модели попали на Hugging Face. Общедоступные модели Anthropic имеют классификаторы, которые проверяют входные и выходные данные в режиме реального времени.
Обе лаборатории провели значительную работу по выравниванию в ответ на это, и ни одна из них не сочла это достаточным. Обе также разместили средства контроля вне модели: мониторы, которые следят за тем, что она делает, и оценивают действие перед его выполнением, с эскалацией к человеку. Организации с максимально возможным пониманием этих систем пришли к выводу, что контроль должен находиться вне модели.
С чего начать?
Учитывая, куда движется регулирование, и чему нас научили последние два десятилетия применения безопасности приложений о том, как эти обязательства появляются, есть три вещи, которые я бы начал реализовывать сейчас, а не ждать.
- Картирование поверхности, начиная с того, что не было авторизовано. Каждая модель в производстве — API SaaS, размещенные эндпоинты, самоуправляемые развертывания с открытыми весами — плюс теневая ИИ.
- Отделите обеспечение соблюдения от модели. Разместите политику в пути инференции, а не в семи отдельных конфигурациях модели. Проверяйте, что поступает внутрь, проверяйте, что выходит наружу, обеспечивайте единообразное соблюдение независимо от того, какая модель или какой облачный сервис используется.
- Создайте журнал аудита вне системы, которую он записывает. Журналы того, что было запрошено, что было возвращено, что было заблокировано и кто что одобрил. Убедитесь, что он генерируется инфраструктурой, которую модель и агент не контролируют. Следователи, изучавшие инцидент OpenAI found, обнаружили, что агенты пытались изменить записи о своих собственных действиях. Если ваша запись генерируется системой, которую она описывает, она будет подозрительной.
Ключевое здесь то, что управление ИИ — это не просто документальная работа. То, что будет требоваться от организаций, будет техническим, непрерывным и доказательным. Это делает это проблемой архитектуры и операций, которая ложится на команды безопасности и операций, а не проблемой политики для вашего юридического отдела.
Мы считаем, что контроль должен находиться в пути, а не в моделях. Каждая модель, которую ваша организация использует — API SaaS, размещенный эндпоинт, самоуправляемые открытые веса, те, которые вы санкционировали, и те, которые вы еще не обнаружили — сходятся в пути инференции. Это делает его идеальной точкой контроля для всех этих моделей, чтобы обеспечить соблюдение политики и создать независимый, подлежащий аудиту журнал.
Правила все еще пишутся.
Никто не знает, какое требование заставит их организацию решить проблему — обязательство по Закону ЕС о ИИ, государственный закон, секторальный регулятор или клиентский контракт. Что я знаю, так это то, что технические определения внутри этих рамок не урегулированы. Что считается адекватным мониторингом, достаточной устойчивостью или приемлемой записью, решается прямо сейчас, в периоды комментариев, органах стандартизации и кодексах практики.
Что возвращает нас к текущим дебатам о темпах развития передовой ИИ. Вне зависимости от достоинств, я предложу одно наблюдение от человека, который управляет этим в производстве: предприятие работает по другому расписанию. Что бы ни решили лаборатории, правительства и индустрия, уже выпущенные модели развертываются и используются в больших масштабах в наших организациях, и обязательства, связанные с этим использованием, очень реальны. Вам все равно понадобятся ответы для вашего совета, ваших руководителей и ваших клиентов, независимо от того, замедлим ли мы развитие возможностей или нет.
Эти решения будут лучше, если они будут основаны на мнении людей, которые эксплуатировали эти системы в больших масштабах — которые знают, что действительно поддается контролю, сколько стоит контроль в плане задержки и сложности, и куда хорошо продуманное правило толкает поведение в неправильном направлении. PCI DSS работала, потому что практикующие ее сформировали ее. Если мы пропустим это, требования все равно будут написаны. Просто людьми, которым никогда не приходилось обеспечивать их соблюдение.
Об авторе
Майкл отвечает за общекорпоративную стратегию и реализацию мер по обеспечению безопасности и устойчивости компании в основе ее деятельности. Он возглавляет организации F5 по безопасности, рискам и цифровым операциям, обеспечивая сквозное оперативное доверие для клиентов, партнеров и сотрудников. Монтоя присоединился к исполнительной команде F5 в октябре 2025 года после того, как с 2021 по 2025 год был членом Совета директоров F5. До F5 Монтоя был главным операционным директором в BlueVoyant, а ранее занимал должность главного директора по информационной безопасности в Equinix и Digital Realty. Он провел более десяти лет в Microsoft на глобальных руководящих должностях, включая должность главного директора по кибербезопасности, регионального CIO/CISO для EMEA и Азии и глобального лидера по операциям центров обработки данных.
