«Ведомости» сообщили, что маркетплейс «Финуслуги» Московской биржи запустил пилотный проект с так называемыми ИИ-заводами — мультиагентной системой для анализа данных и поиска технических ошибок. В этой новости важен не сам термин, а устройство контура: система получает доступ к фактическим продуктовым метрикам, сопоставляет аномалии с кодом и передаёт разработчикам гипотезы для проверки.
По данным компании, которые приводит издание, агенты работают ночью. Они анализируют продуктовые метрики, ищут аномалии в доле неуспешных регистраций, связывают наблюдаемое отклонение с кодом платформы, формируют гипотезу о причине и создают задачу разработчикам. То есть речь идёт не о чат-боте, который отвечает на вопросы, а о системе, встроенной в наблюдение за реальным состоянием цифрового продукта.
«Финуслуги» заявили, что за первый месяц ИИ-агенты помогли обнаружить девять скрытых технических ошибок, мешавших регистрации примерно тысячи пользователей. Компания также оценила экономический эффект от внедрения в двадцать шесть раз выше затрат на разработку и поддержку. До запуска такого контура специалисты, по данным «Финуслуг», тратили от четырёх до восьми часов в неделю на ручной анализ. Эти показатели относятся к конкретному пилоту компании и не являются универсальной нормой для других бизнесов.
Что это значит для бизнеса
Главный вывод из кейса — ценность AI появляется не от самого факта использования модели. Она возникает, когда система видит актуальные данные, понимает границы задачи и встроена в понятный процесс реакции на событие. В данном случае есть измеряемый сигнал — неуспешная регистрация, есть фактическое состояние продукта, есть код, который можно анализировать, и есть человек, принимающий дальнейшее решение.
Это принципиально отличается от попытки «подключить AI ко всей компании». Ограниченный контур проще проверить. Можно увидеть, какую аномалию система обнаружила, какие данные использовала, какую гипотезу сформировала и что произошло после работы разработчика. Если результат нельзя связать с наблюдаемым состоянием, автоматизация превращается в генератор правдоподобных объяснений, а не в инструмент управления.
Для интернет-магазина аналогичный принцип может применяться не к коду, а к воронке. Система может искать резкое изменение на этапе оформления заказа, сопоставлять его с последними изменениями сайта, платёжного сценария или интеграции и готовить карточку инцидента. Для CRM это может быть потеря части входящих обращений между источником и очередью менеджера. Для складского контура — расхождение статусов между учётом и витриной. В каждом случае AI полезен только тогда, когда получает проверяемые данные из источника истины.
Почему человек остаётся в контуре
Источник отдельно подчёркивает роль человека в работе системы. Для бизнес-критичного сервиса это не декоративная оговорка. Обнаружить проблему, предложить гипотезу и самостоятельно изменить промышленный код — операции с разным радиусом ошибки. Чем ближе AI подходит к внешнему действию, тем важнее разделить права на чтение, подготовку решения и запись.
На безопасном первом уровне система может работать read-only: читать метрики, логи и разрешённые объекты, искать исключения и собирать доказательства. Следующий уровень — подготовить задачу, черновик исправления или рекомендуемое действие. Самостоятельное изменение имеет смысл выдавать только там, где последствия ограничены, есть понятный откат и результат можно перечитать после действия.
В новости говорится, что «Финуслуги» планируют распространить ночной мониторинг на весь клиентский путь, а затем научить агентов готовить изменения в коде для проверки разработчиками. Такая последовательность показательна: расширяется сначала зона наблюдения, а действие всё равно проходит проверку человеком. Это позволяет наращивать автономность ступенчато, не смешивая полезность модели с правом безусловно менять систему.
Какие условия делают такой подход рабочим
Первое условие — измеримый объект. Формулировка «улучшать качество» слишком широкая. Система должна видеть конкретный сигнал: изменение конверсии шага, долю ошибок, задержку обработки, расхождение статусов или другой наблюдаемый показатель. Тогда её вывод можно проверить независимо от качества текста, которым она объясняет проблему.
Второе условие — доступ к текущему состоянию. Если AI видит только описание процесса из документа или старую выгрузку, он не может надёжно отвечать на вопрос, что происходит сейчас. Нужна связка с фактическими системами, а вместе с ней — ограничения по объектам и полям, журнал обращений и понятные правила доступа.
Третье условие — владелец следующего шага. Даже точная диагностика бесполезна, если непонятно, кто должен проверить гипотезу и принять решение. В описанном пилоте результат системы превращается в задачу разработчика. В другом бизнесе владельцем может быть менеджер, оператор, инженер, руководитель направления или другой сотрудник, но ответственность не должна растворяться между AI и человеком.
Четвёртое условие — read-back после действия. Технический ответ «операция выполнена» не доказывает, что бизнес-состояние изменилось правильно. После исправления нужно снова посмотреть на объект или метрику. Если AI в будущем получает право на самостоятельное действие, такой контроль становится обязательной частью контура.
Где находятся ограничения и риски
Первое ограничение — качество исходных данных. Агент может хорошо находить закономерности в том, что ему показывают, но пропущенные события, неверные статусы и несогласованные определения метрик будут переноситься в вывод. Поэтому автоматизация диагностики не отменяет работу с источником истины и качеством телеметрии.
Второй риск — путать корреляцию с причиной. Если показатель изменился после обновления, это ещё не доказывает, что именно обновление вызвало проблему. AI может сузить область поиска и подготовить гипотезу, но бизнес-критичные решения требуют проверки. Особенно это важно, когда один показатель зависит сразу от нескольких систем или внешних факторов.
Третий риск — расширить полномочия быстрее, чем систему научились контролировать. Успешный пилот на диагностике не означает, что тем же агентам можно сразу разрешить менять цены, финансовые настройки, клиентские данные или промышленный код. Полномочия должны привязываться к конкретному типу действия и его обратимости.
Наконец, экономический эффект нельзя переносить из чужого кейса в свой бюджет. Заявленная «Финуслугами» эффективность относится к их процессу, объёму ручного анализа и архитектуре продукта. Другому бизнесу сначала нужна собственная базовая линия: сколько времени занимает текущая диагностика, сколько инцидентов реально теряется, какова цена ошибки и сколько стоит поддерживать новый контур.
Практический план действий
Что делать компании, которая хочет проверить похожий подход: выбрать один повторяемый процесс с видимым состоянием; определить источник данных; зафиксировать исходную метрику; разрешить AI сначала только чтение; описать, какие исключения он должен находить; назначить человека, который проверяет результат; и заранее определить, при каком качестве диагностики контур можно расширять.
Следующий шаг — отделить обнаружение от действия. Если система стабильно находит полезные исключения, ей можно разрешить готовить задачи или черновики решений. Только после этого имеет смысл обсуждать автоматическое выполнение низкорисковых операций. Для каждого нового права нужны собственные ограничения, логирование и способ возврата к человеку.
Новость о «Финуслугах» поэтому интересна не как обещание очередной «AI-революции», а как пример конкретной инженерно-управленческой схемы. AI получает доступ к реальному состоянию, работает в ограниченной зоне, создаёт проверяемый результат и не отменяет человека там, где цена ошибки высока. Для бизнеса такая архитектура обычно важнее названия модели или количества агентов.