2 августа 2026 года должен был наступить один из ключевых дедлайнов EU AI Act.
27 июля вступил в силу AI Omnibus и часть high-risk требований получила новые даты.

В лучших традициях менеджмента: release date давно стоит в календаре, а непосредственно перед ней выходит обновление roadmap.

Справедливости ради, решение не принимали за шесть дней до дедлайна. Политическое соглашение было достигнуто ещё 7 мая, а 27 июля изменения уже вступили в силу, но со стороны менеджмента это всё равно хороший кейс: норматив, под который компании строили планы, изменился.

Причина тоже довольно знакомая.

Для полноценного применения high-risk требований нужны стандарты, руководства и другие артефакты. CEN и CENELEC не успели подготовить стандарты в первоначально ожидаемые сроки, и Еврокомиссия прямо называет это одной из причин переноса. Теперь правила для high-risk use cases из Annex III применяются с 2 декабря 2027 года, а для AI, являющегося продуктом или компонентом безопасности регулируемого продукта по Annex I, с 2 августа 2028 года.

Однако мы должны учитывать важный нюанс: AI Act не перенесли целиком. Например, обязательства по обеспечению прозрачности по Article 50 начали применяться с 2 августа 2026 года. Поэтому на сдвиг сроков не стоит реагировать:

Отлично, AI Act отложили, вернёмся к нему через год

Мы должны понять, что именно представляет собой ваша AI-система, какую роль играет ваша компания, к какой ветке норматива относится use case и какие controls уже нужны сейчас. Последние месяцы я отдельно работаю над этой задачей в контексте AI governance и собрал для неё свой assessment toolkit.

В упрощённом виде подход выглядит так:

AI inventory
    ↓
Role & Scope
    ↓
Intended Purpose
    ↓
Risk Classification
    ↓
Applicable Obligations
    ↓
Existing Controls
    ↓
Evidence
    ↓
Gaps
    ↓
Remediation Plan

Ниже покажу часть этого подхода на EU AI Act. Это не юридическое заключение. Финальная legal qualification должна проверяться юристами. Меня здесь интересует другая часть: как превратить норматив регулятора в инженерно и операционно управляемую систему.

Шаг 0. Не начинайте с вопроса «какая у нас модель?»

Одна из первых ошибок, которую я вижу в разговорах вокруг AI регуляции:

Мы используем ChatGPT / Claude / Gemini / Llama. Под какой класс мы попадаем?

Для оценки AI-системы этого недостаточно. AI Act определяет intended purpose как назначение системы вместе с конкретным контекстом и условиями её использования. А high-risk классификация в значительной степени строится именно вокруг того, для чего применяется AI, а не только вокруг используемой модели.

Одна и та же LLM может использоваться как:

• customer-support chatbot;

• coding assistant;

• CV screening tool;

• credit assessment component;

• часть медицинского продукта.

Модель может быть та же, а нормативных последствий последуют совершенно разные. Поэтому в моём assessment первым объектом становится не model inventory, а AI Use Case.

Минимальная карточка выглядит примерно так:

use_case:
  name: candidate-screening
  business_owner: HR
  intended_purpose:
    analyse_and_filter_applications
  users:
    - recruiter
  affected_persons:
    - candidates
  decisions_influenced:
    - candidate_selection
  geography:
    - EU
  autonomy:
    recommendation
  human_review:
    required
  model_provider:
    external

Уже после этого можно начинать классификацию.

Шаг 1. Определите свою роль

Второй вопрос: Кто вы относительно этой системы?

AI Act различает, в частности:

• provider;

• deployer;

• importer;

• distributor;

• product manufacturer.

Скрытый текст

Provider — это тот, кто разрабатывает или заказывает разработку AI-системы и выводит её на рынок или вводит в эксплуатацию под своим именем.

Deployer — организация, использующая AI-систему под своей ответственностью.

Это не формальность. Представим, что вы купили сторонний AI SaaS. В одном случае вы просто используете готовую систему, а в другом, глубоко интегрировали модель, изменили назначение, добавили собственный decision layer и вывели конечный продукт под своим брендом. Ваше нормативное положение уже может быть другим.

В assessment я поэтому отдельно фиксирую:

System
↓
Model Provider
↓
AI System Provider
↓
Deployer
↓
Affected User / Person

