Председатель CFTC Майкл С. Селиг использовал форум 28 октября 2026 года, чтобы поднять практическую проблему автономных финансов: когда программное обеспечение выявляет возможности и совершает сделки от чьего-либо имени, на ком из людей или компаний лежит регуляторная ответственность? Его вопросы касались регистрации разработчиков, ответственности в случае некорректного поведения агента и идентификации стороны, которую он представляет. Это выступление открыло обсуждение политики; в нем не было указано, на какую конкретную сторону следует возлагать каждый убыток, связанный с ИИ.

Главное изменение — это разрешение действовать

В своем выступлении на Frontier Forum Селиг заявил, что при таком подходе следует учитывать выполняемые функции, осуществляемый контроль и экономическую сущность сделки. Он также отметил, что его взгляды не обязательно отражают позицию Комиссии. Предложенный им вопрос «знай своего агента», или KYA, не являлся объявленным режимом идентификации.

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

Таким образом, практический вопрос заключается в том, что разрешено делать системе, кто предоставляет ей эти полномочия и кто может ее остановить. Ни название модели, ни ее предполагаемый интеллект не отвечают ни на один из этих вопросов.

Регистрация и компенсация — разные вопросы

Регистрация связана с тем, подпадает ли деятельность человека или компании под определенную регуляторную категорию. Компенсация связана с тем, имеет ли кто-либо законное требование о возмещении убытка и к кому оно может быть предъявлено. Вопрос о регистрации сам по себе не определяет требование о возмещении ущерба; равно как и убыточная сделка не доказывает неправомерное поведение.

Рассмотрим гипотетическую ситуацию: пользователь разрешает совершить ордер максимум на 1 000 долларов, но агент отправляет ордер на 10 000 долларов. В ходе расследования потребуется восстановить инструкции, заданные ограничения, сообщения об ордерах и исполнение. Ограничение вообще не было реализовано, его изменил оператор, оно было обойдено из-за программной ошибки или неправильно понято пользователем? Эти варианты описывают разные обстоятельства, а не одно событие под названием «сбой ИИ».

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

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

Идентификация агента — только половина задачи

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

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

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

Полная запись торговых операций информативнее убедительного объяснения, созданного постфактум. Сообщения о намеренных действиях следует сопоставлять с ордерами, которые были приняты, отменены и исполнены.

На регулируемые компании по-прежнему распространяются обязательства

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

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

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

Что меняется для трейдеров и разработчиков продуктов?

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

Разработчики, оценивающие интеграции, могут ознакомиться с разделом KTX Skills. В описании продукта публичные рыночные данные, доступные без API-ключа, отличены от частных торговых возможностей и функций работы со счетом, для которых ключ требуется. Благодаря этому объем доступа становится конкретным решением, а не предположением, скрытым за фразой «ИИ-помощник».

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

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

Часто задаваемые вопросы

Доказывает ли прибыльный бэктест соблюдение законодательства?

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

Устраняет ли доступ только для чтения все риски?

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

Отменяет ли отключение агента существующие ордера?

Не следует так считать. Отдельно проверьте статус незавершенных ордеров и позиций. Предотвращение новых инструкций отличается от отмены принятых ордеров или закрытия позиции, связанной с риском.

Гарантирует ли запись в блокчейне возврат средств после ошибки?

Нет. Запись о транзакции может помочь установить, что произошло; возможность возврата зависит от актива, транзакции, контрагентов и доступных правовых или технических средств защиты.

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