Как ответить на запрос клиента про EU AI Act

Почему это вопрос про сделку, а не про штрафы

Когда обсуждают EU AI Act, в первую очередь обычно упоминают санкции. Размер штрафов действительно серьёзный — до тридцати пяти миллионов евро или семи процентов глобальной выручки. Но для небольшой команды это абстракция. Реальная угроза прямо сейчас другая: запрос про соответствие — это точка решения по сделке.

На рынке достаточно много похожих ИИ-продуктов, рядом и по функциональности, и по цене. И когда зрелый покупатель выбирает между двумя вендорами, он выбирает того, у кого меньше юридических и репутационных рисков для самого покупателя. Потому что использование стороннего ИИ-продукта может возложить на покупателя обязанности по AI Act — например, как на deployer. Если вендор не сможет обосновать свою позицию по применимости, роли, риску и доказательной базе, покупатель просто не возьмёт на себя эту нагрузку.

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

Что обычно идёт не так

Если читать ответы ИИ-команд со стороны покупателя — а это часть моей практики — три типа ошибок повторяются особенно часто. Внешне они выглядят по-разному, но все они приводят к одному и тому же результату: разрушению доверия.

Декларация соответствия без обоснования

Самая частая формулировка: «Наша компания соответствует EU AI Act». Точка. Никаких ссылок на статьи регламента, никакого описания продукта в терминах AI Act, никакого упоминания роли или риск-уровня. Кажется, что такая фраза звучит уверенно. На практике она читается ровно противоположным образом.

Регламент применяется поэтапно: запреты по Article 5 и обязанности по AI literacy — подготовленности сотрудников к работе с ИИ — по Article 4 действуют с 2 февраля 2025 года; обязанности по general-purpose AI (GPAI) — с 2 августа 2025 года; основной массив обязанностей, включая high-risk-системы по Annex III — с 2 августа 2026 года; high-risk AI, встроенные в регулируемые продукты по Annex I — с 2 августа 2027 года. Сами интерпретации развиваются по мере выхода разъяснений Европейской комиссии и AI Office.

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

Это разделение между декларативным и действительным соответствием — не моё наблюдение из практики в чистом виде. Veale и Zuiderveen Borgesius (2021), разбирая структуру AI Act ещё на стадии проекта, указывают на риск превращения требований в бумажное соответствие (paper compliance): формально выполненное, но не встроенное в продукт. Зрелый покупатель читает ответ именно через эту призму.

«К нам это не применяется» без доказательств

Зеркальная ошибка — заявить, что AI Act к компании или продукту не применяется. Иногда это действительно так. Но это смелое утверждение, требующее доказательства.

Две классические подошибки:

Неправильный территориальный принцип. Команда говорит: «Мы не зарегистрированы в ЕС, значит к нам это не относится». Это неверно. AI Act работает экстерриториально: если продукт предлагается пользователям в ЕС, или если результат его работы используется в ЕС, регламент применяется независимо от того, где зарегистрирована компания.

