Суверенное облако не решит проблемы с ИИ-рисками. Это сделает управление идентификацией

Ваш совет директоров спрашивает. Ваш юридический отдел спрашивает. Ваши аудиторы будут спрашивать: следует ли переносить рабочие нагрузки ИИ в суверенное облако или оставить их на AWS, Azure или GCP? Европейские предприятия уже провели этот эксперимент — под реальным регуляторным давлением, с реальными деньгами и реальными последствиями. Многие обнаружили, что одно только суверенное облако не обеспечило ожидаемого контроля. Настоящая точка контроля оказалась совершенно в другом месте.

Европа провела этот эксперимент первой, под регуляторным давлением, которое американские предприятия только начинают ощущать. Поскольку DORA полностью вступил в силу с января 2025 года, введение в действие NIS2 продолжается во всех странах — членах ЕС, а положения ЕС об ИИ в отношении систем высокого риска вступают в силу в августе 2026 года, европейские предприятия — особенно в сфере финансовых услуг, критической инфраструктуры и производства — потратили два года на миграцию рабочих нагрузок, пересмотр контрактов и включение суверенного облака в системы управления рисками на уровне совета директоров. Гиперскейлеры отреагировали. AWS запустила свое Европейское суверенное облако в январе 2026 года. Microsoft и Google последовали их примеру, предложив собственные решения для обеспечения суверенитета. Рынок сформировался.

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

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

Программа конференции сделала этот сдвиг видимым. Если предыдущие годы были сосредоточены на архитектуре суверенного облака и выборе поставщика, то трендовыми темами программы 2026 года — как было отмечено на заключительном заседании — стали безопасность ИИ, структура идентификации (identity fabric), управление идентификаторами рабочих нагрузок и криптографическая гибкость. Суверенное облако стало предполагаемой инфраструктурой. Разговор практиков сместился к тому, что вы строите поверх него, и кто контролирует этот уровень.

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

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

Вопрос контроля, на который никто не дает четкого ответа

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

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

Это не гипотетические опасения. Закон CLOUD Act 2018 года дает властям США возможность обязывать американские компании предоставлять данные, хранящиеся за границей, независимо от того, где находятся серверы. Европейские предложения по суверенному облаку от американских гиперскейлеров структурированы для решения этой проблемы — посредством операционного разделения, европейских юридических лиц и ключей, управляемых клиентом, — но эти структуры новы, частично проверены и значительно различаются у разных поставщиков.

BSI Германии поднял ставки еще выше. В апреле 2026 года агентство опубликовало свои Критерии, обеспечивающие автономию облачных вычислений (C3A): первая структура, которая операционализирует, что на самом деле означает облачный суверенитет в технических терминах, включая сценарии отключения, требования к резидентности персонала и специальное положение о федеральном переходе управления облачными операциями в оборонных сценариях. Формально необязательные, эти критерии, как ожидается, станут де-факто эталоном для немецких федеральных закупок — и вероятным шаблоном для общеевропейских рамок, находящихся сейчас в законодательном процессе. Для американских CISO направление движения очевидно: регуляторные определения облачного суверенитета ужесточаются, и разрыв между «данными в Европе» и «операционно суверенными» будет только увеличиваться.

Идентификация — вот где на самом деле живет суверенитет

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

Джейсон Кинаган, руководитель стратегии управления идентификацией в Thales, сформулировал это прямо: «Идентификация смещается из функции ИТ в регулируемую инфраструктуру. Самым важным вопросом на следующее десятилетие будет: кто контролирует?»

Для американского CISO этот сдвиг очень реален: управление идентификацией переходит от чистого ИТ-обеспечения к регулируемой поверхности контроля, которую аудиторы, регуляторы и даже корпоративные клиенты в запросах предложений (RFP) будут все чаще проверять. Вопрос «кто контролирует» больше не является философским. Он контрактный.

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

