Сроки Акта ЕС об ИИ для МСП после переноса в 2026 году

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

Причину путаницы понять легко. В исходном регламенте общей датой начала применения было 2 августа 2026 года. Затем 27 июля 2026 года, меньше чем за неделю до этой даты, вступил в силу AI Omnibus и отложил основные правила для систем высокого риска. Это позднее изменение не перенесло требования статьи 50 о прозрачности, не отменило правила, действующие с 2025 года, и не освободило компанию от обязанностей лишь потому, что в ней работают 40 человек, а не 4 000.

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

Что именно изменилось в августе 2026 года

Суть ближайших изменений проста: правила прозрачности начали действовать 2 августа 2026 года, а большинство требований к системам высокого риска теперь начнут применяться 2 декабря 2027 года или 2 августа 2028 года. Дополнительное время относится к пакету правил для высокого риска, а не ко всем частям Акта.

В июльском сообщении Европейской комиссии об AI Omnibus указаны новые даты. Правила для систем из Приложения III, куда входят перечисленные сценарии в найме, образовании, доступе к основным услугам, биометрии и ряде государственных сфер, перенесли на 2 декабря 2027 года. Требования к ИИ высокого риска из Приложения I, который встроен в продукт или отвечает за его безопасность, например к некоторым видам оборудования и программному обеспечению медицинских устройств с обязательной сторонней оценкой соответствия, перенесли на 2 августа 2028 года.

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

Несколько групп требований действовали еще до этого месяца:

• Определение системы ИИ и запреты на отдельные практики применяются с 2 февраля 2025 года.
• Положение о грамотном обращении с ИИ применяется с 2 февраля 2025 года, хотя AI Omnibus упростил порядок его исполнения и передал Комиссии и государствам ЕС больше работы по поддержке компаний.
• Правила управления и обязанности поставщиков моделей ИИ общего назначения применяются с 2 августа 2025 года.
• С 2 августа 2026 года AI Office может принудительно обеспечивать соблюдение правил для моделей общего назначения, включая старые модели, переходный период для которых уже закончился.

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

Не пишите в записке для совета директоров: «Акт об ИИ отложен до 2027 года». Укажите, какое положение относится к какой системе и с какой даты. Одна эта привычка предотвращает большинство ошибочных решений в этой сфере.

Сфера действия зависит от рынка и использования, а не от размера компании

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

Акт охватывает государственных и частных участников. В рекомендациях Комиссии «Navigating the AI Act» описаны поставщики, пользователи систем, импортеры и дистрибьюторы, причем прямо сказано, что правила распространяются на участников внутри и за пределами ЕС. Американская компания, предлагающая работодателям в Германии продукт с ИИ для подбора сотрудников, может считаться поставщиком в сфере действия Акта. Немецкая розничная сеть, которая покупает продукт для фильтрации кандидатов, может считаться пользователем системы. Обязанности могут возникнуть у обеих сторон, но они будут разными.

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

На практике нужно ответить на следующие вопросы о сфере действия:

1. Подпадает ли программа под определение системы ИИ в Акте или она лишь выполняет жесткие правила, заданные человеком?
2. Вы выступаете поставщиком, пользователем системы, импортером, дистрибьютором, производителем продукта или совмещаете несколько ролей?
3. Предлагают ли систему или модель в ЕС, вводят ли ее там в эксплуатацию, используют ли ее там, либо предназначен ли ее результат для применения в ЕС?
4. Действует ли исключение, например для определенных исследований и прототипов до выхода на рынок, военных целей, национальной безопасности или строго личного непрофессионального использования?
5. Продолжает ли действовать другой закон ЕС или государства, даже если Акт об ИИ не добавляет отдельной обязанности?

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

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

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

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

Большинство внутренних применений ИИ не относятся к высокому риску

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

Комиссия описывает два пути к категории высокого риска. По статье 6(1) ИИ относится к высокому риску, когда он считается продуктом или компонентом безопасности, подпадает под перечисленные нормы ЕС о продукции, а такой продукт требует сторонней оценки соответствия. По статье 6(2) целевой сценарий должен присутствовать в Приложении III. Там перечислены отдельные применения в биометрии, критической инфраструктуре, образовании, трудовых отношениях, доступе к основным частным и государственным услугам, работе правоохранительных органов, миграции, правосудии и демократических процессах.

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

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

В статье 6(3) предусмотрено узкое исключение для системы из Приложения III, которая не создает существенного риска для здоровья, безопасности или основных прав и не оказывает значимого влияния на принятие решений. Условия охватывают ограниченные процедурные или подготовительные задачи, улучшение уже выполненной человеком работы, выявление закономерностей в решениях без замены человеческой оценки и выполнение подготовительной задачи. Профилирование физических лиц исключает такую возможность. Поставщик, который ссылается на исключение, обязан документировать оценку. Правильный вывод состоит не в том, что любая второстепенная HR-функция относится к высокому риску, а в том, что для исключения нужны факты и письменное обоснование.

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

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

Требования прозрачности уже действуют

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

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

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

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

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

