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

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

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

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

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

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

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

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

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

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

Глава 3. Регуляторная инженерия вместо «compliance after the fact»

3.1. AI governance, финансовые нормы и operational resilience

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

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

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

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

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

Регламент Европейского союза 2024/1689 создаёт обязательства для определённых участников и категорий систем. Его применимость должна устанавливаться юридически для конкретного назначения. Для систем высокого риска статья 9 требует документированного и поддерживаемого процесса управления риском на протяжении жизненного цикла. Статья 12 требует технической возможности автоматической регистрации событий. Статья 14 закрепляет эффективный человеческий надзор. Эти требования не дают универсального разрешения агенту действовать. Они показывают, что риск, журнал и надзор должны быть свойствами системы, а не дополнением к отчёту о внедрении. Регламент 2024/1689 является первичным правовым источником.

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

Обновление американского руководства по модельному риску в апреле 2026 года показывает движение к соразмерности, основанной на оценке риска. Совместное руководство Федеральной резервной системы, OCC и FDIC заменило прежние письма и подчёркивает настройку управления с учётом профиля моделей, размера и сложности операций. Его нельзя считать единым правилом для всех стран или всех агентов. Для нашей архитектуры важен принцип: интенсивность независимой проверки и мониторинга связана с фактическим использованием, а не только с названием технологии. Письмо Федеральной резервной системы SR 26 2 фиксирует дату, область релевантности и замену прежнего руководства.

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

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

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

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

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

Следующая таблица разделяет обязанности нормативных контуров и показывает точку их соединения. Она не заменяет юридическую карту требований конкретной организации.

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

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

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

3.2. Перевод требований в исполняемые политики

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

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

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

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

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

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

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

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

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

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

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

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

Четыре уровня перевода требования представлены на последовательных примерах. Формулировки являются авторской инженерной интерпретацией, а не цитатами нормативных актов.

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

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

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

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

3.3.

Evidence

-

by

-

design

: что система должна уметь доказать

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

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

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

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

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

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

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

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

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

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