Готова ли ваша организация к применению ИИ?

Чек-лист для проектных, BIM- и обследовательских компаний

Разработано ROSECO (РУСЭКО-СТРОЙПРОЕКТ) при участии отраслевых экспертов · версия 3.5 · июль 2026

Чек-лист готовности организации к применению ИИ — ROSECO (РУСЭКО-СТРОЙПРОЕКТ)

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

Мы в ROSECO (РУСЭКО-СТРОЙПРОЕКТ) собрали и опубликовали чек-лист из 92 критериев, который помогает провести первичную диагностику организации перед выбором ИИ-сценариев и проверкой гипотез — какие из них дадут наибольший эффект, а какие разрывы в организации, данных или инфраструктуре нужно закрыть до запуска пилота.

Какие ответы вы получите после заполнения

Кому будет полезен чек-лист

Руководителям проектных, BIM- и обследовательских организаций, техническим директорам, ГИПам, ГАПам, BIM-менеджерам, руководителям ИТ, информационной безопасности и организационного развития.

Категории 1–7 применимы к большинству организаций даже без привязки к отрасли строительного проектирования. Категории 8–10 рассчитаны на более узкую специфику: проектную деятельность, BIM-моделирование, технические обследования и изыскания.

Что оценивает чек-лист, а что — нет

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

Перед началом: найдите зоны наибольшего эффекта от ИИ

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

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

Как использовать чек-лист: два варианта

Вариант 1 — от общей оценки к сценарию
  1. Заполните чек-лист исходя из текущего состояния компании.
  2. Определите на его основе, какие ИИ-сценарии можно начать применять без дополнительной подготовки или с минимальными трудозатратами.
  3. Определите последовательность тестирования выбранных сценариев.
  4. Приступайте к тестированию.
Вариант 2 — от сценария к точечной подготовке
  1. Определите один конкретный сценарий применения ИИ, например по самому загруженному подразделению (теория ограничений) или самому длительному этапу работ.
  2. Пройдите применимые к нему категории и подтвердите ответы документами, записями или фактической практикой.
  3. Для каждого ответа «Нет» зафиксируйте, мешает ли выявленный разрыв выбранному сценарию.
  4. Выберите наиболее критичные разрывы и сформируйте действия по их устранению.
  5. Повторите оценку для других сценариев, если требования к ним существенно отличаются.

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

Правила оценки

Краткий глоссарий

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

Структура чек-листа: 10 категорий, 92 критерия

Категории 1–7 универсальны и применимы к любой организации. Категории 8–10 — отраслевые: BIM-моделирование актуально для организаций, применяющих эту технологию, проектные роли и передачи — для организаций, ведущих проектную деятельность, а проверяемость методик обследования — для тех, кто выполняет технические обследования и изыскания. Если вид деятельности организации не подходит под категорию — её можно пропустить.

Пункт 38 и пункты раздела «Знания и обучение» (54–63) оцениваются по шкале зрелости 0–5, где 0 — практика отсутствует, а 5 — применяется системно, контролируется и улучшается. Остальные критерии отмечаются в формате «Да / Нет».

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

Измеряет: Степень эксплицитности описания организации как системы

