Недостаточные исходные данные и замечания экспертизы: как разграничить ответственность за доработку проекта

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

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

Как была организована проектная цепочка

Конечный заказчик заключил договор на разработку проектно-сметной документации для сохранения объекта культурного наследия с приспособлением здания для современного использования. Основной исполнитель, в свою очередь, привлёк субподрядчика для разработки проектной и рабочей документации по этому же объекту.

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

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

Почему перечень замечаний ещё не определяет виновного исполнителя

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

Поэтому профессиональная проверка должна разделить как минимум три вопроса:

• в каком разделе документации обнаружено замечание;
• какая непосредственная техническая причина привела к замечанию;
• находилась ли эта причина в зоне ответственности разработчика раздела либо была обусловлена отсутствующими, поздно переданными или изменёнными исходными данными.

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

Как исходные данные повлияли на оценку спора

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

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

При этом доказательств того, что перед передачей субподрядчику комплект был проверен генеральным проектировщиком на достаточность, полноту и корректность, представлено не было.

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

Что означает проверка достаточности исходных данных

Проверять исходные данные полезно не по формальному перечню «получено / не получено», а через проектные решения, которые на них должны опираться.

Для каждого существенного исходного документа необходимо определить:

• какой раздел проекта использует эти сведения;
• какие параметры или ограничения из документа должны перейти в проектное решение;
• когда документ был получен относительно графика проектирования;
• являлась ли полученная редакция актуальной;
• не противоречила ли она другим исходным материалам;
• можно ли было разработать проверяемый раздел до получения этих сведений.

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

Почему генеральному проектировщику важно проверять данные до передачи субподрядчику

При многоуровневой договорной модели исходные данные часто проходят цепочку «конечный заказчик → генеральный проектировщик → субподрядчик». На каждом следующем уровне легко предположить, что предыдущий участник уже проверил комплект. Рассматриваемая ситуация показывает риск такого подхода.

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

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

Почему положительное заключение нельзя анализировать только по конечному результату

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

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

Проверка должна показывать:

• какое замечание было выдано;
• к какой редакции документации оно относилось;
• какой исходный документ действовал на тот момент;
• кто разработал соответствующее решение;
• какое изменение фактически устранило замечание;
• изменилось ли при этом только решение проектировщика или одновременно была дополнена исходная база.

Без такой истории корректировок трудно обоснованно связать расходы на повторную экспертизу с действиями одного конкретного участника.

Почему количество корректировок не равно количеству ошибок проектировщика

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

Одна корректировка может устранять собственную ошибку разработчика. Другая появляется после уточнения исходных данных. Третья устраняет несогласованность смежных разделов. Четвёртая отражает изменение решения заказчика. Сметная или проектная проверка должна различать эти причины.

Поэтому показатель «количество замечаний» практически не имеет самостоятельной доказательственной ценности без классификации их происхождения и влияния на результат.

Как разграничивать замечания между смежными разделами

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

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

Для этого полезен реестр межраздельных зависимостей: исходный параметр → раздел-источник → раздел-получатель → редакция → дата передачи → результат согласования.

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

Почему расходы на исправление требуют собственной доказательственной цепочки

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

Необходимо установить причинную цепочку:

конкретный недостаток → зона ответственности конкретного исполнителя → необходимость корректировки → фактически выполненное исправление → стоимость исправления → отсутствие другой причины возникновения тех же расходов.

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

Почему важно фиксировать, кто именно изменял проект после передачи

Суд обратил внимание и на другой доказательственный разрыв: основной исполнитель не показал, в каком состоянии результат субподрядчика был передан дальше и какие изменения он сам внёс до передачи конечному заказчику.

Это имеет непосредственное профессиональное значение. Если после получения документации генеральный проектировщик объединяет разделы, редактирует их, устраняет коллизии или заменяет отдельные решения, исходная и переданная на экспертизу версии уже могут не совпадать.

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

Как должен выглядеть аудит причин отрицательного заключения

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

Для каждого замечания в ней фиксируются:

• текст и идентификатор замечания;
• раздел и конкретное проектное решение;
• исполнитель раздела;
• использованные исходные данные;
• состояние исходных данных на дату разработки;
• наличие зависимости от другого раздела;
• причина корректировки;
• документ или новая информация, после которых замечание было устранено;
• ответственный за соответствующее изменение;
• влияние замечания на повторную экспертизу и дополнительные расходы.

Такая матрица позволяет отделить технический факт наличия замечания от профессионального вывода о причине его возникновения.

Почему судебная экспертиза могла иметь решающее значение

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

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

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

Что установил апелляционный суд

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

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

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

Что проверять заказчику и генеральному проектировщику

До начала разработки проектной документации полезно создавать контроль исходных данных как самостоятельный этап, а не рассматривать их передачу как техническую пересылку файлов.

Минимальная проверочная цепочка выглядит так:

1. сформировать перечень обязательных исходных данных по каждому разделу;
2. зафиксировать дату получения и редакцию каждого документа;
3. проверить комплект на полноту и взаимные противоречия;
4. определить, какие решения невозможно разрабатывать до получения недостающих сведений;
5. официально запросить отсутствующие данные;
6. при передаче субподрядчику сформировать собственный реестр переданного комплекта;
7. вести историю последующих изменений исходных данных;
8. связывать каждое замечание экспертизы с редакцией проекта и состоянием исходной базы на эту дату.

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

Практический вывод

Замечание государственной экспертизы показывает, что конкретное решение или комплект документации требует корректировки, но само по себе не отвечает на вопрос, кто создал первопричину этого недостатка.

Для профессионального вывода необходимо восстановить всю причинную цепочку: задание → исходные данные → дата их передачи → разработчик раздела → смежные решения → редакция проекта → замечание экспертизы → способ устранения.

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

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

Источник практики

Арбитражный суд Брянской области, решение от 30 июня 2025 года по делу № А09-7343/2023; Двадцатый арбитражный апелляционный суд, постановление от 22 сентября 2025 года № 20АП-3815/2025 по делу № А09-7343/2023. Апелляционная инстанция оставила решение об отказе в удовлетворении требований без изменения. Суд исследовал связь качества проектной документации с переданными исходными данными, историю передачи результата и доказанность причин возникновения дополнительных расходов.

Материал подготовлен на основе открытых источников и не является описанием проекта нашей компании.