Что ИИ-агенту разрешено делать самому: национальные правила Китая
- Джимшер Челидзе
- 2 дня назад
- 9 мин. чтения
Обновлено: 2 часа назад
Перед тем как отдать процесс ИИ-агенту, руководитель задаёт один и тот же вопрос: что эта штука сделает сама, а где остановится и спросит человека. Пока рынок отвечает на него по-разному в каждом продукте, Китай ответил на уровне национального документа.
8 мая 2026 года три ведомства — Управление по вопросам киберпространства, Госкомитет по развитию и реформам и Министерство промышленности и информатизации — опубликовали «Мнения о нормативном применении и инновационном развитии интеллектуальных агентов». Это первый в стране сводный документ, посвящённый целиком агентам, и вышел он на два с половиной месяца раньше пекинских десяти мер, которые мы разбирали отдельно.
Разница между двумя документами принципиальная. Пекин отвечает на вопрос, на чём агентская экономика зарабатывает. Этот документ отвечает на вопрос, что агенту вообще позволено, — и именно поэтому он полезнее тому, кто прямо сейчас решает, куда пускать агента в своей компании. Оба документа опираются на план «ИИ+» Госсовета КНР, который мы разбирали ранее.
Определение, с которого стоит начать
Документ открывается определением, и оно точнее большинства маркетинговых: интеллектуальный агент — система, обладающая способностями автономного восприятия, памяти, принятия решений, взаимодействия и исполнения.
Пять способностей, и все пять обязательны. Это удобный фильтр для разговора с поставщиком. Если у решения нет памяти между сессиями — это чат-бот с подключёнными инструментами. Если нет исполнения — аналитическая надстройка. Если нет автономного принятия решений — сценарный робот с ветвлениями. Каждая из этих вещей может быть полезной, но продавать их как агента некорректно, и теперь есть на что сослаться.
Четыре базовых принципа тоже стоит прочитать буквально: безопасность и контролируемость как нижняя граница на всём цикле разработки и эксплуатации; нормативность и упорядоченность; инновационный драйв; тяга со стороны применений — с прямой оговоркой «сначала простое, потом сложное, последовательно». Последнее — редкая для программных документов честность о темпе.
Главное: три категории решений
Шестой пункт — тот, ради которого документ стоит держать под рукой. Он требует разграничить полномочия агента на три категории.
Решения, которые принимает только сам пользователь. Агент не имеет права их совершать ни при каких настройках.
Решения, требующие авторизации пользователя. Агент подготавливает, человек подтверждает.
Решения, которые агент принимает автономно. В пределах явно выданных полномочий.
И два условия, которые важнее самой классификации. Первое: пользователь сохраняет право на информированность и окончательное решение при автономных действиях агента. Второе: исполнение агента не должно выходить за пределы выданной пользователем авторизации.

Звучит очевидно ровно до момента, когда вы попробуете описать это для конкретного процесса в своей компании. «Согласовать платёж до 50 тысяч» — какая это категория? А «отправить письмо клиенту от имени руководителя»? А «закрыть задачу в системе»? Практическая ценность документа в том, что он заставляет провести границу явно, до внедрения, а не после первого инцидента.
Рядом стоит седьмой пункт — про контроль поведения. Предписано развивать технологии встроенных правил и поведенческих ограждений, обеспечивающих законность действий агента в публичных, приватных и специальных пространствах. А для важных сценариев — исследовать применение блокчейна, чтобы поведение агента было верифицируемым и прослеживаемым.
Фундамент: чего требуют от технологий
Перечень общих технологий во втором разделе совпадает с тем, что практики называют узкими местами: понимание задачи, планирование задачи, использование инструментов, долговременная память, взаимное распознавание и связность агентов, групповая координация. Отдельно — инструментальная цепочка: базовые фреймворки, компоненты восприятия, памяти, решений, взаимодействия и исполнения, средства разработки, тестирования, развёртывания и эксплуатации.
И к ним — инструменты безопасности: обнаружение состязательных примеров и аномального поведения, а также способность обнаружить, вмешаться, заблокировать и восстановить при некорректных действиях агента.
Эта четвёрка глаголов — готовый чек-лист к любому пилоту. Если на вопрос «что произойдёт, когда агент начнёт делать не то» у поставщика нет ответа по всем четырём пунктам, пилот преждевременен.

