Кратко

  • draft-smith-opsawg-ai-network-governance-01 прямо говорит: передача ограничений сервису ИИ не заменяет независимое программное enforcement.
  • Допустимое предложение, принятая управляющая операция и отправленный rollback не доказывают ни одну и ту же власть, ни восстановление сервиса.

Промпт сообщает модели остаток лимита. Между запросом к модели и действием агент перезапускается. Какой остаток действовал при исполнении?

Ответ нельзя получить из текста промпта. Нужен след состояния и точная версия правил, которыми локальный исполнитель разрешил изменение.

Именно эту границу полезно извлечь из draft-smith-opsawg-ai-network-governance-01, опубликованного 27 сентября 2026 года. Это активный индивидуальный Internet-Draft без одобрения IETF, рабочего консенсуса, RFC stream или формального статуса. В заголовке указано Informational. Документ представляет архитектурное предложение, а не стандарт или отчёт о внедрении.

Он охватывает системы с четырьмя свойствами: прямой доступ к management plane устройства; внешний сервис ИИ для анализа и предложения; изменение конфигурации или состояния без одобрения каждого действия человеком; NETCONF, RESTCONF, gNMI или подобный интерфейс. Чисто рекомендательная система исключена.

Внешний сервис получает контекст и предлагает. Локальный агент собирает телеметрию, обнаруживает отклонение, проверяет и выполняет. ИИ не получает прямого доступа к устройству. Такая изоляция полезна, но делает локальный агент привилегированной точкой пересечения политики, учётных данных и истории.

Action Registry — фиксированный каталог разработчика с параметрами, риском и обратимостью. Operator Allow List — разрешённое подмножество для конкретного deployment. Предложения вне каталога отбрасываются; модель не создаёт новые типы. Параметры вне диапазона запрещены независимо от confidence.

В prompt следует сообщать разрешённые и блокированные действия, protected targets, rate limits и risk ceiling. Это сокращает бесполезные предложения и помогает объяснять escalation. Но Section 16 устанавливает решающую границу: сообщение ограничений не заменяет программное применение. Каждое предложение независимо проверяется. Section 17 повторяет контроль на prompt, parser, guardrail и execution layer.

Значит, хороший prompt не является доступом, а «guardrail passed» без входов не является достаточным аудитом.

Квитанция действия должна связать одобренный человеком policy snapshot, версии Registry и списков, правила целей, границы параметров, риск, состояние счётчиков, degradation, revocation, предложение, parse result, verdict, проверку перед исполнением, аутентифицированную операцию, pre-state, reply, свежую телеметрию и результат rollback или escalation.

Hash промпта обозначает лишь проекцию для внешнего сервиса. Она может скрывать чувствительные правила, упрощать pattern или описывать предыдущий бюджет. Нужна идентичность политики, которую исполнитель действительно прочитал.

Предлагаемые лимиты показывают исторический характер решения. Default в пять remediation actions в час и maximum двадцать, три действия на цель за сутки и maximum пять, а также ограничения необратимых действий, запросов и повторов — предложения индивидуального draft, не универсальные константы.

«Пятое действие часа» требует полного журнала, часов, определения окна и непрерывности после restart. Cooldown, retry, revocation и degradation также зависят от истории.

Section 17.3 рекомендует stateless checks, где возможно, с входами из persistent audit trail вместо памяти, чтобы перезапуск не обнулял счётчики. Состояние не исчезает: власть переходит к журналу и его проекции. Полнота, порядок, retention, время, activation и convergence реплик становятся свойствами безопасности.

Fail-safe примеры последовательны: если rate data недоступны, считать лимит исчерпанным; если target matching сломан, считать цель защищённой; если Registry недоступен, блокировать. Неизвестность не должна становиться разрешением.

После решения политики остаётся устройство. До действия требуется pre-state, после — свежая телеметрия и повторное обнаружение, при отсутствии улучшения — rollback. Cache и suppression не доказывают восстановление.

Снимок конфигурации не возвращает потерянные пакеты, разорванные сессии, исчерпанную очередь или таймер удалённого peer. Rollback — новая операция вперёд в меняющейся системе. Ему нужны собственный ответ, чтение и наблюдение сервиса.

Single target не означает single impact. Один interface или metric может входить в общий failure domain. Локальная команда распространяет эффект через convergence и перенос трафика.

В prompt injection данные устройства — logs и descriptions — могут воздействовать на модель. Санитизация помогает; основная защита состоит в advisory-only статусе ИИ и независимой проверке. Тест должен пройти parser, Registry, target, parameter, history, execution и failover, а не только показать отказ модели.

Draft называет audit trail главным механизмом accountability и рекомендует защиту целостности и внешнее хранение. Там должна находиться квитанция политики. Startup config log не объясняет действие после нескольких reloads.

Авторы пишут, что концепции происходят из production experience. Это их утверждение, не независимое исследование с масштабом, частотой инцидентов и результатами. Пороговые значения остаются локально проверяемыми гипотезами.

Принцип Heng Lu о минимальной начальной спецификации поддерживает проверяемые инварианты: ИИ не расширяет словарь; неизвестная политика закрывает; агент не меняет свои правила; каждая mutation указывает authority. Reality Layers отделяет символ «allowed» от сетевого состояния. Running-Code Primacy требует readback и результата сервиса.

Источники