Критерий Связь с ИИ-готовностью
1 Существует актуальная организационная схема, показывающая все подразделения и связи между ними ИИ работает с описаниями структуры. Без явной оргсхемы ИИ не может понять, кто с кем взаимодействует
2 Существует функциональная схема организации, показывающая, какие функции выполняет каждое подразделение Чёткое описание функций подразделений позволяет оценить потенциальные сценарии применения ИИ, определить точки поддержки сотрудников и заранее закрепить границы ответственности.
3 Существует каталог услуг (сервисов), предоставляемых клиентам, с описанием каждой услуги ИИ может помогать в продаже/кастомизации услуг, только если услуги описаны структурированно
4 Существует полный список типов результатов работы/артефактов, создаваемых организацией (проектная документация, отчёты, модели и т.п.) ИИ генерирует или проверяет результаты работы. Нужен каталог того, что вообще создаётся
5 Для основных типов результатов работы/артефактов определены входы (формат, источник), выходы (формат, структура), требования к качеству, ответственный за создание и критерии приёмки результата (например: для проектной документации — входной формат задания на проектирование, выходной формат — комплект ПД, критерий приёмки — прохождение нормоконтроля и проверки главным специалистом) ИИ требует полной спецификации результатов работы для корректной генерации и проверки. Что на входе, то и на выходе
6 Описаны границы организации: что организация делает сама, что отдаёт подрядчикам, что получает от клиента ИИ должен понимать границы работы — что можно автоматизировать внутри, что остаётся у человека/партнёра
7 Существует актуальный список программного обеспечения (инструментов), используемого организацией, с указанием назначения каждого Список ПО позволяет оценить интеграционную готовность каждого инструмента: наличие API, машиночитаемого экспорта/импорта, готовых коннекторов, необходимость кастомной разработки либо отсутствие практически реализуемого способа интеграции. Это основа для выбора и планирования ИИ-сценариев.
8 Описаны основные потоки работы между подразделениями (кто кому что передаёт) ИИ может оптимизировать или автоматизировать работы, только если они явно описаны
9 Совокупность документов, описывающих организацию (оргсхема, функциональная схема, описания процессов, каталог услуг), доступна сотрудникам и ИИ-инструментам в пределах их ролей и прав доступа ИИ-инструменты могут использовать описания организации как контекст. Разграничение доступа снижает риск неправомерного доступа, если права технически применяются, проверяются и своевременно актуализируются
10 Описания организации (оргсхема, функциональная схема, регламенты процессов и иные документы, описывающие структуру и работу) актуализируются при каждом значимом изменении структуры или процессов; периодичность плановой проверки актуальности определяется частотой таких изменений (например, не реже раза в год при стабильной структуре, чаще — при активных изменениях) ИИ работает с актуальными описаниями. Устаревшие описания приведут к неверным решениям ИИ

Измеряет: Степень чёткости границ ответственности

Критерий Связь с ИИ-готовностью
11 Для каждого ключевого бизнес-процесса определён владелец; для каждого планируемого ИИ-сценария назначены ответственные за настройку, эксплуатацию и приёмку результатов ИИ-инструменты требуют определения ответственных за их настройку и результаты. Без владельца процесса непонятно, кто отвечает за ИИ в этом процессе
12 Для ключевых бизнес-процессов из утверждённого перечня определены ответственные, согласующие, исполнители и лица, принимающие решение (RACI/DACI) Матрица ответственности фиксирует, кто за что отвечает в процессе. Для ИИ-готовности важно не то, что она показывает, какие роли можно «усилить» ИИ, а то, что чёткое распределение ответственности позволяет понять, в какие участки процесса ИИ можно встраивать безопасно, с понятным контуром ответственности за результат
13 Для каждой роли в организации (включая проектные роли: ГАП, ГИП, BIM-менеджер, главные специалисты) существует письменное описание зоны ответственности, независимое от конкретного исполнителя. При смене исполнителя описание роли сохраняется, а новому исполнителю передаются ответственность, информация и необходимые доступы. Важно: описания должны быть привязаны к ролям, а не к должностям ИИ-инструмент может выполнять отдельные операции, относящиеся к роли, если эти операции и критерии проверки результата явно описаны. Ответственность сохраняется за назначенным исполнителем
14 Описаны точки передачи работы между ролями/подразделениями для ключевых процессов ИИ может автоматизировать передачи — самые частые источники ошибок и задержек
15 Определены критерии готовности работы к передаче между ролями (что должно быть выполнено для передачи дальше) ИИ требует чётких критериев для определения, когда его работа завершена и можно передавать дальше
16 Для ошибок ИИ-инструментов определены категории инцидентов (ошибка результата, утечка данных, некорректное действие агента, использование запрещённых данных, необходимость остановки сценария) и ответственные за их разрешение Когда ИИ выдаёт неожиданный результат или создаёт критичную ситуацию, должно быть ясно, кто принимает решение о дальнейших действиях
17 До запуска соответствующего сценария определено и утверждено, какие решения ИИ может готовить, какие может рекомендовать, а какие запрещено принимать без человека, либо установлен утверждённый порядок определения и согласования этих границ до запуска сценария. ИИ может помогать в принятии решений, но право окончательного принятия критичных решений должно быть явно закреплено за человеком
18 Критичные зависимости от одного сотрудника выявлены, для них назначены меры снижения риска (описание метода, дублёр, база знаний, обучение, передача доступа) ИИ может снизить зависимость от ключевых людей, но только если знания этих людей явно зафиксированы и есть план передачи
19 При найме/перемещении сотрудников используются описания ролей, предусмотрена адаптация по всем инструментам должности/роли, включая ИИ-инструменты, с назначением необходимых доступов. ИИ-инструменты для подбора персонала требуют структурированных описаний ролей; новые сотрудники должны быть обучены работе со всеми инструментами роли, включая применяемые ИИ-инструменты.