Умный интернет и паспорт агента
Самая дальняя по горизонту часть документа и, возможно, самая интересная стратегически. Предписано исследовать архитектуру «умного интернета» и создать платформу регистрации агентов: управление цифровой идентичностью, поиск и обнаружение, декларация возможностей. Плюс справочная информация о разработчике, способе развёртывания, протоколах интерфейсов и комплаенс-сертификации. Для мультиагентного взаимодействия — идентификация, доверенная связность, комплаентные платежи, защита и разрешение конфликтов.
Проще говоря: у агента появляется паспорт, реестр и объявленный набор умений, а у других агентов — способ его найти, проверить и заплатить ему.
Если такая конструкция состоится, поменяется точка входа к клиенту. Сегодня продукт борется за место в магазине приложений. В этой конструкции он борется за то, чтобы его нашёл и подключил чужой агент. Здесь же стоит и продвижение протокола межагентного взаимодействия как ключевого национального стандарта — тот же протокол, который позже упомянут в пекинских мерах.
Управление по уровням риска
Одиннадцатый пункт вводит классификационно-уровневую систему управления — по сценарию применения и потенциальному влиянию.
Для чувствительных областей и ключевых отраслей сценарии открываются регулятором совместно с отраслевыми ведомствами, а к продуктам применяются регистрация, тестирование и отзыв проблемных продуктов с рынка.
Для низкорисковых областей — быт, развлечения, повседневная офисная работа — предусмотрен облегчённый режим: инструменты самопроверки на соответствие, информационная отчётность, управление через платформы дистрибуции и отраслевое саморегулирование.
Логика та же, что позже повторит Пекин: категоризация работает не только как ограничение, но и как ускоритель. Низкий риск — быстрый выпуск, высокий — строгая проверка. Обязательные стандарты предписано разрабатывать точечно: медицина, транспорт, медиа, общественная безопасность.
Дополняют картину два механизма. Первый — третьесторонняя оценка функций, производительности, качества и соответствия, с взаимным признанием результатов сертификации, плюс регулярный отчёт о зрелости технологий и применений. Второй — добровольный механизм репутационной оценки участников рынка: за злоупотребление технологиями, склонение к покупке, ложную рекламу и сокрытие информации о дефектах предусмотрены оценка и последующие ограничения.
Потребительские риски, о которых мало кто пишет
Пятый пункт выделяется на фоне остальных, потому что говорит не о технике, а о человеке. Документ прямо запрещает использовать преимущество в данных и технологии очеловечивания для навязывания нежелательных ценностей и алгоритмического выжимания пользователя. И отдельно требует предотвращать риски зависимости и эмоциональной привязанности у несовершеннолетних и пожилых людей.
Это стоит прочитать не как чужую регуляторную специфику, а как раннее предупреждение. Персональный ассистент, который накапливает знание о человеке, по построению обладает и данными, и антропоморфностью. Разница между полезным инструментом и механизмом удержания проходит не по технологии, а по продуктовым решениям — что система делает, когда пользователь начинает обращаться к ней слишком часто.
Девятнадцать сценариев: где государство ждёт результата
Четвёртый раздел перечисляет типовые сценарии по пяти направлениям. Полезен не как список задач, а как карта того, где ожидается спрос.
Наука и промышленность: ассистенты разработки полного цикла, связка агентов с системами проектирования и инженерных расчётов, автоматизация цикла эксперимента; оптимизация производственного расписания, контроль точности обработки и выявление дефектов, связка со станками и промышленными роботами; экологический мониторинг, диспетчеризация электроэнергии, надзор на транспорте, агротехническая диагностика; финансовый риск-контроль — кредитные решения, мониторинг транзакций, противодействие отмыванию.
Потребление, благосостояние и социальное управление: выполнение задач между приложениями и устройствами, круглосуточное обслуживание клиентов, воплощённые агенты в общепите, рознице и логистике, низкозатратные услуги ухода; генерация учебных материалов и персональные образовательные траектории, анализ медицинских изображений и диагностическое рассуждение, сервисы занятости; вспомогательное согласование в госуслугах с переходом от модели «человек ищет услугу» к модели «услуга находит человека», юридическая помощь, городское планирование, сопровождение закупочных процедур.
Как это выглядит изнутри: наш опыт в «Соколе»
Мы строим «Сокол» — персональную ИИ-операционную систему для руководителей (директор, заместители директора) и собственников малого и среднего бизнеса. Шестой и седьмой пункты этого документа описывают ровно те решения, которые пришлось принять самим, до того как документ появился.
Права агента заданы матрицей. Ни один агент не обращается к базе данных напрямую — только через программный слой. По умолчанию действует чтение. Запись возможна лишь по явному разрешению и через черновик, который подтверждает человек. Удаление запрещено полностью. Каждое обращение пишется в неизменяемый журнал. Если наложить это на три категории документа, соответствие получается почти буквальным: чтение — автономная зона, запись — зона авторизации, а всё, что меняет обязательства компании, закрыто для агента навсегда.

