Информационные технологии в строительстве: с чего начать внедрение ИИ

Девелопер вёл объекты в 1С:БИТ.Строительстве, где живут график работ, объёмы, сметы и акты выполненных работ, документы ходили через ЭДО (электронный документооборот) с подрядчиками и проектировщиками, а часть план-факта по небольшим объектам считалась в Excel. Информационные технологии в компании были — учётная система, электронный документооборот, отчётность. Не было другого: данные каждого объекта оставались разрозненными, и любое решение по отклонению в работах собиралось руками — инженер ПТО (производственно-технический отдел) выгружал факт, сводил его с планом, поднимал документы и переписку, после чего писал пояснение руководителю проекта.

Рынок уже прошёл стадию «купим систему и всё наладится». По отчёту Strategy Partners, опубликованному на портале ICT.Moscow, цифровизация строительства в России переходит из повестки внедрения отдельных инструментов в повестку качества данных: готовность проектной модели, графика и стоимости факта работ к машинной обработке определяет, где ИИ вообще даст эффект. Аналитики прямо предлагают оценивать цифровизацию через снижение потерь — переделок, задержек согласований, ошибок в документации, отклонений графика и бюджета. Показательна цифра по ключевому барьеру: почти весь оставшийся регуляторный путь цифровизации связан именно с работой с данными, их машинной обработкой и интеграцией систем — то есть с тем, что агенту нужно на входе.

Масштаб вопроса не теоретический. По исследованию консалтинговой компании «Яков и Партнёры», которое приводит TAdviser, сквозная цифровая трансформация процессов с использованием ИИ способна приносить строительной отрасли около 0,9 трлн руб. в год, при этом маржинальность девелоперов уже упала с 9–11% в 2022 году до 3–5% в 2025-м, а производительность в строительстве — 1,4 млн руб. валовой добавленной стоимости на занятого против 1,8 млн руб. в большинстве других отраслей. И там же названа главная причина, по которой эффект не приходит сам: около 90% компаний фиксируют положительный результат пилотов, но лишь каждая пятая способна измерить его количественно. Препятствия при этом управленческие, а не технологические — качество данных, отсутствие стратегии, размытая ответственность. Дальше разбираем, как из этой ловушки выйти и с чего начинать.

Коротко

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

Содержание

• Почему «купить ещё одну систему» — не первый шаг
• С чего начать: три первых шага, которые дают эффект
• Что делает ИИ-агент поверх существующих систем
• Какие риски это снимает
• Сколько часов это возвращает
• Что остаётся за человеком
• Как это выглядит на практике
• Как внедрить поэтапно
• Что в итоге
• Источники

Почему «купить ещё одну систему» — не первый шаг

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

Системы есть, а данные к машинной обработке не готовы

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

Эффект приходит от снижения потерь, а не от факта внедрения

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

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

С чего начать: три первых шага, которые дают эффект

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

Шаг 1. Навести порядок в данных одного контура

Не во всей компании, а в одном участке, который вы выбрали для пилота. Это значит: договориться, что источник истины по этому процессу один; свести в машинночитаемый вид те поля, по которым принимается решение (позиция графика, объём, срок, подрядчик, статус документа); убрать ручные вставки там, где они ломают связку. Такую подготовку не обязательно делать большой ИТ-программой: почти всегда достаточно навести порядок в справочниках, привести выгрузки к одному формату и закрыть несколько «дырок», где данные вводятся по-разному разными людьми. Это самая неблагодарная и самая недооценённая часть работы — и именно она определяет, будет ли у ИИ что читать.

Шаг 2. Выбрать один процесс с ручной сверкой

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

Шаг 3. Поставить тонкий слой агента поверх системы

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

Что делает ИИ-агент поверх существующих систем

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

1. Читает данные и документы. Забирает позиции графика, фактические объёмы, акты выполненных работ и связанные документы из учётного контура и электронного документооборота, приводя их к одному виду.
2. Сверяет факт с планом. По каждой позиции считает отклонение в натуральных единицах и днях, отделяя отставание физическое от документального — когда работы выполнены, а акт не закрыт.
3. Сопоставляет связанные участки. Одно отставание почти никогда не изолировано: за ним стоят незакрытые объёмы предыдущего этапа и подрядчик, который не вывел людей. Агент поднимает эти связи в одном разборе.
4. Восстанавливает историю по подрядчику. По конкретному отклонению собирает, что этому подрядчику уже выставляли, к какому сроку он обещал выйти и срывал ли раньше. Это самый дорогой ручной шаг — восстановление контекста.
5. Оценивает влияние на срок. Показывает, какие отклонения способны сдвинуть сдачу объекта, а какие закрываются внутри резерва.
6. Готовит разбор и список действий. На выходе — короткая сводка: позиция, отклонение, причина, критичность, предлагаемое действие и владелец. Сводка возвращается в систему, в журнал проекта.
7. Ведёт журнал действий. Каждое срабатывание записывается: какие данные прочитаны, какое правило применено, какое расхождение найдено. По журналу работу агента можно проверить — это и отличает рабочий контур от демонстрации интерфейса.

Чего агент не делает: не переписывает график, не меняет сроки, не закрывает объёмы и не выставляет требования подрядчику. Он готовит разбор и напоминает о сроке, а решение остаётся за человеком. Тот же принцип работает и в других отраслях: например, как устроена ИИ-ассистент для строительства НОВАЦИЯ и демонстрация на объекте, где агент читает данные объекта и готовит материалы, не подменяя специалиста.

Какие риски это снимает

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

Переделки, которые съедают стоимость проекта

Самый дорогой риск — работа, которую приходится переделывать. По сводке данных PlanRadar о стоимости переделок в строительстве, они составляют 5–10% стоимости проекта, а на плохо контролируемых проектах доходят до 20%. Переделка редко бывает следствием одной ошибки — чаще это пропущенное расхождение: не тот объём, устаревшая версия документа, несогласованный участок. Когда такой расхождением ловит агент на этапе данных, а не приёмка на объекте, переделка не превращается в расход.

Предписание и остановка работ

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

Штраф по закону

Нарушение требований проектной документации — это уже не организационная, а юридическая ответственность. По статье 9.4 КоАП, для юридического лица штраф составляет 100–300 тыс. ₽; если нарушение затрагивает надёжность и безопасность и создаёт угрозу вреда, это 300–600 тыс. ₽ либо приостановление деятельности до 60 суток; при повторном нарушении — 700 тыс. – 1 млн ₽ либо до 90 суток. Норма дана по тексту кодекса на consultant.ru (ссылка в источниках). Дисциплина данных и своевременный разбор отклонений снижают вероятность получить такое предписание, а не «оптимизируют процессы» в общем виде.

Возврат комплекта на пересогласование

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

Спор с заказчиком без доказательной базы

Без связанного комплекта и истории переписки доказать, что работы выполнены в срок и в объёме, сложно. Журнал агента и связанные документы дают ту самую фактуру, на которую можно опереться в споре, — а не «мы это делали, но подтвердить нечем».

Зависимость от конкретного человека

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

Сколько часов это возвращает

Часы — уже следствие порядка в данных и агента поверх. Ниже типовой расчёт для девелопера с портфелем из шести объектов и объёмом около 240 позиций графика в месяц; стоимость часа инженера ПТО принята в 900 ₽ по рынку региона.

В ручном контуре сверка одной позиции занимает в среднем 9 минут (выгрузка факта, сопоставление с планом, подъём акта и переписки, короткое пояснение). На 240 позиций это около 36 часов в месяц. Плюс сборка сводки по всем объектам в отдельном файле — около 6 часов, и восстановление истории по подрядчику по спорным отклонениям — около 8 часов. Итого около 50 часов в месяц.

В контуре с агентом черновую сверку и подъём истории делает агент, а человек проверяет исключения и принимает решения: около 14 часов в месяц остаётся на разбор сводок и решения. Высвобождается порядка 35 часов в месяц, это около 31 500 ₽ на портфеле при 900 ₽/час, или около 378 000 ₽ в год. На одном объекте из портфеля экономия пропорционально меньше — около 6 часов, на трёх объектах — около 18 часов в месяц.

Показатель	Вручную	С агентом
Сверка план-факта по 240 позициям	36 ч	10 ч
Сводка по всем объектам	6 ч	1 ч
Восстановление истории по подрядчику	8 ч	3 ч
Итого в месяц	50 ч	14 ч

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

Что остаётся за человеком

Границы ответственности важны не меньше эффекта — именно они делают контур управляемым, а не пугающим.

• Решение по отклонению. Менять ли последовательность работ, перебрасывать ли бригады, требовать ли от подрядчика — решает человек.
• Подпись и передача обязательств. Агент не подписывает акты, не выставляет требования и не ведёт переписку с заказчиком.
• Оценка качества данных. Если источник расходится или данные устарели, решение о правке принимает человек, а не агент «на глаз».
• Стратегия и приоритеты. Что автоматизировать следующим и где остановиться — управленческое решение, а не функция программы.

Как это выглядит на практике

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

Как внедрить поэтапно

1. Уточнить процесс и потерю. Назвать конкретный участок и потерю, которую снимаем, в измеримых единицах: часы на сверку, число пропущенных расхождений, срок от отклонения до решения.
2. Проверить данные. Убедиться, что источники по процессу доступны, а поля, по которым принимается решение, заполняются. Здесь же закрываются очевидные дырки в справочниках и форматах.
3. Зафиксировать замер до. Посчитать часы и объём ручных сверок на текущем контуре — без этой цифры сравнивать будет не с чем.
4. Запустить пилот на одном процессе. Тонкий слой агента поверх системы, без перестройки учётного контура; на входе — данные одного-двух объектов.
5. Проверить результат на выборке. Сверить работу агента с ручным разбором: если расхождений нет, правило работает; журнал действий показывает, на чём основан вывод.
6. Расширить, если метрика изменилась. Второй объект, затем второй процесс — но только после того, как первый показал изменённую цифру.

Что в итоге

Внедрение ИИ в строительстве начинается не с выбора платформы, а с порядка в данных одного процесса. Сначала выбирается участок с ручной сверкой, по нему наводится порядок в данных, затем поверх существующих систем ставится тонкий слой ИИ-агента: он читает данные и документы, сверяет факт с планом, находит расхождение и готовит разбор, а решение и подпись остаются за человеком. Сначала риски — предписание и остановка работ, штраф по статье 9.4 КоАП, переделки стоимостью 5–10% проекта, сдвиг закрытия объёмов, спор без доказательной базы; деньги и часы — следом, и они измеримы уже на пилоте. Первый шаг — бесплатный разбор стратегии внедрения ИИ в компанию на ваших данных.

Источники

• Оценка цифровизации строительства в России: переход к качеству данных, ТИМ у 49% застройщиков во II квартале 2026 года против 44% в IV квартале 2025-го, рост регуляторных индикаторов с 29% в 2026-м до 98% в 2030 году — отчёт Strategy Partners на портале ICT.Moscow.
• Потенциал ИИ в строительстве около 0,9 трлн руб. в год, падение маржинальности девелоперов с 9–11% (2022) до 3–5% (2025), производительность 1,4 млн руб. против 1,8 млн руб., положительный эффект пилотов у 90% компаний при количественном замере лишь у каждой пятой, экономический эффект автоматизации документации и объективного контроля по оценке Минстроя — статья «Искусственный интеллект в строительстве» на TAdviser.
• Потенциальный экономический эффект от ИИ в строительстве до 2035 года — 4 трлн руб., вклад ИИ в ВВП России 11,6 трлн руб. в 2030-м и 46,5 трлн руб. в 2035-м — расчёты ИСИЭЗ НИУ ВШЭ по материалам федерального проекта «Искусственный интеллект», публикация отраслевого журнала «Строительство» на ancb.ru.
• Стоимость переделок в строительстве — 5–10% стоимости проекта, до 20% на плохо контролируемых проектах — сводка данных PlanRadar planradar.com.
• Статья 9.4 КоАП РФ: размеры штрафов для юридических лиц за нарушение требований проектной документации — текст кодекса на consultant.ru.