Что теперь требует статья 4 AI Act?

Грамотность в сфере ИИ по Регламенту ЕС об искусственном интеллекте требует наладить работу, а не выдать каждому сотруднику типовой сертификат. Компания должна принимать меры, которые помогают развивать грамотность сотрудников и других людей, работающих с системами ИИ от ее имени. Сначала нужно определить этих людей, системы, с которыми они работают, решения, на которые влияют эти системы, и ошибки, которые реально может допустить каждая роль.

Такая формулировка имеет значение, потому что статья 4 изменилась в июле 2026 года. Регламент (ЕС) 2026/1744 отменил прежнюю обязанность обеспечить «достаточный уровень» грамотности. Теперь в тексте прямо сказано, что поставщики и операторы систем ИИ не обязаны гарантировать конкретный уровень каждого человека. Обязанность компании действовать при этом сохранилась. Презентация, которую разослали всем, формально может считаться мероприятием, но она слабо подтверждает разумность принятых мер, если рекрутеры, разработчики, сотрудники поддержки и руководители используют разные системы и могут причинить вред разным людям.

Ниже описан практический подход к соблюдению требований, но это не юридическая консультация. Трудовое и отраслевое право, обязанности перед производственными советами, законодательство о защите данных и практика национальных органов могут добавлять требования, которых нет в самой статье 4.

Статья 4 требует мер, а не сертификата

После поправок статья 4 требует от поставщиков и операторов систем ИИ принимать меры для развития грамотности в сфере ИИ. При выборе мер нужно учитывать технические знания, опыт, образование и подготовку людей, условия применения системы и тех, кого она затрагивает. В статье прямо сказано, что компания не обязана гарантировать определенный уровень каждому человеку. Требование стало реалистичнее, но продуманные действия по-прежнему нужны.

Разницу между результатом обучения и мерами компании часто не замечают. Нельзя гарантировать, что каждый человек запомнит каждый урок. Зато можно определить, кому нужны инструкции, дать подходящий для работы материал, отработать рискованные решения, проверить усвоение и устранить пробелы. Такие управленческие действия можно увидеть и подтвердить.

В документе Европейской комиссии «Вопросы и ответы о грамотности в сфере ИИ» сказано, что обязательного формата нет и один формат не подойдет всем компаниям. Там же отмечено, что просьбы просто прочитать инструкцию к системе может оказаться недостаточно. С первым тезисом я согласен, а второй сформулировал бы жестче: инструкция поставщика объясняет продукт, но вашим сотрудникам нужно понимать разрешенные способы применения, правила работы с вашими данными, порядок эскалации и последствия ошибочного результата именно для вашего бизнеса.

Официального сертификата по статье 4 нет, и Комиссия подтверждает, что он не требуется. Сертификат учебной платформы может дополнить журнал посещения, но не докажет соответствие материала роли человека или работу компании с известным риском. Относитесь к сертификату как к квитанции, а не как ко всей программе соблюдения требований.

Обязанность действует с 2 февраля 2025 года. По разъяснениям Комиссии национальные органы надзора за рынком контролируют ее исполнение в рамках механизма, который заработал в августе 2026 года. Если компания опоздала, ей следует сейчас создать обоснованную программу, честно зафиксировать дату и не оформлять посещение или политики задним числом. Чистая история исправления лучше выдуманного прошлого.

В сферу требований могут попасть поставщики, операторы, подрядчики и руководители

Статья 4 распространяется на поставщиков и операторов систем ИИ, в том числе на многие компании, которые лишь используют в работе сторонние инструменты. Оператором обычно считается организация или человек, которые используют систему ИИ под своей ответственностью, кроме личного применения вне профессиональной деятельности. Компания не выходит из сферы требований только потому, что не обучала модель или сотрудник открыл общедоступный чат-бот в браузере.

Круг людей не ограничен штатными сотрудниками. В статье 4 говорится о персонале и других лицах, которые от имени организации работают с системами или используют их. Меры с учетом конкретных задач могут потребоваться подрядчикам, которые готовят рекламные тексты, внешним операторам поддержки с подсказками для ответов, консультантам, анализирующим записи, и временным сотрудникам, размечающим данные. Закрепите обязанность в рабочих отношениях, а не рассчитывайте, что ею занимается поставщик услуг.

