Защитные механизмы ИИ-агентов: почему промптов недостаточно

Последние два года компании просили ИИ отвечать на вопросы. Сегодня они просят его действовать: создавать тикеты, обновлять записи, выполнять запросы, фиксировать код (коммитить). В исследовании Deloitte «Состояние ИИ на предприятии в 2026 году» отмечается, что среди 3 235 опрошенных руководителей бизнеса и ИТ из 24 стран 74% ожидают, что к 2027 году их компании будут использовать ИИ-агентов как минимум «умеренно», в то время как лишь 21% сообщают о наличии зрелой модели управления ими.¹ Что-то должно находиться между автономным системой и тем ущербом, который она может нанести, и для большинства команд этим «что-то» на данный момент является текстовый файл.

Файл промпта — это набор постоянных инструкций, которые инженер пишет для агента: системный промпт, документ с политиками, файл инструкций, зафиксированный в репозитории. Он говорит агенту, над чем тот работает, какие инструменты у него есть и чего он никогда не должен делать: не писать в продакшн; проверять схему перед миграцией; запускать тесты перед коммитом. Файл промпта не требует новой инфраструктуры и (часто) какого-либо одобрения, именно поэтому он стал местом, где многие предприятия хранят свою операционную политику для автономного программного обеспечения.

Именно по этой причине одна и та же инструкция часто повторяется более одного раза: «Не трогай базу данных. Не трогай базу данных». Где-то в файле промптов в вашей компании версия этой строки вставлена с полдюжины раз, вероятно, заглавными буквами. Лаборатория искусственного интеллекта Юджина Ву (Eugene Wu) в Колумбийском университете обнаружила сотни или тысячи таких строк⁴ и пришла к выводу, что большинство из них вообще никогда не должны были попадать в промпт.

Ву — доцент Колумбийского университета и содиректор Лаборатории агентов и процессов обработки данных (Data Agents and Processes Lab), которая охватывает управление данными, машинное обучение, обработку естественного языка (NLP), системные разработки и взаимодействие человека с компьютером (HCI).⁴ Лаборатория работает с компаниями, использующими ИИ-агентов в продакшене, а ее группа по изучению взаимодействия человека с компьютером исследует, как люди управляют правилами для машин. Правило в промпте — это просьба; правило в системе — это гарантия. Ву и его соавтор Чарли Саммерс (Charlie Summers) четко выражают этот контраст в своей Data Flow Control paperработе по управлению потоками данных (Data Flow Control paper)[/L1]]: политики, зашифрованные в промптах или оцениваемые с помощью языковой модели (LLM), по своей сути вероятностны, не дают формальных гарантий и деградируют по мере роста сложности политики и масштаба данных.⁵ Аргумент Ву, озвученный в недавнем выпуске подкаста AI Radicals, заключается в том, что большую часть того, что мы пишем в промпты, следует отнести ко второй категории.

Почему надежность ИИ-агентов — это не проблема времени безотказной работы

Мы заимствовали слово «надежность» из вычислительной дисциплины, где оно описывало производительность: «В традиционных вычислениях, когда мы говорим о надежности, мы имеем в виду то, хороша ли производительность. Достаточно ли она высока или масштабируема», — объясняет Ву. «Но [в корпоративном ИИ] надежность означает: правильно ли он интерпретировал ваш запрос? Или поступил ли он правильно?»⁴

Это важно, потому что теперь одна модель совершает эти суждения многократно в рамках одного запроса: интерпретирует намерения, генерирует код, вызывает инструменты и изменяет состояние. Последствия этого Ву называет семантической сцепленностью. «Качество каждого из этих шагов зависит от каждого другого шага в конвейере», — говорит он. «То, что вы получаете на выходе, может быть произвольно плохим или произвольно хорошим».⁴

Семантическая сцепленность — это зависимость, которая связывает каждое основанное на значении решение в рабочем процессе со всеми остальными. Традиционная надежность — это вопрос выполнения: быстро ли это работает, масштабируется ли, доступно ли? Семантическая надежность — это вопрос интерпретации, а интерпретация накапливается.

Аналогия Ву — это цепочка поставок: компетентный сантехник, работающий с плохими деталями, все равно выдает вам плохой результат, и вы пожинаете его плоды как клиент. Стек агентов ведет себя точно так же, потому что это агенты, вызывающие субагентов, которые вызывают инструменты — то, что некоторые эксперты называют «черепахи на протяжении всей цепочки». Любой компонент, который плохо интерпретирует данные, ухудшает все, что находится ниже по потоку. И поскольку передача управления между этими компонентами носит вероятностный, а не запрограммированный характер, нет такого уровня, на котором можно было бы прекратить проверки и предположить, что все остальное держится. Именно поэтому агентная автоматизация должна проектироваться как система, а не собираться как цепочка.

