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

Глава 1. Почему агент — это не «

LLM

с кнопками»

1.1. Три перехода: генерация → инструменты → автономные цепочки действий

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

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

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

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

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

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

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

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

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

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

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

Такой взгляд согласуется с наблюдаемой осторожностью финансового сектора. В совместном исследовании Банка Англии и Управления по финансовому регулированию участвовали 118 организаций. По данным отчёта, 75 процентов респондентов уже применяли искусственный интеллект. Некоторая степень автоматического принятия решений присутствовала в 55 процентах заявленных сценариев, тогда как полностью автономные решения составляли 2 процента. Эти показатели имеют разные знаменатели и не должны складываться. Их совместное чтение показывает разрыв между распространением технологии и передачей полного операционного усмотрения. Исследование искусственного интеллекта в финансовых услугах Великобритании публикует методику и агрегированные результаты.

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

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

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

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

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

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

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

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

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

1.2.

Side

effects

как принципиальное отличие

agentic

AI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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