Сначала компания должна определить свою роль для каждой системы: поставщик, оператор или сразу оба. Стартап, который создает функцию с ИИ, выступает поставщиком такого продукта. Тот же стартап может быть оператором купленного помощника для рекрутинга и внутреннего помощника для программирования. Роли определяют содержание программы. Инженерам поставщика нужно понимать тестирование, ограничения, документацию и последующее применение. Сотрудникам оператора нужны правила ввода данных, проверки результатов и эскалации.

Высшее руководство тоже нужно включить в анализ. Менеджер, который одобряет покупку системы ИИ или меняет рабочий процесс, способен создать больший риск, чем сотрудник, пишущий запрос. Руководители должны уметь спросить, что делает система, на чьи интересы она влияет, какие данные в нее попадают, где вмешивается человек и как мониторинг обнаружит сбой. Обучение руководства, которое ограничивается советами по продуктивности, обходит решения, ради улучшения которых приняли статью 4.

Регламент об ИИ может распространяться и на организации за пределами ЕС при выполнении территориальных условий закона, например при выводе системы ИИ на рынок Союза, ее использовании в Союзе или использовании результата в Союзе по правилам Регламента. Нельзя определять территориальную сферу только по адресу головного офиса. Сложные трансграничные случаи должен разобрать юрист, но владелец программы уже в это время может составить карту пользователей и затрагиваемых групп в ЕС.

Начните с реестра применения ИИ и карты ролей

Обоснованная программа начинается с реального применения, а не с каталога модных рисков ИИ. Перечислите системы ИИ, которые организация поставляет или использует, включая встроенные функции, которые сотрудники могут не считать искусственным интеллектом. Поиск, ранжирование, сигналы о мошенничестве, расшифровка речи, рекомендации, создание контента, оценка кандидатов, дополнение программного кода и подсказки поддержке могут скрываться внутри обычного ПО.

Для неучтенного применения нужен отдельный способ обнаружения. Спросите команды, чем они пользуются, проверьте реестры одобренного ПО, расходы и приложения единого входа, если закон это допускает, и дайте людям безопасный способ рассказать об экспериментах. Период амнистии часто дает больше информации, чем угрозы. Цель состоит в том, чтобы перевести неизвестное применение в управляемое решение, а не наказать первого сотрудника, который признался, что общедоступный инструмент сэкономил ему час.

Для каждого способа применения запишите, кто работает с системой, что в нее вводят, на что влияет результат, кого он может затронуть и как выглядит правдоподобный сбой. Затем группируйте людей по решениям, а не по названиям должностей. Рекрутеру и менеджеру по продажам может одинаково требоваться урок об избыточном доверии к автоматизации, если оба получают рейтинги людей. Двум разработчикам могут понадобиться разные материалы, если один дополняет код внутренних утилит, а другой создает для клиентов функцию на базе модели.

Проведите простую проверку воздействия с четырьмя вопросами:

• Может ли результат повлиять на трудоустройство, доступ к услуге, безопасность, кредит, образование или другой значимый интерес?
• Могут ли пользователи вводить персональные, конфиденциальные, защищенные авторским правом, регулируемые или чувствительные для безопасности сведения?
• Может ли система действовать, публиковать, отправлять, одобрять, отклонять или менять записи без содержательной проверки человеком?
• Может ли разумный пользователь чрезмерно довериться результату из-за уверенного тона или потому, что он появился внутри привычного рабочего процесса?

Ответ «да» еще не относит систему к высокому риску по Регламенту об ИИ. Команды часто смешивают две разные классификации. Операционный риск означает, что применение может навредить бизнесу или человеку. «Высокий риск» обозначает юридическую категорию с определенными в Регламенте условиями. Путаница ведет и к недооценке опасности, и к лишней бюрократии. Обучайте работе с операционными рисками, даже если юрист заключил, что правовой режим высокого риска не применяется.

В конце укажите на карте владельца и причины для пересмотра. Новые системы, существенные изменения функций, новые затрагиваемые группы, инциденты и изменение правовой классификации должны заново запускать решение о грамотности. Ежегодный календарь реагирует слишком медленно, когда поставщик добавляет автономное действие или команда переносит инструмент из подготовки черновиков в принятие решений.

