Ответственность за рекомендации ИИ в проектировании: разбор

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

Источник: rics.org

Этот вопрос в 2026 году перестал быть теоретическим. Цифровые инструменты на этапе проектирования используются всё шире, а отраслевые площадки — от библиотеки Procore до стандартов buildingSMART — всё активнее обсуждают, как внедрять цифровые инструменты так, чтобы они не ломали процесс, а укрепляли его. Но юридический ответ на вопрос «кто отвечает» остаётся неудобным: отвечает человек и компания, а не модель. Разберём, почему это так, где именно проходит граница ответственности и как владельцу небольшой компании выстроить процесс, в котором ошибка рекомендации не превращается в убыток без виноватого.

Что именно происходит, когда модель «советует»

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

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

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

Почему ответственность не переходит к программе

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

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

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

Что меняется в деньгах, времени и контроле

Практический смысл этой рамки становится виден, когда переводишь её в операционные последствия. Здесь помогает посмотреть, как отрасль уже решает похожую задачу в BIM-координации. buildingSMART International — отраслевая организация, которая развивает открытые стандарты обмена данными в строительстве: формат IFC (стандартизированное цифровое описание зданий, ISO 16739), бесплатную платформу валидации IFC-файлов и протокол BCF — стандартный способ фиксировать и вести замечания и коллизии по BIM-проектам. Смысл этих инструментов ровно тот, который нужен и для работы с рекомендациями модели: любое замечание и любое решение должны быть записаны, адресованы конкретному человеку и отслежены до закрытия.

Что меняется	Почему важно бизнесу	Что проверить
Рекомендация модели становится частью проектного решения	Ошибка всплывёт на стройке, где переделка в разы дороже, чем на проекте	Есть ли обязательный шаг проверки человеком до принятия
Каждое решение должно иметь автора и основание	Без записи «кто и почему принял» спор с заказчиком проигрывается	Фиксируются ли решения в протоколе или системе замечаний
Качество рекомендаций зависит от качества исходных данных	Неполная модель даёт уверенные, но неверные советы	Кто отвечает за полноту и актуальность данных в модели
Договор с вендором не перекладывает ответственность	Претензии к поставщику ПО почти никогда не покрывают убыток	Что написано в лицензионном соглашении об ответственности

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

Где цепочка ломается: честный разбор рисков

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

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

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

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

Что проверить до того, как доверять рекомендации

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

Назначьте зону обязательной проверки. Письменно зафиксируйте: рекомендации по несущим конструкциям, инженерным системам и нормативным требованиям принимаются только после проверки ответственным проектировщиком. Всё остальное — по упрощённой схеме.
Введите след решения. Каждая принятая или отклонённая рекомендация фиксируется: кто, когда, на основании чего. Если работаете в BIM — используйте протокол замечаний (BCF) или хотя бы единый журнал, а не переписку.
Проверьте входные данные. Перед тем как инструмент даёт рекомендации, убедитесь, что модель полная и актуальная. Для IFC-файлов существуют открытые валидаторы — это дешёвый способ отсеять часть проблем на входе.
Прочитайте лицензионное соглашение. Найдите пункт об ответственности и ограничении претензий. Это займёт полчаса и навсегда снимет иллюзию «пусть отвечает программа».
Проведите один разбор. Возьмите последний проект и честно ответьте: если бы рекомендация инструмента оказалась ошибкой, смогли бы вы показать заказчику или экспертизе, что проверка была? Если нет — это и есть первая задача.

Безопасный первый пилот

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

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

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

Кто отвечает за ошибку, если рекомендацию дала модель: понятный разбор для стройки