Від моделей до агентів: переробка трьох ліній захисту
Як управління MLOps відображається у системах агентів: що має додати кожна з трьох ліній захисту, де знаходяться прогалини, та що сигналізують регулятори ЄС, FDA та фінансові органи.
Джерела: From MLOps to AgentOps: Redrawing the Three Lines of Defense
Агентський ШІ порушує правила управління, розроблені для звичайного програмного забезпечення та традиційних моделей, але це твердження легше побачити на конкретному прикладі. Роки роботи з MLOps, які включають каталоги моделей, конвеєри валідації, моніторинг відхилень та процеси схвалення в корпоративних та фінансових установах, не відкидаються, коли організація починає використовувати LLM та агентів. Те, що змінюється, є вужчим та більш конкретним, ніж припускають більшість людей.
Уявіть собі команду з управління ризиками моделей, яка обробляє звичайну заявку. У формі ставляться звичні запитання про дані навчання, номер версії, статус схвалення та дату останньої перевірки відхилень, і команда вже обробила безліч таких заявок. Потім йде опис системи: чотири взаємодіючі агента, шість інструментів, якими вони користуються, індекс пошуку, який оновлюється щодня, та результат, отриманий у результаті послідовності кроків, кожен з яких здавався правильним. Ніщо з цього не відповідає даним у формі.
Опитування McKinsey AI Trust 2026 року, яке охопило близько п’ятисот організацій, показує схожу картину: приблизно третина підприємств стверджує, що рівень їхнього управління достатній для вже існуючих автономних агентів. Решта продовжує використовувати стару форму заявки, сподіваючись, що вона достатньо хороша. Зазвичай це не так, тому корисним є визначення місця її недоліків.
Що вже охоплює існуюча програма
Управління MLOps — це сукупність механізмів контролю, які забезпечують надійність традиційної моделі машинного навчання від етапу навчання до припинення її використання. На практиці:
- Версіонування моделей, щоб завжди було зрозуміло, яка модель працює в продакшені та чому.
- Моніторинг відхилень, який виявляє погіршення продуктивності при зміні вхідних даних.
- Відстеження походження даних аж до наборів для навчання та перевірки.
- Процедури схвалення перед будь-яким випуском у продакшен.
- Дисципліна CI/CD та управління змінами, яка є обов’язковою для будь-якого програмного забезпечення в продакшені, і вона є частиною цієї програми, а не щось окреме.
Жоден з цих механізмів не функціонує сам по собі. Хтось має нести відповідальність за кожен елемент контролю, а хтось інший має перевіряти, чи виконав він свої обов’язки.
Відповідальність зазвичай розподіляється через три лінії захисту — цю схему банки та інші регульовані галузі вже давно використовують для визначення обов’язків. Одна уточнення: у 2020 році Інститут внутрішніх аудиторів перейменував її на Модель трьох ліній, змістивши акцент на створення цінності замість чистого захисту. У фінансових колах та серед тих, хто працює з ризиками моделей, все ще використовується термін «три лінії захисту», як і в цьому тексті, хоча офіційна назва змінилась.
У традиційній програмі MLOps розподіл виглядає так:
- Перша лінія, яка охоплює продукт, дані та інженерію, відповідає за розробку, тестування, впровадження та документування моделей.
- Друга лінія, яка стосується дотримання правил та ризиків, встановлює правила використання моделей, контролює наявність упереджень та перевіряє високоризикові застосунки перед їх запуском.
Ця структура є зрілою та добре зрозумілою, і вона ефективно працює для систем, для яких була розроблена, а саме для моделей із фіксованою структурою, які підтверджуються один раз та контролюються між циклами перевірки.
Як кожна лінія має змінитися для агентів
Управління AgentOps починається з тих самих трьох ліній, але зміст, який перевіряється кожною з них, відрізняється, оскільки системи поводяться по-різному. Основні відмінності зводяться до п’яти конкретних аспектів.
Один артефакт перетворюється на багато. Класичною моделлю є єдиний об’єкт, який потрібно версіонувати. Система з чотирма агентами — це збірка: базова модель, чотири запити до системи, шість визначень інструментів та шар пошуку, який оновлюється автономно. Кожен з цих елементів може змінювати поведінку, тому необхідно версіонувати та тестувати кожну частину. Це більше схоже на запити та схеми інструментів, які розглядаються як вихідний код, із системою контролю версій, перевіркою запитів на внесення змін та тестами типу «канаркові птахи» на окремій доробці, перш ніж щось буде запущено. Відстеження лише моделі залишає приблизно три чверті аспектів поведінки без керування.
Правильний результат потрапляє у допустимий діапазон. Якщо надати традиційній моделі такий самий вхідний даний, вона поверне такий самий результат, тому валідація є простою. Штучний інтелект може у різних запусках надавати два різні, але обґрунтовані відповіді. Тож другий підхід припиняє перевірку на правильність відповіді та починає перевіряти, чи залишаються відповіді у допустимих межах у більшості випадків. Це вимагає наявності механізму оцінки з визначеними пороговими значеннями — наприклад, мінімального рівня успішності на позначеному наборі даних перед випуском, а також запуску людського перегляду, коли рівень впевненості чи оцінки опускається нижче встановленого рівня. Узгодження того, що означає «допустимо у більшості випадків» для конкретного сценарію використання, є окремим завданням, яке не можна виконати за один день.
Один власник перетворюється на ланцюг. У окремої моделі, яка робить окреме прогнозування, є очевидний власник. У системі з чотирма агентами його немає. Коли кінцевий результат є неправильним, але жоден окремий крок не був помилковим, для діагностики потрібен журнал рішень, який фіксує проміжні передачі даних, а також кінцевий результат: вхідні дані кожного агента, кожне рішення та те, що було передано далі. Без нього ніхто не може сказати, який агент несе відповідальність, і перша та друга команди починають суперечити щодо цього після інциденту, замість того щоб домовитися заздалегідь.
Моніторинг відхилень — це не моніторинг поведінки. Перевірки відхилень порівнюють прогнози з відомою базовою лінією. Вони не бачать того, що робить агент під час виконання: які інструменти він використовує, які дії виконує, чи залишається він у межах поставлених завдань. Платформи для спостереження за агентами усувають цю сліпу зону, записуючи весь слід виконання — від викликів інструментів та параметрів до того, як результати одного агента впливають на наступного. Багато з них ґрунтуються на відкритих стандартах, таких як OpenTelemetry, що забезпечує портабельність слідів між різними постачальниками. Для цієї системи слід є єдиним артефактом, за допомогою якого аудитор може пізніше відтворити події. Без нього аудит третьої сторони полягає у перевірці «чорної скриньки» та позначенні цього процесу як незалежної верифікації.
Поновлення календаря стає безперервною зміною. Традиційні моделі поновлюються за певним графіком: щомісяця, щокварталу чи коли накопичується достатня кількість нових даних. Система, побудована на технологіях RAG або безперервної налаштуваності, може змінювати свою ефективну роботу так часто, як оновлюється її база знань, можливо, щодня. Якщо шар пошуку оновлюється щоночі, то третій елемент, який базується на квартальних перевірках, перевіряє систему приблизно у дев’яносто разів рідше, ніж вона змінюється.
Де зустрічаються ці два підходи
Якщо порівнювати їх безпосередньо, обидва підходи мають спільну структуру. Застосовуються ті самі три елементи, і обидва вимагають версіонування, тестування, перевірки та незалежного аудиту. Різниця полягає у деталізації, частоті та об’єктах, які вони перевіряють.
Управління процесами MLOps тут не є помилковим. Його підхід ґрунтувався на припущенні, що поведінка моделі залишається стабільною між перевірками, але система, чий індекс пошуку оновлюється щоночі, не може зберігати цю стабільність протягом такого тривалого часу. Усі п’ять відмінностей виникають через невірність цього припущення: те, що раніше змінювалося щомісяця, тепер може змінюватися щодня, іноді навіть без будь-яких змін у самій моделі.
Щоб подолати цю прогалину, не потрібно створювати нову функцію управління з нуля. Достатньо розширити існуючі підходи новими можливостями, які раніше не були потрібні, та чесно оцінювати витрати, пов’язані з кожною з них:
- Перший підхід: контроль версій запитів та інструментів із тестуванням перед їх впровадженням. Це переважно зміна інженерних практик, а не створення нової команди.
Жоден з цих елементів не є необов’язковим, якщо метою є достовірно визначити, який із чотирьох агентів прийняв рішення.
Що сказали регулятори наразі
Жодна окрема регуляторна система ще не повністю адаптувалася до агентних ШІ, але три існуючі моделі з різних галузей показують, куди рухається ця галузь.
- Закон ЄС про ШІ застосовується у всіх секторах. Обов’язки щодо прозорості, передбачені статтею 50, починають діяти 2 серпня 2026 року, незалежно від інших подій. Більш суворі вимоги Додатку III щодо високого ризику спочатку також починають діяти у цю дату, але запропонований пакет Digital Omnibus, який було принципово схвалено у травні 2026 року та все ще чекає на офіційне прийняття, відкладе їх на грудень 2027 року. У календарі відповідності це затримку слід вказати як поточну.
- Підхід FDA до медичних пристроїв з використанням ШІ є вертикальним та орієнтованим на продукт, а його ключовим інструментом є План контролю змін. За таким планом початкове схвалення вже дозволяє певні оновлення моделей, за умови, що вони залишаються в межах встановлених показників продуктивності. Він супроводжується рекомендаціями щодо належної практики машинного навчання та системою якості, що рухається у напрямку стандарту ISO 13485. Фактично контроль змін стає частиною процесу схвалення, а не обов’язком, який додається пізніше.
Жоден з цих документів не є шаблоном для копіювання. Якщо читати їх разом, вони вказують на певний напрямок: необхідно змінювати заздалегідь визначені межі, рівні ризиків, а також відкрито визнавати неузгодженість між чинними правилами та поведінкою агентів.
Повернення до форми подання заявки
Існуючу форму подання заявок можна залишити. Окрім неї, команді потрібен окремий опитувальник для багатоагентних систем, структурований за трьома напрямками, від яких вона вже залежить, і слід очікувати, що чесна відповідь вимагатиме справжніх зусиль.
Який крок програма подолає першим? Ймовірно, версіонування, оскільки це схоже на проблему керування версіями, яку інженери вже вміють вирішувати. Відповідальність за послідовні рішення, ймовірно, залишатиметься проблемою найдовше. Це проблема організаційної структури в технічному вигляді, і жодні етапи оцінки її не виправлять.
Пов’язана література
- Від агентських циклів до графів робочих процесів: типовий стан, брами перевірки та обмежена відновленість — Чому агенти, які працюють довго, не підходять для одного циклу, та як чітко визначені вузли, ребра, типові об’єкти, перевірені переходи та дозволи для кожного вузла роблять їх надійними.
- LLMOps для агента-асистента: MLflow Traces, оцінювання та брама CI — Створіть асистента для виконання завдань за допомогою PydanticAI та FastAPI, відстежуйте його роботу за допомогою MLflow, оцінюйте його продуктивність за допомогою інструментів GenAI та запобігайте регресіям у GitHub Actions, усе це на локальних моделях.