Полезное обучение меняет поведение человека на работе

Обучение приносит результат, когда дает человеку знания и привычки для конкретного применения ИИ. Это может быть очный семинар, короткий записанный модуль, письменная инструкция, работа под наблюдением, консультационные часы, разбор ситуаций или обязательное согласование. Статья 4 не загоняет каждую компанию в учебный класс, а в реестре Комиссии приведены разные подходы. Там же есть предупреждение: копирование примера не создает презумпции соблюдения требований.

Всем участникам нужна общая база: что организация считает системой ИИ, какие системы она разрешает, как могут ошибаться результаты, какие данные допустимо вводить, когда нужна проверка человеком и как сообщить о проблеме. После общего знакомства переходите к отработке по ролям. Человеку, который создает внутреннее резюме встречи, нужна иная глубина, чем сотруднику, использующему рейтинг для отбора кандидатов на работу.

Хорошая проверка заставляет сотрудника принять рабочее решение. Дайте специалисту поддержки правдоподобную, но вымышленную карточку клиента и подготовленный ИИ ответ с несуществующим условием возврата. Попросите найти проблему, свериться с политикой, исправить ответ и зарегистрировать случай. Тест с вариантами ответа проверит термины, но вряд ли докажет, что человек остановится, когда гладкий текст выглядит правдоподобно.

На обучении нужно конкретно объяснить запреты. Фраза «используйте ИИ ответственно» почти ничего не сообщает сотруднику. Правила «не вставляйте данные клиентов в неодобренные инструменты» и «не отправляйте созданное ИИ юридическое утверждение, пока назначенный проверяющий не сверит указанный источник» помогают действовать. Для каждого запрета дайте разрешенный путь, иначе при приближении срока сотрудники найдут обход.

Опытные технические специалисты уже могут понимать механику моделей, но это не закрывает их потребности в грамотности. Комиссия допускает, что опыта может быть достаточно с учетом инструмента и квалификации, но напоминает о возможных пробелах в праве и этике даже у технических сотрудников. Я видел, как отличные инженеры пропускали правила хранения данных и ограничения продукта, потому что все считали техническую подготовку достаточной для управления. Проверьте недостающий слой знаний и не заставляйте их повторять вводный курс без причины.

Храните доказательства решений, проведения и исправлений

Статья 4 не предписывает специальный сертификат, поэтому лучшие доказательства показывают, как организация принимала и выполняла решения. Сохраните достаточно материалов, чтобы новый владелец программы или представитель органа мог восстановить, кого охватили, почему содержание подходило, когда его передали и что изменилось после отзывов или инцидента.

Компактный пакет доказательств должен содержать утвержденный реестр применения ИИ, оценку ролей и рисков, учебные материалы с номером версии, записи об участии, результаты упражнений или проверки, исключения и дальнейшие действия. Четко отмечайте источник каждого требования. Правило приватности, правило информационной безопасности, ограничение поставщика и мера по Регламенту об ИИ могут попасть в один урок, но их правовые основания нельзя считать взаимозаменяемыми.

Для многих способов применения с низким воздействием достаточно такой короткой записи:

program_version: 2026-08-01
owner: Head of Operations
scope_basis:
  systems: [internal meeting summarizer, approved writing assistant]
  roles: [operations, marketing, customer support]
  affected_groups: [employees, prospects, customers]
measures:
  common_briefing: 60 minutes
  role_exercises: 90 minutes
  guidance_acknowledgement: required
evidence:
  attendance_file: literacy-attendance-2026-q3.csv
  exercise_record: literacy-results-2026-q3.csv
review_triggers: [new system, material feature change, incident, role change]
next_review: 2027-02-01

YAML служит указателем, а не самостоятельным доказательством. В упомянутых файлах нужны идентификаторы участников с учетом местного трудового права и правил приватности, даты, версия программы, назначенный ролевой поток, статус завершения и сведения о дополнительной работе. Храните точные версии слайдов, ситуаций, политики и руководства с ответами, которые применялись в этой версии. Если политика позже изменилась, оставьте старую версию, чтобы запись по-прежнему объясняла, что получил участник.

