Здесь два вида материала. Первый - мои собственные проекты: инструменты, которые я построил и которыми пользуюсь сам, с технической изнанкой и с тем, что в них не заработало. Второй - разбор опубликованных кейсов российских компаний, где разбирается, какая часть заявленного проверяема, а какая осталась за кадром.
Клиентских внедрений с раскрытыми цифрами на этой странице нет. Появятся согласованные к публикации - встанут первым разделом. Пока их нет, полезнее показать техническую сторону работы и дать критерии, по которым читатель сам разберёт любой чужой кейс.
Как читать чужие кейсы внедрения ИИ
Опубликованный кейс почти всегда отвечает на вопрос «что мы сделали» и почти никогда на вопрос «с чем сравнивали». Разница между этими двумя ответами и есть вся ценность кейса.
Вот шесть признаков, по которым видно, стоит ли за текстом работающая система.
| Признак | Что он значит | Какой вопрос задать автору кейса |
|---|---|---|
| Названа база сравнения | Результат посчитан от замера, а не от ощущения «стало лучше» | Что и как измеряли до начала работ |
| Измерен исход, а не активность | «Обработано 3000 обращений» растёт само по себе, стоит систему включить | Сколько обращений закрылось без участия человека |
| Сказано, что осталось ручным | Автор видит границы своей системы и не обещает полной автоматизации | Какие случаи система не берёт и кто их разбирает |
| Указан срок наблюдения | Две недели после запуска и год эксплуатации дают разные картины | Сколько система проработала до момента, когда посчитали результат |
| Описано поведение при отказе | У системы есть очередь для сбоев, а не только счастливый путь | Куда уходит задача, когда модель ошиблась |
| Назван человек со стороны заказчика | Кейс согласован внутри компании, а не собран по памяти | Кто отвечал за проект и подтвердил публикацию |
Ни один признак поодиночке не приговор. Но если из шести отсутствуют четыре, перед вами рекламный текст, и читать его стоит соответственно.
Мои проекты
Дальше четыре проекта, отобранные по близости к задачам бизнеса. Каждый помечен как собственный проект: это инструменты, которые я построил для себя, а не внедрения в чужих компаниях. Цифр экономии в них не будет, потому что взять их неоткуда, а выдуманные обесценят всё остальное на сайте.
Entity SEO Intelligence
Собственный проект. Задача была в том, чтобы понять, как поисковая система видит бренд через сущности своего графа знаний, и отследить изменения во времени.
Устроено так. Тринадцать инструментов, доступных модели по протоколу MCP (стандартный способ дать модели доступ к внешним функциям), граф-база Kuzu вместо обычных таблиц, дашборд на Streamlit и сто пятнадцать автотестов. Аудит бренда сохраняется снимком, следующий сравнивается с предыдущим, расхождения видны построчно.
Что сработало. Хранение сущностей в графе. Связи между брендом, персоной и темами это и есть граф, и запрос про такие связи пишется коротко, вместо многоэтажного соединения таблиц. Снимки с построчным сравнением дали то, ради чего всё затевалось: изменение видно сразу, а не выводится глазами из двух отчётов.
Что не сработало. Главная функция повисла на внешнем интерфейсе Google Knowledge Graph, у которого есть риск отключения, а поисковый индекс CSE ограничен сотней запросов в сутки. В планах перенос источника на Wikidata.
Чем полезно бизнесу. Ровно так же ведёт себя любая система на чужом API. Пока он бесплатный и работает, всё хорошо; в день отключения система теряет свою главную функцию. Вопрос «что мы делаем, когда этот сервис закроется» задаётся до старта, а не после.
Gemini Light RAG
Собственный проект. Задача была в том, чтобы небольшая команда отвечала на вопросы по своим документам, не разыскивая нужный абзац в регламентах руками.
Устроено так. Документы индексируются файловым поиском Gemini, ответ собирается из найденных фрагментов и приходит вместе со ссылкой на источник. Это и есть RAG, генерация ответа с подстановкой найденных кусков документов. Бекенд на Firebase и облачных функциях, доступ по ролям администратора, редактора и читателя, кеш ответов с ограниченным сроком жизни.
Что сработало. Ссылка на источник рядом с ответом. Без неё сотрудник открывает те же документы и перечитывает их сам, и экономии не остаётся вовсе. Кеш тоже отработал: повторный вопрос не уходит в модель второй раз.
Что не сработало. Схема получилась целиком облачной, документы уходят на индексацию в чужой сервис. Для команды из пяти человек это приемлемо. Для компании, где выгрузка документов наружу запрещена, проект в таком виде не применим, и переделывать пришлось бы весь слой хранения.
Чем полезно бизнесу. Вопрос о том, где физически будут лежать ваши документы, решается до выбора модели. Переносить готовую систему в закрытый контур дороже, чем сразу собрать её там, и требования по персональным данным тут добавляют собственных ограничений.
Reviews-WB
Собственный проект. Задача была в том, чтобы обрабатывать поток отзывов покупателей на маркетплейсе без ручного разбора каждого.
Устроено так. Шесть агентов на моделях Claude Haiku и Sonnet, то есть шесть отдельных вызовов модели, у каждого своя узкая роль и свои инструкции. Основная цепочка - три шага:
- Разбор отзыва. Первый агент вытаскивает структуру из свободного текста.
- Ответ. Второй определяет тональность, выбирает маршрут и пишет персональный ответ.
- Проверка. Третий ищет в ответе выдумки и оценивает качество.
Негативный отзыв уходит на подтверждение менеджеру, позитивный публикуется сам.
Что сработало. Отдельный проверяющий шаг. Модель, которая написала ответ, плохо проверяет саму себя, а агент с единственной задачей «найди в ответе то, чего не было в отзыве» ловит выдумки заметно лучше. Маршрут по тональности тоже оправдался: подтверждение человеком стоит там, где ошибка видна публично.
Что не сработало. Проект остался привязан к одному маркетплейсу. Ozon, Яндекс.Маркет и Avito лежат в планах, и это та самая работа, которую недооценивают: логика ответов переносится за день, а стыковка с чужим интерфейсом занимает недели. Настройки голоса бренда там тоже нет, тон зашит в промпты.
Чем полезно бизнесу. Поток отзывов устроен так же, как поток обращений в поддержку, и переносится почти без изменений. А ощущение «мы это быстро подключим ко второй системе» стоит делить как минимум надвое.
Mamba Trading Bot
Собственный проект. Задача была в том, чтобы проверить, может ли модель принимать торговые решения по историческим рядам, и что для этого нужно построить вокруг неё.
Устроено так. Модель на архитектуре Mamba-2, это класс моделей для длинных последовательностей. Обучение с подкреплением, разметка сделок методом трёх барьеров, отдельный блок риска. Индекс турбулентности Махаланобиса блокирует торговлю, когда рынок ведёт себя аномально, и этот запрет живёт в коде, а не в инструкции для модели.
Что сработало. Как раз блок риска. Ограничение, вынесенное наружу от модели, работает независимо от того, что модель думает о рынке: у неё физически нет возможности совершить сделку в запрещённый момент.
Что не сработало. Живых денег бот не видел. Проверен он на исторических данных четырёх активов, подключение к брокеру и проверка на скользящем окне остались в планах. Честная формулировка - «работает на бэктесте», и любые выводы про эксплуатацию тут преждевременны.
Чем полезно бизнесу. Разрыв между «на тесте показатели хорошие» и «система работает в бою» - это тот же разрыв, что между демо и продакшеном. Подробнее про такие ограничения написано в материале о том, как устроен человек в контуре.
Остальные работы лежат на странице, где собраны все мои проекты.
Что видно на этих проектах
| Проект | Что решает | Что из этого применимо в бизнесе |
|---|---|---|
| Entity SEO Intelligence | Отслеживает, как поисковик видит бренд | Работа со связанными данными и контроль зависимости от чужого интерфейса |
| Gemini Light RAG | Отвечает на вопросы по документам команды | Ассистент по базе знаний с обязательной ссылкой на источник |
| Reviews-WB | Обрабатывает поток отзывов с маршрутизацией и проверкой | Разделение ролей между моделями и подтверждение там, где ошибку видит клиент |
| Mamba Trading Bot | Принимает решения по рядам данных под ограничениями | Запреты, вынесенные в код, и граница между тестом и эксплуатацией |
От проекта к проекту повторяется одно. Модель редко оказывается главной частью системы, главное собирается вокруг неё:
- Откуда берутся данные. Пока чужой интерфейс отдаёт их бесплатно, всё работает; в день отключения система теряет главную функцию.
- Кто проверяет результат. Модель, написавшая ответ, плохо проверяет саму себя, поэтому проверка выносится в отдельный шаг.
- Что модели запрещено на уровне прав. Запрет, вынесенный в код, действует независимо от того, что модель думает о ситуации.
- Куда уходит задача, когда что-то не вышло. У системы есть очередь для сбоев и человек, который её разбирает.
Автоматизация бизнес-процессов ломается именно в этих местах, а не на выборе большой языковой модели.
Как эта техническая часть выглядит внутри услуги, описано на страницах про разработку ассистентов и агентов и про внедрение под ключ.
Разбор опубликованных кейсов рынка
Дальше четыре публичных материала, разобранных по критериям из первого раздела. Цель тут не оценить компании, а показать, где в кейсе проходит граница между посчитанным и заявленным. Ссылки ведут на первоисточники, снимки страниц сделаны 4 августа 2026 года.
Калькулятор окупаемости kt-team
Заявлено: внедрение по одному процессу за 300 000 ₽ при доле автоматизируемого в 60%, в примере на восемь ролей бэк-офиса выходит 5,7 млн ₽ вложений против 9 млн ₽ высвобожденного ФОТ в год (kt-team.ru). Проверяемо тут многое: методика открыта, параметры расчёта видны и меняются под свои цифры. Но это модель, а не отчёт по факту. Доля 60% задана допущением, а высвобожденный ФОТ становится деньгами только тогда, когда людей действительно перевели на другую работу.
Чат-ассистент в amoCRM у innovaai
Заявлено: за полтора месяца ассистент принёс более 500 000 ₽ дополнительной выручки, 82% чатов доведены до заявки, 60-70% лидов дошли до продажи (innovaai.ru). Срок наблюдения назван прямо, и это редкость. Не названа база сравнения: сколько тот же канал приносил до запуска и что ещё менялось в эти полтора месяца. Доля чатов, доведённых до заявки, измеряет активность, а выручка приписана ассистенту целиком.
Экономия в кейсах DUC Technologies
Заявлено: экономия от 100 000 до 2 млн ₽ в год, до 80% времени команды, а в примере с ассистентом для кадровой службы затраты времени на оформление документов падают на 80% (duc-technologies.ru). Отрасли перечислены, и это лучше безымянных «клиентов из разных сфер». Формулировка «до 80%» задаёт верхнюю границу без указания, на какой доле обращений она достигнута. Разброс экономии в двадцать раз говорит о компаниях очень разного размера, а какие они, в кейсе нет. Срока наблюдения тоже нет.
Разбор 50 российских кейсов на vc.ru
Заявлено: окупаемость за 3-6 месяцев, доля провалов около 23%, возврат вложений 150-400% за полгода (vc.ru, 18.10.2025). Автор сообщает, что вознаграждения от упомянутых компаний не получает, а кейсы собраны из открытых источников. Методология отбора и способ расчёта возврата вложений не раскрыты, поэтому такие цифры я использую как ориентир со ссылкой на публичный разбор, а не как факт. Доля провалов при этом полезна сама по себе: почти каждый четвёртый проект не доходит до результата.
Почему здесь нет клиентских кейсов
Причина одна и простая. Письменного разрешения на публикацию у меня нет ни по одной работе, а показывать чужие процессы и цифры без него нельзя. Обезличивание тут не спасает: по описанию задачи компания часто узнаётся, и это та же публикация, только с отрицанием.
Что вместо этого. Техническую часть я готов показать на созвоне:
- Как устроены доступы. Что система читает, что меняет и чего не может в принципе.
- Где стоит подтверждение человеком. Какие действия уходят на согласование, а какие выполняются сами.
- Что происходит при отказе. Куда уходит задача, когда модель ошиблась или упала соседняя система.
- Как выглядит журнал сбоев. По каким записям потом разбирают, что пошло не так.
Это проверяется вопросами и не требует ничьего разрешения.
Страница будет пополняться. По завершённым работам разрешение я теперь запрашиваю сразу, пока результат свежий; согласованные кейсы встанут первым разделом, собственные проекты сдвинутся ниже. Дата последнего обновления видна на странице, и по ней понятно, живая эта витрина или брошенная.
Частые вопросы
Чем ваши проекты отличаются от демо, которое мне уже показывали?
Тем, что у каждого написано, где он ломается, и это проверяемо на созвоне. Демо показывает счастливый путь: заранее подобранный запрос, чистые данные, никаких сбоев интеграции. Разница вылезает на втором шаге. Спросите у любого подрядчика, что произойдёт, когда упадёт вторая система в цепочке.
У вас нет кейса в моей отрасли, это проблема?
В части ожиданий да, в части работы обычно нет. Отраслевой кейс отвечает на вопрос «получится ли у нас», и заменить его нечем. Но техническая часть между отраслями переносится почти без изменений: поток отзывов и поток обращений в поддержку устроены одинаково, отличаются словарь и цена ошибки. Проверять стоит не отрасль в портфолио, а то, работал ли человек с вашим типом процесса.
Можно ли верить цифрам экономии в чужих кейсах?
Как ориентиру да, как обещанию нет. Цифра из кейса посчитана на чужих объёмах, чужих зарплатах и чужой доле типовых обращений. Полезнее взять из кейса методику, а числа подставить свои: сколько минут уходит на операцию сейчас, сколько будет уходить с проверкой человеком и сколько таких операций в месяц. Когда методики нет, а есть только итог, считать по нему нечего.
Что будет, если я попрошу показать работающую систему?
Покажу собственные проекты с этой страницы: код, схему доступов, поведение при отказе. Клиентские системы показать не могу по той же причине, по которой их тут нет. Отдельно предупрежу: свои проекты я строил под свои требования, и по ним нельзя судить, сколько времени займёт ваша задача. Сроки считаются по вашему процессу.
Сколько стоит проверить это на моей задаче?
Первый шаг бесплатный: разбор на тридцать минут, где мы смотрим процесс и я называю, где ИИ даст толк, а где не нужен. Дальше пилот от 150 000 ₽ в 2026 году, фиксированная цена и одна задача, на выходе либо работающий результат, либо обоснованный отказ от идеи. Полная лестница с условиями зачёта разобрана на странице, где написано, сколько стоит каждый шаг.
Что дальше
Общая карта темы, от выбора первой задачи до этапов работ, лежит в материале про внедрение ИИ в бизнес. Если хотите проверить свою задачу, а не читать про чужие, начните с бесплатного разбора: полчаса по видео, смотрим процесс и цену ошибки на каждом шаге.
Написать можно в Telegram или на почту hi@za-ai.ru.