«Внедрить ИИ» — формулировка, за которой на практике скрываются совершенно разные по масштабу работы. Одной компании нужен агент, который годами живёт на сервере и разбирает входящие заявки. Другой — разовый прогон одного документа через связку нейросетей перед подписанием акта. Третьей автоматизация вообще ни к чему: важнее, чтобы команда сама умела ставить задачи агенту и проверять результат, без подрядчика на каждое изменение.

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

Случай 1. Проверка строительной сметы связкой нейросетей

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

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

Сначала система распознаёт файл и разбирает его на отдельные позиции: раздел, наименование работ, единица измерения, объём, расценка, итоговая сумма. Формат заранее неизвестен — Excel-таблица, PDF, скан бумажного документа, — распознавание подстраивается под то, что есть на руках.

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

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

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

Итог всей цепочки — список флагов: конкретных позиций и разделов, требующих внимания, с коротким объяснением, чем каждая позиция вызывает вопрос.

Что нашли. Задвоение позиций оказалось самой частой находкой — одна и та же работа попадает в смету дважды под разными формулировками или в разных разделах. Второй по частоте класс — арифметические ошибки в итогах: промежуточная сумма раздела расходится с суммой входящих в неё позиций, обычно после ручной правки одной строки без пересчёта остальных. Отдельно всплыли расценки, заметно превышающие справочные значения, и объёмы работ, расходящиеся между разделами — типичный след сметы, которую собирали по частям разные исполнители. И характерный класс, ставший для меня сюрпризом: «хвосты» от шаблона чужой сметы — документ часто собирается на основе более раннего файла по похожему объекту, и в готовой версии остаются позиции или расценки от прежнего проекта.

Грабли. Без шага нормализации вся проверка задвоений разваливается — система сравнивает текстовые строки буквально и пропускает синонимичные формулировки одной и той же работы. Пришлось строить отдельный слой, который приводит формулировки к общему виду первым делом, ещё до всех остальных проверок.

Вывод. Связка нейросетей делает грубый просев за минуты вместо часов ручной сверки: находит подозрительные позиции и объясняет, чем каждая выделяется. Решение по каждому флагу принимает сметчик — только человек с опытом понимает, оправдана расценка спецификой объекта или перед ним настоящая ошибка. Итоговую подпись такая проверка лишь ускоряет.

Случай 2. ИИ-агент разбора входящих заявок в лизинговой компании

Клиент — руководитель компании, которая сдаёт в лизинг контейнеры и крупное оборудование (название компании под NDA). Поток входящих заявок шёл руками: заявка приходит, её читают, вытаскивают из текста нужные параметры, передают дальше по процессу.

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

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

Итоговая цитата из рабочей переписки: «Я на сервере, бот в Telegram работает. Все прежние задачи теперь кажутся несерьёзными».

Вывод. Отдать клиенту работающий агент — только полдела. Ценность появляется, когда человек понимает архитектуру настолько, что может сам перезапустить систему, поправить промпт или добавить новое поле в разбор заявки — своими руками, без звонка подрядчику.

Случай 3. Боты подбора для автодилеров и агентств недвижимости

Здесь нет именного клиента — есть архетипичная задача, которую вижу на рынке снова и снова, под разными вывесками, но с одной и той же механикой.

Архитектура. Клиент пишет запрос в свободной форме — «нужен седан до двух миллионов, автомат, младше пяти лет» или «трёшка у метро, до сорока метров». Бот извлекает параметры из свободного текста, сопоставляет их с базой объявлений или каталогом, ведёт диалог: уточняет недостающие детали, предлагает варианты, при необходимости сужает или расширяет критерии.

Грабли. Качество подбора решает состояние базы, модель здесь вторична. Каталог с полными структурированными атрибутами (год, пробег, комплектация, район, площадь) даёт точный матчинг. Свалка текстовых описаний без атрибутов заставляет модель угадывать параметры из свободного текста объявления — и точность подбора падает вместе с этим. Второй риск — конфликтующие критерии: бюджет и требуемые опции клиента расходятся с любым объектом в базе, и без явного fallback на живого менеджера бот начинает выдавать натянутые компромиссы вместо честного признания, что подходящих вариантов сейчас нет.

