Аналитическая записка № 8 — Три архитектуры централизации

Аналитическая записка № 8 · Серия: Governance Briefs · Июнь 2026
Операционализирует: Эссе 11 — The Institutional Gap
Beyond Control: Theory of Limits of AI Governance
English · Русская версия

Содержание

I. Архитектура управления, окружающая централизованный узел

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

Это разграничение необходимо установить до начала анализа. Платёжные системы выступают наблюдаемыми прецедентами: они задокументированы, урегулированы и в ряде случаев уже произвели измеримые институциональные последствия. Они предоставляют то, чего AI governance (управление искусственным интеллектом) пока предложить не может — завершённую историческую запись. Техническая логика централизации — единый узел, агрегирующий потоки данных, управляющий идентификаторами, обрабатывающий транзакции и осуществляющий мониторинг поведения в режиме реального времени — та же логика, которая сегодня встраивается в AI-системы принятия решений в кредитовании, здравоохранении, государственном управлении и регуляторном надзоре. Платёжные кейсы — не аналогии того, с чем сталкивается AI governance. Это более ранние проявления той же структурной проблемы, продвинувшиеся дальше по той же институциональной временно́й линии.

Единица анализа — не централизация как таковая. Единица анализа — архитектура управления, окружающая централизованный узел.

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

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

Диагностический протокол

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

  1. Где расположен технический центр системы?
  2. Кто контролирует доступ к этому центру?
  3. Кто принимает критические операционные решения?
  4. Кто несёт ответственность при сбое системы?
  5. Где расположена единая точка отказа?
  6. Какие механизмы надзора существуют — и являются ли они структурно независимыми?
  7. Какие механизмы правоприменения существуют — и могут ли они действовать без согласия надзируемого субъекта?
  8. Какой профиль институционального риска формируется на основе этой совокупности?

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

Одно структурное наблюдение применимо ко всем трём кейсам ещё до начала анализа. Учредительные документы — постановления, нормативные акты, технические стандарты — описывают функциональную архитектуру. Они определяют, кто что делает, при каких условиях, с какими обязательствами по отчётности. Они, как правило, не определяют, что происходит, когда система функционирует именно так, как спроектирована, — но в направлении, которое документ не предусмотрел. Разрыв между проектной функцией и непредусмотренным последствием — не изъян юридической техники. Это структурная особенность любого регуляторного инструмента, применяемого к динамической системе. Архитектура управления, окружающая централизованный узел, проверяется не в режиме штатной работы, а в тот момент, когда система производит исход, которого никто не планировал.

Именно в этот момент архитектура управления либо сдерживает последствия сбоя, либо обнаруживает, что никакой подобной архитектуры не существует.

II. Architecture A — Designed Centralisation: Узбекистан

25 марта 2026 года Правление Центрального банка Узбекистана приняло Постановление № 5/11, утвердившее правила оказания платёжных услуг через единую систему QR-кодов. Документ зарегистрирован Министерством юстиции 15 апреля 2026 года под регистрационным номером 3817. Заявленные цели документа однозначны: стандартизация форматов QR-платежей, обеспечение интероперабельности между провайдерами, сокращение теневой экономики, расширение охвата безналичных расчётов. Это обоснованные цели, и технический инструмент, разработанный для их достижения, обладает внутренней логической связностью.

Архитектура, которую создаёт этот документ, и является предметом анализа данного раздела.

Применение диагностического протокола

1. Где расположен технический центр системы?

Оператор. Документ определяет Оператора как юридическое лицо, которое создаёт систему QR-кодов и управляет ею, обеспечивает её бесперебойное функционирование и формирует клиринговые данные по всем QR-транзакциям. Статья 7 устанавливает, что Оператор ведёт единый реестр всех статических и динамических QR-идентификаторов страны. Статья 6 устанавливает, что Оператор осуществляет мониторинг всего транзакционного потока в режиме реального времени и доводит расчётную информацию до всех участников — также в режиме реального времени или не позднее операционного дня проведения расчётов.

Оператор — не один из участников системы наравне с прочими. Оператор — это инфраструктура, посредством которой функционируют все остальные участники.

2. Кто контролирует доступ к этому центру?

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

3. Кто принимает критические операционные решения?