Измеряет: Степень структурированности и управляемости данных, информации и знаний

Критерий Связь с ИИ-готовностью
20 Для основных типов данных определены источник, владелец, формат, правила хранения, требования к качеству и допустимое использование. Для данных третьих сторон дополнительно фиксируются источник, подтверждённый уровень качества, доступный организации объём контроля и ограничения допустимого использования. ИИ работает с управляемыми данными. Без явных правил ИИ может использовать данные некорректно или небезопасно
21 Существуют утверждённые справочники и классификаторы (услуг, результатов работы/артефактов, проектов, типов данных; при применимости — элементов моделей и дефектов) с указанием владельца, области применения и порядка внесения изменений. ИИ-сценариям нужна управляемая терминология. В разных системах могут применяться разные классификаторы, если определены их области применения, версии и правила сопоставления. Несогласованные значения повышают риск ошибок
22 Для ключевых результатов работы операционная работа ведётся в редактируемых и/или структурированных форматах, пригодных для автоматической обработки, а вывод — в требуемых финальных форматах (включая PDF). См. также категорию 8 для BIM-данных Для автоматической обработки критично сохранение структуры, связей и атрибутов. Рабочие и финальные форматы выполняют разные функции; оба слоя должны оставаться доступными, а пригодность конкретного формата проверяется для выбранного сценария и инструмента.
23 Определены утверждённые места хранения информации с правами доступа, поиском, структурой и правилами связности данных ИИ требует управляемого доступа к данным. Необязательно одно физическое хранилище, важна управляемость
24 Для каждого типа информации определены права на создание, изменение, удаление, чтение и выгрузку; отдельно — допустимость передачи во внешние ИИ-сервисы, обработки локальными ИИ-решениями, использования для анализа или обучения и публикации результата. ИИ должен соблюдать расширенные права доступа, включая все аспекты обработки данных и их распространения
25 Информация снабжена метаданными: кто создал, когда, версия, для какого проекта/задачи, на основе каких входных данных, источник исходных данных, статус проверки, согласования ИИ использует полные метаданные для контекста, провенанса и оценки качества. Без метаданных ИИ не знает, насколько данным можно доверять
26 Можно восстановить утверждённые версии и критичные рабочие состояния информации за установленный срок хранения (например, с использованием систем контроля версий, таких как Git, или встроенного версионирования CDE) ИИ может ошибиться. Версионирование позволяет откатить изменения, сделанные ИИ, в установленных пределах
27 Историческая информация завершённых проектов доступна для аналитической выгрузки в пределах прав, сроков хранения и правил обезличивания/конфиденциальности Историческая информация используется ИИ преимущественно как источник для поиска с дополнением контекста (RAG), примеров, анализа и корректировки инструкций по итогам разбора проектов. Возможно и дообучение модели, хотя оно является отдельным, более дорогим сценарием.
28 Информация из разных источников связана через единые идентификаторы (например, один проект имеет один код во всех системах) ИИ способен сопоставлять записи при неполном совпадении, но такое сопоставление вероятностно. Единые идентификаторы повышают точность, воспроизводимость и проверяемость связи данных.
29 Для критичных массивов данных определена методика проверки качества (выборка, периодичность, ответственный за устранение дефектов) ИИ усиливает проблемы с качеством данных. Плохие данные → плохие решения ИИ (что на входе, то и на выходе)
30 Существует классификация информации по уровню конфиденциальности (публичная, внутренняя, конфиденциальная, коммерческая тайна) Классификация определяет допустимые способы обработки информации: локальный анализ и индексирование, передачу во внешние ИИ-сервисы, использование в базах знаний и публикацию результатов. Она необходима и при полностью локальном контуре как основа управления доступом.
31 Для каждого класса конфиденциальности определены правила обработки информации, а для планируемых к применению ИИ-сценариев — способы их технического и организационного соблюдения ИИ должен соблюдать правила конфиденциальности автоматически. Ограничения должны быть реализованы в правах доступа, настройках и процедурах и периодически проверяться
32 Информация доступна через управляемый поиск по утверждённым источникам с правами доступа и индексированием (например, полнотекстовый поиск с учётом контекста, а не только по заголовкам файлов, как в базовом поиске популярных чат-ботов) ИИ-ассистенты ищут информацию для пользователей с соблюдением прав доступа
33 Структура хранения информации документирована (есть схема: какие типы информации где хранятся) ИИ требует понимания структуры данных для корректного поиска и обработки
34 Существуют стандарты именования файлов и папок, соблюдение проверяется выборочным аудитом или через долю соответствующих файлов. См. также категорию 8 для BIM ИИ использует имена файлов для понимания содержимого. Проверка позволяет оценить фактическую степень соблюдения стандартов