Задачи разведены между несколькими агентами, у каждого своя зона, свой набор доступных данных и своя проверка результата. Причина не в архитектурной эстетике: чем длиннее цепочка автономных шагов, тем ниже шанс дойти до конца без ошибки и тем шире зона, в которой ошибку никто не поймает.
Модель — сменный компонент. Никакой бизнес-логики, привязанной к конкретной передовой модели, обязательный слой изоляции от поставщика. То же требование читается в пункте о безопасности цепочки поставок: управление подключением моделей, вызовами интерфейсов и внешними инструментами — отдельная зона ответственности, а не деталь реализации.
Устойчивость пользователя — ограничитель, а не цель продукта. Пятый пункт про эмоциональную привязанность и алгоритмическое давление — ровно та развилка, которую персональный ассистент проходит на этапе проектирования. В системе заложен слой, который отслеживает перегруз и защищает личное время руководителя, а не наращивает вовлечённость любой ценой. Метрика вовлечённости для такого продукта — плохая метрика: она конфликтует с задачей, ради которой продукт покупают.
Честная разница: платформы регистрации агентов, цифровой идентичности и взаимного признания сертификатов у нас нет и не появится сама. Всё, что документ отдаёт государственной инфраструктуре, продуктовому бизнесу придётся либо строить самому, либо ждать, пока такую инфраструктуру построит кто-то ещё.
Сильные стороны документа
1. Определение агента дано и работает. Пять способностей — рабочий фильтр против маркетинга.
2. Полномочия решений разделены на три категории. Самая практичная конструкция во всём корпусе китайских документов по ИИ: её можно взять и применить к своему процессу за один рабочий день.
3. Право пользователя на окончательное решение зафиксировано. Не как декларация, а как ограничение исполнения: агент не выходит за пределы выданной авторизации.
4. Управление дифференцировано по риску. Тяжёлый режим — точечно, лёгкий — по умолчанию. Это не душит эксперименты.
5. Названа четвёрка требований к сбою: обнаружить, вмешаться, заблокировать, восстановить.
6. Учтены риски для человека, а не только для системы. Зависимость, эмоциональная привязанность, алгоритмическое давление — темы, которых в большинстве регуляторных документов нет вовсе.
7. Сценарии перечислены конкретно. Девятнадцать направлений — карта ожидаемого спроса, а не список благих намерений.
Слабые места и открытые вопросы
1. Кто проводит границу между категориями решений — не сказано. Разграничить полномочия предписано, но кто определяет, к какой категории относится конкретное действие: поставщик, заказчик или регулятор? От ответа зависит, кто отвечает за неверную классификацию.
2. Ответственность за ущерб не распределена. Документ подробно описывает, чего агент делать не должен, но не отвечает, кто платит, когда он это всё же сделал: поставщик агента, владелец модели, заказчик или разработчик подключённого инструмента.
3. Регистрационная платформа описана как исследование. Цифровая идентичность агентов, декларация возможностей, взаимное признание — всё в статусе «изучить и построить», без сроков и без указания оператора.
4. Репутационный механизм добровольный. Тот, кто злоупотребляет, с высокой вероятностью просто в нём не участвует.
5. Требование соответствия мейнстримным ценностям неопределимо технически. Для разработчика это означает необходимость модерации, границы которой заданы вне продукта и могут меняться.
6. Экономики нет вовсе. Кто за что платит, как считать эффективность и что считать выполненной задачей — этих вопросов документ не касается. Их частично закроют пекинские меры через два с половиной месяца.
7. Индикаторы оценки только предстоит создать. Система показателей развития агентов упомянута в заключительном разделе как задача. То есть измерять результат самого документа пока нечем.
Что с этим делать руководителю
1. Проведите границу полномочий до внедрения, а не после. Возьмите процесс, который собираетесь отдать агенту, и разложите все действия на три категории: только человек, с подтверждением человека, автономно. Это упражнение на час, и оно снимает большую часть будущих споров.
И одно уточнение, без которого упражнение легко провести формально. Уровень автономности агента — на каком он «этаже», от ассистента до мультиагентной системы — и объём его полномочий это две разные шкалы, а путают их постоянно. Первая говорит, сколько шагов агент делает без человека. Вторая — что ему вообще позволено решать. Компания, у которой «всего лишь ассистент», может при этом дать ему право менять обязательства перед клиентом, и это опаснее, чем куда более автономный агент в режиме только чтения. Сам по себе уровень автономности почти ничего не говорит о риске: риск задаётся полномочиями.

