Как законы США, Китая и ЕС меняют глобальные правила для IT-бизнеса

Зарубежные требования меняются быстрее, чем их успевают анализировать. Я не считаю, что задача российского IT не в том, чтобы копировать европейские или китайские стандарты. Задача в другом: видеть, куда движется регулирование, чтобы не оказаться заложником чужой архитектуры решений. США, Европа и Китай сейчас строят несовместимые между собой цифровые экосистемы, и каждая из них предъявляет свои требования к тем, кто хочет работать внутри или рядом. https://seberd.ru/5955

Три нормативных блока задают направление цифрового законодательства для остального мира. Их методы расходятся кардинально, но давление на IT-рынок одинаково реальное. Для российских компаний прямое следование иностранным законам невозможно в большинстве случаев по санкционным причинам, а понимание логики этих законов критически важно. Оно позволяет оценивать жизнеспособность используемых решений в перспективе трёх-пяти лет, прогнозировать изменения в 152-ФЗ и требованиях ФСТЭК, строить архитектуру, которая не потребует полного переписывания при новом витке ограничений.


ЕС: давление через антимонополию, а не только через данные

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

Digital Markets Act: ограничения для «привратников»

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

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

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

Digital Services Act: ответственность платформ за контент

DSA работает иначе. Его объект не рыночная конкуренция, а то, что происходит с пользователями на онлайн-площадках. Закон вводит градацию по размеру: маленький хостинг, крупная платформа, очень крупная платформа (Very Large Online Platform, VLOP). Чем больше сервис, тем жёстче требования.

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

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


Китай: данные как государственный ресурс

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

Data Security Law: иерархия по степени важности

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

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

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

PIPL: локальная версия GDPR с другим знаком

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

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

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

Что из этого важно для российского контекста

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

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


США: регулирование через контроль цепочек поставок

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

Entity List и SDN List: административное давление

Министерство торговли США ведёт Entity List, реестр организаций, с которыми американским компаниям запрещено торговать без специальной лицензии. Министерство финансов параллельно параллельно ведёт SDN List (Specially Designated Nationals) с более широкими ограничениями.

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

Для российских разработчиков это означает конкретные операционные риски. Доступ к инструментам вроде JetBrains IDE, системам управления зависимостями npm и PyPI, облачным сервисам для CI/CD. Всё это теоретически может быть ограничено или уже ограничено. Степень реального применения ограничений варьируется, но вектор очевиден.

Экспортный контроль ПО: размытая граница

Отдельный пласт составляет регулирование через Export Administration Regulations (EAR). Запрет распространяется не только на прямую поставку американских технологий, но и на их использование при производстве товаров, которые в итоге окажутся у ограниченных организаций. Применительно к полупроводникам и hardware действует так называемое «правило 25 процентов», для ПО аналогичная логика работает через контроль за реэкспортом через третьи страны.

Открытый исходный код занимает отдельную позицию. Правовой статус open-source-проектов, в создании которых участвовали американские разработчики или организации, остаётся размытым. Технически большинство открытых проектов под лицензиями MIT, Apache или BSD не подпадает под экспортный контроль. Но если проект содержит криптографические компоненты или изначально финансировался американскими структурами, картина меняется. Юридическая неопределённость сама по себе создаёт риски для коммерческих применений.

CHIPS Act и IRA: долгосрочное изменение рынка

CHIPS and Science Act и Inflation Reduction Act работают не как запреты, а как финансовые стимулы для возвращения производства в США и дружественные страны. CHIPS выделяет десятки миллиардов долларов на строительство полупроводниковых фабрик внутри страны. Цель состоит в сокращении зависимости от тайваньских и корейских заводов, одновременно ограничив возможности Китая получать доступ к передовым технологиям производства чипов.

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


Три системы с разной логикой

Если упрощать, то разница между тремя подходами сводится к одному вопросу: кому принадлежат данные и кто несёт ответственность за их использование?

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

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