Измеряет: Степень осознанности применения методов работы (эксплицитность)

Критерий Связь с ИИ-готовностью
35 Ключевые бизнес-процессы из утверждённого перечня описаны с указанием входов, выходов, критериев результата (измеримых или проверяемых по факту) и владельца. Для каждого есть регламент или инструкция. Для процессов, в которых планируется применение ИИ, определены границы его применения ИИ может помогать в плохо формализованных задачах, но безопасное внедрение требует описанных границ, входов, выходов и измеримых критериев проверки
36 Существуют шаблоны для типовых результатов работы/артефактов (отчётов, договоров, спецификаций и т.п.) Без шаблонов структура результата будет носить случайный характер, и ИИ не сможет надёжно предсказать, какую форму использовать
37 Существуют чек-листы для критичных операций (выпуск документации, приёмка работ, проверка моделей), покрывающие конкретные производственные сценарии: выпуск, проверку, согласование, контроль версий, учёт замечаний Автоматизация проверки по чек-листам с помощью ИИ зависит от конкретного производственного сценария, уровня API/интеграций у используемого ПО и трассируемости данных. Сегодня для многих сценариев проверка человеком дешевле, но чек-листы остаются основой, на которую можно опереться по мере роста возможностей интеграций
38 Для утверждённого перечня ключевых процессов методы документированы так, что сотрудник требуемой квалификации может воспроизвести процесс по инструкции с использованием указанных входных данных, шаблонов и контрольных точек. Если инструкция понятна квалифицированному человеку, её можно «объяснить» ИИ. Неявные знания ИИ недоступны. Воспроизводимое описание метода создаёт основу для постановки задачи ИИ и проверки его результата
39 Для каждого метода указано, когда он применим, а когда — нет (условия применимости) ИИ должен знать контекст применения метода, чтобы не использовать его неуместно
40 Определён порядок актуализации методов: кто отслеживает изменения законодательства/стандартов/технологий, как фиксируется необходимость пересмотра, кто утверждает новую версию, как сотрудники уведомляются об изменениях ИИ работает по актуальным методам. Порядок актуализации снижает риск использования устаревших методов.
41 Существует процесс предложения улучшений методов с этапами рассмотрения, принятия/отклонения, внедрения и фиксации решения ИИ может предлагать улучшения методов на основе анализа данных. Управляемый процесс обеспечивает контроль качества изменений
42 Отклонения от стандартных методов фиксируются и анализируются (почему пришлось отклониться) Зафиксированные отклонения могут использоваться для анализа граничных случаев, обновления инструкций и контекста ИИ. Если отклонения не фиксируются, ИИ не узнает о граничных случаях
43 Для сложных методов существуют примеры их применения (кейсы из прошлых проектов) ИИ использует примеры применения методов как материал для поиска с дополнением контекста (RAG) и как ориентир при генерации, а не обязательно как данные для дообучения модели
44 Описания методов работы доступны непосредственно в момент выполнения работы: например, актуальный чек-лист или инструкция открыты в рабочей системе (CDE, корпоративном портале), а не хранятся отдельно в архиве, откуда их нужно искать вручную Доступность актуального метода в рабочем контуре позволяет сотруднику или ИИ-ассистенту использовать его непосредственно при выполнении задачи, без ручного поиска в архиве и риска обращения к устаревшей версии.

