Главная
→
Блог
→
Кейс: как ИИ-ассистент вырос из пилота в прод за 2 месяца

Кейс: как ИИ-ассистент вырос из пилота в прод за 2 месяца

“

Большинство ИИ-пилотов так и не становятся рабочим продуктом. Разбираем историю «Домиленда», который за два месяца довёл ассистента до продакшена, что пришлось построить вокруг модели и чем это отличается от красивого демо.

Статистика: почему это редкость

По данным Strategy Partners, до промышленной эксплуатации на российском рынке доходят лишь 7–10% пилотов ИИ-агентов, а в 73% компаний нет владельца процесса, который мог бы принимать решения без долгих согласований. В мире картина похожая: по данным S&P Global Market Intelligence, средняя организация закрывает 46% пилотов, не доведя их до рабочей версии.

На этом фоне кейс, где два месяца прошли от идеи до работающего продукта, стоит разобрать подробно.

Главный кейс: «Домиленд»

«Домиленд» — PropTech-платформа (технологическая платформа для недвижимости) в экосистеме Яндекса: приложение для жителей жилых комплексов, сервисы для управляющих компаний (УК) и системы умных зданий. У приложения больше полутора миллионов пользователей.

Руководитель продукта Михаил Михайлов собрал ИИ-ассистента для жителей в одиночку за два месяца, причём проектом он занимался не на полную ставку. Ассистент принимает показания счётчиков по фотографии, показывает расход ресурсов и находит заявки жителя в УК. Раньше такое фото приходило на почту, оператор вручную считывал цифры и вносил их в систему.

Результат: ассистентом регулярно пользуются больше 20 тыс. жителей, а около 15% обращений, которые раньше доходили до управляющей компании, он перехватывает сам. Решение работает в продакшене и уже продаётся партнёрам.

Первая версия за пару дней — и почему она не годилась

Первая версия выглядела как у всех, кто пробует агентов: цикл, в котором модель вызывает инструменты, MCP-сервер (стандартный способ подключить к модели внешние инструменты), API (интерфейс обмена данными между программами) и клиент в виде телеграм-бота. Такое можно поднять с любой моделью за пару дней в Yandex AI Studio.

Но для продакшена она не подходила. Передача показаний и заявки в УК — критичные для человека задачи: если ассистент передаст не те цифры или вообще не отправит их, житель заплатит лишнее. Поэтому два месяца ушли не на «сделать чат», а на всё, что вокруг модели.

Что пришлось построить вокруг модели

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

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

Тестовые наборы запросов и журналы. Команда собрала прогоны синтетических и полусинтетических запросов, похожих на реальные обращения, и полный журнал от сообщения пользователя до ответа API. Дополнительно сделали «LLM-судью»: это вторая нейросеть, которая после теста сверяет ответы первой с ожидаемыми и предлагает, что чинить. Именно эта связка, по словам автора, довела проект до продакшена.

Память диалога. В контекст постоянно подставляют номер квартиры и нужные метаданные, чтобы ассистент не переспрашивал, для какой квартиры заявка. Для жителей с несколькими квартирами цена ошибки выше всего.

Иерархия доверия источникам. Бывало, что модель брала ответ из прошлого диалога и сообщала, что создала новую заявку, хотя не создавала. Теперь модель явно знает, какому источнику верить в первую очередь.

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

Явные запреты. К ассистенту подключено около 20 инструментов, и если не написать прямо, что нельзя, модель додумает лишнее. Такие случаи почти не видны при ручной проверке, их ловит только регулярный прогон тестового набора.

Адаптер к реальным системам. Переписывать существующие API времени не было, поэтому сделали переходник, который приводит заявки разных управляющих компаний к единому формату. С современными моделями для кода это заняло один день.

Проверка данных вне модели. Ограничители через инструкцию для модели, по словам автора, не работают: даже 10% ошибок для такого сервиса критичны. Все проверки и операции записи вынесли на уровень API.

Собственный контроль порядка вызовов. Простая фраза «вызови сантехника» разворачивается в несколько шагов, и без строгого порядка результаты шагов путаются. Поэтому написали свой цикл, который отвечает за порядок, расход токенов и обновление доступов.

Итоговое разделение такое: модель нужна только чтобы понять запрос и выбрать действие, а остальное делает код. Автор прямо говорит, что это не «вайб-кодинг» (когда пишешь одну инструкцию и получаешь готовое), а планомерная архитектурная работа.

Почему срок сработал

Если сопоставить с причинами провалов пилотов, видно несколько совпадений.

У проекта был владелец с полномочиями. Руководитель продукта сам принимал решения, а не согласовывал их неделями. Это то, чего не хватает 73% компаний.

Узкий список сценариев. Сценарии выбирали по частоте обращений жителей.

Критичное закрыли в первую очередь. Безопасность данных и тесты построили до расширения функций, а не после.

Работали с реальными системами. Ассистент с самого начала подключался к существующим API управляющих компаний, а не жил отдельно.

Оговорка: эти данные автор опубликовал в блоге Yandex Cloud, то есть у компании есть интерес показать, как быстро можно собрать продукт на её инструментах. Цифры результата не проверены независимо.

Три других примера: скорость, масштаб и цена ошибки

Klarna: быстрый запуск и разговор о качестве. Платёжная компания запустила ИИ-ассистента на моделях OpenAI в феврале 2024 года, и за первый месяц он обработал 2,3 млн диалогов, то есть две трети всех чатов поддержки. Он работал в 23 странах на 35 языках. Но в 2025 году компания начала возвращать людей-операторов, а руководство признало, что качество просело в пользу объёма.
Вывод: метрики запуска, то есть число диалогов, не показали того, что определяет успех.

МегаФон: постепенное расширение. ИИ-помощник «Ежедневный герой» запустили в декабре 2024 года на фокус-группе из 50 сотрудников, а к июлю 2025-го им пользовались больше 3 тысяч менеджеров по продажам. Здесь путь от пилота до масштаба занял около семи месяцев, и это тоже нормальный темп.

Технологии Доверия: измеримый результат. Через три месяца после запуска ассистента для ИТ-поддержки через него проходило около 20% обращений, из которых примерно 80% решались без участия специалиста, а нагрузка на поддержку снизилась примерно на 100 человеко-часов в месяц.

Что это значит для вашего проекта

AllSee называет похожий ориентир: MVP (минимально жизнеспособную первую версию) для ИИ-менеджера запускают до двух месяцев, а для медицинского центра он дал рост заявок из Telegram в 7 раз . Но «Домиленд» показывает, что за этими двумя месяцами стоит работа не над моделью, а над всем, что её окружает: доступами, проверками, тестами и подключением к реальным системам.

Итог

Два месяца до продакшена возможны, если у проекта есть владелец, узкий набор сценариев и заранее продуманные защита данных и тестирование. Сама модель в этой истории занимает меньше всего времени.