Оператор определяет технические стандарты, устанавливает тарифные структуры (по согласованию с участниками), управляет МСС-кодами торговых точек через эквайерный слой, реализует протоколы обеспечения непрерывности работы и формирует клиринговые данные, лежащие в основе всех расчётов. Статья 11 устанавливает обязательство по уведомлению: Оператор информирует Центральный банк об изменениях в технической документации не позднее чем за пятнадцать рабочих дней до их вступления в силу. Сложившийся режим — это уведомление, а не предварительное согласование. Центральный банк получает информацию об изменениях. В документе не предусмотрен механизм, посредством которого Центральный банк мог бы предотвратить, скорректировать или независимо проверить эти изменения до их вступления в силу.

4. Кто несёт ответственность при сбое системы?

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

5. Где расположена единая точка отказа?

Реестр Оператора. Каждый QR-идентификатор в стране проходит регистрацию в едином реестре, который ведёт Оператор. Каждый расчёт проводится через клиринговые данные, формируемые Оператором. Сбой на этом уровне — технический, операционный или регуляторный — не затронет одного эквайера или один платёжный коридор. Он одновременно затронет всю QR-платёжную инфраструктуру.

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

6. Какие механизмы надзора существуют — и являются ли они структурно независимыми?

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

Документ сам по себе не устанавливает роль регулятора в сфере персональных данных в архитектуре управления QR-системой. Остаётся ли поведенческие данные транзакций в сфере действующего регулирования персональных данных — это самостоятельный правовой вопрос. Для настоящей Записки важно другое: никакой независимой надзорной роли в учредительной архитектуре не предусмотрено.

7. Какие механизмы правоприменения существуют — и могут ли они действовать без согласия надзируемого субъекта?

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

8. Какой профиль институционального риска формируется?

Architecture A — Designed Centralisation (Спроектированная централизация) — производит специфический и идентифицируемый профиль риска. Концентрация технических функций, доступа к данным и операционных решений в рамках единого субъекта является архитектурно предусмотренной, а не случайной. Система работает в соответствии с замыслом. Архитектура управления, окружающая этот замысел, содержит структурный разрыв: независимая верификация — того, как используется единый реестр, как осуществляется доступ к поведенческому датасету и какие решения принимаются на основе мониторинга в режиме реального времени — не закреплена в учредительном документе.

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

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

Architecture A оставляет этот вопрос за пределами архитектуры управления, установленной учредительным документом.

III. Architecture B — Emergent Centralisation (концентрация, возникающая как результат взаимодействия участников системы, а не единого проектного решения): Индия (UPI)

Единая платёжная система Индии (UPI) была спроектирована как открытая инфраструктура. Национальная платёжная корпорация Индии (NPCI) — некоммерческая организация, создавшая UPI и управляющая ею, — построила технически интероперабельную архитектуру: любой лицензированный банк или поставщик платёжных услуг мог подключиться, любое потребительское приложение могло работать на этой платформе. Исходная логика носила дистрибутивный характер — вовлечь сотни миллионов граждан, лишённых или ограниченных в доступе к банковским услугам, в формальную платёжную систему, устранив барьеры, которые создают проприетарные сети.

В течение нескольких лет UPI охватила сотни миллионов пользователей. Технический результат был подлинным и существенным.

А затем архитектура произвела нечто, что её создатели не предусматривали.

Применение диагностического протокола

1. Где расположен технический центр системы?

NPCI управляет центральным коммутатором — инфраструктурным уровнем, через который маршрутизируются, аутентифицируются и исполняются все транзакции UPI. NPCI спроектировала уровень над коммутатором как открытый: банки-участники подключаются напрямую, платёжные приложения конкурируют за пользователей, ни одно приложение не получает привилегий на техническом уровне. Технический центр существует. Архитектура была разработана таким образом, чтобы предотвратить концентрацию над ним.

2. Кто контролирует доступ к этому центру?

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

3. Кто принимает критические операционные решения?

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

4. Кто несёт ответственность при сбое системы?

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

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

5. Где расположена единая точка отказа?

