Использование персональных данных для обучения моделей искусственного интеллекта в праве Европейского союза

Введение

Принятие Регламента 2024/1689 об искусственном интеллекте (Artificial Intelligence Act, далее — Акт об ИИ)¹ ознаменовало переход Европейского союза от декларативного этического подхода к нормативно-правовой детализации жизненного цикла систем искусственного интеллекта (далее — ИИ-системы). В отличие от прежнего, преимущественно этического, дискурса новый акт закрепляет юридически обязательные требования к проектированию, обучению и эксплуатации систем искусственного интеллекта при одновременном сохранении действия Общего регламента о защите данных (General Data Protection Regulation, далее — GDPR)². Уже в ст. 2(7) Акта об ИИ подчеркивается, что он «не затрагивает и не уменьшает» объем защиты, гарантированной иным законодательством Союза, прежде всего GDPR, формируя для участников рынка режим двойной нормативной подотчетности³. В доктрине при этом просматриваются по меньшей мере два конкурирующих подхода: часть авторов предлагает рассматривать Акт об ИИ как lex specialis (специальное регулирование по отношению к общему режиму GDPR) для высокорисковых систем (Hadwick, 2024, pp. 947–948; Kindt, 2025, p. 31) (сходная аргументация встречается и в политико-правовых аналитических материалах, сопровождающих обсуждение и принятие Акта об ИИ, где отдельно фиксируются риски пересечений и конкуренции регуляторных режимов⁴); другие, напротив, настаивают на автономной значимости принципов защиты данных и воспринимают Акт об ИИ лишь как техническое уточнение уже существующих обязанностей (Winau, 2023; De Hert & Hajduk, 2024, p. 292; van Bekkum, 2025, p. 2). Автор настоящей работы придерживается промежуточной позиции, исходящей из невозможности свести один режим к другому без потери содержания.

Нормативная конструкция взаимодействия Акта об ИИ и GDPR не может быть сведен к простому суммированию обязанностей. Акт об ИИ формулирует углубленные технические и процессуальные требования (качество данных, управление рисками, документация, оценка воздействия на права), тогда как GDPR закрепляет фундаментальные принципы обработки персональных данных и архитектуру прав субъектов. Нарушение последних способно превратить даже формально выстроенный процесс обучения модели в юридически дефектный. Характерно, что аналитические материалы⁵ к Акту об ИИ прямо подчеркивают: соблюдение самих по себе требований данного документа не гарантирует соответствия требованиям GDPR⁶, а оценка влияния искусственного интеллекта на основные права⁷ (Fundamental Rights Impact Assesment, далее — FRIA) в работах А. Мантелеро и других авторов рассматривается как самостоятельный способ контроля, как отдельная процедура, выходящая за рамки сугубо оценки рисков для защиты персональных данных и конфиденциальности (Mantelero, 2024, p. 9; Kaminski & Malgieri, 2024, pp. 314–315).

Наибольшее напряжение между двумя режимами проявляется на обучающей стадии, где сходятся противоположные методологические векторы. С одной стороны, статья 10 Акта об ИИ закрепляет императив высококачественных, репрезентативных и, по возможности, свободных от ошибок обучающих наборов наряду с обязанностью провайдера внедрять процедуры выявления и коррекции алгоритмических смещений. С другой стороны, GDPR квалифицирует любую загрузку данных в модель искусственного интеллекта (далее — ИИ-модель) как обработку персональных данных и предписывает принцип минимизации: обрабатывать лишь те данные, которые «адекватны, релевантны и ограничены необходимым для целей, для которых они обрабатываются» (ст. 5(1)(c) GDPR)⁸. Здесь важно отметить, что требование репрезентативности фактически размывает правило минимизации и способствует расширению массивов данных, тогда как другие исследователи предлагают рассматривать эти требования как комплементарные при условии строгого риск-ориентированного подхода (risk-based approach) и прозрачной документации об источниках и о структуре датасетов⁹ (Paullada et al., 2021, pp. 1, 4, 10)¹⁰. В настоящей работе минимизация и репрезентативность рассматриваются не как автоматически согласованные принципы, а как напряженная связка, требующая дополнительных гарантий: процедур оценки воздействия на защиту данных (Data Protection Impact Assessment, далее — DPIA), на основные права (FRIA), ведения внутреннего журнала минимизации (обоснование включения каждого класса атрибутов и сроков хранения) и ограничений на вторичное использование обучающих, валидационных и тестовых наборов персональных данных и их производных версий (включая объединенные датасеты и повторно размеченные выборки) вне первоначально заявленных целей обучения.

Возникающая коллизия имеет по меньшей мере три аспекта:

1) вопрос о допустимом объеме и структуре выборки, необходимой для нивелирования предвзятости без утраты соразмерности обработки;

2) правовая судьба повторной и переносной переработки, когда исходные пользовательские данные применены для первоначального обучения, а затем привлекаются для иных целей, включая дополнительное обучение¹¹ и перенос обучения¹²;

3) соразмерность технических и организационных мер категории риска модели с учетом дифференциации согласно ст. 6, 7 Акта об ИИ по уровням критичности и оценки тяжести воздействия на основные права (Malgieri & Santos, 2025 pp. 3, 7; Novelli et al., 2024b, pp. 1-2, 21)¹³.

Особое значение имеет статья 10(5) Акта об ИИ¹⁴, допускающая исключительную обработку специальных категорий персональных данных при разработке и проверке высокорисковых систем лишь в той мере, в какой это строго необходимо для обеспечения выявления и коррекции возможных предвзятостей (biases)¹⁵ в обучающих, валидационных и тестовых наборах данных в рамках процедур управления данными, предусмотренных статьей 10(2)(f)–(g) Акта об ИИ¹⁶, при условии соблюдения установленных данной нормой гарантий. Норма, ориентированная на снижение риска дискриминации и иных неблагоприятных эффектов, одновременно обостряет дилемму правомерности обработки: статья 9 GDPR¹⁷ закрепляет общий запрет на обработку специальных категорий персональных данных, тогда как статья 10(5) Акта об ИИ¹⁸ вводит узкоцелевое исключение, сопряженное с обязанностями по выявлению и снижению смещений и дополненное требованиями: обосновать невозможность достижения цели посредством обработки иных данных, включая синтетические или анонимизированные; применять современные меры безопасности и защиты данных, включая псевдонимизацию; ограничивать повторное использование и передачу третьим лицам, а также обеспечивать контроль доступа и документирование операций; удалять соответствующие данные после достижения цели коррекции смещений либо по истечении срока хранения. В доктрине данная конструкция обсуждается как вопрос о том, представляет ли указанное исключение допустимое точечное смягчение запрета статьи 9 GDPR¹⁹ или, напротив, создает риск «ползучего расширения» (function creep)²⁰, при котором ссылка на устранение смещений фактически легитимирует устойчивую обработку чувствительной информации (van Bekkum, 2025, pp. 3, 7–8).

В отсутствие унифицированных методических разъяснений Европейской комиссии и Европейского управления искусственного интеллекта степень неопределенности усиливается недавними позициями надзорных органов. Так, в заключении 28/2024 Европейского совета по защите данных подчеркивается, что принцип минимизации «в полном объеме применим к разработке и развертыванию моделей» и что крупномасштабный веб-скрейпинг, т. е. автоматизированный сбор данных с веб-сайтов с помощью программных средств, не может автоматически опираться на исключение из информационной обязанности по ст. 14(5)(b) GDPR²¹. Тем самым подтверждается, что источники данных для обучения требуют индивидуальной юридической оценки, а массовый подход, предполагающий загрузку больших массивов данных без разбора, не соответствует стандартам GDPR. В литературе указанные выводы получают неоднозначную интерпретацию. С одной стороны, они рассматриваются как подтверждение того, что требования Акта об ИИ не подменяют и не устраняют автономную применимость GDPR: принципы GDPR и связанные оценочные процедуры сохраняют самостоятельное значение параллельно инструментам Акта об ИИ, включая FRIA (Mantelero, 2024, p. 4; Malgieri & Santos, 2025, pp. 1–2)²². С другой стороны, те же положения описываются как проявление структурной незавершенности многоуровневого регулирования, в рамках которого методологии оценки рисков и контуры правоприменения еще формируются через стандартизацию, подзаконные акты и руководства, что объективно предполагает сосуществование и конкуренцию нескольких моделей комплаенса и enforcement-практик (Novelli et al., 2024b, p. 1; Söderlund & Larsson, 2024, p. 2; van Bekkum & Zuiderveen Borgesius, 2023, p. 2).

