Согласование модели никогда не заменяло ее управление

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

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

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

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

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

Безопасность — это не то же самое, что управление

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

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

Проблема шире, чем сама модель, и она растет

Это не узкоспециализированная проблема разработчиков. Она касается каждого, кто внедряет ИИ, и ее масштаб увеличивается по двум причинам.

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

Согласно отчету OWASP за 2026 год, большинство отслеживаемых ими агентных проектов связаны с написанием кода, а инъекции промптов составляют шесть из десяти рисков в их топ-списке агентных угроз. Неконтролируемая поверхность растет так же быстро, как и уровень внедрения.

Во вторую очередь, ответственность теперь закреплена законодательно. Закон штата Калифорния SB 53 и правила Европейского Союза для систем общего назначения возлагают обязательства на разработчики, но Закон ЕС об искусственном интеллекте также налагает отдельные обязанности на лиц, внедряющих ИИ, а законодательство о защите данных уже привлекает организации к ответственности за то, как используются персональные данные.

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

Публичные бенчмарки тоже не помогают: StrongREJECT, HarmBench и AgentHarm оценивают модель по общим подсказкам, а не по вашим пользователям, вашим данным или вашей политике в конкретный день. Высокий бал является свойством самой модели, а не контрольным журналом аудита.

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

Почему согласование модели не может решить эту проблему

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

Модель не защищена от несанкционированного вмешательства. Инъекция промптов, появившаяся в 2022 году, работает потому, что инструкции и данные передаются по одному и тому же текстовому каналу, поэтому документ, который читает модель, может перезаписать данную ей инструкцию.

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

Модель ненадежна в качестве шлюза. Предоставьте ей инструменты, и она превратится в хрестоматийный пример «скомпрометированного доверенного лица» (англ. confused deputy — термин 1988 года для обозначения доверенной программы, которую ненадежный вызывающий объект обманом заставляет злоупотреблять своими полномочиями), поскольку она не способна отличить инструкцию от считываемых ею данных.

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

Провал по всем трем пунктам ведет не к выводу «нужно согласовывать усерднее». Он означает, что модель не может быть механизмом принудительного контроля, поэтому сам контроль должен располагаться в другом месте.

Решение — это слой поверх модели

Если модель не способна управлять сама собой, решением становится не более совершенная модель, а тонкий слой контроля вокруг нее — такой, который рассматривает модель как ненадежный компонент и выступает посредником для всего, что она пытается сделать.

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

Представьте себе запрос, проходящий сквозь него. Модель считывает свои входные данные и предлагает действие: вызвать этот API, записать этот файл, отправить это сообщение.

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

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

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

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

И ее можно верифицировать, потому что точка принудительного контроля настолько мала, что ее код можно полностью прочитать и действительно доверять ему, чего никогда не удастся достичь с миллиардами непрозрачных весов. Именно поэтому самые надежные исследовательские разработки уже работают по этому принципу: проект CaMeL от Google DeepMind и ETH Zurich обеспечивает доказуемую безопасность, изолируя модель именно таким образом, и этот подход работает, даже если базовая модель остается уязвимой. Гарантия заложена в архитектуре, а не в весах.

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

Правильный уровень

Это вовсе не аргумент против согласования. Согласование необходимо, и оно совершенствуется. Просто это не тот уровень абстракции, который требуется для вопросов, задаваемых регуляторами, аудиторами и пользователями. Ответ на этот вопрос лежит на полке с 1972 года, однако индустрия продолжает выводить его заново самым дорогим путем.

Следующая модель будет безопаснее нынешней. Тем не менее она по-прежнему не будет знать, кто ее использовал, на каких данных и в рамках какой политики. Устранение этого пробела и есть наша работа, и в этом суть истории.