Техническая единая точка отказа — коммутатор NPCI — видна в учредительной архитектуре и подпадает под стандартные требования к устойчивости инфраструктуры. Однако к тому моменту, когда UPI достигла масштаба, выше технического уровня и за пределами учредительной архитектуры сформировалась иная единая точка отказа. Два платёжных приложения стали обрабатывать значительную долю объёма транзакций UPI. Концентрация произошла не на том инфраструктурном уровне, который спроектировала NPCI. Она произошла на уровне приложений — в результате рыночной динамики, которую ни один учредительный документ не регулировал.

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

6. Какие механизмы надзора существуют — и являются ли они структурно независимыми?

Резервный банк Индии осуществляет надзор за NPCI. NPCI структурирована как некоммерческая организация с банковским участием — иная архитектура подотчётности по сравнению с Architecture A, где центральный оператор поднадзорен институту, его же назначившему. Надзорные отношения РБИ и NPCI построены на дистанции.

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

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

Надзорный разрыв в Architecture B структурно отличается от Architecture A. В Architecture A разрыв существует потому, что учредительный документ не назначает независимый надзор за специально обозначенным центральным оператором. В Architecture B разрыв существует потому, что субъекты, аккумулировавшие наиболее значимые данные, не являлись теми субъектами, которых учредительная архитектура была разработана регулировать.

7. Какие механизмы правоприменения существуют — и могут ли они действовать без согласия надзируемого субъекта?

РБИ располагает полномочиями в отношении NPCI и лицензированных банков. Стандартные регуляторные инструменты — проверки, лицензионные условия, предписания об устранении нарушений — применимы. Эти механизмы в принципе функционируют независимо от надзируемых субъектов.

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

8. Какой профиль институционального риска формируется?

Architecture B — Emergent Centralisation (Непредусмотренная централизация - концентрация, возникающая как результат взаимодействия участников системы, а не единого проектного решения) — производит профиль риска со структурной характеристикой, отличающей её от Architecture A: нет учреждающего документа, который можно пересмотреть, нет назначенного оператора, которого можно привлечь к ответственности, нет единого проектного решения, породившего концентрацию. Риск возник из взаимодействия между открытой технической архитектурой и рыночной динамикой, которую учредительная архитектура не была разработана регулировать.

Выявление разрыва в Architecture A указывает на идентифицируемые структуры управления. Выявление разрыва в Architecture B указывает на рыночный исход. Это иной вид институциональной задачи — и та, к которой механизмы правоприменения учредительной архитектуры не были адаптированы.

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

IV. Architecture C — Governed Centralisation: Бразилия (Pix)

Бразильская система Pix была запущена Banco Central do Brasil в ноябре 2020 года со структурной особенностью, которая отличает её от обеих предшествующих архитектур ещё до первой проведённой транзакции. Центральный банк не назначил оператора для управления системой. Центральный банк сам стал оператором. Pix принадлежит BCB, построена и эксплуатируется им напрямую — решение, которое снимает одну управленческую проблему и порождает другую.

Решение: нет назначенного субъекта, деятельность которого требует независимого надзора. Регулятор и оператор — одно и то же учреждение.

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

Применение диагностического протокола

1. Где расположен технический центр системы?

Banco Central do Brasil. Инфраструктура Pix — центральный каталог, уровень клиринга и расчётов, система маршрутизации транзакций — это инфраструктура BCB, эксплуатируемая полномочиями BCB, регулируемая правилами BCB. В Architecture C BCB осуществляет одновременно роль оператора и надзорного органа. Структурный вопрос здесь не в том, осуществляется ли надзор за оператором. Структурный вопрос в том, какой институциональный механизм регулирует BCB в роли оператора — и является ли этот механизм функционально независимым от BCB в роли регулятора.

2. Кто контролирует доступ к этому центру?

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

3. Кто принимает критические операционные решения?

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

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

4. Кто несёт ответственность при сбое системы?

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

5. Где расположена единая точка отказа?

Инфраструктура Pix, эксплуатируемая BCB. BCB существенно инвестировал в операционную устойчивость, и система функционирует в масштабе без крупных сбоев. Единая точка отказа существует, как в Architecture A и B. Отличие состоит в том, что BCB как оператор и надзорный орган обладает прямыми полномочиями для установления и обеспечения соблюдения собственных стандартов устойчивости, не направляя их на проверку в отдельный орган.