Указанные обстоятельства формируют ядро проблемного поля настоящего исследования. Его научная новизна обусловлена тем, что, во-первых, трансграничная цифровая экономика нуждается в оперативных, но юридически выверенных методиках подготовки обучающих наборов и документирования решений на обучающей стадии; во-вторых, существующая литература преимущественно концентрируется либо на догматическом анализе Акта об ИИ и его типовых схемах правоприменения и надзорной практики (enforcement patterns), либо на традиционных вопросах защиты персональных данных, не предлагая синтезированной модели согласованного применения обоих актов в области разработки и эксплуатации ИИ-систем. Отдельные подходы к оценке воздействия на права человека (FRIA), к управлению наборами данных через практики управления данных (data governance) и документирование решений на стадиях формирования и использования датасетов, а также к подготовке проверяемой (audit-ready) технической документации для целей комплаенса по Акту об ИИ (Mantelero, 2024, p. 4; Paullada et al., 2021, pp. 1, 7, 10; Sovrano et al., 2025, pp. 1, 4) пока не сведены в единую правовую конструкцию обучения ИИ-моделей²³.

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

Для достижения цели ставятся следующие задачи:

1) обозначить правовые контуры стадии обучения ИИ-моделей, выявив нормативную специфику и конкурирующие регуляторные векторы Акта об ИИ и GDPR, включая анализ категорий субъектов, их обязанностей и юридического значения терминов «модель», «система», «обучающие данные», «предназначенная цель»;

2) проанализировать трансформацию принципа минимизации данных в условиях потребности в больших и репрезентативных обучающих наборах и связать ее с требованиями к качеству данных и предотвращению дискриминации;

3) сформулировать нормативную модель соразмерности защитных мер, сопоставив положения (ст. 6–7, 9 и 10) Акта об ИИ²⁴ (риск-ориентированный подход к управлению рисками ИИ-систем) и ст. 25 GDPR²⁵ с учетом результатов FRIA;

4) предложить прикладную схему корпоративного комплаенса по стадиям жизненного цикла ИИ-модели (сбор данных, подготовка, обучение, развертывание, мониторинг), объединяющую требования обоих регламентов и позволяющую реализовать их на уровне процедур и документации.

Правовые контуры обучения ИИ-модели

Структурирование правового поля, в котором функционируют практики обучения искусственного интеллекта, невозможно без предварительного разграничения уровней регламентации и уточнения понятийного аппарата. Статья 2 Акта об ИИ прямо закрепляет, что его применение «не затрагивает и не уменьшает» гарантии, установленные иным правом Союза, прежде всего GDPR²⁶. Тем самым формируется конструкция двойного регулирования: Акт об ИИ задает специальный режим для высокорисковых ИИ-систем, а GDPR остается горизонтальной нормой всеобщего действия, определяющей принципы обработки персональных данных и права субъектов²⁷.

Принцип неснижаемости стандартов GDPR превращает отношения между двумя актами не в классическую иерархию «общее — специальное», а в модель согласованного применения: выполнение процедур, предусмотренных Актом об ИИ, не освобождает от следования принципам законности, минимизации и целевого ограничения обработки. Любое технически корректное исполнение требований Акта об ИИ, не опирающееся на принципы GDPR, может быть квалифицировано как юридически дефектное. Это уже отражается в практических руководствах по комплаенсу в сфере искусственного интеллекта²⁸, где отдельно подчеркивается необходимость совмещать риск-ориентированный подход к управлению ИИ-системами и оценку воздействия на основные права.

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

• управление рисками (ст. 9)²⁹;
• управление данными: качество, происхождение, точность, безопасность (ст. 10)³⁰;
• техническая документация (ст. 11)³¹;
• ведение регистрационных журналов (record-keeping) (ст. 12)³²;
• прозрачность и инструкции для пользователей (transparency and instructions) (ст. 13–14)³³ и др.

Эти нормы фактически переносят классические механизмы безопасности продукции (product safety) из сферы технического регулирования в область алгоритмической инженерии. GDPR, напротив, налагает обязанности в зависимости не от роли в цепочке поставок, а от факта обработки персональных данных³⁴. В совокупности это образует матрицу ответственности, где каждая стадия жизненного цикла ИИ-системы соотносится с двумя наборами норм — Акта об ИИ и GDPR, а также с внутренними стандартами управления рисками и качеством (Söderlund & Larsson, 2024, pp. 10–11).

Примечательно, что в ст. 3(1) Акта об ИИ впервые закреплено нормативное определение ИИ-системы: машинная система, разработанная для работы с различным уровнем автономности и способная, для явных или неявных целей, выводимых человеком, генерировать результаты в виде прогнозов, рекомендаций или решений, влияющих на среду, с которой она взаимодействует³⁵. Как следует из соображения 12 преамбулы, понятие ИИ-системы в Акте об ИИ³⁶ конструируется функционально, вокруг способности системы осуществлять алгоритмический вывод (inference)³⁷, а не вокруг конкретного семейства технологий. В сферу регулирования включаются как подходы машинного обучения³⁸, обучающиеся на данных, так и логико- и знание-ориентированные подходы (символьные/экспертные методы), тогда как «более простое» традиционное программное обеспечение, основанное исключительно на правилах, заданных человеком для автоматического исполнения операций, из охвата исключается. Дополнительно, согласно заключению 28/2024 Европейского совета по защите данных, подпадают также и нейросетевые архитектуры, но и системы, основанные на заранее заданных правилах (rule-based systems), статистические алгоритмы и гибридные решения³⁹. Функционально-ориентированный подход смещает акцент с конкретной технологии на результат и контекст использования, что принципиально для правового анализа и оценки рисков; детерминированное программное обеспечение общего назначения при этом выводится за пределы действия акта.

Такое нормативное конструирование имеет два существенных следствия. Во-первых, все процедуры обучения (начальное обучение (initial training), переобучение (retraining), дообучение модели на новых данных) прямо включаются в жизненный цикл ИИ-системы и рассматриваются как объект регулирования Акта об ИИ. Во-вторых, статья 3 Акта об ИИ вводит категории «обучающие», «проверочные» и «тестовые данные» (training, validation и testing data), акцентируя требования к их качеству, репрезентативности и, по возможности, свободе от ошибок⁴⁰. Эти характеристики непосредственно связаны с обязанностью провайдера по ст. 10 Акта об ИИ выявлять и устранять смещения в наборе данных (dataset bias)⁴¹, т. е. структурную предвзятость, например недопредставленность отдельных групп или использование устаревших паттернов поведения, и связывают управление данными с принципом недискриминации и защитой фундаментальных прав (van Bekkum, 2025, p. 7)⁴².

На этом фоне особое значение приобретает разграничение понятий «система искусственного интеллекта» (ИИ-система) и «модель искусственного интеллекта» (ИИ-модель). ИИ-система в понимании Акта об ИИ определяется функционально как машинная система, способная осуществлять алгоритмический вывод (inference) и генерировать результаты (прогнозы, рекомендации или решения), влияющие на среду, в которой она применяется (ст. 3(1); п. 12 преамбулы)⁴³. ИИ-модель, напротив, рассматривается как алгоритмическое ядро и компонент, который может быть встроен в ИИ-систему, но сам по себе не образует ИИ-систему (п. 97 преамбулы)⁴⁴. Юридически обязанности провайдера по Акту об ИИ структурно привязаны к ИИ-системе как объекту вывода на рынок/ввода в эксплуатацию и обеспечения соответствия требованиям регламента (для высокорисковых ИИ-систем, в частности, ст. 16 Акта об ИИ)⁴⁵, тогда как на уровне модели концентрируются ключевые технические риски для персональных данных и основных прав, оценка которых в части защиты данных традиционно проводится через призму GDPR и смежных актов.