Раскрытие должно быть ясным и заметным при первом контакте с материалом, с учетом доступности для людей с ограниченными возможностями. В июле 2026 года Комиссия опубликовала рекомендации по статье 50, а в июне выпустила добровольный Code of Practice on Transparency of AI-Generated Content. Кодекс не заменяет закон, но компания, которая его соблюдает, получает более конкретный способ объяснить выбранную маркировку. Компания, которая не подписала кодекс, может применять другие подходящие меры и должна уметь их документально обосновать.

Для чат-бота поддержки достаточно такой небольшой рабочей записи:

system: website-support-assistant
role: provider-and-deployer
eu_exposure: true
article_50_case: direct-interaction
notice: "You are chatting with an AI assistant. A person can review your request."
notice_location: before-first-message
owner: support-operations
reviewed: 2026-08-03
evidence: screenshot-and-release-id

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

Сначала проверьте запрещенные сценарии

Прекратите запрещенные практики до спора о том, относится ли система к высокому риску: запрет действует с февраля 2025 года, и за его нарушение предусмотрен самый высокий уровень штрафов в Акте. Большинство небольших компаний не найдут у себя запрещенных сценариев, но короткая целевая проверка все равно нужна.

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

AI Omnibus добавил запрет на системы, которые создают сексуальные или интимные материалы без согласия изображенного человека, а также материалы сексуального насилия над детьми. Это одно из содержательных июльских изменений, а не отложенное требование для высокого риска.

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

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

Короткое правило для сотрудников из пяти пунктов часто полезнее документа на 40 страниц:

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

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

Обязанности поставщика и пользователя нужно разделять

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

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

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

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

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

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

Минимальный путь соответствия состоит из пяти записей

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

1. Соберите реестр систем и сценариев

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

Проверьте закупки, журналы единого входа, расширения браузеров, репозитории кода и отчеты о расходах. Поговорите с HR, поддержкой, маркетингом, продажами и разработкой. Неудобный вопрос «Каким инструментом ваша команда продолжит пользоваться, если мы заблокируем одобренного помощника?» часто быстрее опроса обнаруживает личные аккаунты и встроенные функции.

2. Определите роль и связь с ЕС

Для каждого сценария запишите, выступает ли компания поставщиком, пользователем, импортером или дистрибьютором, и объясните почему. Укажите связь с ЕС и заявленное исключение, если оно есть. Если систему продают под вашим брендом, запишите, кто выбрал целевое назначение и кто может менять ее поведение.

3. Классифицируйте применение

Сначала проверьте запреты, затем два пути к категории высокого риска и случаи статьи 50. Отдельно укажите другие режимы, которым нужен свой владелец. Для Приложения III приведите точную категорию и отметьте, заявляете ли исключение по статье 6(3). Слова «низкий риск» без обоснования не считаются классификацией.

4. Привяжите меры и сроки

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

5. Отслеживайте изменения

Проводите проверку по графику, а также при изменении цели, модели, данных, степени автоматизации, затронутой группы или географии. Версия с ранжированием кандидатов требует новой классификации. То же относится к выходу сервиса, работавшего только в США, на рынок ЕС.

Краткая строка реестра может выглядеть так:

{"id":"AI-017","use":"rank inbound job applicants","owner":"people-ops","role":"deployer","eu_use":true,"vendor_system":"external","decision_effect":"shortlist recommendation","human_override":true,"classification":"Annex III employment candidate","live_controls":["approved access","applicant notice","incident route"],"future_controls":["oversight assignment","log retention","use monitoring"],"next_review":"2026-10-01"}

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

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

Доказательства должны соответствовать решению, а не шаблону

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

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

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

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

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

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

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

Заголовок о штрафах плохо подходит для планирования

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

По статье 99 за запрещенные практики штраф может достигать 35 млн евро или 7 процентов годового мирового оборота. За другие перечисленные обязанности участников, включая прозрачность по статье 50 и требования к поставщикам или пользователям систем высокого риска, верхняя граница достигает 15 млн евро или 3 процентов. За неверные, неполные или вводящие в заблуждение сведения для органов предусмотрено до 7,5 млн евро или 1 процента. Для МСП, включая стартапы, применимый максимум равен меньшей из фиксированной суммы и доли оборота. Органы учитывают характер, тяжесть, длительность, умысел, меры по исправлению, сотрудничество и другие обстоятельства дела.

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

Расставьте приоритеты в таком порядке:

1. Остановите потенциально запрещенную практику и передайте спорный случай специалисту.
2. Исправьте раскрытия по статье 50 и работу поставщика с маркировкой, которая уже обязательна.
3. Проверьте, поставляет ли компания модель общего назначения, и если да, закрыты ли действующие требования GPAI.
4. Найдите системы из Приложения III и регулируемые продукты, назначьте работу на 2027 или 2028 год и не накапливайте проектный долг.
5. Поддерживайте меры для обычных сценариев в области конфиденциальности, безопасности, точности, договоров и интеллектуальной собственности.

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

Что МСП следует сделать на этой неделе

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

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

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

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

Обращайтесь за юридической консультацией по тем вопросам, где текст закона и факты действительно допускают спор: исключения по статье 6(3), существенные модификации, статус поставщика в продукте под своим брендом, публикации общественного интереса, классификация по безопасности продукции или пересечение требований трудового права и защиты данных. Передайте юристу уже заполненную запись с фактами. Платить юристу за выяснение того, каким инструментом пользуется HR, значит выбирать дорогой способ составить реестр.

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