6. Какие механизмы надзора существуют — и являются ли они структурно независимыми?

Именно здесь Architecture C наиболее чётко расходится с Architecture A и B и где аналитически проявляется частичный характер институционализации её системы управления.

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

Определяющая черта Architecture C — не отсутствие концентрации. Её определяет предвидение концентрации и частичная институционализация ответа до того, как концентрация становится управленческим кризисом.

BCB поднадзорен Национальному конгрессу Бразилии и действует в рамках конституционной системы независимости центрального банка. Парламентский надзор существует. Судебный контроль существует. Гражданские организации и академические институты участвовали в обсуждении вопросов управления данными Pix, формируя публичную документальную базу. Эти механизмы создают дополнительные институциональные площадки, на которых управленческие вопросы могут ставиться, оспариваться и пересматриваться. Их наличие не разрешает вопрос. Оно меняет характер вопроса.

7. Какие механизмы правоприменения существуют — и могут ли они действовать без согласия надзируемого субъекта?

BCB может применять меры к участникам без их согласия — стандартные регуляторные полномочия. Что остаётся структурно неразрешённым — это правоприменение в отношении самого BCB в роли оператора. Парламентский надзор и судебный контроль теоретически обеспечивают внешние механизмы. Вопрос в том, откалиброваны ли эти механизмы для технических и операционных решений, принимаемых на инфраструктурном уровне, — а не для решений в области денежно-кредитной политики или финансовой стабильности. Инструменты подотчётности разрабатывались применительно к BCB как регулятору. Их применение к BCB как оператору крупнейшей платёжной сети Латинской Америки формировалось итеративно, а не было предусмотрено изначально.

8. Какой профиль институционального риска формируется?

Architecture C — Governed Centralisation (Управляемая централизация) — производит профиль риска, определяемый конкретным структурным условием: концентрация предвидена, названа и частично адресована. Не разрешена. Частично институционализирована.

Architecture C демонстрирует: спроектированная централизация на операторском уровне не обязательно воспроизводит тот же управленческий разрыв, что Architecture A, при условии, что институт предвидит разрыв и своевременно выстраивает параллельное управление. Что Architecture C также демонстрирует: предвидение и частичная институционализация — это не то же самое, что разрешение. BCB управляет рамочными условиями, в которых функционирует BCB. Эта цикличность структурна, а не случайна — и является характерным риском Architecture C, отличным от характерных рисков A и B.

V. Сравнительная типология и мост к AI governance

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

Платёжные системы предоставляют то, чего AI governance пока предложить не может. Институциональные исходы наблюдаемы. Временны́е линии задокументированы. Разрывы между учредительной архитектурой и операционной реальностью уже произвели измеримые результаты. Этот задокументированный опыт — не аналогия того, с чем сталкивается AI governance. Это более раннее проявление той же структурной проблемы, продвинувшееся дальше по той же институциональной временно́й линии.

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

Сравнительная типология

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

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

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

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

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

Мост

Те же три архитектуры всё отчётливее наблюдаются в AI governance. Платёжные кейсы предоставляют завершённый документальный материал. AI-кейсы находятся раньше на той же институциональной временно́й линии. Вопрос не в том, какая архитектура лучше. Вопрос в том, какую архитектуру выстраивает каждая юрисдикция — и что накопленный опыт платёжных систем говорит о том, к чему ведёт каждая из позиций.

Designed Centralisation наблюдается везде, где суверенной властью создаётся единый национальный AI-оператор без структурно независимого механизма верификации. Архитектурная логика идентична Architecture A: назначенный субъект управляет центральной функцией, назначивший орган обеспечивает надзор, и притязание на управление опирается на добросовестность надзируемого субъекта, а не на механизмы, способные действовать независимо от него. Учредительные документы этих систем описывают функциональную архитектуру. Они не описывают, что происходит, когда притязание на управление нуждается во внешней верификации.