В настоящей работе основное внимание уделяется именно ИИ-модели как носителю рисков, связанных с обучающими данными. Для целей анализа используется в том числе понятие «базовая модель» (foundation model) — разновидность модели общего назначения (general-purpose model), описанная в пп. 97–100 преамбулы Акта об ИИ как крупная генеративная модель с миллиардом и более параметров, способная выполнять широкий спектр задач⁴⁶. Такая модель не образует ИИ-систему до тех пор, пока не встроена в прикладной интерфейс и не связана с конкретным сценарием принятия решений; ее правовой режим, следовательно, определяется сочетанием требований Акта об ИИ к качеству и управлению данными и принципов GDPR, применимых к этапу обучения.

Особого внимания заслуживает понятие смещения в наборе данных (dataset bias). В статьях 10 и 44 Акта об ИИ⁴⁷ оно становится связующим звеном между принципом недискриминации (ст. 21 Хартии ЕС об основных правах⁴⁸) и принципом минимизации данных. Законодатель прямо указывает, что одного лишь количественного критерия (размера выборки) недостаточно: необходим качественный анализ предвзятости и потенциальных дискриминационных эффектов, в том числе, в исключительных случаях, использование специальных категорий данных для корректирующих целей В литературе такая постановка вопроса описывается как практическая коллизия между потребностью диагностировать предвзятость по группам и ограничениями режима специальных категорий персональных данных: верификация дискриминационных исходов нередко требует доступа к чувствительным атрибутам или их приближенным заменителям, тогда как GDPR в типичных сценариях ограничивает сбор и использование таких данных, а согласие часто не отвечает критерию свободного волеизъявления. Одновременно подчеркивается, что наращивание массивов сверх строгой необходимости конфликтует с принципами минимизации и целевого ограничения, повышая риск «ползучего расширения» задач и масштабов обработки (function creep); в качестве одного из способов удержания баланса обсуждается использование синтетических данных как инструмента снижения рисков для частной жизни при сохранении задач контроля предвзятости (bias) (van Bekkum, 2025, p. 7; van Bekkum & Zuiderveen Borgesius, 2023, pp. 5–6, 7; Veltmeijer & Gerritsen, 2025, pp. 3174–3175).

С учетом указанной дихотомии разработчик корпоративной ИИ-системы на обучающей стадии сталкивается как минимум с тремя ключевыми задачами:

1) установить, относится ли создаваемый продукт к высокорисковым согласно ст. 6 Акта об ИИ⁴⁹ и, следовательно, подпадает ли он под жесткий режим регулирования;

2) определить, содержит ли обучающий набор персональные данные в понимании ст. 4(1) GDPR и специальные категории данных в смысле ст. 9 GDPR⁵⁰;

3) оценить наличие разумно предсказуемого риска для основных прав, что может требовать проведения процедуры DPIA и, в отдельных случаях, FRIA.

В отличие от абстрактного анализа норм процедура оценки воздействия на защиту данных (DPIA) позволяет продемонстрировать регулятору и самим субъектам данных, каким образом оператор учел выявленные риски и превратил их в управляемые параметры проектного цикла.

DPIA должна включать описание операций и целей обработки; правовой анализ и выбор правового основания; идентификацию и оценку рисков; перечень технических и организационных мер защиты; оценку остаточного риска и, при необходимости, консультацию с надзорным органом (ст. 36 GDPR)⁵¹.

В качестве иллюстрации рассмотрим применение процедура оценки воздействия на защиту данных (DPIA) при обучении модели кредитного скоринга в финансовом секторе. Банк, разрабатывающий алгоритм оценки вероятности дефолта клиента, обрабатывает комплексные массивы персональных данных: кредитные истории, транзакции, сведения из процедур KYC (Know Your Customer), иногда дополнительные профили из внешних источников. При этом возникает реальная опасность косвенной дискриминации по косвенным социальным признакам, опосредованно связанным с защищаемыми характеристиками (например, по месту проживания, типу занятости, уровню дохода, модели потребления) и меморизации («запоминания») чувствительной информации моделью. В рамках DPIA банк фиксирует цели обработки, источники данных и сценарии их повторного использования. Для принятия решения о кредите правовым основанием служит статья 6(1)(b) GDPR (исполнение обязательства из договора), тогда как для последующего улучшения модели — статья 6(1)(f) GDPR (законный интерес) в сочетании с усиленной минимизацией и ограничением доступа⁵². Отбор переменных при этом осуществляется не по принципу «чем больше, тем лучше», а по доказанной значимости для качества прогнозирования и влиянию на риск дискриминации.

Следующий блок DPIA посвящен идентификации и оценке рисков для прав субъектов данных: непрозрачность алгоритмической логики, возможность косвенной дискриминации уязвимых групп, риск утечки информации через поведение модели. Каждый риск получает оценку вероятности и тяжести последствий, после чего формируется набор компенсирующих мер: регулярный аудит смещений (bias); мониторинг дрейфа данных и деградации качества; использование специальных категорий данных исключительно для тестирования справедливости и недопущение их включения в «боевую» модель. Результатом DPIA становится формализация остаточного риска; если он признается высоким, оператор обязан обратиться за консультацией к надзорному органу в порядке ст. 36 GDPR⁵³. Такая консультация не является формальной, а представляет собой механизм диалога о допустимых границах применения искусственного интеллекта в конкретном секторе.

Особенно показательна взаимосвязь между ст. 10 Акта об ИИ (управление данными)⁵⁴ и ст. 25 GDPR (защита персональных данных по замыслу и по умолчанию)⁵⁵. Первая предписывает обеспечивать качество, репрезентативность и корректность данных, а также процедуры управления ими; вторая требует встроенной минимизации и защиты уже на этапе проектирования архитектуры обработки. Только наложение этих требований формирует юридически валидный пайплайн обучения: GDPR задает горизонтальные пределы допустимой обработки, а Акта об ИИ утверждает вертикальные процедуры доказательства ее безопасного и недискриминационного характера.

Дополнительное значение приобретает международный стандарт ISO/IEC 42001:2023 — первый сертификационный стандарт для систем управления ИИ, интегрирующий риск-ориентированное мышление, предполагающее принятие решений с учетом вероятности и тяжести последствий (risk-based thinking), и механизмы постоянного улучшения⁵⁶. Его практическая ценность заключается в том, что он создает процессную прослойку между нормами и инженерными практиками, подтверждая, что принцип минимизации GDPR и процедуры управления данными Акта об ИИ укоренены в системе менеджмента компании, а не применяются разово «под аудит».

Уточнение субъектного состава завершает правовые очертания обучения. Статья 3(3) Акта об ИИ вводит фигуру провайдера (provider) — лица, размещающего систему на рынке под своим именем⁵⁷, одновременно опираясь на традиционные категории, предусмотренные GDPR, — «контролер, оператор персональных данных» (controller) и «обработчик» (processor) (пп. 7–8 ст. 4 GDPR)⁵⁸. На практике одна и та же компания может совмещать обе роли: при разработке выступать оператором по отношению к обучающему набору, а при выводе продукта на рынок становиться провайдером высокорисковой системы. В результате формируется управленческая матрица обязанностей, в которой по вертикали располагаются стадии жизненного цикла (сбор, подготовка, обучение, валидация, эксплуатация и мониторинг), а по горизонтали — кластеры регуляторных норм (обязанности по GDPR, требования Акта об ИИ, процедуры согласно стандарту ISO/IEC 42001:2023). Такая матрица служит инструментом распределения ответственности, планирования ресурсов комплаенса и включения управления рисками в цикл разработки ИИ-модели.

Принцип минимизации данных как ценностный фильтр и методологическая опора обучения ИИ-моделей

Принцип минимизации данных в ст. 5(1)(c) GDPR формулируется через триаду «адекватность — релевантность — ограниченность необходимым»⁵⁹. Адекватность означает соответствие данных поставленной цели, релевантность — наличие прямой связи данных с задачей обработки, а ограниченность необходимым предполагает невозможность достижения цели без конкретного элемента данных. Минимизация в правовом смысле подразумевает то, что обрабатываться должен только тот объем информации, который действительно нужен для конкретной цели⁶⁰ (Finck & Biega, 2021, pp. 55–57).