Вывод. Там, где база остаётся неструктурированной, бот подбора превращается в красивую обёртку вокруг угадывания. Настоящая инвестиция здесь — в приведение каталога к структурированному виду прежде, чем за него берётся модель. Тонкая настройка промпта вторична.

Случай 4. RAG-боты по базам документов компаний

Тоже архетипичный запрос, безымянный: внутренний помощник, который отвечает сотрудникам по регламентам, договорам или базе знаний вместо того, чтобы человек искал документ вручную.

Архитектура. База документов индексируется в векторное хранилище. Запрос сотрудника превращается в вектор, система находит наиболее релевантные фрагменты и передаёт их в контекст модели вместе с вопросом. Ответ приходит со ссылкой на источник — конкретный документ и место в нём, откуда взято утверждение.

Грабли. Первая проблема — чанкинг: как резать документ на фрагменты так, чтобы сохранить смысл предложения или таблицы целиком. Слишком крупные куски засоряют контекст лишним, слишком мелкие — теряют связь между условием договора и его исключениями, которые часто вынесены в соседний абзац. Вторая проблема — устаревание: документы в компании обновляются, а переиндексация вручную быстро превращается в забытую рутину, и бот начинает уверенно отвечать по прошлогодней версии регламента. Третья — честность модели насчёт пустой выдачи: без явной проверки, что релевантный фрагмент действительно найден, система иногда генерирует правдоподобный ответ без реальной опоры в источнике.

Вывод. RAG закрывает вопрос «где найти регламент» надёжнее, чем поиск по ключевым словам, — но только пока индекс поддерживается в актуальном состоянии, а в контур встроена проверка на честный ответ «в базе такого нет».

Второй трек практики: передача компетенции команде

Часть практики устроена иначе, чем четыре истории выше — это осознанный принцип работы. Систему можно построить и отдать в виде чёрного ящика: работает, пока работает, а любое изменение снова ждёт подрядчика. Можно поступить иначе — довести команду до состояния, когда она сама ставит агенту задачи, проверяет результат и встраивает его в свои процессы.

Лондонский инвестфонд Launch Bay Capital пришёл с запросом обучить команду из восьми человек работе с ИИ-агентами — март-апрель 2026. Альтернатива в виде подрядчика на каждую задачу создаёт очередь: любое изменение процесса ждёт исполнителя, а компетенция остаётся снаружи компании вместо того, чтобы прорасти внутрь. Программа строилась на реальных задачах команды: новый инструмент показывался на экране, участники сразу повторяли его на своих рабочих задачах, между сессиями — домашние задания и чат с разбором вопросов. По итогу команда ведёт работу с ИИ-агентами самостоятельно. CEO фонда Николай Бобров написал в рабочей переписке: «Команду довёл до точки Б — супер. Рекомендации на тебя даю всем, кто звонит».

Похожая история — с InTime Brands, где к нам пришли два фаундера почти без опыта работы с нейросетями. Ещё до интенсива мы довели их рабочие места до готовности: развернули ИИ-терминалы с Claude на компьютерах фаундеров, с живой перепиской по нетривиальным сетевым настройкам. Дальше — двухчасовой Zoom-интенсив на реальных сценариях бизнеса. Сооснователь Роман Климонов подытожил: «Помогли с нуля развернуть рабочий терминал прямо на моём компьютере, настроили Claude, провели по реальным сценариям и ответили на все вопросы. Спокойно, по-человечески, без «сделали и ушли». Однозначно рекомендую».

Грабли, которые повторяются в проекте за проектом

Сопоставив эти истории, вижу один и тот же набор проблем под разными масками.

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

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

Деплой на стороне клиента — прежде всего вопрос доверия, а уже потом техническая деталь. Компания, которая пропускает переписку с клиентами или внутренние документы через чужой сервис, теряет контроль над данными. Агент на собственном сервере клиента снимает этот вопрос — но добавляет обучающую нагрузку: кто-то в компании должен понимать, что там происходит.

И последнее: автономность после сдачи проекта — либо главный критерий успеха, либо повод для беспокойства. Если команда после нашего ухода беспомощна перед своей же системой и снова звонит нам чинить или расширять её, это уже вечный контракт на поддержку под другим названием, а задача так и осталась нерешённой.

Итог

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

Тим Зинин, управляющий партнёр «Зинин, Штурбин и партнёры» — zinin-shturbin.com