Не собирайте лишние персональные данные. Именной журнал участия может быть оправдан, а запись каждой дискуссии, скорее всего, нет. Определите правила доступа и хранения вместе с владельцами из HR, приватности и юридического отдела. Статья 4 не отменяет обязанности по GDPR, а раздутый архив доказательств сам создает риск.

Фиксируйте отсутствие и исправление, а не ставьте всем отметку о завершении. Если подрядчик пропустил занятие, ограничьте задачу с ИИ, пока он не пройдет равноценную меру. Если упражнение выявило распространенное заблуждение, измените рабочий процесс или инструкцию и зарегистрируйте это действие. Доказательство того, что компания извлекла урок из пробела, часто говорит о программе больше страницы идеальных оценок.

Не полагайтесь главным образом на скриншоты. Они теряют версии, контекст и возможность поиска. Ведите структурированные записи и выгружайте стабильные копии, если учебная система может удалить аккаунты или перезаписать содержание. Раз в год проверяйте, что ссылки на доказательства работают и владелец программы может собрать полный пример, не обращаясь в пять отделов.

Однодневная программа может заложить основу

Один насыщенный день может заложить убедительную основу для обычной компании, которая использует генеративные инструменты, если до занятия компания составила реестр систем, а после устраняет пробелы. За день нельзя завершить всю работу для каждого поставщика или каждого применения, классифицированного как высокорисковое. Но смешанная группа получит общий язык, отработает основные решения и создаст доказательства для следующей итерации.

1. С 09:00 до 09:30 участники определяют охват, перечисляют одобренные системы, свою роль и один текущий способ применения.
2. С 09:30 до 10:20 команды разбирают галлюцинации, чрезмерное доверие автоматизации, разное качество результатов, приватность, конфиденциальность и безопасность на примерах из компании.
3. С 10:30 до 11:20 каждая ролевая группа отмечает, какие данные можно вводить в систему и какие результаты нужно проверять.
4. С 11:20 до 12:00 участники прослеживают, кто может получить пользу, лишиться возможности, получить ложное утверждение или столкнуться с трудностями при оспаривании результата.

После обеда группа переходит от анализа к репетиции и документируемой проверке.

1. С 13:00 до 14:15 группы находят и исправляют сбои в реалистичных вымышленных ситуациях.
2. С 14:15 до 15:00 каждая группа отрабатывает остановку применения, сохранение фактов, уведомление владельца и выбор безопасного запасного процесса.
3. С 15:15 до 16:00 разработчики и руководители, принимающие решения, разбирают ограничения, человеческий контроль, заявления поставщика и причины для пересмотра.
4. С 16:00 до 17:00 участники проходят практическую проверку, а владельцы назначают дополнительную работу и фиксируют открытые вопросы.

До занятия отправьте короткий исходный опрос. Спросите, какими системами пользуются люди, на какие решения влияют результаты, какие данные они вводят и где проверяют ответы. Не просите оценить «зрелость ИИ» по расплывчатой шкале. Конкретные вопросы выявляют потребности программы и создают полезную исходную запись.

Используйте примеры, похожие на работу компании, но без раскрытия настоящих конфиденциальных или персональных данных. Перепишите реальную схему сбоя, заменив имена, цифры и записи вымышленными. Сохраните давление, из-за которого ошибка казалась заманчивой: клиент ждет, релиз заблокирован или руководитель требует список кандидатов. Очищенные примеры теряют смысл, если вместе с чувствительными сведениями преподаватель удаляет контекст.

Завершите день прикладной проверкой. Участники могут выбрать одобренный инструмент, отказаться от запрещенного ввода, найти неподтвержденное утверждение, назвать нужного проверяющего и оформить учебный инцидент. Оценивайте по письменному руководству с ответами. Тот, кто пропустил пункт, связанный с безопасностью, получает адресную доработку вместо повторения всего дня.

Владелец программы должен выпустить короткую записку о завершении в течение пяти рабочих дней. В ней следует указать посещение, ролевые потоки, метод оценки, пробелы, назначенные действия, владельцев и сроки. Такая записка превращает событие в управляемую меру. Без нее семинар может остаться приятным днем, который ничего не изменил.

