В банковской операционной есть контроль старше компьютеров, на которых он исполняется: составитель платежа не может быть его выпускающим. Один готовит, другой проверяет и подписывает. Принцип четырёх глаз и segregation of duties аудиторы требуют на платежах и проводках без скидок на технологии. А теперь в эту схему входит AI-агент, который готовит платёжный реестр, сверяет счета с заказами — и, если его не остановить, сам же всё и проводит. Агент не меняет контроль. Он меняет того, к кому контроль применяется. Агент готовит — именованный человек открывает one-way door. Разделение зашито в коде, а не оставлено на совесть промпта.
Контроль старше компьютеров
Maker-checker — это разделение исполнения и верификации: maker создаёт или вводит транзакцию, checker проверяет и утверждает до вступления в силу. Одна ошибка или одна мошенническая запись не проходит без второй пары глаз. Это близкий родственник four-eyes principle и строительный блок segregation of duties, в том числе в смысле SOX. Регуляторы финансового сектора не пишут отдельных правил под агентов — они ждут, что фирмы применят существующие рамки (model risk, кибербезопасность, операционная устойчивость) к агентам и добавят контроли, потому что агенты действуют самостоятельно. Так описывает ожидания разбор Arthur по регуляторным контролям: human oversight с maker-checker workflow, границами автономии и порогами, решающими, когда агент обязан спросить человека.
Почему агент без checker — нарушение SoD
Агент, который готовит и проводит, совмещает несовместимое по определению SoD: исполнение и подтверждение в одних руках — пусть и кремниевых. Три aggravating-обстоятельства делают это хуже, чем человек-нарушитель:
- Скорость. Человек проводит десятки платежей в день; агент — тысячи. Ошибка масштабируется мгновенно.
- Буквальность. Агент не «почувствует неладное» при смене реквизитов получателя — он исполнит. Именно смена beneficiary — классический путь authorized-push-payment потерь.
- Невидимость. Действия агента без журнала выглядят как системная активность без автора. Аудитор видит проводки, у которых нет ни maker, ни checker, — только timestamp.
Поэтому вопрос не «нужен ли checker», а «где проходит one-way door и кто её открывает».
One-way door: где она проходит
One-way door — шаг, за которым ошибка движет реальными деньгами и не отменяется тихо. Карта таких дверей для агентных сценариев:
| Сценарий | Агент свободно | Дверь открывает человек |
|---|---|---|
| Платежи и wires | Собирает реестр, сверяет счета с заказами, флагит дубли и смену реквизитов | Выпуск сумм выше порога и на новые/изменённые реквизиты |
| Трейдинг | Мониторит позиции, готовит ребаланс и ордер при дрейфе от мандата | Сделка вне мандата или с breach риск-лимита |
| Закрытие и учёт | Готовит сверки, черновики проводок, пакет доказательств | Контролёр подписывает: исполнитель не может быть единственным аттестующим |
| Клиентские деньги | Обслуживает, готовит операции | Второй подписант на движение средств клиентов |
Правило Rosa: агент быстр вплоть до двери; дверь — именованному человеку. Front office предлагает, риск утверждает — и для агентов это не любезность, а контроль, отделяющий стратегию от rogue book.
Кто такой checker и его полномочия
Checker — не «кто-нибудь, кто нажмёт approve». Требования к роли:
- Именованный. Не «дежурный», а конкретный человек с полномочиями на класс решений. Подпись принадлежит лицу, а не очереди.
- Независимый от maker. Requester не может быть approver — никогда, ни при каких флагах «срочно». Совмещение в одном лице (и тем более в одном агенте) запрещено структурно.
- Информированный. В запросе — что, сколько, кому, на каком основании, что проверено автоматически. Подтверждение вслепую — это подпись под чужим решением.
- Отвечающий. Подпись пишется в журнал дословно с причиной: что подтверждено и почему. «Согласовано» без мотива — слабое доказательство.
AWS в финансовом подходе к agentic AI требует того же через human-AI homology: понять человеческий контроль, определить его применимость к агентам, задокументировать персоны агентов, обеспечить supervision критических действий и segregation of duties для действий и инструментов.
Пороги и лимиты числами
Дверь без чисел — это дверь, которую открывают всегда. Пороговая матрица задаётся явно и пересматривается по журналу:
- Суммовые пороги по классам операций: до X — автоматически по guardrails, выше — checker, выше Y — двойная подпись.
- Новые и изменённые реквизиты — всегда checker, независимо от суммы.
- Лимиты числа операций: инвоков в окно, получателей в реестре, доля изменённых записей.
- Fail-closed: превышение лимита — отказ, а не «пропустить с предупреждением».
Лимиты — тоже контроли: их изменение само требует утверждения и пишется в журнал.
Запрет самоподтверждения в коде
Ключевое слово — в коде. Инструкция «не подтверждай сам себе» в системном промпте ломается инъекцией; структурный запрет — нет. Реализация по образцу OSS-подхода: агент действует только через роль, выполняет только granted-навыки (deny by default, с пином версий), не выходит за лимиты и доказуемо не может утвердить собственную работу. Каждый отказ именован: навык не выдан роли, превышен лимит суммы или числа, конфликтующая роль уже действовала в ране (SoD violation), высокорисковый навык без предшествующего гейта. Высокорисковые навыки живут в отдельной роли, недоступной агенту-исполнителю, — чекерская роль не может быть выдана тому, кто готовит.
Проверка на вшивость для любой реализации: может ли скомпрометированный или галлюцинирующий агент в пределах выданного провести необратимое или подтвердить своё? Если да — это детект-контроль (флаг после факта), а не prevent-контроль. Аудитору нужен второй.
Журнал, который проверяется офлайн
Компания не может выдать себе финансовый аудит — и агент не может сам себе заверить журнал. Поэтому стандарт доказательства: каждое действие, блокировка и подпись коммитятся в hash-chained журнал с подписью Ed25519, который экзаменатор пересчитывает офлайн, без доступа к вашим системам и без вашего кода. Измени одну строку — верификация ломается ровно на ней. В журнале: кто предложил (агент, идентичность, поручение), что именно, кто подписал и с какой формулировкой, что исполнено и с каким результатом, каждый отказ с именованной причиной. Аудит-пак собирается из цепочки, а не из рассказов.
Слабость checker и как её лечить
Честная оговорка из практики: под нагрузкой checker подтверждает факт ввода, а не корректность. Пролистать сотни строк реестра глазами против цен, договоров и накладок невозможно — approval превращается в ритуал. Лечение — усилить сторону checker автоматикой: агент-верификатор сверяет цены построчно и флагит overcharge, three-way matching связывает счёт с заказом и поставкой, проверка против условий договора идёт до человека. Тогда подпись опирается на реальную проверку, а не на взгляд — даже на высоком объёме. Каждая автоматическая верификация тоже логируется: аудитор видит не только подпись, но и на чём она стояла.
Чеклист внедрения
- One-way doors нанесены на карту по всем сценариям с деньгами и обязательствами.
- Checker именован, независим, получает полный контекст и пишет мотив подписи.
- Пороги и лимиты — числами, fail-closed, изменение — через утверждение.
- Самоподтверждение запрещено структурно: раздельные роли, именованные отказы, prevent, а не detect.
- Журнал hash-chained и подписан, верифицируется офлайн третьей стороной.
- Сторона checker усилена автоматическими сверками (цены, matching, договоры).
- Платёжные утверждения — только человеком; агент готовит доказательства (Teradata-правило).
- Ревью порогов и ролей — по расписанию, с владельцами.
Где Codenik
Codenik — это enforce слоя maker-checker, а не рекомендация. Deny by default на инструменты, гейт на необратимое с именованным approver, структурный запрет requester-as-approver, лимиты fail-closed, журнал каждого решения с причиной. Агент готовит платёж со всеми сверками — человек открывает дверь одной подписью с полным контекстом. Аудитор получает цепочку, проверяемую офлайн, а не доступ в прод и честное слово. Разделение обязанностей перестаёт зависеть от дисциплины — оно становится свойством контура, в котором агент работает.
Короткий вывод
Агент, который готовит и проводит, — это нарушение SoD со скоростью машины. Перенесите старейший банковский контроль на новую связку: агент готовит всё вплоть до one-way door, именованный человек открывает её подписью с мотивом, самоподтверждение запрещено кодом, каждое решение — в журнале, проверяемом офлайн. Аудиторы уже знают этот контроль между людьми. Покажите им тот же контроль между агентом и человеком — и разговор о внедрении пойдёт о сроках, а не о запретах.