На практике это превращает минимизацию в инструмент управления рисками: каждое решение о включении нового атрибута (например, даты рождения, геолокации, детализированной истории транзакций) должно оцениваться через призму необходимости для достижения заявленной цели обработки и соразмерности вмешательства в права субъекта персональных данных. Суд Европейского союза в деле Meta Platforms Ireland v. Bundesverband der Verbraucherzentralen & Verbraucherverbände⁶¹ подчеркнул, что даже при наличии выраженного коммерческого интереса, включая финансирование деятельности за счет персонализированной рекламы, допустимость обработки определяется тестом необходимости и пропорциональности, а также наличием менее ограничивающих альтернатив; при этом в условиях широкого и фактически «почти тотального» мониторинга поведения пользователей интересы и основные права последних могут иметь приоритет над интересом оператора, что усиливает значение минимизации как требования исключать из обработки избыточные и идентифицирующие элементы, не являющиеся строго необходимыми для цели⁶².

Дополнительный уровень сложности создает статья 10 Акта об ИИ, которая требует, чтобы обучающие выборки⁶³ были репрезентативными, полными и, по возможности, свободными от ошибок⁶⁴. Репрезентативность предполагает, что выборка отражает свойства всей целевой популяции (например, база клиентов банка включает разные возрастные группы, регионы, социальные категории). Полнота означает наличие признаков, без которых задача модели не может быть решена (например, отсутствие данных о доходах делает кредитный скоринг заведомо деформированным). Требование «по возможности, свободными от ошибок» связано с очисткой выборки от дубликатов, некорректных, противоречивых и явно устаревших значений.

На уровне формальной логики требования минимизации и репрезентативности выглядят как напряженная пара: чем больше данных собрано, тем проще обеспечить статистическую устойчивость⁶⁵, но тем выше регуляторный риск избыточной обработки. Разрешение этого противоречия осуществляется через принцип соразмерности, закрепленный в ст. 52 Хартии ЕС об основных правах: вмешательство в права допускается лишь в той мере, в какой оно необходимо и пропорционально легитимной цели⁶⁶. Для обучения моделей это означает, что использование крупных выборок оправданно только при доказанной необходимости для достижения статистической устойчивости и недискриминационного результата и при отсутствии менее инвазивной альтернативы (например, работы с агрегированными данными или более грубой детализацией признаков).

Современные исследования машинного обучения подтверждают, что рост объема и детализации данных не является безусловным благом. Так, чрезмерное увеличение числа параметров модели (глубины нейронной сети, количества признаков) приводит к переобучению⁶⁷ (Rocks & Mehta, 2022, p. 15). Технически это выражается в снижении числа ошибок на обучающих данных при одновременном росте на тестовом наборе. Для правового анализа важно не само понятие дисперсии и смещения, а вывод: существует точка, после которой увеличение объема и детализации данных ухудшает качество решения и, следовательно, не может считаться необходимым в смысле ст. 5(1)(c) GDPR⁶⁸.

Один из практических способов совместить требования минимизации и репрезентативности — статистическая подвыборка⁶⁹. Основанная на понятных критериях (устранение повторов, выравнивание дисбаланса групп, исключение очевидных выбросов), она одновременно снижает регуляторный риск и повышает обобщающую способность модели. В юридической плоскости это можно рассматривать как реализацию принципов минимизации и защиты данных по замыслу (data protection by design) (ст. 25 GDPR) средствами инженерного проектирования⁷⁰.

Существенную роль играют и методы обезличивания. Классическим подходом остается k-анонимность⁷¹. Исследования показывают, что разумно сконструированная k-анонимность может снижать риск повторной идентификации при минимальном влиянии на качество классификации (Slijepčević et al., 2021). Дополнительно используется l-диверсификация⁷², что препятствует восстановлению личности по редким комбинациям атрибутов. Эти техники не устраняют полностью юридическую связь с понятием персональных данных, но позволяют уменьшить степень вмешательства и продемонстрировать надзорному органу, что контролер предпринял разумные шаги к минимизации риска.

В праве ЕС минимизация данных в сфере обучения ИИ-моделей трактуется не как разовое сокращение признаков, а как управленческий и юридический процесс, встроенный в деятельность контролера. Статья 5(1)(c) GDPR и принцип подотчетности в ст. 5(2) GDPR требуют, чтобы контролер мог объяснить и задокументировать, почему каждый элемент данных включен в обработку⁷³. На практике это реализуется через поэтапную процедуру.

Первый этап — инвентаризация признаков. Контролер составляет полный перечень атрибутов, планируемых к использованию в обучении, и проводит их классификацию по уровню идентифицируемости. Условно можно выделить три уровня. Уровень A включает прямые идентификаторы (имя, паспортные данные, телефон, адрес электронной почты); их сохранение в исходном виде в обучающем наборе допустимо лишь в исключительных случаях. Как правило, в отношении них требуется либо удаление, либо псевдонимизация⁷⁴ (ст. 4(5) GDPR)⁷⁵. Уровень B охватывает квази-идентификаторы (возраст, регион, профессию, комбинацию характеристик), которые по отдельности не раскрывают личность, но в совокупности могут вести к идентификации; их использование требует прохождения теста невозможности альтернативы, когда оператор должен документально подтвердить, что без этих данных невозможно обеспечить требуемое качество модели. Уровень C составляют менее чувствительные признаки, в отношении которых приоритет имеют укрупнение, агрегирование и обезличивание, если потери качества остаются в пределах статистически допустимого диапазона.

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

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

Третий этап связан с применением технологий усиления приватности⁷⁸. В качестве наиболее показательного примера в литературе обычно рассматривается дифференциальная приватность как формализованный подход к ограничению утечек о конкретных записях в наборе данных за счет добавления контролируемой случайности в результаты вычислений⁷⁹ (Dwork et al., 2006, pp. 270–271).

В техническом смысле требование описывается через устойчивость вывода алгоритма к единичным изменениям исходного набора: результат должен оставаться практически одинаково вероятным как при наличии в данных одной конкретной записи, так и при ее отсутствии. Иначе говоря, для любого возможного результата вероятность его получения на двух «соседних» наборах данных (отличающихся одной записью) может различаться лишь в строго ограниченных пределах: допускается ограниченное расхождение по масштабу вероятностей и только очень малая дополнительная вероятность отклонения за пределы этого ограничения. Эта конструкция направлена на то, чтобы по наблюдаемому выходу алгоритма нельзя было надежно восстановить факт наличия конкретного субъекта в наборе данных или извлечь чувствительную информацию о нем. В европейской практике дифференциальная приватность все чаще рассматривается как мера, совместимая с принципом «защита данных по замыслу и по умолчанию» (data protection by design and by default) (ст. 25 GDPR)⁸⁰, при условии документирования выбранного механизма, обоснования отсутствия менее инвазивных альтернатив и оценки влияния добавленной случайности на качество и устойчивость модели при условии документирования выбранного механизма (описание примененной схемы, области применения и того, какие выходы алгоритма защищаются), обоснования отсутствия менее инвазивных альтернатив (сопоставление с вариантами, требующими меньшего объема персональных данных или меньшего вмешательства в обработку) и оценки влияния добавленной случайности на качество и устойчивость модели (в том числе на сохранение сопоставимой точности и долей ошибок для различных групп субъектов и на отсутствие систематически худших результатов для уязвимых или защищаемых групп, что важно для предотвращения дискриминационных исходов).

Особое место в сегодняшней дискуссии занимает федеративное обучение⁸¹. На интуитивном уровне может показаться, что сохранение данных «на месте» автоматически устраняет риски для персональных данных. Однако с точки зрения GDPR ситуация сложнее. В соответствии со ст. 4(1) GDPR персональными являются любые сведения, относящиеся к идентифицированному или идентифицируемому лицу⁸², а Европейский совет по защите данных в заключении 28/2024 подчеркивал, что даже косвенные цифровые следы могут образовывать персональные данные, если существует разумная вероятность их использования для повторной идентификации⁸³. Градиенты и обновления весов при определенных условиях могут быть инвертированы, что позволит восстановить отдельные характеристики исходных записей.

