Внутренний продукт · Управление рисками · Сбер · 2025
риски ИИ-агентовВерсии агентов менялись почти каждый день, а оценка риска жила в задачах Jira, выгрузках Excel и пересылке архивов между людьми.
Убрал из маршрута оценки шесть ручных передач между людьми — это видно на карте процесса «было / стало», — перенеся сбор документов и черновик рисков внутрь продукта. Агент, его версии, тринадцать типов рисков и заключения четырёх подразделений теперь живут в одном месте, а путь версии от «новой» до «согласованной» виден всем, кто в нём участвует.
ИИ-агент внутри банка — не чат-бот на сайте, а работник: он регистрирует самозанятых, планирует диалог с клиентом, ищет должников. У каждого есть версия, владелец, ответственный, статус жизненного цикла и конфигурационная единица в общем каталоге систем. И у каждого есть риски, которых не было у обычного софта: промпт-инъекции прямые и через данные, уязвимости цепочки поставок моделей, взаимное влияние решений на едином ландшафте, отказ ИИ-платформы.
Риск по такому агенту оценивают не один человек и не за один заход: своё заключение дают четыре подразделения, а сводится всё в интегральный показатель. Пока агентов немного, это спокойно живёт в переписке. Когда их становится много, а версии обновляются почти каждый день, переписка кончается — и вместе с ней упирается в потолок сам выпуск ИИ в прод.
Задача пришла от стейкхолдеров риск-функции, и пришла она в форме симптома, а не решения: агентов стало заметно больше, версии обновляются почти ежедневно, у каждой — тринадцать проблемных зон, и никто не может быстро ответить, насколько эта версия готова и рабочая. Требования «сделайте реестр» в постановке не было. Было «мы не успеваем и не видим картину».
Схемы процесса не существовало ни в каком виде. Ни блок-схемы, ни описания — только регламент отдельно, задачи в трекере отдельно и люди, которые держали связь между ними в голове.
Владелец процесса оценки — отвечает за то, чтобы ни один агент не ушёл в прод неоценённым, и за то, чтобы оценка не стала стоп-краном для всего ИИ в банке.
Риск-менеджер — проходит маршрут руками. Ему важно перестать собирать архивы и пересылать файлы, чтобы заниматься собственно оценкой.
Четыре согласующих подразделения — каждое смотрит риск со своей стороны и в своём темпе. Им нужно видеть, что именно они оценивают, не переспрашивая.
Владельцы агентов — те, кто эти версии выкатывает. Для них оценка — внешняя процедура, и им важно понимать, на каком она шаге и когда закончится.
Аудируемость. Процесс регулируемый: любое решение должно оставлять след — кто, когда и на каком основании. Это не пожелание, а рамка, внутри которой можно проектировать.
Дизайн-система банка. Компоненты не переизобретаем: чем ближе к существующим паттернам, тем дешевле разработка и тем меньше учиться пользователю.
Поток изменений. Версии агентов меняются почти каждый день — интерфейс обязан переживать этот поток, а не рассыпаться от него.
Отсутствие схемы процесса. Проектировать пришлось параллельно с тем, как выясняли, что вообще происходит. Discovery и дизайн шли не последовательно, а внахлёст.
Продуктовым дизайном занимался один. Это значит и discovery, и карта процесса, и информационная архитектура, и все экраны с состояниями, и защита решений перед стейкхолдерами. Разработка, аналитика и риск-методология — со стороны команды.
Домен для меня был новый, терминология чужая, а пользователи заняты своей работой и не готовы объяснять её по третьему разу. Самое дорогое в такой ситуации — начать рисовать раньше, чем поймёшь, кто кому что передаёт. Поэтому первым артефактом стала карта процесса, а сетка экранов появилась уже из неё.
Взял карту процесса по ролям вместо привычной карты пользовательского пути. Причина простая: боль здесь живёт не на экране, а в стыках между людьми. Пользовательский путь описывает, что делает один человек; здесь же нужно было увидеть, где работа переходит из рук в руки и сколько простаивает между ними. Классический CJM эту картину не показывает — он рисует одного героя, а героев в маршруте четыре.
Что рассматривал и не взял: сразу идти в прототип и «проверять на пользователях». При двух доступных стейкхолдерах и отсутствии схемы процесса тест прототипа проверил бы удобство экранов, но не ответил бы, правильный ли это маршрут вообще. Сначала маршрут, потом экраны.
Работали дизайн-спринтами, и в них была отдельная колонка под исследование. Спринт здесь выигрывает у бесконечной итеративной работы ровно одним: он заставляет на каждой итерации предъявлять результат людям, которые в процессе живут. При незнакомом домене это единственный способ не уехать далеко в неверную сторону. Чего спринт не дал — глубины: две недели мало, чтобы разобраться в риск-методологии, поэтому спринтов было несколько.
Система разложилась на четыре уровня вложенности — от списка до отдельного риска. Эта же декомпозиция задала порядок работы: пока не понятен нижний уровень (что такое один риск и что с ним можно делать), верхние спроектировать нельзя. К такому порядку я пришёл не сразу — сначала сделал наоборот и переделывал, разбор в разделе 06.
Двухнедельными дизайн-спринтами с отдельной колонкой ревью: макет не уезжал в разработку, пока его не посмотрели. На доске ниже — один такой спринт: слева задачи в бэклоге, справа то, что уже ушло в дев.
У каждого источника своя слепая зона. Стейкхолдеры описывают процесс таким, каким он задуман. Документы — таким, каким он регламентирован. Цифры показывают, как он идёт в жизни. Отраслевые практики подсказывают, что вообще принято делать с рисками ИИ. Я собирал все четыре и смотрел, где они расходятся: расхождение всегда означает, что процесс где-то работает не так, как о нём думают.
Как процесс задуман · два человека, много заходов
Доступных носителей знания было двое, поэтому глубина бралась не количеством интервью, а частотой: возвращался с новой версией карты процесса и спрашивал, где наврал. Главная находка — дорогая часть маршрута оказалась не там, где ожидал. Оценка риска как таковая занимает разумное время; съедает его подготовка к оценке: собрать документы, дождаться выгрузки, переслать, дождаться загрузки.
Как он идёт в жизни
Схемы процесса не было, поэтому маршрут я собирал из задач в трекере и сверял со стейкхолдерами. Так получился юзерфлоу «было» из раздела 04. Расхождение вылезло сразу: на словах путь короче, чем в задачах. Часть шагов люди просто не считали работой — «ну это же две минуты переслать».
Сколько это стоит времени
Каждый шаг передачи стоил от двадцати минут и выше, а таких шагов в выжимке маршрута шесть. Причём минуты — это активная работа, а между шагами добавляется ожидание: пока другой человек увидит, откроет, согласует. Именно это соотношение работы и ожидания стало главным аргументом за то, чтобы убирать передачи, а не ускорять экраны.
Как принято в отрасли
Смотрел, как устроены зрелые B2B-системы управления рисками и сложные внутренние реестры: что выносят в обзор, как делают фасетные фильтры, как показывают аудиторский след. Забрал обзор-сначала и обязательный след решения. Не стал повторять перегруженные таблицы с сортировкой по каждому столбцу — для двух реальных вопросов пользователя это лишний выбор.
Во внутреннем продукте часть решений всегда приходится принимать без цифр: пользователей мало, аналитики по несуществующему продукту нет по определению, а мерить «как было» задним числом обычно уже нечем. В таких местах я не притворяюсь, что данные есть.
Чего измерить было нельзя: сколько версий вообще не доходит до оценки, сколько времени согласующее подразделение держит риск у себя, как часто оценку возвращают на доработку. Что взял вместо этого — три подпорки. Прокси-показатель: вместо неизмеримого «сколько теряем» считал число ручных передач в маршруте, потому что оно наблюдаемо, а время ожидания растёт вместе с ним. Экспертное решение с записанным допущением: где данных не было совсем, формулировал допущение текстом прямо в решении, чтобы его можно было оспорить, а не спорить с ощущениями. Проверяемость после релиза: под каждое допущение закладывал, чем оно опровергается, когда система начнёт копить свою статистику.
Это, кстати, самая частая ситуация во внутренних продуктах. Красивых дашбордов с воронкой там не бывает почти никогда, и умение работать без них — отдельный навык, а не оправдание.
Старый путь я не восстанавливал по памяти: он расписан по шагам прямо на рабочей доске проекта. Ниже он стоит рядом с новым, шаг в шаг. Красным помечены места, где работа останавливалась и ждала человека.
Шесть передач, два человека только на подготовке, каждый шаг от двадцати минут активной работы плюс ожидание между ними. И это выжимка: в жизни маршрут был длиннее.
Из маршрута исчезли обе пересылки, ручная выгрузка, ручная сборка архива и роль администратора-посредника. Осталась работа, ради которой процесс и существует: прочитать, оценить, обосновать.
Во внутреннем продукте аргумент «пользователю так привычнее» не работает: пользователей мало, привычки у них разные, а спорить приходится с методологами и безопасностью. Поэтому у каждого решения ниже есть блок «почему так» с названным принципом. Его можно проверить, оспорить и повторить в следующем проекте, чего не сделаешь с фразой «мне так кажется».
Почему такМантра Шнейдермана для интерфейсов с большими данными: сначала обзор, потом фильтрация и увеличение, детали — по требованию. Реестр без сводки заставляет человека считать глазами то, что система знает точно.
Почему такАвтоприменение выигрывает, когда выдача считается быстро и человек подбирает набор фильтров вслепую: он видит результат каждого шага и не тратит попытки впустую. Кнопка «Показать» уместна, когда запрос дорогой или фильтров много и их набирают осознанно. Чипсы применённых значений на главной — прямое следствие эвристики Нильсена «узнавание вместо припоминания»: состояние фильтра видно, не открывая шторку, и снимается там же, где видно.
Почему такУ числа в списке и числа в отчёте разные работы. Когда карточек десятки, а у каждой четыре суммы, точные цифры — это шум: глаз сравнивает порядки, а не рубли. Но отнимать точность нельзя — она нужна, когда риск защищают. Тумблер вместо жёсткого выбора: обе модели чтения доступны, по умолчанию включена та, что нужна чаще.
Почему такЗакон Хика: время выбора растёт с числом вариантов. Сортировка по каждому полю таблицы выглядит щедро, но заставляет человека каждый раз выбирать из десятка. Здесь нужны ровно два вопроса — «что новое» и «что горит», — поэтому пунктов четыре, а не двенадцать. Выбранная сортировка написана на кнопке: состояние видно, не открывая меню.
Почему такДва принципа сразу. Предотвращение ошибок вместо сообщений о них: система не даёт совершить необратимое действие без обоснования, вместо того чтобы ругаться после. И обратимость: помеченный риск не удаляется, а меняет состояние, поэтому шаг всегда можно отыграть назад. Для регулируемого процесса это ещё и требование аудита — важно не только что решили, но и почему.
Почему такПервая эвристика Нильсена — видимость состояния системы, и она подпирается порогами отклика: до 0,1 с реакция ощущается мгновенной, до 1 с мысль не прерывается, после 10 с внимание уходит. Разбор архива заведомо длиннее десяти секунд, поэтому индикатор обязателен — иначе экран читается как сломанный. Скелетоны вместо крутилки дают ещё и форму будущего результата: ожидание короче не становится, а тревоги меньше.
Почему такПодтверждение уместно ровно там, где действие необратимо и дорого, — во всех остальных местах оно превращается в шум, который щёлкают не глядя. Здесь цена ошибки высокая и восстановить нечем, поэтому диалог оправдан; разрушающее действие в нём подписано словом, а не «ОК».
Раздел, которого обычно нет в портфолио, — и зря: по нему видно, умеет ли человек замечать свою ошибку до того, как её заметят другие. Ниже разборы честные, с последствиями и без героического финала.
Отсюда и порядок в дереве декомпозиции из раздела 02. Он выглядит очевидным, потому что записан задним числом.
Самая дорогая ошибка из трёх: она переписала не экран, а модель данных.
Здесь у меня есть подтверждение помимо памяти: оба варианта лежат на рабочей доске, второй подписан «для идей и наработок на будущее». Историю задним числом я не переписываю.
Результаты записаны формулой: чего добился, чем это измеряется и что для этого сделал. Формат неудобный в хорошем смысле. Если между решением и эффектом нет внятной связи, при такой записи это вылезает сразу, и цифру приходится либо подпирать, либо убирать.
Продуктовый дизайн в этом проекте вёл один: discovery, карта процесса, информационная архитектура, все экраны и состояния, защита решений перед стейкхолдерами. К результату привели три решения, за которые отвечаю лично. Первое — потратить начало проекта на карту процесса вместо экранов: без неё шесть передач так и остались бы невидимыми, потому что по отдельности каждая выглядит безобидной. Второе — развести заключения четырёх подразделений и интегральный показатель: это переписало модель данных и сделало возможными промежуточные состояния. Третье — перенести загрузку документов внутрь продукта, что и убрало посредника из цепочки.
Честно про цифры. Реальны и подтверждены: тринадцать типов рисков, четыре согласующих подразделения, шесть шагов в выжимке старого маршрута, стоимость шага от двадцати минут, два реестра и состав экранов. Цифры на самих скриншотах (639 агентов, 142 оценённых и прочее) — демо-данные макета, а не производственные показатели, и как результат работы они здесь не заявлены. Формулировки эффектов и находок восстановлены по ходу проекта и помечены в коде страницы комментарием «оценка» — при разборе кейса я говорю о них как о реконструкции, а не как о замерах.
Отдельный маршрут для агентов, где полная процедура избыточна: та же система, но короче. Задача уже стояла в бэклоге спринта.
Если черновик риска сформировала модель, это должно быть видно человеку, который его утверждает. Продукт, оценивающий риски ИИ, обязан быть честным насчёт собственного ИИ.
Когда оценок станет тысячи, сводки и фильтров перестанет хватать — нужен поиск по списку и очередь по срокам.
Главный урок домена: в enterprise боль почти никогда не на экране. Она в стыках между людьми, и увидеть её можно только картой процесса, а не разговором о том, чего не хватает в интерфейсе. Спроси риск-менеджера, что улучшить, — он расскажет про кнопку. Посчитай передачи в его маршруте — увидишь, что кнопка ни при чём.
Что сделал бы иначе сегодня: раньше пошёл бы к разработке. Две из трёх моих ошибок стоили спринтов, и обе решались вопросом, который надо было задать до макетов, а не после. И начал бы с нижнего уровня данных сразу, не проверяя на себе, что бывает наоборот.
Другие кейсы
Расскажу детали кейса при встрече — и покажу то, что не влезло на страницу.
