Кратко

  • draft-fengfar-led-01 рекомендует сначала сформировать собственную позицию, затем использовать ИИ, проверить соответствие результата этой позиции и всегда действовать прозрачно. Но документ остаётся активным индивидуальным Internet-Draft, а не политикой IETF.
  • В сферу входят электронная почта, слайды, обсуждения в репозиториях и, возможно, мгновенные сообщения. Текст Internet-Drafts и RFC прямо исключён, поскольку к нему также относятся BCP 78 и BCP 79.
  • Полезное раскрытие должно быть связано с конкретным вкладом и фиксировать ответственного человека, функцию и охват инструмента, границу материалов, проверки, финальное одобрение, автономную отправку и путь исправления.

Архив хранит текст, но не способ его появления

В обсуждении стандартов сегодняшнее письмо может стать источником через много лет. За это время модель изменится, интерфейс исчезнет, а участники забудут контекст. Поэтому короткая метка об ИИ способна сохраниться дольше всего и объяснить меньше всего.

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

Самая короткая рекомендация draft-fengfar-led-01 звучит как “Always be transparent”. Авторы не выдают её за готовый механизм. Они называют конкретные советы крайне предварительными, а в заключении говорят, что решать ещё рано. Более твёрдый вывод состоит в том, что IETF следует разработать руководство до того, как доверие к почтовым обсуждениям ослабеет.

Формальный статус ограничивает возможные выводы. Datatracker показывает активный индивидуальный Internet-Draft со статусом I-D Exists, без RFC stream, ответственного Area Director и даты telechat. Сообщение от 31 июля называло работу черновой, непредписывающей и неавторитетной. Версия 01 от 6 августа учла вопросы общей дискуссионной рассылки. Это не принятие Working Group, не rough consensus, не решение IESG и не правило IETF.

26 августа статья George Michaelson в APNIC Blog привлекла дополнительное внимание, связав помощь ИИ с трудностью участия на английском языке в стандартах и политике RIR. На странице оговорено, что мнения автора не обязательно представляют APNIC. Расширилось обсуждение, но не полномочия документа.

Граница охвата разделяет разные режимы

Проект говорит о тексте в обсуждениях IETF: сообщениях рассылок, слайдах заседаний, GitHub issues и pull requests, а возможно, и мгновенных сообщениях. Он явно не включает текст Internet-Drafts и RFC. Для таких вкладов существуют дополнительные условия прав и интеллектуальной собственности в BCP 78 и BCP 79.

Будущее руководство для почты поэтому не определит автоматически авторство и раскрытие внутри стандартного документа. И наоборот, запись в благодарностях Internet-Draft не расскажет, переводились, суммировались, генерировались или автоматически отправлялись десятки окружающих писем.

Исходная ситуация точно показывает пробел. Один участник применил ИИ, чтобы яснее выразить самостоятельно сформированные идеи. Читатель увидел признаки LLM и перестал читать, поскольку доля человеческой работы была неизвестна. Авторы сохранили обе точки зрения, не объявляя победителя.

Их человеческая граница полезна: определить позицию до обращения к инструменту, проверить верность текста этой позиции, а не только грамматику, и полностью отвечать за отправленное под своим именем. Но принцип ответственности ещё не является записью, доступной для проверки.

Скорость автора становится временем читателя

Языковая помощь действительно может расширить доступ. Точное понимание протокола и идиоматический английский — разные навыки. Перевод и редактура позволяют тратить меньше сил на форму и больше на инженерную проблему.

Та же возможность переносит издержки. Один отправитель быстро создаёт длинный и гладкий ответ, а многие читатели медленно проверяют факты, ищут реальное разногласие и выясняют, понимает ли человек утверждение. Если агенты отвечают агентам, объём может выглядеть как внимание сообщества без независимого суждения.

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

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

Соседние документы не образуют одну норму

RFC 9775 — близкий пример из IRTF. Он представляет консенсус IRSG и прямо заявляет, что не является продуктом IETF или стандартом. В его области генеративный ИИ нельзя указывать как автора. Значительные объёмы сгенерированного текста или другого материала следует раскрывать, например назвать систему и её вклад. Помощь в орфографии, грамматике, переводе и оформлении раскрывать не требуется.

Group Note Консультативного совета W3C от марта 2026 года выбирает другой порог: ясная метка, когда содержание преимущественно является выходом LLM. Документ требует личной ответственности, проверки точности, защиты конфиденциальности и отказа от автоматических ответов, подменяющих обсуждение. Его поддерживает Advisory Board, а не весь W3C или его Members.

«Значительные объёмы», «преимущественно выход» и «всегда прозрачно» — разные институциональные решения. Их нельзя считать тремя формулировками глобального правила или незаметно переносить между IRTF, W3C и IETF.

Запись об ответственности по предложению Daniel Kade

Минимальная единица — запись, связанная с идентифицируемым вкладом.

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

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

Далее записывается человеческая работа. Какие фактические источники и ссылки проверены? Сверялся ли текст с реальной позицией отправителя? Одобрил ли человек финальный вариант? Мог ли инструмент отправлять самостоятельно? Какая версия политики действовала и где исправить или заменить ошибочное раскрытие либо вклад?

Название модели может быть контекстом, но не центром. Поставщик меняет поведение, сохраняя торговое имя. И само имя не доказывает понимание протокола, проверку цитаты или принятие ответственности.

Это предложение Daniel Kade, а не требование текущего проекта. Его цель — оставить решение человеку и сделать выполнение инструмента достаточно видимым для аудита.

Сначала определение, потом модерация

RFC 9245 определяет общую дискуссионную рассылку и относит туда вопросы направления, политики и процесса стандартов IETF, когда нет более подходящего места. RFC 9945 разделяет ответственность участников, администраторов, модераторов, Area Directors и IESG на публичных площадках. Меры ограничены нарушающей обсуждение коммуникацией и сопровождаются публичными процедурами, пересмотром и апелляцией.

Ни один RFC не создаёт тест авторства ИИ и не превращает стилистическое подозрение в отдельное нарушение. Если раскрытие когда-либо соединят с модерацией, определение должно появиться раньше санкции: порог, стандарт доказательств, уведомление, исправление и апелляция. Иначе обвинение по стилю станет процедурной властью.

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

Чего нельзя заключить

IETF не приняла и не отвергла участие с помощью ИИ. Нет данных, что сгенерированный текст изменил реальный результат консенсуса. Проект не устанавливает сегодня обязанность раскрывать каждое сообщение с помощью инструмента.

RFC 9775 не регулирует обычное обсуждение стандартов IETF только потому, что опубликован в RFC Series. W3C Group Note не выражает консенсус членов W3C. Статья в APNIC Blog не является политикой APNIC. Пакет доказательств не показывает, что конкретный участник исказил авторство или делегировал автономную отправку.

Ограниченный вывод надёжнее: обсуждение правильно нашло ответственного человека, но ещё не определило запись, по которой читатель проверит ответственность. «Всегда прозрачно» задаёт направление. Управлением оно становится, когда конкретны объект, полномочия, проверка и исправление.

Источники

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179