Агентный AI: шесть паттернов доверия

Двадцать лет я проектирую финтех-системы, где цена ошибки интерфейса — деньги клиента, поэтому слово «автономность» вызывает у меня не восторг, а профессиональную настороженность. При этом я сам строю AI-продукты — LLM «Чёрный куб», голосовых агентов — и вопрос «что агенту разрешено делать без спроса» для меня не футурология, а рабочая повестка. Статья Виктора Йокко — редкий случай, когда о доверии к AI говорят не лозунгами, а паттернами с метриками. Конспектирую то, что стоит унести в работу.

Вольный перевод-конспект статьи «Designing for Agentic AI: Practical UX Patterns for Control, Consent, and Accountability» (Smashing Magazine, февраль 2026, автор — Victor Yocco). Оригинал: smashingmagazine.com. Сокращено; курсив и примечания мои.

Автономность — не то же самое, что доверие#

Главный тезис статьи умещается в одну фразу:

Автономность — продукт технической системы. Достойность доверия — продукт процесса проектирования.

Агентный AI не просто отвечает на вопросы — он действует от имени пользователя: бронирует, отменяет, платит, пишет письма. Значит, мы проектируем уже не интерфейс, а отношения — с понятной коммуникацией, взаимным пониманием и оговорёнными границами. Йокко предлагает шесть паттернов, выстроенных по жизненному циклу взаимодействия: до действия — согласование намерений, во время действия — контекст, после действия — безопасность и восстановление.

До действия: намерение и границы#

Превью намерения (The Intent Preview)#

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

Хорошее превью — это ясный язык без технического жаргона, последовательные шаги для многоходовых операций и три понятные кнопки: «Выполнить», «Изменить план», «Сделаю сам». Пример из статьи — тревел-ассистент, который заметил отмену рейса и предлагает план из четырёх шагов: отменить рейс UA456 с возвратом денег, перебронировать на DL789 (прямой, 14:30), предупредить отель о позднем заезде, отправить обновлённый маршрут пользователю и попутчице.

Паттерн обязателен для необратимых действий, финансовых операций и передачи данных третьим лицам. Метрики здоровья: доля планов, принятых без правок, — целевой уровень выше 85%; частота кнопки «Сделаю сам» — если её жмут чаще, чем в 10% случаев, модель планирования пора пересматривать. Отдельно понравился пример DevOps-агента для облачной инфраструктуры: в превью — конкретные команды вроде «слить трафик» и «откатить релиз», а не обтекаемое «обновлю окружение».

Шкала автономии (The Autonomy Dial)#

Доверие не бинарно — его нужно калибровать. Регулятор автономии отдаёт пользователю контроль: он сам подбирает поведение системы под свою готовность к риску. Четыре уровня:

• Наблюдать и предлагать — агент только сообщает о возможностях, планов не строит.
• Планировать и предлагать — строит планы, но каждый требует одобрения.
• Действовать с подтверждением — выполняет знакомые задачи, спрашивая финальное «да».
• Действовать автономно — для заранее одобренных задач (например, оспаривание платежей до 50 долларов) работает сам и уведомляет постфактум.

Важная деталь: шкал может быть несколько. Почтовый ассистент получает отдельный регулятор для планирования встреч и отдельный — для отправки писем от имени пользователя. Метрики: распределение аудитории по уровням (Trust Density) и частота смены настроек (Setting Churn) — если пользователи дёргают регулятор туда-сюда, с доверием проблема.

Во время действия: контекст#

Объяснимое обоснование (The Explainable Rationale)#

Агент отвечает на вопрос «почему?» до того, как его задали. Объяснимые действия воспринимаются как логичные, а не случайные, — и пользователь строит верную ментальную модель того, как агент «думает». Хорошее объяснение опирается на прецедент — правила и предпочтения самого пользователя — и звучит просто: «Ты сказал X, поэтому я сделал Y».

Пример из статьи: «Я перебронировал отменённый рейс. Delta 789, вылет в 14:30. Почему: твой рейс отменила авиакомпания, а ты заранее разрешил автономное перебронирование прямых рейсов в тот же день».

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

Сигнал уверенности (The Confidence Signal)#

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

