Пользователь хочет понять различие между Provider и Deployer в контексте EU AI Act и применить это к практической работе по AI governance и compliance.
Provider — это участник, который разрабатывает, выводит на рынок или вводит в эксплуатацию AI-систему или GPAI model под своим именем; Deployer — участник, который использует AI-систему под своей ответственностью.
Provider и deployer — это разные роли участников по EU AI Act. Provider — участник, который разрабатывает, поручает разработку, выводит на рынок или вводит в эксплуатацию AI-систему или GPAI model под своим именем или товарным знаком. Deployer — участник, который использует AI-систему под своей ответственностью, за исключением сугубо личной непрофессиональной деятельности. Поэтому различие не сводится к формуле «vendor versus customer»: клиент может стать provider, если существенно модифицирует систему, ребрендирует её или меняет intended purpose регулируемым образом. Основные связанные понятия Atlas: provider, deployer и ai-system. Обязанности provider обычно сосредоточены на design, compliance evidence, market placement, documentation и post-market monitoring. Обязанности deployer обычно связаны с responsible use, соблюдением инструкций, human oversight, operational monitoring, качеством input data там, где это релевантно, и escalation при возникновении риска. В смешанных supply chains одна организация может даже иметь разные роли для разных систем, версий или deployment contexts.
Provider и deployer можно представить как различие между тем, кто делает инструмент доступным, и тем, кто использует этот инструмент у себя в работе. Компания, которая производит и продаёт safety-critical machine, отвечает за design и product compliance. Завод, который покупает и эксплуатирует эту машину, отвечает за правильное использование, обучение персонала, соблюдение инструкций и мониторинг проблем. С ИИ похоже. Provider обычно должен доказать, что система была построена и поставлена законно; deployer обычно должен доказать, что она ответственно используется в реальном операционном контексте. Обе роли важны, и даже безопасная система может создать риск, если оператор использует её в неправильном контексте.
Аналогия
Производитель оборудования и оператор на заводе: один поставляет систему, другой использует её в реальных рабочих условиях.
Это различие важно, потому что compliance по AI Act ломается, когда обязанности назначены неправильной стороне. Задачу уровня provider, например technical documentation или conformity assessment, нельзя просто переложить на deployer, у которого нет design evidence. Задачу уровня deployer, например local human oversight или monitoring в рабочем процессе, provider не может решить в одиночку. Сроки также важны: обязанности по запрещённым практикам и AI literacy уже начали применяться 2 февраля 2025 года, GPAI obligations — 2 августа 2025 года, а transparency rules запланированы к применению с 2 августа 2026 года. Role mapping поэтому нужно проводить до договоров, запуска или операционного rollout. Это особенно важно при procurement, потому что отсутствие supplier evidence или local oversight может задержать approval.
Срочность
Неверное role mapping может оставить обе стороны в уверенности, что требуемый контроль находится у другой стороны, создавая пробел для аудита и enforcement.
Практическая обязанность — создать role map для каждой AI-системы, а затем связать controls с правильным участником. Providers должны документировать intended purpose, risk classification, system design, testing, instructions, conformity evidence там, где это требуется, post-market monitoring и corrective-action processes. Deployers должны документировать, как используется система, кто её контролирует, какие инструкции соблюдаются, какие input data контролируются, как обучены пользователи и как эскалируются incidents или malfunctions. Договоры должны поддерживать это разделение через information flows, audit support, incident cooperation и change notices. Карту нужно пересматривать каждый раз, когда система ребрендируется, materially changed, интегрируется в другой продукт или используется для новой цели.
Главные ошибки возникают из-за того, что разделение ролей воспринимают как коммерческий ярлык, а не как юридический и операционный анализ. Компания может быть customer по договору, но всё равно принять на себя provider-like responsibility, если изменит purpose AI-системы или будет поставлять её дальше.
Ошибка 1: Называть каждого SaaS-клиента deployer означает игнорировать случаи, когда клиент ребрендирует, перепродаёт или существенно модифицирует систему.
Ошибка 2: Предполагать, что provider documentation заменяет local deployer oversight, значит оставить undocumented human review, staff training и real-use monitoring.
Основное сравнение Atlas — provider-vs-deployer. Связанные термины включают provider, deployer, ai-system, downstream-provider, intended-purpose, conformity-assessment и documentation. Эта страница также должна ссылаться на страницы вопросов о provider и conformity assessment. Она даёт читателям понятный путь от теории ролей к сбору evidence, договорам и обязанностям operational governance. Она также поддерживает чистую внутреннюю перелинковку от role labels к controls.