Ведущий Сатьен Сангани (Satyen Sangani) назвал архитектурную потерю: традиционные вычисления обеспечивают дискретную, детерминированную передачу управления между уровнями, но рабочие процессы агентов — нет. «Люди хотят просто сделать свою работу, а затем передать ее следующему человеку, и такой подход просто не работает», — сказал Сангани.⁴

Что команды на самом деле пишут в промптах своих агентов

Коллеги Ву изучили, что именно команды пишут в этих файлах. «На самом деле в этих промптах вы видите, что огромная их часть пытается сказать агенту, что делать, а чего не делать», — говорит Ву, и объем поразил его команду: «Наши студенты, изучающие HCI, нашли сотни или тысячи таких правил».⁴ Организации уже управляют политиками, отмечает он, но то, какие правила применяются к агенту, зависит от задачи и выполняемого им шага.

Независимые данные свидетельствуют о том, что этот подход хрупок. Исследование, опубликованное Surge AI в июле 2026 года, помещает агентов в 65 корпоративных сред, регулируемых политиками объемом от 20 до 124 страниц, и оценивает полученное состояние по 824 детерминированным критериям.² Самая мощная из 30 конфигураций моделей удовлетворила каждому критерию в 36,2% тестов; большинство передовых конфигураций набрали менее 25%.² Авторы рекомендуют внедрять жесткие элементы контроля за пределами модели.² Задачи, среды и инструменты оценки находятся в открытом доступе, поэтому результаты поддаются проверке, а не просто декларируются.

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

Группа по изучению взаимодействия человека с компьютером (HCI) из Колумбийского университета столкнулась с той же проблемой со стороны удобства использования, и ее первым инстинктом было сокращение: поместить в промпт подмножество правил, а не все сразу, в надежде, что агент будет более добросовестно следовать более короткому списку. Ву посмотрел на ту же стопку правил и пришел к другому выводу.

Перенесите правило из промпта в систему

«Мы посмотрели на это и сказали: о, на самом деле большую часть этого материала мы можем перенести в саму систему», — говорит Ву. «И тогда это не нужно будет обеспечивать вероятностным путем. Мы просто обеспечим это принудительно».⁴

Сангани задал очевидный вопрос: в какую систему? Ответ Ву заключается в том, что единой системы не существует. «Это может быть база данных, операционная система. Это может быть оркестратор или линтер».⁴ В качестве примера он приводит детерминированный проверщик, который читает код и подтверждает, что исключения выбрасываются там, где этого требуют правила, каждый раз, а не только тогда, когда модель об этом вспоминает.

Тест на сортировку прост: можно ли проверить правило путем инспекции кода, состояния или конфигурации без интерпретации того, что имел в виду пользователь? Если да, то ему не место в промпте. На практике это охватывает большую часть того, что команды пишут сегодня. Список ниже охватывает некоторые распространенные указания для промптов, которые на самом деле должны быть заложены в инфраструктуре.

4 распространенных средства защиты промптов, которые стоит перенести в инфраструктуру

• «Не пишите в эти файлы или по этим путям» → права доступа к файловой системе в окружении (harness) или контейнере

«Не пишите в эти файлы или по этим путям» → права доступа к файловой системе в окружении (harness) или контейнере

• «Не пишите в продакшн; сначала проверьте схему» → права доступа к базе данных, ограничения и подключения только для чтения

«Не пишите в продакшн; сначала проверьте схему» → права доступа к базе данных, ограничения и подключения только для чтения

• «Всегда вызывайте исключения здесь; следуйте этому соглашению» → линтер или проверка в CI

«Всегда вызывайте исключения здесь; следуйте этому соглашению» → линтер или проверка в CI

• «Запустите тесты перед коммитом» → оркестратор, определяющий последовательность шагов

«Запустите тесты перед коммитом» → оркестратор, определяющий последовательность шагов

У этого подхода есть второе преимущество, которое легко упуститься из виду. Принудительное исполнение правил — это не просто стена, это еще и сигнал. «Если механизм не вероятностный, на него можно положиться и он дает гарантии, тогда системе вообще не нужно об этом думать», — говорит Ву⁴. В результате окружение может перехватить нарушение, сообщить агенту, с чем именно он столкнулся, и подсказать, что делать вместо этого. Правило в промпте борется за внимание модели на каждом шаге, независимо от того, актуально оно или нет. Правило в системе ничего не стоит до тех пор, пока оно не сработает, а когда срабатывает — поступает в виде обратной связи именно тогда, когда это важно.

