Операційний лог допомагає з’ясувати, що зламалося. Доказовий слід має відповісти, який контекст отримав агент, що запропонував, яке правило застосували, хто погодив виняток і що фактично змінилося. Непов’язані системи складно зіставити під час інциденту.
Спроєктуйте записи під запитання людини, яка перевірятиме систему. Визначте подію, власника, доступ, строк зберігання й спосіб відновлення. Збирайте лише потрібний контекст і не копіюйте чутливі дані до менш захищеного сховища.
Зв’яжіть запит, дозвіл і результат
Для операції зв’яжіть ідентифікатором запит, суб’єкта, запропоновану дію, ціль, версію політики, вердикт, погодження, виклик інструмента й результат. Записуйте відмови, скасування, переривання та невідомий стан після тайм-ауту так само чітко, як успіх. Це не вимагає зберігати приховані міркування моделі.
Відділіть «API відповів успішно» від «дію дозволили». Додайте часові позначки з відомою часовою зоною та версії, потрібні для аналізу. Перевірте, чи може інша людина відновити послідовність кроків і побачити контекст, доступний рецензенту.
Визначте, які дані потрібно маскувати або не записувати: повний текст звернення, ідентифікатори клієнтів, платіжні реквізити та секрети можуть створити новий ризик. Використовуйте контрольовані посилання на захищене джерело, коли цього достатньо. Перевірте, хто може переглядати записи та як фіксується такий доступ.
Не плутайте телеметрію з контролем
Метрики й трасування допомагають помічати затримки, помилки та навантаження. Вони самі не вирішують, чи дозволено дію. Контроль виконання приймає рішення до операції; журнал зберігає докази цього рішення. Хороша телеметрія може співіснувати з відсутністю механізму зупинки чи запису авторизації.
Захист від змін обирайте за моделлю загроз: права, розділення ролей, резервні копії, правила зберігання й перевірка незалежним фахівцем. Підпис або хеш-ланцюжок може виявити модифікацію, але не доводить повноту чи правдивість початкового запису. Перевірте пропущені події, розбіжність часу та відновлення вибірки.
Строк зберігання залежить від призначення запису, застосовних правил і потреб розслідування. Не копіюйте один універсальний строк у всі системи. Визначте власника політики, видалення, резервне зберігання та збереження на час спору чи розслідування там, де це застосовно; перевірте, що дані справді зникають із доступних пошукових шляхів.
Відділіть законодавчу вимогу від інженерної поради
Стаття 12 Акта ЄС про ШІ стосується можливості автоматичного запису подій системами високого ризику для простежуваності, доречної до їхнього призначення. Записи мають підтримувати виявлення ризиків, післяринковий моніторинг і роботу системи. Це не універсальна вимога для кожного AI-інструмента; застосовність оцінюють для конкретної системи й ролі.
Спеціальні поля статті 12(3) стосуються визначених систем дистанційної біометричної ідентифікації за пунктом 1(a) Додатка III, а не кожної системи високого ризику. Стаття не приписує конкретну криптографію, окрему базу чи однакові поля. Узгодьте правовий висновок із фахівцем, а технічний план прив’яжіть до призначення та потрібної простежуваності.
Проведіть настільну вправу з конкретною дією: нехай незалежний аудитор відновить перебіг дії за наявними доказами. Якщо бракує ідентифікатора, версії правила, рішення людини чи фактичного результату, зафіксуйте прогалину. Така перевірка показує практичну придатність журналу, не видаючи її за сертифікацію чи юридичний висновок.
Окремо стаття 26(6) стосується організації, що використовує систему високого ризику: вона зберігає автоматично створені журнали в межах свого контролю протягом строку, що відповідає призначенню системи, але не менше шести місяців, якщо право ЄС або національне право, зокрема правила захисту даних, не встановлює інше. Для фінансових установ можуть діяти вимоги внутрішнього управління за фінансовим законодавством. Це обов’язок розгортувача в зазначеному контексті, а не універсальний строк для всіх AI-систем.
Офіційне джерело: European Commission: Article 12. European Commission: Article 26(6).
Що можна зробити зараз
Візьміть завершену, заборонену й перервану дію. Попросіть колегу відновити джерело контексту, дозвіл, людське рішення та результат. Зафіксуйте, яких зв’язків бракувало й чи був доступ надмірним; усувайте прогалини до розширення збору даних.
