Один источник может выглядеть однозначным, пока не спросишь, какое решение он должен поддержать. В синтетическом учебном кейсе Acme Pay официальная документация v2.1 — базовый источник по API. Рядом есть старая wiki и код прототипа на v1, а ещё письмо поддержки с операционным уточнением. Смысл карты источников в том, чтобы не сложить всё это в одно «самое вероятное» правило. Самый наглядный пример — срок жизни токена. В документации фигурирует 24 часа, в письме поддержки — 4 часа. Это не повод выбрать меньшее число «на всякий случай» и не доказательство, что письмо автоматически обновило контракт. Оба утверждения нужно сохранить рядом, указать их статус и передать вопрос владельцу источника — службе поддержки Acme Pay или роли, которая отвечает за контракт. Пока подтверждения нет, вопрос остаётся открытым. Так же бывает и с рабочими требованиями. Один и тот же абзац можно прочитать как описание поведения, как обязательное ограничение или как пример. Если не записать владельца, дату и границу применимости, агент легко соберёт цельный вывод из разных интерпретаций. Я проверяю такие места в три шага. 1. Что именно утверждает источник? Нужна короткая формулировка, а не пересказ всего документа. 2. На какой вопрос источник имеет право отвечать? Документация задаёт контракт, письмо может уточнить операционную деталь, а устная договорённость о сроках не становится принятой только потому, что её кто-то произнёс. 3. Какой вопрос остаётся открытым после прочтения? Его нужно передать названному владельцу и сохранить до решения. В Acme Pay остаются и другие пробелы: не описано поведение при недоступности провайдера, а требования к логированию и хранению данных не покрыты источниками. Это не приглашение заполнить пропуски «хорошей практикой». Это список вопросов, которые меняют архитектуру и должны получить решение до реализации. Смысл карты источников не в том, чтобы выбрать самый уверенный вариант. Она сохраняет конфликт до тех пор, пока человек с нужным правом не примет решение. Только после этого агенту можно передавать задачу, в которой уже видны версия правила, граница действия и критерий приёмки.

Когда в рабочем процессе появляется агент, возникает соблазн отдать ему не только действие, но и выбор следующего шага. Иногда это разумно. Но не всякая последовательность должна становиться делегируемой. В одном моём внутреннем workflow два процесса-агента увидели правдоподобный идентификатор одной и той же работы и действовали из устаревшего контекста. Финальные данные удалось сохранить благодаря резервным копиям и сверке. Но сам путь записи всё ещё позволял прийти с устаревшим предположением. После этого я разделяю две вещи. Первая — фиксированная последовательность, которую нельзя «улучшить» по ходу выполнения: 1. определить владельца решения; 2. зафиксировать точное действие; 3. привязать свидетельство; 4. назвать принятую версию; 5. указать срок действия или условие переоценки; 6. определить, куда эскалировать неопределённость; 7. проверить результат после действия. Вторая — делегируемый выбор внутри этой рамки. Агент может решить, какой из разрешённых шагов выполнить, как собрать контекст или какой вариант предложить. Но он не должен сам менять владельца, расширять разрешение или считать собственный вывод принятым. В том workflow проблема была не в отсутствии ещё одного агента-наблюдателя. Не хватало технических границ: проверки ожидаемой версии, действующей аренды работы и перехода состояния, который отклоняет устаревший запрос до записи. Это не делает решение универсальным рецептом, но показывает, где фиксированная последовательность должна быть поддержана системой, а не только инструкцией. Это полезное разделение и для обычной аналитики. Если порядок проверки задаётся заново на каждом запуске, система может выглядеть гибкой, но одинаковые входы будут приводить к разным границам ответственности. Если зафиксировать только то, что действительно нельзя менять, а выбор оставить агенту, появляется пространство для автоматизации без потери контроля. Моя рабочая проверка простая: что в этом процессе является инвариантом, а что — выбором? Если ответ не записан отдельно, агент почти наверняка начнёт менять их местами.

В задачах, связанных с риском, решение меняет не количество сигналов, а то, что именно они позволяют утверждать. Когда я делал AI-ассистента для Transaction Monitoring в Finom, он собирал контекст подозрительной транзакции и определял степень подозрительности. В 65% случаев обработка проходила полностью автоматически. Это проверенный факт о конкретной системе и её результате. Но из этого факта нельзя автоматически вывести универсальную архитектуру для любого финтех-продукта. Нельзя сказать, что в каждой такой системе одни и те же данные можно собрать, один и тот же результат закрыть без человека или применять один и тот же порог. Эти решения зависят от источников, правил и владельца процесса. Чтобы показать разницу, возьмём синтетический пример. Пусть система видит перевод с необычной географией и резким изменением поведения клиента. Она может собрать сигналы, присвоить результату уровень риска и передать его на следующий шаг. Но сам результат ещё не говорит, что проверка завершена. Для этого нужно отдельно зафиксировать: — какие источники были доступны на момент решения; — какие признаки сработали и какие альтернативы проверялись; — какой результат считается достаточным для автоматического маршрута; — при каком условии запись обязана вернуться человеку; — кто имеет право принять такой результат. Это и есть граница между сигналом, решением системы и принятой ответственностью. В финтехе green в техническом тесте — ещё не решение по риску. Модель могла ответить, сервис мог вернуть корректный формат, а вывод всё равно оказаться недостаточным для операции. Поэтому я разделяю как минимум четыре слоя: доступность источников, вычисленный результат, проверяемые критерии и право приёмки. Если убрать последний слой, автоматизация просто прячет неопределённость за аккуратным интерфейсом. Если оставить его явным, видно, где модель помогает, где нужны дополнительные свидетельства и где ответственность всё ещё принадлежит человеку.