Упражнения должны воспроизводить сбой под давлением

Лучшее упражнение по грамотности воспроизводит момент, когда разумный человек может довериться системе или применить ее неправильно. Участник должен проверить доказательства, применить правило компании и выбрать запасной процесс. Абстрактные предупреждения о галлюцинациях быстро забываются, потому что все и так согласны с тем, что ИИ ошибается.

Используйте четыре схемы упражнений для разных ролей:

• Уверенный ответ выдумывает политику, источник, факт о продукте или ссылку, а участник должен сверить его с авторитетной записью.
• Пользователь пытается вставить персональные или конфиденциальные данные в неодобренный инструмент, а участник должен выбрать разрешенный путь или удалить чувствительные сведения.
• Рейтинг или рекомендация ставит человека в невыгодное положение, а участник должен определить затронутый интерес, проверить значимые исходные данные и передать решение на содержательную проверку.
• Функция ИИ меняется после обновления поставщика, и владелец должен решить, действуют ли прежние инструкции, тестирование и согласование.

Сделайте руководство с ответами однозначным. Преподаватель должен уметь назвать обязательное действие, допустимое действие и действие, которое создает риск. Открытое обсуждение все равно нужно, особенно когда в политике компании есть пробел, но неоднозначность должна привести к назначенному решению по политике, а не к десяти неофициальным правилам.

Не преподавайте приемы составления запросов как главную защиту. Хороший запрос может улучшить результат, но не превращает модель в достоверный источник, не дает разрешения раскрывать данные и не делает номинальную проверку человеком содержательным контролем. Приемы работы с запросами относятся к обучению продуктивности после того, как участник понял границы и правила проверки.

Проведите учебный инцидент, даже если компания еще не регистрировала инциденты с ИИ. Участник должен знать, куда сообщить, какие факты сохранить, кто может приостановить применение и какой ручной процесс позволит продолжить работу. Если во время упражнения канал сообщения оказался слишком медленным или непонятным, исправьте процесс. Обучение выполнило задачу, если обнаружило операционный дефект до настоящего события.

Разным ролям нужна разная глубина

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

• Все пользователи должны распознавать разрешенное применение, защищать данные, проверять результаты и сообщать о проблемах; сохраните журнал участия, результат разбора ситуации и подтверждение знакомства с инструкцией.
• Менеджеры и закупщики должны описывать цель, затрагиваемых людей, проверку человеком, ограничения поставщика, владельца и причины для пересмотра; сохраните заполненный пример согласования и принятые решения.
• Инженеры и сотрудники продукта должны проверять ограничения, документировать назначение, контролировать изменения, сообщать об ограничениях и поддерживать мониторинг; сохраните техническую ситуацию, результат теста и запись о допуске к релизу.
• Сотрудники HR, юридической службы, безопасности и риск-менеджмента должны применять свои отраслевые правила к использованию ИИ и разбирать эскалации; сохраните разбор случая и назначенные изменения политики.
• Подрядчики и поставщики услуг должны следовать одобренному пути для порученной задачи и использовать согласованный канал инцидентов; сохраните инструкцию, связанную с договором, и запись о завершении.

Людям, которые работают с системами, классифицированными как высокорисковые, может потребоваться дополнительное обучение по человеческому контролю и соответствующим обязанностям оператора, включая статью 26, если она применима. Не считайте, что общая сессия по статье 4 выполняет эти отдельные обязанности. Сопоставьте каждую обязанность со своими доказательствами, а затем повторно используйте материал там, где он действительно закрывает оба требования.

Руководителям нужен короткий, но требовательный поток. Попросите их одобрить или отклонить предложенное применение при неполных сведениях от поставщика, обещанном росте продуктивности и наличии реальной затрагиваемой группы. Они должны определить, что осталось неизвестным и кто отвечает за решение. Руководители с наибольшими полномочиями не должны избегать практики на занятии, состоящем только из определений.

Освобождение от части обучения должно опираться на доказательства. Инженер по машинному обучению может сдать тест по базовой механике вместо модуля, но все равно должен пройти правила компании и упражнение о затрагиваемых людях. Запишите, почему прежние знания были приняты и какие части остались обязательными. Сам по себе высокий пост ничего не доказывает.