Для лидеров в области работы с данными это та же логика, которая уже лежит в основе управления данными и обеспечения политик на уровне данных, но примененная к новому потребителю. Как выразился Ву: «Вам нужно на что-то опираться для обеспечения надежности и качества».⁴

Почему простые ухищрения в промптах не спасают при работе с потоками данных

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

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

Обычно это квалифицируют как промпт-инъекцию, однако, как отмечает Ву, этот ярлык скрывает истинный механизм. На самом деле произошло следующее: ненадежный источник, появление которого никто не предвидел, предоставил агенту информацию, и агент последовал ей. Заплатка на стороне промпта заключается в добавлении новых правил: читать только проверочные письма или проверять каждый вызов инструмента до того, как что-либо попадет в корзину. Ву объясняет, почему это перестает работать: вполне возможно, что вы уже покупали таблетки для похудения раньше, поэтому добавление их в корзину само по себе не является небезопасным действием, и никакой анализ вызова не докажет обратное. «Невозможно проверить вызов инструмента или просто запрос в какой-либо форме и понять, безопасно это или нет, — говорит он. — Потому что все дело в потоках данных».⁴ Происхождение данных — вот в чем проблема, а окружение агента вообще не имеет никакой видимости происхождения, поэтому отслеживание происхождения (lineage) перестает быть функцией отчетности и становится поверхностью контроля.

Ответ его лаборатории — контроль потоков данных: ограничения на то, куда могут перемещаться данные, а не на то, какие команды могут выполняться. История заказов может попасть в вашу корзину. Ваш почтовый ящик — нет. «Если вы можете записать эту политику и если система может детерминированно ее принудительно соблюдать, то на самом деле неважно, как вы спроектируете агента, — говорит Ву. — Если он попытается сделать что-то запрещенное, система просто отклонит это действие».⁴

Этот механизм опубликован, а не является чисто теоретическим. Саммерс и Ву описывают контроль потоков данных вместе со слоем обеспечения соблюдения правил под названием Passant, который переписывает запросы таким образом, чтобы политики проверялись во время выполнения, а не после него. Для пяти движков баз данных (DuckDB, Umbra, PostgreSQL, DataFusion и SQL Server) накладные расходы на такую проверку составляют примерно ноль,⁵ что достаточно дешево, чтобы оставлять ее включенной для каждого запроса, а не только для тех, которые кто-то догадался пометить. В этом и заключается практическая разница между средством защиты, которое вы можете позволить себе везде, и тем, которое вы используете по минимуму.

Сангани пришел к такому же выводу со стороны данных: «Вы ставите знак „Стоп“ на дороге, вы же не вкладываете этот знак в голову водителя, чтобы он заучивал его наизусть каждый раз», — сказал он⁴. Политика должна принадлежать управляемому объекту, будь то метка PII на колонке таблицы или онтология, стоящая за управляемыми продуктами данных.

С чего начать внедрение средств защиты агентов

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

Случай, который убедил его, произошел в Intellect Design — финтех-компании, чье программное обеспечение обслуживает банковские сервисы для клиентов. Работая с ними, Ву обнаружил, что ограничения на использование данных во многом соответствуют финансовым нормативным требованиям. «Сегодня их часто просто сбрасывают в промпты, — говорит он. — Но оказывается, что на самом деле многие из них можно внедрить и просто постоянно проверять в масштабе».⁴ Агенты для написания кода открывают точно такие же возможности.

Цена ожидания поддается измерению. По прогнозам Gartner, к 2027 году 40% предприятий понизят в статусе или выведут из эксплуатации автономных ИИ-агентов из-за пробелов в управлении, выявленных только после инцидентов в продакшне.³ Сангани описал эту динамику на основе личного опыта: «Вам приходится изучать политику, потому что сама ошибка в некотором роде дает понять, нужна ли она вам».⁴

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

Прецедент уже есть в вашем стеке

Ву считает эту задачу решаемой, потому что индустрия уже проходила через это однажды. До реляционных баз данных приложения сами справлялись с повреждением данных и оптимизацией запросов, а транзакции едва ли существовали как концепция. «Разработка приложений была в сотни раз дороже и медленнее, чем должна была быть, — говорит Ву. — И то, что сделала база данных, — она взяла на себя значительную часть этих затрат... именно это, как мы видим, необходимо сделать сегодня для агентов».⁴ Он старается не делать громких заявлений: база данных — это лишь один из многих инструментов, с которыми взаимодействует агент. Этот сдвиг проявляется в том, как LLM все больше ведут себя как слой операционной системы, и в том, почему операционная система искусственного интеллекта должна охватывать агентов, контекст, данные и управление, а не существовать рядом с ними.

