Система аудит-трейлу для AI-агентів
Автономний агент прийняв рішення, яке виявилося невірним. Хто несе відповідальність? Що саме агент бачив у момент прийняття рішення? Які інструменти викликав і в якому порядку? Без audit trail ці питання не мають відповіді — а отже, немає ні налагодження, ні compliance, ні довіри до системи. У нашій практиці кожен другий проект стикається з цією проблемою. Ми розробили підхід, який поєднує технічну глибину та відповідність регуляторним вимогам.
Audit trail для AI-агентів принципово відрізняється від звичайного application logging. Потрібно фіксувати не тільки «що сталося», але й «чому агент це зробив» — вхідний контекст, reasoning, проміжні висновки. Наш досвід показує: правильно налаштований трейлінг скорочує час пошуку помилок на 70% і повністю виключає питання регуляторів.
Що потрібно логувати?
Мінімальний склад запису аудит-логу для AI-агента:
| Поле | Опис | Приклад |
|---|---|---|
trace_id |
Унікальний ID сесії агента | agt-7f3a2b-... |
step_id |
Крок всередині сесії | step-4 |
timestamp |
ISO 8601 з мікросекундами | 2025-03-15T14:23:11.847Z |
agent_id |
Ідентифікатор агента/ролі | procurement-agent-01 |
user_id |
Хто ініціював задачу | user:[email protected] |
action_type |
Тип дії | tool_call, llm_inference, decision |
tool_name |
Викликаний інструмент | query_database |
tool_input |
Аргументи (з маскуванням PII) | {"query": "SELECT ..."} |
tool_output_hash |
Хеш результату | sha256:3f8c... |
llm_prompt_hash |
Хеш промпту | sha256:9a1d... |
decision_reasoning |
Пояснення агента | "Threshold exceeded, escalating" |
latency_ms |
Час виконання кроку | 342 |
Повний вивід LLM і результати інструментів зберігаються окремо (обсяг великий), у лозі — тільки хеші для цілісності. Такий підхід гарантує, що навіть при витоку даних зловмисник не відновить вихідні промпти.
Як забезпечити незмінність логу?
Audit trail безглуздий, якщо його можна змінити постфактум. Використовуємо кілька підходів залежно від вимог:
Append-only storage. PostgreSQL з RULE ON UPDATE DO INSTEAD NOTHING або ClickHouse з MergeTree в режимі тільки вставки. Найпростіше, достатньо для більшості випадків.
Криптографічний ланцюжок. Кожен запис містить хеш попереднього — як blockchain без розподіленості. Дозволяє виявити вставку або видалення записів.
Зовнішній журнал. Дублювання подій у AWS CloudTrail, Azure Monitor або імутабельний S3 bucket з Object Lock. Використовується, коли регулятор вимагає зберігання логів у третьої сторони.
Ми гарантуємо цілісність даних на всіх етапах — від запису до архівації.
Практичний кейс: фінансовий агент під аудитом
Наш клієнт — страхова компанія, агент автоматично формує котирування та приймає рішення за стандартними страховими випадками. ЦБ запитав аудит автоматизованих рішень за останні 3 місяці.
Без audit trail це означало б 3 місяці ручної реконструкції. З впровадженим трейлінгом:
- Вивантаження всіх рішень агента за період — 1 SQL-запит, 40 секунд
- Для кожного рішення — повний контекст: вхідні дані, викликані інструменти, reasoning
- Автоматичний звіт по патернах: скільки випадків автоматично схвалено/відхилено/ескальовано, розподіл за категоріями
- Виявлено 3 системні помилки в логіці агента (неправильна обробка граничних випадків), які без трейлу були б непомітні
Аудит пройдено без зауважень. Три помилки виправлено до того, як вони призвели до фінансових наслідків. Економія для клієнта склала близько 40% часу compliance-відділу.
Що входить у роботу?
Наша пропозиція включає:
- Проектування схеми аудит-логів під вашу архітектуру агентів
- Налаштування append-only storage або криптографічного ланцюжка
- Інтеграція з OpenTelemetry та існуючими системами моніторингу
- Розробка політик retention та автоматичної архівації
- Документація та навчання команди
Середні терміни впровадження: від 2 до 6 тижнів залежно від складності. Ми також надаємо гарантію на коректність трейлінгу протягом року.
Інтеграція з OpenTelemetry
Сучасний підхід — стандартизувати трейсинг агента через OpenTelemetry. Кожен крок агента — span з атрибутами. Це дозволяє:
from opentelemetry import trace tracer = trace.get_tracer("ai-agent") with tracer.start_as_current_span("tool_call") as span: span.set_attribute("tool.name", tool_name) span.set_attribute("agent.id", agent_id) span.set_attribute("user.id", user_id) result = execute_tool(tool_name, args) span.set_attribute("tool.output_hash", sha256(result)) Трейси експортуються в Jaeger, Tempo або комерційні APM-системи. Додатково — метрики в Prometheus, візуалізація в Grafana. OpenTelemetry-рішення в 3 рази швидше впроваджується, ніж саморобний трейлер, і підтримується спільнотою.
Зберігання та retention
Обсяг логів агента може бути значним: активний агент генерує 50–500 МБ структурованих логів на добу. Рекомендована схема:
| Тип зберігання | Термін | Технологія | Запити |
|---|---|---|---|
| Hot storage | Останні 30 днів | PostgreSQL або ClickHouse | Швидкий пошук |
| Warm storage | 30 днів – 1 рік | S3/MinIO з Parquet | Через Athena/DuckDB |
| Cold storage | Більше 1 року | S3 Glacier | Тільки для compliance |
Ми підбираємо оптимальну конфігурацію під ваш бюджет та вимоги регуляторів. Наша команда має 5+ років досвіду в розробці AI-систем та понад 50 реалізованих проектів з аудит-трейлами.
Замовте аудит своєї системи
Якщо ви хочете перевірити, чи готові ваші AI-агенти до регуляторної перевірки, зв'яжіться з нами. Отримайте консультацію з трейлінгу та оцінку вартості впровадження. Ми допоможемо вибудувати прозору та захищену систему логування.