Американский ответ менее монолитен. Внутри страны действует пёстрый набор штатных законов (самый известный из них CCPA в Калифорнии), без единого федерального стандарта по защите данных. Вовне США работают через экспортный контроль и санкции, формируя глобальные цепочки поставок по принципу «с кем ты работаешь».

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


Что это означает практически

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

Технологический стек как регуляторная карта рисков. Каждый компонент в стеке разработки можно оценить с точки зрения юрисдикции происхождения и вероятности изменения условий доступа. Библиотека на GitHub под MIT-лицензией с американскими мейнтейнерами несёт один уровень риска. Проприетарный SDK облачного провайдера несёт другой. Постепенная миграция критических зависимостей на компоненты с рассредоточенным международным сообществом или отечественные аналоги снижает вероятность одномоментного разрыва.

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

Диалог с регуляторами требует конкретного языка. Знание того, как именно устроен DSA или PIPL, позволяет вести предметный разговор с Роскомнадзором и ФСТЭК. Предлагать адаптированные механизмы аудита алгоритмов или категоризации данных гораздо продуктивнее, чем ждать, пока регулятор сам сформулирует требования, опираясь на зарубежные образцы в буквальном прочтении.

Сценарное планирование. Три сценария, которые стоит проработать для любого IT-проекта с горизонтом больше двух лет: полный запрет доступа к конкретной облачной платформе, введение в России требований по аудиту алгоритмов в стиле DSA, ужесточение требований по локализации данных до китайского уровня. Для каждого из них список критических действий составляется заранее. Что переносить, что сертифицировать, каких поставщиков искать. Когда сценарий реализуется, ответ будет готов, а не придётся принимать решения под давлением.


Нюансы, которые обычно упускают

Есть несколько моментов, которые в стандартных обзорах законодательства не появляются.

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

Второй: американский CHIPS Act содержит так называемые guardrails, то есть условия получения субсидий, которые запрещают компаниям-получателям расширять производство в Китае на срок десять лет. Крупнейшие производители чипов де-факто вынуждены выбирать между американскими субсидиями и китайским рынком. Побочный эффект состоит в том, что глобальный рынок полупроводников структурно разделится на два сегмента с разными технологическими стандартами быстрее, чем это произошло бы без субсидий.

Третий: в Китае действует параллельная система сертификации для иностранного ПО под названием Multi-Level Protection Scheme (MLPS). Без сертификата по MLPS иностранный продукт не может использоваться в государственных и критических системах. Фактически это инструмент технологического протекционизма, который выглядит как стандарт безопасности. Российские требования ФСТЭК по сертификации работают по схожей логике, и совпадение здесь неслучайное.


Чек-лист аудита технологических зависимостей

Для практической работы с рисками, которые описаны выше, полезна структурированная проверка. Не всё применимо для каждого проекта, но отправная точка одна.

Инвентаризация стека:

  • [√] Составлен список всех внешних зависимостей с указанием страны происхождения и типа лицензии
  • [√] Выделены компоненты с американским или европейским происхождением, критичные для работы продукта
  • [ ] Для каждой критической зависимости определён альтернатива или план миграции
  • [ ] Проверено, нет ли в цепочке CI/CD облачных сервисов, доступ к которым может быть ограничен

Архитектура данных:

  • [√] Определены категории данных по степени чувствительности
  • [ ] Реализована возможность изоляции данных по юрисдикциям без полного переписывания
  • [ ] Проверено соответствие архитектуры требованиям 152-ФЗ по локализации персональных данных граждан РФ
  • [x] Хранение данных в зарубежной инфраструктуре без понимания регуляторных последствий

Регуляторный горизонт:

  • [ ] Определены три сценария изменения регулирования и список действий для каждого
  • [ ] Проведён анализ потенциальных требований ФСТЭК для проектов в области КИИ
  • [ ] Налажен мониторинг изменений в Entity List и SDN List для используемых вендоров

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

Оставьте комментарий