Что обязательства GPAI значат для покупателей ИИ?

Закон ЕС об искусственном интеллекте изменил требования, которые покупатель ИИ вправе предъявлять поставщику модели. Поставщик, выводящий новую модель ИИ общего назначения на рынок Евросоюза, уже не может отвечать на серьезные вопросы красивой карточкой модели и заверением, что юристы все проверили. С 2 августа 2025 года на такие новые модели распространяются обязанности по статье 53. С 2 августа 2026 года Еврокомиссия может добиваться их исполнения.

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

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

Статья 53 разделяет публичные сведения и материалы для покупателя

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

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

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

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

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

Резюме обучения дает карту, а не реестр данных

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

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

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

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

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

Документация интегратора должна определять шорт-лист

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

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

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

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

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

За заявлением об авторских правах должен стоять рабочий процесс

Требование по авторским правам касается рабочего процесса, а не обещания, что в модели нет защищенных произведений. Статья 53 требует политики соблюдения авторского права и смежных прав ЕС. Особое внимание уделено выявлению и соблюдению оговорок о правах по статье 4(3) Директивы об авторском праве на едином цифровом рынке с помощью современных технических средств.

Формулировка имеет значение. Она не требует гарантировать, что каждый источник свободен от авторских прав, и не закрывает споры об интеллектуальном анализе текста и данных. Она требует повторяемого способа выявлять оговорки и реагировать на них. Раздел об авторском праве Кодекса практики GPAI переводит это требование в более прикладные обязательства: политика, управление поисковыми роботами, меры законного доступа и канал для жалоб правообладателей. Кодекс добровольный, поэтому подпись под ним показывает выбранный путь соблюдения правил, а не заменяет юридическую обязанность.

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

Отделяйте проверку обучения от защиты на выходе. Контроль источников касается создания модели. Фильтры результата, возмещение убытков, поиск сходства и правила для клиентов относятся к ее использованию. Сильный ответ в одной колонке не заполняет пустую вторую. Закупочные команды часто объединяют оба вопроса под меткой «защита интеллектуальной собственности» и перестают видеть, с каким риском поставщик действительно работает.

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

Системный риск требует отдельного досье по безопасности

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

Закон об ИИ предполагает системный риск, когда совокупные вычисления при обучении превышают 10^25 операций с плавающей запятой. Поставщик, который знает, что модель превысит порог, обязан уведомить Еврокомиссию без задержки и не позднее чем через две недели. Еврокомиссия вправе признать системно рискованной и модель ниже порога, если ее возможности или влияние сопоставимы с самыми передовыми моделями. Объем вычислений запускает проверку, но не дает полной оценки безопасности.

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

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

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

Открытый исходный код меняет льготы, но не риск покупателя

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

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

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

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

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

Дата выхода модели на рынок определяет доступные сведения

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

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

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

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

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

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

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

model_evidence:
  provider_legal_name: ""
  model_and_version: ""
  eu_market_date: "YYYY-MM-DD"
  public_training_summary:
    location_recorded: false
    version_coverage: ""
    source_specificity: "low|medium|high"
    declared_gaps: []
  downstream_dossier:
    annex_xii_mapping_received: false
    limitations_relevant_to_use: false
    evaluation_protocol_explained: false
  copyright:
    policy_owner_identified: false
    rights_reservation_process_explained: false
  systemic_risk:
    status: "yes|no|undetermined"
    customer_incident_channel: ""
  change_control:
    notice_period_days: 0
    reassessment_trigger: ""
  decision: "pass|conditional|fail"

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

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

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

Закрепите изменения и отказы в договоре

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

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

Рабочее условие договора начинается с практических фактов:

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

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

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

Следите за поставщиком после покупки

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

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

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

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

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

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

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

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

Связанная цепочка сведений надежнее значка соответствия

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

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

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

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