Это особенно остро проявляется в рабочих нагрузках ИИ. Агентные системы ИИ — модели, которые действуют автономно, совершают вызовы API, выделяют ресурсы, получают доступ к данным — создают новую категорию нечеловеческих идентификаторов, которыми большинство систем управления доступом и идентификацией (IAM) предприятий никогда не предназначались для управления. Рассмотрим конкретный пример, который я видел в средах клиентов: агент развертывания на основе LLM с постоянным доступом к производственным кластерам Kubernetes. Он планирует рабочие нагрузки, выделяет ресурсы и автономно принимает решения о доступе. Если этот агент работает на инфраструктуре суверенного облака, но его идентификация — его учетные данные, его разрешения, его аудиторский след — не управляется должным образом, ваша позиция в отношении суверенитета сильна ровно настолько, насколько слабое звено в цепочке доступа этого агента. Если вы сегодня используете аналогичные агенты в облачных регионах США, те же слепые зоны в отношении идентификации существуют — даже если вы никогда не касаетесь региона суверенного облака.

Себастьян Рор, консультант по IAM и член IDPro, который два десятилетия занимался архитектурой корпоративных идентификаций, сформулировал требования к управлению ИИ-агентами на практике: «Каждому агенту должна быть назначена нечеловеческая идентификация. Должна быть создана надежная модель делегирования от имени. Требуется аудиторский след через интеграцию с SIEM. Никаких долгоживущих учетных данных, никаких ключей API — только эфемерные учетные данные. Аутентификация на основе контекста и гранулярный контроль доступа. Агенты должны управляться как реальные идентификации. И как только этот фундамент заложен: риск-ориентированная, непрерывная повторная аутентификация в сочетании с возможностью отзыва в реальном времени. Есть ли у нас все эти возможности везде сегодня? Не обязательно — но спроектировать архитектуру для этого? Это вполне возможно».

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

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

Когда суверенное облако того стоит — а когда нет

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

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

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

• Суверенное облако не означает, что гиперскейлер не может видеть ваши метаданные. Ключи, управляемые клиентом, защищают данные в состоянии покоя. Они не мешают платформе регистрировать шаблоны доступа, вызовы API и потребление ресурсов. Узнайте, что регистрирует ваш поставщик и куда идут эти журналы. Для американских CISO: это важно для любого гиперскейлера, работающего в соответствии с иностранными требованиями по локализации данных, с которыми вы можете столкнуться по мере развития нормативно-правовой базы.
• Ранние предложения суверенного облака имели реальные пробелы в обслуживании — и выход из них сложнее, чем ожидалось. Многие передовые сервисы ИИ/МО были недоступны на момент запуска; предприятия, которые рано приняли обязательства, в итоге использовали гибридные архитектуры, более сложные, чем предполагалось. И привязка в контексте суверенного облака труднее преодолима, чем в стандартном облаке. Включайте стратегию выхода в решения о закупках до подписания контракта.
• Управление идентификацией нельзя откладывать. Предприятия, получившие наибольшую выгоду от инвестиций в суверенное облако, уже выполнили работу по управлению идентификацией — инвентаризация активов, классификация доступа, управление нечеловеческими идентификаторами. Для американских CISO, сталкивающихся с аналогичными требованиями к управлению ИИ и устойчивости: это урок, который будет наиболее болезненным, если вы не выполнили эту работу.
• Суверенитет от гиперскейлера отличается от суверенитета от европейского провайдера. AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty и Google Sovereign Cloud структурно отличаются от предложений, созданных IONOS, Hetzner, OVHcloud или Deutsche Telekom. Первые предлагают более широкие каталоги услуг с наложенными элементами управления суверенитетом. Вторые предлагают более чистые юридические структуры с более узкими наборами функций. Ни один из вариантов не является универсально лучшим — и выбор должен следовать характеристикам рабочей нагрузки, а не предпочтениям при закупке.

Что американским CISO следует сделать сейчас

Если ваша организация имеет операции в ЕС, дочерние компании или клиентов — или рабочие нагрузки ИИ, достаточно чувствительные, чтобы направление регулирования в США имело значение — это решения, с которыми вы столкнетесь. Три конкретных шага.

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

2. Проведите аудит своей позиции в области управления идентификацией до разработки облачной стратегии. Суверенное облако без зрелости IAM — это дорого и недостаточно. Управление должно происходить на уровне идентификации, а не на границе дата-центра.

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

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

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

Эта статья публикуется в рамках сети экспертных авторов Foundry.
Хотите присоединиться?