Это означает, что в федеративной архитектуре контролер не может автоматически считать градиенты безличной информацией. При наличии разумно предсказуемого риска реконструкции индивидуальных записей возникает высокая степень угрозы для прав и свобод субъектов, а значит, необходимо проводить DPIA по ст. 35 GDPR⁸⁴. В рамках такой оценки контролер должен показать, что архитектурное решение дополнено достаточными гарантиями: сокращением экстремальных градиентов, использованием защищенной агрегации⁸⁵, криптографических механизмов вроде гомоморфного шифрования⁸⁶. Эти технические меры приобретают юридическое значение, только когда описаны в DPIA, закреплены в политиках обработки и отражены в реестре операций обработки.

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

Принцип соразмерности защитных мер в регулировании обучения ИИ-моделей

Принцип соразмерности защитных мер в праве Европейского союза предполагает, что объем и характер технических и организационных мер должны соответствовать уровню риска для прав и свобод субъектов данных и серьезности возможных последствий. В сфере защиты данных он отражен прежде всего в статье 25 GDPR, закрепляющей требование защиты данных по замыслу и по умолчанию (data protection by design and by default), и в статье 32 GDPR, устанавливающей обязанность обеспечить надлежащий уровень безопасности с учетом состояния техники, стоимости внедрения, характера, объема, контекста и целей обработки⁸⁷. Иначе говоря, оператор обязан не просто применить набор мер, а обосновать, почему именно такой набор является достаточным и пропорциональным рискам.

Статья 10(2) Акта об ИИ развивает эту логику применительно к высокорисковым ИИ-системам: провайдеры обязаны не только защищать данные, но и формализовать управление обучающими наборами (data governance), документируя их происхождение, качество, репрезентативность и отсутствие систематических искажений⁸⁸. Тем самым Акт об ИИ смещает фокус с индивидуального риска (логика GDPR) на риск алгоритмического воздействия на группы и общество в целом: неправильно обученная модель может приводить к дискриминации, ошибкам в доступе к социальным услугам, кредитованию, здравоохранению (Novelli et al., 2024a, p. 8). Поэтому соразмерность здесь имеет два критерия оценки: с позиции стандарта охраны прав субъекта персональных данных (DPIA по ст. 35 GDPR)⁸⁹ и риска нарушения основных прав (FRIA) в духе Хартии ЕС об основных правах⁹⁰.

Базовым примером соразмерной меры выступает псевдонимизация согласно ст. 4(5) GDPR⁹¹. Она позволяет отделить идентификаторы (ФИО, паспортные данные, контактную информацию) от остальной части обучающего набора, сохранив возможность контролируемого восстановления личности через отдельный ключ в защищенной системе управления ключами. Однако международный стандарт ISO/IEC 27559:2022 справедливо указывает, что одной псевдонимизации недостаточно: при объединении разных наборов данных сохраняется риск фоновой деанонимизации (background re-identification), когда лицо идентифицируется путем сопоставления псевдонимизированных записей с внешними источниками⁹². Поэтому псевдонимизация рассматривается как необходимая, но не достаточная мера и должна дополняться минимизацией, укрупнением редких сочетаний и контролем доступа.

Для специальных категорий данных (ст. 9 GDPR)⁹³ и высокочувствительных обучающих наборов усиливается роль дифференциальной приватности⁹⁴. В литературе данный подход описывается как предпочтительный для случаев, когда одного обезличивания недостаточно для снижения риска выводимости сведений о субъекте (то есть когда по результатам обработки сохраняется вероятность восстановить связь с конкретным лицом либо извлечь о нем чувствительную информацию) (Arasteh et al., 2024, p. 2; Liu et al., 2024, pp. 737–738). С правовой точки зрения настройка используемого механизма и объема вносимой случайности образует вопрос соразмерности: недостаточная степень усиления защиты делает меры фактически формальными (результаты остаются статистически различимыми в зависимости от участия конкретной записи), тогда как чрезмерное усиление может существенно ухудшить качество модели (увеличить ошибку, снизить устойчивость и привести к неравномерному росту ошибок для отдельных групп субъектов, что повышает риск дискриминационных исходов). Для небольших выборок и редких случаев (например, редких заболеваний) это требует проведения отдельной процедуры оценки воздействия на защиту данных (DPIA) с фиксацией того, почему выбран именно данный способ усиления защиты и каким образом оценено его влияние на точность, устойчивость и потенциальные дискриминационные эффекты.

Следующий слой соразмерных мер связан с классическими средствами информационной безопасности: контролем доступа, ролевыми моделями и шифрованием. Принцип наименьших привилегий (least privilege) предполагает, что разработчик, дата-сайентист или администратор получают доступ только к тем данным, которые им действительно необходимы для выполнения задачи (Menges et al., 2021, p. 2). Статья 32(1) GDPR прямо называет среди мер шифрование⁹⁵, обеспечивающее защиту от несанкционированного доступа как при компрометации инфраструктуры, так и при перехвате трафика⁹⁶. Для высокорисковых систем добавляются аппаратные технологии, например безопасные анклавы⁹⁷. Они особенно актуальны для медицинских, биометрических и иных чувствительных сценариев, где компрометация обучающего контура приводит к необратимому ущербу (Novelli et al., 2024a, p. 7; Novelli et al., 2024b, pp. 5–6; Basdekis et al., 2023, p. 2)⁹⁸.

Отдельный класс архитектурных мер соразмерности связан с сокращением объема передаваемых данных за счет изменения самого процесса обучения. Федеративное и раздельное обучение⁹⁹ часто позиционируется как решение проблем конфиденциальности (Haripriya et al., 2025, pp. 10–11; Pham et al., 2023, pp. 988–989). Однако с точки зрения GDPR и Акта об ИИ эти архитектуры не снимают обязанность по оценке рисков, а лишь смещают ее в другую плоскость. Как показывают исследования по инверсии градиентов (gradient inversion), при недостаточно защищенной агрегации обновлений возможно восстановление исходных признаков. Следовательно, градиенты и обновления весов должны рассматриваться как потенциальные персональные данные, а применение федеративного обучения — сопровождаться DPIA и, при высокорисковых сценариях, FRIA. Соразмерный набор мер в этом контексте включает обрезку экстремальных градиентов, протоколы защищенной агрегации, исключающей анализ обновлений по отдельным клиентам, а при необходимости — криптографические механизмы, включая гомоморфное шифрование.

В практическом управлении рисками выбор сочетания мер не может быть произвольным. Организации, работающие с высокорисковыми ИИ-системами, выстраивают многоуровневую модель анализа угроз, опираясь на четыре базовых параметра: тип и чувствительность данных, масштаб и критичность проекта, профиль потенциального нарушителя и экономическую оправданность мер. Если обрабатываются специальные категории данных в крупных массивах, риск априори оценивается как высокий, что влечет обязанность проведения DPIA (ст. 35 GDPR)¹⁰⁰ и зачастую FRIA, а также применения нескольких уровней защиты одновременно: от псевдонимизации и строгого разграничения доступа до дифференциальной приватности, защищенной агрегации и аппаратных анклавов. Для обезличенных или низкочувствительных наборов достаточно базового шифрования и ролевой модели доступа при условии, что сохранен риск-ориентированный подход.

При иных подходах эта логика институционализируется через формальные рамки управления рисками. Документы из системы актов NIST IR (NIST Incident Response), включая IR 8286C, хотя и потеряли официальный статус, демонстрируют полезную методологию: угрозы сводятся в единый реестр, каждой присваивается уровень риска, а меры защиты привязываются одновременно к бизнес-целям и нормативным требованиям¹⁰¹. В европейском контексте аналогичную функцию начинает выполнять ISO/IEC 42001:2023 — стандарт системы управления ИИ, встраивающий риск-ориентированное мышление (risk-based thinking) и непрерывное улучшение в процессы разработки и эксплуатации ИИ¹⁰². В результате принцип соразмерности перестает быть абстрактным и превращается в управленческую практику: риск идентифицируется, оценивается и «закрывается» документированным набором мер.

Для упорядочения применения защитных средств организации, работающие с обучением моделей, как правило, формируют два слоя документации. Первый — матрица рисков, в которой категориям риска (низкий, средний, высокий) соответствуют обязательные комбинации технических и организационных мер: от псевдонимизации и базового шифрования до дифференциальной приватности, защищенной агрегации и использования аппаратных анклавов. Второй — специализированная процедура оценки рисков обучения моделей (training DPIA), где устанавливаются критерии запуска оценки, пороговые значения для высокого риска, роли участников и взаимосвязь между DPIA, FRIA и требованиями Акта об ИИ к управлению данными.

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