Реализация: числовой показатель («уверенность: 95%»), явное объявление границ компетенции и визуальные подсказки — зелёная галочка при высокой уверенности, жёлтый знак вопроса при сомнениях. Паттерн особенно нужен экспертным системам — медицина, код-ассистенты. Метрики любопытные: корреляция Пирсона между уверенностью модели и долей принятых планов (цель — выше 0,8) и «дельта скрутинии» — насколько дольше пользователи изучают планы с низкой уверенностью. Она должна быть положительной, например +12 секунд: значит, сигнал работает.

После действия: страховка#

Журнал действий и отмена (The Action Audit & Undo)#

Самый фундаментальный паттерн — Йокко считает его обязательным почти для любой агентной системы, и уж точно для операций с деньгами.

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

Практика: хронологическая лента действий, ясные статусы (выполнено / в процессе / отменено) и честное окно отката — «отмена доступна 15 минут». Метрики: доля отменённых действий — если по конкретной задаче она выше 5%, автоматизацию этой задачи нужно выключать; и конверсия страховки — сколько пользователей перешли на уровень «действовать автономно» в течение семи дней после первого успешного undo. То есть работающая отмена не тормозит автономию, а разгоняет её — это лучший аргумент в спорах с продактами.

Путь эскалации (The Escalation Pathway)#

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

• Просьба об уточнении: «Ты написал „следующий вторник“ — это 30 сентября или 7 октября?»
• Предложение вариантов: вместо одного рейса — несколько на выбор.
• Передача человеку: «Эта операция выглядит необычно, я не уверен, как действовать».

Метрики: частота эскалаций — здоровый диапазон 5–15% от всех задач (ниже — агент самонадеян, выше — беспомощен), и доля задач, успешно завершённых после эскалации, — цель выше 90%.

Когда агент ошибся: ремонт и возмещение#

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

Структура правильного извинения — три шага: признать ошибку прямо и просто («я перевёл деньги не туда»), назвать немедленное исправление («перевод отменён, 250 долларов вернулись на счёт»), дать путь к живой поддержке. В примере из статьи агент ещё и сообщает, что инцидент передан на внутренний разбор, чтобы не повторился.

Управление: совет по этике и три фазы#

Паттерны не живут без процесса. Йокко предлагает собрать кросс-функциональный совет по этике агентного AI: юристы и комплаенс задают регуляторные границы, продакт владеет политикой автономии и реестром рисков агента, UX-исследователи проводят калибровку доверия и тесты на «плохое поведение», инженеры отвечают за логирование, откат и генерацию объяснений, поддержка приносит обратную связь с передовой. Реестр рисков, журналы аудита и формальная политика автономии — живые документы, которые регулярно пересматриваются.

Внедрять автономию статья советует поэтапно. Фаза 1 — фундамент безопасности: надёжное превью намерений и инфраструктура журнала с отменой; агент только предлагает. Фаза 2 — калиброванная автономия: ограниченная шкала уровней и объяснимые обоснования; агент действует с подтверждением. Фаза 3 — проактивное делегирование: полная автономия для заранее одобренных задач с низким риском, под постоянным мониторингом.

Финал статьи стоит процитировать целиком:

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

Что я забираю себе#

Шкала автономии — это лимиты, и финтех изобрёл их давно. Банки годами живут с порогами: до какой-то суммы платёж проходит сам, выше — подтверждение, ещё выше — звонок. Уровень «действовать автономно» для агента должен настраиваться ровно так же — суммой, а не абстрактным «доверяю/не доверяю». Забираю формулировку «отдельная шкала на каждый тип действия»: разрешить агенту читать выписку и разрешить платить — разные решения.

Доля отмен как рубильник автоматизации. Правило «отменяют больше 5% — выключаем автодействие для этой задачи» — готовый, честный KPI. В финтехе я бы применял его к автоплатежам и автопродлениям; в собственных продуктах — к любому действию, которое агент делает без спроса.

Журнал действий агента — это выписка по счёту. Пользователь финтеха доверяет системе, потому что каждая операция оставляет след, который можно оспорить. Агенту нужен такой же след: лента действий, статусы, окно отката. Для «Чёрного куба» и голосовых агентов заведу именно timeline, а не лог для разработчика.

Переспрашивающий агент надёжнее угадывающего. Для голосового агента эскалация — вопрос выживания: уверенно назначенная встреча не на тот вторник убивает доверие быстрее, чем три уточняющих вопроса. Диапазон 5–15% эскалаций беру как норму проектирования, а не как признак слабой модели.