Неудачное внедрение обычно начинается с ложного реестра

Знакомая неудача начинается, когда компания покупает общий курс для всех сотрудников и получает почти идеальный процент завершения. Отдел закупок считает задачу закрытой. Через шесть недель поддержка незаметно включает функцию подготовки ответов с ИИ в прежней системе заявок, рекрутеры используют отдельного помощника для резюме записей интервью, а инженеры вставляют трассировки ошибок в личные аккаунты. Ни один из этих способов применения не попал в примеры курса или реестр систем.

Затем поддержка отправляет созданный системой ответ с выдуманным условием договора. Менеджер называет это проблемой галлюцинаций и назначает еще один общий модуль. Такой ответ пропускает операционный сбой: никто не отвечал за изменения функций, список разрешенного применения не включал встроенный ИИ, агент не был обязан сверяться с источником, а канал инцидентов не фиксировал участие ИИ. Дополнительное обучение определениям моделей не исправит эти средства контроля.

Грамотная проверка обновляет реестр, назначает владельца применения, добавляет сверку с источником перед отправкой утверждений о договоре, фиксирует схему инцидента и дает агентам поддержки десятиминутное корректирующее упражнение. Она также выясняет у других команд, где ИИ появился внутри уже купленного ПО. После этого пакет доказательств показывает исходный пробел и исправление, а не делает вид, что первый курс предотвратил любую ошибку.

Поэтому ежегодный процент завершения плохо отражает состояние работы. Отслеживайте охват известных ролей и систем, просроченную доработку, обнаруженные вопросы к политике, проверенные изменения и инциденты, после которых обновили средство контроля или урок. Цифры должны помогать владельцам находить пробелы, а не украшать слайд для совета директоров.

Обновляйте обучение при изменении работы. Новички должны пройти базовую часть до самостоятельного использования. Текущим пользователям нужно адресное обновление, когда система получает существенную функцию, появляется новая затрагиваемая группа, инцидент выявляет непонимание или меняются закон и рекомендации. Сам Регламент (ЕС) 2026/1744 дает хороший пример: материалы, написанные до конца июля 2026 года, могут по-прежнему цитировать старую формулировку «достаточный уровень», и теперь их нужно исправить.

При проверке будут смотреть, имели ли меры смысл

Статью 4 применяют национальные органы надзора за рынком. По разъяснениям Комиссии штрафы и другие меры зависят от национального права и обстоятельств дела. Регламент требует соразмерного правоприменения с учетом характера, тяжести, умышленности или небрежности нарушения. Комиссия также отмечает, что проверка вероятнее, если инцидент указывает на отсутствие подходящего обучения или инструкций.

Не превращайте это в выдуманную таблицу штрафов ЕС по статье 4. Регламент не устанавливает для обязанности по грамотности отдельную простую сумму. Национальные правила о санкциях, отраслевые обязанности, договорные требования, трудовые споры, риски по защите данных и доказательства после инцидента могут пересекаться. Попросите юриста разобрать страны и системы, значимые для вашей компании, вместо повторения максимального штрафа из другой нормы.

Живой реестр практик грамотности Комиссии полезен как источник форматов и идей, но не дает безопасной гавани. В его собственном уведомлении сказано, что повторение примера не создает автоматической презумпции соблюдения. Заимствуйте метод только после того, как свяжете его со своими системами, ролями и затрагиваемыми людьми.

Проверяющий должен увидеть прямую цепочку: организация нашла способ применения, поняла, кто с ним работает и кого он может затронуть, выбрала подходящие к условиям меры, провела их, проверила применение знаний и исправила пробелы. В измененной статье 4 нет требования совершенства. Но равнодушие по-прежнему трудно защитить.

Для основателя разумным первым действием станет девяностоминутная рабочая встреча с владельцами из операций, продукта, HR, безопасности, приватности и юридической службы. Завершите ее списком систем, ролевых групп, затрагиваемых людей и владельцев. Если реестр не выдерживает такой встречи, покупать курс рано. Team & AI Audit от oleg.is поможет изучить более широкую модель работы команды и ИИ, когда подготовка по грамотности обнаружила проблемы с ответственностью или процессами, но юридические выводы компании все равно должен проверить ее консультант.