Комплаенс по жизненному циклу ИИ-модели

Жизненный цикл крупной ИИ-модели (large-scale AI model), т. е. программной системы, использующей методы машинного обучения и имеющей параметрический масштаб не ниже миллиардного порядка, включает несколько ключевых этапов, каждый из которых имеет самостоятельное правовое значение.

Прежде всего определяются цель и сфера применения модели. По сути, речь идет о формулировании задачи, ради которой создается или адаптируется ИИ-система: к примеру, анализ медицинских изображений, обработка естественного языка, кредитный скоринг, прогнозирование финансовых рисков и т. п. В юридической плоскости это соответствует установлению цели обработки персональных данных в смысле ст. 5(1)(b) GDPR¹⁰³: диагностические, образовательные, управленческие, сервисные или иные задачи, подлежащие последующему документированию в политике обработки и оценке воздействия (с позиций DPIA, FRIA и Акта об ИИ).

На следующем этапе разработчик выбирает архитектурный подход: использовать уже существующую модель (дообучение имеющейся архитектуры нейронной сети или иной модели) либо проектировать и обучать модель с нуля¹⁰⁴. От этого решения зависят состав данных, объем вычислений и набор юридических рисков: при дообучении неизбежно встает вопрос о повторной обработке ранее собранных персональных данных, при обучении с нуля — о правомерности изначального сбора и масштабах выборки.

Далее следует этап сбора и подготовки обучающих данных¹⁰⁵. На этой стадии формируются обучающие выборки данных, которые будут использованы для настройки параметров модели. На практике это означает агрегирование объемных массивов данных из открытых источников, публичных реестров, ведомственных систем или коммерчески приобретенных баз. Подготовка включает очистку¹⁰⁶, аннотацию¹⁰⁷ и структурирование данных в формат, пригодный для обучения (Wang et al., 2021, pp. 776–778).

После этого наступает собственно этап обучения модели (training). В типичном сценарии он включает предобучение¹⁰⁸ и последующую тонкую настройку (fine-tuning). В ходе обучения применяются методы оптимизации¹⁰⁹ и механизмы, предполагающие участие человека, позволяющие достигать требуемой точности и управляемости поведения модели.

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

Завершающий технический этап — развертывание /внедрение модели (deployment) в эксплуатационную среду. С этого момента модель начинает использоваться в реальных бизнес- или управленческих процессах, и на разработчика/оператора ложится обязанность по непрерывному мониторингу и периодической переоценке¹¹¹ ее качества, рисков и соответствия нормативным требованиям (Wang et al., 2021, p. 781; De Silva & Alahakoon, 2022, pp. 3–4 ).

Формулируя цель обучения ИИ-модели, необходимо соблюдать принцип ее ограничения (purpose limitation). Согласно ст. 5(1)(b) GDPR персональные данные должны «собираться для конкретных, явных и законных целей и не подлежат дальнейшей обработке иным образом, несовместимым с этими целями»¹¹². Это означает, что цель обучения должна быть заранее определена, описана в документации и связана с конкретными результатами модели; изменение цели впоследствии требует либо нового согласия субъектов персональных данных, либо иного правового основания.

Акт об ИИ дополняет эту конструкцию понятием «предназначенная цель»¹¹³, т. е. учетом условий, контекста и предсказуемых сценариев применения. Для высокорисковых ИИ-систем законодатель прямо требует описывать и принимать к сведению все известные и разумно предсказуемые сценарии использования и злоупотребления. В соответствии со ст. 9 Акта об ИИ провайдер обязан включить предназначенную цель в систему управления рисками (risk management system), а любое ее изменение влечет повторную оценку рисков и при необходимости корректировку архитектуры и процессов обучения¹¹⁴.

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

Сбор данных для обучения должен опираться на одно из оснований, предусмотренных статьей 6(1) GDPR: согласие субъекта (consent), исполнение договора (performance of a contract), выполнение юридической обязанности (legal obligation), защита жизненно важных интересов (vital interests), выполнение задачи в общественных интересах или при осуществлении публичных полномочий (public task), а также законный интерес оператора (legitimate interest), если он не перевешивается правами и свободами субъекта¹¹⁵. Например, если обучение модели связано с задачами устойчивого развития или общественного здравоохранения, это может квалифицироваться как выполнение задачи в общественных интересах по ст. 6(1)(e) GDPR¹¹⁶.

Если данные были ранее собраны для иной цели, применяется статья 6(4) GDPR, предписывающая проверку совместимости целей (compatibility test): анализируются связь между первоначальной и новой целями, контекст сбора, характер данных (обычные или специальные категории), возможные последствия для субъектов и предусмотренные меры защиты¹¹⁷. Пункт 67 преамбулы к Акту об ИИ подчеркивает необходимость прозрачности относительно исходной цели сбора и последующих трансформаций¹¹⁸.

Принцип минимизации данных (ст. 5(1)(c) GDPR) требует, чтобы собирались только те персональные данные, которые действительно необходимы для достижения заявленных целей¹¹⁹. В то же время статья 10 Акта об ИИ устанавливает требование репрезентативности обучающих данных, т. е. их сбалансированности и отражения ключевых характеристик целевой популяции (например, половозрастной структуры, этнического состава, географического распределения)¹²⁰. На первый взгляд это приводит к противоречию: минимизация предполагает сокращение объема данных, а репрезентативность — расширение набора для отражения разнообразия. Однако в современной доктрине эти категории разводятся: минимизация понимается как отбор только релевантных признаков и исключение избыточной информации, тогда как репрезентативность — как баланс и непредвзятость внутри уже минимизированного множества данных. В практическом измерении это означает, в частности, возможность использовать анонимизированные или синтетические данные для увеличения разнообразия без нарушения принципа минимизации (van Bekkum, 2025, p. 7).

На этапе сбора данных статья 13 GDPR обязывает информировать субъектов персональных данных о ключевых параметрах обработки: целях использования данных, правовых основаниях, сроках хранения, получателях, а также о правах субъекта (право на доступ, исправление, удаление, ограничение обработки и др.)¹²¹. Это информационная основа прозрачности, без которой любая последующая работа с данными для обучения ИИ-модели будет юридически уязвимой.

Акт об ИИ дополняет эти требования концепцией практик управления данными¹²². В статье 10(2) Акта об ИИ провайдеру высокорисковой ИИ-системы вменяется в обязанность документировать происхождение данных¹²³, исходную цель их сбора, примененные методы очистки (data cleaning) и разметки (data labelling / annotation). В технической документации (приложение III к Акту об ИИ¹²⁴) должны быть отражены используемые датасеты, процедуры подготовки и проверки, что позволяет контролирующим органам оценить как качество, так и правомерность подготовки обучающего массива.

Требование ст. 5(1)(c) GDPR о минимизации данных в контексте обучения ИИ-моделей означает обязанность оператора (controller) обосновать выбор каждого вида данных¹²⁵. Оператор должен продемонстрировать, почему именно такой набор признаков необходим для достижения заявленной цели и что объем данных соотносится с критерием необходимости, а не с техническим удобством по принципу «чем больше, тем лучше».

С другой стороны, статья 10(3) Акта об ИИ вводит критерий репрезентативности и достоверности обучающих и валидационных данных (representativeness and accuracy): используемые наборы должны адекватно отражать целевую популяцию, исключать систематические ошибки и обеспечивать статистическую пригодность модели. Здесь проявляется различие в логике требований: репрезентативность предполагает широкий охват и разнообразие данных, а минимизация — их сокращение. Правовой подход позволяет согласовать эти требования: оператор фиксирует в документации (отчетах по результатам DPIA; технических отчетах по Акту об ИИ), что объем данных минимален с точки зрения прав субъекта, но достаточен для статистической устойчивости и недискриминации. Баланс достигается, в частности, через исключение явно нерелевантных признаков; укрупнение и агрегирование чувствительных данных; использование анонимизации и синтетической генерации для расширения выборки без увеличения объема персональных данных (Laato et al., 2022, p. 4).