Emergent Centralisation — это возникшее состояние, которое уже характеризует глобальный ландшафт разработки AI. Ни одна система управления не проектировала концентрацию возможностей frontier AI (передовые системы искусственного интеллекта) в двух-трёх лабораториях. Она возникла из взаимодействия доступности капитала, доступа к вычислительным ресурсам, концентрации кадров и скорости развёртывания — сил, действовавших выше технического уровня, который был призван регулировать любой из существующих нормативных фреймворков. К тому моменту, когда создавались основные регуляторные усилия, регулируемый ими ландшафт уже сконцентрировался способами, которые эти фреймворки не предусматривали. Вопрос подотчётности, который это порождает, структурно идентичен проблеме агрегаторов UPI: кто несёт ответственность за концентрацию, которую не создавал ни один учреждающий документ, и как коррекция достигает исхода, возникшего после принятия учредительного замысла?

Governed Centralisation — то, что международная инфраструктура AI-безопасности пытается выстроить с различной степенью институционального авторитета и скоростью. Создание институтов AI-безопасности, заказ многосторонних оценок безопасности, разработка фреймворков добровольных обязательств параллельно с обязывающими регуляторными инструментами — всё это представляет частичную институционализацию ответа на концентрацию, которая была предвидена и названа. Структурный риск, который раскрывает Architecture C, также присутствует здесь: институты, пытающиеся регулировать разработку AI, нередко создаются правительствами, которые одновременно реализуют конкурентное развитие AI как стратегический приоритет. Регулятор и оператор существуют в едином институциональном пространстве. Архитектура управления разрабатывается тем же суверенным аппаратом, который имеет материальный интерес в исходе, регулировать который ему предстоит.

Что документированный опыт платёжных систем добавляет к этому наблюдению — конкретное институциональное наблюдение. Architecture C сталкивается со структурными пределами, поскольку частичная институционализация и разрешённая концентрация — не одно и то же. Наличие управленческого ответа не устраняет управленческий разрыв. Оно меняет его характер. Разрыв больше не существует между концентрацией и её признанием, как в Architecture B, и не между полномочиями и верификацией, как в Architecture A. Он существует между признанием структурной проблемы и полной институционализацией ответа, способного действовать независимо от того института, который эту проблему выявил.

Что раскрывает типология

Центральный результат настоящего сравнительного анализа — не в том, что одни архитектуры безопаснее других. Он в том, что момент, в который институт признаёт концентрацию, и институциональный ответ, выстраиваемый в этот момент, определяют характер управленческого разрыва, который за этим следует. Architecture A порождает разрыв между притязанием на управление и независимой верификацией. Architecture B порождает разрыв между управленческим замыслом и рыночной реальностью. Architecture C порождает разрыв между признанной проблемой и полностью институционализированным ответом.

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

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

Architecture A не отвечает на этот вопрос. Она исходит из того, что вопроса не существует.

Architecture B не может на него ответить. Вопрос приходит после того, как архитектура уже задана.

Architecture C — единственная архитектура в данном сравнении, которая пытается задать этот вопрос до того, как управленческий разрыв становится операционально видимым. Достаточен ли ответ — покажет институциональная временна́я линия.

Источники

Первичные источники

[1] Центральный банк Узбекистана, Постановление Правления № 5/11 (25 марта 2026 г.). Правила оказания платёжных услуг через единую систему QR-кодов. Зарегистрировано Министерством юстиции Республики Узбекистан 15 апреля 2026 г., рег. номер 3817. lex.uz

[2] National Payments Corporation of India (NPCI). UPI Ecosystem: Product Overview and Governance Framework. npci.org.in

[3] Banco Central do Brasil. Pix: Institutional Framework and Operating Rules (2020–2023). bcb.gov.br

[4] Бразилия. Lei Geral de Proteção de Dados (Закон № 13.709, 14 августа 2018 г.). planalto.gov.br

Концептуальный источник

[5] Ходжаев О. Институциональный разрыв: почему ни один существующий институт не способен регулировать AI. Эссе 11 серии Beyond Control: Theory of Limits of AI Governance. okhodjaev.com/essays/the-institutional-gap/ (27 апреля 2026 г.)

Ойбек Ходжаев — более 35 лет опыта в банковском секторе, финансах, государственном управлении и бизнесе в Узбекистане и СНГ.
Автор серии эссе «Beyond Control: Theory of Limits of AI Governance.» okhodjaev.com

Автор консультирует государственные органы и финансовые организации по вопросам управления ИИ, систем верификации и институциональной готовности.

Published: