ИИ-агент в строительной компании: где он окупается, а где нет

ИИ-агент окупается в строительной компании там, где есть повторяемая текстовая работа: разбор заявок, проверка КП, ответы по документации, сводки по объектам. Пилот на одном процессе занимает 4–8 недель и стоит от 300 тыс. до 1,5 млн рублей в зависимости от интеграций.

Сергей Езепенко · 15.11.2026 · время чтения 16 мин

Какие задачи в стройке агент закрывает уже сейчас

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

Разбор входящих заявок и заявок с площадок. Агент читает письмо или сообщение в чате, вытаскивает объект, вид работ, объём, желаемый срок, контакт и вложения, приводит к полям таблицы или карточки в CRM. Типовая заявка от прораба («нужен бетон М300, 12 кубов, на объект Ленина 14, к четвергу») превращается в строку с заполненными полями. Человек проверяет и подтверждает. Экономия — не в скорости набора, а в том, что заявки с почты, WhatsApp и Telegram попадают в одно место, и ничего не теряется в переписке. На потоке 80–150 заявок в неделю это высвобождает 6–10 часов менеджера, оценка зависит от дисциплины площадок.

Проверка КП поставщиков против сметы и спецификации. Агент сопоставляет позиции коммерческого предложения со строками сметы: наименование, единица измерения, объём, цена за единицу, сумма. На выходе — список расхождений: позиция есть в КП, но не в спецификации; объём отличается на 15%; цена выше согласованной; единица измерения не совпадает (тонны против метров). Решение остаётся за снабженцем, но ручной сверки построчно больше нет. На КП из 40–60 позиций проверка занимает минуты вместо часа-полутора.

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

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

Черновики писем и протоколов совещаний. По транскрипту или заметкам агент готовит черновик протокола: решения, ответственные, сроки. По контексту переписки — черновик письма подрядчику или заказчику. Это именно черновики: их правит и подписывает человек. Экономия — 20–40 минут на каждом совещании, но качество сильно зависит от разборчивости записи и от того, насколько участники называют себя.

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

Где ИИ-агент бесполезен и создаёт риски

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

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

Подписание актов КС-2 и КС-3 без человека. Формы КС-2 и КС-3 — документы, на которых держатся деньги и приёмка. Агент может сверить объёмы из акта с исполнительной документацией и сметой и подсветить расхождения, но подпись ставит человек с ответственностью по договору. Автоматическая отправка акта заказчику без проверки — прямой путь к спору об объёмах, который придётся разбирать уже в арбитраже.

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

Работа с чертежами без отдельной модели распознавания. Текстовый агент не читает DWG и PDF с чертежами так, как их читает инженер. Без отдельного решения по распознаванию (векторизация, извлечение спецификаций, привязка к координатам) попытка «спросить у ИИ про узел на листе» даёт уверенные, но неверные ответы. Если в компании нет проекта по оцифровке чертежей, этот сценарий лучше не запускать вовсе.

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

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

Три типа агентов: чат, автоматизация, оркестратор

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

Чат-ассистент. Сотрудник задаёт вопрос в интерфейсе — в мессенджере, в CRM или в отдельном окне — и получает ответ со ссылкой на источник. Прораб спрашивает, какой класс бетона указан в спецификации на секцию 3, снабженец — какой поставщик щебня последний раз срывал срок, инженер ПТО — что написано в п. 4.2 договора подряда по срокам приёмки. Агент ищет по загруженным документам и возвращает цитату с номером страницы. Ничего не меняется в системах: он только читает и отвечает. Это самый дешёвый и быстрый тип запуска — от двух до четырёх недель на подготовку базы и настройку, если документы уже лежат в электронном виде. Ценность здесь конкретная: сокращение времени на поиск информации. На стройке это обычно 15–40 минут в день на человека — звонки, листание PDF, вопросы коллегам.

Автоматизация процесса. Здесь агент сам инициирует действие по событию. Пришло письмо от поставщика о переносе отгрузки — агент читает текст, вытаскивает номер заявки, дату и позицию, создаёт запись в CRM или в 1С, ставит задачу снабженцу и прикладывает исходное письмо. Пришёл акт КС-2 от субподрядчика — агент сверяет суммы и объёмы со сметой и, если расхождение выше порога, помечает документ и отправляет на проверку. Ключевое отличие от чата: сотрудник не спрашивает, агент действует по регламенту. И здесь нужны правила — что делать при неоднозначности. Рабочая схема: если уверенность ниже заданного порога или в письме нет обязательного поля, агент не угадывает, а создаёт черновик и передаёт человеку.

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

Порядок внедрения диктуется не амбициями, а стоимостью ошибки. Чат ошибается безболезненно — сотрудник видит неверный ответ и переспрашивает. Автоматизация уже пишет в учётную систему, и ошибка стоит денег. Оркестратор ошибается цепочкой. Поэтому последовательность «чат → автоматизация → оркестратор» — не осторожность, а способ накопить данные о том, где именно агент промахивается, до того как он получит право менять записи в 1С и календаре. Подробнее о том, чем агент отличается от сценарного бота, разобрано в материале Чем ИИ-агент отличается от чат-бота и что выбрать бизнесу.