Измеряет: Степень фиксации свидетельств работы

Критерий Связь с ИИ-готовностью
45 Значимые результаты работы/артефакты (включая промежуточные версии) сохраняются как свидетельство выполненной работы и доступны для проверки в пределах прав, сроков хранения и правил конфиденциальности ИИ использует сохранённые артефакты как контекст, источник анализа и базу примеров — не обязательно для дообучения модели
46 Для ключевых процессов определены метрики качества, сроков, трудозатрат и ошибок, пригодные для оценки эффективности ИИ-инструментов ИИ требует метрик для оценки своей эффективности и улучшения работы
47 Метрики измеряются с установленной периодичностью (например, еженедельно для оперативных, ежемесячно для стратегических) Регулярные измерения позволяют отслеживать динамику, оценивать эффективность ИИ-инструментов и своевременно корректировать сценарий их применения.
48 Результаты измерений доступны тем, кто принимает решения по улучшению процессов ИИ может предлагать улучшения процессов на основе метрик, но решение принимает человек
49 Существуют целевые и пороговые значения метрик, при достижении или превышении которых требуются конкретные действия ИИ использует пороги для автоматических уведомлений и рекомендаций
50 История измерений сохраняется: можно посмотреть динамику метрик за прошлые периоды ИИ анализирует тренды для прогнозирования и раннего обнаружения проблем
51 При отклонении метрик от целевых значений инициируется анализ причин ИИ может автоматически выявлять отклонения, но анализ причин требует участия человека
52 В решениях об изменении процессов фиксируются использованные данные, метрики, причина изменения и ожидаемый эффект ИИ усиливает принятие решений на основе данных, предоставляя аналитику. Фиксация делает процесс проверяемым
53 Определено, какие промежуточные артефакты работы (черновики, расчёты, согласования) сохраняются, на какой срок и с какими правами доступа Сохранённые промежуточные артефакты могут использоваться ИИ для анализа процесса, выявления причин отклонений и подготовки рекомендаций. Избирательное сохранение позволяет получить эту пользу без избыточного накопления данных и связанных рисков.

Измеряет: Готовность организации делать неявное явным

