Что именно меняется к 2030 году
В июне 2026 года в отраслевой повестке публично прозвучали цели цифровизации строительного комплекса: рост рынка цифровизации, автоматизация экспертизы проектной документации с применением искусственного интеллекта, переход части проектных организаций на ИИ-проверку документации и расширение цифрового мониторинга строящихся объектов. Эти заявления важны как ориентир, но сами по себе не являются новой обязанностью для каждой проектной организации с конкретной датой запуска.
Нормативная основа проектирования остается прежней по логике: проектная документация готовится в соответствии с Градостроительным кодексом РФ, состав разделов для многих объектов раскрывается через постановление Правительства РФ № 87, а прохождение экспертизы зависит от типа объекта, стадии, источника финансирования и других условий. Меняется не назначение проектировщика, а способ проверки и ожидание к качеству исходных данных.
| Что не изменится | Что будет усиливаться | Что делать уже сейчас |
|---|---|---|
| Ответственность проектной организации и специалистов за результат | Автоматическая проверка комплектности, ссылок, коллизий и противоречий | Ввести внутренние контрольные точки перед выдачей комплекта |
| Необходимость проектных решений, расчетов и обоснований | Требование к машиночитаемым данным и связи между разделами | Связать WBS, разделы, ведомости, замечания и версии документов |
| Роль ГИПа, ГАПа, главных специалистов и нормоконтроля | Прозрачность маршрута согласования и истории исправлений | Фиксировать, кто проверил раздел, по каким замечаниям и какой версии |
Почему все начинается с данных
Автоматизированная проверка плохо работает с неуправляемым набором файлов: один раздел называется по шифру, второй по фамилии исполнителя, третья версия лежит в архиве, четвертая отправлена письмом, а замечания закрываются в разрозненных письмах. С точки зрения человека это неудобно. С точки зрения цифровой проверки это почти непригодный материал.
Файлы
Единые имена, шифры, версии, даты, статусы выпуска и понятная связь PDF, исходников, расчетов и приложений.
Требования
Ссылки на нормы, ТЗ, техусловия, СТУ, задания смежникам и проектные решения должны быть проверяемыми, а не спрятанными в свободном тексте.
Замечания
Каждое замечание должно иметь автора, раздел, статус, срок, ответственное лицо, решение и ссылку на исправленную версию.
Отдельный слой - ведомости, спецификации и информационная модель. Если объемы работ ведутся в ручных таблицах без связи с моделью, разделами и сметой, цифровая проверка быстро выявит расхождения. Поэтому полезно заранее разобраться, как связать данные по объемам и модель: подробнее об этом есть в материалах про ВОР в XML и про связь ведомости объемов работ с ТИМ.
Какие процессы нужно привести в порядок
Проектной организации не обязательно ждать финальной версии отраслевых регламентов, чтобы подготовиться. Большая часть полезной работы не зависит от конкретной платформы: это дисциплина управления проектом, контроль качества и понятная фиксация решений.
- WBS проекта. Разбейте проект на разделы, пакеты работ, контрольные точки и выдачи. Так проще видеть, что именно готово, что проверено и где зависимость от смежников.
- Матрица ответственности. За каждый раздел, расчет, исходные данные, замечание и выпуск должен быть понятный владелец.
- Единый журнал замечаний. Не храните критические замечания только в письмах и мессенджерах. Нужны статусы, сроки, история решений и связь с версиями.
- Правила версионирования. Версия, дата, стадия, статус и причина изменения должны быть видны без ручного расследования.
- Регламент внутренней проверки. До выдачи в экспертизу комплект проходит не только визуальный просмотр, но и контроль состава, ссылок, расчетов, пересечений и исходных данных.
Практически это близко к нормальному управлению проектированием. Если WBS, задачи и замечания уже ведутся в едином контуре, автоматизированная проверка становится дополнительным уровнем контроля, а не отдельным авральным процессом. Для настройки структуры работ можно использовать подход из статьи про WBS в проектировании.
Что проверять до экспертизы
Хорошая подготовка к ИИ-проверке - это не попытка угадать будущий алгоритм. Это набор внутренних проверок, которые и сейчас снижают риск замечаний экспертизы, конфликтов со смежниками и повторных выдач.
| Зона проверки | Что может выявлять автоматизация | Что должен сделать человек |
|---|---|---|
| Комплектность | Нет раздела, приложения, расчета, подписи, ссылки или обязательного листа | Проверить применимость требования к конкретному объекту и стадии |
| Нормативные ссылки | Устаревший документ, неверная ссылка, противоречие между разделами | Подтвердить актуальность нормы и корректность проектного решения |
| Смежные разделы | Разные параметры в ПЗ, АР, КР, ИОС, ПОС, смете и ведомостях | Согласовать проектное решение и зафиксировать, какой раздел является источником |
| Расчеты | Отсутствие исходных данных, несвязанные результаты, арифметические ошибки | Проверить модель расчета, граничные условия, нагрузки и выводы |
| История изменений | Исправлен один лист, но не обновлены связанные чертежи, ведомости или смета | Провести повторную смежную проверку перед выпуском |
Автоматизированная проверка не отменяет инженерную ответственность. Она помогает быстрее найти несоответствие, но не доказывает, что проектное решение безопасно, экономически оправдано и применимо к конкретному объекту.
Особенно важно не подменять проверку расчетов формальным поиском ошибок. Вопросы ответственности за расчетные ошибки и организацию контроля подробнее разобраны в статье о контроле качества проектной документации.
Безопасность и внешний контур
Подготовка к цифровой проверке не означает, что полный комплект проектной документации можно отправлять в любой внешний сервис. Внутри файлов могут быть персональные данные, коммерческая тайна, сведения по чувствительным объектам, договорные ограничения и материалы, которые заказчик не разрешал передавать третьим лицам.
Минимальная политика безопасности
- разделите открытые, внутренние, конфиденциальные и запрещенные к внешней передаче материалы;
- укажите, какие задачи можно решать на обезличенных фрагментах, а какие только во внутреннем контуре;
- запретите загрузку титулов, подписей, персональных данных, ценовых приложений и чувствительных схем без проверки;
- фиксируйте, кто, когда и какие файлы передавал во внешний инструмент;
- проверяйте условия сервиса: хранение, удаление, доступ сотрудников провайдера и использование данных для обучения.
Подробный разбор рисков есть в статье можно ли загружать проектную документацию в AI-сервисы. Для подготовки к 2030 году это один из ключевых документов: без политики безопасности компания рискует решить техническую задачу и одновременно создать юридическую проблему.
Дорожная карта на 6-12 месяцев
Реалистичный план не начинается с закупки сложной платформы. Сначала нужно убрать управленческие провалы, которые мешают любой проверке - ручной, экспертной или автоматизированной.
| Период | Действие | Результат |
|---|---|---|
| 1-2 месяц | Провести аудит текущих файлов, версий, замечаний, шаблонов и маршрутов согласования | Понятно, где теряются данные и какие ошибки повторяются чаще всего |
| 2-4 месяц | Ввести единые правила именования, статусов, выдач и журнала замечаний | Проект можно проверить по истории, а не по памяти ГИПа и исполнителей |
| 4-6 месяц | Настроить WBS, матрицу ответственности и контрольные точки качества | Каждый раздел имеет владельца, срок, критерии готовности и проверку перед выпуском |
| 6-9 месяц | Запустить пилот автоматизированной проверки на 1-2 типовых проектах | Появляется перечень проверок, которые реально сокращают замечания и переделки |
| 9-12 месяц | Закрепить регламент: что проверяется автоматически, что вручную, кто принимает результат | Автоматизированная проверка становится частью системы качества, а не экспериментом энтузиастов |
Типичные ошибки подготовки
Ждать обязательного требования
Если стартовать только после формального запуска, придется одновременно менять процессы, готовить сотрудников и исправлять текущие проекты.
Считать проверку заменой нормоконтроля
Алгоритм может подсветить несоответствие, но инженерное решение, применимость нормы и ответственность остаются за специалистами.
Проверять только финальный PDF
Финальный комплект часто скрывает проблему в исходниках, ведомостях, расчетных файлах и несогласованных изменениях смежников.
Не учитывать УКЭП и маршруты выдачи
Электронная подпись, версии и статус выдачи должны быть связаны. По теме подписи и экспертизы полезен чек-лист перехода на УКЭП.
Выводы
- ИИ-проверка проектной документации к 2030 году - это не отдельная кнопка, а часть цифрового контура экспертизы, качества и управления проектированием.
- Готовиться нужно с данных: структура файлов, версии, связи между разделами, расчетами, ведомостями, замечаниями и ответственными лицами.
- Автоматизация не отменяет роль ГИПа, главных специалистов, нормоконтроля и экспертной оценки применимости норм.
- Внешние сервисы требуют политики безопасности: нельзя бездумно загружать полный комплект с персональными данными, коммерческой тайной и ограничениями заказчика.
- Самый практичный шаг на ближайшие месяцы - провести аудит текущего процесса и запустить внутренний регламент проверки до выдачи в экспертизу.
Инструменты GostCheck
- AI-подсказки по строительным нормам - быстрый ориентир по применимым СП, ГОСТ и требованиям, который нужно сверять с первоисточником и проектным контекстом.
- Swarm - WBS, задачи, замечания, версии и управленческий контур для проектной команды.
Нормативные источники и материалы
- Сообщение о круглом столе по цифровизации строительного комплекса - источник отраслевых целей по автоматизации экспертизы и ИИ-проверке документации.
- Градостроительный кодекс РФ - базовые положения об архитектурно-строительном проектировании и экспертизе.
- Постановление Правительства РФ № 87 - состав разделов проектной документации и требования к их содержанию.