Данные: что нужно подготовить до запуска

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

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

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

История переписки и заявок за 6–12 месяцев. Это материал, на котором агент учится различать типовые ситуации: письмо о переносе отгрузки, претензия по качеству, запрос КП, согласование пропуска на объект. Год истории покрывает сезонный цикл — зимние простои, весенний рост объёмов, сдачу объектов в конце года. Половина писем за такой период — типовые, и именно на них настраиваются правила разбора. Без истории агент работает «на общих знаниях» и путает формулировки конкретных заказчиков.

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

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

Ответственный за актуальность базы знаний. Без назначенного человека база деградирует за квартал: регламенты меняются, появляются новые объекты, уходят контрагенты. Нужна роль — обычно это руководитель ПТО или сотрудник службы качества — с задачей раз в две недели проверять новые и изменённые документы и обновлять базу. Это 2–4 часа в месяц, но без них агент через полгода начнёт ссылаться на отменённые приказы.

Порядок подготовки, который работает на практике:

1. Инвентаризация: список источников, владельцев и версий.
2. Чистка: убрать дубликаты и черновики, зафиксировать актуальные редакции.
3. Перевод в машиночитаемый вид: сметы, спецификации, таблицы.
4. Разметка прав доступа по категориям.
5. Назначение ответственного и регламента обновления.

Общий план первого запуска с оценкой сроков и ролей разобран в статье ИИ-агент для малого бизнеса: практический план первого запуска.

Интеграции: 1С, CRM, почта, мессенджеры, смета

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

1С и CRM. Здесь два рабочих варианта. Первый — прямой обмен по API, если у вас 1С:УПП, «1С:ERP» или свежая «1С:Бухгалтерия» с опубликованным HTTP-сервисом, а CRM поддерживает REST. Второй — промежуточный сервис (интеграционная шина или простой брокер очередей), который забирает данные из 1С по расписанию и отдаёт агенту в нормализованном виде. Прямой обмен быстрее в разработке, но при обновлении конфигурации 1С ломается чаще. Промежуточный слой дороже на старте, зато переживает обновления и снимает нагрузку с учётной системы. Для строительной компании типовой набор сущностей: контрагенты, договоры, номенклатура материалов, остатки по складам, статусы оплат. Агент должен не просто читать — он должен писать: создавать заявку, ставить комментарий к сделке, менять статус задачи. Если доступ только на чтение, половина сценариев отпадает.

Почта и мессенджеры. Это основной канал заявок в стройке: прораб пишет в WhatsApp, снабженец — на почту, заказчик — в Telegram. Агент подключается к ящику по IMAP/SMTP или через API почтового сервиса, к мессенджерам — через официальные боты-платформы. Важно заранее решить, где живёт история переписки: если она остаётся только в мессенджере, при смене подрядчика вы теряете контекст. Разумно дублировать диалоги в CRM или отдельное хранилище.

Сметные программы. «Гранд-Смета», «РИК», «Смета.ру» и аналоги плохо отдают данные напрямую. Рабочий путь — выгрузка в XML или Excel по шаблону и разбор на стороне агента. Агент читает смету, вытаскивает объёмы, сопоставляет с номенклатурой и формирует запрос на закупку. Полноценная двусторонняя интеграция со сметным комплексом — отдельный проект на месяцы и редко окупается; выгрузки хватает в 80% случаев.

Пример из практики. Компания с оборотом порядка 400 млн рублей в год запускала агента для отдела снабжения. Первая версия отвечала на вопросы по остаткам, но не могла создать заявку в 1С — снабженцы продолжали заводить её руками, и агент остался игрушкой в чате. После подключения записи через промежуточный сервис доля заявок, оформленных агентом, выросла до 60% за два месяца.

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

Как выбрать модель и подрядчика

Выбор модели — это в первую очередь вопрос к данным, а не к бенчмаркам. В строительстве агент касается договоров, смет, персональных данных заказчиков, иногда — проектной документации с грифом. Если такие данные уходят в зарубежный API, вы обязаны проверить основания обработки по 152-ФЗ, а для отдельных категорий — получить согласие субъектов и оценить трансграничную передачу. Российские модели (YandexGPT, GigaChat, семейство T-Bank) решают эту часть проще: данные остаются в российском контуре, у провайдеров есть документы для проверки. Стоимость токена у них выше, чем у зарубежных, — разница в среднем по рынку в 2–4 раза, но она окупается снятием юридических рисков.

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

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

Что зафиксировать в договоре, кроме сроков:

1. Метрику качества. Например: доля заявок, корректно разобранных агентом без правки человеком, — не ниже 85% на тестовой выборке из 200 обращений. Или точность ответа на вопросы по остаткам — не ниже 90%. Метрика должна измеряться на ваших данных и вашей командой.
2. Методику замера. Кто формирует выборку, кто размечает, сколько итераций доработки входит в цену.
3. Порядок передачи. Код, промпты, схемы интеграций, документация — ваши при расторжении.
4. Ответственность за деградацию. Что происходит, если после обновления модели качество падает ниже порога.

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