Перенос обязанностей на поставщика модели. «Мы используем OpenAI / Anthropic / Google / Mistral, значит обязанности на их стороне». Тоже неверно. По цепочке поставки ИИ существуют обязанности и у разработчика конечного решения, и у компании, которая модифицирует или интегрирует внешнюю модель в свой продукт. Article 25 прямо предусматривает сценарии, в которых роль может смениться: если компания продаёт систему под своим именем, существенно модифицирует её или меняет назначение, она может стать поставщиком (provider) даже в том случае, если изначально использовала готовую модель внешнего разработчика. Hacker, Engel и Mauer (FAccT '23) описывают эту логику как трёхуровневую модель ответственности по цепочке поставки GPAI: разработчик базовой модели, разработчик прикладной системы поверх неё и развёртывающая сторона — у каждого свой набор обязательств.

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

И ещё один важный поворот, который команды часто упускают. Даже если AI Act действительно не применяется к вашей компании или продукту напрямую — это не значит, что он не применяется к вашему клиенту. Если клиент работает на европейском рынке или его пользователи находятся в ЕС, обязанности могут возникнуть на его стороне — например, как у deployer. И тогда ваш ответ «нас это не касается» становится для него слабой опорой.

Передача вопроса юристу в одиночку

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

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

Со стороны покупателя ответ, написанный целиком на юридическом языке без связи с архитектурой продукта, заметен сразу. Сигнал такой: «У этих людей есть юрист, но нет системного управления продуктом». Что само по себе — серьёзный риск-сигнал, потому что соответствие требованиям AI Act — не статическая декларация, а живой процесс. Хороший ответ — совместная работа. Юрист, технический руководитель, владелец продукта, ответственный за управление ИИ — каждый закрывает свой слой.

Принцип: минимальная безопасная эффективность

Прежде чем перейти к структуре ответа — одно важное предупреждение. Эта статья не про то, как красиво упаковать отсутствие системы. Если в продукте действительно есть серьёзные риски, или если внутри команды нет понимания, как продукт работает, какие риски создаёт и кто за них отвечает, никакой хорошо написанный ответ это не заменит.

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

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

И вот когда такая система есть — даже скромная, даже на самом старте — ответ собирается логично. Многое уже видно из самого продукта; описывать почти ничего не нужно — нужно показать то, что есть.

Четыре направления зрелого ответа

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

Направление 1. Соответствие требованиям

Первый столп. Здесь раскрывается базовая позиция компании по AI Act.

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

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

Связь с рынком ЕС. AI Act работает экстерриториально. Конкретно укажите, почему регламент применим (или не применим): продукт предлагается пользователям в ЕС; клиент или deployer находится в ЕС; результат работы системы используется в ЕС; компания является поставщиком, импортёром, распространителем или стороной в цепочке поставки; продукт встроен в решение, выходящее на рынок ЕС. Сам феномен — когда европейское регулирование де-факто становится глобальным стандартом для компаний, формально находящихся за пределами ЕС, — описан в работе Bradford «The Brussels Effect» (2020); AI Act — один из последних его примеров.

Роль компании. Provider, deployer, distributor, importer — или комбинация ролей в разных частях продукта (Article 3 — определения ролей). Команды часто путают свою роль: считают себя deployer, тогда как fine-tuning или существенная модификация делают их provider в этой части системы. Или наоборот — позиционируются как provider, хотя по факту используют внешнюю модель без изменений.

Проверка смены роли (Article 25). Это критично для всех, кто строит решение на базе внешних моделей. Ответьте по каждому пункту: продаёте ли систему под своим брендом; меняете ли её назначение; существенно ли модифицируете внешний компонент (fine-tuning, RAG, изменение поведения через промпты и архитектуру); какие обязанности остаются у поставщика модели, а какие переходят к вам. Развёрнутый шаблон такой проверки — с детальным разбором ролей и обязательной сводки по данным обучения (summary training data) — собран в моём руководстве EthicaLogic — GPAI Guide: его удобно использовать как основу для внутренней самопроверки команды.

Классификация системы. Заполните три самостоятельных измерения: категория системы по AI Act (запрещённая практика — Article 5; система высокого риска — Article 6, Annex III, или встроенная в регулируемый продукт по Annex I; система с обязанностями по прозрачности — Article 50; система без специальных обязанностей, кроме AI literacy по Article 4); GPAI-зависимость (используется / не используется / требуется проверка); роль компании.

Применимые обязанности и сроки. Перечислите основные обязанности, применимые к вашей роли, типу системы и сроку применения. Для каждой обязанности — статья регламента, дата начала применения для вашего случая, текущий статус (сделано / в работе / запланировано), ответственный.

Направление 2. Анализ рисков

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

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

Методология оценки. NIST AI Risk Management Framework, ISO/IEC 42001, ISO 31000, или собственная методология, опирающаяся на одну из них. Назовите её. Если методология собственная, опишите её ключевые принципы в 2–3 предложениях.

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

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

Направление 3. Технические средства

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

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

Обязанности по прозрачности (Article 50). Article 50 устанавливает обязанности прозрачности для определённых AI-систем — и для поставщика, и для развёртывающей стороны. Проверьте каждый пункт: информируется ли пользователь о взаимодействии с ИИ; маркируется ли синтетический или искусственно изменённый контент; есть ли deepfake или synthetic media risk; используется ли распознавание эмоций или биометрическая категоризация. Для каждого применимого пункта опишите, как это реализовано, и какие обязанности по прозрачности остаются у клиента как deployer.

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

Направление 4. Управление и процессы

Третий столп. Один абзац — но конкретный.

Матрица ответственности. Кто внутри компании принимает решения по ИИ. Для небольших команд достаточно перечислить роли: ответственный за управление ИИ, владелец продукта, технический руководитель, юрист или ответственный за соответствие требованиям, лицо, принимающее решение по рискам. Для каждой роли — какие решения в её компетенции.

Проверка и утверждение изменений. Какие категории изменений в продукте (особенно в части моделей, данных, промптов и логики принятия решений) требуют формальной проверки. Какие комитеты или роли участвуют. Какие артефакты создаются — model card, оценка влияния на риски, протокол утверждения.

Реакция на инциденты. Раздел построен вокруг процесса, не вокруг санкций. Если для вашей системы развёрнутый процесс ещё преждевремен, зафиксируйте хотя бы минимальный: кто выявляет инцидент, кто принимает решение, кто уведомляет клиента, какие записи сохраняются и когда пересматривается риск. Сроки уведомления клиента обычно определяются договором, SLA, политикой безопасности и применимыми правовыми требованиями. В развёрнутой версии раздел про инциденты включает: внутренний процесс реагирования; уведомление клиента; уведомление компетентного органа, если применимо; распределение обязанностей между provider и deployer; связь с журналами и доказательной базой; процесс разбора после инцидента и пересмотр риска. Методическая опора по структурированному реагированию — OECD «Towards a Common Reporting Framework for AI Incidents» (2025) — общий каркас для описания инцидентов с ИИ; удобно использовать как отправную точку для внутреннего шаблона.

Сквозная вещь: доказательная база

Доказательная база — это то, что проходит через все четыре направления. Что у вас уже есть в документации, подтверждающее то, что вы пишете.

Минимальный набор: реестр ИИ-компонентов с описанием параметров; описание ролей по AI Act; классификация рисков с обоснованием — не «у нас limited risk», а почему именно; технические описания процедур; процессные документы и матрицы ответственности.

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

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

Закрывающий блок: что ещё впереди и план

Это самая ценная часть для зрелого покупателя. Не пытайтесь казаться идеальными. Прямо опишите: какие обязанности применимы к вашей системе и ещё впереди по таймингу применения регламента; текущий статус по каждой (в работе / запланировано); конкретные сроки закрытия и ответственные.

Зрелый клиент ценит именно это — честную карту будущего, а не лакированную картину настоящего. Ответ «у нас всё закрыто» без признания того, что какие-то обязанности ещё впереди по дате применения, читается как неправда или непонимание поэтапного применения AI Act. И в том, и в другом случае — сигнал к недоверию.

Когда отвечать преждевременно

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

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

FAQ