Практический вывод для лидера по работе с данными — задать вопрос по каждому файлу промптов, который поддерживает ваша команда: какие из этих правил окружение могло бы гарантировать автоматически? Средства защиты, которые стоит сохранить, — это те, которые вам никогда не придется писать дважды.

Интересно, как управляемые продукты данных и подлежащие соблюдению политики могут дать вашим агентам надежную опору? Закажите демонстрацию у нас сегодня.

Источники и примечания

Каждое внешнее утверждение на этой странице поддается независимой проверке. Общедоступные источники перечислены здесь.

1. Опрошено 3 235 руководителей в сфере ИТ и бизнеса в 24 странах Северной и Южной Америки, Азиатско-Тихоокеанского региона, Европы и Ближнего Востока; 21% сообщают о зрелой модели управления для агентного ИИ; 74% ожидают, что их компании будут использовать ИИ-агентов по меньшей мере «умеренно» к 2027 году. Выводы опубликованы в отчете Deloitte «Состояние ИИ на предприятии: неиспользованное преимущество» (январь 2026 г.). — Deloitte Insights, «Руководители бизнеса и ИТ сообщают, что ИИ-агенты масштабируются быстрее, чем средства контроля», 24 апреля 2026 г. https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html

2. 65 агентных задач, поставленных в десяти вымышленных компаниях; стандартные операционные процедуры объемом от 20 до 124 страниц, написанные экспертами; 824 программных критерия приемки, охватывающих как обязательные, так и запрещенные действия; при строгой оценке сильнейшая из 30 оцениваемых конфигураций моделей проходит 36,2% тестов, причем большинство передовых конфигураций показывают результат ниже 25%; авторы рекомендуют внедрять жесткие средства контроля вне модели; практически каждая неуспешная траектория завершается утверждением о соблюдении требований, часто со ссылкой на нарушенные разделы. Задачи, среды и тестовый каркас опубликованы в открытом доступе. — Liudas Panavas, Sebastian Minus, Bradley Monton, Derek Ray, Suhaas Garre, Sushant Mehta & Edwin Chen (Surge AI), HANDBOOK.md: A Benchmark for Long-Context Agentic Instruction Following, arXiv:2607.25398, 28 July 2026. https://arxiv.org/abs/2607.25398

3. К 2027 году 40% предприятий понизят в статусе или выведут из эксплуатации автономные ИИ-агенты из-за пробелов в управлении, выявленных только после инцидентов в рабочей среде. — Gartner, «Gartner заявляет, что применение единообразного управления к ИИ-агентам приведет к сбоям корпоративных ИИ-агентов», 26 мая 2026 г. https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure

4. Все цитаты Юджина Ву (Eugene Wu) и Сатьена Сангани (Satyen Sangani), а также описание исследования группы HCI Колумбийского университета по управлению правилами, сотрудничества с Intellect Design и аналогии с реляционными базами данных. — AI Radicals, Сезон 4, Эпизод 8, «Семантическая связь и взаимосвязанный стек ИИ», Alation.https://www.alation.com/podcast/episodes/semantic-coupling-eugene-wu-columbia/

5. Контроль потоков данных (Data Flow Control, DFC) как декларативная структура для ограничения потоков данных на уровне кортежей, и Passant — переносимый слой принудительного применения перезаписи запросов; примерно 0% накладных расходов зафиксировано при работе с DuckDB, Umbra, PostgreSQL, DataFusion и SQL Server; подходы к разработке политик на основе промптов и оценки с помощью LLM охарактеризованы как по своей сути вероятностные, не дающие формальных гарантий и деградирующие по мере роста сложности политик и масштаба данных. Препринт; в данной форме не рецензировался. — Charlie Summers & Eugene Wu, Columbia University, Data Flow Control: Data Safety Policies for AI Agents, arXiv:2606.05679, 4 June 2026.

АТРИБУЦИЯ АНАЛИТИКОВ И ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Gartner, Избегайте несоответствия систем управления: классифицируйте ИИ-агентов по уровню автономности, Шива Варма (Shiva Varma), май 2026 г.

GARTNER является зарегистрированным товарным знаком и знаком обслуживания компании Gartner, Inc. и/или ее филиалов в США и других странах и используется здесь с разрешения. Все права защищены.

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