Сам процесс обучения моделей в праве ЕС рассматривается как непрерывная обработка персональных данных (continuous processing). Это означает, что на обучение целиком распространяются базовые принципы и права согласно GDPR: законность обработки (lawfulness) (ст. 6)¹²⁶; целевое ограничение и минимизация (purpose limitation и data minimisation) (ст. 5)¹²⁷, обеспечение безопасности (security of processing) (ст. 32)¹²⁸, а также специальные правила профилирования и автоматизированного принятия решений (profiling and automated decision-making) (ст. 22)¹²⁹. Если итоговая модель используется для принятия решений, затрагивающих права субъектов (например, отказ в кредите, приеме на работу, доступе к услуге), возникает дополнительная обязанность информировать о логике и последствиях обработки (ст. 13 и 22 GDPR)¹³⁰ и обеспечивать возможность человеческого вмешательства (human intervention).

Статья 9 Акта об ИИ дополняет эту конструкцию требованием к системному управлению рисками¹³¹. Оно должно носить постоянный, цикличный и документированный характер и охватывать весь жизненный цикл ИИ-системы: от проектирования и обучения до эксплуатации и пострыночного мониторинга. Особый акцент делается на рисках дискриминации и смещения данных. Уже на стадии проектирования и обучения провайдер обязан выявлять такие риски и принимать меры по их снижению¹³².

С этой целью статья 11 Акта об ИИ¹³³ и приложение III к нему¹³⁴ закрепляют обязанность вести подробную техническую документацию, где фиксируются архитектура системы, используемые датасеты, критерии отбора данных, процессы очистки и проверки, протоколы тестирования, методы предотвращения предвзятости и результаты оценок. Такая документация частично пересекается по функциям с реестрами операций обработки по ст. 30 GDPR¹³⁵, что позволяет выстраивать единую систему комплаенса: одна часть записей ориентирована на надзор по линии защиты данных, другая — на контроль соответствия Акту об ИИ.

Принцип защиты данных по замыслу и по умолчанию (ст. 25 GDPR) требует от провайдера искусственного интеллекта внедрять технические и организационные меры еще на стадии обучения: шифрование (защиту данных криптографическими методами), псевдонимизацию (замену идентификаторов токенами), дифференциальную приватность (контролируемое внесение «шума», исключающего выделение человека в наборе данных), а также процедуры «машинного разучивания» (целенаправленное исключение определенных данных из обученной модели)¹³⁶. Эти меры должны быть соразмерны риску и увязаны с требованиями статьи 32 GDPR, предписывающей учитывать состояние техники, стоимость внедрения, характер, объем и контекст обработки¹³⁷.

Акт об ИИ не вступает с этой логикой в противоречие, а усиливает ее: статья 10(2)(f), (g) прямо указывает на необходимость проверки обучающих данных на отсутствие незаконной предвзятости и несоответствующих смещений¹³⁸, а также на согласование таких проверок с принципами и пунктами преамбулы GDPR, включая п. 67 о прозрачности и поддержании актуальности данных¹³⁹.

Особое значение имеет статья 10(5) Акта об ИИ, допускающая использование специальных категорий данных (чувствительные данные о здоровье, биометрии, убеждениях и т. п.) для устранения смещений в обучении¹⁴⁰. Формально это вступает в противоречие со статьей 9 GDPR, устанавливающей общий запрет на обработку таких данных¹⁴¹. Однако Акт об ИИ вводит конкретные условия в смысле статьи 10(5)(a), (b), (e): отсутствие менее инвазивной альтернативы, применение усиленных мер псевдонимизации и других методов защиты, удаление данных сразу после выполнения корректирующей задачи. С правовой точки зрения данную норму следует рассматривать как узкое исключение, которое допустимо только при одновременном выполнении условий ст. 9(2), (4) GDPR¹⁴² и документальном обосновании в DPIA и технической документации. Это означает, что привлечение чувствительных признаков допустимо исключительно в режиме минимально необходимого вмешательства и под постоянным контролем регулятора и внутренних органов комплаенса.

Наконец, доказательства соблюдения указанных норм формируются в единой системе документации. GDPR требует ведения реестров операций обработки (ст. 30)¹⁴³, регистрации инцидентов и уведомлений (ст. 33–34)¹⁴⁴, DPIA и сопутствующих отчетов. Акт об ИИ предписывает хранить протоколы тестов, логи качества, отчеты об оценке рисков и техническое досье¹⁴⁵. В совокупности эти документы составляют корпус доказательств законности и прозрачности обучения. На практике оправдан подход, при котором техническая документация по Акту об ИИ интегрируется с документами по GDPR (политиками обработки, DPIA, реестрами операций), образуя сквозную систему отчетности и повышая доверие к ИИ-системе со стороны регуляторов, партнеров и пользователей.

При валидации (тестировании) модели GDPR продолжает действовать в полном объеме. Если валидационные и тестовые наборы содержат персональные данные, их обработка должна опираться на правовое основание (согласие, договор, законный интерес и т. д.) и соответствовать принципам минимизации и целевого ограничения. На этой стадии особенно важна оценка рисков дискриминации: в соответствии со ст. 13(2)(f) GDPR контролер обязан заранее информировать субъектов о возможных последствиях автоматизированного прогнозирования и рисках для их прав и свобод¹⁴⁶.

Статья 10(2), (3) Акта об ИИ предписывает, чтобы валидационные наборы обладали теми же качественными характеристиками, что и обучающие: релевантностью (связь с задачей), репрезентативностью и способностью обеспечивать проверку точности и устойчивости модели¹⁴⁷. Это означает, что тестирование должно быть спроектировано, чтобы выявлять смещения и ошибки, а результаты должны фиксироваться в отчетах и логах для целей надзора, аудита и подтверждения соответствия как Акту об ИИ, так и GDPR.

На этапе внедрения ИИ-модели в эксплуатацию юридические обязанности оператора и провайдера существенно ужесточаются. Если модель используется для принятия решений, затрагивающих права и законные интересы физических лиц, применяется статья 22 GDPR об автоматизированном принятии решений, предусматривающая право субъекта на вмешательство (пересмотр решения человеком), оспаривание решения и получение объяснений относительно логики обработки¹⁴⁸. Эти требования корреспондируют со статьей 14 Акта об ИИ, закрепляющей принцип человеческого надзора (human oversight)¹⁴⁹, а также со статьей 13 GDPR, устанавливающей обязанность информировать о целях обработки, логике принятия решений и возможных последствиях для субъектов данных¹⁵⁰.

В этом контексте особое значение приобретает концепция так называемого пакета прозрачности¹⁵¹. Под ним в практике применения Акта об ИИ понимается передача по всей цепочке внедрения и эксплуатации исчерпывающего набора материалов: руководств пользователя, технического описания, отчетов о тестировании, ограничений применимости, условий корректного использования и сценариев, при которых система может создавать повышенные риски. Пункт 27 преамбулы к Акту об ИИ подчеркивает, что все лица, участвующие в проектировании, интеграции и эксплуатации системы, должны быть осведомлены о ее характеристиках, возможностях и рисках¹⁵². В свою очередь GDPR в ст. 12–14 дополняет это требованием прозрачности в отношении обработки персональных данных и доступности информации для субъектов, включая сведения об их правах, основаниях обработки и механизмах их реализации¹⁵³.

Мониторинг после внедрения (post-market monitoring) закреплен в обоих нормативных актах. Статьи 33–34 GDPR обязывают контролера сообщать о нарушениях безопасности персональных данных в надзорный орган и при необходимости информировать субъектов данных¹⁵⁴, а также обеспечивать реализацию права на стирание (right to erasure) (ст. 17 GDPR)¹⁵⁵. Статьи 61–62 Акта об ИИ, в свою очередь, требуют от провайдера регистрировать серьезные инциденты, поддерживать систему пострыночного мониторинга и фиксировать результаты в технической документации¹⁵⁶. Формируется правовая симметрия: обе системы регулирования исходят из обязанности постоянного контроля, регулярной корректировки и документированного подтверждения соответствия.

