У більшості систем ШІ є журнали подій. Повноцінні реєстри аудиту трапляються значно рідше.
Ця різниця дорого обходиться, коли клієнт, регулятор, страховик або рада директорів ставить конкретне запитання: покажіть рішення, правило, чинне на той момент, стан погодження, докази та шлях скасування. Журнал налагодження може містити окремі частини відповіді. Рідко він подає її у формі, якій може довіряти той, хто проводить перевірку.
Журнали налагодження створюють для інженерів, які намагаються виправити поведінку системи у виробничому середовищі. Реєстри аудиту створюють для організацій, які мають підтвердити цю поведінку. Вони перетинаються, але це різні системи.
У компаніях, де ШІ є основою продукту й на які поширюються регуляторні вимоги, реєстр аудиту слід від початку вважати інфраструктурою відповідності вимогам. Це не звіт, який додають після запуску. Не пакетне завдання на сховищі даних, яке відновлює події з розрізнених слідів. Не папка з експортованими запитами до моделей. Реєстр — це довговічний запис рішень, що дає компанії змогу без імпровізації під тиском відповісти на запитання «що сталося і чому».
Коротко
- Журнал налагодження фіксує виконання; реєстр аудиту — рішення, правило, вердикт, докази та засіб скасування
- Схема реєстру і є механізмом контролю: те, що ви не вимагаєте записувати, ви не зможете перевірити
- Засоби контролю цілісності, як-от підписи чи ланцюжки хешів, можуть допомогти перевірці; прийнятність також залежить від повноти, походження та доказів контролю
- Створіть реєстр до інциденту: відновлення подій під тиском повільне, дороге й підриває довіру
- Вузький реєстр для рішень із суттєвими наслідками кращий за широке озеро журналів, у якому є все, крім підзвітності
Транскрипти — це не підтвердження походження
Поширена помилка — записати запит і відповідь моделі, а потім назвати це аудиторським слідом.
Транскрипт може бути корисним. Він показує, який текст надійшов до моделі й який текст вона повернула. Але агентні системи роблять більше, ніж обмінюються текстом. Вони знаходять документи, викликають інструменти, записують дані, надсилають повідомлення, оновлюють робочі процеси, запускають погодження і часом надають рекомендації, які люди перетворюють на реальні дії.
Питання аудиту не зводиться до «що сказала модель». Треба з’ясувати: «яку дію запропонували, яка політика її оцінила, який вердикт було винесено, які докази його підтвердили та що сталося далі».
Для цього потрібна структура.
Рядок реєстру аудиту має вказувати клас дії та відповідального суб’єкта. У ньому слід зазначати версію системи або політики, розрізняти запропоновану й виконану дію, фіксувати, чи людина погодила, відхилила або змінила дію, і містити засіб скасування, якщо він існує. Контексту має вистачати для відновлення рішення без зберігання зайвих чутливих даних.
Це не бюрократична охайність. Саме так стає можливою подальша перевірка.
Якщо реєстру немає, кожна серйозна перевірка перетворюється на криміналістичне розслідування. Інженери шукають журнали застосунків. Менеджери продукту — заявки. Фахівці з безпеки — інциденти. Хтось намагається зіставити часові позначки між системами, які не створювали для відповіді на одне й те саме запитання. Компанія, можливо, зрештою відновить перебіг подій, але таке відновлення буде ненадійним.
Реєстр запобігає цьому, записуючи перебіг подій у момент, коли вони відбуваються.
Схема і є механізмом контролю
Багато команд вважають аудит проблемою зберігання. Насправді це проблема схеми даних.
Якщо схема фіксує лише сирі повідомлення, організація зможе перевіряти лише сирі повідомлення. Якщо ж схема фіксує класи дій, вердикти, посилання на докази, погодження людей і засоби скасування, організація зможе перевіряти рішення.
Тому важливо проєктувати структуровані події. У корисному реєстрі є сталі поля, що дають змогу різним командам проводити перевірки. Відділ відповідності може шукати за версією політики. Безпека — за відхиленим класом дій. Інженерія — за робочим процесом та інструментом. Керівництво може запитати, скільки дій із незворотними наслідками було ізольовано минулого місяця.
Визначайте поля реєстру з огляду на реальне рішення та наявні для перевірки записи:
event_id- Ідентифікатор фактичної події, який використовують для зіставлення пов’язаних записів.
timestamp- Зафіксований час події із зазначеним джерелом годинника та точністю.
action_class- Категорія дії з затвердженої таксономії.
actor_id- Ідентифікатор суб’єкта, відповідального за фактичний запит, пов’язаний із контекстом його доступу.
policy_version- Затверджена версія політики, яку фактично застосували під час оцінювання.
policy_reviewed- Посилання на фактичний запис перевірки політики.
verdict- Зафіксований результат оцінювання контролю та його обґрунтування.
evidence_ref- Посилання на докази з контрольованим доступом.
approval_required- Чи вимагає застосовне правило погодження цієї дії.
approval_record- Фактичний рецензент, рішення, перевірений контекст і строк чинності, якщо погодження потрібне.
reversal_handle- Наявний і перевірений шлях відновлення або задокументована відсутність такого шляху.
execution_status- Спостережений стан виконання, пов’язаний із подальшим результатом.
integrity_metadata- Інформація для перевірки обраних засобів контролю цілісності, якщо їх застосовують; сама по собі вона не підтверджує правдивість чи повноту подій.
Поля допомагають із різними перевірками: клас дії групує ризики, версія політики вказує на застосоване правило, вердикт фіксує рішення, а засіб скасування описує доступний шлях відновлення. Перевірки цілісності можуть виявити зміни в зафіксованому вмісті, але самі собою не доводять повноту, виконання чи наявність повноважень.
Схема також формує дисципліну на межі системи. Якщо дія не може оголосити свій клас, її не слід непомітно виконувати. Якщо в дії немає посилання на докази, це має бути видно. Якщо потрібне погодження людини, реєстр має показувати, хто, що й коли погодив. Якщо засіб скасування неможливий, система має зафіксувати це як причину для суворішого контролю, а не приховувати у прозі.
Саме тут аудит перестає бути пасивним.
Вимога створити рядок реєстру змушує виробничу систему робити ризик видимим ще до перевірки. Кожен новий робочий процес має відповісти: до якого класу належить дія, які докази ми зберігаємо, яка версія політики її оцінює і що робити, якщо дія виявиться помилковою?
Ці запитання — механізми управління, замасковані під поля даних.
Захист від непомітної підміни — не декорація
Наступний крок до зрілості — захист від непомітної підміни.
У звичайному операційному журналюванні команди часто припускають, що доступ на запис контролюється, а наявних журналів достатньо. Для налагодження низькоризикових функцій це може бути правдою. Для доказів відповідності вимогам цього замало. Якщо організації потрібно довести, що запис існував у певний час, його не переписали пізніше і він належить до конкретного ланцюга рішень, реєстру потрібні властивості цілісності.
Якщо ви використовуєте схему підпису на кшталт Ed25519, задокументуйте ключі підпису, процес перевірки та дії у разі компрометації ключа. Дійсний підпис підтримує перевірку цілісності за певних припущень довіри; він не доводить правдивість опису події.
Мета не в тому, щоб вразити аудиторів криптографією. Мета — зменшити кількість припущень, яким доводиться довіряти.
Рецензенту потрібні запис і засоби перевірити його походження та цілісність. Поясніть межу довіри, що саме може виявити перевірка, а які пропуски чи обходи вона не виявить; сама криптографія не доводить, коли саме відбулася дія.
Підпис має підтримувати операційну модель, а не замінювати її. Вам однаково потрібні контроль доступу, політика зберігання, дисципліна резервного копіювання, реагування на інциденти та процес перевірки. Але підписана подія реєстру дає цим процесам надійніший об’єкт для роботи.
Щоб зрозуміти правове підґрунтя того, чому вимога журналювати «настільки, наскільки це необхідно» залежить від результату, а не обсягу, дивіться матеріал «Стаття 12 Акта ЄС про ШІ: пояснення вимог до журналювання».
Журнал налагодження та реєстр аудиту: порівняння
| Властивість | Журнал налагодження | Реєстр аудиту |
|---|---|---|
| Хто читає | Інженер о другій ночі | Аудитор, регулятор, страховик |
| Для чого оптимізовано | Швидке усунення несправностей | Обґрунтованість доказів |
| Схема | Неформальна, може змінюватися щотижня | Стабільна, із версіями, визначеними договором |
| Зберігання | Дні або тижні | Строк зберігання визначають застосовне право, мета та зобов’язання |
| Стійкість до підміни | За можливості | Криптографічна |
| Охоплення | Найкраще, коли всеосяжне | Найкраще, коли обмежене рішеннями з суттєвими наслідками |
| Що визначає вартість | Обсяг подій | Кількість класів дій |
| Наслідок збою | Втрачені хвилини налагодження | Провал аудиту, втрата довіри клієнта |
Зазвичай команда може вести обидва типи записів — і їй варто так робити. Помилка — використовувати журнал налагодження для відповідей на аудиторські запитання, а під час перевірки виявити, що ці відповіді не витримують аналізу. Про ширшу різницю між спостереженням за системою та управлінням нею читайте в матеріалі «Спостережуваність і управління AI-агентами».
Створіть реєстр до інциденту
Найгірший час проєктувати реєстр аудиту — після скарги клієнта.
Після інциденту всі хочуть одного: чіткої хронології, контексту рішення, стану контролю, відповідальної системи, запису погодження та шляху усунення наслідків. Якщо реєстру не було в момент події, команді доведеться відновлювати цю хронологію із систем, створених для інших цілей.
Це повільно й ненадійно. До того ж це підриває довіру. Клієнт може прийняти, що система ШІ помилилася. Але йому буде важче пробачити постачальника, який не може пояснити помилку без кількох днів внутрішніх пошуків. Про те, чому звичайних журналів недостатньо для такої перевірки, читайте в матеріалі «Чому журнали AI-агента не витримають аудит».
Практичний проєкт можна почати з малого. Виберіть першу важливу точку ухвалення рішень. Визначте вузьку схему події. Створюйте рядки в момент ухвалення рішення, а не відкладеним пакетним завданням. Додайте клас дії, посилання на вхідний набір даних, посилання на результат, вердикт, версію політики, стан погодження та засіб скасування. Підписуйте подію, якщо цього вимагають норми відповідності. Зробіть експорт зрозумілим для людей поза інженерною командою.
Не чекайте на ідеальну платформу. Вузький реєстр для рішень із суттєвими наслідками кращий за широке озеро журналів, у якому є все, крім підзвітності.
Анонімізоване впровадження в операційних процесах наочно це показало. Коли кожна синхронізація, класифікація сповіщень і суттєвий запис створювали структурований рядок у реєстрі, характер перевірки змінився. Запитання, які раніше залежали від пам’яті оператора, перетворилися на пошукові запити. Для винятків з’явилися обґрунтування. Шляхи відновлення стали явними. Реєстр не усунув потреби в людському судженні. Він зробив це судження підзвітним.
Переваги інфраструктурного підходу
Якщо ставитися до реєстру аудиту як до інфраструктури, змінюється дорожня карта.
Нові робочі процеси агентів успадковують шаблон реєстру. Нові політики використовують наявні поля подій. Експорт для закупівель стає повторюваним. Перевірка інцидентів пришвидшується. Керівництво бачить, які дії дозволяють, відхиляють або ізолюють. Інженери можуть налагоджувати поведінку, не вдаючи, що журнали налагодження є доказами відповідності вимогам.
Реєстр також створює основу для погоджень. Коли система фіксує клас дії, версію політики та вердикт, стає природно спрямовувати низькоризикові дії, які можна скасувати, на автоматичне виконання, а незворотні чи суттєві дії — на погодження. Без такого набору даних логіка погодження зазвичай розпорошується кодом застосунку та ручними процесами.
Є одне безумовне правило: не можна робити реєстр необов’язковим. Якщо лише деякі шляхи записують докази, організація переоцінить своє охоплення. Суттєві дії мають або записуватися до реєстру, або явно виходити за межі його охоплення із задокументованою причиною. Непомітні прогалини гірші за відомі, бо створюють хибну впевненість.
Ефективність інфраструктури відповідності вимогам не вимірюється тим, наскільки вражаюче вона виглядає на схемі. Вона визначається тим, чи може компанія швидко й точно відповісти на складне запитання та надати докази, які витримають перевірку.
Поширені запитання
З: Чи можна додати реєстр аудиту поверх наявних журналів застосунку?
Теоретично так; на практиці схему потрібно проєктувати з боку рішень, а не виводити з журналів. Реєстр, створений постфактум, не відновить поля, яких не було записано під час рішення: версію чинної на той момент політики, стан погодження, засіб скасування. Почніть із наступного робочого процесу з суттєвими наслідками та створюйте рядки реєстру в момент ухвалення рішення. Заповнення минулих записів — окремий і вужчий проєкт.
З: Чи обов’язково використовувати Ed25519, чи підійде будь-яка схема підпису?
Ed25519 — це необов’язковий проєктний вибір, а не вимога Акта ЄС про ШІ чи SOC 2. Обирайте засоби контролю цілісності відповідно до аудиторії, яка перевірятиме дані, і моделі загроз; врахуйте зберігання ключів, їх ротацію, дії у разі компрометації та перевірку експорту. Задокументуйте, чи можуть рецензенти виконати перевірку самостійно.
З: Чи замінює реєстр сховище даних?
Ні. Реєстр — це запис рішень; сховище даних — аналітичний інструмент. Багато команд передають підписані події реєстру до сховища для узагальнених звітів, але реєстр лишається авторитетним джерелом. Якщо дані сховища та реєстру розходяться, пріоритет має реєстр.
З: Як працювати з чутливими даними в реєстрі?
За можливості посилайтеся на чутливі докази, обмежуйте доступ і встановлюйте строки зберігання для матеріалів, на які є посилання. Залишайте в реєстрі необхідний контекст рішення та перевіряйте, чи посилання надалі доступні. І посилання, і сам реєстр можуть розкривати чутливу інформацію та потребують контролю доступу.
З: Яким малим може бути перший корисний реєстр?
Почніть з одного робочого процесу із суттєвими наслідками та полів, потрібних його рецензентам. Перш ніж розширювати охоплення, перевірте повноту, записи дозволів, цілісність, зберігання й експорт. Заповнюйте реєстр фактичними подіями та відкрито зазначайте відсутні докази.
Автор — Нікола Ковтун, засновник Infracortex AI Studio. Ми допомагаємо інженерним командам перетворювати рішення агентів на структуровані, придатні до перевірки й захищені від непомітної підміни докази. Cortex Audit Ledger розташовується перед шляхами виконання дій агентами та записує рішення в момент дії, а не постфактум. Для вашого технологічного стеку замовте ознайомчу розмову або перегляньте опис послуги Security Gate.
Дивіться також: «Чому журнали AI-агента не витримають аудит» | «Стаття 12 Акта ЄС про ШІ: пояснення вимог до журналювання» | «Що таке рівень підзвітності AI-агентів?»