Пост**Дневник Инженерного ИИ — Недели 15–16: нормативные требования как исполняемый код**

**Дневник Инженерного ИИ — Недели 15–16: нормативные требования как исполняемый код** На прошлой неделе не было дневника. Мы строили организацию управления риском и не успели написать о том, что строим. Начали как обычно. Есть HAZID — метод выявления опасностей на ранней стадии проекта. Есть онтология, процессы, навыки. Казалось, нужно сделать то же, что для маркетинга или продаж: разложить методику на шаги, привязать навыки — и готово. Не получилось. 🔧 Риск не встраивается как шаг в процессе. Проверка фактов — шаг: собрал, проверил, пошёл дальше. Риск так не работает. Опасность, выявленная на стадии концепта, всплывёт через два года на эксплуатации. И через пять — при модификации. Он живёт вдоль всего жизненного цикла объекта, а не в одной точке. Но когда стали разбираться глубже, обнаружили другое. Проблема оказалась не в том, как проводить HAZID. Проблема — в том, что ему подаётся на вход. Сегодня нормативные требования — промышленная безопасность, охрана труда, экология — живут в PDF, методичках, реестрах. Эксперт читает их перед сессией, интерпретирует, держит в голове. Что-то помнит, что-то забывает, что-то трактует по-своему. HAZID начинается с эксперта и его памяти. А должен — с нормативной базы. 📊 Оказалось, что мир уже несколько лет движется в эту сторону. SMART-стандарты — умные стандарты, которые машина может не только прочитать, но и понять. ISO, европейские организации стандартизации, в России ПНСТ 864 и ПНСТ 1016. Суть перехода простая. Бумага — машина ничего не видит. Цифровой документ — видит заголовки и пункты. Но дальше — уровень, на котором машина понимает смысл нормы: кто обязан, что должен сделать, к какому объекту, в каких условиях, с какими параметрами. И следующий — где правила уже работают в системах. Мы стали разбирать нормативные документы на составляющие. Документ — на положения. Положения — на отдельные требования. Каждое требование получает структуру: кто обязан действовать, что именно сделать, к какому объекту применимо, какие условия и исключения меняют применимость, какой риск с ним связан, какое подтверждение закрывает выполнение. Не описание текстом, а формальный контракт, который можно проверить. Из применимого набора требований строится контур риска — каркас состояния риска конкретного объекта. И вот что это меняет. HAZID больше не начинается с пустой таблицы. Он начинается с этого каркаса. Опасности выявляются не по памяти, а по структурированным вопросам, которые порождает нормативная база. Каждая опасность, каждый сценарий, каждое действие трассируется обратно — к конкретному пункту конкретного документа. 💡 Это и есть главное. Нормативное требование перестаёт быть документом, который читают. Оно становится кодом, который исполняется. Восемь точек контроля — от проверки контекста объекта до независимой ревизии. И граница, которую важно держать: машина извлекла смысл нормы, но это не значит, что организация его утвердила. Разрешение на применение — управленческое решение, не свойство данных. Назвали организацию RiCE — РискИнжиниринг. Но архитектура, которая получилась, оказалась шире риск-домена. Контракты процессов, точки контроля, верификаторы — паттерны, которые работают везде, где нормативные требования встречаются с реальной работой. На следующей неделе — пилот. Разворачиваем минимальный контур на одном объекте и проверяем, что состояние риска объекта реально обновляется. 👇 Нормативные требования у вас — PDF, который читают, или код, который исполняется? #DiCE #ОрганизацияКакКод #HAZID #RiCE #SMARTстандарты — Mithril