Критерий Связь с ИИ-готовностью
54 Для проектов выше установленного порога сложности/стоимости или при наличии существенных отклонений проводится разбор уроков ИИ использует зафиксированные уроки как материал для поиска с дополнением контекста и корректировки рекомендаций, а не обязательно как данные для дообучения
55 Уроки, извлечённые из проектов, документируются и доступны другим командам ИИ использует накопленные уроки как базу знаний для рекомендаций
56 Для значимых проектных, технических и управленческих решений фиксируются причина, рассмотренные варианты, выбранное решение и последствия ИИ требует понимания контекста решений. Без обоснований ИИ не знает, почему было принято то или иное решение
57 После инцидентов/ошибок проводится анализ первопричин, а не только поиск виноватых ИИ может помогать в анализе первопричин, анализируя паттерны инцидентов
58 Результаты анализа инцидентов приводят к обновлению процедур/чек-листов (замыкается цикл обучения) ИИ требует актуальных процедур. Цикл обучения повышает вероятность, что ИИ работает по обновлённым правилам
59 Существует внутренняя база знаний с примерами решения типовых и нетиповых задач ИИ использует базу знаний как контекст для генерации ответов (поиск с дополнением контекста)
60 База знаний активно используется: есть измеримые признаки (обращения, просмотры, ссылки в задачах, использование при адаптации сотрудников) Измеримое использование людьми подтверждает практическую ценность и актуальность базы знаний. Для применения ИИ дополнительно необходима её техническая доступность
61 Существует процесс актуализации базы знаний: устаревшие записи помечаются или обновляются ИИ требует актуальных знаний. Устаревшая база знаний приведёт к неверным рекомендациям ИИ
62 Есть установленный способ фиксации экспертных знаний, назначены ответственные за темы, есть примеры записей и порядок их актуализации ИИ может усилить экспертов, только если их знания явно зафиксированы и управляются
63 Значимые решения, договорённости и изменения фиксируются в утверждённых системах или документах ИИ работает только с записанными знаниями. Фиксация важных решений делает их доступными для ИИ

Измеряет: Готовность организации безопасно и предсказуемо по затратам работать с ИИ-инструментами и сервисами

Критерий Связь с ИИ-готовностью
64 Определены правила доступа к ИИ-инструментам и ИИ-сервисам: кто может их использовать, с какими данными и в каком контуре (локальном или облачном) ИИ требует чётких правил информационной безопасности, иначе повышается риск утечки данных при использовании внешних сервисов
65 Для критичных данных определено, допустима ли их передача во внешние ИИ-сервисы, и если нет — обеспечена возможность работы с локальными/изолированными решениями Без этого организация не может безопасно выбирать между облачными и локальными сценариями внедрения ИИ
66 Определены минимальные требования к вычислительной инфраструктуре (или бюджету на облачные мощности) для планируемых сценариев применения ИИ Без оценки инфраструктурных затрат выбранный сценарий внедрения ИИ не может быть реализован
67 Определён процесс реагирования на инциденты информационной безопасности, связанные с использованием ИИ-инструментов (утечка данных, компрометация доступа) ИИ увеличивает поверхность атаки за счёт новых точек интеграции и внешних сервисов
68 Сотрудники, использующие ИИ-инструменты, ознакомлены с утверждёнными правилами допустимого использования: какие данные и в какие сервисы можно передавать, какие действия требуют согласования и как сообщать об инциденте; факт ознакомления зафиксирован. Формализованное ознакомление снижает риск случайной передачи конфиденциальных данных и иных нарушений правил использования ИИ.

Измеряет: BIM-специфическая структурированность

