Что это такое
Свод правил применяется на фазах развёртывания (DEPLOY) и эволюции (EVOLVE) методики Oper8. Триггер запуска: переход AI-процесса с уровня A1 (Оператор) на A2 (Коллаборатор, агент действует сам, человек проверяет каждое решение). Дальше каждый шаг к более высокой автономии — A3, A4 — требует новой версии свода с явными изменениями ограничителей. На A1 в production достаточно базового свода (красные линии плюс минимальные ограничители); полный свод трёх слоёв нужен с A2, когда агент начинает действовать сам.
Главная провокация в том, что рабочий свод не равен папке для аудита. Если правило не проходит тест «как я это проверю прогоном eval», оно остаётся декларацией. Декларации блокируют релизы по жалобам и презентациям; правила блокируют по автоматической проверке. Разница в скорости: проверка в CI узнаёт о провале за 30 секунд после релиза, регулятор узнаёт через 4 месяца через жалобу клиента.
По нашим наблюдениям, первый свод собирается за 2 часа тремя людьми (генеральный, владелец процесса, опытный оператор) на материале последних 10 нестандартных решений или жалоб клиентов. Половина из них становится красными линиями, половина — ограничителями. Это упражнение на конкретном материале, не семинар на доске; через 6 недель свод вырастает в 3–4 раза и стабилизируется в объёме.
Как делать
Красные линии: что нельзя никогда
Абсолютные запреты, нарушение которых блокирует релиз и эскалируется на C-suite или Legal. Примеры: «AI не даёт юридических советов»; «AI не одобряет возврат денег без проверки». Реакция на нарушение: безусловный блок и разбор в течение 24 часов. Ритм изменений редкий: при смене регуляторики, после инцидента, при смене модели. В Mid и Enterprise владеет Compliance совместно с Legal. Машинная проверка: safety-тесты в CI с порогом 100%, проваленный тест блокирует деплой. Один внешний взгляд при каждом пересмотре обязателен. Без него свод покрывает только прямые провокации и пропускает манипуляции эмоцией или кросс-доменные обходы.
Ограничители: параметры автономии
Здесь живёт реальное управление: «AI закрывает обращение при уверенности больше 0.9 на базовом сегменте»; «скидка до 10% автоматически, 10–20% с подтверждением владельца, выше эскалация». Реакция на нарушение: откат сегмента с явной датой пересмотра, обычно через 3 недели. Это штатная операция, а не провал команды. Ритм изменений: 2–6 недель по результатам eval (автоматических проверок качества модели). Владельцы: владелец процесса и владелец качества вместе. Первый отвечает за бизнес-эффект, второй за метрики. Машинная проверка: accuracy-тесты с трендом, где падение качества 2 недели подряд запускает расследование. Связку с реальной работой даёт лог решений: каждое значимое расхождение между AI и оператором становится кандидатом в правку ограничителя.
Рекомендации: как делать операционно
Протоколы расследования инцидента, регламент обновления базы знаний, шаблоны для типовых ситуаций. Реакция на нарушение: peer review и постмортем, без блока релиза. Ритм: после каждого разбора. Владеет команда процесса; внешний взгляд берётся у владельца другого процесса. Машинная проверка: регрессионные тесты. Падение качества больше 10% на сегменте больше 20% объёма блокирует релиз.
Когда применяется
Сегментная калибровка определяется не размером компании, а сложностью процесса и регуляторной нагрузкой. В SMB до 100 человек первый свод чаще получается на одной странице: 5–15 красных линий, 15–40 ограничителей, 10–25 рекомендаций. Если красных линий больше 25, половина из них замаскирована под запреты, хотя по сути это ограничители. Инструмент: Google Docs или Notion с историей версий, плюс простой Python-скрипт прогона eval в GitHub Actions. Полная настройка инфраструктуры занимает пару часов работы с AI-ассистентом.
В Mid-market (100–1000 сотрудников) появляется отдельная функция качества (Eval Specialist на 25–40% занятости), Compliance уже есть в оргструктуре, документооборот переезжает в Confluence или Notion. Ритм такой: еженедельная ревизия ограничителей против eval-результатов, ежемесячная ревизия красных линий. В Enterprise (1000+) подключается совет управления AI (AI Governance Board) с правом утверждения изменений ограничителей выше A4 и всех красных линий. Chief AI Officer ведёт реестр сводов по принципу «один процесс — один свод», с общим стандартом оформления.
Mid B2B-компания в снабжении (~350 человек) на седьмом месяце трансформации сменила модель без ревизии свода: «правила те же, всего лишь сменили модель». Через две недели старый ограничитель «закрывать заявку при уверенности больше 0.85» начал срабатывать в 2.3 раза чаще, потому что новая модель системно увереннее. Четыре заявки крупного клиента закрылись без проверки оператором; в одной возникла некорректная номенклатура и потеря 380 тыс ₽ маржи. Лечение заняло неделю: перекалибровка порогов по eval, новый порог 0.92, новый протокол «при смене модели — обязательная проверка распределения уверенности». Стоимость профилактики на месяце 7 составила бы около 25 тыс ₽ времени против 380 тыс ₽ инцидента. Это типовая пропорция 1:15 для пропущенного триггера обновления.
Свод не применяется на прототипе и proof-of-concept: задача стадии в том, чтобы выяснить, есть ли ценность вообще. Базовый свод стартует с переходом в production даже на A1; полный — с A2.
Кто отвечает
Каждый из трёх слоёв имеет своего владельца, и размытие ответственности остаётся самой частой ошибкой дизайна. За красные линии в Mid и Enterprise отвечает Compliance совместно с Legal; в SMB этот слой ведёт генеральный с поддержкой юриста-фрилансера на разовые часы. За ограничители отвечают владелец процесса и владелец качества вместе. Владелец процесса смотрит на бизнес-эффект, владелец качества на метрики и стабильность; решение об изменении ограничителя принимается совместно по eval-результатам. За рекомендации отвечает команда процесса, peer review даёт владелец другого процесса с похожей доменной спецификой. Над всем стоит единый владелец свода как артефакта: в SMB это владелец процесса с компенсационным механизмом против слепого пятна, в Enterprise эту роль закрывает Chief AI Officer.
Типичные ошибки
Театр свода правил. Команда написала 50 страниц, положила в SharePoint, забыла. Через 6 месяцев происходит инцидент, в своде есть подходящее правило, но никто о нём не помнил. Признак: свод не менялся больше 3 месяцев и ни разу не блокировал релиз. Лечение: привязка к pipeline. Новый релиз без прохождения safety-тестов из красных линий не выходит в production. Это первый уровень управления, а не опциональная возможность.
Два расходящихся документа. Compliance-документ для аудита живёт в Word на SharePoint, операционные правила в Confluence или Notion, между ними нет ни автоматической, ни ручной сверки. Через год документы расходятся на 30–60%, и регулятор получает документ, который не отражает реальное поведение системы. Это юридически хуже честного снимка живого свода: есть письменное обязательство, которому система не соответствует. Лечение: один источник в Git или Confluence с историей, снимок для аудита генерируется выгрузкой раз в квартал. Compliance подписывает снимок, не каждую строку правил.
Свод не пересматривается при смене модели. Самая дорогая из трёх ошибок. Старые пороги по уверенности были откалиброваны под распределение прежней модели; новая распределяет уверенность иначе, и через 2–3 недели идут каскадные ложные срабатывания. Команда ищет причину в базе знаний и в данных, там её нет. Лечение: чек-лист смены модели из 5 пунктов в обязательном порядке. В Git появляется коммит с пометкой model-swap-revision рядом с датой обновления.
