Стаття 12 стосується можливостей запису подій у системах ШІ високого ризику. Перетворіть цей обов'язок на план журналювання конкретного процесу, відокремлюючи вимоги закону від інженерних способів їх виконання.
Що насправді говорить стаття 12
Стаття 12 вимагає від систем високого ризику можливості автоматично записувати події протягом їхнього життєвого циклу з простежуваністю відповідно до призначення. Події мають підтримувати виявлення ризиків, післяринковий та операційний моніторинг. Спеціальні поля статті 12(3) — період використання, референсна база, вхідні дані зі збігом та особи перевірки — стосуються дистанційної біометричної ідентифікації з пункту 1(a) Додатка III.
На кого поширюється стаття 12
Застосування визначають за роллю учасника, призначенням системи та територіальною сферою статті 2. Саме опрацювання даних про резидента ЄС не встановлює всіх обов'язків AI Act. Задокументуйте оцінку та роль провайдера або користувача системи.
Чеклист журналювання за статтею 12 для інженерних команд
Використайте наведені інженерні перевірки для виконання застосовних обов'язків запису подій. Для кожної визначте відповідального й тест; заповнений чеклист не є сертифікацією.
Структурні вимоги
Перевірте охоплення роботи системи, включно зі збоями й перериваннями. Протестуйте втрату зв'язку, недоступне сховище та зміни версій моделі чи інструмента, щоб приховані прогалини стали помітними.
Вимоги до змісту
Оберіть контекст події для призначення системи й потрібного моніторингу. Перевірте зв'язок результату з необхідним джерелом і версією системи без розкриття сторонньої персональної інформації.
Вимоги до цілісності
Обирайте засоби цілісності за моделлю загроз і застосовними вимогами. Можуть допомогти обмеження доступу, керування зберіганням, сховище лише для додавання та криптографічна перевірка. Стаття 12 не приписує Ed25519, хеш-ланцюжок або окремий сервіс зберігання. Підпис допомагає виявляти зміни за належної перевірки та керування ключами, але не доводить правдивості початкового запису чи успішного аудиту.
Операційні вимоги
Призначте відповідальних за моніторинг, доступ, зберігання та відновлення записів. Перевірте отримання даних для запиту на перевірку й опишіть повідомлення та розслідування збоїв сховища.
Відокремлюйте документацію від журналів. Стаття 18 встановлює для визначеної документації провайдера період, що закінчується через десять років після виходу на ринок або введення в експлуатацію. Статті 19(1) та 26(6) стосуються автоматичних журналів під контролем провайдера або користувача: строк за призначенням системи, щонайменше шість місяців, якщо право ЄС або національне право, зокрема захист даних, не передбачає іншого. Також можуть діяти фінансові правила; універсального строку п'ять-сім років для всіх журналів агентів немає.
Поширені прогалини, які пропускають інженерні команди
Перевірте записи, які неможливо пов'язати між інструментами, розбіжності часу та видалення потрібних доказів налаштуваннями зберігання. Окремо перевірте, чи журналювання не копіює зайві персональні дані до менш захищеної системи.
Часті запитання
Чи потрібні кожній системі біометричні поля статті 12(3)? Ні: вони стосуються визначених систем дистанційної біометричної ідентифікації. Іншим системам високого ризику потрібен запис подій відповідно до призначення й застосовних обов'язків.
Огляд оновлено 1 жовтня 2026 року: AI Omnibus набрав чинності 27 липня 2026 року. Вимоги глави III, розділів 1-3 застосовуються з 2 грудня 2027 року для систем статті 6(2)/Додатка III та з 2 серпня 2028 року для систем статті 6(1)/Додатка I з урахуванням перехідних положень. Інші обов'язки мають окремі дати застосування.
AI Act: консолідований текст, 27 липня 2026 | Європейська комісія: набрання чинності AI Omnibus | GDPR: Регламент (ЄС) 2016/679