Критерий Связь с ИИ-готовностью
69 Модели доступны для автоматической обработки через открытые форматы (IFC с проверкой сохранения семантики, а также JSON/XML-экспорты, где это уместно) и/или документированные интерфейсы (API) ИИ-инструменты могут работать с открытыми форматами и через API. Важна доступность для обработки, а не конкретный формат
70 Определён утверждённый корпоративный/проектный классификатор элементов моделей и правила его применения ИИ требует взаимно согласованной классификации элементов. Утверждённый классификатор и правила его применения снижают риск разночтений. При использовании нескольких классификаторов должны быть определены соответствия между ними, а соблюдение правил необходимо проверять
71 Атрибуты элементов модели структурированы: есть стандарт заполнения атрибутов для каждого типа элемента ИИ анализирует атрибуты элементов, но также может помогать заполнять пропущенные данные или классифицировать элементы по косвенным признакам при отсутствии полного стандарта. Тем не менее стандарт заполнения повышает точность и снижает потребность в такой компенсирующей работе
72 Для каждого типа BIM-объектов определён обязательный набор атрибутов по назначению объекта и стадии проекта ИИ может использовать библиотеку объектов для генеративного проектирования. Набор атрибутов зависит от типа объекта
73 Для каждого проекта и стадии определён требуемый уровень информации (LOIN) под конкретный сценарий использования модели, включая требования к геометрии, атрибутам и сопроводительной документации. Явные требования к уровню информации позволяют проверять полноту модели и формировать отчёты о готовности с учётом конкретного сценария использования.
74 Геометрия в моделях связана с данными: можно автоматически выгрузить спецификации, объёмы, площади Связь геометрии с атрибутами позволяет автоматически извлекать и сверять спецификации, объёмы и площади, контролировать полноту данных и передавать структурированные сведения в последующие расчётные и аналитические процессы.
75 Замечания экспертизы/заказчика фиксируются структурированно (в BCF или аналогичном формате) с привязкой к элементам модели Возможность автоматического анализа замечаний зависит от того, поддерживает ли используемое ПО экспорт в BCF или доступ через API/MCP. При наличии такой возможности ИИ может анализировать типовые замечания и проверять модели на частые ошибки

Измеряет: Проектно-специфическая чёткость ролей и передач

Критерий Связь с ИИ-готовностью
76 Для каждого конкретного проекта назначены исполнители на роли участников (ГАП, ГИП, главные специалисты по разделам, BIM-менеджер) — в отличие от п.13, где описывается зона ответственности роли в целом, здесь фиксируется, кто именно выполняет эту роль в данном проекте ИИ-инструменты могут выполнять отдельные операции или поддерживать исполнителей ролей. Явные назначения показывают, кто разрешает применение ИИ, проверяет его результат и принимает итоговое решение
77 Разработан и применяется проектный регламент (План выполнения проекта в BIM — BEP, или аналогичный документ для организаций без BIM), определяющий правила работы команды Проектный регламент задаёт контекст для ИИ-инструментов в проекте: требования к моделям/документации, форматы обмена, зоны ответственности
78 Существует протокол координации моделей между дисциплинами (как и когда происходит обмен моделями) При наличии технической интеграции ИИ-инструменты могут анализировать соблюдение протокола, классифицировать выявленные коллизии и готовить адресные уведомления. Передача файлов, уведомление о новой версии и запуск проверки могут выполняться обычной автоматизацией; конкретный состав функций зависит от возможностей используемого ПО.
79 Определены критерии готовности модели к передаче между дисциплинами (например, чек-лист проверок перед передачей) При наличии машиночитаемых правил, поддерживаемого формата и технического доступа к модели через API или иной интерфейс чек-лист может использоваться для автоматизированной предварительной проверки и формирования отчёта. Объём автоматизации выбирается с учётом стоимости проверки; итоговую готовность подтверждает ответственный специалист.
80 Существует процесс разрешения коллизий: определено, кто ответственен за принятие решений по каждому типу коллизий ИИ выявляет коллизии, но решение принимает человек. Должно быть ясно, кто ответственен за какие типы коллизий
81 Для каждой стадии проектирования (предпроект, проектная документация, рабочая документация, обследование, исполнительная документация — в зависимости от типа работ организации) определены результаты и критерии их приёмки При наличии формализованных критериев, машиночитаемых данных, технического доступа и проверенного инструмента ИИ может выполнять предварительную проверку комплектности и отдельных критериев
82 Передача работы между стадиями формализована: есть чек-лист того, что должно быть готово ИИ-инструмент может подготовить проект чек-листа по установленным требованиям, контролировать его заполнение, находить отсутствующие артефакты и формировать напоминания. Итоговое решение о готовности стадии к передаче принимает ответственный сотрудник.

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

