От моделей к агентам: переработка трех уровней защиты
Как управление MLOps соотносится с системами агентов: что должны добавить три компонента, где находятся пробелы, и какие сигналы посылают регуляторы ЕС, FDA и финансовой сферы.
Источники: From MLOps to AgentOps: Redrawing the Three Lines of Defense
Искусственный интеллект в формате агентов нарушает правила управления, разработанные для традиционного программного обеспечения и обычных моделей, но это утверждение легче понять на конкретном примере. Годы работы в области MLOps, включающие ведение каталогов моделей, процессы проверки, мониторинг отклонений и рабочие процессы утверждения в корпоративных и финансовых организациях, не отбрасываются при внедрении LLM и агентов. Изменения более узкие и конкретные, чем предполагают большинство людей.
Представьте команду по управлению рисками моделей, обрабатывающую обычную заявку. В форме задаются стандартные вопросы о данных обучения, номере версии, статусе одобрения и дате последней проверки на смещение, и команда уже обработала множество подобных заявок. Затем следует описание системы: четыре взаимодействующих агента, шесть инструментов, разделенных между ними, индекс поиска, пересоздаваемый ежедневно, и результат, полученный в результате последовательности действий, каждый из которых казался корректным. Ничто из указанного не соответствует данным в форме.
Опрос McKinsey AI Trust 2026 года, охвативший примерно пятьсот организаций, показывает схожую картину: примерно треть предприятий утверждают, что уровень зрелости их систем управления достаточен для уже действующих автономных агентов. Остальные продолжают использовать старую форму заявок, надеясь, что она достаточно хороша. Обычно это не так, поэтому важной задачей является выявление моментов, в которых она терпит неудачу.
Что уже покрывается существующей программой
Управление процессами MLOps — это совокупность мер контроля, обеспечивающих надежность традиционной модели машинного обучения на всех этапах, от обучения до вывода из эксплуатации. На практике это включает:
- Версионирование моделей, что позволяет всегда понимать, какая модель используется в производстве и почему.
- Мониторинг отклонений, позволяющий выявлять снижение производительности при изменении входных данных.
- Отслеживание происхождения данных до этапов обучения и проверки.
- Процедуры утверждения перед любым выпуском в производство.
- Соблюдение принципов CI/CD и управления изменениями, характерных для любого программного обеспечения, используемого в производстве; эти принципы являются частью данной системы, а не стоят вне нее.
Ни одна из этих мер не действует автоматически. Кто-то должен нести ответственность за каждую меру контроля, а кто-то еще должен проверять, что ответственный выполнил свои обязанности.
Ответственность обычно распределяется с помощью концепции трех линий защиты — системы, которую банки и другие регулируемые отрасли уже давно используют для определения ответственности. Одна важная деталь: в 2020 году Институт внутренних аудиторов переименовал её в модель трех линий, сместив акцент с чистой защиты на создание ценности. В финансовых кругах и среди специалистов, занимающихся рисками моделей, по-прежнему используется термин «три линии защиты», как и в данном тексте, хотя официальное название изменилось.
В традиционной программе MLOps разделение выглядит следующим образом:
- Первая линия, охватывающая продукт, данные и инженерию, отвечает за разработку, тестирование, развертывание и документирование моделей.
- Вторая линия, занимающаяся соблюдением норм и управлением рисками, устанавливает правила использования моделей, отслеживает предвзятость и проверяет высокорисковые приложения перед их запуском.
Эта структура сформировалась и хорошо понята, и она эффективна для систем, для которых была разработана, а именно для моделей с фиксированной структурой, которые проверяются один раз и находятся под наблюдением между циклами аудита.
Как должны измениться каждая линия для агентов
Управление AgentOps также основывается на этих трех линиях, но содержание проверок в каждой из них отличается из-за различного поведения систем. Основные различия сводятся к пяти конкретным аспектам.
Один артефакт превращается во множество. Классическая модель предполагает версионирование одного объекта. Система с четырьмя агентами представляет собой своего рода пакет: базовая модель, четыре промпта для системы, шесть определений инструментов и слой поиска, обновляющийся автономно. Каждый из этих элементов может влиять на поведение, поэтому необходимо версионировать и тестировать каждую часть. Это больше похоже на промпты и схемы инструментов, рассматриваемые как исходный код, с системой контроля версий, проверкой pull-запросов и тестами типа canary на отдельном наборе данных перед тем, как что-либо внедрять. Ограничиваясь отслеживанием только модели, мы оставляем примерно три четверти аспектов поведения без управления.
Правильный результат попадает в допустимый диапазон. Если подать тот же входные данные традиционной модели, она вернёт тот же результат, поэтому проверка происходит легко. ГЛМ могут при разных запусках давать два разных, но обоснованных ответа. Поэтому второй подход перестаёт проверять, верен ли ответ, и начинает определять, остаются ли ответы в допустимых пределах в большинстве случаев. Для этого требуется система оценки с установленными порогами — например, минимальный процент правильных ответов на маркированном тестовом наборе перед выпуском, а также механизм ручной проверки, когда уровень уверенности или оценочные баллы падают ниже установленного минимума. Согласование того, что считается допустимым в большинстве случаев для конкретного случая применения, — это отдельная задача, которую невозможно решить за один день.
Один владелец превращается в цепочку. У отдельной модели, делающей отдельное прогнозирование, есть очевидный владелец. У системы из четырех агентов его нет. Когда окончательный результат неверен, но ни один из шагов не был ошибочным по отдельности, для диагностики требуется журнал решений, фиксирующий промежуточные передачи данных, а также конечный результат: входные данные для каждого агента, каждое принятое решение и то, что было передано дальше. В отсутствие такого журнала никто не может сказать, какой агент несет ответственность, и в первые и вторые сутки после инцидента происходят споры по этому вопросу вместо того, чтобы договориться заранее.
Мониторинг отклонений — это не мониторинг поведения. Проверки отклонений сравнивают прогнозы с известным эталоном. Они не учитывают действия агента в процессе выполнения: какие инструменты он использовал, какие действия совершил, оставался ли он в рамках заданных параметров. Платформы для наблюдения за агентами устраняют этот недостаток, записывая полную информацию об исполнении, вплоть до вызовов инструментов, параметров и способа передачи результатов от одного агента к другому. Многие из таких платформ опираются на открытые стандарты, такие как OpenTelemetry, что обеспечивает портабельность записей между разными поставщиками. Для данной системы запись исполнения является единственным документом, на основе которого аудитор может позже воссоздать произошедшие события. В отсутствие такой записи аудит третьей стороны осуществляется с использованием «черного ящика», и это называется независимой верификацией.
Повторная настройка календаря превращается в непрерывные изменения. Традиционные модели перенастраиваются по расписанию: ежемесячно, ежеквартально или каждый раз, когда накапливается достаточное количество новых данных. Система, построенная на технологии RAG или с использованием непрерывной настройки, может изменять своё фактическое поведение столько раз, сколько обновляется её база знаний, возможно, ежедневно. Если слой поиска обновляется еженощно, то третий механизм, основанный на квартальных проверках, контролирует систему примерно в девяносто раз реже, чем она сама меняется.
Точка соприкосновения двух подходов
При прямом сравнении оба подхода имеют схожую структуру. Применяются те же три компонента, и оба требуют версионирования, тестирования, проверки и независимой аудиторской проверки. Различия заключаются в степени детализации, частоте и объектах, которые они контролируют.
Подход к управлению в области MLOps здесь не ошибочен. Все поставленные вопросы основывались на предположении, что поведение модели остается стабильным между проверками, однако система, индекс которой пересоздается еженощно, не может сохранять такую стабильность в течение длительного времени. Все пять различий проистекают именно из несостоятельности этого предположения: то, что раньше менялось раз в месяц, теперь может меняться ежедневно, иногда даже без какого-либо вмешательства в саму модель.
Чтобы устранить этот разрыв, не требуется создавать с нуля новую функцию управления. Необходимо расширить существующие подходы, добавив им возможности, которые раньше не были нужны, и честно оценивать затраты на каждую из них:
- Первый шаг: контроль версий для запросов и инструментов с использованием тестирования типа «канарейка» перед их внедрением. Это в основном изменение инженерных практик, а не создание новой команды.
- Второй пункт: шлюз оценки, указывающий пороги принятия решений, а также письменная процедура передачи дел на более высокий уровень для решений, требующих участия нескольких агентов. Это настоящий проект по разработке политик, и на первом этапе потребуются реальные переговоры с юридическим отделом и отделом соблюдения нормативов.
- Третий пункт: инструменты для отслеживания работы в реальном времени и навыки аудита журнала решений вместо использования статической карточки модели. Для большинства подразделений, занимающихся рисками, связанными с моделями, это означает найм нового сотрудника или серьезную подготовку, а не просто отметка в старом шаблоне обзора.
Ни один из этих элементов не является факультативным, если цель — достоверно определить, какой из четырех агентов принял решение.
Что сказали регуляторы на сегодняшний день
Ни одна из существующих регуляторных систем полностью не адаптирована к агентному ИИ, но три существующих подхода из разных отраслей показывают, куда движется развитие.
- Закон ЕС об ИИ применяется ко всем секторам. Обязанности по транспарентности, предусмотренные статьей 50, вступают в силу 2 августа 2026 года, независимо от других событий. Более строгие требования Приложения III, касающиеся высокого риска, изначально также вступали в силу в эту дату, однако предложенный пакет мер Digital Omnibus, принятый в принципе в мае 2026 года и все еще ожидающий официального утверждения, отложит их вступление до декабря 2027 года. В календаре соблюдения требований следует отразить это отсрочение как находящееся в стадии рассмотрения.
- Подход FDA к медицинским устройствам с использованием ИИ носит вертикальный характер и ориентирован на конкретный продукт; ключевым инструментом в этом контексте является План контроля изменений. Согласно этому плану первоначальное утверждение уже позволяет осуществлять определенные обновления моделей при условии соблюдения установленных параметров производительности. К плану прилагаются рекомендации по эффективной практике машинного обучения, а также указания по созданию системы качества, соответствующей стандарту ISO 13485. Фактически контроль изменений становится частью процедуры утверждения, а не дополнительным обязательством, добавляемым позже.
Ни один из этих документов не может служить шаблоном для копирования. Если читать их вместе, они указывают на определённое направление: необходимо изменить заранее установленные границы, уровни риска, а также открыто признать несоответствие между действующими правилами и поведением агентов.
Вернуться к форме подачи заявок
Существующую форму подачи заявок можно оставить. Помимо неё команде нужен отдельный опросник для многокомпонентных систем, структурированный по трем направлениям, на которых она уже основывается, причём следует ожидать, что честный ответ потребует реальных усилий.
Какому шагу программа сможет первой соответствовать? Вероятно, версионированию, поскольку это похоже на проблему контроля версий, решение которой инженеры уже знают. Ответственность за последовательные решения, скорее всего, будет решаться дольше всего. Это проблема организационной структуры в техническом облике, и никакие этапы оценки её не исправят.
Связанная литература
- От агентских циклов к графам рабочих процессов: типизированное состояние, бранды проверки и ограниченное восстановление — Почему агенты с длительным временем работы выходят за рамки одного цикла, и как явные узлы, рёбра, типизированные объекты, проверенные переходы и разрешения для каждого узла делают их надёжными.
- LLMOps для агента-помощника: MLflow Traces, Evals и бранд CI — Создайте помощника для выполнения задач с использованием PydanticAI и FastAPI, отслеживайте его работу с помощью MLflow, оценивайте его с помощью инструментов GenAI и блокируйте регрессии в GitHub Actions, всё это с использованием локальных моделей.