EU AI Act — не регуляторный документ для экспортёров в ЕС, а зрелый операционный стандарт управления ИИ-рисками. Российский закон об ИИ принят в третьем чтении в июле 2026-го и воспроизводит ту же риск-ориентированную логику. Компании, которые выстроят AI inventory, классификацию рисков, human oversight и audit logs сейчас, не будут переделывать процессы под давлением дедлайна — и получат конкурентное преимущество перед теми, кто ждёт. Почему это не про соответствие EU AI Act Сразу снимем ложный вопрос. Если ваша компания работает только на российском рынке, EU AI Act вам юридически не грозит. Это факт. Но вот другой факт: EU AI Act разрабатывался четыре года при участии сотен enterprise-компаний и регуляторов. Он кодифицирует операционные практики управления ИИ-рисками, которые работают независимо от юрисдикции. Инвентаризация систем, классификация по риску сценария использования, назначение владельца, документация ограничений модели, протокол human oversight, audit log — ни одна из этих практик не требует, чтобы вы продавали продукт в Германию. Параллельно: российский закон об ИИ принят в третьем чтении 08.07.2026. Он воспроизводит риск-ориентированный подход EU AI Act, но с одним принципиальным отличием — презумпция виновности оператора в РФ шире, чем разделение ответственности provider/deployer в европейской модели. Это означает, что российский B2B, внедряющий ИИ без governance-инфраструктуры, несёт больший регуляторный риск, чем его европейский аналог. Вопрос ЛПР здесь не «как соответствовать EU AI Act», а «как выстроить внутренние процессы управления ИИ так, чтобы не переделывать всё заново, когда российский закон заработает в полную силу». Выбор архитектуры — где физически запускать ИИ с учётом 152-ФЗ и санкций — разобран в статье про корпоративный AI: облако, API и on-prem. Здесь мы начинаем с того момента, когда система уже запущена: как ею управлять. Четыре уровня риска → российские B2B-сценарии EU AI Act делит ИИ-системы на четыре уровня риска. Для российского B2B это не абстрактная классификация — это прямой сигнал о том, сколько governance-инфраструктуры нужно вокруг конкретного инструмента. Уровень риска (EU AI Act) | Типовые B2B-сценарии в РФ | Что это означает для governance Неприемлемый (запрещён) | Системы социального рейтинга, манипулятивные AI-агенты | Не внедрять. Если уже есть — немедленный аудит и демонтаж Высокий | HR-AI (отбор резюме, решения об увольнении), кредитный скоринг, медицинская диагностика | Обязательны: документация модели, human oversight с фиксацией, audit log, тестирование на предвзятость, назначенный AI owner Ограниченный | Чат-боты для клиентов и сотрудников, LLM в документообороте, BI-аналитика с генерацией выводов | Обязательна: маркировка «это ИИ», документация ограничений, точка эскалации к человеку Минимальный | Спам-фильтры, рекомендательные системы в каталоге, автодополнение в поиске | Базовая инвентаризация и назначение владельца; специального governance не требуется Практический вывод: если в вашей компании LLM участвует в решениях о найме или кредитовании — это высокий риск по любой логике, российской или европейской. Если LLM формирует проекты договоров — ограниченный риск с обязательной точкой контроля человека. AI Inventory: как провести инвентаризацию, включая shadow AI Главная слепая зона большинства российских B2B-компаний — отсутствие полного реестра ИИ-инструментов. Часть из них официально закуплена, часть используется сотрудниками через личные аккаунты или VPN. Чеклист AI Inventory для российского B2B: • Шаг 1. Опрос по подразделениям — анонимный или через HR: какие AI-инструменты используются для рабочих задач? Включая ChatGPT/Claude через VPN, личные аккаунты GigaChat, YandexGPT, Copilot, open-source модели на локальных машинах. • Шаг 2. Анализ корпоративных расходов — подписки на AI-сервисы в корпоративных картах и счетах. Часто обнаруживает инструменты, о которых IT не знает. • Шаг 3. Сетевой мониторинг — запросы к известным AI API-эндпоинтам (OpenAI, Anthropic, GigaChat API, YandexGPT API). Не для наказания, а для картирования. • Шаг 4. Классификация каждого инструмента — по уровню риска (таблица выше), по типу данных, которые в него передаются, по бизнес-процессу, который он затрагивает. • Шаг 5. Назначение AI owner — конкретный человек, ответственный за каждую систему: следит за обновлениями модели, получает эскалации, ведёт документацию. • Шаг 6. Решение по shadow AI — не запрет, а перевод в управляемый контур: корпоративные аккаунты, одобренные инструменты, инструктаж по тому, какие данные нельзя передавать во внешние системы. Целевая метрика: 100% известных AI-систем прошли инвентаризацию и классификацию, для каждой назначен владелец. Что перенять из EU AI Act прямо сейчас Пять практик с оценкой трудозатрат для команды без выделенного ML-отдела: 1. AI Inventory и реестр систем — *трудозатраты: 2–4 недели первично, далее поддержка*. Структурированный список всех ИИ-инструментов с полями: название, поставщик, бизнес-процесс, уровень риска, AI owner, дата последнего аудита. Хранится в корпоративной wiki или таблице — не важно где, важно что обновляется. 2. Документация ограничений модели (model card / instructions for use) — *трудозатраты: 1–2 дня на систему*. Для каждого ИИ-инструмента в бизнес-процессе — короткий документ: что модель умеет, что не умеет, на каких данных обучена, какие ошибки типичны, когда её выводу нельзя доверять без проверки. Это не техническая документация для разработчиков — это инструкция для пользователя процесса. 3. Протокол human oversight — *трудозатраты: 1 день на процесс*. Подробнее — в следующем разделе. Суть: задокументированная точка контроля человека с критерием принятия/отклонения решения ИИ. 4. Audit log для ИИ-решений — *трудозатраты: от 1 дня (если система поддерживает логирование) до 2 недель (если нужна доработка)*. Фиксация: что запросили у модели, что она ответила, кто принял решение на основе ответа, когда. Минимальный срок хранения — 6 месяцев (по аналогии с EU AI Act Art. 12). Это единственная практика, которая одновременно закрывает EU AI Act, российский законопроект и внутренний операционный контроль. 5. AI literacy для сотрудников — *трудозатраты: 2–4 часа тренинга, повторение раз в год*. Не курс по машинному обучению. Три вещи: понимание того, что модель галлюцинирует и почему; знание, какие данные нельзя передавать во внешние системы; умение распознать ситуацию, когда вывод модели требует проверки человеком. Целевая метрика: 80%+ сотрудников, работающих с AI-инструментами, прошли тренинг. 6. Incident response для AI-инцидентов — *трудозатраты: 1 день на разработку процедуры*. Что считается AI-инцидентом (ошибочное решение с последствиями, утечка данных через внешний AI-сервис, дискриминационный вывод модели), кто получает эскалацию, в какой срок. Целевая метрика: время от обнаружения инцидента до эскалации — не более 4 часов в рабочее время. 7. Политика допустимого использования AI — *трудозатраты: 1–2 дня*. Один документ: какие инструменты одобрены, какие данные нельзя передавать во внешние системы, что делать при обнаружении проблемы. Подписывается сотрудниками как часть онбординга. Human oversight на практике: пример с LLM в документообороте Абстрактный «контроль человека» — это не практика, это декларация. Вот как это выглядит в конкретном процессе. Сценарий: LLM используется для формирования проектов договоров на основе шаблона и параметров сделки. Без human oversight: менеджер получает проект от модели → отправляет контрагенту → юрист видит договор уже после подписания. С human oversight: 1. LLM формирует проект договора — это автоматический шаг. 2. Точка контроля: юрист проверяет по чеклисту из 5 пунктов: раздел ответственности, санкции, форс-мажор, подсудность, реквизиты. Чеклист — не произвольный, а зафиксированный в регламенте. 3. Критерий отклонения: если хотя бы один пункт чеклиста вызывает вопрос — договор не уходит контрагенту, юрист дорабатывает вручную или запрашивает новую генерацию с уточнёнными параметрами. 4. Фиксация: юрист подписывает электронный протокол проверки (дата, версия документа, результат проверки). Это и есть audit log. Ключевое: точка контроля определена заранее, критерий отклонения задокументирован, факт проверки фиксируется. Без этих трёх элементов human oversight — это просто «кто-то смотрел». EU AI Act vs. российский законопроект: где совпадает, где расходится Практика EU AI Act | Аналог в российском законопроекте (июль 2026) | Статус Риск-ориентированная классификация систем | Да, аналогичная логика уровней риска | Совпадает Документация системы (technical documentation) | Требование документирования оператором | Совпадает Audit log / логирование решений | Требование хранения данных о работе системы | Совпадает Human oversight для высокорисковых систем | Требование контроля человека для критических решений | Совпадает Разделение ответственности provider / deployer | Презумпция виновности оператора — ответственность шире | Расходится (РФ строже) Уведомление пользователя о взаимодействии с AI | Требование информирования пользователя | Совпадает Реестр высокорисковых систем (EU Database) | Реестр операторов ИИ в РФ — обсуждается | Частично AI literacy / обучение персонала | Не регулируется напрямую | Не регулируется Запрет манипулятивных систем | Запрет систем, нарушающих права граждан | Совпадает по духу Вывод из таблицы: большинство операционных практик EU AI Act прямо воспроизводятся в российском законопроекте. Компания, выстроившая governance по EU AI Act-логике, будет готова к российскому регулированию с минимальными доработками. Единственное принципиальное расхождение — более широкая ответственность оператора в РФ — означает, что российскому B2B нужно быть даже аккуратнее с документацией, чем требует EU AI Act. Аналогия, которая работает: GDPR → 152-ФЗ Те, кто начал готовиться к GDPR в 2016-м, прошли 2018 год без авральных переработок. Те, кто ждал — переделывали архитектуру данных под давлением. 152-ФЗ прошёл тот же путь в России: компании, выстроившие процессы работы с персональными данными заблаговременно, не испытали шока от ужесточений 2022–2023 годов. Российский закон об ИИ принят в третьем чтении. Подзаконные акты и правоприменительная практика формируются сейчас. Governance-инфраструктура — реестр систем, документация, протоколы — строится месяцами, не неделями. Компании, которые начнут сейчас, получают три преимущества: не переделывают под дедлайн, снижают операционные риски уже в процессе внедрения и формируют доверие корпоративных клиентов, для которых управляемость AI-систем становится критерием выбора поставщика. Метрики зрелости AI governance Если вы хотите измерить, где находитесь сейчас, — вот операционные метрики: • Покрытие инвентаризацией: доля AI-систем в компании, прошедших классификацию по риску (цель: 100% известных систем). • Назначенность владельца: для каждой AI-системы в продакшне есть AI owner с зафиксированной ответственностью. • Документация ограничений: для каждого AI-инструмента в бизнес-процессе есть model card или аналог. • Human oversight: для каждого высокорискового процесса определена и задокументирована точка контроля человека. • Audit log: решения с участием ИИ логируются, срок хранения — не менее 6 месяцев. • Incident response SLA: время от обнаружения AI-инцидента до эскалации — не более 4 часов в рабочее время. • AI literacy: доля сотрудников, работающих с AI-инструментами и прошедших базовый тренинг, — не менее 80%. Эти метрики не требуют ML-отдела. Они требуют решения руководства и назначенного ответственного. *Материалы по смежным темам в блоге brezatech: выбор архитектуры ИИ с учётом 152-ФЗ и санкций — в статье «Корпоративный AI: облако, API и on-prem — риски для РФ».* Ключевые факты • Российский закон об ИИ принят в третьем чтении 08.07.2026 — компании, начавшие выстраивать governance сейчас, не будут переделывать процессы под давлением дедлайна. • EU AI Act вводит четырёхуровневую классификацию рисков — та же логика заложена в российском законопроекте: риск-ориентированный подход совпадает, но ответственность оператора в РФ шире. • По данным опросов, более 60% сотрудников российских компаний используют внешние LLM-сервисы через личные аккаунты или VPN — shadow AI остаётся главным слепым пятном в инвентаризации. • Audit log для ИИ-решений — единственная практика, которая одновременно закрывает требования EU AI Act Art. 12, российского законопроекта и внутренний операционный контроль. • Compliance — это инфраструктурная задача, не документальная: без назначенного AI owner и протокола human oversight документация превращается в формальность.