MITR

01  Задача

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

Для регулируемой среды — банк, объект КИИ, юридическая практика — этого мало. Здесь нужна не правдоподобность, а воспроизводимость, проверяемость и невозможность нарушить установленную политику. Это требования не к качеству отдельных ответов, а к поведению системы как целого.

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

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

02  Принцип: снятие противоречия, а не компромисс

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

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

В терминах ТРИЗ это снятие противоречия в направлении идеального конечного результата — когда нужное свойство (безопасность) обеспечивается самой структурой, а не добавленным «сторожем», которого можно обойти. Безопасность здесь не контролируется постфактум, а доказывается до исполнения. Этим подход отличается от модерации, фильтров и проверок, навешенных на модель снаружи.

03  Действие как объект

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

Принцип одинаков для всех агентов системы. Он не зависит ни от того, какая модель породила действие, ни от того, на каком стеке развёрнут агент. Таково свойство регулятора: он работает с действием как с объектом, безотносительно того, что происходит внутри генератора.

04  Градиент необратимости R0–R5

Действия неравнозначны. Чтение реестра не несёт последствий; необратимое удаление — несёт. Двоичная модель «разрешено / запрещено» одинаково строга к обоим и потому одновременно избыточна и недостаточна.

MITR классифицирует каждое действие по шкале необратимости — от R0 (чтение, нулевое последствие) до R5 (деструктивное, невосстановимое). Класс определяет, какие проверки обязательны. Чем выше цена ошибки, тем строже и дороже проверка; чем ниже — тем легче путь. Ресурс верификации концентрируется там, где ущерб реален, и не тормозит безобидные операции. В текущей редакции таблица охватывает восемь классов критических операций.

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

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

05  Контур проверки

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

5.1. Независимая проверка (Multi-Box)

Действия класса R3 и выше проверяет второй модуль на основе модели другого семейства. Первый порождает решение; второй выносит вердикт — согласен, не согласен, не уверен — с обоснованием. Расхождение фиксируется как событие безопасности и блокирует исполнение до решения оператора.

Проверка эмпирическая, а не формальная. Её смысл — снизить вероятность согласованной ошибки, возникающей из общих смещений одной модели. В инженерии надёжности это резервирование разнородными каналами: два независимых тракта ошибаются вместе реже, чем один. Метрики consensus rate и uncertainty rate измеряются; решение зафиксировано в ADR-0005.

5.2. Формальная проверка (SMT, решатель Z3)

Для деструктивного класса R5 политика записана на языке логики первого порядка, а допустимость действия проверяет решатель выполнимости формул в теориях — Z3. Действие допускается тогда и только тогда, когда из контекстных фактов формально выводится соответствие политике. При отказе решатель возвращает unsat core — минимальный набор условий, приведших к отказу, то есть точную причину.

Здесь «вероятно, безопасно» заменено на «доказано соответствие — либо не исполняется». На дату публикации реализован пилотный фрагмент: один класс действий R5. Расширение на остальные классы R5, затем на R4 — задача Фазы I; полное покрытие R3–R5 — задача Фазы II.

5.3. Эпистемический контур

У каждой записи памяти агента есть происхождение: источник, дата, уверенность. Входящая информация обязательно относится к одной из трёх категорий — установленный факт, гипотеза, шум (приоритетное rule-based ядро с резервным запросом к модели, ADR-014). Эпистемический тег сохраняется как неотъемлемый атрибут записи и сопровождает её на всех дальнейших этапах.

Уверенность периодически пересматривается в режиме challenge pass: система берёт старые записи высокой уверенности и пытается опровергнуть их новыми данными. Противоречие снижает уверенность, устойчивость — повышает.

Это отрицательная обратная связь по знанию — тот же кибернетический механизм, что удерживает термостат у заданной температуры; только здесь он удерживает базу знаний у проверяемого состояния и не даёт накапливаться «уверенным» ошибкам. Так закрывается одна из главных уязвимостей агентов с долгой памятью — старые ошибочные «знания», которые больше никем не перепроверяются. Контур реализован в архитектуре; полная активация по слайсам памяти — задача Фазы I.

06  Инварианты архитектуры

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

Абстракция провайдера модели. Все вызовы моделей идут через единый интерфейс. Ядро не зависит от конкретной модели; добавление новой — адаптер плюс запись в конфигурации.

Политика — отдельный артефакт. Её изменение не требует правки core-кода и применяется горячей перезагрузкой без повторного развёртывания.

Действия R3+ — только через verifier. Единая точка исполнения устроена так, что обход слоя верификации для модели архитектурно невыразим. Оговорка о режиме: на исследовательском стенде шов между воротами и исполнением работает в наблюдательном режиме — ворота считают и пишут вердикт, а эффект даёт прямой вызов; исполненных действий, прошедших ворота в зачёте, на 07.09.2026 нет. Публичный ряд говорит об этом прямо: «проверка исполненных действий не измеряется».

Журнал с первого действия. Каждое решение verifier’а пишется в структурированный журнал; формат спроектирован под 17-й приказ ФСТЭК (раздел 07).

Данные в юрисдикции РФ. Целевая сборка на объекте заказчика не предполагает хранения, обработки или передачи пользовательских данных за пределы РФ.

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

07  Журнал решений

Каждое решение слоя верификации фиксируется в структурированном журнале. Текущая эксплуатация ведёт его в режиме append-only: записи добавляются и не изменяются ретроактивно.

Референсная схема записи, спроектированная под 17-й приказ ФСТЭК, включает поля:

timestamp · event_type · actor_id · action_type · target_resource · parameters · decision (allow / deny) · decision_reason · policy_version · agent_id · session_id

Эталонная схема предусматривает хеш-цепочку записей для криптографического обнаружения ретроактивной правки, подписи коммитов и журналирование на физически отдельный том — стандартные требования эксплуатации в КИИ-контуре. Подписи коммитов и журналирование на физически отдельный том разворачиваются при аттестации на конкретном объекте. Хеш-цепочка при этом работает и на исследовательском стенде: записи сцеплены SHA-256, целостность пересчитывается в браузере читателя, корень цепи публикуется у внешнего свидетеля.

Формат публикуется как референсная схема и предназначен для адаптации в других системах под 187-ФЗ.

08  Состояние и фазы

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

Фаза I — пять исследовательских milestone-ов

(1) schema-validation между выводом модели и executor’ом; (2) внешняя политика как версионируемый артефакт с аттестацией хешем; (3) расширение SMT-проверки на полное покрытие R5 с бенчмарком latency и состязательными кейсами; (4) активация эпистемического контура на slice-выборках памяти; (5) challenge pass MVP — еженедельный пересмотр уверенности записей. Каждый milestone сопровождается письменным артефактом (ADR / препринт) и тестовым покрытием. Фаза II — расширение покрытия и сертификация; её содержание определяется по результатам Фазы I.

09  Модель публикации

Открыто: методология, архитектурные инварианты, референсная схема журнала, шкала классов необратимости, принцип Multi-Box Consensus, дорожная карта фаз, агрегированные метрики эксплуатации, препринты по результатам milestone-ов.

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

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