Без этой карты обсуждать «наш compliance» слишком рано.

Какие классы риска проверять

Еврокомиссия описывает risk-based модель AI Act через четыре основные категории:

1. unacceptable risk;
2. high risk;
3. transparency risk;
4. minimal or no risk.

При проведении assessment я разбиваю high-risk ещё на две ветки и получается такой routing:

            AI Use Case
                     |
                     v
          Prohibited practice?
              /            
            YES             NO
             |               |
           STOP              v
                     Annex I route?
                       /        
                     YES         NO
                      |           |
              HIGH-RISK I        v
                           Annex III route?
                             /        
                           YES         NO
                            |           |
                     HIGH-RISK III      v
                                   Transparency?
                                     /      
                                   YES       NO
                                    |         |
                              TRANSPARENCY   MINIMAL /
                                             OTHER

Это пока классификация, а не решение compliance.

Класс 1. Prohibited practices

Есть AI use cases, для которых вопрос не:

какие элементы управления добавить?

а:

можно ли вообще этот use case использовать?

Article 5 содержит prohibited AI practices. Например, AI Act запрещает некоторые формы social scoring, определённые manipulative practices, отдельные biometric use cases и другие применения.

С инженерной точки зрения это важное различие. Для high-risk системы логика может быть:

CLASSIFY
   ↓
REQUIRE CONTROLS
   ↓
CHECK EVIDENCE
   ↓
PERMIT

Для prohibited use case:

CLASSIFY
   ↓
DENY

Governance-система не должна превращать запрещённый use case в разрешённый просто потому, что кто-то добавил Human Approval.

Класс 2. High-risk по Annex I

Первая high-risk ветка определена Article 6(1). AI-система относится сюда, когда выполняются оба условия:

1. AI является продуктом либо safety component продукта, регулируемого законодательством из Annex I;
2. такой продукт требует third-party conformity assessment.

Упрощённый classification path:

Is AI part of a regulated product?
            |
           YES
            |
Is AI the product itself
or a safety component?
            |
           YES
            |
Is third-party conformity
assessment required?
            |
           YES
            v
       HIGH-RISK
       Article 6(1)

Это может касаться, например, AI внутри определённых видов machinery, medical devices и других регулируемых продуктов. Для этой ветки high-risk requirements теперь применяются с 2 августа 2028 года.

Класс 3. High-risk по Annex III

Для большинства software-компаний эта ветка интереснее. Article 6(2) относит к high-risk системы, попадающие в use cases Annex III.

Среди областей:

• biometrics;

• critical infrastructure;

• education;

• employment;

• access to essential services;

• creditworthiness;

• life and health insurance;

• law enforcement;

• migration и border control;

• administration of justice;

• democratic processes.

Например, AI-система для анализа и фильтрации заявок кандидатов прямо входит в employment-related high-risk examples Еврокомиссии. Именно поэтому вопрос:

Использует ли компания AI?

практически бесполезен. Мне для assessment гораздо интереснее:

Какое решение система принимает или существенно влияет на него?

Следует знать, что Annex III ещё не означает автоматический HIGH_RISK во всех случаях

Здесь начинается более интересная часть Article 6.

В Article 6(3) предусмотрено исключение: некоторые системы из Annex III могут не считаться high-risk, если не создают significant risk для здоровья, безопасности или fundamental rights и не оказывают существенного влияния на результат принятия решения.

Регламент отдельно перечисляет несколько условий: narrow procedural task, улучшение результата уже выполненной человеческой деятельности, detection of patterns без замены human assessment, либо preparatory task.

Однако, если система выполняет profiling физических лиц, это исключение не применяется и система считается high-risk. Поэтому реальный decision tree выглядит уже не так просто:

Annex III use case?
       |
      YES
       |
       v
Material influence / significant risk?
       |
      YES --------------------> HIGH_RISK
       |
      NO
       |
       v
Article 6(3) condition applies?
       |
      YES
       |
       v
Profiling natural persons?
       |
   YES | NO
       |   
HIGH_RISK  potential
           exemption

И здесь появляется ещё один важный артефакт assessment:

classification evidence.

Если организация считает, что Annex III система не является high-risk, Article 6(4) требует документировать эту оценку. То есть результатом нормальной работы должен быть не Excel с колонкой: Risk = Low, а воспроизводимый ответ:

Claim
↓
Regulatory Basis
↓
System Evidence
↓
Classification
↓
Confidence / Open Questions

Именно такой формат я использую в assessment: отдельно фиксирую доказанное, предположение и Not Proven.

Класс 4. Transparency risk

Вот эта часть особенно актуальна прямо сейчас.

Пока high-risk сроки перенесли, Article 50 transparency obligations начали применяться 2 августа 2026 года. Они касаются, среди прочего:

• direct interaction человека с AI;

• machine-readable marking определённого AI-generated или manipulated content;

• deepfakes;

• AI-generated текстов по вопросам общественного интереса в определённых условиях;

• emotion recognition;

• biometric categorisation.

И здесь controls уже совсем другие. Например:

User interacts with AI
        ↓
Does an exception apply?
        ↓
       NO
        ↓
Inform user that interaction
is with an AI system

Или:

Synthetic content generated
        ↓
Article 50 marking applicable?
        ↓
       YES
        ↓
Machine-readable marking
        ↓
Evidence of implementation

Это хороший пример того, почему нельзя создать один generic: AI_ACT_COMPLIANCE = true
Разные regulatory classes требуют разных технических механизмов.

Класс 5. Minimal / no risk

И эту категорию нельзя игнорировать.

Еврокомиссия прямо указывает, что большинство AI-систем относится к minimal/no-risk категории и приводит в качестве примеров spam filters и AI-enabled games. Ошибка здесь обратная:

Давайте на всякий случай применим high-risk governance ко всему AI.

Через несколько месяцев получаем:

• unnecessary approvals;

• огромные evidence packages;

• ручные gates;

• долгий delivery;

• compliance theatre.

Governance должен быть proportional, но здесь есть одна важная ловушка.

Низкий regulatory risk не означает низкий operational risk.

Например, внутренний coding agent может не попадать в high-risk Annex III. При этом если он имеет право:

• merge PR

• deploy production

• modify infrastructure

• change access

• execute financial operation

его regulatory classification и реальный organisational risk — это две совершенно разные вещи. Поэтому в своих assessments я использую две оси:

REGULATORY RISK
               ↑
               |
               |
               |
               |
               +--------------------→ ACTION AUTHORITY

Можно получить систему:

Regulatory Risk: LOW
Action Authority: HIGH

или наоборот:

Regulatory Risk: HIGH
Action Authority: LOW

И controls для них нужны разные.

Для меня это одна из самых важных границ между AI compliance и AI governance.

GPAI как ещё один слой, а не пятый risk class

Отдельно стоит убрать ещё одну распространённую путаницу.

General-Purpose AI Model и high-risk AI system — НЕ одно и то же.

У providers general-purpose AI models существуют собственные обязательства, которые начали применяться ещё 2 августа 2025 года. Среди них техническая документаци, информация для downstream providers, copyright policy и другие требования. То есть:

GPT / Claude / Gemini / Llama
          ↓
      GPAI model
          ↓
used inside your AI system
          ↓
your intended purpose
          ↓
your system classification

Использование GPAI model само по себе не отвечает на вопрос о risk class конечной AI-системы.

Как выглядит assessment на практике

Для каждого use case я начинаю примерно с такой записи:

use_case:
  id: HR-001
  name: CV Screening

role:
  provider: true
  deployer: true

scope:
  jurisdiction:
    - EU

intended_purpose:
  category: employment
  action: filter_candidates

decision_impact:
  material: true

regulatory_assessment:
  annex_i: false
  annex_iii: true
  article_6_3_exception: false

classification:
  result: HIGH_RISK
  confidence: HIGH

evidence:
  intended_purpose: confirmed
  workflow: confirmed
  human_oversight: partial

open_questions:
  - final decision authority
  - evidence retention

Это иллюстративная структура, а не официальная EU schema. Она показывает принцип. Мне же нужен не просто вердикт, а traceability:

Почему мы решили, что система относится к этому классу?

Затем classification превращается в controls

Если результат assessment: HIGH_RISK, то работа только начинается. Для high-risk systems Еврокомиссия перечисляет, среди прочего, требования вокруг:

• risk management;

• качества данных;

• logging и traceability;

• техническая документация;

• информации для deployer;