Пилот за 6 недель: этапы и метрики

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

Недели 1–2. Выбор процесса и сбор данных. Задача — зафиксировать один процесс, где есть повторяющиеся операции, понятный вход и проверяемый выход. В строительной компании это чаще всего разбор входящих заявок и раскладка их по объектам, проверка комплектности пакета документов по подрядчику, первичная сверка спецификаций с прайсом поставщика или подготовка черновиков ответов на типовые запросы. Владелец процесса — конкретный человек, например руководитель отдела снабжения или начальник ПТО, — выделяет 50–100 реальных примеров: письма, таблицы, акты, заявки. Важно брать именно «грязные» данные, как они приходят в работе, а не причёсанные образцы. Параллельно описывается текущий процесс в цифрах: сколько операций в день, сколько минут на одну, кто и что правит руками.

Недели 3–4. Сборка агента и тест на исторических данных. Агент собирается под конкретный процесс: набор инструкций, доступ к справочникам (номенклатура материалов, список объектов, реестр контрагентов), правила эскалации к человеку. Тестирование идёт на отложенной части исторических примеров — тех, что не использовались при настройке. Считается точность по каждому типу операции отдельно: агент может хорошо разбирать заявки и плохо — распознавать позиции в сканах спецификаций. На этом этапе появляется первый список правок: что именно человек исправляет после агента.

Недели 5–6. Теневой режим. Агент работает рядом с человеком, но его результат не уходит в дело — сотрудник выполняет операцию как обычно, а вывод агента сравнивается с его работой. Это снимает риск ошибки в реальных документах и даёт честную статистику. По итогам двух недель собираются метрики:

1. Точность — доля операций, где результат агента совпал с эталоном или был принят без изменений.
2. Доля ручных правок — сколько операций сотрудник переделал и насколько существенно.
3. Время на операцию — среднее время с агентом против среднего без него, включая время на проверку.

Пример из практики: подрядная организация тестировала агента на разборе заявок на материалы. На исторических данных точность по типовым позициям была около 88%, в теневом режиме упала до 79% — сказались сокращения и опечатки в письмах с объектов. Зато время на первичную раскладку заявки сократилось с 12 до 4 минут, а доля заявок, требующих полной ручной переделки, составила порядка 9%. Этого хватило, чтобы запустить процесс в работу с обязательной проверкой человеком на позициях без точного совпадения номенклатуры.

Если процессов несколько и непонятно, с чего начинать, полезен материал ИИ-агент для малого бизнеса: практический план первого запуска.

Бюджет, сроки и типичные ошибки внедрения

Стоимость пилота в строительной компании — от 300 тыс. до 1,5 млн рублей. Разброс определяется тремя вещами: сколько интеграций нужно (почта, 1С, CRM, файловое хранилище), насколько грязные данные и кто делает работу — внешняя команда или свои инженеры с внешним консультантом. Верхняя граница — это когда к агенту подключают учётную систему и настраивают двусторонний обмен, а не просто разбор писем. Промышленный запуск — от 2 до 6 млн рублей: здесь добавляются отказоустойчивость, разграничение прав доступа, журналирование действий агента, регламенты для сотрудников и обучение. Сроки: пилот 6–8 недель, промышленный запуск ещё 2–4 месяца в зависимости от числа процессов и интеграций. Цифры ориентировочные, зависят от контура компании и требований к безопасности.

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

Ошибка вторая — нет владельца процесса. Если за внедрение отвечает только ИТ или только подрядчик, а начальник ПТО или отдела снабжения не участвует, агент настраивается под выдуманный процесс. На практике это выглядит так: агент корректно разбирает заявки по шаблону, но в компании половина заявок приходит голосовыми в мессенджер и фотографиями рукописных списков. Владелец процесса знает эти детали, без него пилот проверяет не то.

Ошибка третья — не считать стоимость токенов и поддержки. Демо на десяти примерах стоит копейки, а рабочий поток в 500–1000 операций в день — уже регулярные расходы на модель. К ним добавляются: доработка инструкций при изменении номенклатуры и регламентов, разбор инцидентов, обновление справочников, контроль качества. По опыту, поддержка съедает порядка 15–25% бюджета внедрения в год, и эту строку нужно закладывать сразу, а не открывать после запуска. Отдельно стоит посчитать стоимость ошибки: если агент неверно определил объём материала, экономия на токенах обернётся перезаказом.

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

Практический ориентир: считайте совокупную стоимость владения на горизонте года — пилот, запуск, токены, поддержка, время сотрудников на проверку — и сравнивайте с экономией часов на операциях. Если разница меньше 20–30%, масштабировать рано.

Автор: Сергей Езепенко, основатель «Системы Поток». Работаю с клиентами с 2018 года, 20 запущенных проектов: стройка, медицина, юруслуги, недвижимость, онлайн-школы.