Регулируемый агентный финтех: как строить автономные AI-системы, которым можно делегировать действия, а не только ответы

2.2.

Blast

radius

и необратимость как базовые переменные

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

Термин «blast radius» пришёл из инженерного языка аварий и безопасности. В этой книге он обозначает множество объектов, процессов и сторон, на которые способно повлиять одно ошибочное решение до остановки. Русское выражение «радиус воздействия» передаёт смысл точнее, когда речь идёт не только о техническом сбое, но также о деньгах, правах, отчётности и клиентах. В названии подраздела использовано русское выражение «радиус воздействия».

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

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

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

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

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

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

Инцидент Knight Capital даёт проверяемый пример быстрого расширения радиуса. Комиссия по ценным бумагам и биржам США установила, что за период около 45 минут система создала около четырёх миллионов исполнений по акциям 154 компаний общим объёмом более 397 миллионов акций. Реализованный убыток составил 460 миллионов долларов. Эти показатели описывают фактическое последствие конкретного программного отказа, а не языкового агента. Для нашей модели важен механизм: автоматическая скорость превратила ошибку одной конфигурации в портфель множества рыночных позиций. Постановление Комиссии служит первичным источником чисел.

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

d = 4 000 000 / 154 ≈ 25 974

В среднем на одну позицию в перечне из 154 акций пришлось около 25 974 исполнений. Эта величина не раскрывает распределение и не описывает отдельную ценную бумагу. Она показывает, что радиус имел одновременно ширину по числу инструментов и плотность внутри каждого инструмента. Для агента аналогом будет не только число клиентов, но и число действий на клиента. Ограничение одного измерения не заменяет ограничение другого.

Случай Citibank показывает необратимость другого рода. Судебное решение фиксирует перевод 894 миллионов долларов основного долга и 7,8 миллиона долларов процентов. Около 385 миллионов долларов было возвращено, а получатели суммы примерно в 500 миллионов долларов первоначально отказались вернуть средства. Если сопоставить возвращённую сумму только с основной суммой, получим приблизительную долю:

k = 385 / 894 × 100 % ≈ 43,1 %

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

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

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

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

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

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

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

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

2.3. Автономность как бюджет, а не как фича

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

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

Слово «бюджет» важно по трём причинам. Первая состоит в конечности ресурса. Полномочие не должно существовать бессрочно только потому, что агент однажды прошёл проверку. Вторая связана с распределением между видами ресурса. Денежный предел не заменяет ограничение числа действий, а срок не заменяет ограничение данных. Третья причина состоит в наблюдаемости расхода и возможности объяснить его владельцу процесса на языке операции.

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

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

Обозначим бюджет задачи как множество:

Б = {Д, К, В, О, П}

Здесь (Д) обозначает денежные пределы; (К) соответствует количественным пределам; (В) обозначает временные пределы; (О) задаёт область данных и объектов; (П) определяет свободу изменения плана. После каждого действия система вычисляет остаток по каждому компоненту. Для количественных величин можно использовать простое выражение:

Б_i^ост = Б_i^нач − Σ(j=1…n) р_ij

В этой формуле (Б_{i}^{нач}) является начальным пределом компонента (i), а (р_{ij}) обозначает расход этого компонента действием (j). Для областей данных и прав вместо вычитания применяется проверка принадлежности разрешённому множеству. Эту формулу я использую как конструкцию управления допуском. Она не предназначена для расчёта регуляторного капитала или бухгалтерского бюджета.

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

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

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

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

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

Подход, основанный на оценке риска, поддерживается действующими руководствами, хотя понятие бюджета автономности является авторским. В апреле 2026 года Федеральная резервная система США опубликовала пересмотренное руководство по управлению модельным риском. Оно заменило письма 2011 и 2021 годов и подчёркивает настройку управления с учётом профиля моделей, размера и сложности операций банка. Положения письма особенно значимы для регулируемых Федеральной резервной системой банковских организаций с активами свыше 30 миллиардов долларов. Письмо SR 26 2 содержит дату, область релевантности и указание на адаптацию контроля к уровню риска.

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

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

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

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

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

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

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

2.4.

Planning

failures

: когда план формально корректен, но семантически ошибочен

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

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

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

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

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

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

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

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

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

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

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

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