Аудит дій AI-агентів: де втрачається простежуваність
Агентний ланцюжок рідко виглядає як один запит і одна відповідь. Навіть просте завдання — це послідовність переходів: модель міркує, викликає інструмент, отримує результат, коригує план і йде далі.
Простежуваність агентних ланцюжків тримається рівно доти, доки кожен такий перехід зафіксовано разом із його входом, виходом і рішенням, яке на ньому було ухвалено.
Розрив з'являється не всередині моделі, а на стиках. Незаписані виклики інструментів — найчастіша діра: агент звертається до внутрішньої системи, її відповідь впливає на підсумкову дію, а в журналі залишається лише текст фінального повідомлення. Рядок є, а відновити за ним причину рішення вже неможливо.
Далі в гру входять повторні спроби, паралельні гілки та часткові збої. Виклик пішов двічі, один раз упав за таймаутом, другий повернув дані — і без наскрізного ідентифікатора кроку ці записи не пов'язати між собою. У журналі з'являється набір розрізнених подій, порядок і зв'язок яких доводиться вгадувати.
Ціна проявляється в момент розбору інциденту з агентом. Замість того щоб відкрити слід і побачити, який аргумент пішов в інструмент і що повернулося, команда реконструює картину за непрямими ознаками: фрагментами відповідей, метриками, опитуванням очевидців.
На це йдуть дні, а висновки залишаються ймовірнісними — їх складно пред'явити замовнику й службі безпеки. Без повного сліду інцидент не можна відтворити, отже, не можна й переконатися, що виправлення закриває проблему.
Аудит дій AI-агентів будується не на кількості логів, а на наскрізному зв'язку кроків. Розбираємо, як це закривається технічно.
Що змінюється після впровадження: розбір інцидентів і відмови
Час локалізації причини
Раніше розбір починався зі звіряння розрізнених логів: кроки агента лежали в одному місці, виклики інструментів — в іншому, права — у третьому. Причина випливала годинами, а частина епізодів так і залишалася з непідтвердженою версією.
Після впровадження журнал будується навколо ідентифікатора трасування: крок, виклик, аргументи й відповідь прив'язані до однієї сесії, тому ланцюжок відновлюється за хвилини, а не за зміну.
Частка інцидентів із непідтвердженою причиною падає до поодиноких випадків — щодо кожного є вхідні дані, рішення агента й результат його перевірки.
Принцип той самий, що в спостережуваності сервісів OpenTelemetry, лише розмітку розширено діями агента: видно не «щось упало», а на якому кроці й за чиїм дозволом.
Які класи відмов зникають
- Повторні дії агента — ідемпотентні ключі та дедуплікація викликів: два однакові списання або листи не проходять.
- Вихід за межі прав — дозволи перевіряються на кожному виклику, а не один раз під час старту сесії; спробу вийти за рамки фіксують і блокують.
- Витік даних у відповіді — перевірка на виході редагує чутливі поля до надсилання користувачу.
Відтворення сесії закриває і розбір, і регрес: зберігаються входи, версії політик і рішення агента, тому епізод можна програти заново й переконатися, що виправлення прибрало відмову, а не замаскувало її.
Способи збору подій: порівняння варіантів
Повнота журналу залежить від того, у якій точці перехоплюється подія.
Чим ближче до агента, тим більше деталей потрапляє в запис — плани, проміжні міркування, аргументи викликів; чим далі від нього, тим нижчі накладні витрати на запис і тим менше шансів втратити подію під час збою самого агента. На практиці варіанти не конкурують, а доповнюють один одного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Збір подій усередині агента | Потрібні міркування, плани й проміжні кроки, а не лише факт виклику | Тримається на дисципліні коду: пропустили виклик — подія зникла з журналу |
| Перехоплення викликів інструментів на проміжному шарі | Агент звертається до зовнішніх сервісів, баз і файлів | У записі видно лише виклики інструментів, внутрішня логіка залишається за кадром |
| Збір на стороні оркестратора | У процесі кілька агентів і підзадач, важлива маршрутизація | Деталізація нижча, навантаження лягає на вузол оркестрації |
| Потік від постачальника моделі | Модель зовнішня, доступу до її коду немає | Склад полів і затримку задає постачальник, частину деталей не віддають |
Вибір диктує питання: які події зобов'язані пережити збій і подальший розбір. Для інциденту зазвичай беруть два рівні — перехоплення викликів інструментів плюс журнал оркестратора, а внутрішній збір додають там, де потрібна логіка ухвалення рішення.
Порядок впровадження: від схеми подій до передавання
Порядок робіт фіксуємо до першого рядка коду: спочатку описуємо, що вважаємо дією агента, і лише потім піднімаємо збір. Інакше журнал виходить або надмірним, або не відповідає на головне питання — хто і на якій підставі зробив виклик.
- Розбір поточних ланцюжків: проходимо викликами моделі, інструментами та зовнішніми сервісами, позначаємо, де втрачається ідентифікатор сесії і де рішення ухвалюється без запису.
- Схема подій: узгоджуємо закритий перелік — запит до моделі, виклик інструмента, відмова політики, зміна стану. Кожній події призначаємо обов'язкові атрибути та зв'язок за ідентифікатором ланцюжка.
- Словник полів журналу: типи, обов'язковість, формат часу й правила маскування персональних даних — до того, як записи почнуть накопичуватися.
- Налаштування збору подій: підключаємо джерела, буферизацію на випадок недоступності сховища й захист від втрати записів під час збою агента.
- Розмежування доступу: ролі на читання, вивантаження й адміністрування; звернення до самого журналу — теж подія.
- Перевірка на тестовому контурі: успішний виклик, відмова, обрив зв'язку, повторне доставляння — звіряємо повноту записів і відновлення ланцюжка за ідентифікатором.
- Приймання системи аудиту й передавання: розбираємо вибірку реальних ланцюжків, віддаємо документацію й навчаємо чергову зміну розбору інцидентів.
Схема подій і словник полів залишаються у вас як робочий документ: за ними змінюються агенти й налаштовуються правила реагування, без звернення до нас за кожним доопрацюванням.
Комплект на виході: схеми, політики, регламенти
Після запуску в замовника залишається робочий комплект, за яким журнал живе без нас: його можна розширювати, чистити й передавати новим інженерам. Кожен артефакт прив'язаний до конкретної операції — додавання події, розбору інциденту, надання доступу.
- Схема потоків подій — шлях від виклику агентом інструмента до запису у сховищі: точки перехоплення, буфер, повторні надсилання, поведінка за недоступності приймача. За нею видно, які дії агента до журналу не потрапляють.
- Словник полів — значення кожного поля, обов'язковість, допустимі формати. Без нього розбір інциденту перетворюється на здогади про те, що саме записав агент.
- Політики доступу до журналу — хто і за яких умов читає записи, термін зберігання, заборона правки. Журнал дописуваний: змінити минулий запис не можна технічно, а не «за інструкцією».
- Ролі й права на читання — окремі набори для чергової зміни, розбору інцидентів, аудиту й служби безпеки: кожен бачить свій зріз, повний доступ не видається за замовчуванням.
- Правила маскування даних — що вирізається до запису: персональні дані, ключі доступу, вміст звернень. Маскування стоїть на вході, тому до сховища чутливі значення не потрапляють.
- Регламент розбору інцидентів — класифікація подій, термін реакції, хто ухвалює рішення зупинити агента, як фіксуються висновки. До нього додано інструкції для чергової зміни: що дивитися і що зібрати до підключення того, хто розбирається.
Документацію передаємо до вашого репозиторію й супроводжуємо перші зміни, поки команда не почне правити її сама.
Кейс: розбір інциденту до та після впровадження журналу
Тригером став інцидент з агентом підтримки: підключений до внутрішньої системи через інструменти, він поза сценарієм змінив статуси й суми за частиною замовлень. Дізналися про це від клієнтів — зміни вже пішли в білінг.
Розслідування відбувалося без журналу: у логах застосунку були виклики методів, але не було ні ідентифікатора агента, ні версії інструкцій, ні прив'язки виклику до сесії.
Три тижні ручного зіставлення дали атрибуцію менш ніж для половини дій, межі інциденту залишилися розмитими, а відкат довелося робити по всій базі — разом із легітимними змінами.
Що змінили
Запровадили незмінний журнал: записи лише додаються, правка й видалення недоступні. На кожен виклик інструмента пишуться агент і версія його інструкцій, вхідні й вихідні дані, обґрунтування рішення, ідентифікатори сесії та батьківської задачі.
Записи приведено до формату трасування OpenTelemetry і зберігають хеш попередньої — пропуск або підміну виявляють, а писати може лише середовище виконання агента.
Метрики до та після
- Розслідування епізоду: три тижні ручного пошуку → вибірка за агентом, сесією та інтервалом часу за години.
- Атрибуція дій: підтверджувалася менш ніж для половини викликів → 100%, з версією інструкцій та ініціатором на кожному кроці.
- Відкат: повне відновлення бази → точковий відкат лише зачеплених записів.
«Схожий випадок розібрали за день і знайшли кореневу причину — перетин прав у двох інструментів, а не помилку моделі», — керівник напряму.
Що робити, якщо система вже працює в продакшені?
Зупиняти агентів не потрібно: збір подій вбудовується як надбудова над точками, де агент викликає інструменти й зовнішні сервіси.
Код агентів при цьому не переписується — перехоплювач фіксує вхідні й вихідні дані виклику та передає подію окремим потоком, щоб час відповіді не зростав.
Поетапність тут не компроміс, а спосіб знизити ризик. Спочатку під спостереження потрапляють найризикованіші сценарії — ті, що змінюють дані, пишуть у зовнішні системи або видаляють записи.
Такі дії незворотні, і саме щодо них найчастіше запитують «хто і на якій підставі це зробив». Решта підключаються наступними хвилями, коли перші події вже перевірено на повноту.
Кожна хвиля — це конфігурація, а не нове складання сервісу. Перехоплювач вмикається прапорцем на групу сценаріїв, правила маскують персональні дані на вході, події йдуть у чергу, а потім у сховище.
Якщо сховище недоступне, вони накопичуються в локальному буфері й надсилаються після відновлення зв'язку: короткий збій не повинен коштувати історії дій.
Пріоритизація будується на двох осях — імовірність помилки в сценарії та ціна її наслідків. Незворотні дії та зовнішні інтеграції йдуть першими, діалогові й довідкові — останніми.
Ефект видно з першої хвилі: журнал аудиту покриває саме ті шляхи, де раніше розбір інциденту був неможливий.
Відкат теж передбачено: зняття прапорця повертає систему до початкової поведінки, а вже зібрані події залишаються доступними.
Якщо ваші агенти вже в експлуатації — розкажіть, які сценарії викликають найбільше питань, і ми повернемося з планом поетапного впровадження під ваш контур.
Сумніви щодо журналу аудиту: розбираємо за пунктами
Заперечення щодо журналу аудиту зазвичай одні й ті самі, і вони справедливі: запис легко зробити неповним, легко переписати, легко перетворити на звалище персональних даних. Нижче — як ми закриваємо чотири найчастіші сумніви на рівні схеми зберігання й правил запису.
Агент викличе модель напряму, оминаючи загальний шлюз — запис загубиться?
Збираємо події з двох шарів: перехоплення на транспортному рівні та обробники всередині процесу агента, де фіксуються виклики інструментів і звернення до зовнішніх сервісів.
Якщо подія пройшла лише одним шляхом, у записі залишається позначка про неповноту ланцюжка, а локальний буфер досилає пропущене за першої можливості. Розрив видно у звіті, а не маскується.
У записах опиняться персональні дані — що з цим робити?
За замовчуванням журнал зберігає ідентифікатор суб'єкта та метадані виклику, а не тіло запиту й відповіді. Там, де повний текст справді потрібен для розбору, вмикаємо маскування полів і псевдонімізацію — зіставлення з особою живе окремо й доступне вузькому колу ролей.
Скільки зберігати записи, щоб журнал не став баластом?
Термін призначається за класом події, а не єдиною цифрою: операційні записи живуть недовго, доступи та значущі рішення — тривало. Далі працює правило життєвого циклу: прострочене вивантажується в холодне сховище, ще пізніше видаляється разом із ключами.
Записи можна переписати заднім числом — як це виключити?
Кожен запис отримує відбиток попереднього та підпис вузла, який його створив, тому правка в середині ламає весь подальший ланцюжок.
Кореневий відбиток періодично фіксуємо на зовнішній стороні, а саме сховище тримаємо в режимі лише додавання — видалити або підмінити минуле не можна, не залишивши сліду.
Обговоримо вашу задачу й повернемося з планом
Щоб перейти від розмови до плану, достатньо опису контуру: які агенти діють, хто ініціює виклики, через які сервіси проходять запити, де стоїть сховище і хто відповідає за інфраструктуру.
Цього достатньо, щоб розкласти задачу на етапи й повернутися з оцінкою термінів і межами робіт — без довгого передпроєктного циклу.
- Обговорення задачі: розбираємо сценарії агентів, хто ухвалює рішення, що вважається чутливою дією і що саме має потрапляти в аудит дій AI-агентів.
- Схема збору: визначаємо точки перехоплення — шлюз перед моделями, виклики інструментів, звернення до баз, — і формат події: хто, що, коли, з яким контекстом і результатом.
- План етапів впровадження: пілотування на одному агенті, потім тиражування, налаштування зберігання й термінів давності, підключення пошуку та вивантажень.
- Склад робіт з аудиту: перелік інтеграцій, правила нормалізації подій, розмежування доступу до журналів, захист від підміни записів.
- Критерії приймання: частка дій агентів, покритих записом, повнота контексту за кожним кроком, час пошуку інциденту, відновлення ланцюжка рішень від запиту до результату.
- Що надіслати: список сервісів і агентів, приклад типового запиту й відповіді, вимоги регуляторів або внутрішніх служб, обмеження за термінами зберігання.
- Подальші кроки: узгоджуємо межі, фіксуємо план етапів і критерії приймання, після чого починаємо з пілота.
Опишіть задачу в такому вигляді — повернемося з оцінкою, планом етапів і складом робіт.