• человеческий контроль;

• надежность;

• cybersecurity;

• точность.

Поэтому следующий инструмент в моём toolkit: Control & Evidence Matrix.

Пример:

Обратите внимание на NOT PROVEN. Для меня это принципиально, если команда говорит: «У нас это реализовано», но assessment не нашёл достаточного evidence, я не ставлю PASS. Ставлю: NOT PROVEN. Обычно это гораздо полезнее красивого compliance score.

Результатом assessment является не процент соответствия

Мне не нравится формат: AI Act Compliance: 83%. Что делать с этими 83% руководителю? Гораздо полезнее получить:

System: CV Screening
Classification: HIGH_RISK / Annex III
Current readiness: NOT READY

Critical gaps:
1. Risk-management evidence
2. Human-oversight verification
3. Technical-documentation completeness

Secondary gaps:
4. Evidence retention
5. Monitoring

Regulatory deadline:
02.12.2027

Recommended sequence:
GAP-1 → GAP-2 → GAP-3 → validation

Теперь уже можно принимать решение:

• что делать;

• кто owner;

• сколько это стоит;

• что является blocker;

• что можно отложить;

• какое evidence должно появиться.

Это уже не только compliance, а operating model.

А если AI use cases уже 30?

Тогда оценивать каждый как независимый compliance project будет довольно дорогой способ работы. Для portfolio-level assessment я сначала строю карту.

Например:

И вот здесь перенос EU AI Act становится действительно полезным. Потому, что появилось дополнительное время не внедрять одинаковый compliance everywhere, а сначала определить реальный exposure и правильно распределить инвестиции.

Я могу проводить такой assessment как для одного consequential use case, так и для AI portfolio компании.

На выходе получается не очередной policy document, а рабочая карта:

AI Inventory + Regulatory Classification + Authority Assessment + Control Coverage + Evidence Gaps + Remediation Priorities

Не хардкодьте AI Act в бизнес-логику

Теперь вернёмся к Omnibus. Представим такой код:

if use_case.category == "employment":
    require_human_oversight()

if use_case.category == "credit":
    require_risk_management()

if date.today() >= date(2026, 8, 2):
    enforce_high_risk_controls()

До 27 июля всё выглядит логично. Потом появляется новый regulatory baseline и начинается:

change date
change exception
change scope
change guidance
change evidence
change tests

Если regulation напрямую зашит в application code, каждое подобное изменение начинает распространяться по системе. Я предпочитаю другую модель:

Governance Core
      ↓
Regulatory Profiles
      ↓
Product Policy
      ↓
Runtime Enforcement
      ↓
Evidence

Regulatory Profile должен быть versioned

Например:

profile:
  id: eu-ai-act
  version: 2026-07-27

application_dates:

  transparency:
    effective: 2026-08-02

  high_risk_annex_iii:
    effective: 2027-12-02

  high_risk_annex_i:
    effective: 2028-08-02

Это опять же не официальная EU schema, а пример инженерной модели, но смысл в другом. Через год мы должны иметь возможность ответить:

Почему 15 августа 2026 года система приняла именно такое решение?

Для этого вместе с governance decision полезно сохранять:

use-case identity
classification
policy version
regulatory profile version
decision
timestamp
evidence references

Тогда regulatory baseline становится воспроизводимой частью decision context.

Classification vs authorization

Ещё одна ошибка: HIGH_RISK → DENY
High-risk не означает prohibited.

Корректнее:

Classification
      ↓
Applicable Obligations
      ↓
Required Controls
      ↓
Evidence Check
      ↓
Governance Decision

Например:

HIGH_RISK
    ↓
Human oversight required
Logging required
Risk management required
Documentation required
    ↓
Are controls satisfied?
    ↓
 YES            NO
  |              |
PERMIT     NOT_READY /
           REQUIRE_ACTION

Иначе compliance layer незаметно превращается в authorization engine.

А если у меня одновременно AI Act, DORA, GDPR и internal policies?

Для FinTech или другого регулируемого бизнеса это скорее нормальная ситуация. Один AI workflow может одновременно затрагивать: EU AI Act + DORA + GDPR + Information Security Policy + Vendor Risk Policy + Internal Approval Policy

Создавать один огромный: EU_COMPLIANCE_ENGINE я бы не стал. Через некоторое время будет сложно понять:

• откуда пришёл конкретный control;

• кто его owner;

• какая версия действует;

• какой regulation требует evidence;

• какой внутренний policy ужесточает requirement;

• что произойдёт при конфликте.

Поэтому regulatory alignment я строю через composition:

             Governance Core
       ┌──────────────┼───────────────┐
       ↓              ↓               ↓
 EU AI Act         DORA          Internal Policy
  Profile          Profile            Profile
       └──────────────┼───────────────┘
                      ↓
              Effective Controls
                      ↓
                Policy Decision
                      ↓
                   Evidence

При этом я бы не строил универсальный compliance framework для всех существующих regulations заранее. Только те profiles, которые подтверждены реальным scope. Иначе governance очень быстро начинает производить governance ради governance.

Что делать компании сейчас

Если AI уже используется в production, я бы не начинал с вопроса:

Как нам стать EU AI Act compliant?

Он слишком широкий. Начал бы с inventory.
Для каждого consequential AI use case:

1. Business owner
2. Provider / deployer role
3. Intended purpose
4. Users
5. Affected persons
6. Decision / action influenced
7. Geography
8. Model / provider
9. Data categories
10. Human oversight
11. Action authority
12. Preliminary regulatory class
13. Existing controls
14. Available evidence

После этого переходить к классификации. Затем controls. И после уже формировать evidence.
И только после evidence строить remediation plan. То есть:

Inventory
   ↓
Classification
   ↓
Controls
   ↓
Evidence
   ↓
Gaps
   ↓
Priorities

Не наоборот.

У меня для этого уже есть подготовленный assessment toolkit

Я сейчас использую этот подход не только как исследование regulation.

У меня подготовлен набор инструментов для AI Regulatory & Governance Assessment, который позволяет пройти путь от конкретных use cases до gaps и remediation. В assessment я могу разобрать:

• AI inventory;

• provider/deployer roles;

• EU AI Act preliminary classification;

• Annex I / Annex III routing;

• Article 6(3) applicability;

• transparency obligations;

• AI-agent authority;

• existing governance controls;

• evidence coverage;

• Not Proven areas;

• regulatory exposure;

• remediation priorities.

Для agentic systems отдельно проверяю:

Что агент может сделать?
Кто дал ему это право?
Где Human Decision обязателен?
Как ограничен scope?
Что произойдёт при policy failure?
Какое evidence останется после действия?

Потому что AI-система может иметь низкий regulatory risk и при этом очень высокий operational authority. Для CTO, COO или CISO это иногда более важный риск.

Итог

В итоге AI Omnibus дал довольно хороший инженерный урок. 27 июля вступило в силу изменение regulation. Через несколько дней наступил старый deadline. High-risk roadmap поменялся, но transparency requirements при этом всё равно начали работать 2 августа. То есть regulation нельзя воспринимать как статический requirements document. Мы давно умеем версионировать: API, schemas, dependencies, infrastructure, contracts.

А regulatory assumptions почему-то часто зашиваем в процессы как константу. Я бы относился к ним так же, как к любой другой внешней зависимости: explicit, versioned, traceable, testable, replaceable. Тогда следующий Omnibus означает:

new regulatory profile
↓
impact assessment
↓
affected controls
↓
targeted remediation

а не:

переписываем половину governance architecture

И если у вас AI уже работает в production и сейчас непонятно:

• какие системы действительно подпадают под AI Act;

• где high-risk, а где governance просто перестраховывается;

• какие controls уже есть;

• что реально нужно закрыть к новым срокам;

• где compliance формально описан, но не подтверждён evidence;

• насколько автономные AI-агенты имеют больше authority, чем вы предполагали,

я могу провести такой assessment. Можно начинать не со всей организации. Достаточно одного реального consequential AI use case. Обычно уже на нём становится видно, где заканчивается разговор про AI regulation и начинается настоящая инженерия governance.

Основные источники

European Commission — AI Omnibus enters into force, 27 July 2026.
European Commission — AI Act application timeline and current high-risk deadlines.
European Commission — Draft Guidelines on classification of high-risk AI systems.
EUR-Lex — Regulation (EU) 2024/1689, Article 6 classification rules.
European Commission — Guidelines on Article 50 transparency obligations.