Критерий Связь с ИИ-готовностью
83 Существуют стандартные методики для каждого типа обследования (дефектоскопия, обмеры, испытания и т.п.) ИИ может помогать в обследовании (например, распознавание дефектов на фото), только если методика явно описана
84 В методиках указаны параметры измерительного оборудования и условия проведения измерений ИИ требует метаданных об условиях измерений для корректной интерпретации данных
85 Облака точек лазерного сканирования и сохраняются в исходном формате сканирования с метаданными (дата, время, оборудование, оператор, условия) Исходные (необработанные) облака точек могут пригодиться для специализированных ИИ-моделей компьютерного зрения (например, автоматического выявления элементов конструкций или дефектов) — это техническое обучение узкоспециализированных моделей, отличное от дообучения универсальных языковых моделей
86 Фотографии обследований сохраняются в исходном разрешении с привязкой к элементам конструкции/помещениям Качественные изображения с контекстной привязкой пригодны для анализа специализированными моделями компьютерного зрения, включая распознавание и классификацию дефектов.
87 Данные приборов сохраняются в табличных форматах с метаданными (дата, прибор, калибровка, условия) ИИ анализирует данные приборов для выявления трендов и аномалий. Табличный формат обеспечивает машиночитаемость
88 Для каждого типа дефекта существует классификация по степени опасности с явными критериями ИИ может автоматически классифицировать дефекты по степени опасности. Явные критерии позволяют формализовать правила классификации и проверять результат ИИ квалифицированному специалисту
89 Дефектные ведомости заполняются в цифровом виде непосредственно на объекте (не переносятся вручную из блокнотов) Цифровые данные сразу доступны для ИИ-анализа. Бумажные блокноты создают разрыв в цепочке данных
90 Существуют утверждённые шаблоны/структуры результатов обследования по типам объектов с общими обязательными полями ИИ требует структурированных результатов. Шаблоны по типам объектов практичнее единого формата
91 При повторном обследовании объекта данные предыдущих обследований доступны для сравнения ИИ может анализировать динамику развития дефектов, только если исторические данные доступны
92 Оборудование для обследований калибруется регулярно, записи о калибровке хранятся ИИ-анализ требует достоверных исходных измерений. Регулярная калибровка и сохранение записей о ней позволяют оценить качество и применимость данных, используемых для анализа.

Итоги самооценки: что делать после чек-листа

Большое количество ответов «Нет» не означает, что организация не готова применять ИИ. Важно понять, какие разрывы действительно препятствуют выбранному сценарию, какие риски они создают и что необходимо устранить до запуска пилота. По итогам самооценки полезно зафиксировать: рассматриваемый ИИ-сценарий, ожидаемый результат, наиболее подготовленные блоки (2–3 категории, на которые можно опереться), критичные разрывы (до пяти пунктов, мешающих запуску), основные риски запуска сейчас и конкретные действия до начала пилота.

Чем может помочь ROSECO (РУСЭКО-СТРОЙПРОЕКТ)

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

Авторы и рецензенты

Разработали:

  • Александр Лапыгин, генеральный директор ROSECO (РУСЭКО-СТРОЙПРОЕКТ) (aal@roseco.net, t.me/gip2gip),
  • Варвара Квашнина, руководитель направления развития и автоматизации ROSECO (РУСЭКО-СТРОЙПРОЕКТ) (t.me/madmuaszel).

Рецензенты:

  • Александр Высоцкий, генеральный директор Vysotskiy consulting (bim.vc)
  • Алла Землянская, директор по работе с пользователями Tangl, автор канала InfraBIM Expert (t.me/infrabimexpert)
  • Роман Митин, эксперт по цифровизации строительства
  • Александр Панькин, независимый эксперт по операционной эффективности цифровой трансформации
  • Павел Федяев, эксперт по цифровизации строительства
  • Олег Чернетченко, директор по проектированию BCC

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

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

roseco.net · @ROSECO_BIM