Отдельный проблемный блок связан с принципом целевого ограничения (purpose limitation). В соответствии со ст. 5(1)(b) GDPR персональные данные могут использоваться только для конкретных, заранее определенных и законных целей и не подлежат дальнейшей обработке способом, несовместимым с этими целями¹⁵⁷. Логика коммерческого использования ИИ-моделей, напротив, предполагает расширение сфер применения: модель, изначально обученная для одной задачи (например, внутреннего риск-анализа), впоследствии адаптируется для иных функций или встраивается в новые бизнес-процессы. Такое расширение цели¹⁵⁸ очевидно противоречит конструкции целевого ограничения.

Для частичного разрешения этой коллизии европейское право предусматривает специальный режим исследовательской дерогации (research derogation). Статья 89 GDPR допускает использование персональных данных в научных и исследовательских целях при условии дополнительных гарантий: псевдонимизации, ограничения доступа, строгого документирования исследовательских целей и процедур¹⁵⁹. Пункт 159 преамбулы к GDPR прямо относит обучение и тестирование алгоритмов к сфере научного и технологического развития, при этом подчеркивая, что такой режим допустим, пока результаты не используются в отношении конкретных субъектов в контексте оказания услуг или принятия решений¹⁶⁰. На этой стадии первична именно исследовательская цель, а не коммерческая эксплуатация.

Статья 2 Акта об ИИ ограничивает сферу действия регламента системами, которые размещаются на рынке или вводятся в эксплуатацию (placing on the market / putting into service)¹⁶¹. Соответственно, сугубо исследовательский этап разработки и внутреннего тестирования ИИ-моделей, когда система не предлагается на рынке и не используется для принятия решений в отношении внешних пользователей, напрямую не подпадает под действие Акта об ИИ и регулируется исключительно GDPR. На этом этапе применим режим исследовательской дерогации, несколько смягчающий требования при условии строгих дополнительных гарантий (ограничение доступа, псевдонимизация, минимизация и т.д.).

Ситуация принципиально меняется в момент вывода модели на рынок¹⁶² или ее ввода в эксплуатацию во внешнем контуре. С этого момента для разработчика/провайдера возникает комплекс новых обязательств.

Во-первых, необходимо пересмотреть правовое основание обработки данных в соответствии со ст. 6 GDPR¹⁶³. Если на исследовательском этапе обработка опиралась на исключение для научных целей (research basis) (в сочетании со ст. 89 GDPR)¹⁶⁴, то при коммерческом использовании требуется иное основание: согласие субъекта (consent) (ст. 6(1)(a)), необходимость обработки для исполнения договора с субъектом данных (или принятия мер до заключения договора по его запросу) (performance of a contract) (ст. 6(1)(b))¹⁶⁵, выполнение юридической обязанности, публичный интерес или законный интерес оператора (legitimate interests) (ст. 6(1)(f)) при выполнении теста баланса интересов¹⁶⁶.

Во-вторых, в силу ст. 27 Акта об ИИ и приложения IV к нему разработчик/провайдер обязан обновить описание целей эксплуатации, областей применения и ограничений системы и зафиксировать их в нормативной и технической документации¹⁶⁷. Эти сведения становятся частью паспорта ИИ-системы, ее технической документации, которая должна включать описание предназначенной цели, целевой среды, категорий пользователей, ограничений и ключевых рисков.

В-третьих, обязательной становится повторная оценка воздействия на защиту данных (обновленная DPIA по ст. 35 GDPR)¹⁶⁸. Переход от исследовательского режима к коммерческой эксплуатации изменяет характер обработки, масштаб воздействия и зачастую категории субъектов. Контролер обязан пересмотреть перечень рисков, обновить перечень мер защиты и зафиксировать измененный уровень остаточного риска.

В-четвертых, при наличии серьезных рисков для фундаментальных прав и свобод (по Хартии ЕС об основных правах¹⁶⁹) возникает необходимость проведения отдельной оценки воздействия на основные права (FRIA). Она проводится как дополнение к DPIA применительно к высокорисковым ИИ-системам, подпадающим под приложение III к AI Act (Mantelero, 2024, p. 17; Malgieri & Santos, 2025, p. 69).

В результате формируется двухступенчатая модель регулирования обучения и использования ИИ-моделей. На стадии разработки и внутреннего тестирования действует исследовательский режим согласно GDPR (п. 159 преамбулы и ст. 89)¹⁷⁰, допускающий дерогацию при условии дополнительных гарантий и отсутствия внешнего воздействия на субъектов. С момента вывода продукта на рынок или ввода в эксплуатацию активируется полный комплекс обязательств одновременно по GDPR и Акту об ИИ. Фактический момент вывода системы на рынок становится юридической точкой отсчета смены режима: именно с этого времени разработчик обязан пересмотреть правовые основания обработки, обновить техническую и правовую документацию, встроить систему пострыночного мониторинга, усилить меры защиты данных и прав субъектов и при необходимости провести как DPIA, так и FRIA.

Заключение

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

С учетом выявленных противоречий и разнонаправленных регуляторных векторов предлагается прикладная модель поведения разработчиков и операторов, построенная по логике «R&D → Market» («от исследовательской стадии к стадии рыночного внедрения»). Суть модели состоит в том, что обучение рассматривается как самостоятельный юридически значимый процесс в рамках общего жизненного цикла ИИ-системы, для которого устанавливается порог перехода от исследовательской дерогации по ст. 89 GDPR к полному режиму Акта об ИИ. Такая конструкция не претендует на единственно возможное решение: в доктрине обсуждаются и более жесткие подходы, исходящие из необходимости изначально применять к обучающим процедурам весь комплекс требований Акта об ИИ, и, напротив, более мягкие позиции, фактически сводящие регулирование обучения к общим нормам о научной обработке данных. Предлагаемая модель занимает промежуточную позицию, увязывая момент вывода системы на рынок с усилением регуляторного режима и формализацией обязанностей по обоим актам.

В рамках данной модели разработчик (или связка «разработчик — провайдер») выстраивает документационную и организационную структуру, включающую определение и фиксацию цели обработки и правового основания (ст. 5, 6 GDPR); правовую и техническую экспертизу обучающих выборок (data governance в смысле ст. 10 Акта об ИИ); предпочтительное использование анонимизированных, агрегированных и синтетических данных там, где это допустимо без ущерба для статистического качества; проведение оценки воздействия на защиту данных (DPIA) в случаях высокого риска (ст. 35 GDPR); ведение внутренней отчетности и журналов операций; соблюдение требований прослеживаемости, устойчивости и подотчетности, закрепленных в Акте об ИИ, включая техническую документацию и протоколы тестирования. С практической точки зрения эта модель превращает набор разрозненных обязанностей в последовательную дорожную карту для корпоративного комплаенса, но одновременно повышает нагрузку на субъекты, лишенные зрелых процедур управления рисками, что уже сегодня является предметом критики со стороны представителей малого и среднего бизнеса.

Значение модели «R&D → Market» состоит в том, что она предлагает операционализированную схему согласованного применения двух параллельных режимов: горизонтальных требований GDPR к обработке персональных данных и вертикальных требований Акта об ИИ к высокорисковым ИИ-системам. При надлежащей имплементации такая схема позволяет не только формально соблюдать ст. 5, 6, 9, 25, 30, 35 GDPR и ст. 10, 11, 69 Акта об ИИ, но и выстраивать доказуемую линию поведения на случай регуляторного запроса или судебного спора. Вместе с тем остается открытым вопрос о стандартизации подобных моделей: пока речь идет о доктринальной конструкции, а не о закрепленном регулятором эталоне, от компаний требуется самостоятельная адаптация предложенного подхода к отраслевым и национальным особенностям.

Отдельным элементом предлагаемой модели выступает тест невозможности альтернативы при работе со специальными категориями данных, используемыми для устранения смещений в обучении (ст. 10(5) Акта об ИИ в сочетании со ст. 9 GDPR). Содержание теста сводится к необходимости документально обосновать, что привлечение чувствительных признаков (например, этнической принадлежности или состояния здоровья) является единственно необходимым и пропорциональным способом достижения заявленной исследовательской или эксплуатационной цели и что сопоставимого уровня недискриминации или точности нельзя достичь путем использования синтетических, анонимизированных или менее инвазивных данных. Такой подход отражает более рестриктивное прочтение ст. 10(5) Акта об ИИ, ограничивающее сферу применения исключения, и тем самым снижает риск признания обработки несоразмерной при проверке надзорным органом или судом.

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