Отраслевые тенденции | 16 октября 2026 г.
В предыдущем блоге я утверждал, что при работе с моделью класса Mythos место перехвата атаки важнее, чем факт её обнаружения, и что путь трафика — это единственная точка контроля, которую не может обойти мыслящий противник. В этой статье я переношу этот аргумент в корпоративную среду: что на самом деле перемещается по этому пути, когда организация начинает использовать ИИ, и почему ответ на этот вопрос меняет наш подход к проектированию безопасности.
Несколько месяцев назад я присутствовал на дискуссии об корпоративном ИИ, которая началась так же, как и большинство подобных обсуждений. Какую модель нам использовать? Должны ли мы запускать её самостоятельно или обращаться к публичной? Как повысить точность и сократить галлюцинации? Все это хорошие вопросы. Но никто не спросил, что происходит после выбора модели.
А происходит вот что. Пользователь отправляет запрос. Приложение получает его, проверяет личность пользователя, извлекает контекст из хранилища документов или базы данных и вызывает несколько внутренних API. Агент может решить, что требуется определенный инструмент. Сформированный запрос достигает модели, которая генерирует токены. Эти токены могут быть ответом. Они также могут быть инструкцией, которая запускает следующий вызов API, следующий рабочий процесс или изменение в системе учета.
Если смотреть на это так, то модель — лишь один компонент в гораздо более длинной цепочке. Эта цепочка и есть то, что я называю путем вывода, и наблюдение, на котором строится эта статья, просто: путь вывода — это путь трафика.
«Обычный трафик переносит данные. Трафик вывода переносит намерения, контекст и решения».
Что на самом деле представляет собой путь вывода
Обучение создает модель. Вывод — это момент, когда обученная модель начинает работать. Когда сотрудник просит корпоративного помощника «обобщить последние результаты и составить черновик письма для руководства», запрос проходит путь примерно такого вида:
Пользователь → Приложение → Идентификация → Контекст и извлечение → API → Агент → Модель → Инструменты → Модель → Ответ → Пользователь
Каждый этап этого пути — это сетевой и прикладной трафик. У него есть конечные точки, задержки, решения по маршрутизации и привязанная к нему идентификация. Он переносит данные, потребляет бюджет и всё чаще несет в себе полномочия на выполнение действий.
Моя коллега Лори МакВитти высказала схожую мысль в начале этого года: вывод — это поведение во время выполнения в рабочей среде, и он ведет себя как уровень приложения, с пользователями, шаблонами трафика, чувствительностью к задержкам, режимами сбоев, ограничениями по стоимости и рисками безопасности. Кунал Ананд, директор по продуктам F5, описывает тот же путь как новую цепочку создания ценности: от промпта до входящего трафика, через рабочие процессы и вывод, и обратно к пользователю. Как только вы принимаете эту концепцию, дискуссия о безопасности должна развиваться вместе с ней. Мани Ганесан, вице-президент F5 по управлению продуктами безопасности ИИ, рассматривает, что этот сдвиг означает для поверхности атаки в своем недавнем блоге: «Ваш ИИ теперь является поверхностью атаки. Готовы ли вы обеспечить его безопасность?»
Четыре предположения, от которых стоит отказаться
Поскольку CISO укрепляют безопасность ИИ, вот четыре предположения, от которых нам всем нужно отказаться:
- «Все дело в модели». Модель привлекает внимание, потому что она является видимой частью. Но промпт может содержать конфиденциальные данные, этап извлечения может вытянуть секретные записи, агент может хранить учетные данные API, а инструмент, который он вызывает, может иметь возможность записи в базу данных. Обеспечение безопасности только модели похоже на укрепление базы данных при игнорировании приложения и API, которые с ней взаимодействуют. Поверхность атаки — это весь путь.
- «Переход от пилота к продакшену — это задача масштабирования». Пилотный проект обычно включает одну модель, несколько пользователей, одно приложение и доступ, утвержденный вручную. Продакшен совсем не похож на это. Отчет F5 «Состояние стратегии приложений 2026» показал, что организации координируют в среднем семь моделей ИИ, при этом 77% опрошенных заявили, что вывод, а не обучение, теперь является их основной деятельностью в области ИИ, а 52% объединяют или оркестрируют несколько моделей вместе. Это не та же самая архитектура с большим количеством пользователей. Это другая архитектура, и модель безопасности должна меняться вместе с ней.
- «Скорость, безопасность и управление — это отдельные уровни». Рассмотрим промпт, содержащий персональные данные. Где-то между пользователем и моделью этот запрос должен быть проверен, отредактирован там, где этого требует политика, направлен в утвержденную модель, отслежен и занесен в журнал для аудита — и все это во время его передачи. Та же точка принятия решений, которая спрашивает: «Куда идет этот запрос?», теперь также должна отвечать: «Должен ли он вообще туда идти?». Это одно решение по обработке трафика, а не три функции, скрепленные вместе.
- «Мы можем собрать вместе точечные инструменты». Организация, безусловно, может собрать стек: API-шлюз, WAF, DLP, IAM, средства защиты ИИ, шлюз моделей, наблюдаемость, SIEM, элементы управления агентами, безопасность MCP. Ни один из этих инструментов не является плохим. Проблема в стыках между ними. Представьте один запрос, проходящий через шесть контрольных точек, каждая со своим механизмом политик и контекстом идентификации. Кто знает, что пользователь, который ввел промпт, — это та же личность, которая сейчас вызывает инструмент? Кто может видеть, что вызов API, вызов модели и вызов инструмента — это одна транзакция? Кто может обеспечить соблюдение последовательной политики на всем пути и доказать впоследствии, что произошло?
В моем предыдущем блоге отмечалось, что стыки — это то, куда в первую очередь смотрит мыслящий противник. То же самое верно и для добронамеренного агента, который просто отклоняется от политики.
Как только вывод начинает рассматриваться как трафик, сам путь становится естественным местом для обеспечения идентификации, политики, защиты данных и контроля агентов — как на входе, так и на выходе.
Когда трафик начинает нести намерения
ИИ добавляет новые этапы к привычной последовательности «запрос-маршрутизация-политика-ответ»: контекст, извлечение, оркестрация, вызов инструментов. Но более глубокое изменение заключается в том, что именно переносит трафик. Обычный трафик переносит данные. Трафик вывода переносит намерения, контекст и решения.
Это наиболее важно для агентов. Помощник, который отвечает на вопрос, — это одно. Агент, который может читать записи клиентов, создавать тикеты, отправлять электронную почту, выполнять код, изменять инфраструктуру или отправлять инструкции по оплате, — это совсем другое. Путь вывода становится путем действий, и радиус поражения от неверного решения перестает быть просто информационным.
Транзакция вывода — это новая единица безопасности
Традиционная безопасность оперирует понятиями пользователей, устройств, приложений, API, рабочих нагрузок и данных. Нулевое доверие научило нас задавать не только вопрос «Кто вы?», но и «К чему вы пытаетесь получить доступ?». Системы ИИ требуют третьего вопроса: «Что вы просите ИИ сделать, с какими данными, через какую модель и какие действия может спровоцировать это взаимодействие?»
Ответ на этот вопрос требует контекста, которым не обладает ни один существующий инструмент контроля. Рассмотрим аутентифицированного пользователя финансового помощника, чей запрос извлекает конфиденциальные финансовые данные во внешнюю модель, передает их финансовому агенту и заканчивается вызовом API ERP для создания инструкции по оплате. Одной только идентификации пользователя недостаточно для принятия такого решения. Это должна делать вся транзакция целиком.
Именно поэтому идентификация, безопасность приложений, безопасность API, безопасность ИИ и управление трафиком объединяются. Единицей, вокруг которой они объединяются, является транзакция вывода: идентификация плюс запрос плюс контекст плюс модель плюс данные плюс инструменты плюс результат плюс действие. Это гораздо более сложный объект, чем HTTP-запрос.
Как только вы начинаете мыслить транзакциями, безопасность перестает быть контрольно-пропускным пунктом и превращается в цикл. Перед выводом возникают вопросы: кто спрашивает, какие данные предоставляет, является ли запрос враждебным и какая модель должна его получить.
Во время вывода вопросы заключаются в том, соответствует ли запрос политике и бюджету и пытается ли агент вызвать инструмент, на который у него нет прав. После вывода вопросы касаются того, безопасно ли возвращать ответ, спровоцировал ли он какое-либо действие и что необходимо занести в журнал. Каждый ответ должен быть получен там, где проходит трафик, потому что это единственное место, где весь контекст существует одновременно.
Что это значит для CISO
Мы уже видели этот паттерн раньше. Монолиты превратились в распределенные приложения, клиент-серверная архитектура стала API и микросервисами, а периметровая безопасность уступила место элементам управления, учитывающим идентификацию и приложения. Каждый раз инфраструктура, которая доставляла и защищала трафик, становилась стратегически важной. Вывод — это следующий виток этого цикла.
Поэтому вопрос, который стоит задать вашей архитектурной команде, заключается не только в том, где живут ваши модели. Спросите, где проходит трафик вывода, что он несет, к чему может получить доступ, какие решения принимает и какие действия может спровоцировать. Затем задайте самый сложный вопрос: где мы можем обеспечить соблюдение политики для всего этого, не замедляя работу приложения?
Потому что в эпоху ИИ самая важная граница безопасности, возможно, больше не находится вокруг модели. Она находится на пути к ней и от нее.
Чтобы узнать больше о том, как F5 подходит к этому вопросу, посетите страницу F5 AI Gateway. Также обязательно прочитайте мой предыдущий пост в блоге: «Остановка передового ИИ на уровне сети: почему встроенный контроль является ключевым преимуществом против моделей класса Mythos».