2. Проверьте поставщика по определению из пяти способностей. Восприятие, память, решения, взаимодействие, исполнение. Чего нет — то и не агент, каким бы ни было название в презентации.
3. Спросите про четыре глагола. Как система обнаруживает некорректное действие, как в него вмешивается, как блокирует и как восстанавливает состояние. Отсутствие внятного ответа хотя бы по одному пункту — стоп для пилота.
4. По умолчанию ограничивайте права. Чтение свободно, запись через подтверждение человека, удаление никогда. Плюс журнал действий. Это дёшево на старте и почти невозможно достроить потом.
5. Начинайте с низкорисковой зоны. Логика документа применима и без регулятора: там, где ошибка обратима и видна, эксперимент идёт быстро; там, где нет, — сначала проверка.
6. Проверьте свой продукт на вовлечённость. Если вы делаете что-то, что накапливает знание о пользователе, задайте себе вопрос из пятого пункта: ваша система помогает человеку меньше в неё возвращаться или больше? Ответ определяет, на какой стороне будущего регулирования вы окажетесь.
7. Следите за паспортами агентов. Если реестры и декларации возможностей станут нормой, точка входа к клиенту сместится с магазина приложений к чужому агенту. Готовность быть найденным — архитектурное решение, которое принимается заранее.
И правило переноса. Механика не переносится по результату. Три категории решений, дифференциация по риску и четвёрка требований к сбою работают в любой юрисдикции, потому что описывают свойства технологии. Реестры, обязательные стандарты и репутационные механизмы опираются на административный ресурс, которого в другой стране может не быть.
Заключение
Из трех китайских документов по ИИ, которые мы разбирали, этот — самый применимый на практике. План «ИИ+» задаёт цели на десять лет, пекинские меры описывают экономику агентов, а этот отвечает на вопрос, который руководитель задаёт первым: что агент сделает сам, а где остановится и спросит.
Ответ, который стоит забрать независимо от юрисдикции: граница полномочий агента — не техническая настройка, а управленческое решение. Его нельзя делегировать разработчику и нельзя отложить до инцидента. Если вы не провели эту границу сами, её проведёт за вас поставщик — исходя из своего удобства, а не вашего риска.
Вопрос к вам. Возьмите один процесс, который вы уже отдали или собираетесь отдать ИИ. Какие действия в нём агент выполняет полностью самостоятельно — и подписались бы вы под каждым из них лично? Будем рады вашим примерам в комментариях.
Источники: полный текст «Мнений», сообщение об издании и ответы на вопросы журналистов на сайте Управления по вопросам киберпространства КНР.
Материал подготовлен с использованием технологий искусственного интеллекта.

